Revision history for MultiLanguageNumbers


Revision [2284]

Last edited on 2011-12-04 02:11:52 by PhilDaintree
Deletions:
I have divided the scripts up between those that are helping with this project - see the link below:
[[ScriptsDisplayNumbers Allocation of Scripts That Use locale_number_format() function]]
[[http://web-erp.svn.sourceforge.net/viewvc/web-erp/trunk/PcAssignCashToTab.php?r1=4682&r2=4684 Example Diff showing What was changed in PcAssignCashToTab.php]]

Revision [2283]

Edited on 2011-12-04 02:10:31 by PhilDaintree
Additions:
This work was completed in November 2011 and the first stable release containing this code was 4.06.2

Revision [2246]

Edited on 2011-10-26 22:22:08 by PhilDaintree
Additions:
In addition it is vital that a number is passed only once through this function. Consider the locale for French where the thousands separator is a "." and the decimal point is a ",". When we get numbers from a $_POST we assume they are entered the French way and replace all "." with nothing to eliminate the thousands separators altogether and replace the decimal point "," with the SQL and en_* standard ".". Now if this value goes through the filter_number_format() again the "." will be removed as the function will assume it is a thousands separator. This is the other advantage of setting the LC_NUMERIC locale to en_US as we can then focus on converting input from the user with filter_number_format() and ensuring output of numbers and values in $_POST variables echoed to users is in the locale_number_format()

Revision [2245]

Edited on 2011-10-26 21:52:28 by PhilDaintree
Additions:
Initially I thought that for numbers to be recognised as numbers and for calculations to work with numbers formatted in the users locale with appropriate thousands separators and decimal points we must use either:
LC_ALL sets all settings for the locale to the user selected locale. However, it does not set LC_MESSAGES to the locale for some reason which I don't understand.
To use the locale to determine the format of numbers and return numbers with appropriate locale character separators and decimal points we would need to use:
However, some may wish to use translations but not actually have the locale required on the server. We only used to set the locale when the system was using the gettext for translations.
For maximum compatibility we need a solution which does not require the locale to be installed on the server or require the locale to be set..
We can actually do transalations without relying on having the necessary locale installed on the web-server using the clever php-gettext. Without the locale installed on the web-server then of course the characters for decimal_point and thousands_sep cannot be determined by reference to the locale_conv() array. So to enable a comprehensive solution that allows numbers to be formatted appropriately irrespective of the installed locales I have also extended the LanguagesArray in includes/LanguagesArray.php to have elements for Thousands_Separator and Decimal_Point. Rather than rely on the values returned from localeconv for thousands separator and decimal point we are using our own hard coded characters from the LanguagesArray.
I had thought that the number_format function would be smart enough to display numbers in the user's locale correctly. However, it appears not. Since we now set the $DecimalPoint character and $ThousandsSeparator in the includes/LanguageSetup.php script we need to refer to these in the new function to format numbers as per the user's locale.
A new function locale_number_format uses the additional parameters to the number_format function to return numbers formatted appropriately for the locale. This is in the file includes/MiscFunctions.php
global $DecimalPoint;
global $ThousandsSeparator;
return number_format($Number,$DecimalPlaces,$DecimalPoint,$ThousandsSeparator;
global $DecimalPoint;
global $ThousandsSeparator;
return str_replace($DecimalPoint,'.',str_replace($ThousandsSeparator,'',$Number));
PHP actually does have a function already that does a similar thing for money formats called money_format - the syntax of this function is a bit weird though. The other stumbling block with this function that Tim noted was that it doesn't actually work under Windows!
Tim pointed out that some locales use a different characters again for formatting currency numbers as opposed to quantity numbers. However, due to the complexity this results in I decided not to go down this track ... just yet.
Numbers input in the locale of the user could potentially cause issues, as it seems that all arithmetic in PHP takes place using full stops for decimal points and no thousands separator. As noted the results of any calculations seem to be returned in the format of the locale. To get numbers that are input converted to numbers that the system can use we need to pass them through a new function. If we were using a locale that did not have a period as a decimal point, we would also need to filter the results of all calculations through the filter_number_format().
Deletions:
in order to display web-pages in the users locale with appropriate thousands separators and decimal points we must use either:
LC_ALL sets all settings for the locale to the user selected locale. However, it does not set LC_MESSAGES to the locale for some reason which I don't understand. I have settled on:
We used to only set the locale when the system was using the gettext for translations. However, if we are using the locale to display numbers correctly too so we need to set the locale correctly which ever method we are using to translate language strings.
Since not all servers that can run webERP with translations will have the appropriate locales installed on them it would be nice to offer a solution which does not require the locale to be installed on the server.
HOWEVER, we can actually do transalations without relying on having the necessary locale installed on the web-server using the clever php-gettext. Without the locale installed on the web-server then of course the characters for decimal_point and thousands_sep cannot be determined. To enable a comprehensive fall-back solution that allows numbers to be formatted appropriately I have also extended the LanguagesArray in includes/LanguagesArray.php to have elements for Thousands_Separator and Decimal_Point. Rather than rely on the values returned from localeconv for thousands separator and decimal point we are using our own hard coded characters from the LanguagesArray.
I had thought that the number_format function would be smart enough to display numbers in the user's locale correctly. However, it appears not.
The function [[http://nz.php.net/manual/en/function.localeconv.php localeconv()]] returns an array containing the thousands_sep and decimal_point characters of the locale. Tim developed a nice function that uses this to format numbers appropriately for the locale. He put this in the file includes/MiscFunctions.php
global $LocaleInfo;
return number_format($Number,$DecimalPlaces,$LocaleInfo['decimal_point'],$LocaleInfo['thousands_sep']);
function locale_money_format($Number, $DecimalPlaces) {
return money_format('%!.' . $DecimalPlaces . 'n',$Number);
global $LocaleInfo;
return str_replace($LocaleInfo['decimal_point'],'.',str_replace($LocaleInfo['thousands_sep'],'',$Number));
PHP actually does have a function already that does a similar thing for money formats called money_format - the syntax of this function is a bit weird though. The other stumbling block with this function that Tim noted was that it doesn't actually work under Windows.
Tim pointed out that some locales use a different characters again for formatting currency numbers as opposed to quantity numbers, so another function locale_money_format is also required. Due to the complexity this results in I decided not to go down this track ... just yet.
Numbers input in the locale of the user could potentially cause issues, as it seems that all arithmetic in PHP takes place using full stops for decimal points and no thousands separator (OR the locale of the server?? in which case the filter_number_format function will need some modification). As noted the results of any calculations seem to be returned in the format of the locale. To get numbers that are input converted to numbers that the system can use we need to pass them through a new function. If we were using a locale that did not have a period as a decimal point, we would also need to filter the results of all calculations through the filter_number_format().

Revision [2200]

Edited on 2011-10-02 01:46:12 by PhilDaintree
Additions:
We used to only set the locale when the system was using the gettext for translations. However, if we are using the locale to display numbers correctly too so we need to set the locale correctly which ever method we are using to translate language strings.
Since not all servers that can run webERP with translations will have the appropriate locales installed on them it would be nice to offer a solution which does not require the locale to be installed on the server.
HOWEVER, we can actually do transalations without relying on having the necessary locale installed on the web-server using the clever php-gettext. Without the locale installed on the web-server then of course the characters for decimal_point and thousands_sep cannot be determined. To enable a comprehensive fall-back solution that allows numbers to be formatted appropriately I have also extended the LanguagesArray in includes/LanguagesArray.php to have elements for Thousands_Separator and Decimal_Point. Rather than rely on the values returned from localeconv for thousands separator and decimal point we are using our own hard coded characters from the LanguagesArray.
Someone who knows the appropriate characters for each language will have to tell me - as I have guessed them at this stage.
Changing the LC_NUMERIC locale actually causes complications for the code as any calculations made returns values formatted in the locale and SQL can only use numbers formatted with no thousands separator and a period as a decimal point.
Originally I was thinking we should convert all these calculations back to the SQL format, but this is silly in my view best to adopt LC_NUMERIC locale that SQL likes (en_US - or windows english-us)and just filter input coming back from the user and display in the format the user likes.
I had thought that the number_format function would be smart enough to display numbers in the user's locale correctly. However, it appears not.
Tim pointed out that some locales use a different characters again for formatting currency numbers as opposed to quantity numbers, so another function locale_money_format is also required. Due to the complexity this results in I decided not to go down this track ... just yet.
Numbers input in the locale of the user could potentially cause issues, as it seems that all arithmetic in PHP takes place using full stops for decimal points and no thousands separator (OR the locale of the server?? in which case the filter_number_format function will need some modification). As noted the results of any calculations seem to be returned in the format of the locale. To get numbers that are input converted to numbers that the system can use we need to pass them through a new function. If we were using a locale that did not have a period as a decimal point, we would also need to filter the results of all calculations through the filter_number_format().
Deletions:
We used to only set the locale when the system was using the gettext for translations. However, now we are using the locale to display numbers correctly too so we need to set the locale correctly which ever method we are using to translate language strings.
HOWEVER, we can actually do transalations without relying on having the necessary locale installed on the web-server using the clever php-gettext. Without the locale installed on the web-server then of course the characters for decimal_point and thousands_sep cannot be determined. To enable a comprehensive fall-back solution that allows numbers to be formatted appropriately I have also extended the LanguagesArray in includes/LanguagesArray.php to have elements for Thousands_Separator and Decimal_Point. If any of the characters returned from localeconv are empty then we set them using our fall back options from this array. Someone who knows the appropriate characters for each language will have to tell me - as I have guessed them at this stage.
I had thought that the number_format would be smart enough to display numbers in the user's locale correctly. However, it appears not.
Tim pointed out that some locales use a different characters again for formatting currency numbers as opposed to quantity numbers, so another function locale_money_format is also required.
Numbers input in the locale of the user could potentially cause issues, as it seems that all arithmetic in PHP takes place using full stops for decimal points and no thousands separator (OR the locale of the server?? in which case the filter_number_format function will need some modification). However, the results of any calculations seem to be returned in the format of the locale. To get numbers that are input converted to numbers that the system can use we need to pass them through a new function. Also, the results of calculations need also to be run through the filter_number_format().
~1) Replacing the function locale_number_format() with the locale_money_format function (which takes the same parameters) when the variable being formatted is money. You could use and find and replace - provided the find and replace function of the editor allows you to interactively choose of whether to replace or not following a find.
~1) The result of any calculations performed will also be returned as numbers in the format of the locale so these also need to be run through the filter_number_format() function before going into SQL
~1) If the result of a calculation is used again in a calculation then dodgy results can come back so the parameters of calculations also need to be run through filter_number_format() function

Revision [2175]

Edited on 2011-09-23 17:57:46 by PhilDaintree
Additions:
===What If the Locale is Not Installed on the Web-Server===
HOWEVER, we can actually do transalations without relying on having the necessary locale installed on the web-server using the clever php-gettext. Without the locale installed on the web-server then of course the characters for decimal_point and thousands_sep cannot be determined. To enable a comprehensive fall-back solution that allows numbers to be formatted appropriately I have also extended the LanguagesArray in includes/LanguagesArray.php to have elements for Thousands_Separator and Decimal_Point. If any of the characters returned from localeconv are empty then we set them using our fall back options from this array. Someone who knows the appropriate characters for each language will have to tell me - as I have guessed them at this stage.
PHP actually does have a function already that does a similar thing for money formats called money_format - the syntax of this function is a bit weird though. The other stumbling block with this function that Tim noted was that it doesn't actually work under Windows.
Tim pointed out that some locales use a different characters again for formatting currency numbers as opposed to quantity numbers, so another function locale_money_format is also required.
Deletions:
PHP actually does have a function already that does a similar thing for money formats called money_format - the syntax of this function is a bit weird though. Tim pointed out that some locales use a different characters again for formatting currency numbers as opposed to quantity numbers, so another function locale_money_format is also required.

Revision [2148]

Edited on 2011-09-12 03:49:08 by PhilDaintree
Additions:
~1) If the result of a calculation is used again in a calculation then dodgy results can come back so the parameters of calculations also need to be run through filter_number_format() function
Deletions:
~1) If the result of a calculation is used again in a calculation then dodgy results can come back so the parameters of calculations also need to be run through filter_input_number() function

Revision [2145]

Edited on 2011-09-11 00:01:35 by PhilDaintree
Additions:
I have converted all occurrences of number_format() in the scripts to use the locale_number_format() function. It is possible that there are other scripts that use numbers that don't have the locale_number_format in them - these are yet to be identified.
Deletions:
I have converted all occurrences of number_format() in the scripts to use the locale_number_format() function.

Revision [2144]

Edited on 2011-09-11 00:00:00 by PhilDaintree
Additions:
~1) The result of any calculations performed will also be returned as numbers in the format of the locale so these also need to be run through the filter_number_format() function before going into SQL
Deletions:
-1) The result of any calculations performed will also be returned as numbers in the format of the locale so these also need to be run through the filter_number_format() function before going into SQL

