PropertyMessageResources behaviour different from PropertyResourceBundle

• Key: STR-2077
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Niall Pemberton
• Reporter: Alexander Daryin
• Component/s: Core
• Affects Version/s: 1.1.0
• Fix Version/s: 1.3.6

Environment

Operating System: All
Platform: All

Description

It is stated in the javadoc of PropertyMessageResources that it "reads message
keys and corresponding strings from named property resources in the same manner
that <code>java.util.PropertyResourceBundle</code> does."

[Property]ResourceBundle defines the following order of traversal:
baseName + "_" + language1 + "_" + country1 + "_" + variant1
baseName + "_" + language1 + "_" + country1
baseName + "_" + language1
baseName + "_" + language2 + "_" + country2 + "_" + variant2
baseName + "_" + language2 + "_" + country2
baseName + "_" + language2
baseName

(1 is user locale, 2 is default locale)

In fact, PropertyMessageResources tries these keys:
baseName + "_" + language1 + "_" + country1 + "_" + variant1
baseName + "_" + language1 + "_" + country1
baseName + "_" + language1
baseName + "_" + default locale
baseName

This causes serious problems with localization.

Example:

I have the following localizations:
resources.properties - default strings (English)
resources_ru.properties - localization to Russian

Default locale is ru_RU (Russian, Russia). A client connects with locale uk
(Ukrainian). As far as there is no Ukrainian localization, I expect that he
will see messages in Russian. But since there is no localization to ru_RU, he
gets messages in English, which is inacceptible.

Comments

[Ted Husted]

Struts does not automatically accept the client browser's locale. The locale is
only changed when your code changes it, so you have all the flexibility you need
to select ru for uk clients.

[Alexander Daryin]

Of course, I can programmatically select "ru" for "uk" clients, but this does
not solve the problem. Suppose I have two sets of localization files:

first.properties
first_ru.properties

second.properties
second_ru.properties
second_uk.properties

If I view a page with "uk" locale, Struts will choose "first.properties"
and "second_uk.properties".

If I forcibly change "uk" to "ru", Struts will choose "first_ru.properties"
and "second_ru.properties".

But if I use PropertyResourceBundle and request bundles for "uk", it will
return "first_ru.properties" and "second_uk.properties".

Wy cannot Struts implement exactly the same behaviour, especially if such
behaviour is stated in the documentation?

[Joe Hertz]

I think I see your complaint. Allow me to put it another way.

Example:

You have a WebApplication supporting english (default props file) and russian.

You also have a User X whose browser generates accept-language headers for
Spanish and Russian in that order.

Youre saying that this user would get the English page and not Russian when
going to a page where <html:html locale="true"> or <html:html lang="true">

I have seen this myself. No idea if that deviates from the spec or not.

 I suggest attaching the example that demonstrates the difference you mention.

[Alexander Daryin]

No, this is not _that_ problem.

What I mean is the following. Suppose I have the following localization files:
language.properties (English)
language_fr.properties
language_ru.properties

I have two servers where I deploy my applications.

Server 1 resides in France. It's default locale is "fr_FR". I expect that when
a user comes with unknown locale (say, "uk_UA") then server shows pages in
French, not in English.

Server 2 resides in Russia. It's default locale is "ru_RU", and I expect "ru"
to be chosen for clients with unknown locale.

If you call ResourceBundle.get for language.properties on Server1 with
locale "uk", you get language_fr.properties. But PropertyMessageResources
returns language.properties.

If you call ResourceBundle.get for language.properties on Server2 with
locale "uk", you get language_ru.properties. PropertyMessageResources again
returns language.properties.

In other words, if I run some GUI application on Server1 and then switch it
interface to "uk", I'll get messages in French. On Server2 - in Russian. But
web applications will always show pages in English if locale "uk" is requested.

[Kuro Kurosaka]

Notion of the default locale makes sense for the desk top application where the
user has the control of the default locale. But I'm not sure if the same logic
applies to the internet web application. Also, I would like to point out that
resources.properties does not need to be in English. You can rename your
Russian resource to resources.properties on the server in Russia, and you'd get
the behavior you want.

[Ted Husted]

This has been the behavior since the beginning, and so I am marking this as an
enhancement. If a patch were offered, it would be considered, but only if
backward compatibility is retained.

I have added a "compatibility mode" configuration option to PropertyMessageResources. It can now be configured to operate in one of three modes:

1) "Default" mode - default, backwardly compatible, Struts behaviour (i.e. the way its always worked).
2) "JSTL" mode - compatible with how JSTL finds messages (fixes STR-2925)
3) "Resource" mode - compatible with how Java's <code>PropertyResourceBundle</code> finds messages (fixes STR-2077)

To configure for "JSTL" mode:

    <message-resources parameter="mypackage.MyMessageResources">
        <set-property key="mode" value="JSTL"/>
    <message-resources>

To configure for "Resource" mode:

    <message-resources parameter="mypackage.MyMessageResources">
        <set-property key="mode" value="resource"/>
    <message-resources>

http://svn.apache.org/viewvc?view=rev&revision=480549