i18n bug?

Nicolas Goutte nicolasg at snafu.de
Mon Jul 11 22:13:22 BST 2005


On Monday 11 July 2005 20:57, David Faure wrote:
> On Monday 11 July 2005 20:07, Nicolas Goutte wrote:
> > On Monday 11 July 2005 16:03, David Faure wrote:
> > > So I can't fix this: we need gettext and the i18n code to use the exact
> > > same hash function, so as long as gettext-0.10.35-kde is the official
> > > KDE gettext, libintl.cpp shouldn't change, and you shouldn't use
> > > another version of gettext (even when no plural forms are involved).
> >
> > I suppose that the gettext's runtime has the same problem and somehow
> > handles it
>
> I haven't tested the old gettext runtime with the new .mo file, but I'm
> quite sure that it would have the same bug as KDE's runtime.

Yes, probably.

>
> > Probably it knows that the hashes of the minor version 0 must be
> > discarded. So perhaps for KDE 3.5, we could use it the other way round:
> > check if it is not minor version 0 and skip the hashes.
>

> AFAICS there is no version number difference between the two versions.
> (The minor version 1 is used for something else; in my case I got
> revision==0 from both gettext tools).

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

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

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 (well, 
originaly, the runtime in KDE comes from glibc).

>
> On Monday 11 July 2005 19:52, Nicolas Goutte wrote:
> > Somewhen 0.10.x will not be distributed anymore and you cannot ask
> > translators to download and compile something or you would get even less
> > volunteers than today.
>
> Well, KDE translators don't need gettext-0.10-kde, except for real-time
> testing of translations.

Which would be a new requirement. Until now, any gettext was supposed to work.

>
> Albert: apart from that, it really doesn't matter that most distributions
> don't ship gettext-kde. KDE release tarballs of kde-l10n ship
> already-compiled .gmo files, so that it doesn't matter which version of
> gettext users or distributors have.

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

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

Have a nice day!





More information about the kde-core-devel mailing list