[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:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2006-07-15 17:54:52
Message-ID: 200607151954.52773.nicolasg () snafu ! de
[Download RAW message or body]

On Saturday 15 July 2006 16:54, Chusslove Illich wrote:
> > [: Nicolas Goutte :]
(...)
> > 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.

But normally with Qt, you always use all arguments. But plurals have the 
problem that sometimes the placeholder cannot be used and must be replaced by 
text. (If I remember well, it was a discussed once that having "1" as number 
for the singular text is not good in some language and that instead the 
word "one" must be translated.)

>
> 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.

Well perhaps you are right with your comment. However it would mean that we 
should consider such a behaviour of Gettext has buggy too and do not consider 
that it will always work with future versions.

>
> 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...

As for tweaking Gettext, well, that is something that we do not control. If 
you can move the Gettext developer to change the behaviour, fine, if not, 
then our problem would not be changed.

>

Well, after all this, I am not sure what the best solution would be. It would 
be stupid to need scriptable translations just for wanting "one" instead 
of "1" in the translated singular text.

(...)

Have a nice day!
[prev in list] [next in list] [prev in thread] [next in thread]