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

GRASS GIS GRASS GIS developer
1

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.

The goal of adding a language preference in the GUI was to allow the user to set GRASS whatever language is desired. This gets set into the .grass6/wx and .grassrc6 files (and I assume .grass7/wx and .grass7/rc files too) in the GRASS LANG variable (named the same but distinct from the system LANG variable). However, the GUI then ignores this language setting by using Python’s locale.getdefaultlocale() instead of reading g.gisenv LANG.

So we need to change all places that use locale.getdefaultlocale() to read the GRASS language setting with code that reads

enc = None
try:
lang = grass.gisenv().get(‘LANG’, None)
if lang:
enc = lang.split(‘.’)[1]
except:
pass

This appears to fix all problems related to oddly set system locale variables by using the new GRASS LANG variable that is set via the GUI preferences, via g.gisenv, or manually in the .grassrc6 or .grass7/rc file.

I can do that when I’m back on my Mac set up for compiling and svn updating in a couple days unless anyone wants to do it sooner. This needs to be changed in multiple places, including gcmd.py, forms.py, task.py, utilties.py, and ghelp.py (where the code associated with locale.getdefaultlocale() just needs to be remmed out I think). It probably needs to be backported across all versions.

This Python form is also used in settings._generateLocale(), where the error raised by locale.getdefaultlocale() returns ‘C’. I suppose this attempts to set a system locale setting somewhere, but I don’t know where yet. My suggestion is that we not be doing this but go with the GRASS local setting to avoid problems in system default locale settings–as seems to be the intent of the new language preference.

Finally, I noticed in tracing this out that EncodeString and DecodeString are repeated in task.py and utility.py. The utility.py version can probably be deleted and replaced with the task.py version.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

2

A quick followup.

locale.getdefaultlocale() also needs to be changed in goutput.py. It’s use in settings.py can probably stay as it is, since even with an error, it just puts “C” into the preferences key for locale until someone decides to change it.

Michael

On Jul 29, 2012, at 1:23 PM, 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.

The goal of adding a language preference in the GUI was to allow the user to set GRASS whatever language is desired. This gets set into the .grass6/wx and .grassrc6 files (and I assume .grass7/wx and .grass7/rc files too) in the GRASS LANG variable (named the same but distinct from the system LANG variable). However, the GUI then ignores this language setting by using Python’s locale.getdefaultlocale() instead of reading g.gisenv LANG.

So we need to change all places that use locale.getdefaultlocale() to read the GRASS language setting with code that reads

enc = None
try:
lang = grass.gisenv().get(‘LANG’, None)
if lang:
enc = lang.split(‘.’)[1]
except:
pass

This appears to fix all problems related to oddly set system locale variables by using the new GRASS LANG variable that is set via the GUI preferences, via g.gisenv, or manually in the .grassrc6 or .grass7/rc file.

I can do that when I’m back on my Mac set up for compiling and svn updating in a couple days unless anyone wants to do it sooner. This needs to be changed in multiple places, including gcmd.py, forms.py, task.py, utilties.py, and ghelp.py (where the code associated with locale.getdefaultlocale() just needs to be remmed out I think). It probably needs to be backported across all versions.

This Python form is also used in settings._generateLocale(), where the error raised by locale.getdefaultlocale() returns ‘C’. I suppose this attempts to set a system locale setting somewhere, but I don’t know where yet. My suggestion is that we not be doing this but go with the GRASS local setting to avoid problems in system default locale settings–as seems to be the intent of the new language preference.

Finally, I noticed in tracing this out that EncodeString and DecodeString are repeated in task.py and utility.py. The utility.py version can probably be deleted and replaced with the task.py version.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

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

3

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 <glynn@gclements.plus.com>

4

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 <glynn@gclements.plus.com>

5

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

tested here with a osgeo4w-wingrass7 in win7-64bit(german).

switching gui-languages (C,fr,es,it,de,jp,...) and starting gui are working.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/locale-problem-solved-but-have-suggestion-tp4991699p4991957.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

