Re: The glibc-2.2 locale name problem
: The alias in /usr/share/locale/locale.alias should not be necessary, instead
: you need a similar line in /usr/lib/X11/locale/locale.alias.
:
: I could not reproduce this problem on my system (RH7, I apologize for mentioning
: this name in this list :), with home made XFree4.0.1 and glibc2.1.95). However
: I highly suspect that it's just a mess-up of locale names in X. From old days,
: zh_TW means zh_TW.eucTW in X world. Only in XFree4, some one realized (finally!)
: that big5 is the more common encoding used and changed the locale alias. The
: change is reflected in /usr/lib/X11/locale/locale.alias file as follows:
: old ---> zh_TW zh_TW.eucTW
: new ---> zh_TW zh_TW.big5
: So you might want to check if you still have the old alias.
Thank you very much. After making the change in
/usr/X11R6/lib/X11/locale/locale.alias
the Xi18n program can run with the /usr/lib/locale/zh_TW locale.
: As for the proper locale name, I believe we can do fine without a whole
: lot of changes. The following are my suggestions.
:
: 1. The C locales are fine, no change needed.
: 2. The X lcoales: need to add the above mentioned change. This is only
: needed for 3.3.x systems and as XFree4 eventually take over, this
: will be the default out of box.
Excuse me, I don't think so. :-)) Here is my opinion.
Although it does not make any difference to use the "zh_TW" or
"zh_TW.Big5" locale name in the point of view of the programmer,
but we still have to take the end users into consideration.
In Taiwan, we have used "zh_TW.Big5" locale name for over one or
two years. We have asked our programmers to use this locale name
if they want to write I18N program, or join the developemnt of
other I18N project (like kde, gtk, gnome, or even mozilla ....).
Even in Debian/potato, Mandrack, and Linux distributions developed
in Taiwan like CLE, linpus, Xlinux, .... etc, and FreeBSD or *BSD
systems, they all use this "zh_TW.Big5" locale name as their standard.
The reason is, at least in the world of Free Software, we have a unique
standard in Taiwan, and it will bring many convenience both for
programmers and end users, or even commercial menufactors.
However, if C locale changes the policy and use "zh_TW" instead of
"zh_TW.Big5", it means many other parts of the system should change
the convension, either the default locale setting or in the source
code. And we might have to re-educate the users and programmers to
use the new convension. Why should we waste these efforts?
So, in my opinion, I suggest that (at least for the locale the Taiwan
people will use) the C locale name should be "zh_TW.Big5". But we
can make a alias from "zh_TW.Big5" to "zh_TW" in
/usr/share/locale/locale.alias
This is very critical, because "setlocale()" call always report the
"official" locale name. Hence from our policy, the "official" locale
name should be "zh_TW.Big5". For the X locale, it is better to use
"zh_TW.Big5" as the "official" name and make an alias to "zh_TW", too.
No matter what, I will modify the xcin (http://xcin.linux.org.tw) source
code such that it is smart enough to identify "zh_TW" to be "zh_TW.Big5".
But in any case, I don't recommand this for other parts of the whole
system. It certainly will introduce many unnecessary confusings.
: 3. The message files (i.e. po files): need both zh_CN/zh_CN.GB2312 and
: zh_TW/zh_TW.Big5 present in /usr/share/locale, as programs will
: look for both of them. I'd suggest that we make the short-named ones
: directories and the longer-named ones links, with the hope that the
: later will eventually disappear as more and more programmers adopt glibc2.2
: convention.
I agree with this. In fact I suggest that in the new development, the
message files should take "zh_TW" or "zh_CN" as the LC_MESSAGES name.
Because the messages only depends on the culture, on the language, and
they should not depend on the encoding.
However, for LC_CTYPE, it always depends on the encoding, and the whole
name like "zh_TW.Big5" is really needed. :-))
T.H.Hsieh
Reply to: