Not really important, but I recognized recently that the data format in the dashboard is … let’s say, a bit unsorted. I’m not sure whether it started with v2.3.0 or earlier.
Isn’t it in reverse order by date?
Actually it should be 29th, 27th, 18th, 3rd, and 11th. I had chosen the date formats j. F Y for dates and G:i for time, and German language, and everywhere else they are shown correctly. Only in the activity box on the dashboard dates are shown like that. That’s why I said it’s not important, it’s just not as it should be.
Oh, so the order IN the date format is BOTH garbled up AND incorrect (ie. the fallback is borked, too).
Lemme just check on an older install … Yeah, it must have come into place AFTER 2.0 - the old 2.0-based install that I got sitting here for testing purposes (client site) doesnt show this behaviour.
Might be using an incorrect / broken translation string?
cu, w0lf.
1 Like
Uses the function wp_dashboard_recent_posts found in wp-admin/includes/dashboard.php.
I compared both the 2.0 and the current 2.3.1 stable release, and the only difference is a notification / widget added for the CP plugin / theme directory. Everything else is identical - thus its almost certainly a translation string issue.
cu, w0lf.
1 Like
this all boils down to the translation tags being different from the original. What I mean is that basically when localizing a date format (since the destination might be very different from source) one has to replace the source tag with the destination tag, not just messing with the destination tag in the hopes it works. And that means having knowledge about those tags and date formats in PHP and it’s something that doesn’t easily come to mind to check. Also localization software does not like when you change the tag entirely and will throw an error (that localizer do need to ignore as exception). Some time this week I am going to see if it is possible to fix the issue by mass editing the tags in all the strings having it and eventually fix the thing.
2 Likes
This is the relevant PHP section from wp_dashboard_recent_posts:
if ( gmdate( 'Y-m-d', $time ) === $today ) {
$relative = __( 'Today' );
} elseif ( gmdate( 'Y-m-d', $time ) === $tomorrow ) {
$relative = __( 'Tomorrow' );
} elseif ( gmdate( 'Y', $time ) !== $year ) {
/* translators: Date and time format for recent posts on the dashboard, from a different calendar year, see https://www.php.net/manual/datetime.format.php */
$relative = date_i18n( __( 'M jS Y' ), $time );
} else {
/* translators: Date and time format for recent posts on the dashboard, see https://www.php.net/manual/datetime.format.php */
$relative = date_i18n( __( 'M jS' ), $time );
}
So its probably one of the last two if-clauses that are garbled up. The date_i18n function expects a date string.
Docs: date_i18n() – Function | Developer.WordPress.org
cu, w0lf.
yes, but the way crowdin (or any CAT tool work for that matter) is that they translate the date format to a tag and then express the tag as a string. so the issue is I think with the fact that when localizing to a foregn language with different format it does not get the right tag correctly converted.
in source the PHP sends the correct string (that to crowdin is a tag) and in the destination the localizer changes the tag format, and it being different messes up with the display since PHP expect it to match
2 Likes
Hm, I wonder if that tool has something like a “do not translate” marker. That’d probably fix the issue.
cu, w0lf.
It does. But this won’t fix. For a simple reason: Italian date format is different from en. This means if you don’t translate the en format will be left untouched in the destination resulting in dates showing as en strings.
What should happen is that php should detect the correct tag in destination and use the correct format…I am still on it because Crowdin should do the heavy lifting on that and not mess up. Something went wrong somewhere.
1 Like
Yeah, they claim that crowdin “supports” PHP. Looks like they’re just meaning “basics”, not important stuff like date formats. Which is kinda the ultra-basics.
Never trust a tool that promotes itself as “agile”. 
cu, w0lf.
Just an heads up about date formats.
ICU Message Syntax | Crowdin Docs according to this documentation I will have to make sure with each localizer that the correct ICU Message for the locale has been set for all the locale.
Apparently that is the issue at play here, that the ICU Message converting the date format to the one specified for the destination is set the wrong way.
1 Like
Well done for identifying the problem!