From keld@dkuug.dk Mon Nov 26 23:36:40 1990 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA04063; Mon, 26 Nov 90 23:36:40 +0100 Date: Mon, 26 Nov 90 23:36:40 +0100 From: Keld J|rn Simonsen Message-Id: <9011262236.AA04063@dkuug.dk> To: XoTGinter@xopen.co.uk, i18n@dkuug.dk Subject: Re: (wg15rin 57) (i18n 28) Strawman resolution to ballot objections X-Charset: ASCII X-Char-Esc: 29 A quick reply to Gregers 3 level support for i18n in POSIX. This is not neccesarily the position of Danish Standards. DS has made an (example) national profile for POSIX. This profile/locale is in accordance with the Danish standard for collating DS 377. I do not believe that DS can endorse a standard like POSIX which does not require facilities which is neccesary to fulfill Danish Standards needs, including correct collating in Danish. I would anticipate that quite some other national bodies will have the same requirements for sorting their language correctly. I will state below what is neccesary to accomodate DS 377. > Category Level Interpretation > ---------------------------------------------------------------- > > LC_CTYPE C-locale Implementation-supplied character > classification support only. > > Basic User specification of character > classification according to rules > defined in 2.4.1, but no additional > classes may be specified. The Basic level is necessary to be able to provide the DS da_DK locale. > Extended As above, but additional classes may > be specified. Not needed. > LC_COLLATE C-locale Implementation-supplied collation > as per the implementor's C locale. > > Basic Implementations shall support > multi-character collation elements and > collation symbols, 1-to-2 mapping and > user-specified 2-level ordering, with > both forward and backward compares. > The "substitute" keyword and the > "no-substitute" and "position" collation > directives are optional. > > Extended Same as basic, but with 1-to-many > mapping and support for the "substitute" > keyword and the "no-substitute" and > "position" collation directives, and > with at least 3 weight levels (possibly > four). Extended level is needed here, 4 levels needed, 1-to-many mapping needed for 8859-1 support! > > LC_MONETARY C-locale Implementation-supplied localeconv() > (or equivalent) support for C locale. > > Basic Implementations shall support user- > definable values for all keywords. Basic is needed. > Extended Currrently same. > > > LC_NUMERIC C-locale Implementation-supplied localeconv() > (or equivalent) support for C locale. > > Basic Implementations shall support user- > definable values for all keywords. > > Extended Currrently same. > > > LC_TIME C-locale Implementation-supplied C locale > support for the C locale field > descriptors %a, %A, %b, %B, %c, > %x, %X and %p. > > Basic Implementations shall support user- > definable values for keywords > abday, day, abmon, mon, d_t_fmt, > t_fmt, d_fmt and am_pm. Basic is needed. > Extended Same as above, plus support for > optional keywords > > > LC_MESSAGES C-locale Implementation-supplied support for > C locale responses and C locale > messages > > Basic Implementations shall support user- > definable values for yesexpr and noexpr. Basic is needed. > Extended Same. My quick conclusion: Implementations with C-locale like facilities should not be sold in Denmark as conforming to ISO POSIX. This is also in line with WG15's resolution that the support for i18n as specified in POSIX.2 draft 10 is the minimum level of support that is needed to accomodate international needs. Keld Simonsen