In some cases, moving or deleting pages on a client wiki does not result in sitelink updates / removal on Wikidata.
The most common causes for this seem to be the following:
- A user performs "move without leaving a redirect behind" on a redirect page on a client wiki. (The corresponding action on Wikidata might fail because redirects are not allowed as sitelinks.)
- A user performs "move without leaving a redirect behind" on a client wiki and the page is moved to another namespace.
- Editing of an Item is restricted (e.g. semi-blocked) for the user.
- Deletions (much smaller number, but maybe only because of interventions from "User:Hoo Bot")
- Other reasons: There seem to be plenty of cases that need a different explanation.
- Page moves and deletions are not processed if you have an SUL and have never visited Wikidata.
- User is blocked on Wikidata but not on the client wiki.
(This section was mostly based on research by MisterSynergy.)
- Let's evaluate possible solutions for the common causes.
- Let's try to think of solutions without dummy users for now.
- Ignoring editing restrictions (like semi-blocks or Item protections) when updating client wiki updates is fair game.
- In what cases would it be better to remove the sitelink rather than update it (e.g. when a page is moved from main to user namespace in the client wiki).
- What are other explanations? (MisterSynergy: Maybe "Wikidata is read-only" at the moment of the edit can also lead to missed sitelink updates.)
- When a page is moved on a client wiki, the sitelink should be updated on Wikidata.
- When a page is deleted on a client wiki, the sitelink on Wikidata should be removed.
This generally happens except when the users is unknown to Wikidata (or blocked).
The question is how these edits should appear on Wikidata.