Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sun-barr!decwrl!shelby!portia!jessica!duggie
From: duggie@jessica.Stanford.EDU (Doug Felt)
Newsgroups: comp.sys.next
Subject: Re: Non-English support
Message-ID: <7733@portia.Stanford.EDU>
Date: 17 Dec 89 04:12:05 GMT
References: <130053@gore.com>
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: duggie@jessica.Stanford.EDU (Doug Felt)
Organization: Stanford University
Lines: 60

In article <130053@gore.com> jacob@gore.com (Jacob Gore) writes:
>Please, let's separate the question of non-English support for the NeXT
>from that NeXT-vs-Mac-nose-thumbing thread.
>
>What exactly is needed?
>

Amen.

You need to support multiple writing systems with large character sets
(Chinese) right-to-left text (Hebrew) and text in which character
glyphs change based on context (Arabic).  It should be possible to
configure the system to support multiple writing systems
simultaneously (some documents names in Hebrew, some in Chinese).
Support should be system-wide (menus, titles in windows, alerts).  It
should be possible to configure a single machine to come up with the system
in a different language depending on the user.

All applications that support text of mixed fonts and sizes should support
arbitrary mixes of writing systems as well.  The writing systems used for
input and editing should be independent of that for the system. 

Dates, times, currency, etc should appear in the proper format for
the language they are in.

Macro langages for UI scripting, databases, spreadsheets, etc should be
language-independent.  They should parse dates etc correctly.  Indexing
programs (Librarian) should also function properly (Chinese, for instance,
has no spaces to delimit words).

It should be possible to switch between input systems for those languages
where several exist (Chinese again).

A particular desire of mine is to be able to mix both traditional and
simplified Chinese characters in the same body of text.  It would be
handy to have the ability to convert between the two where there is a
clear correspondance.  I think you need a very large Chinese character
set because hand-drawn glyphs are useless for indexing or information
retrieval, and they won't scale (unless you get the user to use
postscript to draw them.)

The above is what I think you need for a real multilingual machine.
Programs that manipulate text should be prepared to deal with any
language the user throws at it, no matter what language the program's
UI is configured in.  One should not have to buy multiple copies of
NExcel in order to use it with different language data.  The user's choice
of language should be constrained only by the system software on her
or his machine.

"Localizability" is a bit different from "multilinguality."  I don't
expect that users be able to translate all of a program's menus and
error messages into their language of choice, although I would prefer
that this be possible simply because most companies won't do it
themselves.  I do expect that any program be able to deal with text
in the user's language of choice wherever it manipulates or displays
text supplied by the user.

Not that there aren't huge technical problems, of course :-)

Doug Felt