From keld@dkuug.dk Mon Apr 27 22:56:56 1992 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA14478; Mon, 27 Apr 92 22:56:56 +0200 Date: Mon, 27 Apr 92 22:56:56 +0200 From: Keld J|rn Simonsen Message-Id: <9204272056.AA14478@dkuug.dk> To: sc22wg14@dkuug.dk Subject: Plauger localedef Cc: sc22wg20@dkuug.dk, sc22wg21@dkuug.dk, wg15rin@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 > May I mention just for the record that I provided both of these > published works to WG14's liaison to WG20 (Keld Simonsen) last > year. At the London WG21 meeting (March 92) Simonsen acknowledged > that he not yet read these materials. He agreed with me that nei- > ther WG14 nor WG21 have yet taken any position about localedef > representations, and that he would not imply to WG20 that WG14 or > WG21 favor any particular method of localedef representation. Well, I had read/skimmed the documents, but not found out the full details of what was described there. I read further in the documents at the WG21 meeting, and got the impression of the functionality that you have given here. May I for the record remark, that there have been no official WG14 nor WG21 papers on this subject, nor have there been any statements that I have been asked to bring forward to WG20 on behalf of WG14 or WG21. I talked to Tom about it at the latest WG21 meeting, and remarked that POSIX i18n localedef syntax is really now at DIS stage and as such very advanced in the ISO process, compared to Plauger syntax, which has never been presented officially in ISO fora. So my advice to Tom was, if Plauger localedef should have a chance (which I think it should) it should be brought forward very soon. I also talked to Bill Plauger about it, and his remarks (as far as I remember) was that the two proposals were not conflicting, and that the Plauger model mostly added functionality in the widechar/multibyte conversions. From what I see it is mostly the collating specification that differs - and in my eyes the POSIX model is more general here, and also the model being currently employed by national ISO member bodies and the industry. I do not remember agreeing with Tom that neither WG14 nor WG21 has taken any position on localedef representations, but anyway I agree that this is the current situation. I have presented the Danish POSIX work on locales to WG14 and it was positively received, I got action items to proceed with the work, and it has been agenda points. Anyway at the latest WG14 meeting in Milano we decided to not go further with the work, as it would need a lot of specification along the lines of POSIX localedef which would just be a repetition of their work, and the i18n issue was now the responsibility of WG20. I have told WG20 that WG14 has seen the POSIX work, but not that WG14 prefered it to be done this way. I may have indicated that WG14 was positive to it, but that has also been the case as noted above. > Simonsen has recently submitted an "NP on Cultural Elements and > Registry" (JTC1/SC22/WG20/N079, WG14/N206). He proposes a new > work item to standardize the specification and registry of > localedefs. The proposal presented here overlaps the proposed > scope of work almost exactly. Well, this was not *my* proposal, but the outcome of quite some discussion within WG20, and it is the WG20 proposal. WG20 recognizes the need a registry for POSIX-compliant locales, based on POSIX localedef syntax. This does not mean that we will not investigate other formats, including what you have described here. Actually WG20 is fully aware that POSIX is not the final answer to internationalisation, and WG20 have started a requirements and reference model work for i18n, leading to a TR on the subject. My general remark on the Plauger localedef syntax is that it is not character set independent, and as far as I know, both WG20, WG15 and the industry and the users and the ISO member bodies want to have character set independent locales. This naturally leads to a requirement for character naming attributes. Anyway I think the Plauger syntax could be enhanced to allow use of character naming attributes, but I do not know if such a specification would be simpler than the POSIX syntax. Keld