[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
confused with locale names...
From: |
Andre Charbonneau |
Subject: |
confused with locale names... |
Date: |
Wed, 24 Apr 2002 14:07:20 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 |
Greetings,
I'm confused with the way locale names are handled on my linux system
and maybe someone can help me clarify things a bit.
For example, if I use localedef to create a new locale using the
following command:
localedef -f ISO-8859-15 -i en_CA --force en_CA.ISO-8859-15
the locale directory created is:
/usr/lib/locale/en_CA.iso885915
But if I want the new locale to be located in my home directory, I use
the following command:
localedef -f ISO-8859-15 -i en_CA --force ~/en_CA.ISO-8859-15
and the following directory is created:
~/en_CA.ISO-8859-15
Note how localedef is doing some kind of normalization on the output
directory name. If I set my system to use the newly created system-wide
locale using the following environment I get no problems.
export LANG=en_CA.iso885915
export LC_ALL=en_CA.iso885915
But if I tell the system to use the user-wide locale using the following
environement setup, X applications give error messages saying that the
locale is not supported.
export LOCPATH=$HOME
export LANG=en_CA.ISO-8859-15
export LC_ALL=en_CA.ISO-8859-15
First I thought that the problem was with X not recognizing the
ISO-8859-15 charset name, so I renamed the user-level locale to
en_CA.iso885915, changed the environment appropriately but I still get
the X error messages.
So now I'm very confused, because it seems to work with system wide
locales (even though en_CA.iso885915 does not appear in X's locale.alias
and locale.dir files) but does not work for user-wide locales with the
LOCPATH env variable set.
Now, if I simply compile the new locale and do not explicitely specify
the character set in the locale name, like the following:
localedef -f ISO-8859-15 -i en_CA --force ~/en_CA
export LOCPATH=$HOME
export LANG=en_CA
export LC_ALL=en_CA
X does not complain anymore. But is it because X is still using the
ISO-8859-1 en_CA locale behind the scenes???
I would really like some clarifications on what is happening and what
can be done about it.
My second question is the following:
Is the charset part of a locale name used by applications in any way or
is it only used to differentiate it from other locales compiled with
different charset? For example, in the last scenario, the en_CA locale
under my home directory was created using the ISO-8859-15 character set,
but the locale name is simply en_CA (instead of en_CA.ISO-8859-15).
Will this cause any problems on my system, or is the charset determined
by applications at run-time from the actual content of the locale
instead of by its name? In other words, when you compile a locale with
a character set that is not the default charset for that locale, do you
HAVE to specify the charset in the locale name for the system to be
properly localized?
Any feedback will be greatly appreciated.
Thanks a lot,
Andre.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- confused with locale names...,
Andre Charbonneau <=