Module talk:WikidataIB/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Out of memory error

@RexxS, Mayankj429, and Aman.kumar.goel: I have just undone Special:Diff/971102807. It seems to cause an out of memory error (see before and after). Also the page loading time is significant in the old revision, faster in the new one. I would assume this is the memory issue. I'll leave it reverted for now, but I think people who understand this 10x more than I do need to discuss. -- Amanda (aka DQ) 18:33, 30 December 2020 (UTC)

One possible solution: rather than fetching all property values and filtering out the last with |list=p-1, we can mark a single value as preferred in Wikidata (d:Help:Ranking) and use |rank=p |maxvals=1. From a quick test (after making the preferred value here), memory usage from that single call gets cut in half, from 8MB to 4MB. This requires keeping the preferred value up to date in Wikidata, but otherwise seems like an easy fix. Pinging Dellux mkd, who is keeping this updated in Wikidata. What do you think? — The Earwig ^talk 19:11, 30 December 2020 (UTC)

@AmandaNP, Dellux, and The Earwig: This call:

{{#invoke:WikidataIB|getValue|fwd=ALL|P8011|qual=P585|list=p-1|qo=1|qdf=dmy|qid=Q84055514}} →

costs around 0.5 sec out of 10 sec and 8 MB out of 52 MB of Lua resources, which is pretty expensive for a way to get the latest date, and relies on Wikidata storing values in order. This call:

{{#invoke:WikidataIB|getValue|fwd=ALL|P8011|qual=P585|rank=b|qo=1|qdf=dmy|qid=Q84055514}} →

costs around 0.005 sec out of 10 sec and 0.6 MB out of 52 MB of Lua resources, which is a lot cheaper but relies on the latest date being marked as preferred. Neither of these calls on their own cause an out-of-memory error, but if the editors of the article insist on having a ludicrous 383 references, then every little saving on Lua resources will help to keep the article from falling over. Without either call, the Lua memory usage of the article is still 51.7 MB out of 52.4 MB with nearly 7 sec of Lua processing time. The real solution is to get rid of the massive overcitation, and dramatically reduce the content that's available in the daughter articles per WP:SS. Otherwise, it won't be long before it falls over again. --RexxS (talk) 20:44, 30 December 2020 (UTC)

Well, i just have to repeat what AmandaNP said and that is that i leave this discussion to people who understand this 10x more than i do. I agree with The Earwig and RexxS that we must get rid of the massive overcitation. 383 references so far is way too much and can be reduced in order too keep the article from falling. Again i must say that i leave the call to people who understand this more than i do. Dellux mkd (talk) 21:36, 30 December 2020 (UTC)

Thanks, I'll restore the cheaper version and start nuking out some refs and maybe splitting. -- Amanda (aka DQ) 22:20, 30 December 2020 (UTC)

@RexxS and The Earwig: While I did nuke a lot of things out of the article, me going through and removing any excess referencing seems like a monumental task compared to what we might be able to do by modifying the 15 invokes of this module. Right now, memory is: Lua time usage: 3.419/10.000 seconds | Lua memory usage: 48,199,303/52428800 bytes. After removing the module and replacing by hand: Lua time usage: 2.051/10.000 seconds | Lua memory usage: 28,396,497/52428800 bytes. So if either of you can optimize anything on that page, it would be appreciated. -- Amanda (aka DQ) 14:02, 31 December 2020 (UTC)

Error continues at other sections

@RexxS, The Earwig, AmandaNP, Oshwah, Dellux mkd, and Mayankj429: The "Lua error" is now present for the entire External links section as per latest version Special:Diff/999975064. Also, at COVID-19_pandemic_in_India#Testing one can see a table full of dates being displayed that is serving no logic. Please have a look and a resolution is highly appreciated. Besides this, I request to make the page temporary semi-protection due to disruptive editing by IP editors now and then. Thank you. — Amkgp 💬 18:04, 15 January 2021 (UTC)

Oh boy. Okay, we'll take a look at it. ~Oshwah~^{(talk) (contribs)} 19:34, 15 January 2021 (UTC)

Someone restored the stuff I removed with this edit. -- Amanda (aka DQ) 20:53, 15 January 2021 (UTC)

It's actually back to 10MB from the memory limit likely because of the continual increase in data from wikidata. I'm going to have to remove the values and we'll have to put it in by hand. -- Amanda (aka DQ) 21:00, 15 January 2021 (UTC)

I took out the wikidata statements at they will be ever expanding, and WP:NOTNEWS and WP:INDISCRIMINATE. We can update the numbers manually. -- Amanda (aka DQ) 21:07, 15 January 2021 (UTC)

The values on Wikidata were being updated without marking the latest date as preferred, so there's no way to reduce the overhead without cooperation there. I strongly recommend that we don't use Wikidata for these articles because of the time-sink involved in fixing avoidable problems. --RexxS (talk) 22:06, 15 January 2021 (UTC)

getQualValueByLang

How can I get a qualifier value by language?

I need to get the English value of the media legend (P2096) qualifier of the first value of the image (P18) statement on Douglas Adams (Q42).

--Lectrician1 (talk) 06:00, 12 February 2021 (UTC)

Module:Wd by default gets the value in the local wiki's language, so this works for you:

{{wd|qualifier|Q42|P18|P2096}} → Portrait of Douglas Adams

Thayts ••• 09:20, 12 February 2021 (UTC)

Detecting same/different values in Wikidata

I would like a convenient way to detect when a locally-defined value is equal to the value on Wikidata (which would tell me I could safely remove the locally defined value) or when a locally-defined value is different to the value on Wikidata (which might indicate an error in either value). Possibilities I had in mind:

• Colouring the entire value/text green or red (respectively) if the wd value is same/different
• Adding a small icon (e.g. / ) after the value.

In both cases, they would only appear if set by an editor's personal CSS. This is not something to trouble the reader with. Thanks for consideration — Martin (MSGJ · talk) 19:46, 3 March 2021 (UTC)

Bug with checkBlacklist

{{#if:{{#invoke:WikidataIB |checkBlacklist |name=nationality |suppressfields=residence; nationality; citizenship}} | not blacklisted | blacklisted}} → not blacklisted — Martin (MSGJ · talk) 22:10, 15 March 2021 (UTC)

The module is outputting "false" which is treated the same as "true" by the "if" conditional. It might be better if it just outputted blank rather than false. — Martin (MSGJ · talk) 15:42, 17 March 2021 (UTC)

This works:

{{#ifeq:{{#invoke:WikidataIB |checkBlacklist |name=nationality |suppressfields=residence; nationality; citizenship}} | true | not blacklisted | blacklisted}} → blacklisted

Shall I update the documentation, or can we change the output of "false"? — Martin (MSGJ · talk) 15:54, 17 March 2021 (UTC)

Bug?

Module:WikidataIB#Function_checkBlacklist is currently returning true for both examples, when I'm pretty sure the first is meant to return "blacklisted". {{u|Sdkb}} ^talk 08:56, 23 August 2021 (UTC)

• Oh, I see MSGJ raised this already and identified the issue. I'm not sure if changing to a blank output would cause any issues, but the documentation or something needs to change. {{u|Sdkb}} ^talk 08:58, 23 August 2021 (UTC)

Problem with caption

See also: Module_talk:WikidataIB/Archive_7 § Caption

I'm having a problem getting the correct caption for the image. Burlington Breakwater South Light (Q109370544) has two images. The first does not have a caption but the second does.

{{wdib|maxvals=1|P18|qid=Q109370544|fwd=ALL|osd=n}}

gives me the first image, which is fine:

Burlington Breakwater South VT.JPG 

But

{{wdib|maxvals=1|P18|qid=Q109370544|qual=P2096|qualsonly=y|fwd=ALL|osd=n}}

is giving me the caption for the second image, which I don't want, because it doesn't match the image.

modern replica lighthouse, lit in 2004 

At Module talk:WikidataIB/Archive 6, Rehman suggested using the getQualifierValue function, but I can't get this to work — Martin (MSGJ · talk) 17:18, 27 November 2021 (UTC)