[loc-en-dev] Variant display name
Naoto Sato
Naoto.Sato at Sun.COM
Fri Mar 6 09:39:50 PST 2009
IIRC, those are just for "display names" for those variants. I think we
should just keep the current behavior, especially we should *not* regard
the obsolete ones and current ones as equal when checking the equality
of the locales.
Thanks,
Naoto
Yoshito Umaoka wrote:
> Hi all,
>
> While I was investing what to do for Locale display name, I realized
> there are 3 kinds of variants have its own name in JDK.
>
> %%EURO=Euro
> %%B=Bokm\u00e5l
> %%NY=Nynorsk
>
> However, this page -
> http://java.sun.com/javase/6/docs/technotes/guides/intl/locale.doc.html
> - does not contain any supported locales with variant EURO and B. I
> have several questions here.
>
> 1. I think EURO was used long time ago to distinguish the use of legacy
> domestic currency from Euro in European locales. But for now, we no
> longer have any locales supporting both legacy and Euro. I think it's
> OK to leave it there, but do we need any special handling required for
> locale canonicalization/or checking equality?
>
> 2. I think B is also obsolete. Language code "no" is treated as
> "Norwegian Bokmal" for now. Can we simply ignore the semantics of
> variant B in general?
>
> 3. The supported locale list contains ja_JP_JP / th_TH_TH. These
> locales are canonicalized to ja_JP_u_ca_japanese / th_TH_u_nu_thai by
> the new design. Luckily we do not have any display names assigned to
> them. For now, I did not propose to add locale keyword key/type display
> name support (ICU supports this), because we are not sure how much JDK
> i18n service supports them in JDK7 time frame. For display name
> purpose, can we simply continue to use variant code JP/TH for now?
>
> -Yoshito
--
Naoto Sato
More information about the locale-enhancement-dev
mailing list