Code

Opened 8 years ago

Closed 5 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:

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.

Attachments (0)

Change History (13)

comment:1 Changed 8 years ago by adrian

  • priority changed from high to normal
  • Severity changed from major to normal

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

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 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 8 years ago by david@…

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

Looks like this was fixed in 3055.

Thanks to those who fixed it!

comment:6 Changed 8 years ago by ramiro

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 Changed 8 years ago by david@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

Ramiro,

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

comment:8 Changed 7 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Design 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 7 years ago by mtredinnick

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 6 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 6 years ago by DavidReynolds

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 5 years ago by guettli

  • Cc hv@… added

comment:13 Changed 5 years ago by guettli

  • Cc hv@… removed
  • Resolution set to duplicate
  • Status changed from reopened to closed

Ticket #3672 has patches.

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.