From erik@sran8.sra.co.jp Fri Dec 7 03:14:02 1990 Received: from mcsun.EU.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA23153; Fri, 7 Dec 90 03:14:02 +0100 Received: by mcsun.EU.net with SMTP; Fri, 7 Dec 90 03:17:25 +0100 Received: from srava.sra.co.jp by srawgw.sra.co.jp (5.64WH/1.4) id AA07690; Fri, 7 Dec 90 11:15:18 +0900 Received: from sran8.sra.co.jp by srava.sra.co.jp (5.64b/6.4J.6-BJW) id AA20150; Fri, 7 Dec 90 11:15:22 +0900 Received: from localhost by sran8.sra.co.jp (4.0/6.4J.6-SJ) id AA15257; Fri, 7 Dec 90 11:13:34 JST Return-Path: Message-Id: <9012070213.AA15257@sran8.sra.co.jp> Reply-To: erik@sra.co.jp From: Erik M. van der Poel To: pfm@hpfclj.fc.hp.com Cc: wg15rin@dkuug.dk, XoTGinter@xopen.co.uk Subject: Re: (wg15rin 68) Re: (seq 1416) Re: Japanese Profile Date: Fri, 07 Dec 90 11:13:32 +0900 Sender: erik@sran8.sra.co.jp X-Charset: ASCII X-Char-Esc: 29 > > Perhaps it would be better to take "era" out of the general LC_COLLATE > > rules, and add a hook to the rules for defining locale-specific rules. > > I can hear all of you saying "But how can you internationalize > > programs then?" Well, I think that it is likely that only Japanese > > programs will use %E and %o (for the era year), so in some sense, > > these programs would be localized rather than internationalized. > > There are other locale's that use "era". I believe both Korea and Taiwan > have the concept of era's. I confess that I do not know enough about Korea and Taiwan to confirm this. I hope another reader can help me on this one. > If the proposal is not adequate to address the era requirements, then I > believe we should extend it, not remove it. > > Pam Miller I fully agree with you on this one. However, I feel that it may be premature to include such specifications in a standard. If we are still discussing extensions to the specs (which we are), then that means that the specs are in a state of flux, constantly changing. It would be rather a disservice to the programming community to produce standards and ask developers to conform to them, only to pull the rug out from underneath them the next year. I believe we should be making extensions the usual way, by implementing systems and getting users to try them out, refining them until they are tried and true. However, if we delete the newer ideas from the drafts, we will have lost our means of communicating these ideas. So perhaps we can reserve the standards for the solid (boring) specs, and have a different medium to convey the latest ideas, something for us i18n'ers to play around with. Something like a Request For Comments, perhaps? Erik