|
From: Eli Z. <el...@gn...> - 2016-05-10 16:18:26
|
> From: Keith Marshall <kei...@us...> > Date: Tue, 10 May 2016 11:44:47 +0100 > > >>> 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. Thanks for the info. > 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: > https://sourceforge.net/p/mingw/bugs/2108/?limit=25&page=2#482e Having to set LANGUAGE or LC_MESSAGES to an absolute file name is weird. I guess it only works because Windows doesn't support LC_MESSAGES natively, so the value never gets to setlocale. > 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). Not sure whether this is relevant (I didn't look at the code which implements this stuff in GCC and/or libintl), but there's a subtle asymmetry in how msvcrt's setlocale treats the different categories. Specifically, only LC_ALL may specify the codeset (a.k.a. "codepage") part of the value; if any other category specifies a codeset, Windows will not change the codepage. The URL above doesn't show any examples of changing a codepage, so I'm not sure this is relevant. |