Opened 12 years ago

Closed 12 years ago

Last modified 11 years 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 12 years ago.
Sandbox demo (i18n problem)

Download all attachments as: .zip

Change History (4)

by houmie, 12 years ago

Attachment: Sandbox.zip added

Sandbox demo (i18n problem)

comment:1 by houmie, 12 years ago

Type: UncategorizedBug

comment:2 by Karen Tracey, 12 years ago

Resolution: invalid
Status: newclosed

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 by justinkhill@…, 11 years ago

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?

Note: See TracTickets for help on using tickets.
Back to Top