Opened 12 years ago

Closed 9 years ago

#1241 closed enhancement (duplicate)

Internationalisation of date fields in free admin section.

Reported by: david@… Owned by: nobody
Component: contrib.admin Version: master
Severity: normal Keywords:
Cc: dreynolds@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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.

Change History (13)

comment:1 Changed 12 years ago by Adrian Holovaty

priority: highnormal
Severity: majornormal

comment:2 Changed 12 years ago by hugo

This could be done by using translated date and time formats like we already do in the - 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 ;-)

comment:3 Changed 12 years ago by GomoX <gomo@…>

Hugo, I don't know what you mean by "like we already do in", 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.

comment:4 Changed 12 years ago by 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 ;-)

comment:5 Changed 11 years ago by david@…

Resolution: fixed
Status: newclosed

Looks like this was fixed in 3055.

Thanks to those who fixed it!

comment:6 Changed 11 years ago by Ramiro Morales


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


comment:7 Changed 11 years ago by david@…

Resolution: fixed
Status: closedreopened


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

comment:8 Changed 11 years ago by Chris Beaven

Triage Stage: UnreviewedDesign decision needed

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.

comment:9 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by 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!

comment:11 Changed 10 years ago by 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.

comment:12 Changed 9 years ago by Thomas Güttler

Cc: hv@… added

comment:13 Changed 9 years ago by Thomas Güttler

Cc: hv@… removed
Resolution: duplicate
Status: reopenedclosed

Ticket #3672 has patches.

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