[5983] in www-talk@info.cern.ch
Re: FYI: Multilingual Encoding Discussion on www-talk@www0.cern.ch
daemon@ATHENA.MIT.EDU ((Frank Rojas ))
Sun Oct 2 13:27:15 1994
Date: Sun, 2 Oct 1994 18:24:56 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: fxrojas@nlsarch.austin.ibm.com
From: (Frank Rojas ) <fxrojas@nlsarch.austin.ibm.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
From: "Richard L. Goerwitz" <goer@midway.uchicago.edu>
Date: Thu, 29 Sep 94 08:41:24 -0600
>On the recent AIX 4.1, we provide a UNIVERSAL locale that is based on
>UTF-8 (wchar_t = UCS-2).... We are currently able to input and display
>using the standard Motif 1.2 with our localization for:
This doesn't make sense to me, but then that may just be me. The issues
of localization and multilingualism are distinct. The above paragraph,
though, seems to combine them.
Yes and no. Let me explain.
First, I use "localization" to mean more then just translated messages.
For us we provide "locale packages" for fonts, input methods (including
dictionaries for multibyte languages), code conversions, keymaps,
helps, on-line doc and translated messages.
Thus we provide a German locale that is based on Latin-1. We also
provide 50+ other locale packages that provide support for various
languages / territories... based on their corresponding
national code set.
In ADDITION, the UNIVERSAL locale is special because it is defined to
take advantage of other locale packages. E.g. the German locale and
Arabic locale packages would each bring in their respective fonts and
keyboard maps. All W. European locale packages share the same Latin
fonts.
The UNIVERSAL locale used what ever underlying locale packages are available.
Thus the level of multilingual support in the UNIVERSAL locale depends on
the set of local packages you install.
Let me avoid abstraction by giving a concrete example. Suppose we want
a) a multilingual client and b) to use it in Germany. To fulfull b, we
might well localize for Germany. Surely users will want all of the mes-
sages to come up in German, and this is what i18n was designed to help
designers do. This, however, does *not* mean that users will only want
to view German text via the Web. Although their basic interface is in
German, they might well stumble onto an important Bengali or Swahili
information source, and want to read it. The bottom line is that the
user still wants the German localization. But he or she nevertheless
wants multilingual facilities as well.
Agree 100%.
The set of locale packages we provide allow the users to choose what set
of facilities they desire.
So to repeat, localization and multi-language interfaces are not incom-
patible.
I would agree. Sorry if my earlier notes confused you.
By now I hope you'll understand that we have actually integrated localization
and multi-lingual interfaces into one. (Assumming you expand the definition
of localization to span more then just messages).
Hence my confusion over why anyone would want to achive multi-
lingualism by broadening localization to include a UNIVERSAL locale.
Seems to be self-defeating.
Let me answer by saying that our desire is to make all internatioanlized
applications automatically multilingual via the UNIVESAL locale. I.e.
the multilingual services (text processing, font, input) can be viewed
differently from locale specific services (date/time/messages/...). But
we view all pieces as part of the "localization" process.
I hope I've explained that using standard interfaces internatioanlized
applications can achieve some level of multilingualism. Our the goal
has been to extend the internationalization interfaces to achieve
multilingual from within te system across all applications
- mail, editors, help, print, etc..
The UNIVERSAL locale is not just for application developers it makes
the entire system becomes multilingual.
You should see vi with multi-lingual text.
I hopw this helps.
Frank
