Community Wishlist Survey 2022/Larger suggestions/Grammar editor

From Meta, a Wikimedia project coordination wiki

Grammar editor

  • Problem: When people make edits, sometimes, they tend to word it wrong or miss some kind of punctuation. That makes it hard to read, people don’t understand.
  • Proposed solution: A built-in grammar editor that corrects edits you make. For example, if I wrote “An win in Week 18 sealed afc east for bils”, it would be corrected to “A win in Week 18 sealed the AFC East for the Bills.”, with an explanation.
  • Who would benefit: People who read Wikipedia, and the editors, they know how to word something next time.
  • More comments: I would like to add my own insight and contribute to this if my idea goes through, really hoping it will. There are lots of edits out there with messed up grammar, and I want to fix it. Thank you for taking this into consideration.
  • Phabricator tickets: T265163
  • Proposer: BubbaDaAmogus (talk) 23:05, 10 January 2022 (UTC)[reply]

Discussion

It's definitely not something that could be done for all projects at once. But at the same time a lot of projects already have similar tools, e.g. AWB replacement rules (82 projects) or Wikificator (14 projects). — putnik 23:31, 10 January 2022 (UTC)[reply]
I doubt it could be done reasonably. Take something like Grammarly, for example, which commonly makes lots of mistakes and something like this would be difficult to make in a very exact manner. MrMeAndMrMeContributions 22:10, 11 January 2022 (UTC)[reply]
In the past, amongst devs, I have seen some that believe that grammar should be done from within the browser and is therefore the responsibility of the user. When considering a service like Grammarly of course one has to consider what happens with our requests and if our writing is being stored on some server after being processed. So it's a really nice idea to consider having a related functionality in the editor that we can trust.
I have been asking around about this within the members of the editing team to find out if anything related exists on their roadmap.
Some things that stood out are that they are two challenges to this:
1. right now we don't have a UI to show suggestions to the user
2. we would need an open source grammar library that would provide these suggestions
The editing team has been thinking about alternative which would be allowing contributors to suggest grammar corrections.
In addition to that there's two ideas that some teams have been discussing that are somewhat related that we would like to share here to discuss and would love your input on the talk pages:
- Growth team’s “copyedit” structured task: this is an idea that would propose copyedits to users one at a time for them to correct, they would be surfaced in a different feed though
- Editing team’s “policy check”: (go to 22 mins) the idea in the video could do implemented for grammar (if the algorithms could be found/made) KSiebert (WMF) (talk) 15:06, 12 January 2022 (UTC)[reply]
This is a great summary of what the Editing Team has been thinking about as it relates to providing people feedback, in real-time, about the edits they are making...thank you for sharing it here, @KSiebert (WMF)!
For those interested in learning more and helping to shape the thinking around "policy check," we invite people to join us in phab:T265163 and/or send me a message on my talk page. PPelberg (WMF) (talk) 02:16, 22 January 2022 (UTC)[reply]
Browsers already have grammar spell checking, and there are tools like grammarly etc that will be much better at this than we can ever be (and they, a company with 800 employees, is already not too good at it). Language is hard. —TheDJ (talkcontribs) 10:49, 12 January 2022 (UTC)[reply]
True, @TheDJ language is so hard and we would like to do things right. KSiebert (WMF) (talk) 15:25, 12 January 2022 (UTC)[reply]
To structure edits, we need to have structured grammars and lexemes in Wikidata, to have structured information to fix errors. Thingofme (talk) 11:55, 13 January 2022 (UTC)[reply]
If implemented please make this optional because it could significantly increase page load time over slow internet. — The preceding unsigned comment was added by C933103 (talk)
  • Since something along these lines is already on the Editing team's radar, there's no need for us to step on toes or invent something different. But I assume by allowing this to go into voting, we could get valuable feedback from the community and the show of support could illustrate how important it is to the community, so I'll move this to our Larger suggestions category. Thanks, MusikAnimal (WMF) (talk) 04:00, 25 January 2022 (UTC)[reply]
    C933103> "If implemented please make this optional ..."
    Yes, a configuration switch to disable is essential. Absence of an unwanted automation is worse than imposition of it.
    Regards, ... PeterEasthope (talk) 00:12, 14 February 2022 (UTC)[reply]

Voting