Re: locale-zh

[thhsieh@linux.org.tw]

: > >  * Encoding naming conventions.  Currently different spellings of "Big5",
: > >    "big5", "BIG5", "big-5" etc etc are all over the place.  We need to
: > >    agree on a standard capitalization of this (probably big5), and 
: > >    see which package(s) are affected.
: > >  
: >      yeah, this is a big problem. I have tried locale alias, but many apps
: >      still cant work. I have to make a link (ln -s zh_CN zh_CN.GB2312) by
: >      hand.
: 
: Same here.  And symlinks IMHO are more ugly than locale.alias ...
: I've heard that glibc has changed its locale handling a little since I
: last looked at it ...

Dear All,

I would like to report the way that CLE developers took to solve the
locale name problem of zh_TW.????. Now CLE developers are working on
RedHat-7.0. As you know, this distribution first shipped with glibc-2.2
and XF86-4.0.1. So their situation is very similar to us.

Firstly for glibc-2.2. If we use the glibc release after Oct.25 - 31 (sorry
I cannot remember the exact date, but I just tested the source in CVS tree
in Oct.31), then it has a simple but important change in the locale name.
That is, even the locale name installed in

	/usr/lib/locale/

is named "zh_TW" (i.e., the zh_TW locale data + BIG5 charmap), then the
"setlocale()" call in the program will report

	r = strcmp(setlocale(LC_CTYPE, ""), "zh_TW.Big5");
	/* and r = 0 */

when we run the program under the 

	export LC_CTYPE=zh_TW.Big5

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.

Taking this benefit, the CLE developer tends to not change the locale
installing name any more for zh_TW locale. That is, our locale name
will be installed as

	/usr/lib/locale/zh_TW/		(zh_TW locale data + BIG5 charmap)

This is also the current glibc default.


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
in fact we don't know which standard the XFree86 will use. I remember
someone told me that in the future the standard might be moved from
"zh_TW.B(b)ig5" to "zh_TW" but also allowed backward compatibility, so
I do asked my friend to do the following test. Since glibc is ready OK
and do not have any problem, so we only test the XF86-4.0.1 part. We
installed our XLC_LOCALE (which is copied directly from XF86-3.3.6, the
format is not changed) with the locale name "zh_TW", and try:

	export LC_CTYPE=zh_TW.Big5	# to test the backward compatibility
	<run Xi18n programs>

but it cannot work. Which means, even in XF86-4.0.1, the XLC_LOCALE should
be installed with exactly the same name as we set in the LC_CTYPE environment
variable. Therefore, the CLE developer decided to do this:

	1. install XLC_LOCALE into

	   /usr/X11R6/lib/X11/locale/zh_TW.Big5/
				     ^^^^^^^^^^
	   note this directory name is irrelevent, it can be any name.

	2. add the following lines into locale.dir:

	   zh_TW.Big5/XLC_LOCALE	zh_TW.Big5
	   zh_TW.Big5/XLC_LOCALE	zh_TW.big5
	   zh_TW.Big5/XLC_LOCALE	zh_TW

	   but remove any locale name or alias of "zh_TW" <==> "zh_TW.EUCTW"
	   or other similar names, i.e., the locale name of "zh_TW" will not
	   point to "zh_TW.EUCTW" or other similar name any more.

so that using the locale name either "zh_TW.Big5" or "zh_TW.big5" or "zh_TW"
will result to exactly the same locale, to ensure the backward compatibility
and adopt a potentially new standard of the future.

So, hope that this report will be helpful for fixing the locale name problem
in woody. :-))


: Perhaps we should try out the other TrueType engine in XF4 (freetype) as
: well?  (BTW this and the xtt module are in both xserver-xfree86 and
: xfonts-base)

Another thing to report, the XF4 freetype part contains a BIG5 to UCS2
mapping table which is invalid and should be fixed. It is in the directory:

	xc/extras/X-TrueType/BIG5/

This table is based on the old BIG5_1984 standard, but now in glibc-2.2
the BIG5 charmap is based on the BIG5 cp950 standard and some improvements.
So my personal opinion is to fix this such that they are exactly the same.
I think it should be very easy to create the table for XF86 from glibc-2.2
BIG5 charmap via simple perl script. If you need help, I could do that and
send the patch to you.


Best Regards,

T.H.Hsieh