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

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-08-18 12:57:11
Message-ID: 200508181457.20311.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Nicolas Goutte :]
> And the solution does not seem to mix well with a normal Gettext
> plural.

I wouldn't really say that it doesn't "mix" well, quite the opposite. By 
this I mean that in a standard Gettext PO, you could have this new 
handling alongside Gettext's plural forms without problems. The only 
question is of policy, I feel such redundacy wouldn't be helpful.

Now I am thinking it over, what exactly are the reasons of wanting to 
switch to standard Gettext for KDE? I remember only of wish to avoid using 
patched xgettext and this problem with plural forms containing newlines.

If so, this new approach for plurals also gets rid of newline problem and 
of part of patch to xgettext, while also freeing programmers from special 
plural syntax. As for other part of the patch to xgettext, handling 
context info... Well, Gnome people are using standard Gettext, and they 
didn't come up with anything else other than embedding context into the 
message by hand, with a delimiter between context and message (like 
"download status|Unknown").

> [...] KDE's plural count or Gettext's plural formula do not give any
> hint of how many additional pseudo-plurals would be needed. [...]

I think Gettext actually can pull it off, by translator specifying more 
specific Plural-Forms: header. But then, every plural message would have 
to have all those forms written out, which doesn't seem desirable.

> The only idea I have is to have:
> msgstr "#0>Zero#1>One#>singular#>plural1#>plural2"
>
> Where #0> would introduce the "0", #1> would introduce "1" and #> the
> normal plural forms.

You are talking about extra functionality to plurals themselves, whereas I 
was only thinking of providing cleaner interface (both on programmer's and 
translator's side) to what is already available, with scripting for 
extras.

I like this idea, I am only concerned about realization. On translator's 
side, it looks reasonable, but I would still like if each plural form 
could begin with same delmiter (with these special cases somehow 
following). Also, in implementation it would no longer be lightweight to 
parse (would have to use QString::split() with regex?)

> Also if you create new notations be careful that a \n at start and a \n
> at end must remain there in the translation or "msgfmt --check" will
> complain.

Didn't think about the starting \n :) That one, I think, happened never 
till now (as opposed to newlines in the middle), so I guess it would be 
enough to allow *only first* delimiter (#>) to be preceeded by \n. At 
runtime that would mean only one light check extra.

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

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

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