Revision [2143]

Edited on 2011-09-10 23:59:25 by PhilDaintree
Additions:
Numbers input in the locale of the user could potentially cause issues, as it seems that all arithmetic in PHP takes place using full stops for decimal points and no thousands separator (OR the locale of the server?? in which case the filter_number_format function will need some modification). However, the results of any calculations seem to be returned in the format of the locale. To get numbers that are input converted to numbers that the system can use we need to pass them through a new function. Also, the results of calculations need also to be run through the filter_number_format().
Also critically, SQL does not deal with thousands separators at all and decimal points must be full stops as per ANSI SQL. All numbers going to SQL must be run though this filter_number_format() function.
Deletions:
Numbers input in the locale of the user could potentially cause issues, as it seems that all arithmetic in PHP takes place using full stops for decimal points and no thousands separator (OR the locale of the server?? in which case the filter_number_format function will need some modification). To get numbers that are input converted to numbers that the system can use we need to pass them through a new function. Also critically, SQL does not deal with thousands separators at all and decimal points must be full stops as per ANSI SQL. All numbers going to SQL must be run though this filter_number_format() function.

Revision [2142]

Edited on 2011-09-10 23:57:34 by PhilDaintree
Additions:
-1) The result of any calculations performed will also be returned as numbers in the format of the locale so these also need to be run through the filter_number_format() function before going into SQL
~1) If the result of a calculation is used again in a calculation then dodgy results can come back so the parameters of calculations also need to be run through filter_input_number() function
I think that's it!! However, there are a lot of scripts.... and a lot of numbers to filter :-(
Deletions:
I think that's it!! However, there are a lot of scripts....

