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

> Hi
> 
> Vaclav wrote,
> >[email protected] wrote:
> >> msgfmt.exe supplied with poEdit generates incompatible hashtables
> >> if the original strinsg contain characters with the MSB Bit Set (iE
> >> iso8859-1 characters or UTF8 coded characters .)
> >> the msgfmt.exe supplied with the win32 gettext packages does not
> >> have this problem ...
> 
> >Sorry, but I don't have the slightest idea what are you talking
> >about.
> 
> So just do the follwing:
> a) get either:
> 	http://sourceforge.net/projects/gettext/
> 	or the origiunal for UNIX (www.gnu.org)
> b) generate MO files (with the poEdit supplied ones AND the original
>    ones)
> c) read them with the standard hashalgorithm found within the gettext
>    library, DONOT use wxWidgets localing system, which generates its own
>    hashtables...
> d) compare the result !
> 
> You will notice essentiual differences if you use chars like "???" with
> the string to compare! (the MO supplied hashtable will be different ...)
> 
> [email protected] wrote:
> > You will notice essentiual differences if you use chars like "=D6=C4=DC"
> > with the string to compare! (the MO supplied hashtable will be
> > different ...)
> 
> So what? I don't understand (because you didn't explain) why should=20
> this be a *problem* and what you mean by "incompatible hashtables".=20
[...]
> If I did what you told me to do, I would end up=20

have you done this and checked with the hashtable ?

> 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 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) I do expect the essential information
be identical (the hashtable).

(Sorry: but telling others to read Documantation and FAQ's 
 correctly expects yourself doing the same ! )

I actually suspect, 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...) which will
sure get different results on the hashvalue follwing a different
hashtable.
(As I stated above this is ONE possibility for this, which
 shouldn't be with an open fileformat, which is supposed to be
 redistributable between Systems)
Sure the one who is able to track this down is the one building the
0.12.1 Binaries poEdit is supplying.

At least I see two approaches for this:
a) ignore the hashtable within mo-file and generate your own (this has
   been done at wxwidgets ... 
   This is what I needed to do, to workaround this.
b) change the programs poEdit calls to supply a correct hashtable.

Gruss
	Wolfgang


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504