As a regex novice, I would love to be able to test filters against a huge sample of known good edits, to keep false positives under control. IME when a good-faith newbie hits a filter, they normally leave forever.

@Umherirrender, thank you for that idea. It genuinely seems like it should work, but it doesn't. In fact, no options rendered at all until I made the same change to <choose>, which restored rendering but didn't affect the original issue.

How embarrassing. Yes, it is the RandomSelection extension. Sorry about that -- somehow I remembered it as a non-standard but widely supported HTML tag.

Uh... that was meant sincerely. I have had submissions declined instantly in other organizations for skipping a single sub-bullet in the instructions. Point taken however; it won't happen again.

Sorry, I thought that was obvious from the tags. You get a cupcake for not simply closing it as malformed.

Added tags, d'oh.

I don't remember. It happened right after an upgrade and we didn't document everything because we were fighting fires. It might have been MediaWiki 1.24.

@Aklapper I'm not the OP but this appears to be a duplicate of T53110.

Attaching more realistic screenshots (searching for a term that returns many results, and redirects are clutter). The core search example is from this URL, on a project with:

This is a duplicate of T4679.

For 1.28, it went like this:

Hello, I think the above comments conflate two issues.

Usability bonus: the countdown's max value could account for autogenerated text which will be prepended or appended during save (e.g. manual undo, tagging, section title).