[loc-en-dev] Should we createa a Locale instance with language code "he"?

[y.umaoka at gmail.com]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090227/b33b79bf/attachment.html