[3446] in java-interest
Re: ?Internationalization in Java?
daemon@ATHENA.MIT.EDU (Vania Joloboff)
Mon Nov 13 10:26:59 1995
To: jeff.sundin@nosun.West.Sun.COM
Cc: java-interest@java.Eng.Sun.COM
In-Reply-To: Your message of "Fri, 10 Nov 1995 09:46:29 PST."
<199511101746.JAA29852@monstro.West.Sun.COM>
Date: Mon, 13 Nov 1995 13:53:21 +0100
From: "Vania Joloboff" <vania@gr.osf.org>
> Is anything available to assist with Internationalization in Java programming?
> What pointers to this information are there? Things like a LC_LOCALE
> flag to detect which language to display would be nice.
There is an open issue in Java. Currently [well for Alpha3, I do not
know for Beta yet] the Java run time does not call setlocale. It looks
like the Sun folks have not decided yet whether they would support the
ANSI/POSIX/XOpen locale model or not. With pros and cons.
BTW, there is no such thing as LC_LOCALE in this model.
The categories are LC_CTYPE, LC_MONETARY, etc..
Cons (ANSI model)
If you think that you will have concurrent applets over a single runtime
using different languages (i.e a Java runtime serving multiple X
terminals with users in a different language) then the ANSI/POSIX/XOpen
locale model won't work, because this model is (a) there is one locale
per process (b) the locale is stateful and you cannot save/restore it.
The Java run time is a single process, hence when you would switch
threads in different languages, you would have to switch locale (i.e
call setlocale) underneath and then you loose the state of the C, X, and
Motif libraries (to name only those).
If it is a requirement to run applets in different languages over a
single Java run time, then Java should create its own model.
Pros (ANSI model)
If you think it is acceptable to run all applets (all threads) over a
single run time in a single language, then the locale model would become
more than adequate. When the Java run time starts up, you call setlocale()
and then you can safely use the C, X and Motif libraries functions.
It can be argued that there should be one Java run time per user,
for security reasons as well (running the run time with user's
credentials), therefore a single language: the user's language.
In summary, the Java architects need to choose an i18n model.
Either to use the ANSI/XOpen locale model, to call setlocale(), and then
libC, X and Motif work fine. Or they choose a more flexible model (one
locale per thread) but then, first it cannot be implemented over X and Motif
as they are designed (I am not familiar enough with Windows/NT to tell),
second a Java mechanism is required to announce the locale per applet.
A problem is that Alpha 3 implements neither model...
Another issue in Java Alpha3 is the input method selection per user for Asian
languages. Motif has a resource on vendorShell called XmNinputMethod. When
set, this resource is used by Motif to call XSetLocaleModifiers, so that the X
library may open the network connection to the user's input method. I have not
seen in awt a way of setting this, but you can set it with your .Xdefaults
anyway. So there's a work around. Note this is again based on the locale
model...
========================================================================
Vania Joloboff Phone: (33) 76 63 48 92
OSF Fax: (33) 76 51 05 32
2, Avenue de Vignate
38610 Gieres - France e-mail: vania@gr.osf.org
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
