i18n bug?

[David Faure]

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

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