Code

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#16038 closed Bug (needsinfo)

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

Reported by: jonathanslenders Owned by: nobody
Component: Forms Version: master
Severity: Normal Keywords: l10n
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX:

Description

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.

Attachments (1)

form-field-patch.patch (1.1 KB) - added by jonathanslenders 3 years ago.
patch for forms.Field

Download all attachments as: .zip

Change History (5)

Changed 3 years ago by jonathanslenders

patch for forms.Field

comment:1 Changed 3 years ago by kmtracey

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to needsinfo
  • Status changed from new to closed

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?

comment:2 Changed 3 years ago by 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/

  1. Use a django project with USE_L10N=True
  1. 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

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by jacob

  • milestone 1.4 deleted

Milestone 1.4 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.