Extract translatable strings from block.json files

[swissspidy]

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

For supporting the next iteration of Gutenberg block development, we need to extract strings from block.json files.

Describe the solution you'd like

wp i18n make-pot should parse block.json files and extract all strings it finds with the additional context.

For more information, check out:

• Add the block registration RFC WordPress/gutenberg#13693
• Replace inline JSON Babel plugin with a custom version which supports i18n WordPress/gutenberg#15169

[swissspidy]

Here's the final RFC: https://github.com/WordPress/gutenberg/blob/76aa7154913d54985ffbb57b695c9d7e86492124/docs/rfc/block-registration.md

[gziolo]

I have just closed WordPress/gutenberg#16088 where we all agreed that i18n-command should extract translatable strings from block.json file.

Re-sharing comment from @swissspidy:

I can potentially help with implementation as I built large parts of that tool and am familiar with it. Then, I suppose @ocean90 could help update it on dotorg.

The challenge would be only how WP-CLI locates all block.json files

Just like WP-CLI scans all JS and PHP files for translation functions, it would then also scan all block.json files that are deemed valid. Don't see a huge difficulty there.

I explored building Babel plugin which takes care of converting block.json into JavaScript code but we decided that we shouldn't go in that direction. Here are some snippets of code which should help with the implementation:

const translatableProperties = [
 	'title',
 	'description',
 	'keywords',
 	'styles',
 ];

function wrapTranslatableProperty( node, name, textDomain, types ) {
 	if ( node.type === 'StringLiteral' && node.value ) {
 		node = types.callExpression(
 			types.identifier( '__x' ),
 			[
 				node,
 				types.stringLiteral( `block ${ name }` ),
 				textDomain !== 'default' && types.stringLiteral( textDomain ),
 			].filter( Boolean )
 		);
 	} else if ( node.type === 'ArrayExpression' ) {
 		node.elements = node.elements.map(
 			( elementNode ) => wrapTranslatableProperty(
 				elementNode,
 				name,
 				textDomain,
 				types
 			)
 		);
 	} else if ( node.type === 'ObjectExpression' ) {
 		node.properties.forEach( ( propertyNode ) => {
 			if ( propertyNode.key.name === 'label' ) {
 				propertyNode.value = wrapTranslatableProperty(
 					propertyNode.value,
 					name,
 					textDomain,
 					types
 				);
 			}
 		} );
 	}
 	return node;
 }

The gist of it is:

• string (title and description) and string[] (keywords) are translatable when whitelisted
• for Object[] only label properties are translatable for each object listed (this is only for styles at the moment)

[swissspidy]

@gziolo Thanks for the update! How often do you think the list of translatable properties would change? It might be safer to have title, description, keywords, and styles.label* whitelisted in WP-CLI.

* What about styleVariations?

[gziolo]

@gziolo Thanks for the update! How often do you think the list of translatable properties would change? It might be safer to have title, description, keywords, and styles.label* whitelisted in WP-CLI.

• What about styleVariations?

styleVariations is an alias for styles that is the legacy name and a bit ambiguous.

The whitelist approach is perfectly fine. I don't expect to change it frequently. Only if we decide to add new fields but I don't see any reasons for that as of today.

[swissspidy]

Thanks for the quick response!

Sounds like a relatively easy thing to implement then :-)

[gziolo]

@swissspidy – it seems to be one of the last blockers for making block.json a thing. Can you share some pointers about how this could be implemented? Maybe some prior art (PR or commit)?

[swissspidy]

@gziolo Heya, I created #210 as a starting point for this.