i18n bug?

[Nicolas Goutte]

On Monday 11 July 2005 19:19, Albert Astals Cid wrote:
> That means that no one is going to get correct translations of those texts
> as all modern distributions are using >= gettext 0.14
>
> Could we do a configure check and use a different line given the version
> the user has?

For KDE 3.5, we have to keep binary compatibility. So whatever version is 
distributed, it must work on all systems  (KDE, KOffice, extragears, third 
party....)

However that forces us to find a solution for KDE4.

Have a nice day!

>
> Albert
>
> A Dilluns 11 Juliol 2005 16:03, David Faure va escriure:
> > 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.
> >
> > Phew, finally found the difference.
> >
> > Given
> >   unsigned long int hval;
> >   const char *str = str_param;
> >
> > in gettext-0.10.35 (and in kdecore/libintl.cpp), the hash_string function
> > is defined as hval += (unsigned long) *str++;
> >
> > in gettext-0.14.x, the hash_string function is defined as
> >   hval += (unsigned char) *str++;
> >
> > I'm not sure why it makes a difference, but with msgid=áà (in utf8, so
> > length=4), the hash value is 267522336 with the first line, and 843216
> > with the second line.
> >
> > 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).
>
> ______________________________________________
> Renovamos el Correo Yahoo!
> Nuevos servicios, ms seguridad
> http://correo.yahoo.es