Theme Directory - localize update date

[ramiy]

The "Last updated" string in theme pages needs to be localized.

See here: ​https://he.wordpress.org/themes/twentyfifteen/

And in the attached screenshot.

[ramiy]

Related: #1270

[dd32]

FWIW the patch here only applies to the Server-generated text.

On load, and when viewing a new theme, it's replaced with the localised date according to your browser through JS.

[ramiy]

Add wporg-themes textdomain to the _x() function

[ocean90]

@ramiy Do you have JavaScript disabled? Which browser are you using?

[ramiy]

@ocean90,
Crome + JS enabled

[ramiy]

You are right, on firefox it's in hebrew.

[ocean90]

Replying to ramiy:

@ocean90,
Crome + JS enabled

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-themes/js/theme.js#L478 should take care of the dates. meta-1269.2.patch​ wouldn't help you…

[ramiy]

Ok, so on chrome it loads in hebrew and after a second or two the date changes to english.

[ramiy]

Replying to ocean90:

Replying to ramiy:

@ocean90,
Crome + JS enabled

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-themes/js/theme.js#L478 should take care of the dates. meta-1269.2.patch​ wouldn't help you…

Dominic, The patch will help me to control the date format, I need to add a coma to the date.

[ocean90]

Again, this is a JavaScript template. That's why we let JavaScript handle the date format. Not sure why it doesn't work in your Chrome.

[SergeyBiryukov]

Replying to ocean90:

Again, this is a JavaScript template. That's why we let JavaScript handle the date format. Not sure why it doesn't work in your Chrome.

It doesn't work for me either. It loads in Russian, but then changes to English, probably because my browser UI is set to English.

It does work if I switch the browser UI to Russian. I guess it's OK, but seems inconsistent with the plugin directory.

Also, when JavaScript is disabled, it's hardcoded to use the F j, Y format, which is not suitable for languages with declensions (​#WP11226). "Декабрь 6, 2015" is not correct Russian, "6 декабря 2015" is. That's why we generally use d.m.Y instead of F j, Y.

Ideally, I'd like to switch to human_time_diff(), like we did for plugin directory in #1270. But I guess that would be tricky, because it involves either adding a field in that format to the API or performing an additional request. Recreating the function in JavaScript doesn't seem feasible either, because we need _n() to work.

Could we at least commit meta-1269.2.patch​ to benefit from ​[WP35517] when JS is disabled? :)

[ramiy]

Replying to SergeyBiryukov:

Ideally, I'd like to switch to human_time_diff(), as we did for plugin directory in #1270.

I agree, we should use human time diff everywhere!

[Otto42]

I think it's more likely that we'll eliminate human time diffs in the plugin directory, since it will eventually be an API driven page just like the theme directory is.

Unless you have a localizable JS version of human time diff handy.

[ramiy]

@Otto42, the human_time_diff() function doesn't seems like a very complicate functions.

​https://core.trac.wordpress.org/browser/tags/4.4/src/wp-includes/formatting.php#L2825

If needed, we can create a JS version to return the same output.

[coffee2code]

In 5704:

Theme Directory: Allow the last updated date to be localized.

Props SergeyBiryukov, ramiy.
Fixes #1269.

[ramiy]

It didn't helped... :-(

Reopening the ticket.

[coffee2code]

@ramiy: What do you recommend at this point? It sounds like, as Sergey noted, that your browser UI is set to English or some other language different than the site being loaded. With JS enabled, JS will reformat the date according to the browser settings, which looks to be what is intended.

[obenland]

In 6359:

Themes: Improve localized date display.

This will not solve it for all languages, but at least the more popular ones should see a benefit.

See ​https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString#Using_locales
Fixes #1269.