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

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-08-18 14:18:54
Message-ID: 200508181618.55599.nicolasg () snafu ! de
[Download RAW message or body]

On Thursday 18 August 2005 14:57, Chusslove Illich wrote:
> > [: 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.

Gettext remains the reference implementation, which continues to be developed, 
while KDE's support remains at an old level.

So it makes that developers need a patched Gettext, not only if they want to 
extract KDE files out of Scripty's context (for example third party KDE 
applications) but also when creating .mo files for KDE packages (as msgid 
with non-ASCII characters have a different hash on old Gettext, like KDE, and 
on never Gettext.)

On the other side, Gettext 0.14 introduced Qt-awareness (%1, %2...) and we 
cannot use that, not even when Gettext 0.14 will become standard somewhen in 
the future, if we continue on the current KDE way.

Personally I do not find this situation satisfactory.

I do not tell that everything has to be done now. Even it cannot be done now, 
especially as there would be a need of the Gettext plural support in KBabel.

However, even if it cannot be so right now, I feel that the way should be 
prepared and especially avoid to artificially block the path.

On the other side, I still think that a scripting extension would be more 
useful if it was not something pure KDE-home-brew but something that other 
projects, for example GNOME, could use too. (Think about being it a 
freedesktop.org specification one day.) So this would mean supporting Gettext 
plurals too.

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

I do not think that completely freeing programmers from thinking about plurals 
is such a good idea. Less work for the developer could well mean more work 
for the translators. A balance would be better I think.

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

Yes, that is the way described in the Gettext documentation. Compared to KDE, 
it has another look in code, as the feature is hidden in KDE on the C++ 
level, while it is not in Gettext's normal way, as Gettext does not even 
provide such a function.

>
> > [...] 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 other problems is suddenly that you would get another formula in KDE than 
for other application in that language. (Which is especially bad for language 
known by msginit, which can generate a plural formula.

>
(...)

Have a nice day!

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