Li Tue, Feb 19, 2008 at 03:30:23PM -0800, Bill Kendrick scrijha:
> arrays, based on the "LANG_xx" enums defined in i18n.h). Despite using
> "putenv()" to set the LC_ALL and LANG variables, setlocale() seems to think
> I'm in "en_US.UTF-8".
if LANGUAGE is defined, it has priority over the others.
For translations, gettext uses, in that order, the following sources of
information to determine the locale:
only LANGUAGE allows to define a list of locales (colon separated), the other
variables only define a single locale.
> The "setlocale(LC_ALL, "");" found at the end of i18n.c's setup_language()
> _should_ set all of our locale LC_'s to the one we requested via
> "putenv("LC_ALL=...")" (in that same function), right?
the setlocale(LC_ALL, ""); call will also make gettext read the LANGUAGE
So, check if LANGUAGE isn't defined to "en_US.UTF-8" that would explain
the behaviour you see.
> tuxpaint --lang khmer
> I'll try it by setting by LANG env. variable, instead and see if that helps.
Note also that if you don't have a khmer locale (km_KH.UTF-8 IIRC) then
the result of using an unexisting locale would be problematic...
You can check if you have it with: LC_ALL=km_KH.UTF-8 locale charmap
if it replies UTF-8, it's good, if it replies POSIX or ANSI something,
it's you don't have it.
If you do have it, you can test with:
LC_ALL=km_KH.UTF-8 LANGUAGE=km tuxpaint
If you don't have it, you can test with:
LC_ALL=en_US.UTF-8 LANGUAGE=km tuxpaint
(it could be another than en_US, but it must be an existing UTF-8 one,
as khmer couldn't be properly rendered in non-unicode locales)
in that last exemple you can see that the language of the translations
can be unrelated to the locale (it just requires that the locale
uses a character set covering the language; but there are also, and
maybe tuxpaint is among them, a lot of programs that just use UTF-8
internally, regardless of the locale encoding; in such cases it will always
The various locale variables (LC_* or the LC_ALL takign priority over them
all) are used to define things like the character set, the paper size,
the alphabetic sorting order, the format for numbers, the monetary symbol, etc
but for selecting the language used for the user interface (or the languages,
in plural) the LANGUAGE variable is preferred.
It has the advantages of being independent of the locale (so, allowing to
be able to display translations in languages that haven't yet a locale defined)
and being able to give an *ordered list* of preferred languages, so the
program would display the best matching language.
For example, the common setting for a Walloon environnement would
be LANGUAGE=wa:fr so that if a translation is not available in Walloon,
it would be tried to show it in French befor English, as almost all
Walloon speakers also understand French.
Ki ça vos våye bén,
http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466