Incorporate simple Plain Language checker for content

Thanks @GreenSkunk I do think that this could be quite useful to show to authors. There are these PHP based tools like https://github.com/DaveChild/Text-Statistics which the Content Readability module uses but also worth noting that this could be delivered through JS too.

https://github.com/yichiang/plain-language-checker
https://github.com/duereg/too-wordy
https://github.com/retextjs/retext-readability
https://github.com/clearnote01/readability
https://github.com/btford/passive-voice/tree/master

One challenge for Drupal with this is that most of these are really focused on English specifically or at least European languages.

@quietone I moved this back to Drupal core as it really should be something we look at for CKEditor 5. Really don't see any interest in developing anything new on CKEditor 4.

One challenge for Drupal with this is that most of these are really focused on English specifically or at least European languages.

This is where my mind went, immediately. 😅

I'm not sure if this would ever make sense in Drupal core for that reason. I think this would make for a superb contributed module though, and once that is mature enough, we could consider moving it into Drupal core, once it also has facilities to allow additional modules to add support for more languages 😊

Also, technically speaking, this does not need to be coupled to CKEditor 5 at all. Why not support it for all text fields? And provide a status report entry for it? That'd show you which content is in strongest need of simplification, and would allow updated rules to be checked across the entire site instead of just for the content you're editing.

Since this is not yet in the ckeditor5.module component, moving it to the text.module component — let's see where this goes! 🤓

Just thoughts on why I don't think this is practical in core. This would make an awesome module. I looked at this with hemingway and ckeditor 4 and i concluded there were few UI patterns that could be followed:

1) Target the current input box with an a regularly updating value in (say) the settings tray.
2) Show a summary on a preview page - whereby you could optionally force the user to show a preview.
3) If someone was approving a new version they would see the readability score during that process before publishing.

From a practical point of view of an "approver" role, you might want your readability assessment to target a rendered area which it might include mutiple entities, formats and text fields. There might be multiple rendered areas on the page/entity you want to differentiate from a readability POV. So then are you incorporating such a module at the display settings level off arbitrary entities - you've now drifted further away from wysiwyg and text areas.

Reading the issue summary I think this is a discussion is to have with the product managers. I checked on committer slack if I was on the right track and larowlan agreed. Therefor, I am moving this to the Core ideas project.

It's an interesting idea for sites that have blog posts or something, but it wouldn't make sense for every site or every content type.

I also think it makes more sense as a contrib module first to gauge interested level. The plan for Drupal 11 has the goal of creating a smaller Drupal Core via "The Great Module Migration", so we don't want to add a bunch of things to Core again in opposition to this goal if it won't be used by many sites.