i18n bug?

Nicolas Goutte nicolasg at snafu.de
Mon Jul 11 18:43:54 BST 2005


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

Yes, that is the subtle change that I meant. (Sorry that you had problems to 
find it again.)

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

H'm, that is perhaps fine for KDE 3.5, if we have nothing better to keep 
binary compatibility, but this is probably not a long-term solution for KDE4.

Probably we should use the gettext runtime (which seems to be LGPL 2.0/2.1 as 
far as I have understood). If there are still ports not supported by gettext, 
then we could still use the KDE runtime.

I suppoe that the main problem is our own plural handling. But as it works in 
the PO/MO format, it should run for the runtime too. Similar for our content 
handling.

(Using the new plural a I once wished would be nice too, but KBabel is not 
ready for such a change.)

Have a nice day!





More information about the kde-core-devel mailing list