i18n bug?

[Nicolas Goutte]

On Monday 11 July 2005 23:34, David Faure wrote:
> On Monday 11 July 2005 23:13, Nicolas Goutte wrote:
> > That is bad. So there must be some different support in gettext for it.
(...)
> > (What I do not understand is why this problem is only with gettext
> > 0.14.x, as the new hash code is already in gettext 0.13.x.)
>
> Well, as I said, most users do NOT need gettext. So only a translator
> testing translations would see the problem, and only on some specific
> strings where it makes a difference (it's quite rare to have accents in the
> msgid...). I'm quite sure gettext-0.13.x exhibits the same behavior as
> 0.14.x.

Accents in message ids are perhaps rare but there are more and more of these. 
(It is not only accents but also symbols like the copyright and registered 
signs.)

>
> > > One should really remember that this isn't the only difference between
> > > the two gettexts: we also have a kde-specific patch for plural
> > > handling, so even if "fixing" this hash string thingie was possible, it
> > > wouldn't really allow using gettext-0.14.1 with kde at the moment. So
> > > in fact I wonder why I bothered debugging this ;)
> >
> > As far as I remember, KDE loads the strings the same way. Only the
> > proceeding is different. So we could load with gettext, while keeping the
> > same proceeding.
>
> How does that help? Using "new hash table" function would mean requiring
> "new gettext" .mo files, which means porting the kde-plural-handling to
> 0.14.x - all this for what purpose?

What I do not understand is that KDE is nearly the only application having its 
own gettext runtime. So how does it works outside the KDE world?

>
(...)
> > Which would be a new requirement. Until now, any gettext was supposed to
> > work.
>
> Nope, since it doesn't handle plural forms like KDE does. Nothing new
> there.

I will try to explain it more explicitely.

I meant building the MO files. Until now, every gettext tools were supposed to 
work.

As for KDE's libintl.cpp, it does *not* handle plurals at all! Plurals are 
currently handled by KDE at a higher level (above translate_priv) . So 
replacing libintl.cpp by gettext's runtime would keep a working KDE.

>
(...)
>
> > > So for KDE3 we stay where we are, but for KDE4 we might want to look
> > > into using the new gettext plural handling, if it matches KDE's needs
> > > (IIRC coolo said it didn't, but IIRC he also plans to talk to the
> > > gettext guys ;)
> >
> > The problems for using gettext's plural are:
> > - it would need a new function name (gettext is only C-aware in this
> > matter.) - for context string, we would still need our own code.
> > - KBabel has no support for gettext's plurals (at least not at save).
>
> Well, there you go. No libintl.cpp hash function changing until those
> problems are solved.

One problem has not to do with the other. KDE uses only the normal call 
(normally called gettext()) to work. We do *not* need to support the gettext 
plural form to use the gettext runtime.

As written above, libintl.cpp *does* not handle the plurals. So primary we do 
not care how gettext is supposed to handle its plurals. (Changing to 
gettext's plural forms would be a further step, which is probably outside 
this discussion.)

> (GNU gettext has no support for context at all? That's
> surprising).

As far as I hvae understood the gettext documentation, gettext considers the 
PO/MO file to be the context. (Gettext has functions to call a translation 
from a specific PO/MO file for this reason. This is not KDE's way of seeing 
at the problem.)

Have a nice day!