I'm using manual edit of member funds editing their profile. I do have spanish language. My problem is when using spanish language the point decimal separator "." is changed to a comma "," so when editing the member profile, internally the funds lose all their decimals after the comma ",".
As I have various sponsorusergroups levels I have implemented an options value selector in where current funds are added to the corresponding funds for each sponsorusergroup. After editing the member profile with the new option selected I lose the decimals so the expiration date is not correct.
Can it be possible to internally change the comma into a point just after editing the member profile this in order not to lose the decimals ?
Paul, Some more feedback: At General->Language for date translation If I change my current 'spanish' to 'english' this difficulty is solved. So one solution would be to seek on how to maintain the 'spanish' for date translation but without affecting the funds variable format.
There are a potentially infinite (with custom fields) number of other spots that could happen, though. Probably it should be handled at the mysql level. Does changing the field character set or the table character set to spanish help?
At mysql level funds variable is stated as double, I already tested changing to float but with the same results.
The funds are correctly presented in the selected character set. I do need to present the funds value always in english character set in order it to be processed correctly internally or convert them internally into english set to be processed correctly.
Also if someone, using the default template, inserts a funds value of "14,5" using a comma instead of a point, you will notice that the system cuts off the decimals.
Please test it changing at editmembers.tpl the funds piece with:
For 4.1 I'll force the locale to english for that field.
For 5.0 I'll try to check whether fields are numeric and adjust add/update processing accordingly. But, on checking, PHP gives the decimal separator '.' for the locale 'spanish'. This means I have no means to tell whether , is a thousands separator or a decimal separator.
Though according to the PHP manual page, setlocale is pretty useless since other pages loading on the server (anyone else on a shared host) reset the locale system-wide during the middle of execution. Plus, it says the locale name varies drastically by system so you never know what to use unless you're an expert on your server config. Seems like the most appropriate thing would be to stop using it entirely and rely on the system setting.
I did test a lot with php code at the template without results, but now I do have the solution:
At classes/member.php replace the:
function funds($round = 2) { return round($this->funds, $round); }
with:
function funds($round = 2) { return number_format ($this->funds, 2,'.',''); }
And we do have to state/mention that when editing, the funds decimals should always be entered with a "." dot separator. This works perfect using spanish language, the "." dot decimal character is not changed.
My problem was the lose of the decimals due to the dot being reverted to a comma.
We need funds to be formatted into english to be processed correctly, so this way they will always be in english regardless of the date format.
Funds are not altered manually by users, but only by admin or automatically, so I do not see a problem on stating that the format should be with a dot as the decimal separator. At spanish if we present a dot we can always understand that it stands for decimal separator it's not a problem. The english format is fine at spanish too and I do believe for other languages too. All calculators present the english format and they are used all over.
At ver. 4.1.51 we still have this difficulty. When I use other language than english I do have the language {LANG_DATEFORMAT_LOCALE} variable that I do have to force it to english in order not to present this issue. Having {LANG_DATEFORMAT_LOCALE} to spanish affects the funds presentation. Is it possible to implement also my solution in order to override this ?
Well it doesn't work for me, but I wouldn't expect it to since I don't believe I have the spanish locale installed on my computer. Is your web host spanish-speaking? If not, they may not have the locale installed either.
The simplest test is this file: <?php setlocale(LC_TIME, "spanish"); echo strftime("%B"); ?>
Unfortunately the manual says that locale may be known by different names on different systems, so I can't even guess how spanish is represented on your system if it is present.
Actually I do have a /usr/share/locale/es/LC_TIME/coreutils.mo, but setlocale(LC_TIME, "es") doesn't work.
0/5
1
2
3
4
5
Sorry, you don't have permission to post posts. Log in, or register if you haven't yet.
Comments on editing memberfunds
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
I'm using manual edit of member funds editing their profile.
I do have spanish language. My problem is when using spanish language the point decimal separator "." is changed to a comma "," so when editing the member profile, internally the funds lose all their decimals after the comma ",".
As I have various sponsorusergroups levels I have implemented an options value selector in where current funds are added to the corresponding funds for each sponsorusergroup. After editing the member profile with the new option selected I lose the decimals so the expiration date is not correct.
Can it be possible to internally change the comma into a point just after editing the member profile this in order not to lose the decimals ?
Paul,
Some more feedback:
At General->Language for date translation
If I change my current 'spanish' to 'english' this difficulty is solved. So one solution would be to seek on how to maintain the 'spanish' for date translation but without affecting the funds variable format.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
There are a potentially infinite (with custom fields) number of other spots that could happen, though. Probably it should be handled at the mysql level. Does changing the field character set or the table character set to spanish help?
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
At mysql level funds variable is stated as double, I already tested changing to float but with the same results.
The funds are correctly presented in the selected character set.
I do need to present the funds value always in english character set in order it to be processed correctly internally or convert them internally into english set to be processed correctly.
Also if someone, using the default template, inserts a funds value of "14,5" using a comma instead of a point, you will notice that the system cuts off the decimals.
Please test it changing at editmembers.tpl the funds piece with:
<IF {SPONSORUSEUG} is yes>
<tr>
<td class="labelscolumn"><span class="labels">{LANG_EDITPROFILE_FUNDS}:</span><br />{LANG_EDITPROFILE_FUNDSHELP}</td>
<td class="optionscolumn"> MEMBERFUNDS CURRENT VALUE: {MEMBERFUNDS} <input type="text" name="funds" size="5" value="{MEMBERFUNDS}" /></td>
</tr>
</IF>
Please test it also changing the
settings->general: Language for date translation:
with spanish and english
Edit the same profile two times.
At classes/member.php we have
function funds($round = 2)
{
return round($this->funds, $round);
}
I believe here we can have a sort of detector if decimal separator is a point or a comma ?
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
For 4.1 I'll force the locale to english for that field.
For 5.0 I'll try to check whether fields are numeric and adjust add/update processing accordingly. But, on checking, PHP gives the decimal separator '.' for the locale 'spanish'. This means I have no means to tell whether , is a thousands separator or a decimal separator.
Though according to the PHP manual page, setlocale is pretty useless since other pages loading on the server (anyone else on a shared host) reset the locale system-wide during the middle of execution. Plus, it says the locale name varies drastically by system so you never know what to use unless you're an expert on your server config. Seems like the most appropriate thing would be to stop using it entirely and rely on the system setting.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Spend the last 3 hours on this, just doesn't work.
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
I did test a lot with php code at the template without results, but now I do have the solution:
At classes/member.php replace the:
function funds($round = 2)
{
return round($this->funds, $round);
}
with:
function funds($round = 2)
{
return number_format ($this->funds, 2,'.','');
}
And we do have to state/mention that when editing, the funds decimals should always be entered with a "." dot separator. This works perfect using spanish language, the "." dot decimal character is not changed.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Your solution is the same as forcing the locale to english for the field, and doesn't address the general problem.
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
My problem was the lose of the decimals due to the dot being reverted to a comma.
We need funds to be formatted into english to be processed correctly, so this way they will always be in english regardless of the date format.
Funds are not altered manually by users, but only by admin or automatically, so I do not see a problem on stating that the format should be with a dot as the decimal separator. At spanish if we present a dot we can always understand that it stands for decimal separator it's not a problem. The english format is fine at spanish too and I do believe for other languages too. All calculators present the english format and they are used all over.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
I'll have the locale only apply to dates and not numbers, then.
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
At ver. 4.1.51 we still have this difficulty. When I use other language than english I do have the language {LANG_DATEFORMAT_LOCALE} variable that I do have to force it to english in order not to present this issue. Having {LANG_DATEFORMAT_LOCALE} to spanish affects the funds presentation. Is it possible to implement also my solution in order to override this ?
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Post 9 was written after 4.1.51, so check 4.1.52.
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
Thanks, Working fine now.
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
Paul,
Related to this, but not so relevant :
I have never being able to present a date in spanish language nor now after my php upgraded to ver. 5.
For example January shall read Enero in spanish.
Can you check if this works for you ?
(Of course without affecting the number format as it shall be always in english as discussed before)
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Well it doesn't work for me, but I wouldn't expect it to since I don't believe I have the spanish locale installed on my computer. Is your web host spanish-speaking? If not, they may not have the locale installed either.
The simplest test is this file:
<?php
setlocale(LC_TIME, "spanish");
echo strftime("%B");
?>
Unfortunately the manual says that locale may be known by different names on different systems, so I can't even guess how spanish is represented on your system if it is present.
Actually I do have a /usr/share/locale/es/LC_TIME/coreutils.mo, but setlocale(LC_TIME, "es") doesn't work.