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

[Naoto Sato]

Ah, yes.  Thank you.

Naoto

Doug Felt wrote:
> The builder defaults language to 'und'
> 
> Doug
> 
> On Fri, Mar 6, 2009 at 9:51 AM, Naoto Sato <Naoto.Sato at sun.com 
> <mailto: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
> 
> 


-- 
Naoto Sato