db said:
I set the system properties in the very beginning of the constructor of
the main frame
and display the system properties just before the progress monitor is
initialized.
A one sentence description of what your code does is not particularly
helpful and doesn't address the suggestion I made anyway.
I don't know you and have no idea how much experience you have with
i18n/l10n (internationalization/localization) in particular or Java in
general so forgive me for saying this if you are actually very experienced:
is it possible that you are setting the properties and locale to US English
as you've described but then fail to get the appropriate resource bundle and
text due to an error after you set the locale but before you display the
progress monitor? That would be entirely possible if you were not very
familiar with i18n/l10n.
For example, if you set your locale to US English but the title of the
progress monitor was hard-coded as:
progressMonitor.setNote("Anfangen");
then you are inevitably going to get German text, not English.
The other case where you may get a language that you don't want is if you
don't name the file containing your resource bundle correctly. That
situation is considerably harder to detect than the one where you hard-code
the text and ignore the locale.
I had similar problems to yours a couple of years back and spent a few hours
experimenting; I wrote myself some documentation to describe what I'd found.
This is it:
------------------------------------------------------------------------------------------------------------------
Locales
When your program loads a message ResourceBundle, the bundle loaded depends
on a combination of three factors: what ResourceBundle you requested, what
locale is the default for your system, and what ResourceBundles are defined
to your program. Strangely enough, number, currency, and percent formatters
will format their values in the format of the appropriate locale.
For example, suppose a program named PROG01 has a Message Base name of
PROG01_Msg. The default locale for the Java Virtual Machine running on a
given machine is 'en_CA'. The program has defined the following
ResourceBundles:
'de_DE', i.e. PROG01_Msg_de_DE.properties
'en_CA', i.e. PROG01_Msg_en_CA.properties
'en', i.e. PROG01_Msg_en.properties
'fr_CA', i.e. PROG01_Msg_fr_CA.properties
<default bundle>, i.e. PROG01_Msg.properties
The following table documents what message ResourceBundle will be loaded:
Locale chosen by user
ResourceBundle loaded
Reason
de_DE
de_DE
bundle 'de_DE' exists
de_AT
en_CA
bundle 'de_AT' does not exist and no 'de' bundle exists
de_CH
en_CA
bundle 'de_CH' does not exist and no 'de' bundle exists
fr_CH
en_CA
bundle 'fr_CH' does not exist and no 'fr' bundle exists
fr_FR
en_CA
bundle 'fr_FR' does not exist and no 'fr' bundle exists
fr_CA
fr_CA
bundle 'fr_CA' exists
en_CA
en_CA
bundle 'en_CA' exists
en_US
en
bundle 'en_US' does not exist but 'en' bundle exists
en_UK
en
bundle 'en_UK' does not exist but 'en' bundle exists
ja_JP
en_CA
bundle 'ja_JP' does not exist and no 'ja' bundle exists
Note: Number formatters will give numbers in the locale chosen by the user,
NOT the locale indicated by the above table. For example, if the user chose
the locale fr_CH in the above scenario, numbers will still be formatted in
fr_CH style (with "S. Fr" in front of currency amounts) even though all
messages will come from the en_CA message bundle.
If we modify the above scenario so that the only ResourceBundles defined to
the program are 'de_DE', 'en', 'fr_CA', and the default bundle (i.e. we have
eliminated the en_CA bundle, which corresponds to our default locale) and
then let the users select the same locales, here is what will happen:
Locale chosen by user
ResourceBundle loaded
Reason
de_DE
de_DE
bundle 'de_DE' exists
de_AT
en
bundle 'de_AT' does not exist and no 'de' bundle exists
de_CH
en
bundle 'de_CH' does not exist and no 'de' bundle exists
fr_CH
en
bundle 'fr_CH' does not exist and no 'fr' bundle exists
fr_FR
en
bundle 'fr_FR' does not exist and no 'fr' bundle exists
fr_CA
fr_CA
bundle 'fr_CA' exists
en_CA
en
bundle 'en_CA' does not exist but 'en' bundle exists
en_US
en
bundle 'en_US' does not exist but 'en' bundle exists
en_UK
en
bundle 'en_UK' does not exist but 'en' bundle exists
ja_JP
en
bundle 'ja_JP' does not exist and no 'ja' bundle exists
If we modify the above scenarios so that the only ResourceBundles defined to
the program are 'de_DE', 'fr_CA', and the default bundle (i.e. we have no
English bundles at all) and then let the users select the same locales, here
is what will happen:
Locale chosen by user
ResourceBundle loaded
Reason
de_DE
de_DE
bundle 'de_DE' exists
de_AT
default
bundle 'de_AT' does not exist and no 'de' bundle exists
de_CH
default
bundle 'de_CH' does not exist and no 'de' bundle exists
fr_CH
default
bundle 'fr_CH' does not exist and no 'fr' bundle exists
fr_FR
default
bundle 'fr_FR' does not exist and no 'fr' bundle exists
fr_CA
fr_CA
bundle 'fr_CA' exists
en_CA
default
bundle 'en_CA' does not exist and no 'en' bundle exists
en_US
default
bundle 'en_US' does not exist and no 'en' bundle exists
en_UK
default
bundle 'en_UK' does not exist and no 'en' bundle exists
ja_JP
default
bundle 'ja_JP' does not exist and no 'ja' or 'en' bundle exists
If we modify the above scenarios once again so that the only ResourceBundles
defined to the program are 'de_DE' and 'fr_CA' (i.e. the default bundle no
longer exists), this is the result:
Locale chosen by user
ResourceBundle loaded
Reason
de_DE
de_DE
bundle 'de_DE' exists
de_AT
exception
bundles 'de_AT', 'de', 'en', and default do not exist
de_CH
exception
bundles 'de_CH', 'de', 'en', and default do not exist
fr_CH
exception
bundles 'fr_CH', 'fr', 'en', and default do not exist
fr_FR
exception
bundles 'fr_FR', 'fr', 'en', and default do not exist
fr_CA
fr_CA
bundle 'fr_CA' exists
en_CA
exception
bundles 'en_CA', 'en', and default do not exist
en_US
exception
bundles 'en_US', 'en', and default do not exist
en_UK
exception
bundles 'en_UK', 'en', and default do not exist
ja_JP
exception
bundles 'ja_JP', 'ja', 'en, and default do not exist
This gives rise to an observation: if you need to ensure that the message
text is at least in the correct language, if not necessarily the correct
dialect, you must make sure that you supply a language-only bundle, e.g. if
you want to make sure that you give French-speakers from France and
Switzerland messages in French, you must create an "fr" bundle, even if you
don't create "fr_FR" or "fr_CH' bundles. Of course, French-speakers from
France and Switzerland may be dismayed to see that their messages are not in
precisely the dialect of French they wanted but they will be happier than if
they get English messages.
------------------------------------------------------------------------------------------------------------------
Now, that is probably "too much information" but I wanted to share with you
all the documentation I wrote on the subject in the hope that it would be
helpful.
In brief, you need to understand what ResourceBundle gets used if the locale
specified in your program does not exist. If you've specifed "en_US" in the
program and are still getting German, one of the following has probably
happened:
- you don't have a bundle whose name ends with _en_US, e.g.
PROG01_Msg_en_US.properties (NOTE: the hyphen in front of the "en_US" is
very important! If your base name is PROG01_Msg and your resource bundle is
called PROG01_Msgen_US.properties rather than PROG01_Msg_en_US.properties,
it will not be found and some other bundle, perhaps your German one, will be
used.)
- you do have a bundle whose name ends with _en_US, e.g.
PROG01_Msg_en_US.properties but the text in that file is in German. (Perhaps
you just forgot to translate the text in that file!)
