From keld@dkuug.dk Sat Dec 29 15:21:34 1990 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA23040; Sat, 29 Dec 90 15:21:34 +0100 Date: Sat, 29 Dec 90 15:21:34 +0100 From: Keld J|rn Simonsen Message-Id: <9012291421.AA23040@dkuug.dk> To: wg15rin@dkuug.dk Subject: Re: specific locales X-Charset: ASCII X-Char-Esc: 29 I am reposting this to wg15rin as the original posting was only sent to uniforum-intl. Keld --- Subject: RE: specific locales (i18n 56 = # 459) (#462) On Thu Dec 27, 1990 1:43 pm EST, keld@dkuug.dk said: > Subject: (i18n 56) specific locales (#459) > ... > > There has been a discussion on the uniforum-intl list about locales, > which I now am continuing on the i18n list, as it is very relevant to > the work of WG15 RIN. > > The original statement as I understood it was that we should not > standardize locales, that is the data in locales, but it was OK to > standardize the language for it. That's correct: standardizing the locales is a bad idea for Uniforum, X/Open, and IEEE P1003 committees, per se. > > I am active in three aspects here. > > 1. I am collecting example locales and making them available by anon ftp > ... > This is in accordance with an item of the approved programme of > work for WG15 RIN. This is valuable work: as I said the original intent was that locales would be posted! Terrific! > > 2. I have been involved in producing the example Danish National > profile and locale on behalf of the Danish member body of ISO (DS). > ... [This] work is, of course, [designed to convert] this locale > into a formal Danish standard. > Bingo! Beautiful! National ISO bodies, such as your Danish (work), are tasked with standardizing locales; that's why I said X/Open, Uniforum, and IEEE P1003 should leave this work alone. Now it's realistic that X/Open (for example) may have pointer references to standard locales, such as the end-result of your Danish work, but the data itself falls solely under the Danish ISO's purview. > 3. I am a member of ISO/IEC JTC1/SC22/WG14 for the C language, > and WG14 has asked me to propose a "C" locale which is more > intelligent than the current C locale. I have done some work on this. > > I am not sure if the original poster was hinting at some of this work, > and which he thought should not be carried out. I was not aware of this work, nor do I know what WG14's extra needs are. Personally, I am most dissatisfied with P1003.2's i18n work, particularly on the locales: that's why I wrote so many Ballot Objections and why I will not change my vote. > ... I see that there > might be problems with the "enhanced C locale" - defining concrete > data for that, but that has already been done with the C and POSIX > locales. > > I think the enhanced C locale is very convenient to fulfill the project > that WG14 has been mandated to do by SC22 on solving "character set issues". > > I would like comments on how this could be carried out most conveniently. Keld Thanks ever so much for posting this information, and thank you for taking the trouble to make the aforementioned locales available via the "airwaves". I think that's terrific! = Bob Makowski Please post, or re-post, what WG14's needs are. I can't comment until then. Please note, however, today I'm posting a response to greger's P1003.2 "strawman" (26 Nov) proposal: I have plenty to say about that! Also, I published my P1003.2 D9 objections at the Summit Uniforum. I want to compare what's there with WG14. INTERNET: Bob_Makowski@MCIMail.com VOICE: 1-714-476-6936 (24hour - messages) USnail: 2796 Harbor #141, Costa Mesa, CA. 92626