Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!paperboy!macrakis From: macrakis@gr.osf.org (Stavros Macrakis) Newsgroups: comp.std.internat Subject: Re: Reneging on promises (Internationalization) Message-ID: Date: 7 Jan 91 09:06:09 GMT References: <472@eiffel.UUCP> <2347@enea.se> Sender: news@OSF.ORG Followup-To: comp.std.internat Organization: OSF Research Institute--Grenoble Lines: 36 In-reply-to: amanda@iesd.auc.dk's message of 5 Jan 91 22:33:11 GMT In article amanda@iesd.auc.dk (Per Abrahamsen) writes: A new standard (ISO Latin1) has been created, which conforms to the ASCII standard, and is quickly being accepted. The best thing to do might be to ignore ISO 646, and switch to ISO Latin1 as fast as possible. I agree that ASCII is the de facto standard, and that it is unrealistic to expect existing 7-bit ASCII programs to be updated to ISO 646. However, beware! Latin1 does NOT cover all Latin-alphabet languages, only western European ones (and excludes a couple of minor cases like French oe and Dutch ij). For instance, it is missing (Polish) barred-l, (Czech) hacek-r, (Turkish) hacek-g, (Croatian) barred-d, (Dutch) ij, (French) oe, (Romanian) t-cedilla, and (Chinese pinyin) o-hacek. And of course it does not cover other alphabets (Greek, Cyrillic, Arabic, Hebrew, etc.), much less Chinese characters. I do not think it appropriate to make a quick patch for Western European languages which will have to be changed soon thereafter for other languages. It <> seem appropriate though to insist that all string-handling primitives be able to handle <> 8-bit characters. Although it would be nice as well to permit string literals with (say) Latin-1, I am now not convinced it is a good idea. Natural-language literal strings should always be separated from the program to allow for later localization (translation of messages etc.). And let's hope that the transition to 16-bit characters will not be too painful when it comes. -s