[I18n] Label "Move %s" - up/down/left/right not translatable

[pedro-mendonca]

Describe the bug
The labels of the buttons to move blocks, the label is partially missing i18n.
The string Move %s is correct, but the strings that can be included in the placeholder %s are not.
The direction strings up, down, left and right arent't translatable.

To reproduce
Steps to reproduce the behavior:

1. Set your WP install to other locale than en_US
2. Open block editor
3. Create multiple blocks
4. Hover the move arrows on the left of the block (see screenshot below)
5. See error: Move is translatable, the direction isn't.

Expected behavior
The placeholder %s should include a translation of up, down, left or right.
Also, these very short strings MUST have a context.

Screenshots

Additional context

• Tested in WP 5.4 RC1, no standalone Gutenberg installed

[aduth]

This appears to have regressed as part of #16615.

Notably: The labels were previously rendered in their full (and translated) forms, e.g. __( 'Move up' ), etc.

https://github.com/WordPress/gutenberg/pull/16615/files#diff-4d796bdfde89804a60bfac1e1bf3ff9aL64

As described in the original issue, they are now concatenated, but the directional labels are not translatable:

gutenberg/packages/block-editor/src/components/block-mover/index.js

Lines 122 to 125 in cf7f028

	label={ sprintf(
	__( 'Move %s' ),
	getMovementDirection( 'up' )
	) }

gutenberg/packages/block-editor/src/components/block-mover/mover-description.js

Lines 35 to 48 in cf7f028

	const getMovementDirection = ( moveDirection ) => {
	if ( moveDirection === 'up' ) {
	if ( orientation === 'horizontal' ) {
	return isRTL ? 'right' : 'left';
	}
	return 'up';
	} else if ( moveDirection === 'down' ) {
	if ( orientation === 'horizontal' ) {
	return isRTL ? 'left' : 'right';
	}
	return 'down';
	}
	return null;
	};

[aduth]

I added this to the "WordPress 5.4 Must Have" project, since this is a regression of WordPress 5.4. However, it's not clear to me whether it can be fixed at this point, since the 5.4 RC has passed and is typically considered a string freeze.

[aduth]

@pedro-mendonca Do you have a sense whether these labels would be better off implemented in their fully-expanded forms, vs. injected by placeholder?

i.e.

• __( 'Move up' )
• __( 'Move right' )
• __( 'Move down' )
• __( 'Move left' )

[pedro-mendonca]

The current placeholder form generates very small strings that probably need context.
Simple strings as "up", "down", "left" or "right" may vary a lot depending of its context.
It needs specific context so translators know it is to concatenate with "Move %s".

In the end, the current form uses 5 different strings that need very clear and specific contextualization.

The simple __( 'Move up' ) form will end with just 4 strings, no mess.

So... in my opinion... bring back old simple unconcatenated form :-)

[aduth]

I opened a pull request to reintroduce full labels: #20664

[pedro-mendonca]

Awesome, thanks! 👍

[ocean90]

However, it's not clear to me whether it can be fixed at this point

Strings are available since today for translators. As mentioned in the post, string changes may still occur.

This case is something we should definitely get fixed for 5.4.

[pedro-mendonca]

I agree, it’s a bug, not a enhancement.