I see absolutely no point to having eq as an alias for =. Other than that, I'm for this.

@alex-mashin That's not really relevant to this bug. That's more what T63432 is asking for.

I don't see this happening, since (most) categorization happens after the part of the preprocess that Scribunto runs in, so you'd end up with paradoxes and the awkward inability to use the feature on the current page.

In T86702#985086, @Nemo_bis wrote:

@Jackmcbarn, I see you deleted the message on some of the affected wikis, do you know how many are left? I see about 120 which created this page, but most of them are old translations in need of deletion.

In T87559#1042766, @Rich_Farmbrough wrote:

I strongly disagree with this. There is no purpose to be served other than vindictiveness in denying locked users the ability to receive email.

Now I understand what you're saying the problem is. You don't want having the autoreview permission to imply having the autoreviewrestore permission. That does seem like a good idea now. Note that if we do go this route, I don't see a reason that review or rollback should imply that permission either. (If we want enwiki reviewers and rollbackers to have that ability, we can add autoreviewrestore to those groups.)

This is an issue with the on-wiki template code, not with the software.

I think that you'd quickly end up with very unwieldy templates if this functionality were usable directly from wikitext. Note that either https://gerrit.wikimedia.org/r/#/c/141052/ or https://gerrit.wikimedia.org/r/#/c/169983/ would allow you do to do what you want from Scribunto in a cleaner and easier to understand way.

That's completely unrelated.

I disagree that we should do this. Lua errors should be handled by pcall() and not be allowed to escape back to wikitext at all.

This was an issue with on-wiki templates and modules, not a software issue (though it is fixed now).

It looks like the fix for T47412, I7e8109ea, fixes this as well. It's already fixed on group0, and it arrives at group1 and group2 next week.

I note that the user ID solution will cause edit summaries to be completely wrong if a revert revision is imported to another wiki (since the same ID will refer to a different user).

In T87396#990828, @TTO wrote:

No longer requires manual DB manipulation, as the article was deleted. It would still be nice to make sure nothing else has gotten moved into Topic space though.

In T87396#990540, @Krenair wrote:

@TTO: You added the shell project. What is there for us to do here exactly?

This seems to be another doBlockLevels bug.

In T86598#972497, @Metronomo wrote:

Ok, now I can see why it behaves as external link, but still sometimes is broken and is no internal or external ...

As far as I'm concerned, this is working correctly. Currently, if a link looks like it could be valid as either an internal or external link, the external link wins. This has been the case for a long time, and a lot of stuff could break if we change it.

I don't think extensions should be editing pages, especially in cases like this one where the edits being made depend heavily or entirely on parts of the page's old content. I think we'd be better off with a rewrite of the bot.

I don't think a fourth gender option should be added. I prefer Withoutaname's solution of combining "other/none/prefer not to say" all into the same option (since they all require gender-neutral pronouns anyway).

This isn't limited to null revisions. The following sequence will also trigger the bug:

• Vandal1 vandalizes a page
• Vandal2 vandalizes the same page
• Patroller1 reverts Vandal2's edits but doesn't notice Vandal1's edits
• Patroller2 later uses Twinkle's "Restore this version" link to go back to the revision before Vandal1 edited
• Patroller1 gets a notification that Patroller2 reverted their edit

The fix will be live on all WMF wikis on January 14th.

The fix will be live on all WMF wikis on January 14th.

Uh, it's closed.

This is actually the same problem as T7278, although it's a totally unrelated symptom. https://gerrit.wikimedia.org/r/#/c/137153/ will fix both.

This would still be a major breaking change to a lot of wikitext, which would need a really good reason and a discussion (maybe even an RfC) first.

You escaped the result, not the nowiki'd source.