From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA11121 for caml-redistribution; Fri, 29 Oct 1999 19:04:58 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA18712 for ; Fri, 29 Oct 1999 04:02:54 +0200 (MET DST) Received: from ruby (pm1-20.triode.net.au [203.63.235.36]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id EAA20193 for ; Fri, 29 Oct 1999 04:02:48 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by ruby (8.9.3/8.9.3) with ESMTP id OAA05793; Fri, 29 Oct 1999 14:29:14 +1000 Sender: weis Message-ID: <3819229A.4C8A37FC@maxtal.com.au> Date: Fri, 29 Oct 1999 14:29:14 +1000 From: skaller Organization: Maxtal X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Deboursetty CC: caml-list@inria.fr Subject: Re: Go for ultimate localization! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Benoit Deboursetty wrote: >> > At least, there is a certain consistency in C allowing only > English characters: were I in a normalization committee, I would even > demand, in the C norm, that a compliant source code has everything, > identifiers and comments, in American English (you must be hoping I will > never be given such power). FYI: as it happens, I _am_ in the C standardisation committee, and the latest version of C, code named 'C9X', which has now passed the final NB balloting, as well as C++, which is already an International Standard, permits a certain subset of ISO10646 in identifiers. All the characters are in the first (unicode) plane. [The actual subset is listed in Appendix E of the C++ Standard] However, neither permits any variations on keywords :-) > In other words, localizing error messages, charsets is fine: also > *localizing the parser* seems more consistent to me. I have no opinion on the idea of allowing _alternate_ keywords, or even syntax, more amenable to international use. However, I would like to be 'pedantic' and object to the word 'localisation'. I would STRONGLY object to localising ANY aspect of the ocaml language, and this is one of my reasons for objecting to the current Latin-1 support. I advocate _internationalisation_, not localisation, that is: all the possible characters, grammar extensions, new keywords, or what ever, are universally available to everyone. On the other hand, I _would_ support localisation of diagnostic error messages and documentation: that is, if you speak French, you get errors in French. > Of course, this > raises again the issue I was speaking of in my previous post: using > languages different from the "computer esperanto" in computer programs > would probably block international exchanges I am not at all sure about that. Have you considered it might _facilitate_ international exchange? For example, Japanese programmer able to use Japanese extensively in a programming language might now be free to release it internationally, without feeling bound to 'Anglicize' it. This would make it harder for non-Japanese speakers to understand than Japanese speaker -- but 'harder' is better than 'impossible because the program was never publically released'. I personally feel embarrassed that I can't follow dialog in French, reading this group. But that is surely MY problem, and I am grateful so many French can read and write MY native language (English with an Ozzie accent :) fluently. > every French computer > scientist sounds really suspect to a non-scientific person when he speaks > of "strings" all the time. The same with "bit". It's also because of > things like that, that computer people are sometimes thought of they > can't communicate. Now, that cannot be the reason -- because it doesn't explain why the same is thought of English speaking computer nerds. :-) > [ "un string" is only an underwear in French. And there is a > very unfortunate collision between the English word "bit" and another > word. ] The mind boggles. An anecdote from the C++ Standardisation process: when a new feature of the C++ library was being developed, which provided 'auxilliary' information, it was originally called 'baggage'. The name was changed to 'traits'. I was one of the people who said that 'baggage' has unfortunate connotations in Australia (at least), refering to a sexually promiscuous woman in derogatory masculine slang. > Of course, such an extension won't probably be used in business as > long as everybody speaks English at work in almost every software > development group anyway. I am surprised: is this really the case in France, for example? It is not in Japan (perhaps the language is more alien?) > All this may be very difficult to implement, I don't know, I am > telling things from the user's point of view. I do not think the difficulty of implementation is any more than a minor issue. The major issue, surely, is, that: at least in most programming languages, _something_ is universal, even if the keywords tend to be derived from English. If too many alternative ways of doing the same thing are available, we may end up with a mish mash language (sort of like English itself :-) -- John Skaller, mailto:skaller@maxtal.com.au 1/10 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller downloads: http://www.triode.net.au/~skaller