i18n bug?

[Albert Astals Cid]

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?

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, más seguridad 
http://correo.yahoo.es