Greetings MarkusIt worked 
Thank you
I’m getting an error, that before I was getting:
GRASS 6.4.0svn (North-Carolina):~ >
(process:4282): Gdk-WARNING **: locale not supported by C library
(process:4282): Gtk-WARNING **: Locale not supported by C library.
Using the fallback ‘C’ locale.
But it works at least for wxpython translations. Grassmods no.
Regarding .UTF-8 and without .UTF-8, it was the same. I thought that this error had something to do wuth UTF-8 but no.
Ok thanks
Best regards
Gilbert
On Wed, Feb 3, 2010 at 3:37 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi Gilbert,
On Wed, Feb 3, 2010 at 3:39 PM, Gilbert Ferrara
<gilbertferrara1974@gmail.com> wrote:
Hello Markus
You suggestion is to maintain grass64 file and create those two right?
Yes, I would not touch the original grass64 file.
At the end of each one of them it calls grass64 by grass64 “$@” right?
Right. With “$@” you can pass parameters to the original start script.
But if I was running grass64 -wxpython, if I run grass64eng -wxpython, the
“-wxpython” is still parsed?
Yes, because of the “$@” parameter.
Did you try?
es_ES.UTF-8 ? How can I know if this is applicable?
Try and error… Either without or with .UTF-8, depends on the distribution
you use.
Thank you
When I tried, I will reply to the grass mailing list
Perfect.
cheers
Markus
Thank you merci
Gilbert
On Wed, Feb 3, 2010 at 2:31 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Wed, Feb 3, 2010 at 1:35 PM, Gilbert Ferrara
<gilbertferrara1974@gmail.com> wrote:
I just want to provide GRASS64 in two languages and without the user has
to
define lang in the bash_profiles.
My idea was to create 2 files: grass64eng and grass64sp each one with
different language sets. So the user would have only to select the
adequate
file.
I would create
grass64eng
export LANG=en_US
export LANGUAGE=en_US
export LC_MESSAGES=en_US
grass64 “$@”
grass64sp
export LANG=es_ES
export LANGUAGE=es_ES
export LC_MESSAGES=es_ES
grass64 “$@”
(or, if applies es_ES.UTF-8 instead of es_ES).
Hope this helps,
Markus
On Wed, Feb 3, 2010 at 5:20 PM, Gilbert Ferrara
<gilbertferrara1974@gmail.com> wrote:
Greetings Markus
It worked
Excellent!
Thank you
I'm getting an error, that before I was getting:
GRASS 6.4.0svn (North-Carolina):~ >
(process:4282): Gdk-WARNING **: locale not supported by C library
(process:4282): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
But it works at least for wxpython translations. Grassmods no.
Regarding .UTF-8 and without .UTF-8, it was the same. I thought that this
error had something to do wuth UTF-8 but no.
The problem will be the mixture of encodings:
grasslibs_es.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
grassmods_es.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
grasstcl_es.po:"Content-Type: text/plain; charset=UTF-8\n"
grasswxpy_es.po:"Content-Type: text/plain; charset=UTF-8\n"
@dev: To which encoding should we consolidate this mix?
Markus
Markus Neteler wrote:
> I'm getting an error, that before I was getting:
> GRASS 6.4.0svn (North-Carolina):~ >
> (process:4282): Gdk-WARNING **: locale not supported by C library
> (process:4282): Gtk-WARNING **: Locale not supported by C library.
> Using the fallback 'C' locale.
> But it works at least for wxpython translations. Grassmods no.
> Regarding .UTF-8 and without .UTF-8, it was the same. I thought that this
> error had something to do wuth UTF-8 but no.
The problem will be the mixture of encodings:
No it won't. GNU msgfmt always uses UTF-8 in the .mo files, and
converts to the locale's encoding automatically (so that you don't
need separate .mo files for e.g. LANG=es and LANG=es.UTF-8).
grasslibs_es.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
grassmods_es.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
grasstcl_es.po:"Content-Type: text/plain; charset=UTF-8\n"
grasswxpy_es.po:"Content-Type: text/plain; charset=UTF-8\n"
@dev: To which encoding should we consolidate this mix?
ISO-8859-1.
This doesn't have any effect upon the resulting .mo file, but it
ensures that the files don't contain any characters outside of the
Latin-1 repertoire. This may be significant as we get more Windows
users, as Microsoft tries quite hard to ensure that data gets infected
with Windows-specific extensions.
It also ensures that the file remains editable on as many systems as
possible. Supporting arbitrary unibyte encodings is almost as
straightforward as supporting ASCII; supporting multi-byte encodings
or wide characters is somewhat harder (more work and more platform
dependencies).
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Feb 3, 2010 at 11:02 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
> I'm getting an error, that before I was getting:
> GRASS 6.4.0svn (North-Carolina):~ >
> (process:4282): Gdk-WARNING **: locale not supported by C library
> (process:4282): Gtk-WARNING **: Locale not supported by C library.
> Using the fallback 'C' locale.
> But it works at least for wxpython translations. Grassmods no.
> Regarding .UTF-8 and without .UTF-8, it was the same. I thought that this
> error had something to do wuth UTF-8 but no.
The problem will be the mixture of encodings:
No it won't. GNU msgfmt always uses UTF-8 in the .mo files, and
converts to the locale's encoding automatically (so that you don't
need separate .mo files for e.g. LANG=es and LANG=es.UTF-8).
Ah, right, you explained it already.
grasslibs_es.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
grassmods_es.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
grasstcl_es.po:"Content-Type: text/plain; charset=UTF-8\n"
grasswxpy_es.po:"Content-Type: text/plain; charset=UTF-8\n"
@dev: To which encoding should we consolidate this mix?
ISO-8859-1.
Done so in 6.4, 6.5 and 7.
Markus