Feature request for supporting extended locale fallback


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.


July 1, 2018, 12:03 AM
Trac Comment 4 by chris@740c518763f3afe1—2007-12-29T23:32:40.000Z

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?

July 1, 2018, 12:03 AM
Trac Comment 8 by —2010-11-02T21:07:06.649Z

John is driving the inheritance issues on the CLDR side, so I reassigned this to him until we figure out what to do.

July 1, 2018, 12:03 AM
Trac Comment 9 by —2010-11-09T18:31:38.578Z

related to #8111

July 1, 2018, 12:03 AM
Trac Comment 12 by —2011-02-15T18:41:54.883Z

srl on the hook too because #8111 closed

July 1, 2018, 12:03 AM
Trac Comment 13 by —2011-03-23T20:28:32.761Z

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.


John Emmons










Time Needed


Fix versions