[zanata-users] Format specifiers and Plural forms

[Noriko Mizumoto]

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

noriko

(2014年07月28日 18:14), Ding Yi Chen wrote:
>
>
> ----- 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.
>