Change 709768 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/Disambiguator@master] Add change tag to edits that introduce disambig links

https://gerrit.wikimedia.org/r/709768

This appears to duplicate what User:DPL bot has been doing in enwiki since 2011.

@Narky_Blert there might be some confusion here over what a 'tag' is: this task is to add a revision/change tag to each edit that introduces a new disambig link to a page. The existing system on English Wikipedia of adding the {{dablinks}} template is also colloquially called 'tagging', but it's not the same thing. There's room, I think, for both systems: the template is added when there are a bunch of disambig links on a page, but the revision tag is added when there's even one, and it can be used for filtering in Recent Changes and Watchlists.

@Samwilson - dablinks is only added if (I Ithink) there are 7+ links in an article. User:DPL bot sends 'nastygrams' to registered users who add even one DABlink (see e.g. [https://en.wikipedia.org/w/index.php?title=User_talk:Narky_Blert&diff=1035020962&oldid=1034126318 for one of my mistakes]) It doesn't bother with IPs, because they don't know what talk pages are. The list of all current DABlinks is maintained in [https://dplbot.toolforge.org/disambig_links.php?limit=500 Disambiguation Pages with Links], updated twice-daily.

Regardless, it seems DPL bot is only for English Wikipedia, when nearly all content wikis have the same problem, so the revision tag will hopefully be of use to them.

The other motivation here is for metrics. We want to know how many dablinks are added and with which editors, user experience levels, etc. The revision tag will make it possible to answer these questions.

I'd say very likely all, rather than nearly all. Most of my edits outside enwiki (32 languages) have been error-fixing. (I hardly ever look outside home languages; links elsewhere might be guesswork, and will need confirmation.) If this benefits any non-English WP - excellent, the effect won't be limited to there.

Metrics should be interesting; I might be able to comment on them. In my experience on enwiki - this is purely anecdotal - DABlinks can be added by anyone between single-post IPs, and 10-year users and admins; or even a DABfixer in the 100,000 club who should have known better.... One thing to look for will be outliers - editors who add multiple DABlinks, especially if they do so repeatedly.

Change 709768 merged by jenkins-bot:

[mediawiki/extensions/Disambiguator@master] Add change tag to edits that introduce disambig links

https://gerrit.wikimedia.org/r/709768

QA notes: This hopefully should be easy to test. When you edit a page and add a link to one of the pages listed at Special:DisambiguationPages, it should have a tag next to it in the revision history that reads "Disambiguation links".

In T287549#7274569, @MusikAnimal wrote:

QA notes: This hopefully should be easy to test. When you edit a page and add a link to one of the pages listed at Special:DisambiguationPages, it should have a tag next to it in the revision history that reads "Disambiguation links".

@MusikAnimal I have added links to a couple of different disambiguation pages on beta (as different users) but so far they have not been tagged:

• https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Libris_(disambiguation)&action=history
• https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Page&action=history

Special:Tags reports no use of the disambiguator-link-added tag.

@MusikAnimal It looks like dom_walden found the problem and was able to successfully test that the feature adds the tags, e.g. https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Conflict-title-0.08982248967603867-I%C3%B1t%C3%ABrn%C3%A2ti%C3%B4n%C3%A0liz%C3%A6ti%C3%B8n&action=history

And the count of "tagged-changes" is correctly incrementing at https://en.wikipedia.beta.wmflabs.org/wiki/Special:Tags - currently showing as "9 changes"

But I noticed that when I click "9 changes" in that second link, there are no results: https://en.wikipedia.beta.wmflabs.org/w/index.php?tagfilter=disambiguator-link-added&limit=50&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2

Is that a bug? (Note: It works as expected for other tags, such as mobile-edit)

In T287549#7280117, @Quiddity wrote:

But I noticed that when I click "9 changes" in that second link, there are no results: https://en.wikipedia.beta.wmflabs.org/w/index.php?tagfilter=disambiguator-link-added&limit=50&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2

Is that a bug? (Note: It works as expected for other tags, such as mobile-edit)

Yeah, I am observing this issue on my local too (though oddly I recall it working before). I will look into this Sunday with intentions of getting a fix out before the train departs Tuesday. Thanks for flagging this issue!

In T287549#7282429, @MusikAnimal wrote:

In T287549#7280117, @Quiddity wrote:

But I noticed that when I click "9 changes" in that second link, there are no results: https://en.wikipedia.beta.wmflabs.org/w/index.php?tagfilter=disambiguator-link-added&limit=50&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2

Is that a bug? (Note: It works as expected for other tags, such as mobile-edit)

Yeah, I am observing this issue on my local too (though oddly I recall it working before). I will look into this Sunday with intentions of getting a fix out before the train departs Tuesday. Thanks for flagging this issue!

Looking into this further, I believe the issue is that the LinksUpdateComplete hook can be called before a row is added to the recentchanges table. We use ChangeTags::updateTags() to add the actual tag, and it attempts to look up the recent changes ID automatically (based on the revision ID we give it). In my debugging, the query to fetch the rc_id is null and hence no association is made between the recent changes entry and the tag. It's possible this won't be a problem in production, but I can't be certain of that.

I'm not sure how to get around this. We need to use the LinksUpdateComplete hook because we need access to the LinksUpdate instance to get the links that were added in the edit. RecentChange_save is an appropriate hook to ensure the recent change entry has been persisted. So it would seem we need to sort of use both hooks to ensure we have the data we need and that the timing is correct. I don't think this is possible :/

I think it's still worthwhile to tag the revisions, since that is of use to us in measuring the efficacy of other things we do for the disambig wish. However it is misleading to have the tag listed at Special:RecentChanges, so maybe we should hide it from view for the time being. We can do this by changing the interface message of the tag to a hyphen-minus -.

In T287549#7286274, @MusikAnimal wrote:

I'm not sure how to get around this. We need to use the LinksUpdateComplete hook because we need access to the LinksUpdate instance to get the links that were added in the edit. RecentChange_save is an appropriate hook to ensure the recent change entry has been persisted. So it would seem we need to sort of use both hooks to ensure we have the data we need and that the timing is correct. I don't think this is possible :/

Not sure if it's helpful (or whether there's a better way to do that), but AbuseFilter uses this approach for the "tag" action. Essentially, while filtering the action it stores a list of tags keyed by page details, and retrieves it later in onRecentChange_save. See ChangeTagger for an overview of how it works. I think I once opened a task to improve this situation in core, but cannot find it at this time.

Change 713319 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/Disambiguator@master] Hide disambiguator-link-added tag temporarily

