Site editor: last modified time is not translatable

[oandregal]

Description

Some strings from global styles revisions are not translatable.

Step-by-step reproduction instructions

• Switch your WordPress environment to a language other than English that is 100% translated (e.g.: Spanish).
• Visit "Appearance > Styles".
• Provided you have some style revision you'll see the last modified time at the bottom. Note how the time specifier (minutes, hours, days) is not translated:

• Click on it, which opens the global styles revisions sidebar. There's the same issue there (note the "minutes", "a day", or "days" strings):

Environment info

I tested this on WordPress 6.3, though the string comes from Gutenberg.

The corresponding lines point to the use of humanTimeDiff function here and here.

[oandregal]

cc @ramonjd @andrewserong

[oandregal]

The same happens when visiting a page details in "Appearance > Pages > SomePage"

Note the "days" string at the botton right, when it should be "días".

[ramonjd]

Looks like humanTimeDiff doesn't set the locale.

i can try to fix

[ramonjd]

Looks like humanTimeDiff doesn't set the locale.

Not sure about this now. The output of wp.date.getSettings() in the editor shows the right locale and relative translations:

So it might be the way, or even when, we're calling these functions that's causing the problems. The locale is set correctly in the source.

Though for me in development, the entire block editor is not translated (tried setting ES and DE as my language in both WP and browser), so I probably need to look at that first.

I'm away until next week so I can take a closer look then. Thanks!

[ramonjd]

Oh wait, we probably need to add further relative translations. See Core:

https://github.com/WordPress/wordpress-develop/blob/bf00a673a5f1d7f4707a6f914e1408526a8dc06a/src/wp-includes/script-loader.php#L430

And the rest in Gutenberg:

gutenberg/packages/date/src/index.js

Line 111 in eed863a

relative: {

[t-hamano]

I was also able to reproduce this problem.

Oh wait, we probably need to add further relative translations. See Core:

https://github.com/WordPress/wordpress-develop/blob/bf00a673a5f1d7f4707a6f914e1408526a8dc06a/src/wp-includes/script-loader.php#L430

As a test, I temporarily hard-coded all the formats for a particular site language as follows, and confirmed that the output was as expected.

function wp_default_packages_inline_scripts( $scripts ) {
	// ...
	$scripts->add_inline_script(
		'wp-date',
		sprintf(
			'wp.date.setSettings( %s );',
			wp_json_encode(
				array(
					'l10n'     => array(
						// ...
						'relative'      => array(
							/* translators: %s: Duration. */
							'future' => __( '%s from now' ),
							/* translators: %s: Duration. */
							'past'   => __( '%s ago' ),
							's'      => '一秒以内',
							'ss'     => '%d秒',
							'm'      => '一分',
							'mm'     => '%d分',
							'h'      => '一時間',
							'hh'     => '%d時間',
							'd'      => '一日',
							'dd'     => '%d日',
							'M'      => '一ヶ月',
							'MM'     => '%dヶ月',
							'y'      => '一年',
							'yy'     => '%d年',
						),
					),
					// ...
				)
			)
		),
		'after'
	);
	// ...
}

And the rest in Gutenberg:

If the newly required format is not currently needed in the core, should it be added on the Gutenberg side? Another fundamental problem may be that the format string is hard-coded in the first place.

[ramonjd]

If the newly required format is not currently needed in the core, should it be added on the Gutenberg side? Another fundamental problem may be that the format string is hard-coded in the first place.

Thanks for double-checking!! 🙇🏻

Yep, we'll need something on the Gutenberg side. I haven't tested this theory yet, but I'm hoping we could add an updated inline script from the plugin and thereby make another call to wp.date.setSettings() to get the new translations.

If the newly required format is not currently needed in the core

Since 6.3 it is :) So the core patch would augment the existing values.

[ramonjd]

I've added something to Gutenberg in #53931

I'll do the core patch on Monday.

The slight complication is that it requires translations so it's not a "right now" fix.

An alternative might be to just use a formatted date for these fields instead of humanTimeDiff() however the relative time strings should be translated anyway (they were added in Gutenberg > 4 years ago but never synced to Core :( )

[swissspidy]

This was originally reported at https://core.trac.wordpress.org/ticket/47373

What's the reason for fixing this first in Gutenberg by patching core, rather than just fixing this in trunk directly? That just creates more friction and confusion. Not to mention that the GB PR won't do anything anyway when the strings aren't existing & translated in core, which would make it quite pointless.

[oandregal]

This was originally reported at https://core.trac.wordpress.org/ticket/47373

Oh, I wasn't aware of it. Thanks for sharing.

What's the reason for fixing this first in Gutenberg by patching core, rather than just fixing this in trunk directly? That just creates more friction and confusion. Not to mention that the GB PR won't do anything anyway when the strings aren't existing & translated in core, which would make it quite pointless.

Gutenberg supports the last two WordPress releases. At the moment, WordPress 6.2 and WordPress 6.3. Even when/if the fix is released as part of WordPress 6.4, Gutenberg still has to support WordPress 6.3. I think it's worth enabling users to see the string in their language faster than 6.4 is available (and before they update).

[oandregal]

Not to mention that the GB PR won't do anything anyway when the strings aren't existing & translated in core, which would make it quite pointless.

Oh, let me unwrap this @swissspidy. My understanding is that because Gutenberg creates new strings, those will be available for translation as soon as the corresponding Gutenberg version is released (16.6, in a few days). Is this correct?

[swissspidy]

My understanding is that because Gutenberg creates new strings, those will be available for translation as soon as the corresponding Gutenberg version is released (16.6, in a few days). Is this correct?

Yes and no.

The strings will be picked up by string extraction and can be translated in the Gutenberg project on translate.wordpress.org, but since you are using the default text domain to load the translation, the translations won't actually get loaded. So it doesn't work.
If you actually want to bring this to users faster, you'd need to change the text domain to gutenberg (just in the plugin, not in the core patch of course).

[oandregal]

Got it. Thanks, Pascal. Prepared a fix at #53995

[ramonjd]

The strings will be picked up by string extraction and can be translated in the Gutenberg project on translate.wordpress.org, but since you are using the default text domain to load the translation, the translations won't actually get loaded. So it doesn't work.

TIL

Thanks for the explainer. I wasn't sure, thinking that default would come from Core.