Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!aussie!rex From: rex@aussie.COM (Rex Jaeschke) Newsgroups: comp.std.c Subject: Re: Localization (4.4.2.1) Message-ID: <54.UUL1.3#5077@aussie.COM> Date: 16 Feb 91 19:30:58 GMT References: Organization: Journal of C Language Translation Lines: 72 > Sender: enag@ifi.uio.no (Erik Naggum) > > This concerns the ANSI C standard. The localeconv function has some > examples on page 111. I'm concerned with the specific entry on line 4 > of that page. It says something about Norway. I live in Norway. ... First, to the importance of this: The part of the standard document you cite is in an example. EXAMPLES ARE NOT PART OF THE STANDARD. If an example (or footnote or anything in the Rationale) contradicts something in the standard proper, the standard proper wins. If nothing is said in the standard proper, the example (etc) is simply a possible guideline/tutorial which, as you appear to believe, is incorrect or, at least, out of date. So, from a validation aspect, `It doesn't matter.' If, however, you are correct, it should be fixed. Derek Jones of the UK is the Project Editor for the Normative Adendum being produced by ISO C WG14. I shall bring this to his attention to see if it can be fixed by him. As I recall, most (if not all) of the locale stuff relating to currency in locales was researched by IBM's X3J11 reps (who, by the way, came from IBM Canada). Others may have contributed and/or confirmed all this. I, personally, did not yet I still voted to accept it in the final document. I have no expertise or interest in this particular area as I'm sure many others voting did not either. There comes a point in any such venture where you must trust people to do `the right thing'. Knowing the IBM reps well I trust they did what they thought was the right thing at the time they researched it and so I stand by their efforts and my vote. Hindsight is the most exacting science and we can also improve something. Also note that it was unlikely anyone working on ANSI C had a vested interest in the Norgegian marketplace at that time. We did, however, try to accomodate both European and Asian cultures with locales, etc., as best as we knew how and by cooperating with their suggestions and requests. I am not personally aware of any direct input from Norway either at the ANSI C or ISO C level re this or any other issue. If Norway has a standards body why aren't they participating in ISO C? Denmark is and they are concerned about their specific alphabet issues. > I'm not impressed. One is led to believe that whatever else they say > on localization is also grossly out of date, and subsequently that the > whole locale stuff is bugridden at its core, never really tested. This is a very extreme position. You are assuming locales are trashed just because the example has a problem. The standard does not require any implementor to provide any locales beyond "C". I'm sure that if you provided a Norwegian locale and did it `the right way' your customers will thank you for it. I may be reading into this something that isn't there but it sounds like `The damned US is ignoring the rest of the world again.' In any event I'd like to publicly state that having been heavily involved with X3J11 from about the 4th or 5th meeting on I never once saw evidence of the committee as a whole trying to subvert any attempt to provide reasonable support for non-USA, non-English cultures. The addition of locales and multibyte primitives delayed the standard probably 2 years but we did it anyway. And, FYI, although I may be the US international rep, I am an Australian citizen. BTW, The Danish Standards Assoc. has done a LOT of work on defining a Danish National Locale. Their ISO C rep is very much involved with ISO POSIX which is also looking at standardizing locales. Rex ---------------------------------------------------------------------------- Rex Jaeschke | Journal of C Language Translation | C Users Journal (703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL rex@aussie.COM | Reston, Virginia 22091, USA | Programmers Journal ---------------------------------------------------------------------------- Convener of the Numerical C Extensions Group (NCEG) ----------------------------------------------------------------------------