You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ti...@sastau.it> on 2006/10/03 09:06:16 UTC
Proposed solution for the old and known English locale bug
In the attached patch there is a very simple way to fix the old and
known bug that makes impossible to display the English labels when OFBiz
is run in an operating system with a system language (different from
English) that is available in the OFBiz ui lables property files.
The bug is caused by the way the Java localization routines search for
localized files and by the fact that in OFBiz we don't maintain the en_EN
files, because the labels are in the default properties files (without
locale extension).
For example, if I run OFbiz in an operating system with locale it_IT, and
I set the language session to en_EN, the labels are shown in Italian
because the en_EN files are not found and so (before using the default
labels without locale suffix) the Java localization routine retrieves the
system langage (it_IT) and searches for property files with the it_IT
suffix (and finds them).
The proposed solution (that Jacques LeRoux already suggested in an old
Jira issue) is to use the -Duser.language=en parameter when invoking the
java command (in the OFBiz startup files): in this way the default system
locale will be the English one, and everything will work as expected... I
don't think it is a bad solution, in fact it is correct to set the JVM in
which OFBiz is running to the same locale of the default language files of
OFBiz.
Can I commit the patch?
Jacopo
Index: startofbiz.bat
===================================================================
--- startofbiz.bat (revision 452073)
+++ startofbiz.bat (working copy)
@@ -16,8 +16,8 @@
REM #####################################################################
ECHO ON
-"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -jar ofbiz.jar >
framework\logs\console.log
+"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -jar
ofbiz.jar > framework\logs\console.log
REM This one is for more of a debugging mode
-REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Xdebug -Xnoagent
-Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
ofbiz.jar > framework\logs\console.log
+REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -Xdebug
-Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
ofbiz.jar > framework\logs\console.log
Index: startofbiz.sh
===================================================================
--- startofbiz.sh (revision 452073)
+++ startofbiz.sh (working copy)
@@ -30,7 +30,8 @@
#DEBUG="-Dsun.rmi.server.exceptionTrace=true"
#RMIIF="-Djava.rmi.server.hostname=<set your IP address here>"
MEMIF="-Xms128M -Xmx256M"
-VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN"
+LANGUAGE="-Duser.language=en"
+VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN $LANGUAGE"
# Worldpay Config
#VMARGS="-Xbootclasspath/p:applications/accounting/lib/cryptix.jar $VMARGS"
Re: Proposed solution for the old and known English locale bug
Posted by Jacques Le Roux <ja...@les7arts.com>.
+1
I already use this setting for months now without any problem at all.
Jacques
----- Original Message -----
From: "Jacopo Cappellato" <ti...@sastau.it>
To: <of...@incubator.apache.org>
Sent: Tuesday, October 03, 2006 9:06 AM
Subject: Proposed solution for the old and known English locale bug
> In the attached patch there is a very simple way to fix the old and
> known bug that makes impossible to display the English labels when OFBiz
> is run in an operating system with a system language (different from
> English) that is available in the OFBiz ui lables property files.
> The bug is caused by the way the Java localization routines search for
> localized files and by the fact that in OFBiz we don't maintain the en_EN
> files, because the labels are in the default properties files (without
> locale extension).
>
> For example, if I run OFbiz in an operating system with locale it_IT, and
> I set the language session to en_EN, the labels are shown in Italian
> because the en_EN files are not found and so (before using the default
> labels without locale suffix) the Java localization routine retrieves the
> system langage (it_IT) and searches for property files with the it_IT
> suffix (and finds them).
>
> The proposed solution (that Jacques LeRoux already suggested in an old
> Jira issue) is to use the -Duser.language=en parameter when invoking the
> java command (in the OFBiz startup files): in this way the default system
> locale will be the English one, and everything will work as expected... I
> don't think it is a bad solution, in fact it is correct to set the JVM in
> which OFBiz is running to the same locale of the default language files of
> OFBiz.
>
> Can I commit the patch?
>
> Jacopo
>
>
> Index: startofbiz.bat
> ===================================================================
> --- startofbiz.bat (revision 452073)
> +++ startofbiz.bat (working copy)
> @@ -16,8 +16,8 @@
> REM #####################################################################
> ECHO ON
>
> -"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -jar ofbiz.jar >
> framework\logs\console.log
> +"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -jar
> ofbiz.jar > framework\logs\console.log
>
> REM This one is for more of a debugging mode
> -REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Xdebug -Xnoagent
> -Djava.compiler=NONE
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
> ofbiz.jar > framework\logs\console.log
> +REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -Xdebug
> -Xnoagent -Djava.compiler=NONE
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
> ofbiz.jar > framework\logs\console.log
>
> Index: startofbiz.sh
> ===================================================================
> --- startofbiz.sh (revision 452073)
> +++ startofbiz.sh (working copy)
> @@ -30,7 +30,8 @@
> #DEBUG="-Dsun.rmi.server.exceptionTrace=true"
> #RMIIF="-Djava.rmi.server.hostname=<set your IP address here>"
> MEMIF="-Xms128M -Xmx256M"
> -VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN"
> +LANGUAGE="-Duser.language=en"
> +VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN $LANGUAGE"
>
> # Worldpay Config
> #VMARGS="-Xbootclasspath/p:applications/accounting/lib/cryptix.jar $VMARGS"
>
>
Re: Question on extend-entity
Posted by David E Jones <jo...@undersunconsulting.com>.
Probably because those services internally are not as generic as they
should be...
BTW, there is already a place for a phone number extension, is on the
PartyContactMech entity.
-David
On Oct 4, 2006, at 1:34 PM, Amit Shinde wrote:
> Hello,
> I am using extend-entity ability to add more fields to an existing
> OFBiz
> entity. These fields are not relational. I am trying to extend
> TelecomNumber
> table and add a field 'extn' to it. This field represents the Phone
> Extension Number. This field is created in the table but no data is
> persisted. We call 'createPartyTelecomNumber' service of OFBiz
> which in turn
> calls 'createTelecomNumber'. Both these service take auto-
> attributes of the
> TelecomNumber entity for input mode. So, inspite of passing the 'extn'
> parameter, it is still not persisted. I cant figure out on what the
> reason
> is. Any insight will be appreciated.
>
>
> <extend-entity entity-name="TelecomNumber">
> <field name="extnNumber" type="short-varchar"></field>
> </extend-entity>
>
> <service name="createTelecomNumber" engine="simple"
> location="org/ofbiz/party/contact/ContactMechServices.xml"
> invoke="createTelecomNumber" auth="true">
> <description>Create a Telecommunications Number</description>
> <auto-attributes entity-name="TelecomNumber" include="all"
> mode="IN"
> optional="true"/>
> <attribute name="contactMechId" type="String" mode="OUT"
> optional="false"/>
> </service>
>
> <service name="createPartyTelecomNumber" engine="simple"
> location="org/ofbiz/party/contact/
> PartyContactMechServices.xml"
> invoke="createPartyTelecomNumber" auth="true">
> <description>Create a Telecommunications Number</description>
> <auto-attributes entity-name="PartyContactMech" include="all"
> mode="IN" optional="true"/>
> <auto-attributes entity-name="TelecomNumber" include="nonpk"
> mode="IN" optional="true"/>
> <attribute name="contactMechPurposeTypeId" type="String"
> mode="IN"
> optional="true"/>
> <attribute name="contactMechId" type="String" mode="OUT"
> optional="false"/>
> </service>
>
>
>
> Thanks in advance,
>
> Amit Shinde
>
>
Question on extend-entity
Posted by Amit Shinde <am...@amicontech.com>.
Hello,
I am using extend-entity ability to add more fields to an existing OFBiz
entity. These fields are not relational. I am trying to extend TelecomNumber
table and add a field 'extn' to it. This field represents the Phone
Extension Number. This field is created in the table but no data is
persisted. We call 'createPartyTelecomNumber' service of OFBiz which in turn
calls 'createTelecomNumber'. Both these service take auto-attributes of the
TelecomNumber entity for input mode. So, inspite of passing the 'extn'
parameter, it is still not persisted. I cant figure out on what the reason
is. Any insight will be appreciated.
<extend-entity entity-name="TelecomNumber">
<field name="extnNumber" type="short-varchar"></field>
</extend-entity>
<service name="createTelecomNumber" engine="simple"
location="org/ofbiz/party/contact/ContactMechServices.xml"
invoke="createTelecomNumber" auth="true">
<description>Create a Telecommunications Number</description>
<auto-attributes entity-name="TelecomNumber" include="all" mode="IN"
optional="true"/>
<attribute name="contactMechId" type="String" mode="OUT"
optional="false"/>
</service>
<service name="createPartyTelecomNumber" engine="simple"
location="org/ofbiz/party/contact/PartyContactMechServices.xml"
invoke="createPartyTelecomNumber" auth="true">
<description>Create a Telecommunications Number</description>
<auto-attributes entity-name="PartyContactMech" include="all"
mode="IN" optional="true"/>
<auto-attributes entity-name="TelecomNumber" include="nonpk"
mode="IN" optional="true"/>
<attribute name="contactMechPurposeTypeId" type="String" mode="IN"
optional="true"/>
<attribute name="contactMechId" type="String" mode="OUT"
optional="false"/>
</service>
Thanks in advance,
Amit Shinde
Re: Proposed solution for the old and known English locale bug
Posted by Jacopo Cappellato <ti...@sastau.it>.
Ok,
this is now in svn rev. 452792
Jacopo
David E Jones wrote:
>
> I think that's fine. It has minimal impact on things, well really no
> significant impact for most users except to correct this issue but
> change the default locale.
>
> Hopefully at some point we'll be able to change the internationalization
> code to not use the PITA Java ResourceBundle stuff... and then these
> problems will just disappear... ;)
>
> -David
>
>
> On Oct 3, 2006, at 8:06 AM, Jacopo Cappellato wrote:
>
>> In the attached patch there is a very simple way to fix the old and
>> known bug that makes impossible to display the English labels when OFBiz
>> is run in an operating system with a system language (different from
>> English) that is available in the OFBiz ui lables property files.
>> The bug is caused by the way the Java localization routines search for
>> localized files and by the fact that in OFBiz we don't maintain the en_EN
>> files, because the labels are in the default properties files (without
>> locale extension).
>>
>> For example, if I run OFbiz in an operating system with locale it_IT, and
>> I set the language session to en_EN, the labels are shown in Italian
>> because the en_EN files are not found and so (before using the default
>> labels without locale suffix) the Java localization routine retrieves the
>> system langage (it_IT) and searches for property files with the it_IT
>> suffix (and finds them).
>>
>> The proposed solution (that Jacques LeRoux already suggested in an old
>> Jira issue) is to use the -Duser.language=en parameter when invoking the
>> java command (in the OFBiz startup files): in this way the default system
>> locale will be the English one, and everything will work as expected... I
>> don't think it is a bad solution, in fact it is correct to set the JVM in
>> which OFBiz is running to the same locale of the default language
>> files of
>> OFBiz.
>>
>> Can I commit the patch?
>>
>> Jacopo
>>
>>
>> Index: startofbiz.bat
>> ===================================================================
>> --- startofbiz.bat (revision 452073)
>> +++ startofbiz.bat (working copy)
>> @@ -16,8 +16,8 @@
>> REM
>> #####################################################################
>> ECHO ON
>>
>> -"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -jar ofbiz.jar >
>> framework\logs\console.log
>> +"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -jar
>> ofbiz.jar > framework\logs\console.log
>>
>> REM This one is for more of a debugging mode
>> -REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Xdebug -Xnoagent
>> -Djava.compiler=NONE
>> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
>> ofbiz.jar > framework\logs\console.log
>> +REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -Xdebug
>> -Xnoagent -Djava.compiler=NONE
>> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
>> ofbiz.jar > framework\logs\console.log
>>
>> Index: startofbiz.sh
>> ===================================================================
>> --- startofbiz.sh (revision 452073)
>> +++ startofbiz.sh (working copy)
>> @@ -30,7 +30,8 @@
>> #DEBUG="-Dsun.rmi.server.exceptionTrace=true"
>> #RMIIF="-Djava.rmi.server.hostname=<set your IP address here>"
>> MEMIF="-Xms128M -Xmx256M"
>> -VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN"
>> +LANGUAGE="-Duser.language=en"
>> +VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN $LANGUAGE"
>>
>> # Worldpay Config
>> #VMARGS="-Xbootclasspath/p:applications/accounting/lib/cryptix.jar
>> $VMARGS"
>>
>>
>>
>
Re: Proposed solution for the old and known English locale bug
Posted by David E Jones <jo...@undersunconsulting.com>.
I think that's fine. It has minimal impact on things, well really no
significant impact for most users except to correct this issue but
change the default locale.
Hopefully at some point we'll be able to change the
internationalization code to not use the PITA Java ResourceBundle
stuff... and then these problems will just disappear... ;)
-David
On Oct 3, 2006, at 8:06 AM, Jacopo Cappellato wrote:
> In the attached patch there is a very simple way to fix the old and
> known bug that makes impossible to display the English labels when
> OFBiz
> is run in an operating system with a system language (different from
> English) that is available in the OFBiz ui lables property files.
> The bug is caused by the way the Java localization routines search for
> localized files and by the fact that in OFBiz we don't maintain the
> en_EN
> files, because the labels are in the default properties files (without
> locale extension).
>
> For example, if I run OFbiz in an operating system with locale
> it_IT, and
> I set the language session to en_EN, the labels are shown in Italian
> because the en_EN files are not found and so (before using the default
> labels without locale suffix) the Java localization routine
> retrieves the
> system langage (it_IT) and searches for property files with the it_IT
> suffix (and finds them).
>
> The proposed solution (that Jacques LeRoux already suggested in an old
> Jira issue) is to use the -Duser.language=en parameter when
> invoking the
> java command (in the OFBiz startup files): in this way the default
> system
> locale will be the English one, and everything will work as
> expected... I
> don't think it is a bad solution, in fact it is correct to set the
> JVM in
> which OFBiz is running to the same locale of the default language
> files of
> OFBiz.
>
> Can I commit the patch?
>
> Jacopo
>
>
> Index: startofbiz.bat
> ===================================================================
> --- startofbiz.bat (revision 452073)
> +++ startofbiz.bat (working copy)
> @@ -16,8 +16,8 @@
> REM
> #####################################################################
> ECHO ON
>
> -"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -jar ofbiz.jar >
> framework\logs\console.log
> +"%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -jar
> ofbiz.jar > framework\logs\console.log
>
> REM This one is for more of a debugging mode
> -REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Xdebug -Xnoagent
> -Djava.compiler=NONE
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
> ofbiz.jar > framework\logs\console.log
> +REM "%JAVA_HOME%\bin\java" -Xms256M -Xmx512M -Duser.language=en -
> Xdebug
> -Xnoagent -Djava.compiler=NONE
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -jar
> ofbiz.jar > framework\logs\console.log
>
> Index: startofbiz.sh
> ===================================================================
> --- startofbiz.sh (revision 452073)
> +++ startofbiz.sh (working copy)
> @@ -30,7 +30,8 @@
> #DEBUG="-Dsun.rmi.server.exceptionTrace=true"
> #RMIIF="-Djava.rmi.server.hostname=<set your IP address here>"
> MEMIF="-Xms128M -Xmx256M"
> -VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN"
> +LANGUAGE="-Duser.language=en"
> +VMARGS="$MEMIF $DEBUG $RMIIF $ADMIN $LANGUAGE"
>
> # Worldpay Config
> #VMARGS="-Xbootclasspath/p:applications/accounting/lib/cryptix.jar
> $VMARGS"
>
>
>