This fell off the sprint entirely. However, the checks I've been working on are absolutely grist for the mill and I've made a couple small updates as I went along.

This got deprioritised last week and our sprint got extended. It's at the top of my list, unless I get reprioritised again.

Monday morning update:

• The initial version is merged and will be on the train. We can see how it works in production on Thursday afternoon
• I need to write an initial configuration for enwiki for Thursday
• We need to internationalise and work out "learn more" links (outside of this ticket) before this can come out of experimental.

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'll unassign as I'm not working on this and it's nto been prioritised

If we do implement this, make sure there's also a ticket to backfill for various TextMatchEditCheck-based checks.

I wrote a patch which uses action.once( "discard" ) to spot when the check is resolved manually – however, it'll also fire if the user deletes a big chunk of text, which doesn't feel like it's quite right.

I think this might be best handled by having Parsoid escape \ to %5C. If you visit the read page with parsoid turned on then [[o\i]] is also rendered incorrectly.

The answer might be browsers.

Testing on a larger article of around 150kb copied from enwiki "Bat" I found:

We have an ignoreQuotes patch inflight, apparently.

I think this is Parsoid. I've clipped out the HTML that ve is building its model from:

The pull-through ticket at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1230406 which updates the VisualEditor extension has been approved, so it should go out on next week's train and should be available everywhere, including enwiki, by Thursday.

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.

I'll have to check back with @ppelberg about whether all he wanted was a raw list, but here's a quick look at what's on the main branch (by configuration name):

I did a quick performance check on a small article, but it's probably worth doing so again on a large article once this has hit production. My dev setup has issues with large articles, if I can't fix that in 15 minutes I'll revisit.

That's merged. Some small attention to detail to do, like making "learn more" point to the right place, but possibly that's unnecessary because we've yet to solve how to do links in the presence of internationalisation.

(transcribing) Next up: A member of editing engineering please populate ticket with a list of all available suggestions, using whichever language we've been using.

It seems like we've discussed the toast option before – it's a bit of a pain with our implementation. I'll discuss highlights. I think it wouldn't be too hard to fire the toast if the user fixes manually: I'll look in to that.

I've pulled the latest version of standalone ve, and it looks like the highlight is correctly respecting dark mode. We'll need to pull through ve core to VisualEditor before this is reflected on mw.

Whew, big day! Initial reviewable version on gerritt.

We'll land an MVP ticket without internationalisation and instrumentation, and add those in a follow up patch before closing this ticket.

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

Most of the way there – I have https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1229118 in progress.

I've got the sketch of the check working – currently it's more like a FirstInternalLinkEditCheck; now it's a matter of getting the algorithm right.

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.

We might benefit from an initial small set of words that we can take to production which won't be too controversial (or difficult to review) while using the full list for feedback.

This week this has been a little backburnered. I'm working on an edit check which hopefully will be the bones (and probably the meat!) of an example for the documentation.

• Test page on patchdemo
• Config on patchdemo

• Raw configuration file on patchdemo
• Test page on patchdemo

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

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

Popping this in the backlog as I'm not likely to get to this in the coming couple of weeks.

No change last week; hoping to take a look this week.

The patch to fix ignoreLeadSection has now landed.

This is blocked on ignoreLeadSection and identifying a word list.

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.

@EAkinloose this change was to AddReferenceEditCheck and I can't see how it could have affected paste check behaviour – could we file this as a separate bug?

I'm having trouble with reproducing the blocked scroll bug.

I think I shouldn't have put these in the inbox, will ask later

I had been working on this in markdown locally, but last week I've turned it into wikitext (a surprisingly frustrating process which wasn't as automatable as it looked) and continued making updates on-wiki instead.

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.

https://www.mediawiki.org/wiki/User:Zoe-WMF/VisualEditor/EditCheckDraft

Update for case sensitivity:

We discussed the merits of this and concluded that this would probably not be a useful heuristic because there are many cases (such as chemical elements) where we would want the en_GB spelling. Avoiding proper nouns (in English, by looking for title cased words) is likely to cover these cases more accurately.