[loc-en-dev] Locale Display Name with script

[Doug Felt]

The builder defaults language to 'und'

Doug

On Fri, Mar 6, 2009 at 9:51 AM, Naoto Sato <Naoto.Sato at sun.com> wrote:

> I vote for the simpler ones for now.  We could change display names after
> JDK7.
>
> BTW, the last paragraph reminds me of a question: do we allow Locale
> instance creation through the factory method or the builder, without
> "language"?  In BCP47, it is mandatory, otherwise you cannot tell the first
> two letter code is language or region.  I may have asked this question
> before, but cannot remember the answer.
>
> Naoto
>
>
> Yoshito Umaoka wrote:
>
>> Below is the current specification of Locale#getDisplayName.
>>
>>>
>>>
>>>      getDisplayName
>>>
>>> public final java.lang.String *getDisplayName*()
>>>
>>>    Returns a name for the locale that is appropriate for display to
>>>    the user. This will be the values returned by
>>>    getDisplayLanguage(), getDisplayCountry(), and getDisplayVariant()
>>>    assembled into a single string. The display name will have one of
>>>    the following forms:
>>>
>>>        language (country, variant)
>>>
>>>        language (country)
>>>
>>>        language (variant)
>>>
>>>        country (variant)
>>>
>>>        language
>>>
>>>        country
>>>
>>>        variant
>>>
>>>    depending on which fields are specified in the locale. If the
>>>    language, country, and variant fields are all empty, this function
>>>    returns the empty string.
>>>
>> A couple days ago, Mark Davis suggested that we may need to make up a
>> display name not just by concatenating individual fields' display names.
>>  For example, en_US may be displayed as "American English".  I'm not fully
>> supporting this idea for the specific example he raised, but when we think
>> about script support, we may want to look at two examples - Simplified
>> Chinese and Traditional Chinese.  I want to extend the existing pattern
>> based display name generation for this reason, but at the same time, it
>> requires some design changes in LocaleNameProvider.
>>
>> Locale display name could be supported via custom LocaleNameProvider
>> implementation.  For now, the contract is that LocaleNameProvider
>> implementation returns a display name of individual field when JDK does not
>> have the translation.  But Locale#getDisplayName is formatting them based on
>> the rule described above.  Technically, we could add a new API in
>> LocaleNameProvider which handles a locale name as a whole (e.g.
>> getDisplayLocale(Locale loc, Locale inLoc)).
>>
>> In longer term, we should consider better way to handle this.  But I do
>> not think we can do much for JDK7.  So my current proposal is simply add
>> script display name based on the current rule (with minor extension).  More
>> specfically -
>>
>> language (script, country, varinat)
>> language (script, country)
>> language (script)
>> language (country, variant)
>> language (country)
>> language (variant)
>> language
>> script (country, variant)
>> script (country)
>> script (variant)
>> script
>> country (variant)
>> country
>> variant
>>
>> Practically, script without language does not make much sense.  We could
>> prevent such locale instance is created through the builder, but I'm not
>> sure we really need to do this.  I prefer to keep it simple (allows script
>> only locales).  Do you have any preferences?
>>
>> -Yoshito
>>
>>
>>
>
> --
> Naoto Sato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090306/d46a442f/attachment.html