[GRASS-dev] locale problem solved - but have suggestion

[Glynn Clements]

Michael Barton wrote:

> Are you suggesting that using only a language setting internal to
> GRASS, without setting the system locale variables will not allow
> GRASS to switch to the appropriate language (or maybe switch for
> some things but not for others)?

On Unix, child processes spawned from the GUI will get their locale
settings from the environment variables. The GUI cannot affect their
localisation other than through the environment variables.

The environment variables are only relevant if setlocale() is called
with an empty string as the locale. If setlocale() isn't called, the
"C" locale is used. If setlocale() is called with some other string as
the locale, that specific locale is used.

> If so, perhaps we should take a different tack of setting LC_CTYPE
> and LANG (system variable) from GRASS LANG, and setting LC_ALL to
> "C" on startup. Then we could keep the Python calls as they are now. 
> I assume that this would only affect these system variables for the
> GRASS session.

GRASS modules use the LC_CTYPE and (if built --with-nls) LC_MESSAGES
categories. The former affects the encoding used for messages, and the
behaviour of the <ctype.h> functions (isXXX(), toupper(), tolower(),
etc). The latter affects the choice of message catalogues used for
localised messages.

Other programs may use other categories, but LC_NUMERIC is problematic
because it causes e.g. printf("%f") to use the locale's decimal
separator, which can result in invalid output (most standardised
textual file formats use a dot as the decimal separator, while many
locales use a comma).

> What do you think? Does Windows use these variables or a different
> set?

MSVCRT uses the user's "region" settings (set via the control panel)
if setlocale() is called with an empty string as the locale argument. 
It doesn't use the POSIX environment variables (LANG, LC_*).

There isn't a simple way to run a specific process with a different
locale (there's the AppLocale program, but it isn't officially
supported on recent versions of Windows, and I have no idea how it
works).

Also, Windows doesn't really deal with encodings. Anything which uses
"char*" (including practically the entire standard C library) is
considered "legacy". Internationalised programs are supposed to
essentially abandon "char" and use wchar_t for everything.

-- 
Glynn Clements <glynn at gclements.plus.com>