Code

Opened 6 years ago

Closed 5 years ago

#6693 closed (fixed)

Inconsistency in localized datetime formats between filters and utility functions

Reported by: Petr Marhoun <petr.marhoun@…> Owned by: garcia_marc
Component: Internationalization Version: master
Severity: Keywords: i18n-fixed
Cc: post@… Triage Stage: Fixed on a branch
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I tried to understand handling of localized datetime formats in django. It seems filters (django.template.defaultfilters.date and django.template.defaultfilters.time) use settings - without any localization. And utility functions (django.utils.translation.trans_real.get_date_formats and django.utils.translation.trans_real.get_partial_date_formats) use localized values of strings "DATE_FORMAT", "DATETIME_FORMAT", "TIME_FORMAT", "YEAR_MONTH_FORMAT" and "MONTH_DAY_FORMAT" - settings is ignored (there are exceptions - if these strings are untranslated of if trans_null is used, utility functions behave as filters).

I don't think it is right. I would like to describe main use cases (with my opinions on them) and propose an solution.

USE_I18N is False

How it should be: Values from (global or local) settings should be used everywhere.

How it is: Without any problems.

USE_I18N is True, only one language is used

How it should be: As in the previous use case. And if the language is different from English, localized values should be used be default.

How it is: There are some problems - in templates (through filters) values are not localized be default; in admin (through utility functions) local settings is ignored.

Documentation says: "DATE_FORMAT - The default formatting to use for date fields on Django admin change-list pages." It is not true in this situation.

USE_I18N is True, more languages are used

How it should be: As in the previous use case. And it should be simple to translate datetime formats from local settings (these translations should be used everywhere).

How it is: There are some problems - both from the previous use case; translation of datetime formats from local settings is not simple.

Possible solution

  1. Mark DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT for translation in django.conf.global_settings.py.
  2. Translate these string to all languages.
  3. Use translated values of datetime formats from settings in filters.
  4. Deprecate get_date_formats and get_partial_date_formats and use ugettext/ugettext_lazy with arguments DATE_FORMAT and friends instead.

Attachments (4)

datetime-i18n.diff (30.7 KB) - added by Petr Marhoun <petr.marhoun@…> 6 years ago.
datetime-i18n.py (935 bytes) - added by Petr Marhoun <petr.marhoun@…> 6 years ago.
a fast script for 2
datetime-i18n.2.diff (30.7 KB) - added by Petr Marhoun <petr.marhoun@…> 6 years ago.
datetime-i18n.3.diff (8.0 KB) - added by Petr Marhoun <petr.marhoun@…> 6 years ago.
patch which dont' change po files

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by Petr Marhoun <petr.marhoun@…>

Changed 6 years ago by Petr Marhoun <petr.marhoun@…>

a fast script for 2

Changed 6 years ago by Petr Marhoun <petr.marhoun@…>

comment:1 Changed 6 years ago by Petr Marhoun <petr.marhoun@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I am sorry - I copy content also to title. And I have no rights to change it.

File datetime-18n.diff is the patch - but it cannot be viewed by trac (I don't know why) - it is possible to download it. File datetime-i18n.py is a help script.

comment:2 Changed 6 years ago by SmileyChris

  • Summary changed from Inconsistency in localized datetime formats between filters and utility functions I tried to understand handling of localized datetime formats in django. It seems filters (django.template.defaultfilters.date and django.template.defaultfilters.time) use settings - without any localization. And utility functions (django.utils.translation.trans_real.get_date_formats and django.utils.translation.trans_real.get_partial_date_formats) use localized values of strings "DATE_FORMAT", "DATETIME_FORMAT", "TIME_FORMAT", "YEAR_MONTH_FORMAT" and "MONTH_DAY_FORMAT" - settings is ignored (if these strings are untranslated of if trans_null is used, utility functions behave as filters). I don't think it is right. I would like to describe main use cases (with my opinions on them) and propose an solution. =USE_I18N is False= How it should be: Values from (global or local) settings should be used everywhere. How it is: Without any problems. =USE_I18N is True, only one language is used= How it should be: As in the previous use case. And if the language is different from English, localized values should be used be default. How it is: There are some problems - in templates (through filters) values are not localized be default; in admin (through utility functions) local settings is ignored. Documentation says: "DATE_FORMAT - The default formatting to use for date fields on Django admin change-list pages." It is not true in this situation. =USE_I18N is True, more languages are used= Inconsistency in localized datetime formats between filters and utility functions How it is: There are some problems - both from the previous use case; translation of datetime formats from local settings is not simple. =Possible solution= 1. Mark DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT for translation in django.conf.global_settings.py. 2. Translate these string to all languages. 3. Use translated version of formats from settings in filters. 4. Deprecate get_date_formats and trans_real.get_partial_date_formats and use ugettext/ugettext_lazy with argument DATE_FORMAT (and friends) instead. to Inconsistency in localized datetime formats between filters and utility functions

comment:3 Changed 6 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to Accepted

I'm not sure yet if this is the perfect solution, but it's on the right track.

Could you please create a patch that just contains the code changes and does not touch any files under django/conf/locale. That will make it easier for me to review and apply. Translators will update their locale files in due course: we don't change them as part of a code change. If a string isn't in the MO file, it just gets treated as a literal in any case, so there's not need to include the translation from day one.

Changed 6 years ago by Petr Marhoun <petr.marhoun@…>

patch which dont' change po files

comment:4 Changed 6 years ago by Bela Hausmann <post@…>

  • Cc post@… added

comment:5 Changed 5 years ago by garcia_marc

  • Keywords i18n-fixed added
  • Owner changed from nobody to garcia_marc

comment:6 Changed 5 years ago by garcia_marc

  • Triage Stage changed from Accepted to Fixed on a branch

comment:7 Changed 5 years ago by jezdez

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

(In [11964]) Fixed #7980 - Improved i18n framework to support locale aware formatting (dates and numbers) and form processing.

Thanks to Marc Garcia for working on this during his Google Summer of Code 2009!

Additionally fixes #1061, #2203, #3940, #5526, #6449, #6231, #6693, #6783, #9366 and #10891.

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.