WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#30864 closed defect (bug) (fixed)

Date format inconsistent across the admin

Reported by: iseulde Owned by: iseulde
Milestone: 4.5 Priority: low
Severity: normal Version:
Component: Administration Keywords: has-patch
Focuses: Cc:

Attachments (3)

30864.patch (566 bytes) - added by iseulde 5 years ago.
30864.2.patch (6.0 KB) - added by iseulde 5 years ago.
30864.3.patch (8.0 KB) - added by iseulde 4 years ago.

Download all attachments as: .zip

Change History (34)

#1 follow-up: @pavelevap
5 years ago

It is standard (and localized) date format from General Settings?

#2 in reply to: ↑ 1 @SergeyBiryukov
5 years ago

Replying to pavelevap:

It is standard (and localized) date format from General Settings?

Correct. This appears to be consistent with the usage of 'date_format' option in the rest of the admin and in front-end functions like get_comment_date(), get_the_date(), wp_list_pages(), etc.

#3 @tyxla
5 years ago

  • Keywords reporter-feedback dev-feedback added; needs-patch removed

Just conducted a couple of tests myself. I confirm that the date format is being translated correctly in the attachment grid details popup. The mysql2date() translates the date through date_i18n() by default, unless false is passed as third parameter ($translate). So, unless the default value of $translate is changed, nothing else should be done here.

#4 follow-up: @iseulde
5 years ago

  • Keywords reporter-feedback dev-feedback removed
  • Version changed from 4.0 to 3.5

date_i18n only translates words in a date format, it does not translate the date format itself. I don't think we should use the date setting for the blog for the admin. The dates in the admin should all be the same. F j, Y is not translated to the right date format by just using date_i18n.

This is also the case for the media modal.

@iseulde
5 years ago

#5 @iseulde
5 years ago

  • Keywords has-patch added

Sorry, didn't have the time to submit a patch when I first reported the issue.

#6 in reply to: ↑ 4 @SergeyBiryukov
5 years ago

Replying to avryl:

The dates in the admin should all be the same.

Well, the rest of the admin generally appears to use get_option( 'date_format' ).

The only place where __( 'F j, Y' ) is used in the admin is the Date Format menu itself in General Settings. It's also the default value of date_format option on install.

So I'm still not sure why this should change.

In Russian, 'F j, Y' is translated to 'd.m.Y', and that's the format I see in Attachment Details modal in media grid, with or without the patch. I guess it would be different if I select a different format in General Settings, but then, with the patch, this date in Attachments Details modal would be in different from the rest of the admin.

#7 follow-up: @iseulde
5 years ago

  • Component changed from Media to Administration
  • Keywords needs-patch added; has-patch removed
  • Version 3.5 deleted

Yeah, I noticed a few other instances, but I wouldn't say it generally does.

The problem here is that the date format is the same as the blog, and the admin for different users might not be in the same language, or the entire admin might just be in a different language.

Also, when you first install WordPress in English and then switch the language, the date format doesn't change because the option has already been set. The WordPress admin should just not use this option and always use the same date format.

So yes, the patch is not good, we need to change all other instances of this.

#8 @iseulde
5 years ago

Hm, thought the language setting was on a user basis, not sure why. Still, the second point is a valid reason?

#9 in reply to: ↑ 7 @SergeyBiryukov
5 years ago

Replying to avryl:

Also, when you first install WordPress in English and then switch the language, the date format doesn't change because the option has already been set.

Yep, but the new format becomes available in General Settings.

The WordPress admin should just not use this option and always use the same date format.

