Wikidata For Wikimedia Projects/Reduce change propagation noise - Meta-Wiki

Wikidata For Wikimedia Projects/Reduce change propagation noise - Meta-Wiki
Jump to content
From Meta, a Wikimedia project coordination wiki
Wikidata For Wikimedia Projects
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.
Tracked in
Phabricator
Task T401286
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 causes a recent change injection from a Wikidata Reference or Qualifier edit.
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.
Tracked in
Phabricator
Task T401288
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.
A Wikidata Item can contain multiple aliases per language
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:
Sitelink
L.xx
Label
(in a specific language, e.g. L.en = English Label)
Title
D.xx
Description
(in a specific language)
C.Px
Statements
(Claims), where specific properties/values are reused.
Other
(miscellaneous: existence checks and other), this is where aliases used to be assigned until this deployment.
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
Other
(or Miscellaneous), but are just one data-type falling under this aspect type.
The
aspect type does not have a
.xx
language modifier, meaning it cannot be specified to check for changes on certain languages.
What the Page Information tells about what Wikidata entity information is being tracked
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).
A single Wiki-page can be tracking changes to many Wikidata entities (items and properties)
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.
Edits to Wikidata aliases can quickly create a lot of 'noise'
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:
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
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
aspect and won’t push any notifications for the
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
Tracked in
Phabricator
Task T401290
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
Retrieved from "
Wikidata For Wikimedia Projects/Reduce change propagation noise
Add topic