Inconsistency in localized datetime formats between filters and utility functions

[Petr Marhoun <petr.marhoun@…>]

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.

[Petr Marhoun <petr.marhoun@…>]

a fast script for 2

[Petr Marhoun <petr.marhoun@…>]

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.

[Malcolm Tredinnick]

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.

[Petr Marhoun <petr.marhoun@…>]

patch which dont' change po files

[Jannis Leidel]

(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.