[loc-en-dev] Builder / Locale API detailed review

[Doug Felt]

On Tue, Jul 6, 2010 at 2:55 PM, Yoshito Umaoka <y.umaoka at gmail.com> wrote:

> Hello,
>
> In the project conference call on last Friday, we reviewed Builder / Locale
> API behavior. I updated the two document to reflect our conclusions:
>
> http://sites.google.com/site/openjdklocale/design-notes/builder
> http://sites.google.com/site/openjdklocale/design-notes/locale
>
> Sections in orange background are either not covered in the call or things
> we did not conclude.
>
> I think there are some remaining design questions
>
> 1) new Locale("no", "NO", "NY").toLanguageTag()
>
> There are two possible options
>
> a. "nn-NO"
> b. "no-NO-x-jvariant-NY"
>
> Semantically, "nn-NO" is preferred for other applications. However, it does
> not round trip well (or should it?)
> "no-NO-x-jvariant-NY" preserves entire fields as is, but it depends private
> use to indicate it's Nynorsk.
>
> I prefer "nn-NO". Although forLanguageTag("nn-NO") will return a Locale
> nn_NO, we also propose both nn_NO and no_NO_NY are included in
> ResourceBundle / LocaleServiceProvider look up candidate list, so nn_NO
> matches resource no_NO_NY or vise versa.
>
> 2) Locale.forLanguageTag("en-x-jvariant-WIN") vs. new
> Builder().setLanguage("en").setExtension("x-jvariant-WIN").build()
>
> In the last call, we thought private use "jvariant-*" should be treated as
> Java variant. I think above two should create the same Locale - en__WIN. Are
> there any objections with this behavior?
>
> If we decide to parse private use "jvariant-*" into variant, we need to
> resolve one more issue.
>
> new
> Builder().setLanguage("en").setVariant("Windows").setExtension("x-jvariant-XP").build()
>
> We have two choices. setExtension above to set "XP" to variant, or append
> "XP" to the variant. So the result Locale would be either:
>
> a) en__XP
> b) en__Windows_XP
>
> I prefer option b) that means, "append". This behavior is somewhat
> consistent with toLanguageTag() - new Locale("en", "",
> "Windows_XP").toLanguageTag() returns "en-Windows-x-jvariant-XP".
>
> I think there's a few more issues to clarify:

1) what does ... setExtension("x-jvariant-XP").setVariant("Windows") return?
2) what does ... setExtension("x-jvariant-XP").setExtension("x-jvariant-NY")
return?
3) what does ...
setExtension("x-jvariant-XP").setVariant("Windows").setExtension("x-jvariant-NY")
return?

The usual behavior for setExtension is to replace, not append.  So it seems
we're special-casing extensions starting with "x-jvariant-" to append.  If
so, we need to explain this special case in the javadoc.

Alternatively, we can wait until we resolve to a Locale, and then if we have
an x-extension starting with jvariant- we can append the variants at that
time (and strip this data from the x-extension).





>
> 3) Locale.forLanguageTag("en-a-abc-a-def-x-123") and new
> Builder().setLanguageTag("en-a-abc-a-def-x-123")
>
> When two extensions with a same key are in a language tag, how should we
> interpret this? The same question also applies to duplicated Unicode
> attributes / multiple Unicode locale keyword with a same key.
>
> We should decide if we simply treat this as an error (forLanguage tag
> truncate anything second "a" / setLanguageTag to throw an exception and set
> error index at the second "a"). Alternatively, we just ignore the second one
> ("a-def") and continue parsing.
>
> We'll make the final decision for them in the next call (next Monday).
>  I'll write design note explaining detailed behavior for the rest of area by
> the next call and we'll go through the document.
>
> Thanks,
> Yoshito
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20100707/8bde8217/attachment.html