El Do 25 de 03 de 2010 a les 23:23 +0000, en/na Henning Eggers va
escriure:
> Public bug reported:
>
> The following would be validated by 'msgfmt -c' for languages whose
> plural form 0 is only used for one value of n (e.g. n!=1):
>
> msgid "English %d"
> msgid_plural "Englishs %d"
> msgstr[0] "Translation"
> msgstr[1] "%d Translations"
>
Note some things:
1. If the message is a c-format string, this is a valid translation.
2. If the message is a python-format string, this is _not_ a valid translation. The Python interpreter checks for unnamed arguments
and the program will crash.
3. 'msgfmt -c' will validate both of the above cases, although the
Python one will lead to a crash. This should probably be
reported as a bug in gettext upstream
4. Some languages, such as Arabic and Hebrew, need to be able to
specify translations as msgstr[0] "Translation", so they rely on
the feature of being able to discard arguments in C.
> But for languages that don't have such a plural form, the validation
> would fail because the missing format specifier in msgtr[0]. This is
> possible because msgfmt reads and evaluates the plural form expression
> from the PO file header.
>
Are you sure validation would fail? When debugging the Arabic crashes in
the bug from the above comment, I remember that 'msgfmt -c' validated
the translations in all cases, even in Arabic, which has got a different
plural expression. But that was some time ago, so maybe I should
recheck.
> When entering these values in the Launchpad web UI, they will be
> validated in any language. The validation code does not take the
> language into account and there seems to assume n!=1 for a plural form
> expression. It should use the plural expression when validating, though.
>
I do not know the validation code Launchpad uses, but it was my
understanding that it used msgfmt. If there is a change to be made, I'd
suggest to simply tighten the check in python-format strings (point 2.
above). I haven't checked all other *-format cases, though.
El Do 25 de 03 de 2010 a les 23:23 +0000, en/na Henning Eggers va
escriure:
> Public bug reported:
>
> The following would be validated by 'msgfmt -c' for languages whose
> plural form 0 is only used for one value of n (e.g. n!=1):
>
> msgid "English %d"
> msgid_plural "Englishs %d"
> msgstr[0] "Translation"
> msgstr[1] "%d Translations"
>
Note some things:
1. If the message is a c-format string, this is a valid
translation.
translation. The Python interpreter checks for unnamed arguments
2. If the message is a python-format string, this is _not_ a valid
and the program will crash.
3. 'msgfmt -c' will validate both of the above cases, although the
Python one will lead to a crash. This should probably be
reported as a bug in gettext upstream
4. Some languages, such as Arabic and Hebrew, need to be able to
specify translations as msgstr[0] "Translation", so they rely on
the feature of being able to discard arguments in C.
More details here:
https:/ /bugs.launchpad .net/ubuntu/ +source/ language- selector/ +bug/409785/ comments/ 9
> But for languages that don't have such a plural form, the validation
> would fail because the missing format specifier in msgtr[0]. This is
> possible because msgfmt reads and evaluates the plural form expression
> from the PO file header.
>
Are you sure validation would fail? When debugging the Arabic crashes in
the bug from the above comment, I remember that 'msgfmt -c' validated
the translations in all cases, even in Arabic, which has got a different
plural expression. But that was some time ago, so maybe I should
recheck.
> When entering these values in the Launchpad web UI, they will be
> validated in any language. The validation code does not take the
> language into account and there seems to assume n!=1 for a plural form
> expression. It should use the plural expression when validating, though.
>
I do not know the validation code Launchpad uses, but it was my
understanding that it used msgfmt. If there is a change to be made, I'd
suggest to simply tighten the check in python-format strings (point 2.
above). I haven't checked all other *-format cases, though.