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 <gl...@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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
