Wikidata For Wikimedia Projects/Reduce change propagation noise
How to see Wikidata edits in other Wikis Watchlist and Recent Changes
Wikidata edits in Watchlists and Recent Changes are an opt-in feature. For more information, see this guide to enabling Wikidata edits in your Recent Changes and Watchlist pages.
Description of problem
[edit]There is a very high-volume of Wikidata-injected rows in to the Recent Changes tables, sometimes even double the amount of those Wikis actual edit rows.
For example:
- ar.wikipedia: 2.3x more Wikidata-injected rows than local edits
- uk.wikipedia: 3.2x more
- no.wikipeda: 7x more
(Mentioned in T400698)
This is drastically contributing to a large set of slow queries in recent changes tables (with queries reaching a time-out resulting in direct user-facing impact) and it's also makes them so noisy that people don't check them anymore.
Impacts
- Direct: many queries time out due to their size
- Indirect: Undermines the original purpose of Recent Changes as a tool to monitor content integrity, as a high-volume of low-impact edits drown out useful or meaningful ones.
- It also adds to a negative perception of Wikidata content being included in Wiki-articles and pages, as the noise it creates does more harm than good.
Below are some tasks aimed at addressing this situation and will take place in 2 phases.
The initial tasks (Phase 1) are to immediately and drastically reduce the amount of edit rows being added to the recent changes table from Wikidata, to stop the situation from worsening and buy enough time for the next phase.
Phase 2 tasks will be longer-lasting or permanent solutions to the issue at hand.
Phase 1: Turn off (temporarily) Qualifiers and References Wikidata edits to the Recent Changes tables
[edit]A large proportion of Wikidata-injected rows mentioned in the examples above come from edits to the Qualifier and/or Reference section of a Wikidata statement.
We plan to temporarily turn their tracking off so they will no longer appear in the Recent Changes table, while a better solution is explored (see Phase 2: new usage tracking for Qualifiers and References) .

What exactly is affected?
When editing a Statement of a Wikidata item, if the edit occurs on the Qualifier or Reference section, no recent change injection will be created.
What isn't affected?
- Edits to the main facts of a statement (property/value pair) will still cause a recent change injection.
- A change to a qualifier or reference and a statement fact in the same edit, will also cause a recent change injection.
How long will the Qualifer/Reference edits be missing from Recent changes?
We estimate ~2 months, from beginning of September to end of October, however this may take longer. We will do our best to keep it as short as possible and communicate any changes or delays.
Status
[edit]- Passed code review: 28.08.2025
- Added to MediaWiki version:
MW-1.45-wmf.17; 2025-09-02 - Deployed to all Wikis by end of day, 04.09.2025.
Phase 1: More granular Alias tracking
[edit]Problem Statement
[edit]Edits to Wikidata Items aliases (Also known as) field have been creating unnecessary 'noise' in Recent Changes pages and Watchlists of other Wikis.
Background Context
[edit]All Wikidata Items can contain a single Label, Description but can have multiple Aliases (also known as) per language.
They help describe the item in natural language terms.

When information from Wikidata is included on a Wiki-page, it is tagged with an 'aspect' type, represented by a letter.
Aspect types refer to parts of a Wikidata entity and help MediaWiki keep track of where Wikidata's data are displayed on a page and when an update is needed.
This is important for page loading and rendering, instead of rechecking the entire Wikidata entity on every page-load, only the tracked aspects are checked. This improves page-load speed and keeps the functions from being too expensive computationally.
Aspect types in use:
- S = Sitelink
- L.xx = Label (in a specific language, e.g. L.en = English Label)
- T = Title
- D.xx = Description (in a specific language)
- C.Px = Statements (Claims), where specific properties/values are reused.
- O = Other (miscellaneous: existence checks and other), this is where aliases used to be assigned until this deployment.
- X = All, other aspects (such as statement data).
Subscribing: Telling the parser what information needs to be checked
[edit]There could be multiple ways of subscribing Wikidata information from an Article, the semantics can be different but fundamentally, a mw.wikibase.FUNCTION or parser function must be invoked directly on the client-page or in the Lua code of an extension (Extension: Wikibase Client), Module: or Template: that is being invoked on the client page.
For example, the South Pole Telescope article invokes the Template:Infobox_Telescope (which reuses functions from Module:WikidataIB) where many functions (getLabel, getDescription, getAlias/es etc.) reside.
Noisy Notifications
[edit]Wikidata aliases were assigned an aspect type of O = Other (or Miscellaneous), but are just one data-type falling under this aspect type. The O aspect type does not have a .xx language modifier, meaning it cannot be specified to check for changes on certain languages.

