One example from hu.wikipedia (there are lots): first item on this list
https://hu.wikipedia.org/wiki/Speci%C3%A1lis:UnconnectedPages?page=1977%E2%80%931978-as+spanyol+labdar%C3%BAg%C3%B3-bajnoks%C3%A1g+%28m%C3%A1sodoszt%C3%A1ly%29&submit=Go
is in fact connected to Q597748; according to page history, that connection was made at the end of 2012.
Description
Details
- Reference
- bz53562
Event Timeline
This happens because the database isn't up to date yet. A null edit on the page solves this.
Use a bot to do null edits on all these pages. I've compiled a list for you at http://toolserver.org/~multichill/temp/queries/wikidata/huwiki_touch_bot.txt . The query is at http://toolserver.org/~multichill/temp/queries/wikidata/huwiki_touch_bot.sql
The list contains 16855 items. Ask one of you local (pywikipedia) bot operators to run over this file:
touch.py -lang:hu -family:wikipedia -file:huwiki_touch_bot.txt
That will kill the false positives.
I went though the list and I did null edit on every page, but I don't see any different on the linked special page.
Similar issues have been reported in my talk page on the Italian Wikipedia, too: https://it.wikipedia.org/w/index.php?diff=61662325
However, I found that even using the MediaWiki purge API https://www.mediawiki.org/wiki/API:Purge with the 'forcelinkupdate' parameter enabled solves the problem.
So:
- we can consider this bug as RESOLVED (INVALID / WONTFIX), having users to manually purge the cache, or:
- we state that this bug pertains to WikidataRepo; also the 'Component' field of this bug should be changed accordingly. Wikibase *Repo* (not *Client*) should automatically query the purge API of the corresponding client when adding/editing a sitelink. This is a client-side problem, but only a change on the server-side can fix it.
Lydia, which option would you prefer?
I set it to lower. It should still be fixed. But the priority is lower now. (I'm leaving it in client because that's where the issue is seen.)
https://ca.wikipedia.org/wiki/Especial:UnconnectedPages also lists many connected pages as unconnected. Could you help providing the list of pages awaiting a null edit? Thank you.
I have just searched out when this happens. It happens only by pages which include some old interwiki. See for example https://cs.wikisource.org/wiki/Speciální:UnconnectedPages?page=Author%3A-&submit=Prov%C3%A9st&iwdata=only (the most pages are connected) or https://en.wikipedia.org/wiki/Special:UnconnectedPages?page=Category%3A-&submit=Prov%C3%A9st&iwdata=only (some are connected).
I hope this will help solve the problem.
I made a list for the Catalan wikipedia at http://toolserver.org/~multichill/temp/queries/wikidata/cawiki_touch_bot.txt (query at http://toolserver.org/~multichill/temp/queries/wikidata/cawiki_touch_bot.sql). Just run a touch bot over these pages.
(In reply to Maarten Dammers from comment #8)
I made a list for the Catalan wikipedia
Thank you! https://ca.wikipedia.org/wiki/Especial:UnconnectedPages?page=&submit=V%C3%A9s-hi&iwdata=only is now clean.
PS: according to ca.wiki admin Vriullop, who run the bot using Maarten's list, this exercise has been useful to detect potentially systematic vandalism deleting links to ca.wiki but leaving the labels, something that we will have to watch closer at https://www.wikidata.org/w/index.php?title=Special:RecentChanges&tagfilter=new+editor+removing+sitelink
(In reply to Quim Gil from comment #9)
systematic vandalism deleting links to ca.wiki but leaving the labels, something that we will have to watch closer
[[d:User:LinkRecoveryBot]] is doing that for us ;-)
example: [[d:Special:Diff/106570700/108694713]]
Per recent improvements in Special:UnconnectedPages I highly doubt this bug is still valid.
It seems like there's still some issues. I see "1692 nî Sūi-tián" listed here even though the page itself shows the page as being connected to Wikidata.
This is not actionable.
Due to infrastructure problems very rarely such things might happen, but that's not specific to Wikibase. Also this is only derived data, so it's acceptable if it goes out of sync in extremely rare cases.