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

[Naoto Sato]

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