gettext/libintl 0.17-1 not relocatable.

[Erwin Waterlander-2]

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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Charles Wilson-8]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Charles Wilson-8]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Charles Wilson-8]

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-gnu-gettext@... (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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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-gnu-gettext@... (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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Charles Wilson-8]

> 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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Tor Lillqvist]

> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Charles Wilson-8]

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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Tor Lillqvist]

> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Andy Koppe]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[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*. 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Andy Koppe]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Charles Wilson-8]

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


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Erwin Waterlander-2]

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



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users