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

  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!att!allegra!alice!andrew
  2. From: andrew@alice.att.com (Andrew Hume)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Message-ID: <24540@alice.att.com>
  6. Date: 3 Jan 93 06:26:22 GMT
  7. Article-I.D.: alice.24540
  8. References: <1993Jan1.115424.27258@enea.se> <1i2gpvINN3lm@rodan.UU.NET> <8504@charon.cwi.nl>
  9. Organization: AT&T Bell Laboratories, Murray Hill NJ
  10. Lines: 69
  11.  
  12. In article <8504@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
  13. ~ In article <1993Jan2.230101.20871@enea.se> sommar@enea.se (Erland Sommarskog) writes:
  14. ~  > The problem with your idea is that you believe that everything is
  15. ~  > known at input time. It isn't. If you have a list of names which 
  16. ~  > is to be used in Sweden, Norway, Denmark and Finland, the list will
  17. ~  > sort differently depending on the reader, not on who is entering the 
  18. ~  > text. The Swedish and Finnish alphabets ends with A-ring, A-dots,
  19. ~  > O-dots. The Danish and Norwegian ends with AE-ligature, O-slash,
  20. ~  > A-ring. Looks trivial for a simple bit-order sort? Nope. Because
  21. ~  > the dotted A is equivlent to the AE ligature and so is dotted O and
  22. ~  > O-slash. Thus Danish and Norwegian names with slashed O should
  23. ~  > appear together with Swedish and Finnish names with dotted O. So
  24. ~  > the sort algorithm must make no distinction between the two, except
  25. ~  > when everything else in the same. And the sort algorithm must know
  26. ~  > in which order the user wants the text to be presented.
  27. ~ Not to mention that the Danish/Norwegian 'aa' is sometimes equivalent
  28. ~ to 'a-ring'.
  29. ~  > 
  30. ~  > This is a simple end-user requirement which your proposal is not
  31. ~  > incapabale to handle.
  32. ~ I think you intended to say that Vadims proposal is not capable to
  33. ~ handle it (I agree with that).
  34.  
  35.     vadim is capable of defending himself, but this last statement
  36. is simply wrong. in vadim's scheme, you simply have extra information
  37. over a normal unicode stream. in the worse case, or at least
  38. a complicated one, you fall back and do a complicated compare function
  39. (like unicode has to do all the time). what vadim's point is, i think,
  40. that for rudimentary sorting, using nonoverlapping encodings based on
  41. languages gives you a good answer for (almost) free. he is not saying
  42. this rudimentary sort meets every need (although he did argue for
  43. dropping fancy sorting together of names etc).
  44.  
  45. ~  > >which is not easy and sometimes ruins the whole logic of the
  46. ~  > >program (see shell globbing example in my previous posting os
  47. ~  > >tr example before).
  48. ~  > 
  49. ~  > You've talked a lot about regular expressions etc. Frankly I
  50. ~  > don't give a damn about those. The main bulk of computer users
  51. ~  > are not programmers and don't know what a regular expression
  52. ~  > is, so why focus such specific issues?
  53. ~ I agree completely here.  Shell globbing, regular expressions and
  54. ~ sorting by 'ls' are not relevant.  (There are still systems around
  55. ~ that do not sort the list of files at all.  Can you say IBM VM/CS?)
  56. ~ Those things are indeed used by programmers only, end-users search
  57. ~ on fixed strings and would be surprised if their dotted-a shows no
  58. ~ match because of language differences.
  59.  
  60.     i think this is wrong, too. almost all systems offer some
  61. facilities and applications that present sorted data, mainly
  62. filenames. many applications also offer some form of pattern matching,
  63. even if it is just some simple wildcard matching. it is important
  64. that the sorting rules be comprehensible and (echoing vadim here)
  65. SIMPLE. this is relevant. whether or not vadim's scheme adequately addresses
  66. this is a factual and technical question, and implies a technical
  67. (non-hysterical nor name-calling) reply.
  68.  
  69.     just to show my impartiality, i think a weakness of vadim's
  70. scheme is the difficulty of distinguishing the different characters to
  71. the user. for vadim's example of cyrillic and english, that is not a problem
  72. as teh cyrillic and latin fonts are easily distinguishable. but what about
  73. text which has french/german/italian/english mixed together? or as erland
  74. pointed out, text with a bunch of scandanavian languages mixed together?
  75. being able to have several almost identical but distinguishable fonts
  76. on the screen at once is a fairly difficult task (although not
  77. very difficult).
  78.  
  79.         andrew hume
  80.