For more information -
http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html#getBundle(java.lang.String,%20java.util.Locale,%20java.lang.ClassLoader)
Adrian Crum wrote:
It then goes to the fallback locale - which is configurable also.
-Adrian
Daniel Martínez wrote:
I agree. Configuration of default locale through OfBiz is the way to go.
Only a note. For screen labels, what happens if a screen label does
not exist in the user locale, nor the default locale? It should then
go to english.
Then:
1- Look for label in user locale. If does not exist:
2- Look for label in default locale. If does not exist:
3- Look for label in "permanent" locale (en)
This will be interesting for Spain as there are around 3 more
languages (apart from spanish) used in the country and the default
language would be spanish, not english. I think there are more
countries in this or similar situations.
--
Daniel
Adrian Crum escribió:
It seems the issue of default locale comes up with regularity. I
believe some of the confusion or problems come from the fact that the
default locale is not handled by the framework in a structured way.
Right now the only way to set the default locale is by setting it on
the machine the JVM is running on, or through a Java command line
parameter. I think it would be better to have the default locale
configurable in OFBiz.
It would be a trivial change to make and I think it will eliminate a
lot of quirky behavior.
Some time ago I tried a default locale implementation that was
exactly like the current implementation of the default time zone, and
it worked quite well. All code called a utility method to get the
default locale, and that method retrieved the default locale from a
general.properties setting.
What do you think?
-Adrian