[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