Size Change: -3 B (0%)

Total Size: 1.05 MB

_{compressed-size-action}

Hmmm I'm not sure we need this...
Traditional, PHP-based themes needed translations 'cause the user was unable to edit the files directly. In a block-based theme however, users can just edit their templates and change whatever text they want, so having translations for preset templates seems to me a bit of an overkill.
That being said, I understand that the above opinion may not be shared by others. In case we do want to make these translatable, then perhaps adding a new block would over-complicate things? A block is (usually) available in the UI, and we wouldn't want a "translatable text" block to be available to end-users, it would be too confusing. So chances are if we add this it will be hidden in the UI. But if it's hidden in the UI, then maybe it would be better to just have a UI-less translatable attribute available to some blocks instead of adding a new block? 🤔
So instead of this:

<!-- wp:heading -->
<h2><!-- wp:i18n { "text": "Results:" } /--></h2>
<!-- /wp:heading -->

it would look something like this:

<!-- wp:heading { "translatable-text": "Results" } -->
<h2>Results</h2>
<!-- /wp:heading -->

Agreed, while it's been an open discussion for a while, we haven't seen a lot of concrete use cases surface that would warrant a more complex system in place. Variants of localized text and content is something we do want to properly tackle for phase 4 at a site and user level, taking all those complexities into consideration, and I don't expect a block grammar solution to be in place until those requirements are made explicit.

The examples I've seen so far generally fall into two groups: things that should be absorbed into blocks as defaults ("previous page / next page" on navigation, for example; or "no results" on query) and things that can be thought of as theme patterns, like the content of an opinionated 404 template.

In that sense, I think patterns are a possible solution that has merit because it also addresses another current limitation — allowing a theme to design the content of a template or part while also making it available as a pattern for users. So maybe a wp:pattern block that's scoped to the theme directory could allow a theme to introduce these more opinionated designs with translatable text by default in a theme.

For the context, my previous exploration of almost the same idea: #23268. I shared the conclusions in #23268 (comment):

This approach doesn't look very promising so I will close this PR. It was nice to go through the process to gather some feedback and see better what kind of challenges we are facing here.

I had a quite interesting discussion with @mtias about an alternative approach that we could investigate. I wanted to quickly summarize the idea. There is this registerFormatType API method developed by @ellatrix. I was wondering if we could implement tokens based on this concept using <data> HTML tag.

The HTML <data> element links a given piece of content with a machine-readable translation. If the content is time- or date-related, the <time> element must be used.

Example usage would be:

<data value="token/translation">Cherry Tomato</data>

On the server, there would be a logic that parses the output generated and runs filters registered for data tokens:

function block_content_token_translation( $content, $value ) {
    if ( $value !== 'token/translation' ) {
        return $content;
    }
    return __( $content );
}
add_filter( 'block_content_token', 'block_content_token_translation' );

UI part would work very similar to how other RichText formatting controls work as of today, closer to the concept of annotations though.

Anyway, it's one year old now so things might changed 😄