From seki@sysrap.cs.fujitsu.co.jp Tue Dec 11 11:37:21 1990 Received: from mcsun.EU.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA13950; Tue, 11 Dec 90 11:37:21 +0100 Received: by mcsun.EU.net via EUnet; Tue, 11 Dec 90 11:40:51 +0100 Received: from fai.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AB01870; Tue, 11 Dec 90 05:39:53 -0500 Received: by fai.fai.com; id AA04732; Tue, 11 Dec 90 02:38:49-1795 Received: from [133.161.1.9] by fgw.fujitsu.co.jp (5.65/6.4J.6) id AA02563; Tue, 11 Dec 90 19:36:03 +0900 Received: by spad.sysrap.cs.fujitsu.co.jp (4.12/6.4J.6) id AA16463; Tue, 11 Dec 90 15:55:30 JST Date: Tue, 11 Dec 90 06:55:26 GMT From: Masahiro SEKIGUCHI Return-Path: Message-Id: <9012110655.AA00458@seki.sysrap.cs.fujitsu.co.jp> In-Reply-To: Erik M. van der Poel Organization: Planning Dept., R&P Div., Fujitsu Limited Address: 1015 Kamikodanaka, Nakahara-ku, Kawasaki 211 JAPAN X-Host-Os: Fujitsu SX/G E13A X-Mailer: Mail User's Shell (6.5 4/17/89) To: i18n@dkuug.dk Subject: Re: Japanese Profile Cc: XoTGinter@xopen.co.uk X-Charset: ASCII X-Char-Esc: 29 > > # Based on POSIX.2 D10 syntax with X/Open extension. > > I hope you have proposed these "X/Open extensions" to the Posix > people. It would be better for X/Open and Posix to be compatible with > each other. I have the same opinion. Unfortunately, the X/Open company is a big organization, and I am not responsible > > > > # This definition implicitly assume that underlying encoding > > # is UJIS (EUC-JIS) or similar one. > Which parts of your definition depend on the encoding? The interpretation of ellipsis (...) depends on underlying encoding. For example my definition will work for encoding so-called 7-bit- JIS (which are used in JUNET) as well as UJIS, but will not on Shift-JIS nor Kanji codes which are not based on JIS X0208. > I believe that, in general, locale definitions should be independent > of encodings. ... abridged ... > The locale definitions should only contain references to > the symbolic names, and are therefore independent of the encoding. I agree. The reason why my example depends on paticular encoding is ellipsis. It is a convenient way to short cut large definitions, but the resulting locale definition becomes non-portable. We X/Open discussed it and decided to use ellipsis, knowing disadvantages to do so, to reduce the size (i.e., number of lines) of the definition. Please remember that it is only an example to show usefulness of localedef command. > If it is possible that a country other than Japan may want to have a > slightly different way of defining their era year, then I think that > this keyword should not be called "era". It is unfair for any one > country to reserve a general word like "era". > > 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. Such an approach is far from internationalization. When I want to make my application program fully internationalized, it should print the date in true French style in the French locale and in true Japanese style in the Japanese locale. If an user (or Japanese national standard body or whoever) decided that era system is true Japanese style, the above program should print the era year names as the date. So, the era system should be covered in general internationalization facilities. -- Masahiro Sekiguchi Planning Dept., R&P Div., Fujitsu Limited seki@sysrap.cs.fujitsu.co.jp (JUNET) -or- PDB01144 (NIFTY-Serve)