From: Erwin W. <wat...@xs...> - 2009-10-26 21:47:51
|
Hi, Because the automatic language detection was not working with gettext/libintl 0.16.1 I switched to gettext/libintl 0.14.4 distributed by the GnuWin32 project. This was in Nov 2008. The GnuWin32 also supports relocation. I was now trying gettext/libintl 0.17-1 and noticed that the language detection works now, but the relocateability not. Kees Zeelenberg, GnuWin32 maintainer, told me that he 'fixed' the GnuWin32 port so that relocation works. Is it known that MinGW gettext/libintl are not relocatable? Or is this just not enabled? I think it is important that it works, because you never know where a person unpacks the binary package. best regards, -- Erwin Waterlander |
From: Charles W. <cwi...@us...> - 2009-10-26 22:05:36
|
Erwin Waterlander wrote: > I was now trying gettext/libintl 0.17-1 and noticed that the language > detection works now, but the relocateability not. Kees Zeelenberg, > GnuWin32 maintainer, told me that he 'fixed' the GnuWin32 port so that > relocation works. You're going to have to give more details on how it fails, and why you think relocatability does not work. The MinGW version of gettext is compiled using --enable-relocatable, and in fact is compiled with the following prefix: C:/msys/1.0/var/tmp/gettext-reloc-yA4108 So, since it actually works on my system when installed into C:\MinGW, that means relocation is actually working. Now, the *MSYS* version of gettext is NOT compiled with --enable-relocate. If you're using that version by mistake...don't. You want: gettext-0.17-1-mingw32-bin.tar.lzma gettext-0.17-1-mingw32-dev.tar.lzma gettext-0.17-1-mingw32-doc.tar.lzma gettext-0.17-1-mingw32-ext.tar.lzma gettext-0.17-1-mingw32-lic.tar.lzma gettext-0.17-1-mingw32-src.tar.lzma gettext-0.17-1-mingw32.RELEASE_NOTES libasprintf-0.17-1-mingw32-dll-0.tar.lzma libgettextpo-0.17-1-mingw32-dll-0.tar.lzma libintl-0.17-1-mingw32-dll-8.tar.lzma You do not want: gettext-0.17-1-msys-1.0.11-bin.tar.lzma gettext-0.17-1-msys-1.0.11-dev.tar.lzma gettext-0.17-1-msys-1.0.11-doc.tar.lzma gettext-0.17-1-msys-1.0.11-ext.tar.lzma gettext-0.17-1-msys-1.0.11-lic.tar.lzma gettext-0.17-1-msys-1.0.11-src.tar.lzma gettext-0.17-1-msys.RELEASE_NOTES (Well, you probably WANT them, but make sure the msys version is installed over in /usr/*, not <MINGW_PLACE>. Any mingw gcc compiler will always look in <MINGW_PLACE> first, before /usr/[include|lib], where MINGW_PLACE is the root directory into which you've installed mingw gcc itself. If you installed mingw gcc itself into the same place where your msys stuff is (that is, e.g. C:\msys\1.0\*) -- you're screwed. Don't do that. -- Chuck |
From: Erwin W. <wat...@xs...> - 2009-10-26 22:41:41
|
Charles Wilson schreef: > Erwin Waterlander wrote: > >> I was now trying gettext/libintl 0.17-1 and noticed that the language >> detection works now, but the relocateability not. Kees Zeelenberg, >> GnuWin32 maintainer, told me that he 'fixed' the GnuWin32 port so that >> relocation works. >> > > You're going to have to give more details on how it fails, and why you > think relocatability does not work. The MinGW version of gettext is > compiled using --enable-relocatable, and in fact is compiled with the > following prefix: > C:/msys/1.0/var/tmp/gettext-reloc-yA4108 > So, since it actually works on my system when installed into C:\MinGW, > that means relocation is actually working. > > Now, the *MSYS* version of gettext is NOT compiled with > --enable-relocate. If you're using that version by mistake...don't. > > You want: > gettext-0.17-1-mingw32-bin.tar.lzma > gettext-0.17-1-mingw32-dev.tar.lzma > gettext-0.17-1-mingw32-doc.tar.lzma > gettext-0.17-1-mingw32-ext.tar.lzma > gettext-0.17-1-mingw32-lic.tar.lzma > gettext-0.17-1-mingw32-src.tar.lzma > gettext-0.17-1-mingw32.RELEASE_NOTES > libasprintf-0.17-1-mingw32-dll-0.tar.lzma > libgettextpo-0.17-1-mingw32-dll-0.tar.lzma > libintl-0.17-1-mingw32-dll-8.tar.lzma > > You do not want: > gettext-0.17-1-msys-1.0.11-bin.tar.lzma > gettext-0.17-1-msys-1.0.11-dev.tar.lzma > gettext-0.17-1-msys-1.0.11-doc.tar.lzma > gettext-0.17-1-msys-1.0.11-ext.tar.lzma > gettext-0.17-1-msys-1.0.11-lic.tar.lzma > gettext-0.17-1-msys-1.0.11-src.tar.lzma > gettext-0.17-1-msys.RELEASE_NOTES > > (Well, you probably WANT them, but make sure the msys version is > installed over in /usr/*, not <MINGW_PLACE>. Any mingw gcc compiler > will always look in <MINGW_PLACE> first, before /usr/[include|lib], > where MINGW_PLACE is the root directory into which you've installed > mingw gcc itself. > > If you installed mingw gcc itself into the same place where your msys > stuff is (that is, e.g. C:\msys\1.0\*) -- you're screwed. Don't do that. > > -- > Chuck > > Hi, I have installed gettext-0.17-1-mingw32-bin gettext-0.17-1-mingw32-dev libgettextpo-0.17-1-mingw32-dll-0 libiconv-1.13-1-mingw32-bin libiconv-1.13-1-mingw32-dev libiconv-1.13-1-mingw32-dll-2 libcharset-1.13-1-mingw32-dll-1 libintl-0.17-1-mingw32-dll-8 I noticed that I had a different libintl-8.dll. I now installed the one from libintl-0.17-1-mingw32-dll-8, but it made no difference. I'm working on a Dutch Windows Vista. I have MSYS and MinGW installed in different directories. My program was compiled with localedir set to c:/usr/local/share/locale (prefix=c:/usr/local). I pack my program with libiconv-2.dll and libintl-8.dll. To test my program I delete directory c:/usr/local/share/locale and unpack the package at a different location in c:/tmp/wcd/. I get nothing but English messages. I have not set LANG or LANGUAGE environment variables. This is the directory listing: Map van c:\TMP\wcd\bin 26-10-2009 23:35 <DIR> . 26-10-2009 23:35 <DIR> .. 26-10-2009 23:35 0 dir.txt 26-07-2009 02:46 1.070.103 libiconv-2.dll 26-07-2009 03:18 122.719 libintl-8.dll 26-10-2009 23:15 333 wcd.bat 26-10-2009 23:15 211.646 wcdwin32.exe 26-10-2009 23:15 371 wcd_win95.bat This is PATH (MinGW and MSYS are not in it): PATH=c:\tmp\wcd\bin;C:\Program Files\PC Connectivity Solution\;c:\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\ If I do the same test with the GnuWin32 port I get Dutch messages. -- Erwin Waterlander |
From: Charles W. <cwi...@us...> - 2009-10-27 01:10:29
|
Erwin Waterlander wrote: > > I have not set LANG or LANGUAGE environment variables. Try explicitly setting LC_ALL or LANG to the appropriate value. > This is the directory listing: > > Map van c:\TMP\wcd\bin ... I'll assume that your translation catalogs are actually present in c:\TMP\wcd\share\locale... > > If I do the same test with the GnuWin32 port I get Dutch messages. > I bet Zees added a bunch of stuff to automatically set the locale based on the Windows language settings. The mingw port of gettext doesn't do any of that; it is intended to behave like unix gettext -- which requires the LC_* or LANG vars to be set correctly, AFAIK. But I'm no expert in all this... -- Chuck |
From: Erwin W. <wat...@xs...> - 2009-10-27 06:38:03
|
Charles Wilson schreef: > Erwin Waterlander wrote: > >> I have not set LANG or LANGUAGE environment variables. >> > > Try explicitly setting LC_ALL or LANG to the appropriate value. > This doesn't help. These have nothing to do with relocateability. > >> This is the directory listing: >> >> Map van c:\TMP\wcd\bin >> > ... > > I'll assume that your translation catalogs are actually present in > c:\TMP\wcd\share\locale... > Yes. > >> If I do the same test with the GnuWin32 port I get Dutch messages. >> >> > > I bet Zees added a bunch of stuff to automatically set the locale based > on the Windows language settings. The mingw port of gettext doesn't do > any of that; it is intended to behave like unix gettext -- which > requires the LC_* or LANG vars to be set correctly, AFAIK. > > But I'm no expert in all this... > The automatic language detection was ported by Tor Lillqvist. With this you don't need to set the LANG variable (very friendly for Windows users). But you can still select another language by setting LANG/LANGUAGE. For relocation the GNU relocateable module is used. I believe this module was patched by Kees for GnuWin32. It doesn't matter where you unpack the GnuWin32 packages. As long as the directory structure stays the same the language files are found. -- Erwin Waterlander |
From: Erwin W. <wat...@xs...> - 2009-10-26 22:58:08
|
Erwin Waterlander schreef: > Hi, > > I have installed > gettext-0.17-1-mingw32-bin > gettext-0.17-1-mingw32-dev > libgettextpo-0.17-1-mingw32-dll-0 > libiconv-1.13-1-mingw32-bin > libiconv-1.13-1-mingw32-dev > libiconv-1.13-1-mingw32-dll-2 > libcharset-1.13-1-mingw32-dll-1 > libintl-0.17-1-mingw32-dll-8 > > I noticed that I had a different libintl-8.dll. I now installed the one > from libintl-0.17-1-mingw32-dll-8, but it made no difference. > > I'm working on a Dutch Windows Vista. I have MSYS and MinGW installed in > different directories. > My program was compiled with localedir set to c:/usr/local/share/locale > (prefix=c:/usr/local). > I pack my program with libiconv-2.dll and libintl-8.dll. > > To test my program I delete directory c:/usr/local/share/locale and > unpack the package at a different location in c:/tmp/wcd/. I get nothing > but English messages. > > I have not set LANG or LANGUAGE environment variables. > > This is the directory listing: > > Map van c:\TMP\wcd\bin > > 26-10-2009 23:35 <DIR> . > 26-10-2009 23:35 <DIR> .. > 26-10-2009 23:35 0 dir.txt > 26-07-2009 02:46 1.070.103 libiconv-2.dll > 26-07-2009 03:18 122.719 libintl-8.dll > 26-10-2009 23:15 333 wcd.bat > 26-10-2009 23:15 211.646 wcdwin32.exe > 26-10-2009 23:15 371 wcd_win95.bat > > This is PATH (MinGW and MSYS are not in it): > > PATH=c:\tmp\wcd\bin;C:\Program Files\PC Connectivity > Solution\;c:\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\ > > > If I do the same test with the GnuWin32 port I get Dutch messages. > > I had an old libasprintf installed. I installed libasprintf-0.17-1-mingw32-dll-0, rebuild my program, and now it seems to be working. Thanks, -- Erwin Waterlander |
From: Erwin W. <wat...@xs...> - 2009-10-26 23:01:48
|
Erwin Waterlander schreef: > > I had an old libasprintf installed. I installed > libasprintf-0.17-1-mingw32-dll-0, rebuild my program, and now it seems > to be working. > > Oops. I forgot to delete c:/usr/local/share/locale/. before testing. It is still not working. -- Erwin Waterlander |
From: Erwin W. <wat...@xs...> - 2009-10-27 06:56:16
|
Charles Wilson schreef: > > The MinGW version of gettext is > compiled using --enable-relocatable, and in fact is compiled with the > following prefix: > C:/msys/1.0/var/tmp/gettext-reloc-yA4108 > So, since it actually works on my system when installed into C:\MinGW, > that means relocation is actually working. > Gettext and libintl are the only mingw tools shipped with Dutch messages. If I set LANGUAGE to "nl" msginit starts to produce Dutch messages. I confirm that this seems to work. I can't test other mingw tools. -- Erwin Waterlander |
From: Erwin W. <wat...@xs...> - 2009-10-27 08:22:28
|
Op 10/27/2009 07:56 AM, Erwin Waterlander schreef: > Charles Wilson schreef: > >> The MinGW version of gettext is >> compiled using --enable-relocatable, and in fact is compiled with the >> following prefix: >> C:/msys/1.0/var/tmp/gettext-reloc-yA4108 >> So, since it actually works on my system when installed into C:\MinGW, >> that means relocation is actually working. >> >> > > Gettext and libintl are the only mingw tools shipped with Dutch > messages. If I set LANGUAGE to "nl" msginit starts to produce Dutch > messages. I confirm that this seems to work. I can't test other mingw tools. > > Actually I find it strange that I need to set the LANGUAGE variable to "nl" before the gettext tools start to produce messages in Dutch. There seems to be a preference for English. Normal behaviour would be that you get by default messages in the language set in your regional settings (like the GnuWin32 tools behave). Erwin |
From: Charles W. <cwi...@us...> - 2009-10-27 14:50:16
|
Erwin Waterlander wrote: > Actually I find it strange that I need to set the LANGUAGE variable to > "nl" before the gettext tools start to produce messages in Dutch. There > seems to be a preference for English. Not exactly. You appear to not understand how libintl actually works. In the source code of an i18nized package, you might see something like: printf(_("some error message: %s\n"), stringvar); The _() is the macro that invokes the translation on the specified string -- in this case, "some error message: %s\n". Basically, the string as specified in the source code is used as a 'key', along with the LC_ALL/LANG setting, to look up the appropriate translation. However, if (a) no tranlation files are found for the specified LANG, or (b) in the translation file for that LANG, there is no string corresponding to the desired key ("some error message: %s\n"), then the key itself is used. In this example, since the source code was written in English, the "default" I-can't-find-the-translation value is English. But, the source code could have been written as printf(_("bachHa' ngoqDe': %s\n"), stringvar) meaning the default value -- the "preference" as you say -- is Klingon. Of course, that means that all of the translation files would be, in effect, Klingon-to-$LANG translations. The source code of most i18nized packages is written in English, presumably by convention and because there are more volunteers that can create English-to-$LANG translations than using any other base language (Klingon would be a phenomenally bad choice...) > Normal behaviour would be that you get by default messages in the > language set in your regional settings (like the GnuWin32 tools behave). No, to do the translation you need a few things: the phrase you want to translate, which language you want to translate it TO, and the database of translations. (The language you are translating FROM is implicit -- it's whatever the source code was written in). 1) The database of translations is in ${prefix}/share/locale/$LANG/pkg.mo If there are relocation errors, the package might not be able to find this -- and you'll end up with the default (source code) language. In your example, that appears to be English. 2) The phrase to be translated is given in the source as the argument to the macro _(). We have to assume the author did that part correctly. 3) There must be a translation file for your desired language, and it must contain a translation for the specified phrase. You'd be surprised how often translation files are missing one or two phrases... 4) Somehow, the i18n package -- in this case, libintl -- needs to know the desired language to translate to. On unix systems, this is communicated via the environment variables (LC_*, LANG) -- unix has no "registry" in which to look up the "regional settings". Unmodified libintl behaves exactly the same way -- since it knows nothing about this "registry" thing, it will ignore your "regional settings"; set LANG. Since setting LANG enables the translations in your package to work properly, I can rule out problems with #1, #2, and #3 -- the "problem" is #4, and has nothing to do with relocation. Relocation works. Your issue appears to be that you like the non-unixy modifications to libintl that Zees has made to gettext, so that it uses win32-specific methods to determine "regional settings" from the "registry" -- rather than using the unix LC_* and LANG variables. I'm not going to modify the mingw port in this way. If you think this win32-specific behavior is a good thing, then I encourage you to ask Zees to submit the relevant changes to Bruno Haible over at bug...@gn... (archives here: http://lists.gnu.org/archive/html/bug-gnu-utils/) If those changes go into the official gettext, then the MinGW gettext will have them. -- Chuck |
From: Erwin W. <wat...@xs...> - 2009-10-27 16:15:31
|
Op 10/27/2009 03:49 PM, Charles Wilson schreef: > Erwin Waterlander wrote: > >> Actually I find it strange that I need to set the LANGUAGE variable to >> "nl" before the gettext tools start to produce messages in Dutch. There >> seems to be a preference for English. >> > > Not exactly. You appear to not understand how libintl actually works. > > In the source code of an i18nized package, you might see something like: > > printf(_("some error message: %s\n"), stringvar); > > The _() is the macro that invokes the translation on the specified > string -- in this case, "some error message: %s\n". Basically, the > string as specified in the source code is used as a 'key', along with > the LC_ALL/LANG setting, to look up the appropriate translation. > > However, if (a) no tranlation files are found for the specified LANG, or > (b) in the translation file for that LANG, there is no string > corresponding to the desired key ("some error message: %s\n"), then the > key itself is used. In this example, since the source code was written > in English, the "default" I-can't-find-the-translation value is English. > > But, the source code could have been written as > > printf(_("bachHa' ngoqDe': %s\n"), stringvar) > > meaning the default value -- the "preference" as you say -- is Klingon. > Of course, that means that all of the translation files would be, in > effect, Klingon-to-$LANG translations. The source code of most i18nized > packages is written in English, presumably by convention and because > there are more volunteers that can create English-to-$LANG translations > than using any other base language (Klingon would be a phenomenally bad > choice...) > > >> Normal behaviour would be that you get by default messages in the >> language set in your regional settings (like the GnuWin32 tools behave). >> > > No, to do the translation you need a few things: the phrase you want to > translate, which language you want to translate it TO, and the database > of translations. (The language you are translating FROM is implicit -- > it's whatever the source code was written in). > > 1) The database of translations is in > ${prefix}/share/locale/$LANG/pkg.mo > If there are relocation errors, the package might not be able to > find this -- and you'll end up with the default (source code) > language. In your example, that appears to be English. > > 2) The phrase to be translated is given in the source as the argument > to the macro _(). We have to assume the author did that part > correctly. > > 3) There must be a translation file for your desired language, and it > must contain a translation for the specified phrase. You'd be > surprised how often translation files are missing one or two > phrases... > > 4) Somehow, the i18n package -- in this case, libintl -- needs to know > the desired language to translate to. On unix systems, this is > communicated via the environment variables (LC_*, LANG) -- unix has > no "registry" in which to look up the "regional settings". Unmodified > libintl behaves exactly the same way -- since it knows nothing about > this "registry" thing, it will ignore your "regional settings"; set > LANG. > > Since setting LANG enables the translations in your package to work > properly, I can rule out problems with #1, #2, and #3 -- the "problem" > is #4, and has nothing to do with relocation. > > Relocation works. > > Your issue appears to be that you like the non-unixy modifications to > libintl that Zees has made to gettext, so that it uses win32-specific > methods to determine "regional settings" from the "registry" -- rather > than using the unix LC_* and LANG variables. > > I'm not going to modify the mingw port in this way. If you think this > win32-specific behavior is a good thing, then I encourage you to ask > Zees to submit the relevant changes to Bruno Haible over at > bug...@gn... (archives here: > http://lists.gnu.org/archive/html/bug-gnu-utils/) If those changes go > into the official gettext, then the MinGW gettext will have them. > > -- > Chuck > Hi, I understand how gettext works. My test shows that the MinGW gettext tools can produce Dutch messages if I set LANGUAGE. So the Dutch translations are not missing. That I get English if I don't set LANGUAGE is indeed another problem. Not the relocate problem. My program is most used in Windows Console or PowerShell. In these environments it's not common to define LANG and LC_ variables. What's wrong with Windows specific patches for MinGW ports? What's wrong with Tor Lillqvist's patch to read regional settings from the Windows registry instead of locale environment variables? I think this patch was originally made for Gimp. I don't know if this is included in the original libintl source, or that this is patched to the MinGW port. According to you is is not part of the original code. But it shows that you don't need to set LANG or LC_ALL to get messages in other languages. This proves to me that Tor's patch is in the MinGW port. I can just use LANGUAGE to set a language preference (which only works after localization has been enabled). Back to the relocation problem. It's not working for my package when I use MinGW libintl. If you want I can send you source code and a binary package so you can test it yourself. It requires a non-English Windows to test it properly. best regards, Erwin |
From: Tor L. <tm...@ik...> - 2009-10-27 20:37:53
|
> That, however, makes this setting a questionable choice for > determining the UI language of applications. The correct API for it is > GetUserDefaultUILanguage(). That is a question open to debate... Whatever one does, somebody will say it is wrong. > See this blog post by MS's Mr. > International, Michael Kaplan: > http://blogs.msdn.com/michkap/archive/2005/02/01/364707.aspx Which tells you that this option is changeable only on MUI installations of Windows, and the choices are restricted to those MUI alternatives installed. And I don't see him saying that this should also be the default UI language of *3rd-party applications*. I don't think it is that uncommon for people to have a Windows installation in one language, but still prefer to use 3rd-party software with UI (where available) in another. As far as I know, MUI installations of Windows are fairly rare. (I came across my first one when I added that feature to the Windows 7 Ultimate installation on my laptop. The MUI feature wasn't even possible IIRC in a "lower" Windows 7 edition, only in Ultimate.) In any case, the locale on the"Formats" tab in "Region and Language" presumably takes as its default the UI language of Windows. So if I understand correctly, if gettext would use GetUserDefaultUILanguage(), for the majority of users, certainly all using "home" installations of Windows with no MUI, that would mean that to change the UI language of software using gettext, they would have to set the environment variables. In my opinion, it is easier to tell end-users to choose a locale in the "Formats" tab than to tell them how to set environment variables. But yeah, I certainly agree that it isn't uncommon for people to ask for instance "how do I make GIMP use English instead of my local language", presumably because they find the localised terminology somewhat silly. (I belong to this group myself...) The response being then that either they should change the locale in the control panel, shouldn't have installed the localisations in the first place, should remove the share\locale tree, or (you could see this coming) set the LANG environment variable... Typically people who ask this are power users, though, who know how to set an environment variable. --tml |
From: Andy K. <and...@gm...> - 2009-10-27 21:23:18
|
2009/10/27 Tor Lillqvist: >> That, however, makes this setting a questionable choice for >> determining the UI language of applications. The correct API for it is >> GetUserDefaultUILanguage(). > > That is a question open to debate... Whatever one does, somebody will > say it is wrong. > >> See this blog post by MS's Mr. >> International, Michael Kaplan: >> http://blogs.msdn.com/michkap/archive/2005/02/01/364707.aspx > > Which tells you that this option is changeable only on MUI > installations of Windows, and the choices are restricted to those MUI > alternatives installed. And I don't see him saying that this should > also be the default UI language of *3rd-party applications*. He does here: http://blogs.msdn.com/michkap/archive/2007/04/15/2146890.aspx "Now you could in theory use the "Standards and Formats" setting, also known as the default user locale (you would use LOCALE_USER_DEFAULT in that GetLocaleInfo call). It has the advantage of being settable on all platforms, if nothing else. Clearly though, it is not intended to drive the UI language, and thus if you made it drive UI language in your application you would be providing confusing UI to the user. [...] If you are providing a localized copy of your application then you can default to the UI language of the operating system and then you should honestly provide your own user interface to let them change it, based on the list of localized versions of your application that you support. The various lists that Windows provides aren't actually good ways to choose your UI language (beyond that possible idea of the initial one you might choose via GetUserDefaultUILanguage when it is available -- that function is included in almost every version you need other than Win98; it even is there on WinME)." And gettext of course already has its own user interface for changing the UI language: LANG and its relatives. Andy |
From: Charles W. <cwi...@us...> - 2009-10-28 03:09:14
|
Tor Lillqvist wrote: >> However, since this win32-specific behavior is ALREADY part of the stock >> gettext, but apparently isn't working to automatically set the default >> locale, > > To the best of my knowledge, it *should* work automatically. I don't > see that I would use any patch that would affect this functionality in > my build of the libintl DLL. Hmm. Using Andy's recommendation -- that I can change the Formats setting in Region and Language without causing the Windows UI to be modified into (for me) illegibility, I was able to test this. Changing "Current format" to "German (Germany)", I launched the MinGW msgcat as follows: $ echo $LC_ALL $LC_CTYPE $LC_LANG $LANG $LANGUAGE (e.g. no environment variables are set) $ /mingw/bin/msgcat -h Aufruf: c:\MinGW\bin\msgcat.exe [OPTION] [EINGABEDATEI]... PO-Dateien aneinanderfügen und zusammenziehen. Meldungen suchen, die in zwei oder mehr der angegebenen PO-Dateien vorkommen. Changing the "Current format" back to English (United States), and launching it again: $ /mingw/bin/msgcat -h Usage: c:\MinGW\bin\msgcat.exe [OPTION] [INPUTFILE]... Concatenates and merges the specified PO files. Find messages which are common to two or more of the specified PO files. By using the --more-than option, greater commonality may be requested So, it appears that Tor is correct: even the mingw.org version of libintl "works" -- it finds the relocated language files (from C:/msys/1.0/var/tmp/some-random-prefix/share/locale to C:/MinGW/share/locale), AND it switches translations based on not just the unixy envvar settings, but also based on the Regional And Language settings in Windows (at least, under Vista sp 2). [as a side note, setting the envvars takes precedence -- that is, overrides -- the Region and Language value] So, back to the OP's original query: it seems that the problem is not in the mingw.org libintl at all -- or not directly. There is obviously *something* odd going on, because simply dropping in Tor's version allows his client app to work, but using the mingw.org version doesn't. But at this point, I'm afraid that actual debugging will be necessary to figure out why the difference. -- Chuck |
From: Erwin W. <wat...@xs...> - 2009-11-02 20:46:09
|
Charles Wilson schreef: > > Hmm. Using Andy's recommendation -- that I can change the Formats > setting in Region and Language without causing the Windows UI to be > modified into (for me) illegibility, I was able to test this. > > Changing "Current format" to "German (Germany)", I launched the MinGW > msgcat as follows: > > $ echo $LC_ALL $LC_CTYPE $LC_LANG $LANG $LANGUAGE > > (e.g. no environment variables are set) > > $ /mingw/bin/msgcat -h > Aufruf: c:\MinGW\bin\msgcat.exe [OPTION] [EINGABEDATEI]... > > PO-Dateien aneinanderfügen und zusammenziehen. > Meldungen suchen, die in zwei oder mehr der angegebenen PO-Dateien > vorkommen. > > Changing the "Current format" back to English (United States), and > launching it again: > > $ /mingw/bin/msgcat -h > Usage: c:\MinGW\bin\msgcat.exe [OPTION] [INPUTFILE]... > > Concatenates and merges the specified PO files. > Find messages which are common to two or more of the specified PO files. > By using the --more-than option, greater commonality may be requested > > > So, it appears that Tor is correct: even the mingw.org version of > libintl "works" -- it finds the relocated language files (from > C:/msys/1.0/var/tmp/some-random-prefix/share/locale to > C:/MinGW/share/locale), AND it switches translations based on not just > the unixy envvar settings, but also based on the Regional And Language > settings in Windows (at least, under Vista sp 2). > > [as a side note, setting the envvars takes precedence -- that is, > overrides -- the Region and Language value] > > So, back to the OP's original query: it seems that the problem is not in > the mingw.org libintl at all -- or not directly. There is obviously > *something* odd going on, because simply dropping in Tor's version > allows his client app to work, but using the mingw.org version doesn't. > But at this point, I'm afraid that actual debugging will be necessary > to figure out why the difference. > > -- > Chuck > Hi, I had a look at the source code of iconv. Mingw iconv.exe relocation works. What iconv does is the following: relocatable.c and relocatable.h have been added to the source. In iconv main() the following is added: set_program_name (argv[0]); bindtextdomain("libiconv",relocate(LOCALEDIR)); What I do in my program is just from the gettext manual: bindtextdomain (PACKAGE, localedir); So the difference with MinGW iconv is that I'm not using the relocate() function that has been added to iconv. For GnuWin32 relocation the use of relocate() doesn't seem to be a requirement. regards, -- Erwin Waterlander |
From: Tor L. <tm...@ik...> - 2009-10-27 18:39:57
|
> So it's not common. Not my problem. If you want stock gettext/libintl > to provide translation services, then you must set the variables Please have a look in stock GNU gettext 0.17 sources. Look at the function gl_locale_name_default() in gettext-runtime/intl/localename.c. Look for the # if defined(WIN32_NATIVE) part. --tml |
From: Tor L. <tm...@ik...> - 2009-10-27 20:05:35
|
> However, since this win32-specific behavior is ALREADY part of the stock > gettext, but apparently isn't working to automatically set the default > locale, To the best of my knowledge, it *should* work automatically. I don't see that I would use any patch that would affect this functionality in my build of the libintl DLL. --tml |
From: Erwin W. <wat...@xs...> - 2009-10-28 07:40:02
|
Op 10/27/2009 09:05 PM, Tor Lillqvist schreef: >> However, since this win32-specific behavior is ALREADY part of the stock >> gettext, but apparently isn't working to automatically set the default >> locale, >> > > To the best of my knowledge, it *should* work automatically. I don't > see that I would use any patch that would affect this functionality in > my build of the libintl DLL. > > --tml > Hi, I see that language detection works correctly in libintl version 0.17-1. Charles, your assumption was correct: I meant "in preference to", not "instead of". My complaint is that relocation doesn't work. I have prepared two versions of my program. One build with GnuWin32 libintl (0.14.4), the other with MinGW libintl (0.17-1). See http://www.xs4all.nl/~waterlan/libintl_test/ The GnuWin32 version supports relocation, in the MinGW version it doesn't work (for me). A short readme.txt file is included for explanation. You can test relocation also on an English version of Windows. I like to know if it is a 'problem' of MinGW libintl, or that I do something wrong while building my program. best regards, Erwin Waterlander |
From: Charles W. <cwi...@us...> - 2009-10-27 18:17:13
|
> My test shows that the MinGW gettext tools can produce Dutch messages if > I set LANGUAGE. Right. THEREFORE, the mingw gettext tools (e.g. libintl) are successfully locating the translation files. Unless I missed something, you verified that this works -- when you set LANG -- with the C:\tmp\wcs\ installation. Therefore *relocation works*. Full Stop. > So the Dutch translations are not missing. That I get > English if I don't set LANGUAGE is indeed another problem. Not the > relocate problem. > My program is most used in Windows Console or PowerShell. In these > environments it's not common to define LANG and LC_ variables. So it's not common. Not my problem. If you want stock gettext/libintl to provide translation services, then you must set the variables. Other, patched versions of libintl may bypass this requirement, but stock gettext does not. mingw.org provides stock gettext. Set the variables using the My Computer->Properties->Environment Settings controls, or use a different port of gettext. > What's wrong with Windows specific patches for MinGW ports? Because I do not want to maintain in perpetuity UNNECESSARY patches; I don't have time for that. My purpose in providing a MinGW port of gettext was strictly the following: to enable i18n of the OTHER official packages on mingw.org, under the normal unix usage patterns. If you are able to use the libintl library and headers for other purposes -- great. But that's not why I provided it, and I'm not going to waste time 'expanding my mission'. Look, I'm the one who is encouraging the other mingw and msys developers to stop routinely configuring with --disable-nls. We can support i18n IN THE UNIX FASHION fairly easily, so we should. But this thread is starting to change my mind. It's too damn much hassle. If you want to extend gettext/libintl behavior with windows-specific features, take that up with the upstream maintainer of gettext, Bruno Haible. I am not going to fork gettext. > What's wrong with Tor Lillqvist's patch to read regional settings from > the Windows registry instead of locale environment variables? I'll *assume* that when you say "instead of" you mean "in preference to" -- that is, if I HAVE actually set $LANG then that should take precedence over some registry setting, IMO. IF that understanding of Tor's patch is correct, then nothing is WRONG with it. I just don't want to maintain a fork, no matter where the patch comes from. Take it to Bruno. OTOH, if "instead of" is correct -- that is, if with Tor's port then only the registry settings matter and the environment variables have no effect, then that IS a problem. It would be a deliberate incompatibility with the behavior of the stock -- official -- gettext. > I think this patch was originally made for Gimp. I don't know if this is > included in the original libintl source, It is not. > or that this is patched to the > MinGW port. Be careful of your definitions. When *I* say mingw port, I mean the version provided by mingw.org. You appear to be talking about Tor's version, which may be *compiled* using mingw gcc, but is not "the" mingw port. It is "a" mingw port -- Tor's mingw port -- used and distributed with GIMP. If *he* wants to maintain a fork of gettext in perpetuity that's his choice. Not mine. > According to you is is not part of the original code. Correct. > But it > shows that you don't need to set LANG or LC_ALL to get messages in other > languages. SURE. You can write software to do any thing you want. I could write a patch that requires you to specify the desired language settings in a file called C:\ErwinLanguageFileForMinGWGettext.txt. But that would be stupid. Tor has provided a patch to do *something different than stock gettext*. I don't really care. My mingw.org version of gettext will be as close to *stock* gettext as it can possibly be, and still compile and work properly SO LONG AS you follow the same usage patterns as are required under unix. That is, set the fracking variables. > This proves to me that Tor's patch is in the MinGW port. No, Tor's patch is in Tor's port. There is nothing anywhere in the stock gettext source code that does ANYTHING related to the registry or windows-specific language settings. It uses the variables. Full Stop. > I > can just use LANGUAGE to set a language preference (which only works > after localization has been enabled). Frankly, I'm a little amazed that you keep harping on this. If you set LANG (or LANGUAGE), it will work. But you *must set LANG* -- unless you've patched libintl, like Tor has done, to get the language settings from some other source, such as the registry. I will not patch libintl in this way -- unless stock, upstream, gettext does so. So talk to Bruno. > Back to the relocation problem. It's not working for my package when I > use MinGW libintl. If you want I can send you source code and a binary > package so you can test it yourself. It requires a non-English Windows > to test it properly. There should be no need for non-English windows, to demonstrate the problem or success. Here's the output of mingw 'msgcat -h' on a plain old US English Windows system: $ /mingw/bin/msgcat -h Usage: c:\MinGW\bin\msgcat.exe [OPTION] [INPUTFILE]... Concatenates and merges the specified PO files. Find messages which are common to two or more of the specified PO files. By using the --more-than option, greater commonality may be requested ... $ LANG=de /mingw/bin/msgcat -h Aufruf: c:\MinGW\bin\msgcat.exe [OPTION] [EINGABEDATEI]... PO-Dateien aneinanderfügen und zusammenziehen. Meldungen suchen, die in zwei oder mehr der angegebenen PO-Dateien vorkommen. ... msgcat is linked against the MinGW libintl dll, and uses the DLL's facilities to provide the translation services. Since the DLL and msgcat were compiled using --prefix=/tmp/var/some-random-path, the mere fact that msgcat.exe can find the translation files in C:\MinGW\share\locale\de\LC_MESSAGES\* means that relocation is working. The fact that setting the LANG variable results in a proper translation means that libintl is working AS DESIGNED. You're asking for a different design. You won't get it from me. Use Tor's version, or talk to Bruno. -- Chuck |
From: Charles W. <cwi...@us...> - 2009-10-27 19:23:21
|
Tor Lillqvist wrote: >> So it's not common. Not my problem. If you want stock gettext/libintl >> to provide translation services, then you must set the variables > > Please have a look in stock GNU gettext 0.17 sources. Look at the > function gl_locale_name_default() in > gettext-runtime/intl/localename.c. Look for the # if > defined(WIN32_NATIVE) part. Well, I did grep for registry access functions -- my assumption was that since the Windows Language Settings are stored there, that you would use those functions to get them (e.g. RegOpenKey). However: $ objdump -p /mingw/bin/libintl-8.dll reveals that the mingw.org libintl-8.dll does in fact import the function: 153ce 418 GetThreadLocale and since $ find . -type f | xargs grep GetThreadLocale ./gettext-runtime/intl/localename.c: lcid = GetThreadLocale (); ./gettext-tools/gnulib-lib/localename.c: lcid = GetThreadLocale (); shows that the only place in the libintl source code that accesses that function is in the part of gettext-runtime/intl/localename.c that you reference (the gnulib code is not used by libintl), I can only assume that the code in question is "active" within the mingw.org libintl-8.dll. My apologies for assuming that the win32-specific behavior was not part of the stock gettext. I still, however, have no interest in expanding the behavioral differences between unix and win32 gettext/libintl; I don't want to maintain a fork. However, since this win32-specific behavior is ALREADY part of the stock gettext, but apparently isn't working to automatically set the default locale, I'll accept necessary patches to get the mingw.org version working properly and release a rebuilt version. However, I can't actually track down this issue myself, as I don't have an i18nized version of windows to exercise the behavior (nor can I switch my win32 computer to $LANG!=English for the duration; I use it too much). -- Chuck |
From: Andy K. <and...@gm...> - 2009-10-27 20:06:22
|
2009/10/27 Charles Wilson: > Tor Lillqvist wrote: >>> So it's not common. Not my problem. If you want stock gettext/libintl >>> to provide translation services, then you must set the variables >> >> Please have a look in stock GNU gettext 0.17 sources. Look at the >> function gl_locale_name_default() in >> gettext-runtime/intl/localename.c. Look for the # if >> defined(WIN32_NATIVE) part. > > Well, I did grep for registry access functions -- my assumption was that > since the Windows Language Settings are stored there, that you would use > those functions to get them (e.g. RegOpenKey). However: > > $ objdump -p /mingw/bin/libintl-8.dll > > reveals that the mingw.org libintl-8.dll does in fact import the function: > > 153ce 418 GetThreadLocale > > and since > > $ find . -type f | xargs grep GetThreadLocale > ./gettext-runtime/intl/localename.c: lcid = GetThreadLocale (); > ./gettext-tools/gnulib-lib/localename.c: lcid = GetThreadLocale (); > > shows that the only place in the libintl source code that accesses that > function is in the part of gettext-runtime/intl/localename.c that you > reference (the gnulib code is not used by libintl), I can only assume > that the code in question is "active" within the mingw.org libintl-8.dll. > > My apologies for assuming that the win32-specific behavior was not part > of the stock gettext. I still, however, have no interest in expanding > the behavioral differences between unix and win32 gettext/libintl; I > don't want to maintain a fork. > > However, since this win32-specific behavior is ALREADY part of the stock > gettext, but apparently isn't working to automatically set the default > locale, I'll accept necessary patches to get the mingw.org version > working properly and release a rebuilt version. > > However, I can't actually track down this issue myself, as I don't have > an i18nized version of windows to exercise the behavior (nor can I > switch my win32 computer to $LANG!=English for the duration; I use it > too much). GetThreadLocale() returns the LCID for the locale chosen on the "Formats" tab of the "Region and Language" control panel. Changing it doesn't necessitate a reboot and doesn't affect the Windows UI language. That, however, makes this setting a questionable choice for determining the UI language of applications. The correct API for it is GetUserDefaultUILanguage(). See this blog post by MS's Mr. International, Michael Kaplan: http://blogs.msdn.com/michkap/archive/2005/02/01/364707.aspx Andy |