[zanata-users] Format specifiers and Plural forms

Mon Jul 28 08:14:48 UTC 2014

----- Original Message -----
> Hi Noriko,
> 
> Please see answers inline below.
> 
> ----- Original Message -----
> > From: "Noriko Mizumoto" <noriko at fedoraproject.org>
> > To: "Ding Yi Chen" <dchen at redhat.com>
> > Cc: zanata-users at redhat.com
> > Sent: Monday, 28 July, 2014 3:33:07 PM
> > Subject: Re: [zanata-users] Format specifiers and Plural forms
> > 
> > (2014年07月28日 14:48), Ding Yi Chen wrote:
> > >
> > > ----- Original Message -----
> > >> Hi
> > >>
> > >> There are two issues raised from Japanese team, and those have been
> > >> filed as the bugs. However, one is stalled leaving the status 'new', and
> > >> another was not fixed but closed.
> > >>
> > >> Could you mind to check them and advise if any chance that Zanata can
> > >> address them better for both us and developers?
> > >>
> > >> * Format specifiers
> > >> See the discussion of the thread title 'Transifex expression check
> > >> problem' at trans ML, original post was here [1]. The bug has been filed
> > >> at Red Hat Bugzilla [2].
> 
> Zanata does not have this issue in general, but it is one we should prepare
> for. Translators are usually not prevented from saving a translation in
> which the format specifier has been changed, but there might be a validation
> warning. It is possible for maintainers to turn a validator to error state,
> which is intended to prevent saving translations that would break a build.
> The important thing is to make sure our validator is smart enough to
> distinguish differences in format specifiers.
> 
> It has been a while since I worked on the validators so I do not remember
> whether the printf variables validator deals with this case specifically.
> Please file a bug for Zanata with a few examples of the changed format
> specifiers that you think should not cause a validation error (source and
> translation strings containing variables with the specifiers). That will
> allow us to set up a test case so we know how well it is handled at the
> moment, and is a good foundation for updating the validator to treat those
> cases properly.

Note that in terms of https://bugzilla.redhat.com/show_bug.cgi?id=960628, 
those specifiers are not actually for printf, but date.

Generally Zanata won't be able to tell what does "%d" means in msgid.
It can be printf format specifiers, date format specifiers, or even some format for custom
program.

If you move those around, it may break, say log analyzer. So in Zanata,
we rely on project maintainer to tell Zanata:

1. If it is Ok to move or add or remove specifiers, set printf validator as "Off".
2. If it is normally recommend to change specifiers, set printf validator as "Warning".
3. If the specifier should stay as-is, set printf validator as "Error".

The default is "Warning", that is, you can save, but it will be shown as Warning.
As a translator, you can turn off the validators for yourself, but only
project maintainer can set the project wide validators.

We parhaps should file an RFE that allow developers to specify the validators
in command line.
-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
DID: +61 7 3514 8239
Email: dchen at redhat.com

Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com