Code

Opened 21 months ago

Closed 20 months ago

Last modified 8 months ago

#18769 closed Bug (invalid)

Despite selected language, Forms still rely on LANGUAGE_CODE to format datetime (demo included)

Reported by: houmie Owned by: nobody
Component: Internationalization Version: 1.4
Severity: Normal Keywords: formats, i18n, l10n
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I have discussed this issue in stackoverflow and it seems to be a bug.

Summary:

In a nutshell, despite creating custom formats.py, only the templates react to the selected language while the forms still rely on LANGUAGE_CODE

Details:

I have created a small live demo to show the problem. Please open the demo here: http://sandbox.chasebot.com/

When you click on British English, you can see how both the date- and time format within the template change accordingly, which is great.

Now if you click on Add, you will see how both the current date and time are populated for you in the form. However they still carry the American date format, instead of the selected British language.

The only way to fix this is to change

LANGUAGE_CODE = 'en-us'

to

LANGUAGE_CODE = 'en-gb'

in settings.py. This approach would be obviously useless as its no longer dynamic and favors one group over the other. LANGUAGE_CODE should be the last priority since the selected language should have a higher priority. But this doesn't work when having custom formats.py for each language.

I have created custom formats.py to override the date and time formats for en and en_GB as described in the documentation so I am clueless what else I could do.

Please be so kind and download my demo (22 kb) from my dropbox (https://dl.dropbox.com/u/44307777/Sandbox.zip) or see attachment: All you have to do is to edit settings.py to adjust the path to sqlite.db.

Attachments (1)

Sandbox.zip (22.4 KB) - added by houmie 21 months ago.
Sandbox demo (i18n problem)

Download all attachments as: .zip

Change History (4)

Changed 21 months ago by houmie

Sandbox demo (i18n problem)

comment:1 Changed 21 months ago by houmie

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Type changed from Uncategorized to Bug

comment:2 Changed 20 months ago by kmtracey

  • Resolution set to invalid
  • Status changed from new to closed

The form you are using hasn't specified to localize the fields. The forms.py file in the sandbox project has:

from django.forms.models import ModelForm
from Sandbox_App.models import Company

class CompanyForm(ModelForm):
    def date_callback(self, field, **kwargs) :
        return field.date(localize=True, **kwargs)
    def time_callback(self, field, **kwargs) :
        return field.time(localize=True, **kwargs)

    class Meta:
        model = Company

I gather it is expected that these callback functions will turn on localization for the fields, but I do not know where the idea for defining these callbacks came from. Django model forms do not call these functions, so they have no effect. Changing that forrms.py file to:

from django import forms
from Sandbox_App.models import Company

class CompanyForm(forms.ModelForm):
    date = forms.DateField(localize=True)
    time = forms.TimeField(localize=True)

    class Meta:
        model = Company

results in the form on initial display being localized as per the chosen language.

comment:3 Changed 8 months ago by justinkhill@…

I'm having trouble getting my Canadian and Australian sites to use the correct date formatting via the localize=True method mentioned here. My other international sites are working correctly.

I've decided it is because there are no en_AU and en_CA formats.py files in the django core project: https://github.com/django/django/tree/master/django/conf/locale
Am I left to create my own as described here: https://docs.djangoproject.com/en/dev/topics/i18n/formatting/#creating-custom-format-files

If so, so be it, but may I ask why such well know countries do not have their own formats.py in the core project? Am I doing it wrong?

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.