From keld@dkuug.dk Wed Dec 12 15:04:55 1990 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA15583; Wed, 12 Dec 90 15:04:55 +0100 Date: Wed, 12 Dec 90 15:04:55 +0100 From: Keld J|rn Simonsen Message-Id: <9012121404.AA15583@dkuug.dk> To: erik@sra.co.jp, seki@sysrap.cs.fujitsu.co.jp Subject: Re: (i18n 46) Re: Japanese Profile (#422) Cc: XoTGinter@xopen.co.uk, i18n@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 > > 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 also am in favour of being able to specify short locales. Being the author of a very long one... I proposed a feature to use the ... in locales in a charcter set independent way some time ago. This was actually giving the functionality of what a Danish DP ballot comment asked for, so we would like it to be considered by WG15/1003: The order of the symbolic range could be taken from another charmap than the current one, when executing the localedef utility. Thus you could use a fairly complete charmap like a 10646 or UNICODE charmap and always have this general ordering for each of the other charmaps that would be employed. The use of this feature could be specified on the localedef command line, or by a directive in the locale source. If such a feature was available, I think that the X/Open Japanese locale could be character set independent. > > 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). And I think Greger has incorporated it in the newest POSIX.2 draft. > 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. Maybe you should have more than one Japanese locale. The Japanese delegation at the RIN meeting in London presented a paper on Japanese requirements (I think the original authors were Nakahara-san and Nakao-san). This paper had about 4 different kinds of cultures (I do not have the paper available right now), inluding modern Japanese (with arabic numbers and western dates), traditional Japanese (with kanji numbering) and government Japanese (with era dates) So there might be these locales: ja_JP,mo modern Japanese ja_JP,tr traditional Japanese ja_JP,go government Japanese I am not sure what Erik means when he talks about main/secondary system. I think you have just one (or maybe two) date formats available in your locale. There is the d_fmt and d_t_fmt - where the latter also includes the time. The Danish Locale also uses a weekday name in the latter. Actually I think if you use Era dates in one of them, you should also use it in the other - to be consistent - and the chioce of Era vs. western dates should be done by chosing the locale. Doing programming for Japan depending on the knowledge that one date format displays the Era and the other the western date seems messy to me. Keld