🚀 go-pugleaf

  Date: Sun, 30 May 93 09:43:17 +0200
  From: Dale Stipe <dstipe@ips.iacd.honeywell.com>

  [translation vs. localization]

Fully automated translation of embedded text in programs is not currently
possible; some automated translation is possible, however the quality is
not sufficient to depend on it completely.  On the other hand, automated
translation systems may be useful as tools to be used in the localization
process.  However, their expense (and complexity of use) is prohibitive.
The most useful tool for localizers is a multi-lingual terminology data-
base.  Again, these are rather expensive and usually tuned to particular
sublanguages (e.g., medicine, aeronautics, etc.), and are often tied to
particular language pairs, e.g., (German/English, Japanese/English, etc.)

  Are there any experts out there that can provide a step-by-step guide to
  i18n?

Most experts are tuned into particular platforms and the solutions those
platforms provide, if any at all.  There are few experts who know all the
(different) solutions on different platforms.

  I just got the XPG4 document set to see what it has to offer.

You should be aware that X/Open is in the process of (yet again) revising
its approach to I18N.  They recently published what is called a "Distributed
Internationalization Services Snapshot" (DISS) which will eventually be
turned into the I18N facility of XPG5 (at least this is my understanding).
In the DISS is introduced the notion of an opaque text object which supports
stateful encodings and other types of functionality, e.g., each object is
associated with an attribute object which can store the locale in which
the text object is to be interpreted.

The point here is that there is still a lot of development going on in
supplying basic substrate solutions to I18N problems, a process which I
see continuing for 3-5 more years at least.

  Are there any books that people have read that give a short concise
  definition of an approach to solving the i18n development problem?

Not particularly.  However, I am aware of a couple of books being written
that do provide much more information than is currently available.  I don't
expect them to be finished before the end of this year or early next year.
A couple of books available now are the "Digital Guide to Designing
International Software" by Digital Press, and "Global Software" by Dave Taylor,
published by Springer-Verlag.  The former is oriented towards DEC's solutions;
the latter is fairly high-level, and gets into market issues; however, it
does cover some material on locales and related processing functions found
in the XPG3 and POSIX world.  In the Macintosh world, you can find a text
called "Macintosh Worldwide Development - Guide to System Software."  It
covers the MacOS Script Manager and related functions.

Many of the Unicode consortium's members are working on various aspects of
supporting I18N through the use of the Unicode Worldwide Character Set
(ISO/IEC 10646-1:1993, UCS2 form).  I expect them to be publishing API
guides and the like for their customers which concern solutions for
supporting Unicode.

As for X11R5's support, it is oriented primarily at two things (1) making
use of locale bindings to determine the interpretation of character strings,
e.g., strings in resource files or resource databases, (2) providing a
FontSet mechanism for associating multiple X11 fonts together for displaying
text encoded with portmanteau style encodings, e.g., EUC, UJIS, ISO 2022, etc,
and (3) providing an Input Method mechanismm for supporting the input of
Chinese, Japanese, and Korean text.  One of the major missing components of
X11R5 is the lack of Output Methods, which are needed to effectively support
the display of Arabic, Indic (Devanagari, Tamil, etc.), SE Asian, and
other scripts which require more complex mappings from characters to glyphs
at output time.  [For some strange reason, the X people and the X/Open people
don't seem to understand this latter process, and, instead, have assumed that
input methods would handle this mapping at input time.  However, this
assumption is completely wrong!]

As an I18N expert, I would say that the biggest problems in I18N are
(in order):

1. Proliferation of multiple character set and encoding standards and the
   lack of a common interchange form.

2. Lack of embedded writing system (language & orthography) tags in character
   data.  [You need this to tell whether an <A> is an English A, a French A,
   a Spanish A, etc.]  Such tags are independent of locale tags since they
   may vary in a single string, e.g., a multilingual string.

3. Lack of an adequate API for supporting the full needs of I18N, and, the
   proliferation of multiple, incompatible APIs across differnt platforms.

4. Lack of high quality non-Roman fonts, and lack of font technology such
   as Postscript and TrueType, to adequately describe the needs of these
   fonts.

5. Lack of ancilliary standards such as Keyboard Layouts, per-Language
   Cultural Requirements, etc.

The most pernicious of the problems, #1 above, can now be solve fairly well
thanks to the new ISO/IEC 10646-1:1993 Universal Character Set standard (and
Unicode, the more fully specified 2-byte form of this new standard).  However,
problems remain in the actual use of Unicode; e.g., the possibility of having
a NUL octet embedded in a 2-byte character encoding.  [In Unicode, a coded
character must be interpreted as a full 16-bit wide character, and not as
a string of octets such as are found in multi-byte encodings like JIS.]

Item #2 above is just starting to be addressed, and it will be some time
before general solutions are available here.  The same for #5.

Item #3 is getting attention from a number of places; however, there is
not much commonality in the solutions being proposed.

Item #4 is now much better since Monotype and Linotype have converted their
non-Roman collections to PostScript Type 1, and since many new good fonts
are coming out of Asia for supporting CJK in PostScript and TrueType.
However, new technology in the font standards themselves will be some time
in coming, although new extensions to TrueType for addressing non-Roman
fonts are well under way.

I hope the above has helped some, although they may not be the kind of
answers you are looking for.

Glenn Adams

Metis Technology, Inc.			Tel: +1 617 868 8010
358 Windsor Street			Fax: +1 617 868 8089
Cambridge, MA 02141
USA