Re: [Mingw-users] How to enable national language support (NLS)and install lanugage packge?
- Date: Tue, 10 May 2016 11:44:47 +0100
- From: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-users] How to enable national language support (NLS)and install lanugage packge?
-----BEGIN PGP SIGNED MESSAGE-----
On 10/05/16 08:19, waterlan wrote:
> Eli Zaretskii schreef op 2016-05-09 20:59:
>>> From: Erwin Waterlander It doesn't always work out-of-the-box.
>>> Sometimes you need to help by setting these variables:
>>> set LANG=zh_CN set LANGUAGE=zh_CN
>> Does GCC indeed cater to these variables?
Yes. GCC uses GNU's textdomain, (from GNU gettext, via libintl). The
Windows builds may also attempt to honour Microsoft's locales, but any
of these, (or LC_* environment variable settings), should override.
It may be worth noting that, depending on your installation, you may
need to specify full (absolute) localization path names, (to whatever
directory contains the message catalogues), as explained here:
Also note follow-up comments to that, and that my experience was not
always consistent, w.r.t. behaviour of different environment
variables; in particular, setting LC_MESSAGES or LANGUAGE gave more
consistently reliable results than LC_ALL or LANG; (I don't know why).
> This is my experience in general with applications linked to
> libintl on Windows. The behaviour can differ with libintl version
> or Windows version (Win7/8 32/64 bit). Libintl is not always able
> to pick up the locale from the Windows system locale setting. I
> read somewhere that gcc has its private copy of libintl included.
I don't know where you read it, but yes, you are quite correct: the
GCC sources do indeed include (at least a subset of) the GNU libintl
code. What's more, the GCC build process seems to favour static
linking with this embedded code, over dynamic linking with any
pre-existing libintl DLL which may be installed. All of the GCC
builds, which I've posted recently, have statically linked libintl
code; I've not been able to circumvent that, (which suggests that
mingw-get's declared dependency on libintl-8.dll may, in fact, be bogus):
$ objdump -x /mingw/bin/gcc.exe | grep DLL
DLL Name: ADVAPI32.DLL
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll
DLL Name: USER32.dll
DLL Name: libiconv-2.dll
> I don't know any specific information about that. I assumed it
> would work the same as standard libintl.
Likewise, I don't know for certain, but I believe it does; the source
code does bear significant similarity to (parts of) GNU gettext.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: