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

[Doug Felt]

Heh, Yoshito answered more thoroughly than I did and I'd forgotten about
including the illegal variant as an x-jvariant value.

The moral is, never trust me on answers to these questions, always wait for
Yoshito to reply :-)

Doug

On Wed, Jun 30, 2010 at 5:55 PM, Doug Felt <dougfelt at google.com> wrote:

> 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/90919a11/attachment.html