[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