Internationalisation of date fields in free admin section.

[david@…]

Inkeeping with the good internationalisation work that is going on, it would be very useful, if the representation of DateField or DateTimeField were to show correctly formatted dates based on the locale or language settings from the settings file. For example UK dates would be good to display as DD/MM/YYYY rather YYYY-MM-DD.

[hugo]

This could be done by using translated date and time formats like we already do in the global_settings.py - just one format for parsing and one for formatting in the admin (message IDs like ADMIN_DATE_FORMAT and ADMIN_TIME_FORMAT could be used).

On the other hand, I have to admit that I quite like the "neutral" format YYYY-MM-DD. But then, I am a coder, and coders often prefer sortable formats over weird "natural" formats ;-)

[GomoX <gomo@…>]

Hugo, I don't know what you mean by "like we already do in global_settings.py", because the current DATE_FORMAT strings in the settings files are ignored (this in django from-svn-pre-0.91-but-post-0.90). In order to change the date format in all the pages I had to modify the current datefield implementation and its validator (which, btw, uses a regexp which sucks, since it might be fast, but it can't correctly validate "weird" dates such as 2003-02-29, but that goes for another ticket, i'll post it).
And anyway, the trunk implementations of these did not take into account the DATE_FORMAT setting at all (in particular the hardcoded validator regex :P). So yes, i think this should be added since i18n is not complete without it.

[hugo]

The settings are used in multiple places in the code for _output_ of dates - like the overview pages in the admin, when there are dates listed. I don't say that we already use those for parsing dates - that's what actually is my suggestion, just use translated technical message IDs for the parse specifications as for print specifications. That way translators can just provide language-specific date and time formats. Of course this would require patching validators and admin code - that's why this ticket is still open and not closed ;-)

[david@…]

Looks like this was fixed in ​3055.

Thanks to those who fixed it!

[Ramiro Morales]

david,

[3055] is just related to the i18n of the visualization of two specific date (no date time) formats so I' m not sure if that is exactly what you were asking for with this ticket.

Regards,

[david@…]

Ramiro,

I think you might be correct, I just got over excited that someone had fixed it ;)

[Chris Beaven]

This comes up in IRC every now and then and is met with a bit of contention. Let's hear an official word on whether this is a valid enhancement request.

[Malcolm Tredinnick]

This is a valid concern from a localisation perspective. However, it's also very hard to do in a smooth fashion that won't make things very painful when the i18n framework isn't enabled. So design work is needed here before we can go about making a fix. Anybody with concrete suggestions that work both with an without i18n enabled should bring them up on django-developers.

[Jacob]

It seems the only issue left here is correctly parsing dates based on locale, correct?

If so, I think we need a bit of inspiration here; I'm having trouble seeing a way of doing this that isn't crufty and prone to breakage. Ideas are welcome!

[David Reynolds]

Are we against the idea of just using settings to set the date/time formats? That seems like the simplest way to do it and also gets around the fact that people might not actually like the 'standard' way dates are formatted in their country.

[Thomas Güttler]

Ticket #3672 has patches.