commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mattias J <>
Subject Re: [Resources] RFE: Support for multiple Locales in Messages.getMessage
Date Sat, 14 May 2005 07:54:03 GMT
At 2005-05-13 23:03, you wrote:
>Mattias J wrote:
> > At 2005-05-11 23:47, you wrote:
> >
> >> Currently the Messages.getMessage methods only support a single Locale.
> >>  So if you had an application that provided English (default) and French
> >> resources and a user preferred to read German, French, and English (in
> >> that order), a call to Messages.getMessage(<German>, <key>) would
> >> the message from the English resource when the message from the French
> >> resource would be preferable.
> >>
> >> This RFE calls for the Messages.getMessage methods to accept an array of
> >> Locales where they currently accept a single Locale.  The implementation
> >> would then search for the specified key in each of the resources for the
> >> specified Locales in element order.
> >
> >
> > I don't even think this is possible, since Commons Resources (AFAIK)
> > uses java.utils.ResourceBundle for one of its implementations, and
> > ResourceBundle returns the resouce for the default locale, if the
> > requested locale is not found. There would therefore be no way for
> > Commons Resources to know whether the resource was found using the
> > primary locale or the default locale, and would therefore not be able to
> > tell when the secondary locale should be used.
>I believe that you can tell if you have a ResourceBundle for the
>requested Locale or the default Locale by calling
>ResourceBundle.getLocale.  You can then compare the returned Locale with
>the requested Locale and if they don't match you can try to get another
>ResourceBundle with the next Locale in the list.

That is right. I confused it with the fact that if you get a ResourceBundle 
for the requested Locale, but that bundle does not contain the requested 
key, the ResourceBundle class will look for the key in the parent bundle 
recursively, up until the default Locale.

So we might be talking about two different scenarios here:
- The primary Locale does not exist, and a secondary Locale should be used
- The requested key does not exist for the primary Locale; the Locale used 
instead cannot be determined

The case I was talking about may be a non-issue, since most localizations 
should include all the keys.

   /Mattias Jiderhamn

   Mattias Jiderhamn
   Expert Systems

   Web: <>
   Skype: <callto://mattiasj78>mattiasj78

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message