Re: locale-zh
: > locale setting. Which means, what we set under the LC_CTYPE environment
: > variable will be returned by the setlocale() exactly. This is crucial
: > since currently many locale related programs still have a bug to relay
: > on the return of setlocale() call. So this change should work around on
: > them.
:
: Really? One big program I know depends on setlocale() is X. Ironically,
: before this change Big5 locale works fine out of box in RH7. Now one has to
: modify X to make it working. I'm not sure this change is a good move. It
: only gives users an illusion. It makes the return value of setlocale() even
: more unreliable and user-dependent. Though it's not a big deal.
This change is suggested by the developers in Japan, and Drepper is
kindly to do the change. The Japan developers provide the following
reasons for this change:
1. When we set the locale environment to be something like:
(the following are only for example, sorry I cannot remember exactly
the locale name of Japan)
export LC_CTYPE=ja_JP.JIS
then the /usr/bin/locale command will return:
LC_CTYPE=ja_JP.JIS
i.e., exactly the same as the name we set, but setlocale() call returns
ja_JP.jis (or just: ja_JP)
i.e., it returns the internally normalized one. This is inconsistance.
2. They asked for backward compatibility. Because many Japan X Apps.
installed their X app-defaults and resources files in
/usr/X11R6/lib/X11/<locale-name>/
and this <locale-name> should be exactly the same as the LC_CTYPE
setting. They complained that using glibc-2.2 most of their environment
cannot work. Therefore Drepper made this change.
For my personal opinion, I like this change. This makes glibc to be
more backward compatible to the old style, without lost its new
features. Although the return of setlocale() call will not normalize
to its internal name, but as you mentioned before, to get the "correct"
name we should use other calls like "nl_langinfo()". So I think this
should be good enough.
But with the new change of glibc, I don't see any necessary changes
should be took for XF86. Only a proper setting in locale.dir is necessary.
And as you mentioned, the settings in current CVS is already OK. So that
should not be a problem. Could you please figure out the changes you
have to make for your case?
: > Secondly for XF86-4.0.1. It has a small problem. The copy shipped with
: > RedHat-7.0 does not contained any "zh_TW.B(b)ig5" XLC_LOCALE data, so
:
: Are you sure? My RedHat-7.0 installs a zh_TW.big5 XLC_LOCALE.
I don't know. I am not a RedHat user. Many of my friends told me
that they just cannot find any XLC_LOCALE for big5 locale. They
only found a big5 charmap or something like that in RedHat XF-4.0.1.
They told me this and asked me how to fix this, and I guess that
using the XLC_LOCALE of XF-3.3.6 might work. So they done this.
: It is my understanding that the convention for locale naming in X is that
: the names always contain charset part. The short names (without charset) are
: only used for alias. I'm not sure this is actually a stated rule though.
:
: The latest locale.dir in X CVS looks like this:
:
: zh/XLC_LOCALE: zh_CN.eucCN
: zh/XLC_LOCALE: zh_CN.GB2312
: zh_TW.big5/XLC_LOCALE: zh_TW.big5
: zh_TW.big5/XLC_LOCALE: zh_TW.Big5
: zh_TW.cns11643/XLC_LOCALE: zh_TW.eucTW
:
: I strongly suggest CLE add zh_CN.GB2312, otherwise xcin will have problem
: working under GB2312 locale.
Of coures they do. In my past mail I just focused on the big5 part.
In the GB part the situation is very similar, and CLE developers
also have the zh_CN.GB2312 lines in the locale.dir file.
: The latest locale.alias in X CVS looks like this:
:
: zh: zh_CN.eucCN
: zh_CN: zh_CN.eucCN
: zh_CN.big5: zh_TW.big5
: zh_CN.EUC: zh_CN.eucCN
: zh_CN.euc: zh_CN.eucCN
: zh_CN.gb2312: zh_CN.eucCN
: zh_TW: zh_TW.big5
: zh_TW.EUC: zh_TW.eucTW
: zh_TW.euc: zh_TW.eucTW
: zh_TW.big5: zh_TW.big5
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Question: why should we need this line? The name alias to itself??
Thanks for your information :-)
T.H.Hsieh
Reply to: