Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#49388 closed defect (bug) (invalid)

Default date/time formats for non-US English locales are incorrect

Reported by: getsnoopy's profile getsnoopy Owned by: getsnoopy's profile getsnoopy
Milestone: Priority: normal
Severity: normal Version:
Component: Date/Time Keywords:
Focuses: Cc:

Description

The default date/time formats (i.e., the first options listed under the "Date Format" and "Time Format" fields in Settings > General) are incorrect for non-US English locales. For example, the default suggests "jS F Y", but the correct one is simply "j F Y". This issue exists for other English locales as well, and similarly with the time format.

Change History (5)

#1 follow-up: @SergeyBiryukov
5 years ago

  • Component changed from General to Date/Time
  • Focuses ui-copy removed
  • Keywords reporter-feedback added

Hi there, welcome to WordPress Trac! Thanks for the report.

The default date format in General Settings is actually F j, Y, as seen in wp-admin/includes/schema.php.

Date format is a translatable setting, each locale provides its own format. Russian uses d.m.Y, for example.

Which locale are you using?

#2 in reply to: ↑ 1 ; follow-up: @getsnoopy
5 years ago

I see now that my phrasing could've been better. By "non-US English locales", I meant "non-US, English locales"; i.e., non en-US English locales, so these would be en-GB, en-AU, en-NZ, en-ZA, and en-CA. It seems like the translated versions of those formats in those locales are incorrect.

But I also now realize that the default format should be changed as well, since en-US is the only locale that uses "F j, Y" as the date format, while basically every other locale/country use the long-form international DMY date format "j F Y" (RFC 2822) or the numerical international DMY date formats "Y-m-d" (ISO 8601) or "d/m/Y". The "F j, Y" format can be added to just the en-US locale.

#3 in reply to: ↑ 2 ; follow-up: @siliconforks
5 years ago

Replying to getsnoopy:

I see now that my phrasing could've been better. By "non-US English locales", I meant "non-US, English locales"; i.e., non en-US English locales, so these would be en-GB, en-AU, en-NZ, en-ZA, and en-CA. It seems like the translated versions of those formats in those locales are incorrect.

That's not really true for en-CA - "F j, Y" is more commonly used in Canadian English.

But I also now realize that the default format should be changed as well, since en-US is the only locale that uses "F j, Y" as the date format, while basically every other locale/country use the long-form international DMY date format "j F Y" (RFC 2822) or the numerical international DMY date formats "Y-m-d" (ISO 8601) or "d/m/Y". The "F j, Y" format can be added to just the en-US locale.

I don't see how an en-US translation could be "added to just the en-US locale" - if a WordPress installation uses the en-US locale, it doesn't install any translation files at all; it just uses the default translatable strings (which are assumed to already be in the en-US locale).

Probably the thing that needs to be fixed is the translation you have installed, which should change "jS F Y" to "j F Y". Which locale are you using - is it en-GB?

#4 in reply to: ↑ 3 @getsnoopy
5 years ago

Replying to siliconforks:

That's not really true for en-CA - "F j, Y" is more commonly used in Canadian English.

The official date format for Canada is "j F Y" for both French and English. "F j, Y" is allowed as an exception for English, and it is common only because of its proximity and ties to the US.

I don't see how an en-US translation could be "added to just the en-US locale" - if a WordPress installation uses the en-US locale, it doesn't install any translation files at all; it just uses the default translatable strings (which are assumed to already be in the en-US locale).

Probably the thing that needs to be fixed is the translation you have installed, which should change "jS F Y" to "j F Y". Which locale are you using - is it en-GB?

Interesting. That seems like a separate and deeper issue then. But yes, I've checked all of the English non-US locales, and they all have this issue. I've actually suggested fixes for those strings via the translation UI; that should eventually fix the issue, yeah?

#5 @Rarst
5 years ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

Thank you for reviewing these. :)

The default strings in core code are considered to be US English, so it sounds like there is no issue with them here.

Localized strings should be handled as part of core translation process (which you did) and are not a subject to core development in this case.

Note: See TracTickets for help on using tickets.