Re: 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> Sadly one swallow doesn't make spring.

I don't disagree.  Sure, Americans with ostrich pragmatics educated in
dodo schools of design are a problem, even if they're still Finnish or
Japanese according to their passports.

But the Europeans and the Asians are just as bad.  They just lipsync
"L'Internationale" better, since it serves their purposes vis-a-vis
them obstructory Americans.

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

Haven't written a book yet[1], but two articles ....

Linux Journal, Apr/May 1999.
Ch 28 of Professional Linux Programming, Wrox Press.

Not to mention マルチリガル環境実現 (or so) by Handa &co, and 国際化プ
ログラミング／Ｉ１８Ｎハンドブック by Suehiro &co.  Neither one of
which would be much help to your Tcl friends, even with a good English
translation, I'm afraid.  The first is mostly self-promotion by
pioneering implementers, and the second is extremely abstract and
standards-oriented.

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

Because it's hard, and there's damn little practical experience out
there.  I've got 100 pages in print in those two articles (converting
dense LJ pages to sparse Wrox pages ;-).  That's maybe 10% of what
should go into a book at the current state of the art ... 1000 pages.

The problem is the lack of wrappers.  Eg, XIM?  Uh-uh, and even if it
was acceptable, you'd still have the problem of non-X apps.  So you
need to discuss dead keys and other keymap issues, lowlevel X and tty
programming, etc.  Interfacing to dictionary servers (which don't
deliver Unicode conversions).  Etc  You have to do it all by hand, in
each separate environment.

But let's talk about writing that book....

    Jim> The extra kanji in JIS X
    Jim> 0213 are likely to show up in Unicode fonts long before
    Jim> anyone puts them into "Shift_JIS Fonts".

Er, more like several years after.  Mojikyo, no?

More seriously, they will never ever appear in a "Shift_JIS font."
CID font, the Cmap would be a couple hours' work.  10 minutes later,
'net release.

    >> 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> Document them, please.

"Them"?  You mean the wrappers?  I can tell you what doesn't qualify
yet, if you like.  I don't know how to fix them.

    >> 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.

    Jim> Sadly I know some core teams who are just as much the
    Jim> problem.

Hm.  If you say so, I don't know everybody in the field, not by a long
shot.

But my point is that ASCII-speakers don't have the need.  It's not
surprising that they are neither willing to implement Unicode
themselves, when Java is slow and leaks memory like a sieve and
XFree86 4.0.x is apparently incompatible with decent sound[2].  Nor
accept patches to put Shift_JIS, EUC-JP, and ISO-2022 on equal footing
with ISO-8859-1, which would require massive follow-up effort to
unbreak ASCII, let alone non-ISO-8859-1 European locales.  They've got
better places to put their effort.

And the localizers, with the need, prefer to maintain separate
patches, rather than contribute a (configurable) full I18N adaptation,
but then that gets old and they stop.  A plague on both houses....


Footnotes: 
[1]  Linux 日本語環境 doesn't count, it's L10N.

[2]  Certain platforms.  Details off list if you want, Chris.

-- 
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."