Localization of django form Field falls back to False instead of settings.USE_L10N
|Reported by:||jonathanslenders||Owned by:||nobody|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
django.forms.Field has a localize argument which defaults to False instead of settings.USE_L10N.
This causes unexpected/random behaviour.
Field is initialized right after the form has been defined. So, Input widgets like DateTimeInput, are also inialized at this time, where the date formatting is set according to the current language when USE_L10N is still enabled.
The field will stay in the language that was active during the creation of the form. So, when an application has several forms, but they were somehow created in different languages, they all have different formatting.
When USE_L10N is enabled in settings.py, it's better to default to this value.
It's no good that Input calls a method 'get_format' which behaviour depends on the value of USE_L10N, while Field has an init attribute 'localize'.
In my opinion, the 'localize' attribute of a Field should be deprecated, but if someone would really require it (which I doubt, as it is broken now...), DateTimeInput or any Input widget should never call formats.get_format when USE_L10N=True, but localize=False, as this combination causes the field to be localized in a random language. (And causes it to stay and render in this language, no mater the active language later on.)
People using ModelForm, usually don't explicitely initialize Field for datetime fields in their model, so they fall back to the broken default.
Patch attached which sets Field.localize to USE_L10N and fixes ModelForm. If someone still uses the localize parameter, and sets it explicitely to False (True would not be an issue), he gets the broken behaviour again.
Change History (5)
comment:1 Changed 5 years ago by
|Patch needs improvement:||unset|
|Status:||new → closed|