Page MenuHomePhabricator

Entity usage for mw.wikibase.entity:getSitelink()
Open, Needs TriagePublicBUG REPORT

Description

As an editor I want to only be notified about relevant Wikidata changes in my watchlist in order to monitor only changes that have an effect on my article.

Problem:
We have 2 ways to get the sitelinks for an Item via Lua. They are:

  • entity:getSitelink( )
  • mw.wikibase.getSitelink( qid )

They lead to different usage aspects being tracked. The first one adds the Sitelink aspect and the second one sets the Title aspect. This is not correct. They should both be adding the Title aspect instead.

This is a problem because it leads to useless Wikidata change notifications in the client watchlists. This means editors are less likely to keep the Wikidata changes showing up in their client watchlist and thereby miss important changes that are actually relevant to their article.

Example:
See original report below

BDD
GIVEN a Lua call using the entity:getSitelink( ) function in an article
WHEN checking the usage aspects for that article/Item
THEN the Item providing the sitelink should be tracked with the Title aspect
AND

Acceptance criteria:

  • entity:getSitelink( ) no longer tracks the usage in the Sitelink aspect but instead in the Title aspect.

Original report:

Test LUA module:

local p = {}

function p.award(frame)
	local qid = 'Q534981'
	local entity = mw.wikibase.getEntity ( qid );
	if entity then
--		return '[[' .. entity:getSitelink( ) .. ']]'
		return '[[' .. mw.wikibase.getSitelink( qid ) .. ']]'
	end
end

return p

When I'm using it via {{#invoke}} on some page, under Wikidata entities used in this page I'm getting Medal "Veteran of Labour": Title which is correct, since I'm requesting "home" sitelink only

When I'm commenting mw.wikibase.getSitelink line and uncommenting entity:getSitelink line, I'm getting exactly the same result on the page, but under Wikidata entities used in this page I can see Medal "Veteran of Labour": Sitelink which is incorrect. It leads to the pollution of Watchlist with interwiki addition/removal for connected entities.

Event Timeline

Apparently implementation of wikibase.getSitelink() in client/includes/DataAccess/Scribunto/mw.wikibase.lua is utilizing trackUsageForTitleOrSitelink() in client/includes/DataAccess/Scribunto/WikibaseLanguageIndependentLuaBindings.php
Implementation of methodtable.getSitelink() in client/includes/DataAccess/Scribunto/mw.wikibase.entity.lua is much more brutal, it just fires addSiteLinksUsage on any access to sitelinks table

It looks very strange that 2 implementations of getSitelink() functions that are supposed to work identically based on 2 completely different pieces of code. If they are not going to be merged somehow, I believe the easiest way to fix this would be to expose addTitleOrSitelinksUsage() for lua and use it instead of php.addSiteLinksUsage Technically maskEntityTable() always passes both entityId and key (globalSiteId here) to usageFunc(), it just addSiteLinksUsage happens to ignore second parameter

Note: This came up in the last office hour again.

Change #1067368 had a related patch set uploaded (by Joely Rooke WMDE; author: Joely Rooke WMDE):

[mediawiki/extensions/Wikibase@master] Fix sitelink entity usage tracking

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

Change #1067368 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Fix sitelink entity usage tracking

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

Hi @Ghuron, this ticket will hopefully soon be resolved!

Before it is, I wondered if you had any visual examples of what the bug looked like or how we could replicate it to show what the Watchlist noise from useless Wikidata change notifications looked like?

At ru-wiki we implemented a workaround in 2021, so this bug is not very easy to reproduce here. I would simply make a test module with the LUA code snippet I provided in the original report, paste it into the {{#invoke}} draft, and use "Show preview" in "Wikidata entities used in this page" to see what exactly is being used for each variant.

This will make a massive reduction in size of wbc_entity_usage and recentchanges tables. I will keep an eye for the numbers. Thank you!

Has this already been deployed? The project added by ReleaseTaggerBot, the roadmap and the Tech News suggests so, but my watchlist is still full of irrelevant changes.

Has this already been deployed? The project added by ReleaseTaggerBot, the roadmap and the Tech News suggests so, but my watchlist is still full of irrelevant changes.

@Ainali, thanks for getting in touch. Could you please send us a screenshot and a little description of the irrelevant changes you're seeing? Thanks a lot!

Sure! Here are a few from my watchlist on Swedish Wikipedia. (Unrelated weirdness, why is the Wikidata edit summary not in English when I set the rest of my interface to that?)

Skärmbild från 2024-09-12 17-33-57.png (142×1 px, 91 KB)

It will take a while for the reparses to take effect and update entries in wbc_entity_usage and so on. At least a month.

Change #1083819 had a related patch set uploaded (by Joely Rooke WMDE; author: Joely Rooke WMDE):

[mediawiki/extensions/Wikibase@master] Prevent getAllStatements from returning mutable entity statements

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

JoelyRooke-WMDE subscribed.

Patch set for Change #1083819 was mistakenly assigned to this ticket - please disregard

@Ainali as nearly 2 months have passed, have you noticed any difference or improvement to your Watchlist entries?

@Danny_Benjafield_WMDE Not really, here's a screenshot from just now in my watchlist on svwiki.

Skärmbild från 2024-11-08 18-32-48.png (481×1 px, 309 KB)

That looks like a different problem. Alias in pnb shouldn't be really subscribed in Swedish Wikipedia. Something has been incorrectly in lua.

Looking at the first entry in your watchlist:
https://sv.wikipedia.org/wiki/Diskussion:Belarus?action=info

grafik.png (497×747 px, 47 KB)

This would explain a lot. I think (not 100% sure) the "misc" aspect should be easy to fix? Regardless, this is a different issue.

@Ainali and @Ladsgroup : thank you for the updates. I will forward this information to the team and see if we can help. If we open a new ticket, I will comment it here.