Re: XIM, kinput2 & Tk

[jwb@example.com (Jim Breen)]

[I note a convergence of views in this thread.]

>> From: "Stephen J. Turnbull" <turnbull@example.com>
>>     Jim> Moreover, it eventually recognised that the original
>>     Jim> catalogue-based approach was inadequate.
>> 
>> I don't see why, for bread-and-butter I18N.  

Actually I gave MS too much credit. The original approach had
catalogues, but it was still basically single-byte code that had to be
relocalized each release. MS spent a fortune achieving, more or less,
their "single binary" goal.

>> Besides monolingual
>> applications, the current structure covers the most important case of
>> multilingual use: a novice in the language being manipulated
>> (determined by LANG) wants messages in another language (determined by
>> LC_MESSAGES).  Assuming the apps are coded that way, and not
>> arbitrarily using LC_CTYPE....

Which reminds me, I see refs to Debian's "locale" application, which
presumabably set up things for you. Is it any good?

>>     Jim> I quizzed RMS
>> 
>> Waste of time, he has _no idea_....  I used to respect his position on
>> I18N as consistent, if not completely up-to-date.  Then he blew all
>> his credibility with Emacs 20.

Amen.

>>     Jim> I'd like to see a formal structure for using multiple
>>     Jim> languages, i.e.  codesets, collating sequences and IMs. AFAIK
>>     Jim> this needs extensions beyond the basic POSIX model,
>> 
>> Really it just needs locale objects.  The structure is there in POSIX;
>> the big mistake that was made there is making locale a process-global
>> parameter.  Thus spake the ever-so-erai Drepper-sama, and as usual,
>> he's correct.  (I say so. ;-)
>> 
>> We're really pretty close to it in the X11 model, since XFontSets,
>> XIMs, and XOMs (don't ask unless you're Egyptian) all bind the locale
>> at creation time.  They screwed the pooch on LC_CTYPE (_still_ haven't
>> had time to chase that down :( ) but the basics are pretty solid
>> ... if someone would just implement, implement, implement the toolkit
>> that those things are supposed to be encasulated in.  And glibc has a
>> lot of this stuff already, but nobody knows what it is or where and
>> it's undocumented.  :-(

Amen (see, I'm agreeing with you down the line.)

>> 
>>     Jim> e.g. GNU's LANGUAGE list.
>> 
>> No, I don't much like that, because it's also process-global (and the
>> process is the shell, at that).  I really don't see why LANGUAGE is so
>> terribly useful.  Most of the time, English is a satisfactory fallback
>> language, and English is always available since it's the hash key.  

All we need are apps that know they speak English   8-)} Actually I
blame RMS and gettext() for overlooking the built-in-default option.

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]