[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The glibc-2.2 locale name problem



On Fri, Oct 20, 2000 at 11:05:02PM +0800, thhsieh@linux.org.tw wrote:
> 
> 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.

Hello Hsieh,

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.

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


Regards,
rigel



Reply to: