This is an archive of past discussions about Module:WikidataIB. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
New parameter for getValue sought to avoid attempt to resolve redirects
Line 371 and 372 perform expensive operations that record tranclusions to pages. This occasionally results in the module outputting a plain label when an article exists but is not a redirect (Module assumes is a DAB page). However, because of artitle.id and artitle.isRedirect, even though no clickable link is produced, a page link is still registered, causing the page to pop up on Disambiguation pages with links. I would like a parameter to pass to getValue that will disable line 371/372. If no valid sitelink exists, go ahead and link to Wikidata, without checking for a local redirect. Terribly verbose but something like "noRedirectResolution". Alternatively, disable this section entirely until such time we can test for page existence without registered a page link. -- ferret (talk) 00:32, 30 May 2018 (UTC)
The reason for that code is that Wikidata refuses to allow an entry like archaeologist (Q3621491) to have a sitelink to Archeologist, merely because the latter is a redirect (the English Wikipedia discusses 'archaeologist' as part of the 'Archaeology' article). If it were not for that code, biographical infoboxes would not have links to many of the occupations, for example. Who would make use of a parameter that disabled the code? Would any infobox designer use a parameter that disabled linking for an unpredictable number of values or fields? I seriously doubt it. There is no problem with expensive calls in the module – the call mw.title.new(id) is not used. The problem is that mw.title.new(label, namespace) – which is called when there is a label, but no sitelink – incorrectly makes an entry in the table used for "What links here". That affects every Lua module using that call, not just WikidataIB, and that is the problem that needs to be fixed. I'll investigate alternate methods of deciding whether a label represents a linkable article on the local Wikipedia. In the meantime, anybody can bypass the problem by supplying a local value. --RexxS (talk) 15:07, 30 May 2018 (UTC)
@Ferret: I've been trying to minimise the use of mw.title.new(label, namespace) in the sandbox, but I'm having difficulty testing because I can't find examples of the effect you are referring to. Could you list perhaps half-a-dozen articles where the problem occurs, please? and I'll see if I can improve matters at all. --RexxS (talk) 15:50, 30 May 2018 (UTC)
@RexxS: mw.title.new itself is not an issue, it is calling .id or .isRedirect on the resulting object. These are the ones that register page links. Even if the resulting output does not contain a link, soon as .id/.isRedirect are used, a transclusion is registered. I have not been able to find any way to test for page existence that does NOT cause a page link to register. The source of complaint resulting in this request is at Template talk:Infobox video game#The series field and Template talk:Infobox video game#Skate (video game) and Template:Infobox video game (series= field). In both cases, editors who are attempting to resolve DABLINK reports have came across cases where the series parameter is pulling from Wikidata, and the linked item does not have an enwiki article. Line 371 and 372 take the linked item's label and attempt to discover if its a redirect (neither case was), and then outputs a plain label (assuming the article to be a DAB). On the surface, this is exactly the behavior you would want. Unfortunately, calling .id and .isRedirect register a pagelink anyways, and the article is pushed into the DABLINK reports. See the back and forth edit history on Skate (video game). As a test case, you can look at Module:Sandbox/Ferret. If you check Whats Links Here on User:Ferret/sandbox, you'll see that User:Ferret/sandbox2's use of the module and artitle.isRedirect (Well, redirectTarget, but same result) cause it to register as a linked page. I used maketitle but new works the same way. It's the call to the title object that actually makes the link, not mw.title.new. -- ferret (talk) 16:42, 30 May 2018 (UTC)
@Ferret: Sure, that's true. But as soon as I create the object, I test for its id and isRedirect properties, otherwise there's no point in creating it, so we end up with the same result. I've re-written the sandbox code so that if there is no sitelink, I check whether the value itself (which is a wikibase-item) has a property instance of (P31) equal to Wikimedia disambiguation page (Q4167410). If so, I give the plain label and skip checking for existence of an article and whether it's a redirect. Now, if a wikibase entity exists which has no sitelink to enwiki, has a English label, is not an instance of a dab page, has an article title on enwiki the same as the label, but is not a redirect, then I don't know what it is, but it will turn up in Disambiguation pages with links. However, I hope there won't be many of those once the sandbox code is implemented.
As for your sandbox and the rest, I'm aware of the spurious linking, and I understand how it happens, but I'm still waiting for somebody to give me a few examples of actual articles using WikidataIB that provoke the problem. Then I can test whether the sandbox code fixes the problem. I'm not keen to modify the main module until I can show that the sandbox code does what I'm expecting it to do. Can you help with that? --RexxS (talk) 18:26, 30 May 2018 (UTC)
@Ferret: Thanks. That let me test other possibilities. I agree that the call mw.title.new(label, namespace) alone doesn't cause the spurious link. I thought I could circumvent the issue by replacing the test using the title object's id and isRedirect properties with one that uses the title object's redirectTarget property. Unfortunately, despite the documentation not indicating it, it also creates a spurious link. I'll have another think. --RexxS (talk) 13:32, 31 May 2018 (UTC)
I found the same issue. Several of the title object properties are not explicitly labelled as creating a site link but do. It seems to be any of the expensive ones that cause a DB retrieval though. -- ferret (talk) 13:36, 31 May 2018 (UTC)
That's right. It's because the devs used a short-cut to record the change of state in the same table that records links. And I'm now having an argument with Anomie on this very issue at mw:Extension talk:Scribunto/Lua reference manual #Title object and spurious links because I dared to update his documentation. If you have a moment to spare, You might pitch in to emphasise just how important it is to fix this bug, because otherwise the title library is pretty useless in Wikipedia. Cheers --RexxS (talk) 17:51, 31 May 2018 (UTC)
Anomie appears to be correct in the strictest sense. isRedirect is a link, redirectTarget is a transclusion. Both appear in "What Links Here". I do not know if DABLINK stuff tells the two apart or not. If so, it is worth trying redirectTarget to find if a redirect works without tripping DABLINK. -- ferret (talk) 19:06, 31 May 2018 (UTC)
Well, Anomie is insistent that redirectTarget doesn't create a link, so I'll happily refer any future complaints to him to sort out. The sandbox code does indeed only produce a transclusion, so I'm happy that it's an improvement, but I'd be willing to bet that the gnomes who look for links to dab pages won't see it that way. I'm waiting for the RfC on using Wikidata in infoboxes to be concluded before rolling out the updates currently in the sandbox, but hopefully those will lay to rest many of the current issues that folks have with how we fetch Wikidata. Cheers --RexxS (talk) 20:25, 31 May 2018 (UTC)
