bug-glibc
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]