[loc-en-dev] [Fwd: Locale RFE]

[Yoshito Umaoka]

Hi folks,

I updated the API specification of resource bundle/locale service lookup 
- ResourceBundle, ResourceBundle.Control and LocaleServiceProvider.  
There are no API signature changes proposed, but I updated following API 
descriptions to match the changes in Locale.

ResourceBundle.html#getBundle(java.lang.String, java.util.Locale, 
java.lang.ClassLoader)
ResourceBundle.Control.html#getCandidateLocales(java.lang.String, 
java.util.Locale)
LocaleServiceProvider.html (class description)

Note:

- LocaleServiceProvider takes into account fallbacks within variant when 
variant has multiple subtags separated by underscore.  I updated 
ResourceBundle to match the design.  I think this is a right thing to 
do, but if you have any concerns, please provide your comments.

- I did not include special handling of Locales with deprecated language 
code.  We discussed about MyResource_he.class should be included in the 
lookup path when Locale "iw" is requested.  This behavior does not quite 
fit to the design of ResourceBundle.Control.  We could state this as the 
special JRE implementation only behavior, or extending 
ResourceBundle.Control to add a new API which returns "alternative" 
bundle name.  But I start feeling that the feature does not make people 
happy - at least, introducing such a hacky spec would not match the 
outcome.  If someone really need to use "he" for bundle naming for some 
reasons, he/she can still override Control#toBundleName to support 
bundle name with "he".  It cannot support both, but I do not think there 
is a strong requirement.

Please take a look at these updates and provide your feedback.

Thanks,
Yoshito

-------- Original Message --------
Subject: 	Locale RFE
Date: 	Mon, 14 Sep 2009 03:49:21 -0400
From: 	Yoshito Umaoka <y.umaoka at gmail.com>
To: 	locale-enhancement-dev at openjdk.java.net 
<locale-enhancement-dev at openjdk.java.net>



Hi folks,

After the conference call last week and some additional sub discussions 
with Mark, Doug and Steven, I update the API specification.  I'm 
attaching the latest proposal (API doc) in this message.

Since the last revision, followings were updated.

- toString() to include script/extensions after variant prefixed by 
"#".  For example, "en_US_#Latn", "th_TH_TH_#nu-thai", etc.
- toLanguageTag() to preserve variant which does not conform the BCP 47 
syntax using private use with special subtag "jvariant".  For example, 
Locale en_US_WIN will be transformed to a language tag 
"en-US-x-jvariant-WIN".
- Builder to check variant syntax to be conformed to the BCP 47 variant 
by default.  Another Builder constructor - Builder(boolean 
isLenientVariant) allows people who want to use any arbitrary variants.  
With isLenientVariant true, Buidler#setVariant will skip all syntax 
checks and never normalize the input value to lowercase letters.
- The class description to refer the Unicode language and locale 
identifiers as the reference design of java.util.Locale
- Clarify Locale and its methods won't check validity of each subtag 
values - only checks syntactical restrictions in Builder to support 
"well-formedness".

Last week, we revisited toString() issues.  Mark, Doug and myself really 
want to see all internal fields written by toString().  The proposal 
above should not break any practical code parsing toString() values 
(recognized as a segment of variant and usually discarded while 
processing).  But if this is not really acceptable, we could give up 
this change and back up some explanation about this in the previous 
revision.

Please take your time to review this revision and provide your comments 
by the end of Tuesday September 15.

I could not finish some necessary changes in ResouceBundle / 
LocaleServiceProvider class (no API changes, but the description should 
be updated.  I'm still struggling to select proper wording...)  I'll 
provide this part by Tuesday morning.

BTW, the new language tag RFC got the number assigned - 
http://www.rfc-editor.org/rfc/rfc5646.txt

-Yoshito


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090916/1ec7c49a/attachment-0003.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090916/1ec7c49a/attachment-0004.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090916/1ec7c49a/attachment-0005.html