Latest Comments Block: Trims comment text when site language is set to Chinese

[swoodipto]

Steps to reproduce the behavior

1. Add a new page/post and use the Latest Comment Block
2. Make a test comment in Chinese. You can use this Chinese Lorem Ipsum tool
3. Set site language to zh-cn, zh-hk or zh-tw
4. Check the page/post which has the Latest Comment Block

What I expected to happen	What actually happened
The Block should show the entire comment text:	It shows a trimmed comment when language is set to zh-cn, zh-hk or zh-tw:

Context

Reported by a user: 25882904-hc

Browser / OS version

Vivaldi 3.6.2165.36 (Stable channel) (x86_64) / Mac OS Big Sur 11.0.1

Does this happen on simple or atomic sites or both?

Yes, happens on both.

Is there any console output or error text?

[Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
wpLikes.displayWidget @ s0.wp.com/:3007
ajax @ s0.wp.com/:2206
success @ s0.wp.com/:2968
(anonymous) @ s0.wp.com/:2220
execute @ s0.wp.com/:1511
resolve @ s0.wp.com/:1514
receive @ s0.wp.com/:1658

[Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
wpLikes.displayWidget @ ??/wp-content/js/postmessage.js,/wp-content/js/jed/jed.js,/wp-content/js/wpcom-proxy-request.js,/wp-content/js/likes-rest-nojquery.js?m=20200826:3007
ajax @ ??/wp-content/js/postmessage.js,/wp-content/js/jed/jed.js,/wp-content/js/wpcom-proxy-request.js,/wp-content/js/likes-rest-nojquery.js?m=20200826:2206
success @ ??/wp-content/js/postmessage.js,/wp-content/js/jed/jed.js,/wp-content/js/wpcom-proxy-request.js,/wp-content/js/likes-rest-nojquery.js?m=20200826:2968
(anonymous) @ ??/wp-content/js/postmessage.js,/wp-content/js/jed/jed.js,/wp-content/js/wpcom-proxy-request.js,/wp-content/js/likes-rest-nojquery.js?m=20200826:2220
execute @ ??/wp-content/js/postmessage.js,/wp-content/js/jed/jed.js,/wp-content/js/wpcom-proxy-request.js,/wp-content/js/likes-rest-nojquery.js?m=20200826:1511
resolve @ ??/wp-content/js/postmessage.js,/wp-content/js/jed/jed.js,/wp-content/js/wpcom-proxy-request.js,/wp-content/js/likes-rest-nojquery.js?m=20200826:1514
receive @ ??/wp-content/js/postmessage.js,/wp-content/js/jed/jed.js,/wp-content/js/wpcom-proxy-request.js,/wp-content/js/likes-rest-nojquery.js?m=20200826:1658

Level of impact (Does it block purchases? Does it affect more than just one site?)

Medium

Reproducibility (Consistent, Intermittent) Leave empty for consistent.

Consistent

Screenshot / Video: If applicable, add screenshots to help explain your problem.

Same as above:

[p-jackson]

This is the "Latest Comments" block from core Gutenberg. It's actually working as expected, but perhaps it can be argued that "as expected" is confusing.

The block only shows an excerpt from each comment, as can be seen in the block settings.

The way a excerpt is calculated depends on the language, but in general it's the first 20 words (see get_comment_excerpt()). However each language can set it's own max number (i.e. something other than 20) and some languages count individual characters as words.

Site language set to `en` (see the English comment is truncated after 20 words)	Site language set to `zh-tw` (each character counts as a word)

[p-jackson]

While it's working as expected I thought of a few points

1. To me it seems that each comment should be truncated according to its own language rules. So English comments are truncated by word and Chinese comments are truncated by character. This would require each comment to be stored with its own locale metadata, and that's probably too over the top to ever be implemented in core. But just thought it was mentioning how it could work if we didn't care about complexity.
2. Given the user was surprised by this, perhaps 20 is too short for Chinese? This number can be set on a language-by-language basis. zh-tw is set to 20 (which is the default), but ja has been set to 40. A fluent speaker who understands the nuances of the language could submit a change to this translation to "fix" this in future WordPress releases.
3. There's a bug in the editor where the in-editor preview of the Latest Comments block truncates comments according to the rules of the user's locale, but the front end renders according to the rules of the blog's locale. This difference could have added to the confusion about how this works, and is an editor bug we can fix.

   Block as seen in the editor	Block as seen in the front-end

[p-jackson]

@autumnfjeld I'm taking a look at a fix for (3)

[p-jackson]

Proposed fix for (3) in WordPress/gutenberg#33944

[p-jackson]

Given the user was surprised by this, perhaps 20 is too short for Chinese? This number can be set on a language-by-language basis. zh-tw is set to 20 (which is the default), but ja has been set to 40. A fluent speaker who understands the nuances of the language could submit a change to this translation to "fix" this in future WordPress releases.

@otpidusprime what do you think about leaving this aspect of the issue up to translators. If the current truncation length is set to 20 it presumably means a Chinese speaking person at some point or other has decided that this is an acceptable truncation length. And I'm certainly ill equiped to advocate for this change in the core translations 🙂 Should we leave this as is given it's working as expected, or do you think we should find a way to check whether 20 is good enough?

[p-jackson]

I've merged the fix for the difference between editor preview and frontend WordPress/gutenberg#33944

[autumnfjeld]

@p-jackson This can be moved to Done, ya? Also it looks like the issue/PR aren't automatically linked since PR was in a different repo (at least I think that is what is going on). I've added an explicit reference to this issue in the PR.

[p-jackson]

@autumnfjeld No doesn't look like we can link PRs in different organisations, but I wouldn't have linked these two anyway. The PR fixes one issue, but doesn't solve the original problem that it was unexpected for the text to be truncated, even though it's by design. We could still make a decision that we're not going to address that though.

Also, Kathy set up a system where issues wouldn't close until they were in production. Instead issues that were waiting for a deploy get the [Status] Fix Inbound label. The bug fix won't appear on wpcom until the next version of GB is released and then deployed to wpcom.

[p-jackson]

Fix will ship in Gutenberg 11.4

[p-jackson]

11.4.1 has been deployed to WordPress.com, however the fix doesn't seem to be working. I think it's something to do with the _locale=site param not working on wpcom the same way it does on a stand alone site.

[p-jackson]

Working on fix to wpcom API D66501-code