The handling of decimal numbers from HTTP requests in the FundraisingFrontend is inconsistent:
* `donation/new` expects English-formatted numbers (using a locale-aware parser) and will default to 0 if the number can't be parsed.
* `donation/add` expects German-formatted numbers (using a locale-aware parser) and will default to 0 if the number can't be parsed.
* `apply-for-membership` expects German-formatted numbers (using simple string-replacement of comma to dot) and has no default.
* `validate-amount` expects an integer (Euro Cents)
* `validate-fee` can handle both English and German-formatted numbers (using simple string-replacement from comma to dot)
My proposal would beThe best way to unify the situation is to get rid of the existing locale-aware `AmountParser` and standardize on expecting integer amounts in the controller parameters, which represent EuroCents. This will avoid rounding errors. For this solution, the client-side code, both in FundraisingFrontend and in the banners needs to be changed - the browser must still display decimal numbers in the locale of the user, both in FundraisingFRontend and inbut the value that gets sent to the banners needs to be changedserver must be an EuroCent integer.
**Note:** Check for usages of `AmountFormatter` which will format the amount for rendering it in the template.Conversely, If the amount is rendered as a string in the template then everything is fine,all amounts in JSON data (provided for templating or the skin) should also be integers representing EuroCent and the frontend code (takes care of formatting it in the right locale). but iWe must also get rid of the a`Amount is processed by JavaScript,Formatter` PHP class. it needs to re-parse the (German-formatted) amount againWhile working on the ticket you can take the usage of the class as an indicator that the amount formatting code needs to be changed.
**Note:** The estimation is made under the assumption that there will only be one skin to be changed.