Block API: Add i18n support to block.json metadata file

[gziolo]

Part of #16209.

There are some issues related to internationalization (i18n) support in newly introduced block.json metadata files that still need to be resolved.

There is a proposal in block registration metadata document that we still need to implement:
https://github.com/WordPress/gutenberg/blob/trunk/docs/reference-guides/block-api/block-metadata.md#internationalization

The good news is that WP-CLI has implemented (wp-cli/i18n-command#210) native support for translatable strings extraction from block.json file in i18n command. It was based on the aforementioned RFC. It still needs to be released though.

JavaScript

1. JSON imports work only in Node.js or with webpack tool. In Gutenberg, we use a custom plugin that inlines JSON in JavaScript as a plain object. We should decide whether we add the same plugin to the shared Babel preset (@wordpress/babel-preset-default) distributed as part of WordPress packages.
2. We miss the logic that wraps translatable fields with i18n functions, it still needs to be added. In the past, there was a failed attempt to build a Babel macro that would address both points but it wasn’t as straightforward as expected. We were afraid it could be a point of bugs when not configured properly. Related PR: Babel macro: Add new Babel macro which handles block.json file transformation #16088.

PHP (Implemented)

The same issue applies to i18n handling on the PHP side of things. There was a new register_block_type_from_metadata utility function added in #20794 to make it possible to register a new block type using block.json metadata file. It's still missing i18n support.

Temporary support

The temporary approach for 3rd party blocks that want to use register_block_type_from_metadata would be to keep everything that doesn't need to be translated in block.json and put the rest as additional params passed with 2nd argument, e.g.:

register_block_type_from_metadata( __DIR__, array(
	'title'       => _x( 'My block', 'block title', 'my-plugin-domain' ),
	'description' => _x( 'My block is fantastic!', 'block description', 'my-plugin-domain' ),
	'keywords'    => array( _x( 'fantastic', 'block keywords', 'my-plugin-domain' ) ),
) );

[swissspidy]

What's also missing here is the whole WordPress.org part and what the translation files will look like. We currently use JSON files with MD5 hashes for JS translations, and PO files for PHP translations. Where do block translations live?

[noisysocks]

👋 ended up here because of the [Priority] High label. What's the status of this one? Should we prioritise it for 5.7?

[gziolo]

Yes, that would be great. In fact, it requires changes on the WordPress core side because we lack filters in register_block_type_from_metadata. Relate proposal for filters in WordPress/wordpress-develop#821.

@jorgefilipecosta works on a similar proposal for a theme.json file in #27380. It should help to drive this integration. I don't think it's a blocker though 😃

@noisysocks, do you plan to take care of it or you only wanted to triage labels?

[noisysocks]

@noisysocks, do you plan to take care of it or you only wanted to triage labels?

Just triaging! This issue will need an owner.

[gziolo]

I opened PR targeting the WordPress core: WordPress/wordpress-develop#868.

[gziolo]

On the PHP side of things, everything is sorted out with https://core.trac.wordpress.org/ticket/52301. You can now register a block type using:

register_block_type_from_metadata( __DIR__ );

It will load the block.json file from the current directory and translate fields that are listed as translatable when the textdomain is provided.

I plan to update the client-side code to ensure it doesn't override the block metadata registered on the server for core blocks.

[noisysocks]

Removing this from the 5.7 board per this comment from @gziolo:

#23636 won’t have more items in WP 5.7, it requires some more fiddling on the Gutenberg side to make it work and it depends on the changes that are included in WP core for 5.7.

[gziolo]

I started JS implementation in #30293.