I guess that would make it harder to implement user-level timezone settings (#18146) in the future.

Currently, I would expect the date_format option to affect both the admin and the front-end (with maybe a few exceptions where a more granular format is needed, e.g. for revisions).

#10 @iseulde
5 years ago

I guess that would make it harder to implement user-level timezone settings (#18146) in the future.

Not sure how that would make it harder as it doesn't have anything to do with language.

Yep, but the new format becomes available in General Settings.

That's right, but it is not automatically switched when changing the language.

I would expect the date format to be the same across the admin, I'm not sure if the user should have a say in how the date is formatted in the admin. They don't for the post list. They don't for the publish box.

#11 @pavelevap
5 years ago

I am sorry, but I do not see any problem here? I checked our localized version and there is no problem with general date option. Yes, it would be fine to go through all date strings appearances in core and maybe we could remove some not needed strings, I guess, but I do not see any problem here...

#12 @iseulde
5 years ago

I don't see why the admin should use the same date format as the blog/site. That doesn't make any sense to me.
If, however, this does make sense for everyone else, then we should also change the date format in the post/page/comment/... list, "Draft saved at...", Dashboard activity widget, the "Publish" meta box, the "Revisions" meta box, and I'm probably forgetting a few things.

One other argument against using the option: in some cases it makes more sense to use a shorter or longer date format, which are all translated differently. I don't think it would be a bad idea to have a shortcut to use these in core, to make it easier for plugins to pick a date format that is properly localised.

Last edited 5 years ago by iseulde (previous) (diff)

#13 @iseulde
5 years ago

  • Summary changed from Media Grid: Attachment Details: Date format not translated to Date format inconsistent across the admin

Updating the summary...

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#15 follow-up: @markjaquith
5 years ago

I agree that this setting shouldn't affect the backend. My take:

  1. This setting should affect the front of the site only.
  2. Maybe it should be moved to "Reading" to reflect that.
  3. We should have, in core, filterable, localized "short" and "long" date/time and date-time format strings that we use in core and that developers can use.

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#17 follow-up: @samuelsidler
5 years ago

  • Priority changed from normal to low

I think we should push this to 4.3. It's not a new issue in 4.2 and it's not critical to fix.

#18 @SergeyBiryukov
5 years ago

  • Milestone changed from 4.2 to Future Release

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

@iseulde
5 years ago

#21 @iseulde
5 years ago

  • Keywords has-patch added; needs-patch removed

If I decide to leave out the year, add the name of the day or want seconds to be visible as well on my blog, or do something really weird with it, it should not affect the admin.

#22 in reply to: ↑ 17 @transl8or
5 years ago

Replying to samuelsidler:

I think we should push this to 4.3. It's not a new issue in 4.2 and it's not critical to fix.

Hi all,

I started contributing to the lastest translations, especially
(formal and normal) german and had to walk throu some of my WordPress
Test- and Live-Installations to get some consistency in words and context.

As this is also an issue with the date shown in various places I thought I'd share this with
you and hope for an solution/integration in WordPress 4.3.

I have already posted about it here: https://wordpress.org/support/topic/missing-the-year-in-the-activity-widget-in-the-dashboard but haven't read through this ticket.
I'm with Mark on the the point of having the choice to have different date settings
for backend and frontend and even different (frontend) sites in a mulitsite install...
Haven't thought about that back then. But I think it should be consistent at the backend.

Also I'd be glad if the Activity Widget could have the Year displayed beside the post.
It can't really be a matter of place if you use a short format like mm/dd/yy or dd.mm.yy ?!
I think it looks a bit odd not to say incomplete without the year and then immediately the comma before the time. Screenshot: http://workupload.com/file/mokLvgmf

And then have a preview for all posts where the time is without a leading zero and instead seconds, which are not really necessary there.
Screenshot (widescreen): http://workupload.com/file/QpzuA6lY
Screenshot (breakpoint 700x): http://workupload.com/file/KmmIjH1f

Thanks for working that out.
Danke für's Überarbeiten.
Fortfahren. :-)

@iseulde
4 years ago

#23 @iseulde
4 years ago

In 35811:

Make date format consistent across the admin

The 'date_format' and 'time_format' options shouldn't affect the backend.

See #30864

#24 in reply to: ↑ 15 @iseulde
4 years ago

  • Milestone changed from Future Release to 4.5

What's left here? Maybe 2. Let's move 3 to a different ticket.

Replying to markjaquith:

I agree that this setting shouldn't affect the backend. My take:

  1. This setting should affect the front of the site only.
  2. Maybe it should be moved to "Reading" to reflect that.
  3. We should have, in core, filterable, localized "short" and "long" date/time and date-time format strings that we use in core and that developers can use.
Last edited 4 years ago by iseulde (previous) (diff)

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


4 years ago

#26 @chriscct7
4 years ago

  • Owner set to iseulde
  • Status changed from new to assigned

@iseulde is there anything left to do except splitting off the ticket?

#27 @iseulde
4 years ago

Decide whether or not the setting should be moved to "Reading".

#28 @azaozz
4 years ago

We should have, in core, filterable, localized "short" and "long" date/time and date-time format strings that we use in core and that developers can use.

Absolutely agree. We should do what all operating systems are doing: have a place to store locale settings and then use them everywhere. If translators want to change a particular instance, they still can. If the users want to change that for the site -- they can with the (old) option.

Thinking we need something like localized_date_time array with short and long date formats, and short and long (with seconds) time formats? That should be settable by translating the default settings.

Last edited 4 years ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


4 years ago

#30 follow-up: @chriscct7
4 years ago

An option that could be considered is we could call whats merged into core for that ticket done and split the stuff in comments 27 and 28 to new tickets for next release. Any thoughts on that @azaozz + @iseulde?

#31 in reply to: ↑ 30 @azaozz
4 years ago

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

Replying to chriscct7:

Yeah, makes sense. Fixed with [35811].

Note: See TracTickets for help on using tickets.