6

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@gclements.plus.com>

7

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

8

On Wed, Aug 1, 2012 at 6:08 AM, Michael Barton <Michael.Barton@asu.edu> wrote:
...

I have not explicitly built with --with-nls. Is this required for GRASS to use
different language settings (i.e., po.* files)?

To my knowledge yes.

In the past, GRASS menus and dialogs would simply show up in whatever
language the computer was set to.

Not sure about this - how should that work?

--with-nls is needed. Perhaps we can add some check into the language selection
code to pop up a message in case the GRASS installation comes without --with-nls
support?

Markus

9

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

10

On Wed, Aug 1, 2012 at 7:35 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

FWIW, I've so far tried hard coding language settings in various ways to test, including:

...

Is NLS enabled in that compilation?

Markus

11

Hello,
there are numerous issues with current approach, including ability to
changing locale to non-working one (hey, Python, it's 2012 and UTF-8
locales are common!).

Please test following patch on Mac and Windows GRASS versions:
copy attached file to grass-trunk source code;
apply it with 'patch -p0 < change_GUI_language.patch'

Changes:
Provide only available languages as a choice (we don't have GRASS
Esperanto version (yet));
Store only language code in preferences, as encoding guess might be wrong;
Fall back to language.UTF-8, if Python's locale guess is wrong;
Fall back to C, if all attempts to change LC_MESSAGE have been
unsuccessful (i.e. locale not available).

If it works for You (Michael, I especially looking at You now), I'll commit it.
Tested on Gentoo Linux with lv_LV.UTF-8 and pl_PL locales. Setting
unsupported locale (i.e. ru) causes fail back to C.

Maris.

2012/8/1 Markus Neteler <neteler@osgeo.org>:

On Wed, Aug 1, 2012 at 7:35 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

FWIW, I've so far tried hard coding language settings in various ways to test, including:

...

Is NLS enabled in that compilation?

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

(attachments)

change_GUI_language.patch (3.28 KB)

12

Michael Barton wrote:

I have not explicitly built with --with-nls. Is this required for
GRASS to use different language settings (i.e., po.* files)?

For C modules and libraries, yes. Python code will probably ignore the
--with-nls setting.

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

13

I've never compiled --with-nls prior to this. However, at least a few years back, GRASS that I compiled came up in Spanish on my colleague's machines--either because the with-nls flag dates to a few years back or because it worked in spite of not compiling with-nls. No one told me when this stopped working and my builds were only in English, so I'm in the dark on that.

I just tried to compile with-nls, but got this config error

checking whether to use NLS... yes
checking for gettext... no
checking for gettext in -lintl... no
configure: error: *** Unable to locate gettext() function.

I KNOW that I have python gettext. So how do I specify it? Or is this a non-Python gettext that I must install separately?

Michael

On Aug 1, 2012, at 8:44 AM, Glynn Clements wrote:

Michael Barton wrote:

I have not explicitly built with --with-nls. Is this required for
GRASS to use different language settings (i.e., po.* files)?

For C modules and libraries, yes. Python code will probably ignore the
--with-nls setting.

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

_____________________
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Corporation 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

14

It's in the libintl library, not Python gettext. Another dependency to worry about on OS X. I'll dig up my notes later this evening for you.

On Aug 1, 2012, at 12:15 PM, Michael Barton wrote:

I've never compiled --with-nls prior to this. However, at least a few years back, GRASS that I compiled came up in Spanish on my colleague's machines--either because the with-nls flag dates to a few years back or because it worked in spite of not compiling with-nls. No one told me when this stopped working and my builds were only in English, so I'm in the dark on that.

I just tried to compile with-nls, but got this config error

checking whether to use NLS... yes
checking for gettext... no
checking for gettext in -lintl... no
configure: error: *** Unable to locate gettext() function.

I KNOW that I have python gettext. So how do I specify it? Or is this a non-Python gettext that I must install separately?

