The exceptions listed in MOS:ENGVAR include quotations, titles of works, and proper names. For quotations, we probably want to apply the same logic to skip them as we're doing for Tone Check. For titles of works, maybe skip anything in italics. And for proper names, maybe skip anything capitalized.

This was doable with TextMatchEditCheck. The words list is by no means great (it didn't have color/colour on it when I got it...), but it works!

Patchdemo here
Configuration file here

Oh, and I forgot to do this earlier… screenshot!

Configuration file as it stands at the moment (as the patchdemo will go away at some point):

For quotations, we probably want to apply the same logic to skip them as we're doing for Tone Check.

There's no edit-check logic for that currently. The model might possibly cope with it, but that's a black-box.

Update for case sensitivity:

To update in more depth:

• Internally we tried out the check and found that proper nouns were often suggested for changes.
• We've chosen to resolve this by turning on case sensitivity, since in English proper nouns tend to be capitalised
• We also considered whether links to other pages should be matched on the theory that they would tend to be proper nouns, see T414191: Add link filter to TextMatchEditCheck?. A counterexample was identified in chemical elements, and the fact that wikis might use a mix of redirects and link titles to handle the matter. While it might be a useful tool for other checks, we concluded that it's a less useful heuristic than capitalisation for this check.

We also identified that since this check is a pure-configuration change there's not really a clear deployment process. A code change would go through gerrit and the review process, whereas this would be deployed using manual changes to the configuration file on enwiki. We're therefore going to use this as a trial run for the process in T413257: [Meta] Define the deployment path for new Edit Checks/Suggestions.

We discussed that lead sections were likely to have text such as "Colour (or color in American English)" and that we should ignore the lead section as a rough heuristic to prevent this issue.

I've set ignoreLeadSection on the match config field on the patchdemo, but I found that the change was not reflected. I'm filing a ticket to explore why.

This is blocked on ignoreLeadSection and identifying a word list.

The patch to fix ignoreLeadSection has now landed.

Next action:

• Create a new patchdemo and copy over config and test page
• Make sure patchdemo link and current config are in the task description as well as in comments

In using another page for the patchdemo I discovered that there's other templates which redirect to "Use British English", in this case "EngvarB".

The following templates link to Template:Use British English:

Template:EngvarB
Template:EB
Template:Eb
Template:Use Scottish English
Template:En-GB
Template:Use European English
Template:Use International English
Template:Use british english
Template:Use British
Template:Use british
Template:Ube
Template:UBE
Template:Engvarb
Template:Use BrE
Template:Use Welsh English
Template:Engvar-B
Template:Use British English spelling
Template:International English
Template:Engvar B
Template:Uken
Template:UKEN
Template:Use British English with -ise spellings
Template:Use British english
Template:Use British spelling

• API query
• Extraction script: cat redirects.json | jq -r '.query.pages | first | .redirects | .[] | .title'
• Special page: https://en.wikipedia.org/wiki/Special:WhatLinksHere?target=Template%3AUse+British+English&namespace=&hidetrans=1&hidelinks=1&limit=50

• Get these templates into the config

I should have written my script with editing the config easily in mind.

cat redirects.json | jq '.query.pages | first | .redirects | map(.title[9:])'

[
  "EngvarB",
  "EB",
  "Eb",
  "Use Scottish English",
  "En-GB",
  "Use European English",
  "Use International English",
  "Use british english",
  "Use British",
  "Use british",
  "Ube",
  "UBE",
  "Engvarb",
  "Use BrE",
  "Use Welsh English",
  "Engvar-B",
  "Use British English spelling",
  "International English",
  "Engvar B",
  "Uken",
  "UKEN",
  "Use British English with -ise spellings",
  "Use British english",
  "Use British spelling"
]

Change #1228501 had a related patch set uploaded (by Zoe; author: Zoe):

[mediawiki/extensions/VisualEditor@master] TextMatchEditCheck: bugfix on ignoreLeadSection

https://gerrit.wikimedia.org/r/1228501

• Raw configuration file on patchdemo
• Test page on patchdemo

I've found a bug where ignoreLeadSection is still not covered. I think I've fixed it, regenerating a patchdemo...

Test wiki created on Patch demo by Zoe-WMF using patch(es) linked to this task:
https://dc375f81da.catalyst.wmcloud.org/wiki/The Colour of Magic

• Test page on patchdemo
• Config on patchdemo

Change #1228501 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] TextMatchEditCheck: bugfix on ignoreLeadSection

https://gerrit.wikimedia.org/r/1228501

@zoe, if the above list of redirects is hard-coded, does that mean that, if future redirects are created to the British English template, articles tagged with those redirects would not cause the suggestion to activate? That's not optimal, but if it's what we want for the MVP we should probably add a note to the template documentation that, if new redirects are created, they should also do something to ensure this stays in sync.

Good catch, that's right. We could also consider writing a script capable of checking it for us. Probably easily scripted in bash assuming the user has jq installed, or python with native libraries.

PM & engineering are happy to deploy this in experimental mode (ie disabled by default), preferring velocity over perfection.

We'll discuss with community liaison in case there's blockers, and on whether to go with a smaller word list.

The ignoreLeadSection fix landed on Monday, so it should now be fixed in production. This means we can go ahead with production configuration on a technical level; I'll check in on the word list.

Block on ignoreQuotes being available and add ignoreQuotes to the config

ignoreQuotedContent (via patch + patch) merged on the 21st, so it'll be on the deployment train next week, and available on enwiki on the 29th.

It specifically tests whether the start of the range you're considering is within quotes (or is an opening-quote, which isn't technically within, but...), which we might need to expand for other cases, but for this textmatch rule in particular should be Just Fine.

Monday morning update:

• We're waiting on the train for ignoreQuotes and ignoreLeadSection, so this can't go anywhere until Thursday afternoon.
• Still deciding about initial word list, as this will be in front of interested volunteers
• I think the current config is out of sync with the ticket in terms of text, so I'll be checking that

I've shared the new copy proposed for this new suggestion in T415849: Define Edit Suggestion card copy for en.wiki Beta Feature release.

I updated the last version of the config to include ignoreQuotedContent

I've put this up on enwiki via:

• Creating a new MediaWiki:Editcheck-config-textmatch-british-english.json page in https://en.wikipedia.org/w/index.php?diff=1336439688
• Using the new import feature to include it in MediaWiki:Editcheck-config.json in https://en.wikipedia.org/w/index.php?diff=1336439790