>>>>> In <[EMAIL PROTECTED]> >>>>> Peter Novodvorsky <[EMAIL PROTECTED]> wrote: >> ++ 13/12/00 11:55 -0500 - Ben Collins: >> > On Wed, Dec 13, 2000 at 06:49:09PM +0300, [EMAIL PROTECTED] wrote: >> > > locale-gen generates incorrect locale-files. For example if I insert >> > > this line: >> > > ru_RU.KOI8-R KOI8-R >> > > in /etc/locale.gen, it generates locale in /usr/lib/locale/ru_RU.koi8r >> > > directory. Its not a bug of locale-gen, its a feature of >> > > localedef, that "normalizes" locale names. This feature make life >> > > hard from people with .charset locales (japanese .eucJP for eg.), >> > > because programs check directories with charset name in upper >> > > characters (for example qt, gtk and XFree86). Me and Alexander >> > > Kotelnikov ([EMAIL PROTECTED]), patched the locale-gen, so it works >> > > with such locales. Here it is: >> > > >> > > <skip> >> > >> > I cannot implement this. Upstream claims that normalizing is part of the >> > spec, and is the Right Thing, so I will not go against the grain here. >> > Programs that try to read these files directly will need to take this into >> > account and do the Right Thing themselves.
>> It seems that this is trouble not only for us russians, but for >> japanese people. I'm Ccing this mail to debian-i18n and >> debian-russian, if you don't know how many users have trouble with this >> silly Drepper's ``Right Thing''. (BTW, in previous version of libc, >> there was exception for ru_RU.KOI8-R and Makefiles generated KOI8-R, >> not koi8r locale) >> NIDD In this case there is no trouble with ja_JP.eucJP. When set LANG=ja_JP.eucJP : 1) glibc search ja_JP.eucjp locale directory, so refer /usr/lib/locale/ja_JP.eucjp correctly. 2) but in this case glibc's setlocale(3) returns ja_JP.eucJP. (not ja_JP.eucjp) 3) X and gtk (or others like this) would use setlocale(3) return value, so libXt, gtk or etc etc etc.... use ja_JP.eucJP for there own locale mechanism. -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
