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

[Michael Barton]

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.

There are a couple aspects to this. The most obvious aspect from the user point of view is whether or not the GUI is in their language or not. With the current setup, changing the language in the GUI preferences has no impact on the language of the menus, dialogs, etc--at least on my Mac. Looking at the code, I can't see that changing the GUI language setting does anything beyond setting the gisenv LANG variable. If this is not coded into GRASS to have any impact, there is no point in having it. Helmut reports a changed language in the interface on Windows, but I don't know yet what he did to change the language--in GUI preferences or at the system level. 

Inserting...

import locale
locale.setlocale(locale.LC_ALL, locale="es_ES.UTF-8")
locale.setlocale(locale.LC_CTYPE, locale="es_ES.UTF-8")
locale.setlocale(locale.LC_MESSAGES, locale="es_ES.UTF-8")

...at the GUI startup also has no effect; my menus and dialogs are still in English. 

I can play with other kinds of settings combinations, but sort of need some guidance of what should be set and where to have any impact on this. 


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

I have not explicitly built with --with-nls. Is this required for GRASS to use different language settings (i.e., po.* files)? In the past, GRASS menus and dialogs would simply show up in whatever language the computer was set to. I like the idea of being able to explicitly set the language, but it is not working on the Mac. Since my builds get used by people in other countries, I'd like to find a way to fix this.

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

So how is Helmut getting different languages in his GUI on Windows???

Michael

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