i18n bug?

[David Faure]

On Monday 11 July 2005 23:13, Nicolas Goutte wrote:
> That is bad. So there must be some different support in gettext for it.
No there isn't. I don't understand what you mean there; they changed the hash function,
that's it. Old versions are not compatible with newer versions.

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

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

> I have looked again quickly at the code: in kdelibs/kdecore/klocale.cpp every 
> loading of a message pass thorugh the translate_priv function. That is not 
> even the KCatalogue level and even less the gettext runtime level
Yes this is what I called the "KDE runtime" in my earlier long mail.
Since we have control over it, it doesn't matter that most people have a different
runtime installed, or have a different gettext installed.
/me waves his hand like a Jedi and says "there is no problem... there is no problem..." ;)

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

> Yes, but distributors make modifications (also in translations probably).
Doubtful.

> > 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. 
(GNU gettext has no support for context at all? That's surprising).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).