Re[2]: [Draft] Writing i18n apps with glibc 2.2
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
Reply to: