[loc-en-dev] About Locale#toString()

[Doug Felt]

What is the motivation for treating the variant field
underscore-by-underscore rather than as an entire unit?

Doug

On Wed, Feb 18, 2009 at 9:02 AM, Yoshito Umaoka <y.umaoka at gmail.com> wrote:

> In the bi-weekly project call, we agreed not to change the behavior of
> toString().  This implies that you won't get any new field information (such
> as script and extensions) returned by toString().
>
> In the current proposed API set, we have toLanguageTag(), which returns
> syntactically valid BCP47 language tag string.  However, subtags in a BCP47
> language tag is delimited by hyphen('-') instead of underscore('_').  One of
> the goals in this project is to include script field value involved in the
> resource bundle lookup inheritance. Therefore, I would like to have a method
> creating a locale string delimited by underscore, which can be used for
> resource bundle suffix. (Technically, this can be achieved by composing the
> string by appending getLanguage(), getScript()...)  This is a common
> operation and I think it is worth having such API.
>
> I'm considering following three APIs for the purpose.
>
> String toFullString()
> Locale getBaseLocale()
> Locale getParent()
>
>
> toFullString() is a variant of toString() to generate a string
> representation of Locale, but also include script and extensions if they are
> available.
>
> getBaseLocale() returns a Locale (proposed implementation is to return a
> singleton) without locale extensions.  Locale extensions is not used for
> resource bundle lookup.
>
> getParent() returns a parent Locale (proposed implementation is to return a
> singleton).  A parent locale represent a locale omitting the most right
> field of its child locale.  For example, Locale("en") is a parent locale of
> Locale("en", "US").  If a locale has a variant field and the variant field
> contains one or more underscore characters, then its parent still have
> variant field, but excluding the substring after the last underscore.  For
> example, Locale("en", "US", "NYC") is a parent locale of Locale("en", "US",
> "NYC_JFK")
>
> With these 3 APIs, the resource bundle is collecting key-value pairs with
> the pseudo code below -
>
> Locale target; // the resolved Locale
> Locale loc = target;
> ResourceBundleImpl child = null;
> while (true) {
>    ResourceBundleImpl aBundle = loadFrom(bundleBaseName + "_" +
>        loc.getBaseLocale().toFullString());
>    if (child != null) {
>        child.parent = aBundle;
>    }
>    loc = loc.getParent();
>    if (loc == null) {
>        // Locale.ROOT.getParent() returns null
>        break;
>    }
>    child = aBundle;
> }
>
> Do you think we should have such APIs?  Also, if you do, do you want to
> make them public or keep them package local/private?
>
> -Yoshito
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090218/2c0f2af2/attachment.html