Thanks for the input Glynn, This makes me wonder about the new approach to better setting locale/language for GRASS.
AFAICT, the idea is to set a GRASS variable - LANG - and then read that to set the language and encoding. However, as I indicated, once that is set, it seems to be largely ignored. I can't see anywhere that the GUI then sets any system language/locale variable--only in the wx file (GUI config) and the GRASS LANG variable in the rc file. There IS code to set the translation based on this information. I assumed that this would work, but haven't tested it because I've been focusing on finding the bugs that caused the GUI to crash and malfunction. 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)? 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. What do you think? Does Windows use these variables or a different set? Michael ______________________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jul 30, 2012, at 4:01 AM, Glynn Clements wrote: > > Michael Barton wrote: > >> After a lot of digging I finally traced the source of the locale >> problem that disables the menus and a related problem that throws a >> lot of errors about unknown locale into the terminal. >> >> The serious error is in python/grass/scripts/task.py line 460, and can >> be fixed with an error trap as follows: >> >> try: >> enc = locale.getdefaultlocale()[1] >> except: >> enc = None >> >> >> The more general problem, however, is the use of Python's >> locale.getdefaultlocale() in several places. This uses system locale >> variables, starting with LC_CTYPE. If one of these is unrecognizable >> by Python for some reason, it throws an error which may just put an >> error message in the terminal or could cause more serious problems >> like the one's I've been encountering on non-English systems. This >> apparently has happened variously on Mac's at least. > > It's not Python which reads the environment variables; it's libc, > specifically setlocale(). > > If the environment variables are invalid, it will affect any library > functions which Python uses, along with any child processes spawned > from Python. > > E.g. any localised text generated by GRASS modules will use the > encoding specified by the LC_CYTPE category, which is set from the > environment. > > If you want to control the locale from the GUI, or from configuration > files, you have to set the environment variables correctly for any > child processes. However, setting the environment variables won't > affect Python's locale unless you call locale.setlocale() again. At > which point, locale.getlocale() should return the correct value. > > -- > Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
