Blocks: Add i18n support to register_block_type_from_metadata

[gziolo]

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

Related issue in Gutenberg: WordPress/gutenberg#23636.

Related PR in WP-CLI from @swissspidy: wp-cli/i18n-command#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 (wp-cli/i18n-command#210) native support for translatable strings extraction from block.json file in i18n command. It was based on the aforementioned document.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[ocean90]

I'm missing the part where the text domain is passed to register_block_script_handle() so that wp_set_script_translations() can be called. Is that still being added?

[gziolo]

I'm missing the part where the text domain is passed to register_block_script_handle() so that wp_set_script_translations() can be called. Is that still being added?

Right, I think I missed it. I saw something similar added to Create Block, but it wasn't backported to the core.

https://github.com/WordPress/gutenberg/blob/556505024833dd815dbc365e75c2279f003cd472/packages/create-block/lib/templates/esnext/%24slug.php.mustache#L45

[gziolo]

@ocean90, is it good to assume that if there is no textdomain defined in block.json that this block/plugin isn't meant to be translated?

[ocean90]

I'd say so, yes. Would core blocks set it to default? But it actually doesn't seem like it will ever be empty due to the default being default?

wordpress-develop/src/wp-includes/blocks.php

Line 238 in b35353a

$textdomain = isset( $metadata['textdomain'] ) ? $metadata['textdomain'] : 'default';

[gziolo]

True, I thought I removed this line 😅
Yes, I believe we either explicitly set it to default for core blocks or auto-detect them through core namespace in the block name and auto-apply default this way.

[gziolo]

I removed this fallback for now as it's way more complicated for blocks than for plugins where we have:

    // If no text domain is defined fall back to the plugin slug.
    if ( ! $plugin_data['TextDomain'] ) {
        $plugin_slug = dirname( plugin_basename( $plugin_file ) );
        if ( '.' !== $plugin_slug && false === strpos( $plugin_slug, '/' ) ) {
            $plugin_data['TextDomain'] = $plugin_slug;
        }
    }

Plugins fall back to the plugin slug, so we could do the same. What do you think?

The challenges I see:

• block.json can be located anywhere, so the parent folder might be not the best way to pick
• block.json might be inside the plugin so it would have the textdomain define but the challenge is how to read it
• block.json might be inside the theme so it would have the textdomain define but the challenge is how to read it
• name field is constructed from namespace/slug so we could use it in a quite reliable way

[lukecarbis]

This PR will need eyes from the documentation team.

[hellofromtonya]

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

[ZebulanStanphill]

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

[gziolo]

@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 it follows that. 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/