id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 22171 sanitize_separators throws away too many thousand separators Klaas van Schelven nobody "Users in countries that use symbols other than the period (e.g. comma) as a decimal separator, may still occasionally use the period as a decimal separator. (Because they've come to expect that computers want input with a period). If the period coincides with the THOUSANDS_SEPARATOR, and USE_THOUSANDS_SEPARATOR is turned on, this results in the decimal separator basically being thrown out, but still with a validated result. Example shell output (THOUSANDS_SEPARATOR == '.'; USE_THOUSANDS_SEPARATOR = True)): {{{ >>> from django.utils.translation import activate >>> activate('nl-nl') >>> >>> class F(forms.Form): ... f = forms.DecimalField(max_digits=15, decimal_places=2) ... >>> f = F({'f': '10.10'}) >>> print f.is_valid() True >>> print f.cleaned_data['f'] 1010 }}} Why does this happen? django/utils/formats.py has a function sanitize_separators, that basically tosses all thousands separators ''even if they do not actually separate thousands'' My solution would be to only toss thousands separators which have at least 3 digits on their right hand side. Admittedly this is not a full solution: the value 100.000 is still ambiguous if we assume that users may mean either ""thousands separator"" or ""decimal separator"" with the period. But at least it does not silently convert 10.00 (which doesn't mean 1000 to anyone) into 1000. This solution also happens to cover all scenarios where cents are involved, which A better solution would not validate ""10.00"" at all (since it does not contain either a decimal separator nor a thousands separator separating thousands). However, the current interface of sanitize_operators does not allow for it: it attempts to sanitize towards a string w/ period, and does not allow us to complain if the input is a string w/ period, but we wouldn't want to allow that as a valid input. The/a solution for Django 1.4 is attached. I imagine it may be a bit more hairy in the up-to-date version, as this supports full unicode for the input, and I'm not entirely sure on the interaction of regex & unicode. I've reproduced this in 1.4, but can see in the repo that as of today the code still experiences this problem." Cleanup/optimization closed Internationalization dev Normal fixed Ready for checkin 1 0 0 0 0 0