OFBiz and the default locale

[Adrian Crum]

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

[Daniel Martínez-4]

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

[Adrian Crum]

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
>

[Adrian Crum]

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
>>
>

[Bruno Busco]

I agree to add a default locale property in a way similar to
"currency.uom.id.default"

-Bruno

2008/5/12 Adrian Crum <[hidden email]>:

> 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)<http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html#getBundle%28java.lang.String,%20java.util.Locale,%20java.lang.ClassLoader%29>
>
>
>
> 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
> > > >
> > >
> > >
> >

[Jacques Le Roux]

Adrian (and others),

Also please remember this issue https://issues.apache.org/jira/browse/OFBIZ-1696

Thanks

Jacques

From: "Adrian Crum" <[hidden email]>

> 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
>

[Adrian Crum]

I have been playing around with this idea and I have come up with a
better solution.

My original idea was to have a UtilMisc.getDefaultLocale() method that
would return the configured default locale - just like the existing
UtilDateTime.getDefaultTimeZone() returns the configured default time zone.

The disadvantage to that approach is that all Locale.getDefault() and
TimeZone.getDefault() method calls have to be changed to the utility
class method calls. An extensive and heavy-handed change.

There is a way to set the JVM default locale and time zone in Java. I'd
like to put that code in the Start class - so that those values are set
before any other classes are loaded (which may rely upon those defaults).

-Adrian

Adrian Crum wrote:

> 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
>

[Jacques Le Roux]

+1

Jacques

From: "Adrian Crum" <[hidden email]>

>I have been playing around with this idea and I have come up with a
> better solution.
>
> My original idea was to have a UtilMisc.getDefaultLocale() method that
> would return the configured default locale - just like the existing
> UtilDateTime.getDefaultTimeZone() returns the configured default time zone.
>
> The disadvantage to that approach is that all Locale.getDefault() and
> TimeZone.getDefault() method calls have to be changed to the utility
> class method calls. An extensive and heavy-handed change.
>
> There is a way to set the JVM default locale and time zone in Java. I'd
> like to put that code in the Start class - so that those values are set
> before any other classes are loaded (which may rely upon those defaults).
>
> -Adrian
>
> Adrian Crum wrote:
>> 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
>>
>

[Adrian Crum]

Jacques (or anyone interested),

Could you take a look at the latest patch in
https://issues.apache.org/jira/browse/OFBIZ-1696 ? It contains all of
the changes I plan to commit.

-Adrian

Jacques Le Roux wrote:

> +1
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> I have been playing around with this idea and I have come up with a
>> better solution.
>>
>> My original idea was to have a UtilMisc.getDefaultLocale() method that
>> would return the configured default locale - just like the existing
>> UtilDateTime.getDefaultTimeZone() returns the configured default time
>> zone.
>>
>> The disadvantage to that approach is that all Locale.getDefault() and
>> TimeZone.getDefault() method calls have to be changed to the utility
>> class method calls. An extensive and heavy-handed change.
>>
>> There is a way to set the JVM default locale and time zone in Java.
>> I'd like to put that code in the Start class - so that those values
>> are set before any other classes are loaded (which may rely upon those
>> defaults).
>>
>> -Adrian
>>
>> Adrian Crum wrote:
>>> 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
>>>
>>
>

[Jacques Le Roux]

OK, I give it a try...

Jacques

From: "Adrian Crum" <[hidden email]>

> Jacques (or anyone interested),
>
> Could you take a look at the latest patch in
> https://issues.apache.org/jira/browse/OFBIZ-1696 ? It contains all of
> the changes I plan to commit.
>
> -Adrian
>
> Jacques Le Roux wrote:
>> +1
>> Jacques
>>
>> From: "Adrian Crum" <[hidden email]>
>>> I have been playing around with this idea and I have come up with a
>>> better solution.
>>>
>>> My original idea was to have a UtilMisc.getDefaultLocale() method that
>>> would return the configured default locale - just like the existing
>>> UtilDateTime.getDefaultTimeZone() returns the configured default time
>>> zone.
>>>
>>> The disadvantage to that approach is that all Locale.getDefault() and
>>> TimeZone.getDefault() method calls have to be changed to the utility
>>> class method calls. An extensive and heavy-handed change.
>>>
>>> There is a way to set the JVM default locale and time zone in Java.
>>> I'd like to put that code in the Start class - so that those values
>>> are set before any other classes are loaded (which may rely upon those
>>> defaults).
>>>
>>> -Adrian
>>>
>>> Adrian Crum wrote:
>>>> 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
>>>>
>>>
>>
>