Re: ICU Accept Language API Proposal

Doug Felt <[email protected]> Tue, 30 Nov 2004 18:34:00 -0800 (PST)
Newsgroups gmane.comp.lib.icu.general
Message-ID <[email protected]>
For Java I prefer the version of the APIs that return ULocale, since ICU4J APIs
take ULocale.  There is no StringEnumeration either, the ICU4J APIs use arrays
of ULocale so that's what should be used instead.  The fallback parameter is
always ugly in Java since there's no pass-by-reference, it would be nice to
avoid it.  Even if we don't avoid it, it needn't be an integer.  The only
condition of interest is a boolean, and 'true' to indicate that a fallback was
returned is good enough, I expect, so the 'enum' values aren't required either.

So the Java APIs would be 

static ULocale acceptLanguage(String acceptLanguageList, ULocale[]
availableLocales, boolean[] fallback);

static ULocale acceptLanguage(ULocale[] acceptLanguageList, ULocale[]
availableLocales, boolean[] fallback);

NullPointerException is thrown if acceptLanguageList or availableLocales is
null.  If fallback is non-null, it will contain true if a fallback locale (one
not in the acceptLanguageList) was returned.  The value on entry is ignored. 
ULocale will be one of the locales in availableLocales, or the ROOT ULocale if
if a ROOT locale was used as a fallback (because nothing else in
availableLocales matched).  No ULocale array element should be null; behavior
is undefined if this is the case.

I'd provide convenience overrides of these that omit availableLocales, these
would use ULocale.getAvailableLocales implicitly.

static ULocale acceptLanguage(String acceptLanguageList, boolean[] fallback);
static ULocale acceptLanguage(ULocale[] acceptLanguageList, boolean[]
fallback);

------

An alternative is to not provide the fallback fill-in, and not do fallback,
instead just let users perform the fallback themselves.  Utility API could be
provided that generated fallback locales from a list of locales similarly to
how the original proposal described.  Then users who want to fallback could
just invoke this api and retry.  For example:

static ULocale acceptLanguage(String acceptLanguageList, ULocale[]
availableLocales);
statuc ULocale acceptLanguage(ULocale[] acceptLanguageList, ULocale
availableLocales);

static String createFallbackList(String acceptLanguageList);
static ULocale[] createFallbackList(ULocale acceptLanguageList);

use would look like this:

ULocale l = ULocale.acceptLanguage(httpAcceptLanguage, locales);
if (l == null) {
    httpAcceptLanguage = ULocale.createFallbackList(httpAcceptLanguage);
    l = ULocale.acceptLanguage(httpAcceptLanguage, locales);
    // the caller knows that a fallback locale was required
}

acceptLanguage would return null if there was no exact match, unless the root
locale was in the acceptLanguageList, in which case ULocale.ROOT would be
returned even if there was no exact match.

this is a little cleaner in Java but requires more work of the client.  just
wanted to offer it as an alternative.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com