Blocks: Add i18n support to register_block_type_from_metadata

[gziolo]

Related issue in Gutenberg: ​https://github.com/WordPress/gutenberg/issues/23636.

Related PR in WP-CLI from @swissspidy: ​https://github.com/wp-cli/i18n-command/pull/210.

Description

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

There is a proposal in block registration document that we still need to implement:
​https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-metadata.md#internationalization-not-implemented

The good news is that WP-CLI has implemented (​https://github.com/wp-cli/i18n-command/pull/210) native support for translatable strings extraction from block.json file in i18n command. It was based on the aforementioned document.

Code

​https://github.com/WordPress/wordpress-develop/pull/868

Trac ticket: https://core.trac.wordpress.org/ticket/52301

Related issue in Gutenberg: ​https://github.com/WordPress/gutenberg/issues/23636.

Related PR in WP-CLI from @swissspidy: ​https://github.com/wp-cli/i18n-command/pull/210.

## Description

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

There is a proposal in block registration document that we still need to implement:
​https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-metadata.md#internationalization-not-implemented

The good news is that WP-CLI has implemented (​https://github.com/wp-cli/i18n-command/pull/210) native support for translatable strings extraction from block.json file in i18n command. It was based on the aforementioned document.

This PR will need eyes from the documentation team.

[gziolo]

In 49981:

Blocks: Add i18n support to register_block_type_from_metadata

Related Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/23636.
Related WP-CLI PR: ​https://github.com/wp-cli/i18n-command/pull/210.
Related documentation proposal: ​https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-metadata.md#internationalization-not-implemented

Adds programatic i18n support to register_block_type_from_metadata function for block settings registered from block.json file that provides textdomain field.

Props swissspidy, ocean90.
Fixes #52301.

[gziolo]

In 49982:

Blocks: Add automatic RTL handlind for block styles registered from metadata

Related Gutenberg issue: ​https://github.com/WordPress/gutenberg/pull/28274

With this change it is going to be possible to use the same pattern that wp_style_add_data uses for RTL handling. If the block style file with "-rtl.css" is included in addition to the regular style referenced in "block.json" file then it is going to be automatically registered.

Props swisspidy, aristath.
See #52301.

Merged in changeset https://core.trac.wordpress.org/changeset/49981 and https://core.trac.wordpress.org/changeset/49982

Shouldn't textdomain be textDomain to match the camelCase already being used for editorScript and editorStyle?

@ZebulanStanphill, I know it's confusing. In the written language it's two words so you would expect text_domain in PHP and textDomain in JavaScript, but in practice, it' was mostly textdomain in PHP codebase so followed it. Related docs:

• ​https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-metadata.md#text-domain
• ​https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/#text-domains
• ​https://developer.wordpress.org/reference/functions/load_plugin_textdomain/

[gziolo]

Related documentation changes in Gutenberg: ​https://github.com/WordPress/gutenberg/pull/29023.