https://gerrit.wikimedia.org/r/713319

Change 713319 merged by jenkins-bot:

[mediawiki/extensions/Disambiguator@master] Hide disambiguator-link-added tag temporarily

https://gerrit.wikimedia.org/r/713319

Change 713367 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/Disambiguator@master] Apply the disambiguator-link-added in onRecentChange_save

https://gerrit.wikimedia.org/r/713367

Change 713367 merged by jenkins-bot:

[mediawiki/extensions/Disambiguator@master] Apply the disambiguator-link-added tag in onRecentChange_save

https://gerrit.wikimedia.org/r/713367

Change 713357 had a related patch set uploaded (by MusikAnimal; author: Daimona Eaytoy):

[mediawiki/extensions/Disambiguator@wmf/1.37.0-wmf.19] Apply the disambiguator-link-added tag in onRecentChange_save

https://gerrit.wikimedia.org/r/713357

Change 713357 merged by jenkins-bot:

[mediawiki/extensions/Disambiguator@wmf/1.37.0-wmf.19] Apply the disambiguator-link-added tag in onRecentChange_save

https://gerrit.wikimedia.org/r/713357

I've changed my mind. I can see this being potentially very useful. In [https://en.wikipedia.org/w/index.php?title=Iota_Phi_Theta&action=history this simple case] from today, I reverted a repeatedly-edited vanity post, and "Disambiguation links" made the relevant edits stand out. In other cases, where a DABlink-adding edit has been buried under more recent ones, this could make it more easy to identify. (I haven't yet looked outside enwiki.)