In T370778#10007273, @Aklapper wrote:

No, it should not. (This ticket also lacks reasoning - please use the feature request template for requesting features. Thanks.)

Merging Wikitech accounts is not technically possible.

Per the note at the top of https://wikitech.wikimedia.org/wiki/SRE/LDAP/Renaming_users, we no longer rename LDAP accounts.

Per the note at the top of https://wikitech.wikimedia.org/wiki/SRE/LDAP/Renaming_users, we no longer rename LDAP accounts.

When I null edit https://en.wikipedia.org/wiki/Draft:Kourage_beatz_nsi, for example, the "There is already an article named Kourage beatz nsi in the mainspace." notice disappears, but then it reappears as soon as I revisit the page.

In T365374#9890676, @Liz wrote:

I'm not getting that message any more but some queries are just running endlessly and never finishing. I had one that ran for more than 3 hours before I finally cancelled it. Does this warrant a new case to be opened?

Bug appears to have been fixed.

@Jidanni How did you find the "Google" option? I don't see any Google option at https://en.wikipedia.org/wiki/Special:Search. Also, which browser are you using?

Now fixed along with T140960.

Instead, the "Open Page Curation" link will disappear altogether following T320922.

I have readded the Regression tag. It turns out that this is in fact a regression after all.

I suspect that the cause for this is the same as the one for T315591. If the cause turns out to be the same for both, then you may create a new task documenting the cause and merge both tasks into there.

I suspect that the cause for this is the same as the one for T316490. If the cause turns out to be the same for both, then you may create a new task documenting the cause and merge both tasks into there.

Mannan Wani (before it was draftified) also did not get added to the queue even though it was undeleted by a non-autopatrolled admin (Jay). The problem occurs regardless of whether the undeleter has autopatrol rights or not.

In T296035#8072781, @Jdforrester-WMF wrote:

In T296035#8072525, @GeoffreyT2000 wrote:

In T296035#8072424, @Jdforrester-WMF wrote:

In T296035#7590148, @GeoffreyT2000 wrote:

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

There has never been a "bug". The behavior prior to the PageUpdater change has always been to increment the edit count by 1 for each move, with no additional increment for the redirect.

That definitely sounds like a bug to me; two entries in RecentChanges but only one edit increment. Clearly, you think otherwise.

Now, with PageUpdater being used to create the redirect, PageUpdater will also increment the edit count for the redirect. The correct behavior is to treat the null edit and the redirect as the same move, not as separate edits, when updating the edit count. So, the original change actually introduced a bug, not fixed one.

Right, so even though you say there's a bug in incrementing by 2 instead of 1, your changes don't fix it, but instead fix a different one, of incrementing by 3 instead of 2?

In T296035#8072424, @Jdforrester-WMF wrote:

In T296035#7590148, @GeoffreyT2000 wrote:

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

Let's make this a blocker for MW 1.39. If the change gets merged in master, then I will backport it to 1.38.

This would require modifying LinksDeletionUpdate.php to no longer have $rcIdsForTitle.

Still not fixed after several months.

Oh, I now see why the change was made. It was made to unofficially fix T297754 (at least on Wikimedia wikis), and now the fix has been officially implemented in MediaWiki.

I have removed the "Regression" tag and updated the description to say that it specifically affects Wikimedia wikis.

Could anyone confirm this on a test installation of MediaWiki 1.38 (as yet unreleased) without the "Linter" extension installed? My guess is that https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/755817 causes this on wikis with the extension installed.

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

Wikipedia's 21st birthday is a month from today (January 15, 2022). Is that what you mean by "Wikipedia Birthday 2022"?

In T291967#7485626, @Pchelolo wrote:

Not on Friday unfortunately. No deployments on Fridays.