Description: ------------ When passing a non-int to toWords (e.g. 10.5 or 10abc3) all non-numeric characters are cast to int, replacing it with a zero. So, 10.5 becomes 1005 and 10abc3 becomes 100,003 -- both clearly misrepresenting the values passed to the function. Expected result: ---------------- When passed a float, I would expect one of two things: a) 10.5 (for example) is split on the period, and toWords is recursively run on 10, then 5, and the two are concatenated with the word "point". b) the value is simply cast to int, discarding everything including and to the right of the decimal. When passed an alphanumeric string, I would expect one of two things: a) any non-numeric characters to be stripped out. 10abc3 would become 103. b) the value is simply cast to int, discarding everything from and including the first non-numeric character to the right. 10abc3 would become 10. Actual result: -------------- Currently: 10.5 results in 1005 being parsed, yielding one thousand five. 10abc3 results in 100003 being parsed, yielding one hundred thousand three.

I also have a testcase lying around here.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.

Looking at other files, particularly lang.es_AR.php; theres been a slightly different approach it looks like. Namely if ($dec) { $dec = $this->toWords(trim($dec)); $ret .= ' con ' . trim ($dec); }

It appears that the bug fix introduced an uncoditional cast to int, which broke passing of bigger numbers. Committed a fix fo that in CVS.