I mocked up a community configuration page where we can configure all the checks we currently have. It's doable - most of the current checks’ configs could remain unchanged and be easily represented in the schema and usable in cc, and TextMatch would need only minor updates to its config. However, this page is probably not what we're looking for right now.

I'm not seeing this consistently. After dismissing a tone check, I'm able to add some content to the paragraph and trigger a TextMatch check without re-activating the tone check. I can also add subjective (but not textmatch-triggering) content to a paragraph where I had previously dismissed a tone check, and in some cases it will re-activate a tone check.

@Ryasmeen , it should be fixed now!

It should be a "minOccurrences" numeric value under the config block, and then must have an "expand" value set as well (likely to "paragraph"), outside of the item's config block. I've updated the documentation to reflect this. Thanks!

Thanks for sharing @Ryasmeen. Let me look into this and get back to you.

I'm glad it helped.

And Russian:

Configs for dewiki:

First pass at configs for enwiki:

In T409484#11352755, @Aklapper wrote:

[Please review project tags/subscribers when creating subtasks - thanks!]

@ppelberg, let me know if you'd rather this be a child of T404220.

QA: I’ve been keeping this doc updated with notes on TextMatch. The Testing/Demoing instructions section might be particularly helpful for you. Please let me know if you have any questions that aren’t covered there.

In T407286#11292113, @DLynch wrote:

Currently we have a method of creating a "tag name" for the rules, but that's just based on their numeric index in the config. This is good for us because it doesn't require the users to work out a unique identifier, but it's also very fragile for persistent references between edit sessions.

A main confusion with this data is going to be that it'll be tied to the state of the on-wiki config at the moment it's logged, so there's going to be some need to manually investigate it to work out what's actually meant by any given log entry and also we won't be able to generalize the meanings between wikis.

Thanks for the helpful context. I'm looking into the replacements now - I agree it's a next logical step. I'll follow up if there are any gaps I come across.

I looked into this a bit. The link works on the Talk page because when those links are rendered in Parser, it tracks each title in a map and adds the _{i} if needed. To make the link work in the edit summary, we would need to see if a similar thing can be tracked in CommentParser/CommentFormatter, where it’s creating the links for each revision in the history page. This might require a not insignificant amount of refactoring that I'm unable to take on right now, but I hope to revisit later.

Here's what I found.

We decided to be consistent with how the Text setting applies to the other source editors (where the textarea does not reflect the setting). Per @DLynch - If we want to change this, we should probably make a new ticket where we decide on what the correct behavior should be, and apply it universally.