Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#55809 closed defect (bug) (reported-upstream)

Comments Query Loop block title is not being translated

Reported by: cbravobernal's profile cbravobernal Owned by:
Milestone: Priority: normal
Severity: normal Version: 6.1
Component: Editor Keywords: has-patch
Focuses: javascript Cc:

Description

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.

Attachments (2)

Screenshot 2022-05-24 at 22.22.57.png (171.0 KB) - added by cbravobernal 2 years ago.
Comments Query Loop description.png (8.7 KB) - added by mukesh27 2 years ago.

Download all attachments as: .zip

Change History (20)

This ticket was mentioned in Slack in #core by cbravobernal. View the logs.


2 years ago

#2 @SergeyBiryukov
2 years ago

  • Milestone changed from Awaiting Review to 6.0.1

#3 @audrasjb
2 years ago

  • Version changed from 6.0 to trunk

It appears on trunk.
Moving for 6.0.1 consideration.

Thanks!

#4 @mukesh27
2 years ago

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

#5 @peterwilsoncc
2 years ago

  • Component changed from Comments to Editor
  • Milestone 6.0.1 deleted
  • Resolution set to reported-upstream
  • Status changed from new to closed

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.

This ticket was mentioned in Slack in #polyglots by nao. View the logs.


2 years ago

This ticket was mentioned in PR #2826 on WordPress/wordpress-develop by c4rl0sbr4v0.


2 years ago
#7

  • Keywords has-patch added; needs-patch removed

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

ockham commented on PR #2826:


2 years ago
#8

Confirming that I see the block title translated:

https://i0.wp.com/user-images.githubusercontent.com/96308/174294642-ba7a6155-df71-4e28-baf2-aa9f5e7ee9ed.png

c4rl0sbr4v0 commented on PR #2826:


2 years ago
#9

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 😄

ockham commented on PR #2826:


2 years ago
#10

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.)

ockham commented on PR #2826:


2 years ago
#11

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).

ockham commented on PR #2826:


2 years ago
#12

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.

ockham commented on PR #2826:


2 years ago
#13

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.

ockham commented on PR #2826:


2 years ago
#14

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 😕

c4rl0sbr4v0 commented on PR #2826:


2 years ago
#15

Closed in favor of #2921

#16 @SergeyBiryukov
2 years ago

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.

#17 @SergeyBiryukov
2 years ago

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.

SergeyBiryukov commented on PR #2826:


2 years ago
#18

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 🙂

Note: See TracTickets for help on using tickets.