[loc-en-dev] Unicode locale extension - what it meant to Java
dougfelt at google.com
Wed Jun 30 17:58:40 PDT 2010
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 :-)
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.
> 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. "
>> (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
>>> 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
>>> Imperial calendar. This is Java's proprietary definition. In the
>>> 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 :-)
>>> For me, adding unicode locale extension APIs in Java indicates a
>>> level of commitment for supporting Unicode locale extension in
>>> 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
>>> 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
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the locale-enhancement-dev