If an alias is changed in any language on the subscribed Wikidata item (regardless of the language of the client Wiki), a change propagation is made and a RecentChanges row is created (and a Watchlist notification is sent to any Watchlists watching the client Wiki page).

You can see what Wikidata entities and data are being tracked for the current page from the Page Information (found under the Tools ∨ dropdown menu) or at the bottom of the Edit source tab. It will provide a list of the subscribed Wikidata Items and what aspects of the item are being tracked for changes (sitelink, label, statements, miscellaneous [other]).
Since a Wiki page can subscribe to multiple Wikidata entities, even minor edits (such as alias changes in in any language) can generate a large volume of Recent Changes entries/Watchlist notifications. For the majority of editors, these notifications have very little importance and relevance to the client Wiki-page/article.

Aside from the extra-load on the database, this 'noise' discourages editors from enabling Wikidata edits in their Recent Changes/Watchlist pages and contributes to a negative perception of Wikidata's use in Wiki-pages.
Solution
[edit]We are deploying a change so that Alias edits will be under a much narrower criteria to trigger notifications and Recent Changes entries on subscribed Wiki pages.
By reducing the number of tracked edits, we aim to make Watchlists and Recent Changes tables more useful and relevant to editors to monitor changes to articles and content they care about, while also reducing pressure on the database.
Creating a new aspect type
[edit]We are implementing a new aspect type, specifically for aliases: A = Alias and includes a language modifier (.xx), allowing tracking to be much more specific.
Examples:
- A.en will subscribe to changes to the English-language alias.
- A.it will subscribe to changes to the Italian-language alias (even if client Wiki is the English Wikipedia).
- A.fr will subscribe to changes to the French-language alias.
Alias entity usage limit
[edit]Additionally, we are applying an entity usage limit of up to 10 entities. This trade-off is needed to maintain the size of Recent Changes table (recent_changes) while reducing the number of notifications. This means if a Wiki-page/article is subscribed to 10 or more entities, an edit to an alias (of any language) will Wikidata entities subscribed:
- 10+ entities: an edit to the alias section in any language will cause a Watchlist notification and Recent Changes entry
(the same as the previous behaviour)
- 9 or less entities: unless the alias edit occurs in a specified language tracked by an aspect (A.en), no notification/recent changes entry will be created.
Updating pages
[edit]A null-edit or purging the page's cache where the subscribed languages are stated (within Lua-code of the Module: or Template: page) is required for these changes to take effect as they will be tracking changes in the O aspect and won’t push any notifications for the A aspect until then.
We will deploy a user-script to 'touch' those pages and ensure the aspect-type is changed.
Status
[edit]- Passed code review: 04.09.2025
- Added to MediaWiki version: MW-1.45.0-wmf.18
- Deployed to all Wikis by end of day, 11.09.2025
Phase 2: new Aspect type for Wikidata Qualifiers / References
[edit]Problem Statement
[edit]Removing Wikidata edit notifications for Qualifers and References results in important information is missing from the history of a page/article. Wikimedians need to be able to see what changes are being made to decide whether the edit is valuable, accurate and verifiable.
Background
[edit]In Phase 1, all notifications and recent changes entries for non-Wikidata Wikis coming from edits on the Qualifier and/or References of Statements were disabled.
This was always intended as a temporary measure while we investigated how to place these under a new aspect type. This will result more granular tracking, less recent changes and watchlist noise from fewer/irrelevant entries.
Status
[edit]- Investigation:
In progress…
- Code Review: TBD
- Deployment to all Wikis: TBD