i18n bug?

Nicolas Goutte nicolasg at snafu.de
Mon Jul 11 19:44:51 BST 2005

On Monday 11 July 2005 20:07, Nicolas Goutte wrote:
> On Monday 11 July 2005 16:03, David Faure wrote:
> > On Monday 11 July 2005 11:39, David Faure wrote:
> > > > Also somebody having time should test if this problem is visible with
> > > > the gettext runtime or not. May be the bug is the old runtime code
> > > > that KDE uses.
> > >
> > > Yes that's the problem. I plan on updating libintl.cpp today.
> (...)
> > 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.
> 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.

I have looked at the loading code of gettext 0.14.1. My idea is not going to 
work, as revision 1 files need quite different to load.

However it seems that using "msgfmt --no-hash" is the solution to use. 
(Revision 1 files need mandatorily a hash table, o that --no-hash probabl 
means wirting a revision 0 file.)

So at configure time, it should be checked if msgfmt allows --no-hash and to 
use that parameter when using msgfmt in KDE.

Have a nice day!

> Have a nice day!

More information about the kde-core-devel mailing list