home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / bsd / 10916 < prev    next >
Encoding:
Text File  |  1993-01-05  |  5.0 KB  |  118 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!caen!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: INTERNATIONALIZATION: JAPAN, FAR EAST
  5. Message-ID: <1993Jan5.093059.29631@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: Weber State University  (Ogden, UT)
  8. References: <2565@titccy.cc.titech.ac.jp> <1992Dec28.064029.24421@fcom.cc.utah.edu> <2616@titccy.cc.titech.ac.jp>
  9. Date: Tue, 5 Jan 93 09:30:59 GMT
  10. Lines: 106
  11.  
  12. In article <2616@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
  13. >In article <1992Dec28.064029.24421@fcom.cc.utah.edu>
  14. >    terry@cs.weber.edu (A Wizard of Earth C) writes:
  15. >
  16. >>|> True. But, it should be noted that they don't fit even in 16 bits.
  17. >>
  18. >>Work is already under way to adapt Unicode to 32 bits.  I would be interested
  19. >>in any similar work you know of in progress for XPG4/JIS.
  20. >
  21. >Anyway, a program written for 16 bit Unicode can not be usable with 32 bit
  22. >Unicode.
  23.  
  24. Not true.  Attribution of files/users/compound data within the files/etc.
  25. allows easy identification of version changes.
  26.  
  27. >>I am *not*
  28. >>interested in proposing or attempting to provide yet another standard, if
  29. >>that is what you believe is necessary.
  30. >
  31. >Then, why you are interested in using yet non-existent standard?
  32.  
  33. Unicode has been codified.  It exists:
  34.  
  35.     The Unicode Standard
  36.     Worldwide Character Encoding
  37.     Version 1.0, Volume 1
  38.     _The Unicode Consortium_
  39.     Addison-Wesley Publishing Company, Inc.
  40.     ISBN 0-201-56788-1
  41.  
  42.     The Unicode Standard
  43.     Worldwide Character Encoding
  44.     Version 1.0, Volume 2
  45.     _The Unicode Consortium_
  46.     Addison-Wesley Publishing Company, Inc.
  47.     ISBN 0-201-60845-6
  48.  
  49. >BTW, can you explain what XPG4 is?
  50.  
  51. The internationalization mechanism following XPG3, the SVR4.2 standard for
  52. internationalization.  XPG4 is XPG3 with East Asian language support.
  53. Standards documents are currently avilable, but a reference implementation
  54. (to the best of my knowledge) is not.  I can look up and post the
  55. publication information if you are truly interested.
  56.  
  57.  
  58. >>Again, I want to stress that we are about the identification and adoption
  59. >>of an existing standard rather than the specification and ratification of
  60. >>a new one.
  61. >
  62. >Then, the only standard available now for internationalization is ISO 2022.
  63. >
  64. >It can, at least, differentiate Chinese and Japanese character.
  65. >
  66. >Do you want to use it?
  67.  
  68. ISO 2022 places the unacceptable burden of Runic encoding for monolingual
  69. environments (post localization).  While is is an "OK" standard for
  70. internationalization (multinationalization, really, since it deals with the
  71. concept of multilingual documents directly), the penalties of a change in
  72. apparent environment for the purely localized user are unacceptable, since
  73. the purely localized user is the majority case.
  74.  
  75. The differentiation of Chinese and Japanese characters is the job of the
  76. input mechanism, which would, in any case, be required to change between
  77. the job of inputting Chinese and the job of inputing Japanese.  This switch
  78. is an acceptable tagging mechanism for multilingual use.  Tagging for
  79. monolingual use can be done on a per-system or per-user basis, since it
  80. is unlikely that all localaization databases for each language (message
  81. catalogs, etc) will be kept around.  As an English-speaker only
  82. (hypothetically speaking, since I can get along in Japanese, German, Latin,
  83. and Spanish and have a very little Greek, Gaelic, French and Swahili on the
  84. side), I am unlikely to localize my machine to anything other than English,
  85. and the only thing served by carrying around localization sets for 20 other
  86. languages is my disk drive vendor.
  87.  
  88. The primary use for an interntaionalization mechanism will be localization;
  89. anything on top of that (and yes, we can build multilingual applications
  90. on top of that with little effort) is gravy.
  91.  
  92. >>We may invoke "tricks" to reduce storage requirements or to
  93. >>retrofit existing input mechanisms, but we are not attempting a new standard.
  94. >
  95. >Again, existing input mechanism for Japanese is so large that even very
  96. >complex tranlation does not affect its performance.
  97.  
  98. All the more reason to not quibble about storage mechanisms and get down to
  99. the job of coding a reference implementation.  Unicode is a storage mechansim;
  100. it does *not* disctate the display font any more than a plain text file
  101. dictates the default Postscript font that will be used when you type "lpr".
  102. Both input and display are functions of the localization (or
  103. multinationalization) mechanisms we choose to employ on top of the storage
  104. mechanism.
  105.  
  106.  
  107.                     Terry Lambert
  108.                     terry@icarus.weber.edu
  109.                     terry_lambert@novell.com
  110. ---
  111. Any opinions in this posting are my own and not those of my present
  112. or previous employers.
  113. -- 
  114. -------------------------------------------------------------------------------
  115.                                         "I have an 8 user poetic license" - me
  116.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  117. -------------------------------------------------------------------------------
  118.