>>>>> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> you tried to fix a language recognition problem but that is Michael> not the issue. Our problem is that gettext (MinGW, Michael> --with-included-gettext) doesn't really care about what we do Michael> in messages.C. It seems to check LC_MESSAGES et al. by Michael> itself. Actually gettext only uses the values when the variables are set. Otherwise, if checks the windows values via GetThreadLocale, which is the right thing to do if we want to have proper windows support (we do not want to have to set variables in some batch file, do we?). So the long term goal is IMO to use Get/SetLocaleThread in windows, which is probably not too difficult if we add the list of windows language IDs to the lib/language file. Michael> Here comes a minimal patch for the Windows platform. It just Michael> captures two NULL values returned from setlocale and uses the Michael> output of gettext no matter whether we were able to set the Michael> locale or not. It looks good, although I have difficulties reading non-unified diffs... Note that we get NULL as result because windows does not have the LC_MESSAGE category. I wonder if we could try to query another one... For example, I am not sure your test for NULL with LC_CTYPE is necessary (but it does not hurt). Michael> Comments? It should (hopefully) not affect behaviour on other Michael> platforms. BTW: According to the man pages, gettext ALWAYS Michael> returns a reasonable string. There is no real need to check Michael> for NULL. So, what does work and what does not with the patch? Do you get translated document strings? Also, there are some interesting informations at: http://www.haible.de/bruno/gettext-FAQ.html#windows_woe32 In this FAQ it is said also that bad accents (ascii form that have been reported elsewhere) is due to not setting LC_CTYPE correctly. JMarc
