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

Re: locale-zh



Hello thhsieh,
On Fri, Nov 17, 2000 at 09:01:33AM +0800, thhsieh@linux.org.tw wrote:
> 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.

Yes, I recall reading this on cle-devel, but at that time I was too busy ..
hopefully after the exams are over, I can start work on it again.

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

This would be great!

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

If it works with zh_TW.Big5, then I see no reason to make symlinks or
add entries to locale.alias too.

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

I seem to recall that the format for XF4's locale.* has changed to something
like
	zh_TW.Big5/XLC_LOCALE:		zh_TW.Big5
			     ^ note the colon

I could be wrong ...

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

Thank you!

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

If the format is the same as that used by the old xfs-xtt, then it should
be easy :p

How about the table in /usr/lib/X11/fonts/encodings/large?  Does it have
problems too?

Once again, thank you and the CLE team!

-- 
  Roger So                                            telnet://e-fever.org
  spacehunt at e-fever dot org                          SysOp, e-Fever BBS
  GnuPG  1024D/98FAA0AD  F2C3 4136 8FB1 7502 0C0C 01B1 0E59 37AC 98FA A0AD

-- 
| This message was re-posted from debian-chinese-big5@lists.debian.org
| and converted from big5 to gb2312 by an automatic gateway.



Reply to: