home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1076 < prev    next >
Encoding:
Text File  |  1993-01-07  |  4.9 KB  |  108 lines
  1. Newsgroups: comp.std.internat
  2. Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Message-ID: <1993Jan7.065611.15193@fcom.cc.utah.edu>
  6. Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
  7. Sender: news@fcom.cc.utah.edu
  8. Organization: Weber State University  (Ogden, UT)
  9. References: <1i0s05INNnfn@rodan.UU.NET> <1993Jan1.114158.17149@prl.dec.com> <1i2emiINN2td@rodan.UU.NET>
  10. Date: Thu, 7 Jan 93 06:56:11 GMT
  11. Lines: 95
  12.  
  13. In article <1i2emiINN2td@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
  14. >In article <1993Jan1.114158.17149@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:
  15. >>In article <1i0s05INNnfn@rodan.UU.NET>, avg@rodan.UU.NET (Vadim Antonov) writes:
  16. >>> 
  17. >>> A good encoding should support easy (i'd say natural) localization.
  18. >>> It should provide simple algorithms for simple functions
  19. >>> like getting string length, searching a character, case-insensitive
  20. >>> comparison, lexicographical comparison.
  21. >>> 
  22. >>
  23. >>Well that's where you're wrong.  The characters and how they are used
  24. >>are distinct problems.
  25. >
  26. >Don't you realize that having trivial programs to ask which language
  27. >they're doing operation in effectively defeats the entire purpose of
  28. >Unicode?
  29.  
  30. This is not directly required (nor desirable) given the standard tools
  31. for locale specification.  It does not follow as an inevitable conclusion
  32. of Boyd's statement.
  33.  
  34. >Should my shell ask me about language of every [a-z] in my commands?
  35.  
  36. No, the shell should be localized to the users language preference, as should
  37. the commands.
  38.  
  39. >If it shouldn't then it has to get the information somewhere, right?
  40.  
  41. Right.
  42.  
  43. >If the information is kept outside the text (file names in this case)
  44. >then why do i need all those extra bits -- my program *already* knows the exact
  45. >(small) alphabet.
  46.  
  47. Good question.  Answer:  Because it reduces the set of functions required
  48. to process each language.  There is not a single function per language
  49. for text manipulation.  It simplifies the interface to do file manipulation
  50. based on text, and it allows for relatively somple localization of any
  51. application.  In addition, it provides a basis for multilingual processing;
  52. you can either do this however you choose to, or wait for followon standards,
  53. or use existing standards which don't conflict with the basic Unicode
  54. concept.
  55.  
  56. I wouldn't place the information in the file name itself, however; this has
  57. the unfortunate effect of needing to attribute a character to a particular
  58. language -- this assumption that the file name could hold the information
  59. is not valid for Unicode (as you have so frequently pointed out).  Much
  60. better to either embed information in the data (for a multilingual file)
  61. or in the file attributes within the file system (for a monolingual file).
  62.  
  63. >"Unicode -- a code for texts which will never be sorted!" Great.
  64.  
  65. As I (and nearly everyone else in this forum) pointed out in a prior
  66. article, the argument that sorting is associated with lexical order fails
  67. even under your assumption of a character set per language/locale because
  68. of the existance of multiple sort orders per locale.  If the information
  69. must be maintained externaly to the data for such languages, why not for
  70. all languages?
  71.  
  72. >>Problem 2 (localisation) is damn hard.
  73. >
  74. >Tell me. I've spent ten years doing *real* localization and i know
  75. >the price of ill-thought solutions on the ground level (aka character
  76. >set ordering).
  77.  
  78. Again, sorting can not be safely tied to character set lexical order for
  79. all languages.  I disagree with Boyd here.  Localization with Unicode is
  80. a piece of cake.  Unicode allows it to be entirely data driven, with no
  81. locale-specific algorithms or hard-coded data.
  82.  
  83. >>Should Problem 1 cater for the fact I type `localisation' whereas
  84. >>you type `localization'?  We're both using Engligh, typed on American
  85. >>keyboards (I guess, oops mine's made in West Germany) so where are you
  86. >>going to draw the line.  Is this Problem 1?  I say it's Problem 2.
  87. >
  88. >The example is artificial and has nothing to do with the character sets.
  89. >As you well aware it is different words in the same alphabet.
  90.  
  91. This example becomes more of a problem when translated to one of a glyph
  92. variant between Chinese and Japanese.  I agree that the problem is one
  93. of words, not characters -- however, in ideographic languages, words *are*
  94. characters.  The example is not as artificial as you make out.
  95.  
  96.  
  97.                     Terry Lambert
  98.                     terry@icarus.weber.edu
  99.                     terry_lambert@novell.com
  100. ---
  101. Any opinions in this posting are my own and not those of my present
  102. or previous employers.
  103. -- 
  104. -------------------------------------------------------------------------------
  105.                                         "I have an 8 user poetic license" - me
  106.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  107. -------------------------------------------------------------------------------
  108.