Last modified: 2014-11-18 18:07:12 UTC
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 [[d:Q597748]]; according to page history, that connection was made at the end of 2012.
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.
It seems fine to me now. Is there still an issue that can't be fixed by a null edit?
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]]
*** Bug 68945 has been marked as a duplicate of this bug. ***
