[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: RFC: Out with %n in KDE4
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2006-07-15 14:54:26
Message-ID: 200607151654.26610.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Nicolas Goutte :]
> GNU uses plural with printf, so perhaps some translation programs could
> assume that too. And especially as we do not know the state of KBabel
> [...]

Exactly the point is that if translation program complies to Gettext 
standards, then it cannot object to this or that placeholder in plural 
messages.

And I don't think they would even try to be "smart" and assume printf, 
because there are many possibilities of what number placeholder can be. In 
any case, that would be plain broken behavior.

> And the more KDE4 has differences, the more we would have to explain.

KDE, same as Qt, has that key difference that placeholders encode nothing, 
they are just a list of indices. Translators anyway have to adapt (and are 
adapted) to that.

In C-style printf placeholders encode types, and eg. in Python they encode 
argument comments (like %{outfile}). So difference of placeholder formats 
is already a reality.

Now that I mention Python, I kind of like the comment-encoding, but I 
decided that *that* would be too much of a change for our programmers and 
translators.

> Another point is that developer will continue to write "One item",
> "%n items" (be %n now be written %1 or %d in KDE4) like now, so that you
> do not have the %1 anymore. (How does msgfmt --check react with such a
> qt-format entry?)

Hm, now I too played around with this, and Gettext seems to use a strange 
heuristic with c-format:

If the msgstr[0] can happen for more than one number, than placeholders are 
checked against msgid_plural, period.

If the msgstr[0] can happen only for 0, then it gets weird. For example, 
aside from what you mentioned in another message, this will pass the 
check:

#, c-format
msgid "one file in %s"
msgid_plural "%d files in %s"
msgstr[0] "one file in %s"
msgstr[1] "%d files in %s"

but so will this:

#, c-format
msgid "one file in %s"
msgid_plural "%d files in %s"
msgstr[0] "one file in nowhere"
msgstr[1] "%d files in %s"

which is obviously wrong, and this:

#, c-format
msgid "one file in %s"
msgid_plural "%d files in %s"
msgstr[0] "one file in %s"
msgstr[1] "%d files in %s"

will *not* pass.

In other words, it seems that if msgstr[0] can happen only for 0, msgfmt 
will allow msgstr[0] to contain no placeholders at all, otherwise it will 
try to match with msgid_plural.

The conclusion is that this heuristic, as long as Gettext developers 
consider it valid, can be applied to qt-format as well. And qt-format 
anyway needs small tweaks in Gettext, so...

> But we have many messages in KDE3 where you have %1, %2... and %n. How
> do you plan to convert those messages? (It is annoying, as it would mean
> that the conversion scripts must be more intelligent than they are
> currently.)

I don't think this is much of a problem. Conversion scripts anyway check at 
some point if it is a plural message, so it is easy to add code to turn %n 
into %1 and increment others.

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]