Page MenuHomePhabricator

Be able to filter Wikibase edits in Recent Changes on type of change
Open, Needs TriagePublic


As an editor on the client I want to be able to filter which Wikidata changes are shown in my watchlist and recent changes in order to filter out changes that are not relevant to me.


  • Editors are seeing changes from Wikidata that they do not consider relevant for their Wikipedia work. For example changes to sitelinks to other language editions.
  • Editors are also seeing too many changes in their watchlist. This leads to them being more likely to disable showing all Wikidata changes and not seeing any of the changes that are relevant for them.

We could solve this by offering a filter to not show certain types of changes coming from Wikidata. The following filters probably are going to be useful:

  • sitelinks
  • labels
  • descriptions
  • aliases


  • I am seeing an edit on Wikidata showing up in my English Wikipedia watchlist that changes the sitelink on Hebrew Wikipedia. I am not interested in this edit as I don't speak the language.



Acceptance criteria:

  • editors on the client wiki are able to filter their watchlist and recent changes for certain types of edits coming from Wikidata

Original report:

[Stolen from]

It would be lovely to add a filter group for RecentChanges/Watchlists for Wikibase edits based on type of edit:

  • sitelink
  • label
  • description
  • alias

    For the above four, you'd probably want to filter explicitly on adds/changes/removes, and on a match list of languages (maybe pre-populated from the user's Babel stack)?
  • statement

    For this, you'd want add/changes/removes, but also details within changes like added/removed qualifiers, and possibly match to a list of properties (e.g. show me changes that remove instanceOf claims).

From my poking around the DBs, this is going to be a serious epic if we do this. Wikibase doesn't store any of this information inside the DB stack, instead calculating it on the fly from deserialised entities fetched from external storage, so there's nothing in the recentchanges table for the filtering code to use, nor anything even to join onto.

See also: T60698: Enable fulltext search in edit summaries (and logs)

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

A prototype of this could likely be pretty good just filtering on the edit summary used.
We could also look at using rc_params?

Edit summary is in a different table so that would be a bit expensive, but probably doable? Of course it'd be tricked by people manually writing the trigger terms into the edit comment of a normal edit, but that's maybe sufficient for a start?

JTannerWMF added a subscriber: JTannerWMF.

We will consider this for the future, however, it is not currently in scope.

All of these cases were mentioned in todays Bug Triage Hour:

They all have in common that editors are alerted about stuff that a) does not show up in the article or b) that they are unable to vet as they don't speak the relevant language.

Note: Not all cases of these are covered by this task.