[loc-en-dev] Should we createa a Locale instance with language code "he"?
Naoto Sato
Naoto.Sato at Sun.COM
Fri Feb 27 14:57:15 PST 2009
I prefer the option 3, too. Actually I tried the option 1 back in JDK6
beta, and I got a regression from a customer at the end of the JDK6 dev
period so I had to back it out.
BTW, how do you search "he" resource in option 2, without changing the
Locale class?
Naoto
y.umaoka at gmail.com wrote:
> Java Locale constructor always maps language code "he" to "iw" (also
> done for a couple of more cases). This implementation forces people to
> tag resources with the deprecated language tag "iw". We discussed about
> this and we thought it could be resolved by the locale resource look up
> code.
>
> ResourceBundle.Control#getCandidateList represents the suggested look up
> order. If we allow a Locale instance to store "he" as language code, we
> could create a lookup candidate list like - he_IL -> iw_IL -> he -> iw.
> Here is the design question -
>
> 1. The current JDK implementation returns the same result for new
> Locale("he") and new Locale("iw"). If we allow people to create an
> instance of Locale with language code "he" internally (in other words,
> Locale#getLanguage() returns "he", instead of "iw"), we can resolve the
> candidate list problem easily. But, in this case, new
> Locale("iw").equals(new Locale("he")) should return true.
>
> 2. Another option is to JDK's own ResourceBundle lookup code to search
> both he and iw, but the candidate list only contains Locales with "iw".
> This implementation has no impacts to the existing apps. But doing
> special thing in JDK implementation is somewhat ugly.
>
> 3. Yet another option is to keep the Locale constructor's behavior
> (silently maps "he" -> "iw"), but LocaleBuilder to allow people to
> create a Locale instance with language code "he". This has less impact
> to existing applications, but like option 1 above, we need special
> handling for testing equality.
>
> I think 1 (change the Locale constructor's behavior) is problematic. I
> guess we should either go for 2 or 3. I personally prefer the 3rd
> option. What do you think?
>
>
> -Yoshito
--
Naoto Sato
More information about the locale-enhancement-dev
mailing list