Revision [2133]

Edited on 2011-09-10 01:02:47 by PhilDaintree
Additions:
[[ScriptsDisplayNumbers Allocation of Scripts That Use locale_number_format() function]]
[[http://web-erp.svn.sourceforge.net/viewvc/web-erp/trunk/PcAssignCashToTab.php?r1=4682&r2=4684 Example Diff showing What was changed in PcAssignCashToTab.php]]
Deletions:
[[ScriptsDisplayNumbers Scripts That Use locale_number_format() function]]

Revision [2132]

Edited on 2011-09-10 00:59:07 by PhilDaintree
Additions:
~1) Test the script and make sure you can add records and delete records using input in the format of a different locale and that numbers are displayed correctly for the locale.
Deletions:
~1) Test the script and make sure you can add records and delete records etc.

Revision [2131]

Edited on 2011-09-10 00:57:57 by PhilDaintree
Additions:
~1) Replacing the function locale_number_format() with the locale_money_format function (which takes the same parameters) when the variable being formatted is money. You could use and find and replace - provided the find and replace function of the editor allows you to interactively choose of whether to replace or not following a find.
~1) Check all $_POST variables (I use find $_POST in my editor) that are meant to contain a number and ensure they are encapsulated inside the filter_number_format() function before they are used in any calculations or used in any SQL
~1) Test the script and make sure you can add records and delete records etc.
~1) Commit the changed script back to SVN
Deletions:
~1) Replacing the function locale_number_format() with the locale_money_format function (which takes the same parameters) when the variable being formatted is money. You could use and find and replace - provided the find and replace function of the editor allows you to interactively choose of whether to replace or not following a find.
~2) Check all $_POST variables (I use find $_POST in my editor) that are meant to contain a number and ensure they are encapsulated inside the filter_number_format() function before they are used in any calculations or used in any SQL
~3) Test the script and make sure you can add records and delete records etc.
~4) Commit the changed script back to SVN

