Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5399 ; Wed, 23 Dec 92 21:00:15 EST Xref: sserve comp.unix.bsd:9276 comp.os.linux:20147 Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail From: news@hrd769.brooks.af.mil (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: <1h5k34INN88g@hrd769.brooks.af.mil> References: <agp22+#@rpi.edu> <1gvpt0INN8s0@hrd769.brooks.af.mil> <CARLTON.92Dec21163013@scws8.harvard.edu> NNTP-Posting-Host: hrd769.brooks.af.mil In article <CARLTON.92Dec21163013@scws8.harvard.edu> carlton@scws8.harvard.edu (david carlton) writes: >In article <1gvpt0INN8s0@hrd769.brooks.af.mil>, news@hrd769.brooks.af.mil (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 >carlton@husc.harvard.edu > 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