From erik@sran8.sra.co.jp Wed Dec 12 13:52:15 1990 Received: from MCSUN.EU.NET by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA14591; Wed, 12 Dec 90 13:52:15 +0100 Received: by mcsun.EU.net with SMTP; Wed, 12 Dec 90 13:55:21 +0100 Received: from srava.sra.co.jp by srawgw.sra.co.jp (5.64WH/1.4) id AA19915; Wed, 12 Dec 90 21:54:33 +0900 Received: from sran8.sra.co.jp by srava.sra.co.jp (5.64b/6.4J.6-BJW) id AA24816; Wed, 12 Dec 90 21:54:32 +0900 Received: from localhost by sran8.sra.co.jp (4.0/6.4J.6-SJ) id AA22688; Wed, 12 Dec 90 21:52:36 JST Return-Path: Message-Id: <9012121252.AA22688@sran8.sra.co.jp> Reply-To: erik@sra.co.jp From: Erik M. van der Poel To: seki@sysrap.cs.fujitsu.co.jp Cc: i18n@dkuug.dk, XoTGinter@xopen.co.uk Subject: Re: (i18n 44) Re: Japanese Profile Date: Wed, 12 Dec 90 21:52:32 +0900 Sender: erik@sran8.sra.co.jp X-Charset: ASCII X-Char-Esc: 29 > > I hope you have proposed these "X/Open extensions" to the Posix > > people. > > I have the same opinion. > > Unfortunately, the X/Open company is a big organization, and I am > not responsible OK, I can understand that you are very busy. Perhaps we (wg15rin) can work on this. Greger, what do you think? > 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 don't think it is a question of whether or not it will "work". If the system is implemented properly, it should collate even Shift-JIS exactly as you specify in your ellipsis definitions. Of course, it cannot be as efficient as JIS, since there is no one-to-one relationship between the collation definition and the Shift-JIS code. (By the way, LC_COLLATE is an area where even the Americans will enjoy the benefits of i18n. Until now, American-English has often been sorted according to the ASCII code, with a one-to-one relationship between the collation rules and the encoding. With LC_COLLATE, the Americans will be able to do proper sorting, and it will be easier for us to see "Makefile" and "makefile" next to each other. :-) > 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. Yes, we (the Japanese SSI/POSIX group and Keld) also thought it would be a good idea to introduce the ellipsis (ranges of characters) in the *charmap*, for the same reason (to reduce the size). > Please remember that it is only an example to show usefulness of > localedef command. Yes, I realize it is only an example, and I thank you once again for distributing it. > > 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 I agree that the era system should be covered in the general i18n facilities. My concern is that the definition may not be general enough. However, if everyone thinks that this is good enough for now, then perhaps we should just go ahead and implement it. On another note, if the era system is the "true Japanese style", then perhaps we should make it accessible through %Y instead of %E? If an American is writing an internationalized program that uses strftime() to obtain a string containing the year in the local format, he/she is much more likely to use %Y, which is also easier to remember since it stands for "Year". Most Americans don't understand %E, the Era system. Of course, the Japanese use both systems, the Western year and the Era year, so that's why we want *two* -- %Y and %E. What I'm trying to say in this message is: Why don't we put the main system (the true local style) in %Y, and put the secondary system in the other one. Erik