NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/bsd/10552

Internet Message Format | 1992-12-23 | 7.1 KB

Xref: sparky comp.unix.bsd:10552 comp.os.linux:21408
Path: sparky!uunet!cs.utexas.edu!sun-barr!sh.wide!wnoc-tyo-news!sranha!anprda!pmcgw!personal-media.co.jp
From: [e-mail] (Chiaki Ishikawa)
Newsgroups: comp.unix.bsd,comp.os.linux
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Message-ID: <[e-mail]>
Date: 22 Dec 92 11:05:42 GMT
References: <agp22+#@rpi.edu> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.unix.bsd
Organization: Personal Media Corp., Tokyo Japan
Lines: 119
Nntp-Posting-Host: ds5200
In-reply-to: [e-mail]'s message of 21 Dec 92 23:30:30 GMT
X-Md4-Signature: fc687e38b46132c38f9949ca6deb7e08


Hello. I am a Japanese working at a Japanese software company in Tokyo, Japan.

In article <[e-mail]> [e-mail] (InterNet News) writes:

    [ text deleted ]

     We did it for internationalizing our process control software.  Each
   required string was recorded in a big file (orientation wasn't a problem,
   but was taken into account) where each string (including it's diacriticals)
   was stored according to function.  Yeah, it WAS more work, but we could do it.
   We had a function that used the English String Content as a hashed key into
   the file, and displayed the correct state, etc. on the screen based on the
   string required and target language.  We loaded the target language strings
   into memory to speed up the process.  One thing that we DIDN'T try to do was
   have the software try to translate anything.  We just displayed the data.
     It is the same idea as using 'malloc' to create a data area, rather than
   a set address in memory.  It is just a matter of designed-in flexibility.

This aproach explained here is essentially the ones X/Open and POSIX
are using for gettext or dgettext (spelling?).  Essentially, you will
use a (external) database of display strings keyed by your original
language string, say, English string, and at runtime use the proper
display string. I myself used a similar approach in localizaing a
French software.

   >For example, if you want to
   >type something in the Nagari script, hardly an uncommon script, you
   >will either have to have an overly complicated and artificial method
   >of entering text (bad - this puts unnecessary burden on the user),

     We need a Nagari input device; the 101 key keyboard is hardly the correct
   vehicle for this type of processing.  Is the fact that a good Nagari input
   device does not exist because American engineers are stupid?  I don't
   think so.

Completely agreed. It has nothing to do with the American. In Japan,
we had/have a big problem of inputing many different Japanese
characters into computer systems. It is better to leave the problem to
the Japanese community (engineers, typical users, educators, and such)
to figure out the solutions if they exist. [We do have a temporary
solution, which I think is a kludge althouth it works well.]  Of
course, suggestions from overseas engineers are welcome, too. However,
unfortunately, if you don't understand the language of the target
community, it will be very difficut to offer reasonable suggestion.
For example, I have no idea about what Nagari looks like. So I don't
expect my suggestion will not be worthwhile for people who use Nagari
script.

However, even if we don't understand the target community's lanuguage,
we can make the work of localization by much, much easier by NOT
including language-specific feature in the core design. Of course, it
will be silly to expect a word-processor to avoid language specific
decisions. But, many applications as TSgt Dave Burgess writes here can
avoid/postpone/hide such dependency till the last implementaiton
stage. This means that if the original design pays attention to I18N,
such localization can be done in a modular way without BREAKING other
parts of the software.

IMHO, This is an important lesson.

     Designing for internationalization is not the issue, in my opinion.  In
   fact, it is not in our best interest to continue the mistakes we have made
   in the past.  The only design consideration for internationalization is to
   make a concious desicion to DO it.  Once that decision is made, then a
   strategy for adoption must be formulated.  A couple of simply example are
   included below:

     -  No Static Strings compiled into the kernel of your programs; make them
   loadable moduleis based on langauge(s) required.  The concepts of shared
   libraries and remote process calls both come to mind as possible methods
   for implementation.
     -  Use printf modules that obey more rules than "Left to Right at 10CPI"
   or redesign your printf to include a rules base for different languages.
   For example, modify it so that printf can print in any of the four primary
   directions (up, down, left right) and can print based on some kind of
   larger character set than 7 bit IBM-PC.  Those two new rules for printf
   could solve many of the problems we have today.

Again, totally agreed. I have worked with a French company which
produces mechanical engineering tool on WS. We wanted to introduce
Japanese version into the Japanese market. I literally have to plod
the French engineering team (AND THE MANAGERS) to modify the original source
code to better support I18N. The changes made are essentially

- String data are now stored in separate files. (French, Germany,
English, and Japanese to follow soon.)

- The interaction is done on X window and the new dialog manager are
organized to access external string data base to manage string display
and mouse input.  This part is yet to be localized. X11R5 is not
adopted by every HW vendor yet, and I will have to see if X11R4 can
handle the Job adequeately. It will. We have at least done preliminary
work for Japanese only and it works.

Regarding printf, I haven't gone that far yet. POSIX and X/Open will
call for some kind of LOCALE-specific behavior of printf. But, my
suggestion is "DON'T BET ON IT." As far as I have seen, the
locale-specific behavior is too new to be stable and I can see it may
change over the next few years, and there will be customers who don't
like the default locale behavior anyway :-(
But, again, as a starting point, it will serve a purpose in the long run.

     If you use the two methods above as simple starting points, and design
   your programs to conform to a standard that says you won't  violate the
   method you are going to use for your internationalization.  From there,
   the design can proceed unimpeded.  Your implementation mileage may vary
   of course.

   TSgt Dave Burgess

Yes, and it is best to instill the sprit of I18N into the manager
above the engineering team. If the manager insists on I18N approach,
things will fall into pieces eventually: although it may take time. I
have worked with this French company almost 4 years now :-)
Nice things about them is they speak English to me so that we can
communicate. I don't speak French.

Chiaki Ishikawa