[loc-en-dev] Norwegian resource bundle lookup

[Yoshito Umaoka]

A couple of months ago, Masayoshi posted a counter proposal for 
Norwegian lookup order below.
> The *_NO look-up sequences should be consistent with the no and nb 
> ones. So
> the sequences should be:
>
> no_NO -> nb_NO -> no -> nb
> no_NO_NY -> nn_NO -> no_NO -> nn -> no
> nn_NO -> no_NO_NY -> nn -> no
> nb_NO -> no_NO -> nb -> no 
For Norwegian cases, we also need to consider what kind of things done 
by Java users with the current JDK.  First of all, new Locale ("nb", 
"NO") or new Locale ("nn", "NO") is legal and works as you expect even 
with JDK 6.  Because Web browsers already sending Accept-Language "nb", 
"nb-no", "nn", "nn-no", such Locales are created by the standard J2EE 
implementation.  Application developers have several design options to 
handle them as they want.  One solution is obviously providing bundles 
using language code "nb" and "nn" in addition to "no" (I also saw such 
implementation in a product).

JDK documentation clearly stated that a language of locale ID "no_NO" is 
Norwegian Bokmål.  Also, Norwegian Bokmål is more widely used in Norway, 
so Java bundles no_NO in existing Java applications are most likely 
contain Norwegian Bokmål contents.

In Java, a language of locale ID "no_NO_NY" is Norwegian Nyrnorsk.  If 
we can replace it with "nn_NO", it would be nice, but we cannot do this 
for backward compatibility reasons.

Masayoshi's counter proposal for lookup order starting no_NO_NY is below -

no_NO_NY -> nn_NO -> no_NO -> nn -> no

I do not see any problems with the second candidate - nn_NO, because 
no_NO_NY was in JDK for locale Norwegian (Nynorsk) - Norway.  "nn_NO" is 
the most appropriate representation if we can forget about the backward 
compatibility support.

However, the third candidate "no_NO" looks problematic.  As I described 
above, the current JDK documentation clearly states no_NO is for 
Norwegian (Bokmål) - Norway.  And many folks actually expect no_NO 
contains Norwegian Bokmål contents.  I think  Masayoshi assumed that 
people who uses language code "nn" for Norweigan Nyrnosk always uses 
"nb" for Norwegian (Bokmål).  But I do not think this is not true as I 
explained above.

If we interpret no_NO_NY is an alias of nn_NO, the lookup order should 
be below -

nn_NO_NY -> nn_NO -> nn

However, above list breaks the backward compatibility.  In Java 6, if 
you start with no_NO_NY, no_NO and no are included in the lookup path.  
So we need to put them in the candidate list.  For these reasons, I 
believe the right order, which fully support the people's expectation is 
below -

nn_NO_NY -> nn_NO -> nn -> no_NO -> no

When you start from nn_NO, Masayoshi's proposal looks OK, but I think 
inserting no_NO before no is better for consistency with the case 
starting with no_NO_NY.  (In other words, we interpret no_NO_NY and 
nn_NO are equivalent)

nn_NO -> no_NO_NY -> nn -> no (Masayoshi)
nn_NO -> no_NO_NY -> nn -> no_NO -> no (Yoshito)

For the case starting from no_NO/nb_NO, the order of no and nb does not 
matter practically.  I still prefer "nb" always comes before "no" 
(because "nb" is more specific), but I do not see any impacts to 
existing applications.

We also need to consider when language only locale "no", "nb" or "nn" is 
requested.   Norwegian locales with country code does lookup between 
"no" and "nb"/"nn", I think we may want to do the similar thing also for 
language only locales.  More specifically -

no -> nb
nb -> no
nn -> no

The first one is "default specific language" fallback for a macro 
language.  The second and third are "macro language" fallback for a 
specific language belongs to the macro language.  The initial design 
draft sorted out all the characteristics of things to be considered in 
systematical manner.  But such design require data (macro language and 
specific language mappings) which we do not want to maintain in JDK (for 
stability reasons).  Technically, such handling can be done by 
overriding ResourceBundle.Control and implements your own 
getCandidateLocales, so I think we exclude this from JDK 7 proposal.

-Yoshito