home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0009.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  2.0 KB
  1. From: Donn Terry <uunet!hpfcrn.fc.hp.com!donn>
  2.  
  3. >From: randall@uvaarpa.virginia.edu (Randall Atkinson)
  4.  
  5. >As one who is fairly active in the multilingual computing
  6. >side of things, I'm fairly certain that it just isn't worth
  7. >it to try to make ISO 646 the basis of *anything* for the
  8. >practical reason that it wasn't well thought out to begin with
  9. >and has already been superceded by the ISO 8859/* family of
  10. >8-bit character sets.
  11.  
  12. Agreed.  I believe that the Danes and other Europeans will agree, too.
  13.  
  14. ...
  15.  
  16. >I thought that trigraphs got excessive attention back when ANSI C
  17. >was being developed and I fear that excessive attention will be
  18. >devoted to ISO 646 when there are other areas of internationalisation
  19. >that really deserve being thought about and solved cleanly.
  20.  
  21. Yup.... but it's also a real problem.
  22.  
  23. >Most of the vendors of hardware in Europe are supporting ISO 8859/1
  24. >now, so it is the real long term solution to European needs anyway.
  25. >Worrying about support for ISO 646 is a mistake, worrying about
  26. >supporting ISO 8859/* and the Asian need for larger character sets 
  27. >being fully supported and ways of handling date formats and such
  28. >aren't a mistake at all.
  29.  
  30. The problem is that reality impinges on the ideal world.  In particular
  31. there are LOTS of 646 terminals out there.  And, as the European
  32. participants note, they aren't going to get replaced with 8859 ones
  33. for on the order of 10 years.  (646 also is still a lowest common
  34. denominator: as I understand it, sendmail can't handle 8-bit (if
  35. I'm wrong, I apologize, but you get my point)).
  36.  
  37. Thus, there is a real problem to be solved here.  I personally lean toward
  38. some sort of many-to-one and one-to-many translation at the terminal
  39. interface, but that doesn't always appear successful.  Add to it the
  40. problem of not knowing whether the user is an expert or not.  (The
  41. expert can handle | being slashed-o, but the ordinary terminal operator
  42. probably can't.)
  43.  
  44. Donn Terry
  45. (No position is official, but as U.S. Rapporteur for SC22/WG15/IRG I'm
  46. at least plugged in.)
  47.  
  48. Volume-Number: Volume 19, Number 10
  49.  
  50.