Pierre van Rooden wrote:
Michiel Meeuwissen wrote:
default locale is not necessary en, so _en files must be available
too. (perhaps the normal .properties files can be removed?)
IIRC the normal .properties files are used if no file can be found for
the given locale.
So even if you have a system with, say, default locale 'es', if you
specify 'en' as a locale, and it can't find the _en file, it should
use the normal property file instead.
So why do we need an _en file if the default file contains this value
and the system defaults to it? It only sounds like more work.
And leaving the normal property files out means that systems with
different default locales fail to load even the default (english)
values, unlesh you explixitly specify 'en' or make custom localized
property files.
Anyway, I *thought* that's how it worked. If not, maybe you can
elaborate?
Yhis is the way ResourceBundles work. getBundle will try to match the
locale as close as possible (language, country, variant). When no bundle
matched the locale then the default will be used.
It is sometimes hard to reproduce this behavior in your browser when you
have multiple languages in your preferences. All languages are send to
the server in the http accept-language header. The server will try all
languages with the ResourceBundles in the order they arrive. Some
scenarios to make it more clear
Scemario 1
User semds en_US amd nl_NL
Server has resourcebundles:: names.properties and names_nl.properties
Response will display values from names_nl.proeprties
Scemario 2
User semds en_US amd nl_NL
Server has resourcebundles:: names.properties names_en.properties and
names_nl.properties
Response will display values from names_en.proeprties
Scemario 3
User semds nl_NL and en_US
Server has resourcebundles:: names.properties names_en.properties and
names_nl.properties
Response will display values from names_nl.proeprties
Scemario 4
User semds fr_FR
Server has resourcebundles:: names.properties names_en.properties and
names_nl.properties
Response will display values from names.proeprties
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
