#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)
Change History (4)
by , 12 years ago
Attachment: | Sandbox.zip added |
---|
comment:1 by , 12 years ago
Type: | Uncategorized → Bug |
---|
comment:2 by , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → 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 by , 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?
Sandbox demo (i18n problem)