We've also now implemented useTemplate, which is an alternative approach we're using for T413420. Either template or category could be useful, depending on the particular circumstances.

The current mapping was derived as follows:

We should decide whether or not the issues mentioned amount to a showstopper.

Note that wgCategories is populated at load time, so won't reflect changes during the edit session. On the other hand, it does include categories that implicitly apply to the page via a template.

The mwCategory group doesn't contain hidden categories, whereas I think for this usage we do want them.

In T411285#11416705, @Esanders wrote:

I think these optimisations aren't even necessary if we switch to a concatenated regex, as that runs in 20ms on a massive article.

The above refactor introduces SetTextFinder, which avoids having to rebuild normalizedQuery on every single call to ve.dm.Document#findText. It also introduces MemoizedTextFinder, which avoids rechecking the same runs of text on each document update, making it faster even than the RegExp method. Here are some rough timings on a 90k article:

Hmm I think building normalizedQuery is the slow part of ve.dm.Document#findText. On a 90k article, I'm seeing a 5000-element Set search with caseSensitiveString: true being twice as fast as caseSensitiveString: false.

We discussed this in the dev sync, and looked at how to clone with an empty internal list, which solves the issue.

We folded these improvements into TextMatchEditCheck in T398478 .

The alternative technique we decided on (subclassing) is sufficient for current needs, so this is no longer needed right now.

Following discussion, we decided the final implementation should use a different technique (subclassing).

The above patch set tests lazy rendering the CE branch corresponding to each UnrenderedNode. It doesn't attach it to the CE tree (and nor, therefore, the DOM). It shows a count of rendered UnrenderedNodes as the save button caption.

Yes, here are some differences. In all the use cases we can think of, TextMatch:

1. finds an exact word or phrase,
2. regardless of context,
3. optionally offering one or more replacements;

Based on our discussions, it seems like minOccurrences, and expand=paragraph generally, open up a world of new use cases that seem distinct from plain old text matching.

As an aside, it's interesting what a large difference page complexity can make, for a given byte size. And it's not just tables. Of articles around the 99th centile point (82 kB), Parabola is particularly slow, presumably due to all the inline mathematics templates plus the images.

I would prioritize the ideas above as follows:

Possible optimization: Use IndexedDB to ensure VE code is cached

These benchmark timings suggest that >3 second waits should be rare on typical articles when internet connectivity is good. So any optimizations should be targeted at either large articles or slow internet connectivity. One optimization that would help with both scenarios is:

Testing on a basic device (Samsung Galaxy A13 5G) on Wifi, an average article took under 2 seconds to load:

Here's an example with voice input running well over 100 characters in a single "paste". I think for a mobile user writing a paragraph from scratch, that would be pretty feasible.

Unfortunately composition events are not at all consistent across IMEs (some don't even issue them at all). I think it would be better to go with a higher limit, like say 250 chars. Coincidentally that would also help to exclude other things that are likely to be reasonable short pastes, e.g. the official long name of an institution, where copyright law / Wikipedia policy is unlikely to be relevant.

Hmm this is an intriguing idea. However there are some IMEs that "paste" a sentence at once. Below is an example with a Chinese text input method. Many voice input methods do this too I think. Therefore the thresholds would need to be high.

Some further points here following our team discussion:

I cannot reproduce the behaviour exactly as described in Step 3:

Thanks @cscott. Documenting what you pointed out in our engineering discussion: mwparserfromhtml is built on Parsoid, so its plaintext rendering should in principle be closer to something we can replicate in VE based on the Parsoid HTML input we load.

As mentioned in face-to-face discussions, a use case Growth is considering is where ranges are identified in the article's content directly, obtained via REST (without loading it into VisualEditor). It is likely that mapping such ranges to ranges in a VisualEditor session would require some sort of heuristic element (e.g. matching runs of plaintext) which means the accuracy would not be 100% (e.g. due to inline templates). The optimal heuristic parameters would depend on the use cases we hope to support.

On review, I think there is enough here for now. The UI is a little underdocumented, but it contains less that is unique to VisualEditor than either the DM or CE do.

Alternatively, investigate transaction isolation levels

Per discussion, we're reinstating the Learn More links, but pointing to metawiki:NPOV .

Resolved by the merge of https://gerrit.wikimedia.org/r/1149663 .

To avoid accumulating techdebt on this, @zoe and I refactored the Edit Check architecture to always treat checks as asynchronous. For technical details, see comments under https://gerrit.wikimedia.org/r/1149663 .

In T390248#10920661, @ppelberg wrote:

Update

I've updated the copy in the task description to align with what @SSalgaonkar-WMF, @dchan, and I discussed offline.

These changes are in service of making it clear to the people who will be encountering Tone Check to know where/what this feedback message is coming from.

Final estimate was a peak load of 2.6 requests per second, and a mean load of 0.7 requests per second, if Edit Check were running on all Wikipedias for users who've completed <100 edits.

Reviewed by me

Done by me

Done by me

Reviewed by me