Localization of django form Field falls back to False instead of settings.USE_L10N

[jonathanslenders]

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.

[jonathanslenders]

patch for forms.Field

[Karen Tracey]

The problem description here is very confusing to me. A programmatic test case illustrating the problem would help.

The localize Field argument, and its default, was not added on a whim; it was reluctantly added to fix #13032. Are you sure your proposed change would not re-introduce the problem that it was introduced to fix?

[jonathanslenders]

A test case, I hope this will clarify the issue.

---

1. Paste following snippet in django_test_case.py

​http://dpaste.com/hold/543037/

2. Use a django project with USE_L10N=True

3. open shell_plus, and import django_test_case

You will see that both forms produce a different outcome. In this case it's obvious where the localization comes from. What what is wrong, is that the form seems to be localized somehow, but the localization does not match the language which is active during the initialization of the form.

From the user's perspective, I think we have two use cases:

1. No localization: everything rendered like it's in English, or the default.
2. With localization: a form renders in the language which is active at render-time, or during the initialization. The language that was active during the declaration of the form should be of no importance. (Form.metaclass should be transparent here.)

I'm not really satisfied with keeping 'localize=False' as the default. When using modelforms, do we have to specify for every single datetime field that we want to have localization?

At least in DateTimeInput.init, don't call formats.get_format when self.is_localized will not be set by the form.

Please reopen again.

Thanks,
Jonathan

[jonathanslenders]

If French was active when the form was declared (during "import forms"). All datetime fields for following requests will render in French. (I would understand, if it was English, as non-localized), but not French, especially while the active language during a request could be German.

[Jacob]

Milestone 1.4 deleted