Related: There is a spellchecker API at https://spell.toolforge.org/ supporting 90 languages

One aspect to consider is whether the communities will be able to adjust the rules used for "spelling, grammar, punctuation, tone, etc." When theLanguage team explored this space, one interesting aspect of projects such as LanguageTool was the possibility for the communities to define rules to adjust them to their policies (e.g., support for multiple variants of a language, discouraging certain non-neutral expressions or suggesting certain words for consistency, etc.).
The integration of this kind of systems is very relevant for the Language team, since it is a common need surfacing in recent research ("Provide more tools related to translation, such as dictionaries and spell check."). In this case, for surfacing issues to the user before publishing (which seems related to the editor guidance described in T265163: Create a system to encode best practices into editing experiences)

Also these types of tools tend to rely on a custom dictionary (when you use a word it doesn't recognize, you can add it to the dictionary so you don't get warned about it every single time) - would we need something like that? Would it be per-user? Per-page? Where would it be stored and how would it be exposed to moderation / anti-abuse workflows?

Relatedly, if someone rejects a spellcheck issue, ideally that would be stored somewhere - when the page is edited, and someone runs another spellcheck, we don't want them to go through all the issues that have already been resolved previously (although I guess whether this matters depends on the rate of false positives). Again, how would that be stored? (MCR?) How would it survive edits?

It seems like we would need some kind of community configuration for spellcheck per language wiki. We could do some research to see what size limitations we'd have by placing it all in a single, per-wiki MediaWiki namespace JSON page; that would have the advantage of giving us a lot of things for free in terms of moderation and oversight.

In T307882#8363229, @DAbad wrote:

• From Growth team: "The high level summary is: we want to provide suggestions to users about "copy edit" fixes they can make to articles. The suggestions will come from a LanguageTool application instance, and those suggestions will be further filtered by a Python application that is responsible for proxying requests to/from LanguageTool (some updates / more reading here https://phabricator.wikimedia.org/T315086). Given that architecture, we would have two services (LanguageTool, and Copyedit) in Wikimedia's Kubernetes cluster."

The Language team would be also very interested in using the LanguageTool service. I'm sharing some usecases that are relevant for us in case they help the service to support a broader set of needs (or be architected in a way that is easier to support them in the future):

Content/Section translation could use the LanguageTool service to surface issues in the translations at different times: (a) while users edit them (e.g., showing issues after completing a paragraph or sentence), (b) in the process of publishing (e.g., prompting users to review if there are major issue detected) and/or (c) after publishing (i.e., recommending to improve the article by correcting the detected issues).

The types of issues could range from (a) spellchecking mistakes the user made, (b) grammar issues resulting in unnatural sentence formation based on light modifications of machine translation, or (c) word choice preferences by the community (i.e., to encourage consistency in the way certain terms are translated).

Next Steps:

• @lbowmaker will run point on this request to dig deeper with the team on potential architecture support needs and draft for recommendation on path forward

@lbowmaker quick heads up, I'm working on some diagrams and documentation recap in T321020: Research Spike: Copy Edit, I'll share it and ping you back asap.