Michael

On Aug 1, 2012, at 8:44 AM, Glynn Clements wrote:

Michael Barton wrote:

I have not explicitly built with --with-nls. Is this required for
GRASS to use different language settings (i.e., po.* files)?

For C modules and libraries, yes. Python code will probably ignore the
--with-nls setting.

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

_____________________
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Corporation 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

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

15

Michael Barton wrote:

I've never compiled --with-nls prior to this. However, at least a few
years back, GRASS that I compiled came up in Spanish on my colleague's
machines--either because the with-nls flag dates to a few years back
or because it worked in spite of not compiling with-nls. No one told
me when this stopped working and my builds were only in English, so
I'm in the dark on that.

I just tried to compile with-nls, but got this config error

checking whether to use NLS... yes
checking for gettext... no
checking for gettext in -lintl... no
configure: error: *** Unable to locate gettext() function.

I KNOW that I have python gettext. So how do I specify it? Or is this
a non-Python gettext that I must install separately?

This has nothing to do with Python. This is the gettext() function
used by lib/gis/locale.c to translate messages[1]. On Linux, it's part
of libc; on other platforms, it's usually in libintl.

[1] It's actually dgettext() which is used, as that allows us to have
separate grasslibs and grassmods catalogues.

If you build without NLS support, the _(...) macro simply evaluates to
its argument, so messages within C code won't be translated.

Python has its own gettext package, which is always used.

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

16

Patch has been commited to trunk to get wider testing.

Fail reports welcome,
Maris.

2012/8/1 Maris Nartiss <maris.gis@gmail.com>:

Hello,
there are numerous issues with current approach, including ability to
changing locale to non-working one (hey, Python, it's 2012 and UTF-8
locales are common!).

Please test following patch on Mac and Windows GRASS versions:
copy attached file to grass-trunk source code;
apply it with 'patch -p0 < change_GUI_language.patch'

Changes:
Provide only available languages as a choice (we don't have GRASS
Esperanto version (yet));
Store only language code in preferences, as encoding guess might be wrong;
Fall back to language.UTF-8, if Python's locale guess is wrong;
Fall back to C, if all attempts to change LC_MESSAGE have been
unsuccessful (i.e. locale not available).

If it works for You (Michael, I especially looking at You now), I'll commit it.
Tested on Gentoo Linux with lv_LV.UTF-8 and pl_PL locales. Setting
unsupported locale (i.e. ru) causes fail back to C.

Maris.

2012/8/1 Markus Neteler <neteler@osgeo.org>:

On Wed, Aug 1, 2012 at 7:35 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

FWIW, I've so far tried hard coding language settings in various ways to test, including:

...

Is NLS enabled in that compilation?

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

17

OK Maris. Thanks. However, I want to test GRASS with just --with-nls before I try the patch. Then I'll try that. Did you see Glynn's posts about setting locale on posix and windows systems?

Michael

On Aug 3, 2012, at 10:18 PM, Maris Nartiss wrote:

Patch has been commited to trunk to get wider testing.

Fail reports welcome,
Maris.

2012/8/1 Maris Nartiss <maris.gis@gmail.com>:

Hello,
there are numerous issues with current approach, including ability to
changing locale to non-working one (hey, Python, it's 2012 and UTF-8
locales are common!).

Please test following patch on Mac and Windows GRASS versions:
copy attached file to grass-trunk source code;
apply it with 'patch -p0 < change_GUI_language.patch'

Changes:
Provide only available languages as a choice (we don't have GRASS
Esperanto version (yet));
Store only language code in preferences, as encoding guess might be wrong;
Fall back to language.UTF-8, if Python's locale guess is wrong;
Fall back to C, if all attempts to change LC_MESSAGE have been
unsuccessful (i.e. locale not available).

If it works for You (Michael, I especially looking at You now), I'll commit it.
Tested on Gentoo Linux with lv_LV.UTF-8 and pl_PL locales. Setting
unsupported locale (i.e. ru) causes fail back to C.

