home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / internat / 1001 < prev    next >
Encoding:
Internet Message Format  |  1993-01-03  |  4.6 KB

  1. Path: sparky!uunet!paladin.american.edu!gatech!pitt.edu!djbpitt
  2. From: djbpitt+@pitt.edu (David J Birnbaum)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Language tagging
  5. Message-ID: <1336@blue.cis.pitt.edu>
  6. Date: 3 Jan 93 15:53:29 GMT
  7. References: <1993Jan2.020512.3287@klaava.Helsinki.FI> <1321@blue.cis.pitt.edu> <1993Jan2.231703.21201@enea.se>
  8. Sender: news+@pitt.edu
  9. Organization: University of Pittsburgh
  10. Lines: 78
  11.  
  12. >>In both cases, if you want language-specific data in your text stream,
  13. >>you have to say so during input. If I need to insert Bulgarian words
  14. >>into a Russian text stream I can do so without indicating a change,
  15. >>as long as I understand that the consequence will be that the Bulgarian
  16. >>data will be treated like Russian.
  17. >
  18. >Then I have to ask you explain something about Unicode I don't
  19. >know. It is true that if you are using language-dependent features
  20. >such as spell-checking and hyphenation, while inputting the text,
  21. >then you have to know what you are doing with Unicode. But once
  22. >you're done with it, it doesn't matter any longer, until the next 
  23. >time you want to process the text in some way. With Unicode you
  24. >can decide whether to treat the text in Bulgarian or Russian,
  25. >with Vadim's system you're stuck unless you convert it.
  26.  
  27. It is true that Vadim's character set always carries language
  28. information along with it, while bare Unicode does not. A Unicode based
  29. system, though, will require more than the bare character set (which is
  30. why I refer to it as a "Unicode-based system," rather than simply as
  31. "Unicode"). 
  32.  
  33. There are two sets of problems: information that can (and must, if it is
  34. to be present at all) be entered during input and information that
  35. cannot be foreseen until subsequent processing is to be performed (and
  36. that, therefore, cannot be entered during input).
  37.  
  38. Concerning the former, I would normally require that my texts include
  39. language identification, so that the same "this is Bulgarian" or "this
  40. is Russian" information would be present in both a Unicode-based system
  41. and Vadim's system, although it would not be an inalienable part of the
  42. character set in the former. Thus, I would be "stuck with" language
  43. information under both systems. While Unicode is capable of
  44. representing text without language information (by eschewing the use of
  45. tags), I can't think of a situation where I would want to do so. I can
  46. always ignore the tags if they are an impediment to some later
  47. processing, but I can't restore them automatically if they haven't been
  48. encoded at all.  Thus, I don't think the ability of Unicode to
  49. represent text without language information is either a virtue or a
  50. liability; it isn't a virtue because text normally _is_ in a specific
  51. language (although I can construct perverse exceptions) and it isn't a
  52. liability because that information can be encoded on a different level.
  53. If, under your proposal, the "Russian" or "Bulgarian" tag can be
  54. disgarded after input, how can a subsequent user process a multilingual
  55. text that has to distinguish Bulgarian from Russian information? I agree
  56. with Vadim that this information should travel with the text, but I
  57. disagree with his insistence that it must be part of the character
  58. encoding architecture itself.
  59.  
  60. Concerning the latter, as has been indicated by others on this list,
  61. processing depends on factors other than the language of input, such as
  62. locale (defined more narrowly than language) or, more specifically, the
  63. processor's locale (which is not necessarily the same as the locale in
  64. which the text was entered). Thus, Vadim's proposal to store some
  65. information needed for processing as part of the character set will not
  66. obviate the need to provide additional information, information that
  67. must reside not only outside the character set, but outside the text
  68. stream. Under either Vadim's proposal or the type of Unicode-based
  69. system with language tags that I suggest, a mechanism will be needed to
  70. distinguish information that is an inherent and inalienable part of the
  71. text independent of locale from information that is at least partially
  72. determined by locale. We can't wish away this complication.
  73.  
  74. >But at least
  75. >shifting scripts is a more obvious, than changing languages. If I
  76. >switch from Swedish to Russian I would probably change the keyboard
  77. >set-up, but not if I switch from Swedish to German - there is no
  78. >reason to.
  79.  
  80. Script, language, and keyboard may be independent, although certain
  81. combinations are more common than others.
  82.  
  83. --David
  84.  
  85. -- 
  86. Professor David J. Birnbaum         djbpitt+@pitt.edu [Internet]
  87. The Royal York Apartments, #802     djbpitt@pittvms   [Bitnet]
  88. 3955 Bigelow Boulevard              voice: 1-412-687-4653
  89. Pittsburgh, PA  15213  USA          fax:   1-412-624-9714
  90.