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

[Doug Felt]

The constructors maintain the variant for compatibility; that is, a
subsequent call to Locale.getVariant must return "JP".
 LocaleBuilder.setVariant("JP") I think will throw an exception since the
value is invalid and it expects to validate the input (that's part of the
value of the builder).

Once constructed:

Locale.forLanguageTag (I believe) will ignore the invalid value but process
the rest of the tag, unlike LocaleBuilder it tries to be lenient.

Locale.toLanguageTag will omit the variant, since it's syntactically
invalid, and add "-u-ca-japanese"

Locale.getExtension('u') will return (I believe) "ca-japanese".

The serialized form of the Locale, when read by Java 6, should see the "JA"
variant though not, of course, the extension.

Haven't tested this, though.

Doug

On Wed, Jun 30, 2010 at 4:37 PM, Naoto Sato <naoto.sato at oracle.com> wrote:

> I wasn't sure that Yoshito's "In the current proposal" was just for the
> Builder. If that's the case I am fine. I want to confirm that the variant
> that is created by the Locale constructor is intact, otherwise it would
> cause a compatibility issue.
>
> The reason I brought this up was that the current API doc ("Compatibility"
> section in the Locale class description) reads:
>
> "When the Locale constructor is called with the arguments "ja", "JP", "JP",
> this extension is automatically added. "
>
> Naoto
>
>
> (6/30/10 4:07 PM), Doug Felt wrote:
>
>>
>>
>> On Wed, Jun 30, 2010 at 3:51 PM, Naoto Sato <naoto.sato at oracle.com
>> <mailto:naoto.sato at oracle.com>> wrote:
>>
>>    (6/30/10 2:08 PM), Yoshito Umaoka wrote:
>>
>>        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.
>>
>>
>>    What do you mean by "transformed" here? I thought that
>>    "-u-ca-japanese" is just automatically added and "JP" variant is
>>    intact. Is it not?
>>
>> JP is too short to be a valid variant value in BCP47, so when converting
>> to a BCP47 identifier it is dropped.  I believe the decision is that a
>> Java locale created from a LocaleBuilder with -u-ca-japanese will not
>> return JP from getVariant, but Yoshito knows for sure, I expect :-)
>>
>> Doug
>>
>>
>>
>>        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.
>>
>>
>>    Let's separate implementation from the spec. Although we might add
>>    this type of explanation in the "supported locales" document, that's
>>    never been part of the spec.
>>
>>    Naoto
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20100630/7122adb0/attachment-0001.html