Re: [poedit-users] Re: Poedit-users digest, Vol 1 #81

Hi,

Wolfgang Jung wrote:
> > If I did what you told me to do, I would end up=20
>
> have you done this and checked with the hashtable ?

No -- I don't what to look *for*.

> > with two .mo files produced by (presumably) different versions
> > of=20 gettext, but it's perfectly normal that different compiler
> > versions=20 produce different output.=20
>
> No, it would be normal thats producing differnt Binarys of the
> programs.. Since I donot know which compiler is used 

*msgfmt* is a compiler that compiles .po files into .mo files.

> for the 
> Program (which creates the MO-File from the PO-File) and it is
> supposed to be possible to redistribute (you will get to this if
> you read the documentation supplied with the gettext(GNU) package,
> it honours little and big endian as well) the MO-Files between
> Systems (and therefor compilers) 

MO means "Machine Object" and is nonportable machine-specific format. 
GNU format is only one of possible formats of .mo files.

> I do expect the essential 
> information be identical (the hashtable).

This has nothing at all to do with portability -- there's no reason 
why the table would be required to be exactly same all the time. On 
the contrary, it's perfectly reasonable to assume that new gettext 
versions may come with a better hashing algorithm and use it instead 
of the old one, in which case the hash would change. Format 
documentation leaves no doubt that you cannot 100% rely on the hash: 
"The hash table contains indices to the sorted array of strings in 
the MO file. Conflict resolution is done by double hashing. The 
precise hashing algorithm used is fairly dependent on GNU `gettext' 
code, and is not documented here."

> I actually suspect,

Finally!

> what is happening at the poEdit supplied 
> msgfmt.exe  vs msgfmt.exe(win32 gettext project)
> The hashing (hash_string.h in gettext package is running on
> 8 Bit characters (hash_string (const char *str_param))
> (char is at least at all compilers I know (old cc on unix, gcc, cc
> (os9) ,...) an 8 Bit type (sure C(++) does not define the width,
> but it has been sort of standard is way). With msgfmt.exe(win32
> gettext project) this gets called with the UTF-8 strings ... which
> nicely 8bits chars ... the msgfmt.exe (poEdit supplied) seems to
> call the hash_string with some other string (maybe: decoded UTF-8
> and wchar...) 

msgfmt is compiled from same (GNU) sources in both cases, so this is 
nonsense. More likely something's wrong with your .po files (and I 
can't resist saying that if you would use ASCII msgids as you are 
supposed to by gettext, you wouldn't have this problem). Or gettext's 
way of handling of non-ASCII msgids changed -- it's a nonstandard 
recently added thing.

Vaclav

-- 
PGP key: 0x465264C9, available from http://pgp.mit.edu/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAwDbzxDYa/UZSZMkRAobWAKCj7U6E/UVTVkwa2QS2M/bERvvbIQCdHNyD
9lJ+c8+HKZygogrRLFK4Q7A=
=h+4w
-----END PGP SIGNATURE-----