bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: [Translation-i18n] Handling qt-format in gettext tools (was: Updatin


From: Bruno Haible
Subject: Re: [Translation-i18n] Handling qt-format in gettext tools (was: Updating qt-format handling?)
Date: Sat, 20 Oct 2007 23:52:57 +0200
User-agent: KMail/1.5.4

Chusslove Illich wrote:
> We started running the 0.16.2-pre5 on the KDE repository side, to give it a
> shakedown, and stumbled upon a problem with msgmerge and plural messages.
> The message initially has a wrong format directive (habit from KDE3):
> 
>   #, c-format
>   msgid "Add resource from addressbook"
>   msgid_plural "Add %n resources from addressbook"
>   msgstr[0] "Engadir un recurso dende o libro de enderezos"
>   msgstr[1] "Engadir %n recursos dende o libro de enderezos"
> 
> Then the code is corrected such that the plural part gets %1 instead, and
> after the translation is merged:
> 
>   #, kde-format
>   msgid "Add resource from addressbook"
>   msgid_plural "Add %1 resources from addressbook"
>   msgstr[0] "Engadir un recurso dende o libro de enderezos"
>   msgstr[1] "Engadir %n recursos dende o libro de enderezos"
> 
> i.e. the fuzzy flag does *not* get set. So we end up with msgmerge producing
> invalid out of valid POs.

Many thanks for this report! This bug could really become a nightmare for
translators. I've fixed it now.

> In fact, it seems to me that msgid_plural is just being ignored on merge,
> making this somewhat a wider problem.

The msgid_plural is indeed not part of the comparison criteria during merge.
The assumption is that if the singular forms are the same, the plural forms
will be the same - except that they may differ in insignificant ways.
Evidently, when switching from c-format to kde-format, this is not the case
any more.

Now, I've made the plural checking in msgmerge stricter (as strict as in
msgfmt): It will detect that msgstr[1] should consume as many arguments
as msgid_plural, when viewed as a kde-format string, and since it does not
do that, it will mark it fuzzy.

> Perhaps a good enough fix would be to, after a positive match by
> msgctxt + msgid has been established, just additionally match msgid_plural
> and fuzzy if different?

This is a excellent idea. I'll implement this as well.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]