[GRASS5] [bug #3591] (grass) d.vect.thematic (and other scripts): LC_NUMERIC setting not used in my Debian

[Glynn Clements]

Markus Neteler wrote:

> > > >>this bug's URL: http://intevation.de/rt/webrt?serial_num=3591
> > > >>-------------------------------------------------------------------------
> > > >>
> > > >>Subject: d.vect.thematic (and other scripts): LC_NUMERIC setting not
> > > >>used in my Debian
> > > > 
> > > > 
> > > > GRASS doesn't use any of the locale categories except for LC_MESSAGES
> > > > (if it was built using --with-nls).
> > 
> > Actually, I've just noticed that it also uses LC_CTYPE (again, only if
> > built using --with-nls):
> > 
> > 	revision 1.8
> > 	date: 2004/08/27 11:16:51;  author: markus;  state: Exp;  lines: +1 -0
> > 	added LC_TYPE for japanese
> 
> To what file do you refer?
> 
> Aha:
> 2004-08-27 13:16  markus
> 	* lib/gis/locale.c: added LC_TYPE for japanese

Yep.

> +               setlocale(LC_CTYPE, "");
>                 setlocale(LC_MESSAGES, "");

> > This looks pretty dubious, as it changes the behaviour of many of the
> > <ctype.h> functions (isalpha(), tolower() etc) as well as
> > strcasecmp(), but GRASS' built-in string handling always assumes ASCII
> > (e.g. G_strcasecmp() only considers A-Z/a-z regardless of the locale).
> 
> So, should we remove LC_CTYPE?

I don't know. What was the reason for adding it? I know the commit
message says "for japanese", but which functions need to use the
locale's LC_CTYPE?

The problem with C's locale mechanism is that it's far too coarse. It
was a hack added to deal with the fact that the existing API functions
had US/English conventions hardcoded into them.

Proper localisation requires considering the "audience" for each
individual piece of information. If you're writing something to a file
in a standardised format, it needs to use that format's conventions
regardless of the user's locale. If it's part of the interface text,
it should use the user's locale.

Other cases are less clear; e.g. what conventions (or language) should
be used for history text? The user's locale is a reasonable guess, but
it could well be wrong if their native language isn't the same as the
rest of their team.

> > > mlennert at moritz:~/CVS/GRASS/grass6/scripts$ grep -R LC_NUMERIC *
> > > d.correlate/d.correlate:export LC_NUMERIC=C
> > > d.out.png/d.out.png:export LC_NUMERIC=C
> > > d.resize/d.resize:export LC_NUMERIC=C
> > > d.vect.thematic/d.vect.thematic:export LC_NUMERIC=C
> > > i.fusion.brovey/i.fusion.brovey:export LC_NUMERIC=C
> > 
> > [snip]
> > 
> > > So it is used quite a lot in scripts.
> > 
> > In all cases, it's forced to "C", which is the same as it not being
> > used. Scripts do this to prevent other programs (e.g. awk) from using
> > the user's LC_NUMERIC settings, so that they don't end up passing
> > floating-point values which use a comma to programs which expect a
> > dot.
> 
> I have added it everywhere upon your suggestion:
>  http://grass.itc.it/pipermail/grass5/2005-March/017637.html
> 
> Maybe a misunderstanding. What do do now?

Find out why the setlocale(LC_CTYPE, "") was needed for Japanese. If
it's due to a few specific function calls, we should probably be
doing e.g.:

	setlocale(LC_CTYPE, "");
	do_something(...);
	setlocale(LC_CTYPE, "C");

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