The glibc-2.2 locale name problem
: You should not need to link anything, glibc 2.1.95 locales should work just
: fine out of box, unless debian maintainer accidentally broke it. Did you tried
: and failed, or you just didn't see the familiar zh_CN.GB2312 and zh_TW.Big5
: directories? By default, glibc 2.1.95 installs 5 zh locales in /usr/lib/locale,
: zh_CN (gb2312), zh_CN.gb18030, zh_HK, zh_TW (big5) and zh_TW.euctw. As you
: can see the two locales are there and just got different names. Glibc is smart
: enough to know that you want to use zh_CN even if you set LC_* to zh_CN.GB2312
: or zh_CN.gb2312, same holds true for zh_TW.Big5 and zh_TW.big5. Actually it's a
: little bit too smart and outdone itself, even you set locale to zh_CN.garbage,
: it will set it to zh_CN.
:
: If you really want to create an alias for a locale, soft link is not the
: suggested way. You might want to use /usr/share/locale/locale.alias instead.
Hello,
I have upgraded to libc6_2.1.95-1.deb and made a little test.
Although glibc-2.2 is smart enough such that it can determine
the default locale name "zh_TW" as "zh_TW.Big5", but it could
still introduce a lot of problems in the other parts of the system.
For example, the XFree86 (3.3.6) system. Even I made an alias
name from "zh_TW" to "zh_TW.Big5" in /usr/share/locale/locale.alias,
any X Window program using FontSet to draw texts will crash when
it excutes the XCreateFontSet() function call. Which means, all
of the Xi18n program will not run in this circumstance.
Therefore, a consistant locale name in all parts of the system
is important. If we want to use "zh_TW", then the X locale name,
gtk configuration, and all the other parts should switch to it.
This might cause a lot of efforts. Or, we can just make the change
mv /usr/lib/locale/zh_TW /usr/lib/locale/zh_TW.Big5
then everything works very well :-))
T.H.Hsieh
Reply to: