Subject: Re: (i18n 44) Re: Japanese Profile

From: Erik M. van der Poel <[email-masked]>
Date: Wed, 12 Dec 90 21:52:32 +0900

> > 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