Re[2]: [Draft] Writing i18n apps with glibc 2.2

[hashao <hashao@china.com>]

Hello rigel,
On Monday, October 16, 2000, rigel wrote:
>>  1. Don't use environment variables to determine locale settings.  In
>>     particular, do NOT use the value returned by setlocale(3) to
>>     determine the current locale's encoding!  Instead, use
>>     nl_langinfo(3) for this purpose.

r> Good point. However I don't think it's glibc 2.2 issue. Actually if you stick
r> with glibc only this is not a very big issue, because you always know how
r> the locales are named (well, kind of). It's a serius issue when you want your
r> program also runs on other unix systems with their native C library. That's
r> when the naming conventions becomes wild. So if portability is a concern,
r> nl_langinfo should be used no matter what C library you work with.

setlocale and nl_langinfo should be used conjunctly to construct a
locale under glibc 2.2.x.

r> Just a small thing. A new LC_CTYPE class "hanzi" was added in glibc 2.2
r> locale (both zh_CN and zh_TW have it, zh_HK doesn't though). It currently
r> contains all the unicode unihan characters. I don't know how useful this
r> is (your comments on this are welcomed). In case some one is interested in
r> this, here is a sample implementation of "iswhanzi(wchar_t wc)"

This would make parsing hanzi string easier. Also handy for
line breaking detection, I think. It is just that it is not
portable :(.

-- 
Best regards,
 hashao                            mailto:hashao@china.com.n.s.pam

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