Hi Tex,
There is a not-all-that-straightforward method that I've seen which
might fit your needs.
First: establish your resource bundle locale as separate from the
currently active locale (e.g. have a variable for your resource locale and
use it to explicitly load the resources rather than using the program
locale and letting Java determine locale for you). This will allow you to
control the loading of the resource bundle YOU WANT to be associated with
a specific locale.
Second: Create a resource bundle called "ResourceLocale.properties" in the
format:
<locale_installed>=<locale_to_use>
where locale_installed is the name of the installed locale (like es_EC for
Ecuador) and locale_to_use is the name of the locale of the resource
bundle you'd like to contain the messages (es_CO for Latin America, for
example). This sounds awful, but there are only 144 installed locales in
JDK 1.3 (cf. http://www.inter-locale.com/demos/locales.jsp), at least on
Linux that's the number... and you only have to do it once.
It is not performance enhancing, but it does provide a quick-and-dirty way
of getting around the problem you describe. That way "es" can be whichever
variant you prefer and the defaulting mechanism still works for things
like NumberFormet and the like. In any case, it makes some sense to
control bundle loading like this anyway, because there are some vague
cases in the locale model (like LA Spanish).
You may also find that you need TWO resource bundle sets, one with
localizable strings (e.g. locale_to_use) and one with locale-related
strings that are not for localization (e.g. the regular resource bundle).
The downside to this solution is that it makes code devilishly difficult
to read (by comparison) and can confuse developers (who have to remember
what goes where).
Regards,
Addison
===========================================================
Addison P. Phillips Principal Consultant
Inter-Locale LLC http://www.inter-locale.com
Los Gatos, CA, USA mailto:addison@inter-locale.com
+1 408.210.3569 (mobile) +1 408.904.4762 (fax)
===========================================================
Globalization Engineering & Consulting Services
On Wed, 26 Jul 2000, Tex Texin wrote:
> I wonder how others are dealing with problems like the
> following:
>
> I have a Java program for which I also have a translation for Latin America.
> I know there are differences among the Latin American dialects, but I am
> told this file is ok for all Latin America. At the same time it is not
> for use in Spain, so I have a different file for that.
>
> I have not found a locale for Latin America. I am reluctant to create
> locales for each country in L.A. as I guess it is too likely I will
> get it wrong, and it also increases the disk footprint of the program.
>
> I do not want to simply make this translation the default (es), as I am
> concerned I do not know all of the places where the preferred language is
> Castillian Spanish, and for these I would need to make an exception.
>
> Any good ways around this, or do I need to simply bite the bullet and
> make one variation for every country.
>
> tex
>
> --
> If practice makes perfect, and nobody's perfect, why practice?
> ----------------------------------------------------------------------------
> Tex Texin Director, International Products
> mailto:texin@progress.com +1-781-280-4271 Fax:+1-781-280-4655
> Progress Software Corp. 14 Oak Park, Bedford, MA 01730
>
> http://www.progress.com #1 Embedded Database
> http://www.SonicMQ.com JMS Messaging- Best Middleware Award
> http://www.aspconnections.com #1 provider in the ASP marketplace
> http://www.NuSphere.com Open Source software and services for MySQL
>
> Globalization Program http://www.progress.com/partners/globalization.htm
> -----------------------------------------------------------------------------
> Come to the Panel on Open Source Approaches to Unicode Libraries
> at the Sept. Unicode Conference http://www.unicode.org/iuc/iuc17
>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:06 EDT