[loc-en-dev] Unicode locale extension - what it meant to Java

[Yoshito Umaoka]

First of all, I'm not trying to retract Unicode locale extension part of 
proposal proactively. But I think we need to clarify the scope of our 
proposal - what Unicode locale extensions meant to Java itself.

We want to bring Unicode locale extension to Java world. Java used to 
define variant to specify specific behavior variations. This model does 
not fit well to BCP 47.

Unicode locale extension give you formal/well-structured scheme for 
representing a variation of locale. Java Locale ja_JP_JP is used for a 
variant of locale ja_JP, just changing calendar type to be Japanese 
Imperial calendar. This is Java's proprietary definition. In the current 
proposal, ja_JP_JP is transformed to -u-ca-japanese.

For me, adding unicode locale extension APIs in Java indicates a certain 
level of commitment for supporting Unicode locale extension in Java 
itself. However, we did not discuss about Java's i18n service 
implementation part much so far. We only care two exceptional cases - 
ja_JP_JP and th_TH_TH at this moment. But, if we once expose Unicode 
locale extension in Java, Java users may expect Currency instance 
created with Locale de-DE-u-cu-dem to use German Mark.

Of course, we need a framework first. Actual use of Unicode locale 
extension in Java i18n services might be done later. If we decide to add 
APIs dedicated for Unicode locale extensions and defer the support in 
i18n services, I think we should clearly state what Unicode locale 
extension meant to Java i18n services - what are supported, what are 
not, etc. I'll put this topic in the next project meeting.

-Yoshito