Comment Query Loop block not translated.

[peterwilsoncc]

Description

This was originally reported by @c4rl0sbr4v0 as WP#55809.

Comments Query Loop block title is not being translated.

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

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

I (Peter) suspect the data is being pulled from block.json rather than included as a translatable string within the block's JavaScript files.

@mukeshpanchal27 posted a follow-up comment that the description is also not translated so it appears to be a general translation issue with the comment query loop.

Step-by-step reproduction instructions

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.

Screenshots, screen recording, code snippet

Environment info

• WordPress 6.0

Other data was not provided but I suspect it was without the Gutenberg plugin activated as the block has been renamed in trunk.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[cbravobernal]

I will be happy to take a look at it

[peterwilsoncc]

Please note: since opening this issue I've edited it as it appears to be a general translation issue in the comment query loop block.

@c4rl0sbr4v0 Thank you! Please be aware that in the trunk branch the files have moved to the directory packages/block-library/src/comments/.

When it comes time to merging the fix for WP 6.0, the team can manage moving around the files if you wish.

[cbravobernal]

I (Peter) suspect the data is being pulled from block.json rather than included as a translatable string within the block's JavaScript files.

In WordPress trunk, as you mention, without Gutenberg, is taking the data from src/wp-includes/js/dist/block-library.js.

In the Gutenberg repo, if we update the pofile by changing to the new folder, and them compile the mo. The block is translated.

#: wp-includes/blocks/comments-query-loop/block.json
msgctxt "block title"
msgid "Comments Query Loop"

to

#: wp-includes/blocks/comments/block.json
msgctxt "block title"
msgid "Comments"

I'm afraid I am stuck here. I don't know how to address this fix in the code, as there seem to be more variables happening (the JS to PHP translatable string function, I guess), but I don't know if we do more steps during the deployment of a version.

[swissspidy]

cc @ocean90 in case this is related to language packs

[swissspidy]

Block titles and descriptions are usually taken from block.json if available, but that only works for server-side registered blocks.

The core/comment-query-loop isn't server-side registered though, only on the client (it's absent from register_core_block_types_from_metadata()).

Registering it server-side fixes the issue, but there's probably a reason why it wasn't done like this. Plus, the same problem might exist for other blocks as well.

@gziolo Perhaps you have some ideas here?

[gziolo]

It looks like we missed listing comments-query-loop in WordPress core when backporting changes for 6.0:

https://github.com/WordPress/wordpress-develop/blob/6.0/src/wp-includes/blocks/index.php

This is going to be addressed with WordPress/wordpress-develop#2647 in the trunk as a general fix to ensure better code sync, but it looks like we need to include the patch in 6.0.1 with the manual fix. The translation should still get applied to the client, but it might be the case that the translations from block.json don't get merged into the list of translations passed for JS scripts.

[swissspidy]

but it might be the case that the translations from block.json don't get merged into the list of translations passed for JS scripts.

Yep, because we only pass translations from JS files there, not JSON files.

[gziolo]

but it might be the case that the translations from block.json don't get merged into the list of translations passed for JS scripts.

Yep, because we only pass translations from JS files there, not JSON files.

In practice, we bundle the JSON file into the JS file. We might be able to revisit that approach as soon as the proposal for import assertions for JSON becomes the standard in JS: https://github.com/tc39/proposal-import-assertions (stage 3 as of today) and we start using it.

[swissspidy]

In practice, we bundle the JSON file into the JS file.

Right, but during string extraction we can only extract the block name/description from block.json, since there is nothing to extract from the bundled JS file, so once we generate the actual translation files they won't be included there. Hope that makes sense :)

[gziolo]

In practice, we bundle the JSON file into the JS file.

Right, but during string extraction we can only extract the block name/description from block.json, since there is nothing to extract from the bundled JS file, so once we generate the actual translation files they won't be included there. Hope that makes sense :)

Right, now I remember how complex this use case was. I guess a proper server-side registration is the best approach I can think of in the short term 👍🏻

[cbravobernal]

I created a PR on wordpress-develop to fix it.

But there are a few unit tests failing. Does anyone know what could it be?

[SergeyBiryukov]

I believe this was fixed in #2921. Merged in r53631, backported to the 6.0 branch in r53632.