Re: Future of open source I18N [was: Setting Deafult Font Size in X]

[jwb@example.com (Jim Breen)]

Finally snatching a moment to reply.....   [much snipping]

>> From: "Stephen J. Turnbull" <turnbull@example.com>
>>     Jim> in a foreign language (i.e. English) and convince the
>>     Jim> developers to make a heap of changes they will never use and
>>     Jim> probably can't even test.
>> 
>> chikusho.  Go look at the authorship of Pine and the authorship of RFC
>> 1462 (IIRTRFCC, otherwise permute digits), take the intersection, and
>> tell me that's why Pine doesn't have decent Japanese support.

Sadly one swallow doesn't make spring.

>>     Jim> And the problem seems to lie with XIM and the gruesome mess
>>     Jim> that calls itself I18N in the Unix world.
>> 
>> Oh, come now, Jim, you know better than that.  I18N is just plain
>> hard.

I don't think it needs to be that hard. Someone needs to write a book
on I18N with Unix/Linux. Damn - I should do that myself, but I simply
haven't the time.

At present the hard information has to be pried out painfully, and the
ratio of correct advice to misleads is rather low.

>>   (Hideki Hiura of XIM and IIIMF infamy tells
>> hilarious stories of the "migratory Japanese minority" who spent years
>> inciting various national standards committees to propose the addition
>> of certain corporate kanji to Unicode.)  Microsoft may be willing to
>> ignore those standards, but we shouldn't.  A bad standard is better
>> than no standard.

Actually I agree with the approach. The extra kanji in JIS X 0213 are
likely to show up in Unicode fonts long before anyone puts them into
"Shift_JIS Fonts".

>>     Jim> First we need (a) a revamp of the locale structures and rules
>>     Jim> so that I18N can really happen, and
>> 
>> I disagree.  But I'm listening....
>> 
>> Basically, human beings are single-threaded.  Machines are fast.
>> There's no particular reason why doing a setlocale() on every
>> keystroke would be prohibitive.  If people not doing libUnicode or
>> libc implementation (or the equivalent, such as writing libc wrappers
>> for Lisp or Python) would restrict themselves to using the LANG and
>> LC_ALL categories for everything except message catalogs, and the LANG
>> (or the GNU extension LANGUAGES) and LC_MESSAGES categories for
>> message catalogs (gettext), there just wouldn't be a problem.

I'm trying to get a consistent set of advice to the Tcl/Tk core people
on what they should be doing on this. For example, Tk won't display
Japanese unless LANG has been set to Japan. It won't engage kinput2 via
the xim protocol unless all the locales are set to Japanese. They thought
this was the correct interpretation of the documentation.

>> I see that as a generic way to deal with the issue.  Once we've got
>> some useful de facto standard wrappers, we can try to make them formal
>> standards.  But I18N is just too hard to try to (re)standardize a priori.

Document them, please.

>> It's not the core teams who have problems, these days.  It's the
>> localizers who haven't caught up to the mid-80's yet and still think
>> that generating code is a big cost center.

Sadly I know some core teams who are just as much the problem. Yes,
having localizers takes the heat off them, but it *has* to be fixed.
Trouble is it is hard and takes time and effort. We don't have people
like Bill with deep pockets.

Jim
-- 
Jim Breen  [jwb@example.com  http://www.csse.monash.edu.au/~jwb/]
Visiting Professor, Institute for the Study of Languages and Cultures of 
Asia and Africa, Tokyo University of Foreign Studies, Japan
+81 3 5974 3880         [$B%8%`!&%V%j!<%s(B@$BEl5~30Bg(B]