Maris.

2012/8/1 Markus Neteler <neteler@osgeo.org>:

On Wed, Aug 1, 2012 at 7:35 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

FWIW, I've so far tried hard coding language settings in various ways to test, including:

...

Is NLS enabled in that compilation?

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

_____________________
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

18

If this approach works, changes will be needed in several other wxpython modules that use getdefaultlocale() to set encoding.

Michael

On Aug 1, 2012, at 7:04 AM, Maris Nartiss wrote:

Hello,
there are numerous issues with current approach, including ability to
changing locale to non-working one (hey, Python, it's 2012 and UTF-8
locales are common!).

Please test following patch on Mac and Windows GRASS versions:
copy attached file to grass-trunk source code;
apply it with 'patch -p0 < change_GUI_language.patch'

Changes:
Provide only available languages as a choice (we don't have GRASS
Esperanto version (yet));
Store only language code in preferences, as encoding guess might be wrong;
Fall back to language.UTF-8, if Python's locale guess is wrong;
Fall back to C, if all attempts to change LC_MESSAGE have been
unsuccessful (i.e. locale not available).

If it works for You (Michael, I especially looking at You now), I'll commit it.
Tested on Gentoo Linux with lv_LV.UTF-8 and pl_PL locales. Setting
unsupported locale (i.e. ru) causes fail back to C.

Maris.

2012/8/1 Markus Neteler <neteler@osgeo.org>:

On Wed, Aug 1, 2012 at 7:35 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

FWIW, I've so far tried hard coding language settings in various ways to test, including:

...

Is NLS enabled in that compilation?

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

<change_GUI_language.patch>

_____________________
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

19

On Sat, Aug 4, 2012 at 7:18 AM, Maris Nartiss <maris.gis@gmail.com> wrote:

Patch has been commited to trunk to get wider testing.

Fail reports welcome,

Here we go :slight_smile:

After make distclean, when compiling without NLS support, I cannot start
the GUI any more:

GRASS 7.0.svn (patUTM32):/raw_data/lidar_raw/las13_format/toposys_optech2007

Traceback (most recent call last):

  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/main.py",
line 34, in <module>
    from core.render import Map
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py",
line 38, in <module>
    from core.settings import UserSettings
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 1123, in <module>
    UserSettings = Settings()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 42, in __init__
    self._defaultSettings() # -> self.defaultSettings
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 74, in _defaultSettings
    id_loc = self._generateLocale()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 59, in _generateLocale
    self.locs = os.listdir(os.path.join(os.environ['GISBASE'], 'locale'))
OSError: [Errno 2] No such file or directory: '/usr/local/grass-7.0.svn/locale'

Markus

20

Sorry!
At one point I was thinking about adding necessary code, still I
forgot about it. Fixed in r52582.

Maris.

2012/8/7 Markus Neteler <neteler@osgeo.org>:

On Sat, Aug 4, 2012 at 7:18 AM, Maris Nartiss <maris.gis@gmail.com> wrote:

Patch has been commited to trunk to get wider testing.

Fail reports welcome,

Here we go :slight_smile:

After make distclean, when compiling without NLS support, I cannot start
the GUI any more:

GRASS 7.0.svn (patUTM32):/raw_data/lidar_raw/las13_format/toposys_optech2007

Traceback (most recent call last):

  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/main.py",
line 34, in <module>
    from core.render import Map
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py",
line 38, in <module>
    from core.settings import UserSettings
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 1123, in <module>
    UserSettings = Settings()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 42, in __init__
    self._defaultSettings() # -> self.defaultSettings
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 74, in _defaultSettings
    id_loc = self._generateLocale()
  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/settings.py",
line 59, in _generateLocale
    self.locs = os.listdir(os.path.join(os.environ['GISBASE'], 'locale'))
OSError: [Errno 2] No such file or directory: '/usr/local/grass-7.0.svn/locale'

Markus