Comments Query Loop block title is not being translated

[cbravobernal]

Comments Query Loop block title is not being translated.

Tested with 6.0 local version in French, Chinese and Spanish.

Steps to reproduce:
1.) Set a language different than English.
2.) Go to a Post.
3.) Add Comments Query Loop block.
4.) Check that the block title is not being translated.

The PO translation files seems to be ok, so I still cannot tell which is the cause of this issue.

[audrasjb]

It appears on trunk.
Moving for 6.0.1 consideration.

Thanks!

[mukesh27]

Additionally, this block(Comments Query Loop) description is also not translated.

[peterwilsoncc]

This report has been logged in the Gutenberg repository as ​#41292. It appears the bug needs to be fixed in the package managed there.

I'll edit the issue to note it also applies to the description per @mukesh27's follow up comment.

I've closed this issue as reported-upstream. It's a valid and correct report but now it's reported in the Gutenberg issue tracker it's better the conversation continues there.

Thanks folks.

Add server-side registration so we can fix Comment Query Loop title and description not being translated.

​More info on the issue.

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

Confirming that I see the block title translated:

A lot of unit tests are failing, but those seem unrelated to me (?)

I'm checking and running on local. Anyway, here there are not reviews-merges, they are done in Trac 😄

I had another look at the unit tests.

All 18 failures are actually the same (although they happen in different locations):

Unexpected incorrect usage notice for WP_Block_Type_Registry::register
Failed asserting that an array is empty.

I had one idea -- maybe we _are_ doing something wrong when registering the block.

Turns out that the PHP for individual blocks is synced from Gutenberg via npm packages (see e.g. 619693e75fad97f4b67bc4cf600902933d73587c an example).

So basically, we don't really edit src/wp-includes/blocks/my-block.php directly; instead, we:

1. make the changes in Gutenberg to packages/block-library/src/my-block/index.php,
2. publish a new npm version of @wordpress/block-library with those changes, and
3. file a PR against wordpress-develop with a version bump for @wordpress/block-library accordingly. Judging from 619693e75fad97f4b67bc4cf600902933d73587c, I _think_ that the version bump is generated by running npm run sync-gutenberg-packages

I'm not 100% sure this is the reason for the unit test failure, but it might be. Regardless, it seems to be how block changes need to be made 😅 (And yeah, if wonder if this is documented anywhere.)

I'm not 100% sure this is the reason for the unit test failure, but it might be. Regardless, it seems to be how block changes need to be made 😅

I realize that this might be tricky since we've already changed the directory name to comments in Gutenberg 😕

But here's another thought -- unit tests are specifically complaining about an "incorrect usage notice for WP_Block_Type_Registry::register). So maybe we can at least observe those locally (either when running unit tests, or maybe when running wordpress-develop's development instance).

I managed to track down the incorrect usage notice that's being triggered; it's this:

Block type "core/comments-query-loop" is already registered.

I think that error makes sense; after all, the Comments Query Loop block has already been registered prior to this PR. So now we have to find where that was happening and probably disable it.

I tried grepping for other occurrences of comments-query loop and found this: ​https://github.com/WordPress/wordpress-develop/blob/a5b555aac3b95d368efd2c69c057d23d836acc86/tools/webpack/blocks.js#L92

I think this is a likely candidate -- some Webpack plugin that gets information about all static and dynamic blocks, separately.

So I tried moving comments-query-loop from the static to the dynamic section

{{{diff
diff --git a/tools/webpack/blocks.js b/tools/webpack/blocks.js
index 3250df5bbf..05b50d5e4d 100644
--- a/tools/webpack/blocks.js
+++ b/tools/webpack/blocks.js
@@ -38,6 +38,7 @@ module.exports = function( env = { environment: 'production', watch: false, buil

'comments-pagination-next',
'comments-pagination-numbers',
'comments-pagination-previous',

+ 'comments-query-loop',

'cover',
'file',
'gallery',

@@ -89,7 +90,6 @@ module.exports = function( env = { environment: 'production', watch: false, buil

'code',
'column',
'columns',

• 'comments-query-loop',

'embed',
'freeform',
'group',

}}}

I then ran npm run build, which unfortunately failed:

Running "webpack:prod" (webpack) task
ERROR in unable to locate 'wordpress-develop/node_modules/@wordpress/block-library/src/comments-query-loop/index.php' glob

webpack compiled with 1 error

Which makes sense, since the @wordpress/block-library package doesn't have a comments-query-loop folder (but a comments one, per our ​rename) 😕

I wonder if we'll have to do an ​npm release with that rename reverted 😕

Closed in favor of #2921

[SergeyBiryukov]

In 53631:

Editor: Register the Comments Query Loop block from metadata.

This ensures that the block title and description can be translated.

Follow-up to [53157].

Props cbravobernal, bernhard-reiter, adamziel, gziolo, peterwilsoncc, audrasjb, mukesh27, SergeyBiryukov.
Fixes #56093. See #55809.

[SergeyBiryukov]

In 53632:

Editor: Register the Comments Query Loop block from metadata.

This ensures that the block title and description can be translated.

Follow-up to [53157].

Props cbravobernal, bernhard-reiter, adamziel, gziolo, peterwilsoncc, audrasjb, mukesh27, SergeyBiryukov.
Merges [53631] to the 6.0 branch.
Fixes #56093. See #55809.

All 18 failures are actually the same (although they happen in different locations):

Unexpected incorrect usage notice for WP_Block_Type_Registry::register
Failed asserting that an array is empty.

I had one idea -- maybe we _are_ doing something wrong when registering the block.
...
I managed to track down the incorrect usage notice that's being triggered; it's this:

Block type "core/comments-query-loop" is already registered.

Just to follow up on this, I've committed a change to the test suite in r53637 to always include the actual _doing_it_wrong() message or deprecation notice in the output if one is encountered, which should hopefully make it easier to track down issues like this in the future 🙂