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

Internet Message Format | 1992-12-22 | 6.8 KB

Xref: sparky comp.unix.bsd:10523 comp.os.linux:21320
Path: sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
From: [e-mail] (InterNet News)
Newsgroups: comp.unix.bsd,comp.os.linux
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Date: 21 Dec 1992 17:30:44 -0600
Organization: Armstrong Lab MIS, Brooks AFB TX
Lines: 121
Message-ID: <[e-mail]>
References: <agp22+#@rpi.edu> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: hrd769.brooks.af.mil

In article <[e-mail]> [e-mail] (david carlton) writes:
>In article <[e-mail]>, [e-mail] (InterNet News) writes:
>
>> So, I have a suggestion.  Change someone.  If you think
>> internationalization is a snap, try it.  Get convinced that it is
>> hard to retrofit, but relatively simple to design for and proceed
>> from there.
>
>I don't believe you.  I could believe that doing it badly (well enough
>to handle most European languages, say) is easy, but I think doing it
>well takes a lot of work.  You have to deal with different character
>sets, ways of text entry, direction of text, mixing scripts,
>connection rules, and so forth; some of these are not difficult
>problems, perhaps, but a lot of them are.

  You don't believe that we did it, or that it is easier to design for
ahead of time than try to retrofit it?

  True enough.  The implementation of a small set of these is a nontrivial
set of programming units.  On the other hand, you only need to do it once.
If you adopt a paradigm that says "Any narrative text in my programs will
use functions loaded at run-time for proper display" will solve your
initial design problem, in that the actual decision is to wait until it
is time to actually do it.

  As a made up example, let's assume we are running a program that displays
the status of an assembly line.  There are three states for the line: "OK"
"Plugged" and "Restarting".  A possible design decision could be to call a
routine that will display, in the proper color and orientation, that string
in whatever language the client wants.  This way, you leave the stub there
for each of the states, but don't actually have to implement it until you
have a valid need.

  As the program units get more interactive, the processes become harder.
They still only need to be written once.  If I wrote a routine that displayed
an arbitrary string on the screen, it could take display space and orientation
into account.  At this point, I don't really care what the characters were,
since I am leaving the final implementation to the last phase.

  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.

>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.

>read ahead in the input stream before figuring out what to put on the
>screen (crummy for interactive input), or deal with the fact that what
>you have put on the screen is going to change even when the user keeps
>on typing without deleting (bad, because it makes the characters on
>the screen jump around a lot.)

  You are correct; it is not going to be easy the first time.  From then on,
it should be a relative snap.  Isn't that what OOP is about?  The
implementation of this type of thing will exist, once created, and reusable
if it is designed for the larger concept of internationalization.

>Doing any sort of decent solution will
>take a lot of extra coding, require a lot of research to figure out
>what the problems are and what sort of solution people prefer, require
>care not to lead to bloated programs (if you care), and is not what I
>would call "relatively simple".
>

  You are correct, in that trying to solve all of these problems at the
same time is a gargantuan task.  Each one, however, is much simpler to
solve one at a time, and will only have to be solved once.
  BTW, yes I DO care about bloated programs.  That is why an elegant,
reusable solution is the goal.  I haven't written this mythical piece of
code yet, but I expect it is around the corner.


>Perhaps I'm missing something, though - would you care to share with
>us your methods for designing for internationalization?
>

  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.


>david carlton
>[e-mail]
>

  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