In Java application, it is recommended that localized strings are stored in
resource bundles and accessed via java.util.ResourceBundle. JDK ResouceBundle
implementation searches a bundle associated with the given Locale and if the
match is not found, it downgrades the given Locale (e.g. en_US -> en) to seek
for fallback bundle until a match is found.
This simple fallback logic works OK for many cases, but some people may want to
use different locale fallback path. For example -
zh_HK -> zh_TW -> zh
nn_NO -> nn -> no_NO -> no -> nb_NO -> nb
In ICU4J, ULocale supports RFC3066 extended language tags. With RFC3066 style
language tag with script code, the fallback logic may be more complicated. For
example -
zh_Hant_HK -> zh_HK -> zh_Hant -> zh_TW -> zh
zh_Hans_HK -> zh_HK -> zh_Hans -> zh
To support better language fallbacks, ICU4J should provide next two things.
1. A method which populates fallback locales in ULocale class. Because the
order of fallback locales may be different depending on the start point, so the
current ULocale#getFallback() is not sufficient. We may need -
ULocale[] getFallbacks()
2. ResourceBundle replacement which supports ULocale. With JDK ResourceBundle,
we cannot handle RFC3066 extended language tag properly. ICU4J should provide a
extended ResourceBundle class which takes ULocale as an argument.
I found this bug while looking for code to do the following:
Let's assume I have a servlet with ResourceBundle's configured for each of { "EN", "FR" }. I then receive a ServletRequest for which getLocales() returns { "RU", "FR" }. If I write naive code which simply just pulls the first "RU" code from the request and calls ResourceBundle.getBundle(baseName, "RU") with it, that method will fall-back to and return "EN" (which they don't speak), as opposed to "FR", which they do speak, and which we have a bundle for.
I could check to see if the ResourceBundle I got back is an exact match, and if not, try another locale from the request list, but things get more complicated if, for example, my servlet supports { "EN", "FR-XX" } and/or they ask for "FR-YY".
I wish there was a ResourceBundle.getBundle(String baseName, List<Locale> locales). Can the ICU project help me out here?
John is driving the inheritance issues on the CLDR side, so I reassigned this to him until we figure out what to do.
related to #8111
srl on the hook too because #8111 closed
Moving to UNSCH for the time being. I can't see us getting to this in the 4.8 timeframe, and I am wondering about the priority of this as well.