Xref: utzoo comp.std.c:4346 comp.std.internat:796 Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!axion!tsa!domo From: domo@tsa.co.uk (Dominic Dunlop) Newsgroups: comp.std.c,comp.std.internat Subject: Re: Localization (4.4.2.1) Message-ID: <1991Feb16.140510.22226@tsa.co.uk> Date: 16 Feb 91 14:05:10 GMT References: Reply-To: domo@ukc.ac.uk (Dominic Dunlop) Followup-To: comp.std.internat Organization: The Standard Answer Ltd. Lines: 106 [Note that I'm making an attempt to divert this discussion into comp.std.internat] In article enag@ifi.uio.no (Erik Naggum) writes: > 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. > > According to this example, Norwegians write "kr1234,56" when they mean > 1,234.56 units of local currency. According to this example, they > also write "kr1234,56-" when they mean -1,234.56 units of local > currency. > > I wonder how this managed to get into a standard in the year 1989. > After spending a few days asking friends, and them their fathers, I my > friends in the Norwegian Standards Association, the uniform reply is > "that went out of recommended use more than 20 years ago". In 1968 NS > 4133 (Norwegian Standard for Letters and other Documents, Writing and > Layout), the international currency code "NOK" is recommended... > international trade and communication, and is preferred for domestic > [and so on] > > 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. Well, yes. It is fair to say that internationalization issues were introduced to both the X3J11 and the POSIX working groups rather late in the day, with the result that ANSI X3-159 (C) and ANSI/IEEE 1003.1 (POSIX operating system interface) are rather light on internationalization-related content. This lightness is likely to be redressed in two forthcoming standards, the X3J16 C++ work, and the POSIX 1003.2 standard (shell and utilities): the internationalization lobby was able to get at these projects sufficiently early in their development to ensure that internationalization issues are considered at every turn. Well, most turns. Well, a good proportion of turns. It is also the case that the 1990 version of 1003.1 (which is the same thing as ISO 9945-1:1990) says a bit more about internationalization than the 1988 edition, and that the next edition of the C standard will also pay more attention to the issue, thanks to much work by Japan and Nordic countries, among others. (Sadly, ISO 9899:1990, the first edition of the international standard for C, has the same technical content as ANSI X3-159.) As for testing, where do you get things tested? In the marketplace, that's where. Unfortunately, there was very little prior art for X3J11 and POSIX workers to standardize, and what prior art there was had known shortcomings -- for example in the handling (or lack of handling) of wide characters. As a result, much of what the standardizers did was to try to make sure that practical fixes to known problems were not precluded in the future, rather than trying to come up with fixes at once. I believe POSIX did fairly well in this respect. I'm not so sure about C. A word of praise here for X/Open, which has thrown a lot of resource at the issue. But X/Open has to learn that standards working groups do not respond well to being told that a proposal must be accepted unchanged or not at all. > My direct questions are: > > Where did X3J11 get the input for these examples? > The point is that X3J11 set out to create an American National Standard. Should they be expected to know about Norway? Probably not. It's just rather a shame that they claimed to, because it creates a very bad impression with those who know better. It happens that the working group rules would have allowed participation by Norweigian companies, but what Norweigian company would want to spend money on the creation of an American standard? Try selling that idea to your management. In general, I wish more people around the world in general, and in America in particular, knew about such things as ISO 4217, Codes for the representation of currencies and funds. But they don't. People may, if you're lucky, know about their local conventions (don't rely on it though -- how many Norweigians know of the existence of NS 4133, I wonder?) This means that the right place for the definition of such things is in their target market (or ``locale'' as standards people have it). The 1990 edition of the POSIX.1 standard has annexes addressing this issue -- including a Danish example created by the Danish standards body. The internationalization rapporteur group of the ISO POSIX working group is trying to make sure that POSIX internationalization facilities do not preclude the definition of any locale that anybody, anywhere might reasonably require. The more people who get in touch with us and tell us what we're doing wrong, the happier we'll be. (Yes, I'm the UK rapporteur, but take this posting as individual comment.) > Are they didactic only, or are they intended to show real use > of the localization features? Obviously, didactic only -- intended as an example, since the text says ``may well be used'', rather than ``shall be used''. A dangerous example, though: implementors are inclined to take anthing that appears in a standard as gospel. Let me know as soon as someone tries to sell you a compiler with this example cast into its libraries... > > I would appreciate pointers to how this can be updated, as well. > Personally, I would not bother trying to fix the ANSI standard. Get in touch with your national standards body, obtain pointers to those associated with ISO/IEC JTC1/SC22/WG14 (C language), and take it up with them so as to make sure that the problem, if it exists in the current edition (I'm told it's out) of ISO 9899, is fixed in the next, or in an corrigendum or addendum. -- Dominic Dunlop