Stabilize Time to Read block

[t-hamano]

The Time to Read block was implemented in #43403 and shipped into the Gutenberg plugin in February 2023, but is not yet bundled with the core.

Issues like #13796, #15350 have been reported related to this block, but all issues labeled with this block are closed and there are no open issues. Therefore, I'm hoping this block will be included in WordPress 6.4.

However, this block relies on the new wp_word_count() function to calculate the number of characters on the server side. A patch has been submitted in the core ticket for this new function, but in order to ship this block in the core, I believe this function needs to be implemented in the core first.

[annezazu]

Wanted to flag this feedback from the 6.4 roadmap from @joedolson:

The “time to read” is something I’m not very comfortable including in core. I have some fundamental reservations about this because the idea that there’s a certain amount of time a post should take to read is inherently ableist. It can create a sense of inadequacy in people who struggle with reading by placing a “normal” value to an experience that real people experience in radically different ways.

@scruffian brought up the idea of a Word Count option instead which might be a better path to pursue for Core.

[t-hamano]

The “time to read” is something I’m not very comfortable including in core. I have some fundamental reservations about this because the idea that there’s a certain amount of time a post should take to read is inherently ableist. It can create a sense of inadequacy in people who struggle with reading by placing a “normal” value to an experience that real people experience in radically different ways.

I can understand this point. However, there is also a Time to Read section in the Document Panel of the post editor. This section was added in #41611. This feature is included in Gutenberg 13.7, so this item has existed since WordPress 6.1.

[torounit]

The same is true for the "Word Count" already included in Gutenberg, but the "Word Count Block" does not work for languages that do not separate words with spaces, such as CJKV.

[scruffian]

What about character count? How does time to read cope with CJKV languages?

[t-hamano]

How does time to read cope with CJKV languages?

This block calculates the number of characters or words, taking into account the site language count type (words | characters_excluding_spaces | characters_including_spaces) first, in order to calculate the reading time. It simply divides that number by the "average rate of reading per minute".

If this block were to be changed to one that only outputs the number of characters or words in the content, I think this could be accomplished by simply removing just the division logic.

Alternatively, it might be a good idea to provide the following UI so that the site creator can change to a count type other than that site language, as shown below.

Also, if it is problematic for this block to enforce "normal" standards, we can provide a UI with variable reading rates as follows.

[joedolson]

I can understand this point. However, there is also a Time to Read section in the Document Panel of the post editor. This section was added in #41611. This feature is included in Gutenberg 13.7, so this item has existed since WordPress 6.1.

Having this data available as a point of reference for content authors and editors is profoundly different from having it present for site visitors. I'm not particularly thrilled with it in the editor, either, but in that context it's only directed at people who are actively working on the document, and can be used as a relative metric to assess the length of your working drafts; the value is more abstract in that context, because the audience is not, in fact, reading the document.

[annezazu]

I think we need more time to determine adding this block to Core and let discussion continue further. Going to punt to 6.5 at this point to focus current efforts.

[t-hamano]

Thanks for the detailed explanation, @joedolson!

I would love to hear from @afercia and @alexstine , who have a deep background in accessibility, about their opinions on this discussion 🙏