Revision [2130]

Edited on 2011-09-10 00:56:52 by PhilDaintree
Additions:
~4) Commit the changed script back to SVN

Revision [2129]

Edited on 2011-09-10 00:56:16 by PhilDaintree
Additions:
~3) Test the script and make sure you can add records and delete records etc.

Revision [2128]

Edited on 2011-09-10 00:55:08 by PhilDaintree
Additions:
So the first step is to update your svn repository to the very latest trunk.
~2) Check all $_POST variables (I use find $_POST in my editor) that are meant to contain a number and ensure they are encapsulated inside the filter_number_format() function before they are used in any calculations or used in any SQL
I have divided the scripts up between those that are helping with this project - see the link below:
Deletions:
~2) Check all $_POST variables that are meant to contain a number and ensure they are encapsulated inside the filter_number_format() function before they are used in any calculations or used in any SQL

Revision [2126]

Edited on 2011-09-10 00:36:18 by PhilDaintree
Additions:
Each script that uses numbers (and hence has the locale_number_format() function in it needs to be gone through:
~1) Replacing the function locale_number_format() with the locale_money_format function (which takes the same parameters) when the variable being formatted is money. You could use and find and replace - provided the find and replace function of the editor allows you to interactively choose of whether to replace or not following a find.
~2) Check all $_POST variables that are meant to contain a number and ensure they are encapsulated inside the filter_number_format() function before they are used in any calculations or used in any SQL
I think that's it!! However, there are a lot of scripts....
[[ScriptsDisplayNumbers Scripts That Use locale_number_format() function]]
Deletions:
ScriptsDisplayNumbers

