Module talk:WikidataIB/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 8

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)

Skate (video game) does it. It is currently not doing it because the wikidata pull has been suppressed. Same for Eye of the Beholder (video game). These are the two that started the discussions of spurious links. Removing |series from either should do it. -- ferret (talk) 21:03, 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)

I've also re-enabled my test code in User:RexxS/sandbox/Wikidata so we can check whether that page shows up as a link to the dab page [ [Skate]] in the other reports. --RexxS (talk) 20:29, 31 May 2018 (UTC)

Major update, June 2018

While the Wikipedia:Wikidata/2018 Infobox RfC has been running, I've not updated the main module, but left developments in the sandbox. Now that the RfC has ended, I've updated the main module from the sandbox. This has brought some improvements both in performance and functionality.

• Performance gains will occur because the module now only loads the part of the Wikidata entry that it needs for the call, rather than the whole Wikidata entry (which was formerly the only way of accessing the data). The calls to other Wikidata entries which are not immediately associated with the page are no longer expensive.
• The getValue call now supports ranks via a parameter, offering more flexibility than using getPreferredValue (which is now just a call to getValue with rank set to "best").
• The getValue call now supports returning qualifiers as values in parentheses after the property value.
• The getValue call now allows a number of extra parameters to provide extra functionality such as limiting the number of values returned, or auto-collapsing the list of returned values if the number of values exceeds a given number. Details are in the documentation at Module:WikidataIB/doc #Parameters to getValue.
• There is a new call, getValueByQual, which works similarly to getValue, but only returns value(s) that have a particular qualifier with a given value. Details are in the documentation at Module:WikidataIB/doc #Function getValueByQual.
• There is a new call, getValueByLang, which works similarly to getValue, but only returns value(s) that have the qualifier language of work or name (P407) with a given language code as its value. Details are in the documentation at Module:WikidataIB/doc #Parameters to getValueByLang.
• The getValue call now displays its results a little differently when the value returned has a sitelink available. In those cases, the link remains to the sitelink, but the displayed text uses the site link (with disambiguation text removed) instead of the label. This is a response to the vulnerability of labels to vandalism on Wikidata.
• The wrapper template {{wdib}} is a convenient shortcut for {{#invoke:WikidataIB |getValue | ...}} using the same parameters. For example the spouse (P26) of Douglas Adams (Q42): {{wdib |P26 |qid=Q42 |fwd=ALL |qual=DATES}} gives Jane Belson (1991–2001) 

There are numerous test cases/examples at Module talk:WikidataIB/testing. Please ping me if problems arise. --RexxS (talk) 18:27, 13 June 2018 (UTC)

This module is getting ridiculously bloated. {{3x|p}}ery (talk) 21:24, 13 June 2018 (UTC)

Don't be so rude. Nevertheless, you should feel free to make constructive suggestions about which parts of the functionality you would remove to improve the module. --RexxS (talk) 23:25, 13 June 2018 (UTC)

getPreferredValue causing problem on page without a WD item ?

I know, the simple answer is "So make the item."

{{Infobox video game}} on use at The Sinking City is not displaying the locally defined value for image=. Currently the article has no WD item linked. Substituting a random QID for testing, the image will then appear. Looks like something isn't gracefully failing when there is no QID. -- ferret (talk) 02:28, 14 June 2018 (UTC)

I believe this is now fixed. {{3x|p}}ery (talk) 02:38, 14 June 2018 (UTC)

Confirmed, is fixed, thanks. -- ferret (talk) 02:40, 14 June 2018 (UTC)