home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / bsd / 10569 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  4.0 KB

  1. Xref: sparky comp.unix.bsd:10569 comp.os.linux:21455
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!kuhub.cc.ukans.edu!husc-news.harvard.edu!husc-news!carlton
  3. Newsgroups: comp.unix.bsd,comp.os.linux
  4. Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Message-ID: <CARLTON.92Dec22164619@scws8.harvard.edu>
  6. From: carlton@scws8.harvard.edu (david carlton)
  7. Date: 22 Dec 92 16:46:19
  8. References: <agp22+#@rpi.edu> <1gvpt0INN8s0@hrd769.brooks.af.mil> <CARLTON.92Dec21163013@scws8.harvard.edu> <1h5k34INN88g@hrd769.brooks.af.mil>
  9. Organization: Citizens for Boysenberry Jam
  10. Nntp-Posting-Host: scws8.harvard.edu
  11. In-reply-to: news@hrd769.brooks.af.mil's message of 21 Dec 92 23:30:44 GMT
  12. Idol: Herbert Gro"nemeyer
  13. Lines: 66
  14.  
  15. In article <1h5k34INN88g@hrd769.brooks.af.mil>, news@hrd769.brooks.af.mil (InterNet News) writes:
  16. > In article <CARLTON.92Dec21163013@scws8.harvard.edu> carlton@scws8.harvard.edu (david carlton) writes:
  17. >> In article <1gvpt0INN8s0@hrd769.brooks.af.mil>, news@hrd769.brooks.af.mil (InterNet News) writes:
  18.  
  19. >>> So, I have a suggestion.  Change someone.  If you think
  20. >>> internationalization is a snap, try it.  Get convinced that it is
  21. >>> hard to retrofit, but relatively simple to design for and proceed
  22. >>> from there.
  23.  
  24. >> I don't believe you.  I could believe that doing it badly (well
  25. >> enough to handle most European languages, say) is easy, but I think
  26. >> doing it well takes a lot of work.  You have to deal with different
  27. >> character sets, ways of text entry, direction of text, mixing
  28. >> scripts, connection rules, and so forth; some of these are not
  29. >> difficult problems, perhaps, but a lot of them are.
  30.  
  31. > You don't believe that we did it, or that it is easier to design
  32. > for ahead of time than try to retrofit it?
  33.  
  34. I don't believe that it's relatively simple to design for.
  35.  
  36. >> For example, if you want to type something in the Nagari script,
  37. >> hardly an uncommon script, you will either have to have an overly
  38. >> complicated and artificial method of entering text (bad - this puts
  39. >> unnecessary burden on the user),
  40.  
  41. > We need a Nagari input device; the 101 key keyboard is hardly the
  42. > correct vehicle for this type of processing.  Is the fact that a
  43. > good Nagari input device does not exist because American engineers
  44. > are stupid?  I don't think so.
  45.  
  46. Of course the actual keycaps on the 101 key keyboard are wrong for
  47. Nagari, but there are more serious problems than that.  For example,
  48. the combination of the three letters "tsa" (with no space between
  49. them) looks different than the combination of the three letters "t s
  50. a" with spaces between them.  So no matter what sort of input device
  51. you use, you either have to force the user to explicitly specify when
  52. typing a "t" whether it is followed by a space, by another consonant,
  53. by a vowel, etc., or deal with the fact that you won't (usually) have
  54. enough information to display a letter properly when the user types
  55. it.  Maybe it's more of a matter of my biases than anything else (I
  56. grew up using the Roman alphabet, and this may affect my opinion that
  57. the natural way to input text in Sanskrit, say, is to input it a
  58. letter at a time instead of a syllable at a time), but I think the
  59. problem is deeper than the input devices.
  60.  
  61. >> read ahead in the input stream before figuring out what to put on
  62. >> the screen (crummy for interactive input), or deal with the fact
  63. >> that what you have put on the screen is going to change even when
  64. >> the user keeps on typing without deleting (bad, because it makes
  65. >> the characters on the screen jump around a lot.)
  66.  
  67. > You are correct; it is not going to be easy the first time.  From
  68. > then on, it should be a relative snap.
  69.  
  70. If you do it right the first time, if you manage to hit upon a
  71. solution that is easy for both the user and the programmer.  But
  72. getting to that stage may take a long time, months or years.
  73.  
  74. I do agree that it's a lot simpler if you stick to output-only
  75. programs that don't depend on the layout of their output.
  76.  
  77. david carlton
  78. carlton@husc.harvard.edu
  79.  
  80.        HUMAN REPLICAS are inserted into VATS of NUTRITIONAL YEAST...
  81.