Revision [2124]

Edited on 2011-09-10 00:19:09 by PhilDaintree
Additions:
I have converted all occurrences of number_format() in the scripts to use the locale_number_format() function.
ScriptsDisplayNumbers
Deletions:
%%php

Revision [2123]

Edited on 2011-09-10 00:12:17 by PhilDaintree
Additions:
%%(php)
%%(php)
%%(php)
%%(php)
I had thought that the number_format would be smart enough to display numbers in the user's locale correctly. However, it appears not.
===Filtering Numbers Input===
Numbers input in the locale of the user could potentially cause issues, as it seems that all arithmetic in PHP takes place using full stops for decimal points and no thousands separator (OR the locale of the server?? in which case the filter_number_format function will need some modification). To get numbers that are input converted to numbers that the system can use we need to pass them through a new function. Also critically, SQL does not deal with thousands separators at all and decimal points must be full stops as per ANSI SQL. All numbers going to SQL must be run though this filter_number_format() function.
===What is to be Done?===
Deletions:
I had thought that the number_format would be smart enough to display numbers in the user's locale correctly. However, it appears not.

Revision [2122]

Edited on 2011-09-10 00:03:21 by PhilDaintree
Additions:
====Multi Language Number Formatting====
%%php
%%
%%php
%%
%%php
%%
%%php
%%
===number_format function===
I had thought that the number_format would be smart enough to display numbers in the user's locale correctly. However, it appears not.
The function [[http://nz.php.net/manual/en/function.localeconv.php localeconv()]] returns an array containing the thousands_sep and decimal_point characters of the locale. Tim developed a nice function that uses this to format numbers appropriately for the locale. He put this in the file includes/MiscFunctions.php
%%php
function locale_number_format($Number, $DecimalPlaces) {
global $LocaleInfo;
return number_format($Number,$DecimalPlaces,$LocaleInfo['decimal_point'],$LocaleInfo['thousands_sep']);
function locale_money_format($Number, $DecimalPlaces) {
return money_format('%!.' . $DecimalPlaces . 'n',$Number);
/* and to parse the input of the user into useable number */
function filter_number_format($Number) {
global $LocaleInfo;
return str_replace($LocaleInfo['decimal_point'],'.',str_replace($LocaleInfo['thousands_sep'],'',$Number));
%%
PHP actually does have a function already that does a similar thing for money formats called money_format - the syntax of this function is a bit weird though. Tim pointed out that some locales use a different characters again for formatting currency numbers as opposed to quantity numbers, so another function locale_money_format is also required.
Deletions:
<%php
%>
<%php
%>
<%php
%>
<%php
%>

Revision [2121]

The oldest known version of this page was created on 2011-09-09 23:51:22 by PhilDaintree
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki