Re: XIM, kinput2 & Tk

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

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

    Jim> Moreover, it eventually recognised that the original
    Jim> catalogue-based approach was inadequate.

I don't see why, for bread-and-butter I18N.  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....

For true multilingual applications, yes, they should ignore locales or
even subvert them when interfacing with monolingual apps and
libraries.  But we don't know enough about that yet to enunciate
general principles.

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

    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.  In
those cases where your first choice is unavailable, you can reset
LC_MESSAGES.  No reason why the app can't do it on the fly.  Make it a
standard dialog: "I'm sorry sir, there don't seem to be any messages
in Japanese.  I have Mandarin, Afrikaans, British English, Australian
English, and N'Awlins Creole.  Which would you like?"  (Yes, there is
an implementation in Chapter 28 of Professional Linux Programming.)

Also, there are applications (eg, XEmacs) where even native speakers
agree that some fallback (English) is preferable to their language
(Japanese) because the translation just sucks.  (In some of the
comments deep in the Mule code it's even worse -- the Japanese
comments by the original programmer are inaccurate and the English
translations correct!)  LANGUAGE really ought to be a fallback itself,
deferring to the user's resources per package.

    Jim> I'd like also to see more effort and coordination of utilities
    Jim> and user interfaces so we are not stuck with hand-crafted
    Jim> wrappers and the like.

Did someone call for coordination?  Maaaaama!  Maaaamaaaa!  :-)

There's always Mule....  Why bother with any language but Elisp?  :-)

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