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
16038	Localization of django form Field falls back to False instead of settings.USE_L10N	jonathanslenders	nobody	"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."	Bug	closed	Forms	dev	Normal	needsinfo	l10n		Unreviewed	1	0	0	0	0	0