[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [zanata-users] Format specifiers and Plural forms

Hi David and Ding-Yi
Thank you for sharing the detail!
I will take those information back to my team.


(2014年07月28日 18:14), Ding Yi Chen wrote:

----- Original Message -----
Hi Noriko,

Please see answers inline below.

----- Original Message -----
From: "Noriko Mizumoto" <noriko fedoraproject org>
To: "Ding Yi Chen" <dchen redhat com>
Cc: zanata-users 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 -----

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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]