NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/unix/bsd/10425

Internet Message Format | 1992-12-21 | 5.8 KB

Xref: sparky comp.unix.bsd:10425 comp.os.linux:21072
Newsgroups: comp.unix.bsd,comp.os.linux
Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Message-ID: <[e-mail]>
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Sender: [e-mail]
Organization: Weber State University  (Ogden, UT)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 19 Dec 92 08:31:37 GMT
Lines: 95

In article <[e-mail]> [e-mail] (Tony Porczyk) writes:
>[e-mail] (Richard L. Goerwitz) writes:
>
>>>> Has anyone in this newsgroup ever heard of the Unicode/ISO10646
>>>> (UCS) standard?
>>>
>>>You know, if 386BSD could be made to support NET-UTF (the Plan 9 version
>>>of the 10646 standard) that would be a major advantage over commercial
>>>Unices...
>
>>One of the big criticism leveled at US Engineers is that they are either
>>too dumb or lazy to build into their software support for non-Western
>>scripts.  Given that Linux originates in Europe, can we look forward to
>>better support for Unicode and ISO10646?  At least for "long" charac-
>>ter definitions?
>
>Yeah, that's probably why NT supports Unicode, it's those dumb US
>Engineers...  Could we lay off idiotic generalizations and stick to
>technical aspects of the software?  It's business that dictates what's
>included in the package.  If it makes economic sense, it will be there.
>Most of the internationalization is done locally anyway, so it has
>nothing to do with dumb engineers.

1)    You have a good point about US Engineer bashing.

2)    "Internationalization done locally" is called localization.

3)    In terms of "economic sense", one wonders why Unicode and ISO10646,
    basically Western standards, are being applied to Far East languages
    like Japanese, Chinese, and Korean, when the XPG4 standard, using
    JIS (an existing Far Eastern standard) as a subset, is being ignored
    by NT?


To deal with the points in order:

US Engineers produce software for the available market; because of the
input difficulties involved in 6000+ glyph sets of symbols, there has been
a marked lack of standardization in Japanese hardware and software.  This
means that the market in Japan consists of mostly "niche" markets, rather
than being a commodity market.  This has changed somewhat with the Nintendo
corporations recent successes in Japan, where standardized hardware is
being used in most homes; this is probably an indicator of where the
Japanese market is heading.  Still, a Nintendo (even with many peripherials
not available in the US) is not a workstation.  Even here, the use of a
custom DMA chip on *each* cartridge instead of *in* the machine, with a
patent on it and a stiff licensing fee outside of Japan tend to imply that
the Japanese software market will not be open any time soon to volume sales
of US originated software.  This combines to make most internationalization
Europe-centric, and therefore limited to 8-bit clean applications/drivers.

It is currently possible to localize anything.  Some of the European work
(and some very particular "8 bit clean" code done in Greece) have been done
for 386BSD.  This is called enabling; in particular, enabling for
localization.  What we want is internationalization of 386BSD; this means
providing tools and native (kernel and file system, and in particular, file
system name space) support for it.  Internationalization goes beyond
localization by providing for multinational use without exectable code
changes.  If we assume booting to X on a VGA (640x480) as a default, and
additional setup of the X to support alternate resoloutions, then we can
cover nearly all written human languages, with exceptions for Arabic,
Hebrew, and Tamil (and similar languages) which require "connection rules"
to be drawn (not supported in X) or have differing drawing direction (for
which there is only primitive support).  "Internationalization done locally"
is localization: a seperate source tree is needed.

Microsoft has adopted Unicode as a standard.  It will probably be the
prevalent standard because of this -- the software world is too wrapped
up in commodity (read "DOS") hardware for it to be otherwise.  Unicode
has also done something that XPG4 has not: unified the Far Eastern and
all other written character sets in a single font, with room for some
expansion (to the full 16 bits) and a discussion of moving to a full
32 bit mechanism.  XPG4, by adopting the JIS standard, appears to be
igonoring HAN (Chinese) and many other languages covered by the Unicode
standard.  So even if the Unicode standard ignores backward compatability
with Japanese standards (and specific American and European standards),
it better supports true internationalization.  I think that Japaneese
users (and European and American users, if nothing is done about storage
encoding to 8 bit sets) are going to have to live with the drawbacks of
the standard for a very long time (the primary one being two 16K tables
for input and output for each language representable in 8 bits, and two
16k tables for runic mapping for languages, like Japaneese, which don't
fit on keyboards without postprocessing).


                    Terry Lambert
                    [e-mail]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------