-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blocks: Add i18n support to register_block_type_from_metadata #868
Blocks: Add i18n support to register_block_type_from_metadata #868
Conversation
I'm missing the part where the text domain is passed to |
Right, I think I missed it. I saw something similar added to Create Block, but it wasn't backported to the core. |
return false; | ||
} | ||
|
||
if ( ! empty( $metadata['textdomain'] ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 pickblock.json
might be inside the plugin so it would have the textdomain define but the challenge is how to read itblock.json
might be inside the theme so it would have the textdomain define but the challenge is how to read itname
field is constructed fromnamespace/slug
so we could use it in a quite reliable way
This PR will need eyes from the documentation team. |
Merged in changeset https://core.trac.wordpress.org/changeset/49981 and https://core.trac.wordpress.org/changeset/49982 |
Shouldn't |
@ZebulanStanphill, I know it's confusing. In the written language it's two words so you would expect
|
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 ini18n
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.