Opened 19 years ago

Closed 16 years ago

#1241 closed enhancement (duplicate)

Internationalisation of date fields in free admin section.

Reported by: david@… Owned by: nobody
Component: contrib.admin Version: dev
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: no UI/UX: no

Description

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 by Adrian Holovaty, 19 years ago

priority: highnormal
Severity: majornormal

comment:2 by hugo, 19 years ago

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 ;-)

comment:3 by GomoX <gomo@…>, 19 years ago

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.

comment:4 by hugo, 19 years ago

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 by david@…, 18 years ago

Resolution: fixed
Status: newclosed

Looks like this was fixed in 3055.

Thanks to those who fixed it!

comment:6 by Ramiro Morales, 18 years ago

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,

comment:7 by david@…, 18 years ago

Resolution: fixed
Status: closedreopened

Ramiro,

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

comment:8 by Chris Beaven, 18 years ago

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 by Malcolm Tredinnick, 18 years ago

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 by Jacob, 17 years ago

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 by David Reynolds, 17 years ago

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 by Thomas Güttler, 16 years ago

Cc: hv@… added

comment:13 by Thomas Güttler, 16 years ago

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

Ticket #3672 has patches.

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