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

[Michael Barton]

FWIW, I've so far tried hard coding language settings in various ways to test, including: 
1) setting system language variables in my .profile; 
2) adding locale.setlocale(locale.LC_ALL, locale="es_ES.UTF-8") statements for all system variable equivalents in wxgui.py at startup; 
3) setting self.locale = wx.Locale(language = wx.LANGUAGE_SPANISH) in wxgui.py; 
4) as well as setting the GUI preferences to spanish. 

Nothing changes my interface. It stays English. 

Michael

On Jul 31, 2012, at 11:52 AM, Glynn Clements wrote:

> 
> 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>

_____________________
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu