Change Details

The handling of decimal numbers 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. To make the amount handling more consistent, I propose the following steps: * Decide if the Request value objects of the use cases (add donation, new donation, validate amount, add membership, validate memebership fee, etc) get `Euro` objects or strings (dot-delimited) and make the Request objects consistent. * Use the locale-aware parser everywhere. * Set a global locale that's used for amount parsing. We *don't* use the locale for determining translations, as that might be different, especially in Switzerland where there are several languages. * Use the locale for parsing AND on the client side for formatting amounts that are submitted. * Standardize on the de_DE locale for the fundraising application. * Adjust the banners accordingly- A smaller fix would be to use string replacement instead of a number parser and to standardize on decimal points instead of commas throughout the application.

The handling of decimal numbers 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. To make the amount handling more consistent, I propose the following steps: * Decide if the Request value objects of the use cases (add donation, new donation, validate amount, add membership, validate memebership fee, etc) get `Euro` objects or strings (dot-delimited) and make the Request objects consistent. * Use the locale-aware parser everywhere. * Set a global locale that's used for amount parsing. We *don't* use the locale for determining translations, as that might be different, especially in Switzerland where there are several languages. * Use the locale for parsing AND on the client side for formatting amounts that are submitted. * Standardize on the de_DE locale for the fundraising application. * Adjust the banners accordingly- A smaller fix would be to use string replacement instead of a number parser and to standardize on decimal points instead of commas throughout the application. **Note:** This inconsistency has forced us to add workaround code in banners at least 2 times. When this issue is fixed, check the banner code if the amount is passed on correctly, both to `donation/new` and to `donation/add`.

The handling of decimal numbers 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. To make the amount handling more consistent, I propose the following steps: * Decide if the Request value objects of the use cases (add donation, new donation, validate amount, add membership, validate memebership fee, etc) get `Euro` objects or strings (dot-delimited) and make the Request objects consistent. * Use the locale-aware parser everywhere. * Set a global locale that's used for amount parsing. We *don't* use the locale for determining translations, as that might be different, especially in Switzerland where there are several languages. * Use the locale for parsing AND on the client side for formatting amounts that are submitted. * Standardize on the de_DE locale for the fundraising application. * Adjust the banners accordingly- A smaller fix would be to use string replacement instead of a number parser and to standardize on decimal points instead of commas throughout the application. **Note:** This inconsistency has forced us to add workaround code in banners at least 2 times. When this issue is fixed, check the banner code if the amount is passed on correctly, both to `donation/new` and to `donation/add`.