With the addition of this item, we'll also want to adjust the spacing for the table-of-contents__count items. Currently, it looks a little weird to have that last "Blocks" item sitting off on its own:

Two options:

1. Widen the modal, remove the existing 25% width rule, and give each items some right-padding instead:

2. Change the 25% width rule to 33.33% instead, to force the 4th and 5th items onto the next line. We'll also want to add a tiny bit of bottom padding to these items. This keeps things compact, but also avoids having just one item all alone:

Option 2 seems like the simplest fix to me.

Hi, @kjellr Thanks for your comments. I think the option two looks better for me. But we may still need to wait for some design feedback.

Just thought I'd also comment that the feedback from @kjellr was the design feedback.

Your PR was discussed during the design triage meeting:
(https://wordpress.slack.com/archives/C02S78ZAL/p1554221572033000 - you may have to sign up to slack to view the discussion).

It seems like you both agree on option 2, so that looks like a good way forward.

Hi @ellatrix, thanks for clarifying this pr further. This pr still does not fix the counting for mixed script post. But it can count the correct number of Chinese words.

I expect to create a new feature to support counting the words in a mixed script post in the future. But at this point, I think it is good to add characters count in the content structure as most editors already provide this. An example is MS Word:

@Jackie6 Thanks, this is looking great!

One final thing: for Latin scripts it might make sense to include both word count and character count, but does it also make sense for e.g. a Chinese translation? Should word count not be removed in that case (perhaps by allowing an empty translation)?

Hi @ellatrix thanks for comments. Do you mean we need to remove the word count when the language is Chinese? I think it will cause the inconsistency of UI. That is sometimes both word count and char count show but sometimes only char count show.

@Jackie6 Yes, the UI will be different, but is word count useful at all in a Chinese translation? If it's not useful, it shouldn't be there?

@ellatrix But apart from Chinese, Korean and Japenese are also character-based rather than word-based. For languages like these, we also need to remove the word count?

Just a random drive-by, but even though we have characters in CJK languages that by themselves are words it doesn't mean that there aren't multi-character words.

Other languages such as early Greek, Linear B, early Egyption also don't use spaces to separate words. Okay, we'll ignore the fact that these earlier languages could be equally written left-to-right, right-to-left, top-to-bottom, bottom-to-top, or changing text direction at intervals to form spirals and other patterns.

Word segmentation is a real problem with an extremely complicated solution. Check out this post from the Solr project talking about ambiguity in Chinese word segmentation - ambiguity that exists because there are multiple valid ways to segment the words in the sentence.

the first segmentation means “I like New Zealand Flowers.” The second segmentation means “I like fresh broccoli”

it's impractical to think that we have the energy and time at the moment to conclusively solve this generally-unsolved problem but we do have some reasonable ways we can move forward in the meantime:

• cut out word counts entirely: a drastic choice that excludes being helpful to a large swath of cases where it otherwise would be
• cut out word counts for any language we think might be troublesome: this is the conservative option to prevent making basic mistakes but may not be super helpful
• add some qualifying notice to the word count when we think it could be wrong, such as when we detect characters from languages that don't us spaces for segmentation or when the ratio of spaces to characters is below a given threshold

my shallow thoughts on the matter are that it'd be more helpful to show the word count with some disclaimer - maybe a popover tooltip explaining that we think it could be wrong - because if we hide it altogether at the first detection of a Chinese character then we'll be degrading the experience without an explanation for not only Chinese posts but also posts that quote Chinese text, even if it's just a small one.

for inclusionary purposes I think it would make more sense to develop some basic heuristics to detect when we think the word count could be wrong; possible indicators based on no research could be:

• word-to-character ratio is out of whack, less than 1:20 (spaces to other characters)
• we encounter a long stream of characters in non-roman letters, we could treat the blob as a whole or split it based on approximate character-per-words estimates

Thanks @dmsnell for you comment.

My (small) problem with this change is that each of these counts can be translated.

So e.g. a Chinese translating might be:

• words => characters_excluding_spaces.
• characters => characters_excluding_spaces.

So you'd just have two counts that are the same thing.

Possible solution:

• Remove word count if __( 'words' ) === __( 'characters' ).
• OR remove word count if __( 'words' ) === 'characters_excluding_spaces' && __( 'characters' ) === 'characters_excluding_spaces', and if __( 'words' ) === 'characters_excluding_spaces', force character count to be characters_including_spaces, or if __( 'words' ) === 'characters_including_spaces', remove character count.

What do you think @dmsnell and @Jackie6?

Another possible solution is to display all three possible counters, and don't translate anything.

Remove word count if __( 'words' ) === __( 'characters' ).

@ellatrix this suggestion is much more favorable in my opinion because it's starting at least with some kind of principle: if the translator says that these are the same then only show one

special-casing specific languages in groups I'm sure will cause more stir and degradation than we intend.

having looked at @wordpress/wordcount it became clear that we're starting from the point of poking-at-holes vs. building a solid ground. that is, making this robustly-solved is a much bigger project than just showing characters and so I think getting character counts out even when word counts will be wrong is a positive step forward

I'm a fan of adding a disclaimer popup but I can see where that could introduce needless confusion - for the time being checking if __( 'words' ) === __( 'characters' ) or whatever form is used here __( 'words', { context: 'label for word-count' } ) is a good tradeoff between getting it perfect and getting it shipped

@ellatrix I am a little confused. Why would __( 'words' ) === __( 'characters' ) ? In Chinese, the translated strings of words and characters would be different. And I guess we cannot control the localization here, right? From my understanding, we just wrap translatable strings in the __() function, and translators will translate the strings.

@Jackie6 If it is different, it would still be displayed. If it's translated the same, one of them is removed. It doesn't make sense to have both counts if they are the same. This may not be the case in Chinese, but maybe it is in another language.

@ellatrix I assume with Remove word count if __( 'words' ) === __( 'characters' ) you meant charCountType === wordCountType? Because __( 'words' ) is totally different from _x( 'words', 'Word count type. Do not translate!' ).

If I'm not mistaken this one can be closed now that #24823 was merged?

@aristath Sort of. #24823 doesn't really fully address #13796, which this PR aimed to do.

I tried to understand what this PR is trying to solve.

The character count is implemented by #24823. I think the rest of what this PR is trying to do is to add an option to control the presence or absence of spaces in the character count.

In word count, we can control the count type by words, characters_excluding_spaces and characters_including_spaces.

In character count, on the logic is fixed on characters_including_spaces.

Is this the right goal for this PR?

Doing some cleanup in the repository. I was wondering if this PR still worth keeping open. Probably needs to be redone entirely if we ever get to it. Let's close it. Please let me know if you think otherwise.