[loc-en-dev] Locale Display Name with script
Naoto.Sato at Sun.COM
Fri Mar 6 09:51:39 PST 2009
I vote for the simpler ones for now. We could change display names
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.
Yoshito Umaoka wrote:
> Below is the current specification of Locale#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)
>> 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)
> script (country, variant)
> script (country)
> script (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?
More information about the locale-enhancement-dev