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

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Jim" == Jim Breen <jwb@example.com> writes:

    Jim> Hear, hear. I can see the problem though, it's often easier
    Jim> in a big project to generate a set of Japanese patches than
    Jim> to go into battle

Easier to "generate", yes, but that's 1960s thinking.  Today we know
that generating code is maybe 10% of the battle.

    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.

    Jim> The problems occur where kinput2 collides with xim.

True enough.  But ironically enough, XIM was designed and implemented
by Japanese, well familiar with the kinput2 protocol etc.

    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.

_If_ and _only if_ you are willing to run an all-Microsoft shop,
Windows 2000 and its apps _might_ be considered acceptable I18N.

But as soon as you acknowledge that it's a multiplatform world, you
realize that there is no dog-poop in the MS living room because MS
walks its dog in the park (and leaves the shovel and baggie at home).

I18N is a mess in the Unix world because we've been at it longer.
(Microsoft didn't even try until Unicode was in Version 2.1---that's
why I've been a Linux user since 1994.)  There are localized
variations all over the place, and we do need to keep backward
compatibility---especially in free software, where if we don't do it,
the offended Japanese and Ethiopians will, and with our own code!

And it's a mess because of nationalistic (and corporatistic)
chauvinism on the part of representatives to the international
standards committees.  (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.

>> Yes, Japanese is different.  But it's not Spaniards or Croatians who
>> pay the price of "Japanese exceptionalism," it's us Japanese users.
>> And especially those of us who are (admittedly only approximately, in
>> my case) multilingual.

    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.

If and when I get some time to code, revamping the XEmacs code that
deals with XIM to allow on-the-fly selection of XIM input managers is
pretty high on my list.  Do it once, it won't have to be done again
(although the code will be copyright Code That Sucks, Inc, and will
need lots of improving, I expect ;-).

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.

    Jim> (b) a change of mind-set on the part of many open-source
    Jim> developers, who still live in a world where software is
    Jim> By_Americans_For_Americans, and I18N means supporting
    Jim> ISO-8859-1 at most.

That change has taken place.  Turbolinux is making money _here_ and in
China, _not_ in the U.S. from all I've heard.  glibc is a mess,
granted, but at least Ulrich's heart is in the right place on I18N.
The money says internationalize or die.  The volunteer projects I know
about are all heading in the right direction too (although that's a
biased sample since I've been drawn to participation in free software
almost entirely through the need for I18N support).

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.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."