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


Reply via email to