Module talk:WikidataIB/Archive 6

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 ← Archive 4 Archive 5 Archive 6 Archive 7 Archive 8

Retrieving nth value using #invoke:WikidataIB

Also posted at data:Wikidata:Project_chat

Is it possibly to retrieve an nth value from wikidata within a property. E.g. for a person to retrieve the first listed occupation separately to the second, the third etc? Example: 

{{#invoke:WikidataIB| getQualifierValue| qid=Q15136093| P106| pval=Q3809586| qual=P108| name=occupation| fetchwikidata=ALL}}

returns me the whole list of employers when I use it here, or just the first one if I use it over at wikidata's talkpages. T.Shafee(Evo&Evo)talk 02:05, 21 September 2019 (UTC)

Using the split function from Module:String2:
  1. {{#invoke:String2 |split | txt={{#invoke:WikidataIB |getQualifierValue |qid=Q15136093 |P106 | pval=Q3809586 |qual=P108 |name=occupation |fetchwikidata=ALL |noicon=y}} |sep=", " |idx=1}} → Staffordshire Record Office
  2. {{#invoke:String2 |split | txt={{#invoke:WikidataIB |getQualifierValue |qid=Q15136093 |P106 | pval=Q3809586 |qual=P108 |name=occupation |fetchwikidata=ALL |noicon=y}} |sep=", " |idx=2}} → Lancashire County Council’s Museum Service
  3. {{#invoke:String2 |split | txt={{#invoke:WikidataIB |getQualifierValue |qid=Q15136093 |P106 | pval=Q3809586 |qual=P108 |name=occupation |fetchwikidata=ALL |noicon=y}} |sep=", " |idx=3}} → TED
and so on. --RexxS (talk) 19:05, 21 September 2019 (UTC)
@RexxS: Thank you - very logical now that I see it! One limitation though: For properties where not all values have an entry (e.g. end time (P582) of the example above), is there a way to ask invoke:WikidataIB to include an empty string for the missing value? In the example above end time (P582), |idx=3 should return an "" empty string but idx=4 should return "June 2013". Could a |fulllist= parameter be included to avoid removing repeat separators? T.Shafee(Evo&Evo)talk 23:57, 22 September 2019 (UTC)
@Evolution and evolvability: I'm not too certain what you're trying to achieve, so it's quite hard to guess at what code would be best. Can I suggest you have a look at what getValue can do with its qualifiers and see if that gives you a solution before I start re-coding, please? It can duplicate the functionality of getQualifierValue and quite a lot more now. Here are some examples using Andy Mabbett (Q15136093):
I've recently updated the documentation, so it might pay to check what's possible using different pre/post-fixes and separators. Cheers --RexxS (talk) 01:37, 23 September 2019 (UTC)
@RexxS: Apologies, I'll give a bit more detail. In this instance, I'm trying to automatically generate rows of a table such as this one, where each row details the a values of a property. In this case, for each instance of occupation = "Wikimedian in Residence", return organisation, location, start, and end dates. This all works fine when a person has only ever held a single WiR position, but if a person has held multiple WiR positions, only some of which have end dates, you end up with the end date column shifting upwards where empty cells should be (example). Eventually I'll template it so that generating rows only requires the QIDs. 05:35, 23 September 2019 (UTC)
@Evolution and evolvability: Because most of the folks who use WikidataIB are template coders, rather than Lua coders, I've created some wrapper templates like Template:Stringsplit and Template:Wdib to condense the calls to modules such as String2 and WikidataIB. Using those can make your template more readable - just use {{stringsplit to replace {{#invoke:String2 |split and {{wdib in place of {{#invoke:WikidataIb |getValue. You ought to consider using getValue instead of getQualifierValue.
I also created some helper templates like Template:If then show to do common tasks for template coders. That template tests whether a parameter is empty and displays it if it is, or returns another parameter if it isn't. That allows us to call Wikidata once and then test and display the result, or give something else if the result is blank, So we could provide a non-breaking space if the call was empty, thus creating an blank cell in the table for you.
Having said all of that, it doesn't offer a solution for your problem. What you need is a non-empty value to pad out the returned list of qualifers, so that each list is the same length. The snag is that it can only work if we know how many items you want to be in the list. I'll have a look at how I can insert a non-empty value every time the qualifier has no value and let you know when I've coded it. --RexxS (talk) 16:43, 23 September 2019 (UTC)

Function qualsToTable

@Evolution and evolvability:

Wikimedian in residence (Q3809586)
Name employer (P108) URL (P2699) work location (P937) start time (P580) end time (P582)
Andy MabbettRoyal Society of ChemistryRSCWikiCambridge Science Park22 September 201418 September 2015
Andy MabbettBirmingham Museums TrustThinktankThinktankJanuary 2015June 2015
Andy MabbettORCID, Inc.ORCID June 2014 
Andy MabbettThe New Art Gallery WalsallNew Art Gallery WalsallThe New Art Gallery WalsallMay 2013June 2013
Andy MabbettARKiveARKiveBristolJuly 2011October 2011
Andy MabbettStaffordshire and Stoke on Trent Archive ServiceSAHSStaffordshire County MuseumMay 2013June 2013
Andy MabbettLancashire County Council’s Museum ServiceQSMMQueen Street MillMarch 2013September 2014
Andy MabbettTED  January 2016July 2016
Andy MabbettQueen Mary University of LondonHMBRGLondonApril 2017August 2017
Andy MabbettThe Physiological SocietyPhySocLondonApril 2017October 2017
Andy MabbettCoventry UniversityCoventry UniversityDisruptive Media Learning LabJune 201931 May 2021

How does that look? It's only an early draft and needs internationalisation and a parameter for the placeholder (currently hard-coded as "-" so I can see what's happening), but you could play around with it for now and let me know what changes you want. --RexxS (talk) 22:31, 23 September 2019 (UTC)

@RexxS: You're a champion, thank you. And it looks like it should be possible to merge into the current template I've been working on {{WiR table row}}. Thanks again. It looks like that should work perfectly! Some additional features that would improve functionality:
  1. Having ymd dates (2019-08-30) would make the date columns sortable (and probably useful for other applications).
  2. Being able to include the qid and edit icon as the row's first item would be valuable (see {{WiR table row}}). Perhaps a parameter to omit the <tr> and </tr> tags to allow it be used in the middle of a row?
  3. In case some of the urls are extremely long, it might be useful to be able to place the links inside [https://www.example.com custom text], but that might be over-specialised for the module.
T.Shafee(Evo&Evo)talk 00:54, 24 September 2019 (UTC)
@Evolution and evolvability: I've implemented date sorting using Template:Date table sorting inside the module. Using ISO-style dates in article text is generally not recommended (see MOS:DATEUNIFY). I know how to add a first column and have an idea for shortening the displayed urls. I'll do that later this evening. --RexxS (talk) 17:15, 24 September 2019 (UTC)
Done. See if you can find any problems and let me know. Cheers --RexxS (talk) 21:47, 24 September 2019 (UTC)
Postscript: I also implemented a parameter |emptycell= so you can choose what to have in the empty cells. It defaults to &nbsp;, but you can set |emptycell=- for a short dash. etc. --RexxS (talk) 21:59, 24 September 2019 (UTC)
@RexxS: Thank you again - I'll leave a link here once I've got the system up and running at outreach.wikimedia.org. T.Shafee(Evo&Evo)talk 23:41, 24 September 2019 (UTC)
@Evolution and evolvability: I just spotted your suggestion about removing <tr>...</tr>. It can't work because the module outputs multiple rows and won't fit in a table in any other way. If you should need more than one extra column at the start of a row, you can just use something like |firstcol=Cell 1 value</td><td>Cell 2 value. That would give two extra columns and could be extended as long as you only want a fixed value in each column. --RexxS (talk) 00:56, 25 September 2019 (UTC)
@RexxS: That makes sense. The |firstcol= works well for any of the use cases I can think of. Let me know when the functionality has been moved from the /sandbox into the main template. I'm asking or it to be imported over to outreachwiki here. T.Shafee(Evo&Evo)talk 02:00, 25 September 2019 (UTC)
@RexxS: Going well so far. A couple of urls shorten oddly though (e.g. (Q68772051#P106)). Any ideas? T.Shafee(Evo&Evo)talk 11:49, 29 September 2019 (UTC)
@Evolution and evolvability: Its quite hard to cleanly shorten https://he.wikipedia.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%99%D7%96%D7%9E%D7%99_%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94/%D7%92%D7%9C%D7%90%D7%9D/%D7%A1%D7%A4%D7%A8%D7%99%D7%99%D7%AA_%D7%99%D7%95%D7%A0%D7%A1_%D7%95%D7%A1%D7%95%D7%A8%D7%90%D7%99%D7%94_%D7%A0%D7%96%D7%A8%D7%99%D7%90%D7%9F,_%D7%90%D7%95%D7%A0%D7%99%D7%91%D7%A8%D7%A1%D7%99%D7%98%D7%AA_%D7%97%D7%99%D7%A4%D7%94
In Module:WikidataIB/sandbox, I've tried decoding the url before capturing the final word, so we would get:
Liron DorfmanYounes and Soraya Nazarian Library, University of Haifaאוניברסיטת חיפהHaifaAugust 2012February 2013
Would you have a chance to try out the sandbox for now, please? as I don't want to keep making minor alterations to the main module. As soon as you're happy, I'll update the main module, but let's dig out the bugs using the sandbox first. I suspect that there will be other occasions where we will need to use unicode string matching. --RexxS (talk) 18:47, 29 September 2019 (UTC)

@RexxS: Ok, I think I've finished with inputting all the relevant info to wikidata. See the table as it currently stands. The only thing that really to be edited in the module sandbx before merging into the main module and importing over to meta: is there any way to avoid the error message when the end date is 'unknown'. A question mark or similar would be better if possible. Finally, is there any way to avoid having to manually list the QID for each wikimedian in residence individually, and instead just list all Q for which P106==Q3809586? T.Shafee(Evo&Evo)talk 08:22, 27 October 2019 (UTC)

@Evolution and evolvability: I've fixed the error message when the date is unknown and used "?" for the value. It's easy to change, just let me know.
The only practical way to create a list of items from Wikidata that match a given criterion is to use a bot which interrogates the Wikidata Query Service and creates the list. One such bot is User:ListeriaBot, but unfortunately the output it creates doesn't suit the Luddites because if they alter it, it gets changed back the next time the bot is run. So the bot has been banned from from being used in mainspace. You'll have to do it manually, although you could use https://w.wiki/Asg to generate the list of WiRs for you whenever you need them. You could also use Listeriabot with that query to generate the list in your userspace, where it is not banned.
Let me know when you're ready to update the main module. Cheers --RexxS (talk) 18:23, 27 October 2019 (UTC)
Excellent. In that case, I think it is now ready to merge the sandbox into the main module so that it can also be imported over to meta and outreachwiki. I see what you mean about ListeriaBot. For the moment I'll see how the solution works with the table as currently set up. T.Shafee(Evo&Evo)talk 23:44, 27 October 2019 (UTC)
@Evolution and evolvability: The main template is now synced with the sandbox. It's ready to go wherever you want. Cheers --RexxS (talk) 01:32, 28 October 2019 (UTC)

Last steps over at meta

@RexxS: Hi! The copy over at meta is so close to operational (see example meta:Wikimedian_in_residence) The only thing that doesn't seem to be operating is the date display, but no error message is being shown. Any guesses for what template/module is missing? T.Shafee(Evo&Evo)talk 10:30, 28 November 2019 (UTC)

@Evolution and evolvability: the problem is that Meta has the Module:Complex date, but none of its dependencies. Have a look at Module:WikidataIB, lines 15 to 17, for a list of its eight dependencies. You'll have to arrange to have those imported from Commons, as well as re-importing the Commons version of Module:Complex date. The complication is that the English Wikipedia already had a Module:Date, so the modules here have been altered slightly to use a differently named module for Module:Date. --RexxS (talk) 17:23, 28 November 2019 (UTC)

Remove pen icon from every row in infoboxes

I find the pen icon to edit individual rows of infoboxes quite distracting and unsightly. See for example Arecibo Observatory.

Would it be possible to remove it? I think keeping [edit on Wikidata] option would be enough. Vpab15 (talk) 23:46, 18 December 2019 (UTC)

There is a "noicon" option for the module. Infobox telescope doesn't seem to implement it, but look at Infobox video game for an example. -- ferret (talk) 00:05, 19 December 2019 (UTC)
@Vpab15: I personally don't find the pen icon distracting and unsightly, but personal tastes differ. If the pen icon is disabled, other editors with different preferences may ask for it to be restored, so that doesn't bode well for finding a consensus on whether it should appear or not.
It has the functionality of allowing editors who spot a mistake or vandalism to go directly to the place on Wikidata where they need to make the correction, so that in itself must be a argument to retain the links. In addition, under current plans, when mw:Wikidata Bridge is implemented, the pen icon will be needed to pop-up the proposed editing interface to directly edit Wikidata from within a Wikipedia article.
Nevertheless, I could add a class to the icon, for example class="penicon", which would then allow you to add a line to your common.css file:
  • .penicon { display: none; }
The line would ensure that you never see the pen icons, although other readers would be unaffected. Would that represent an acceptable solution for you? --RexxS (talk) 02:55, 19 December 2019 (UTC)
Thanks @Ferret:, @RexxS:. I agree it is a matter of taste, but the average Wikipedia reader would probably find it more puzzling and distracting than useful. I can live with it as it is now, although I appreciate the offer, RexxS. It is more a question of whether it is a better user experience to have the pen icons or to just have the "edit on Wikidata" link. Vpab15 (talk) 15:58, 19 December 2019 (UTC)

Output of currency values

Hi. Following-up on a previous discussion we had here some time back. Looking at an article like Ace Embilipitiya Power Station, can we craft a way to change the output of the "Construction cost" parameter (which currently displays as 8,000 million Rs (2005)), so that it displays as Rs 8,000 million (2005) instead (including links)? Rehman 13:08, 18 February 2020 (UTC)

To get the biggest value / value corresponding to latest 'point in time'

What is the best way to get the biggest value or the value corresponding to latest 'point in time'? I have tried this code {{#invoke:WikidataIB|getValue|fwd=ALL|P1120|qual=P585|osd=no|list=ubl|df=dmy}}. It list all the values. But I want to get only the value which is either the biggest or the value corresponding to the latest 'point in time'.-❙❚❚❙❙ JinOy ❚❙❚❙❙ ✉ 21:32, 7 April 2020 (UTC)

@Gnoeee: The module does not have the functionality to select biggest or smallest from multiple values. Normally, I would recommend sorting the values and then using Module:String2's stringsplit function to select whichever value you want (see the documentation), but that requires you to use a unique separator for the values and you haven't given me an example. Are you working with values that are numeric, text, date?
Nor does the module have the functionality to filter the results on a date qualifier being latest/earliest. The only simple way to get the latest value is to make it the only preferred rank on Wikidata, and use the |rank=best parameter in getValue. Sorry. --RexxS (talk) 22:17, 7 April 2020 (UTC)
@RexxS: Thank you for the reply. I was working on to get the numeric value which corresponds to latest 'point in time'. Since the data changes every data, I want to make the edit only in Wikidata so that the change will be reflected in Wikipedia. I have added the case on my sandbox over here. I just required the value with the date at the bottom.-❙❚❚❙❙ JinOy ❚❙❚❙❙ ✉ 22:28, 7 April 2020 (UTC)
@Gnoeee: Well if you have a new value added every day, and you think it will always be the last in the list, you could cheat and use something like
  • {{wdib |ps=1 |P1120 |qual=P585 |sep="--" |df=dmy |qid=Q15397819}} →
to get a list of values with a custom separator ("--") in this case from the Wikidata Sandbox 3 (Q15397819) just as an example as I don't know where you're using it. Then you split off the last one:
  • {{stringsplit | txt={{wdib|ps=1|P1120|qual=P585|sep="--"|df=dmy|qid=Q15397819}} |sep="--" |idx=-1}} →
You don't need the qid= for the page you're working on; just leave it out. Hope that helps. --RexxS (talk) 23:30, 7 April 2020 (UTC)
It worked. Thank you. I have added it to an English article, 2020 coronavirus pandemic in Kerala here. IS it possible to remove the dates if required.? -❙❚❚❙❙ JinOy ❚❙❚❙❙ ✉ 05:34, 8 April 2020 (UTC)
@Gnoeee: Yes, just leave off the |qual=P858 and you just get the number:
  • {{wdib |ps=1 |P1120 |sep="--" |df=dmy |qid=Q15397819}} →
  • {{stringsplit | txt={{wdib|ps=1|P1120|sep="--"|df=dmy|qid=Q15397819}} |sep="--" |idx=-1}} →
You can drop the dateformat as well, of course, if you have no dates. --RexxS (talk) 17:04, 8 April 2020 (UTC)

Optionality of Wikidata

Hello everyone. I've recently begun using a local MediaWiki instance to prepare articles for Wikipedia and for an authentic experience exported several templates to use them there. Some of them transclude this Module. Since this local instance has no connection to Wikidata, access to mw.wikibase, which is nil, fails and results in errors. I added a check (see the sandbox) to make sure the variable exists before it used. This will have a low impact on Wikipedia but a higher one for local wikis of other users, so I leave the inclusion of this fix up to you. Regards, IceWelder [✉] 14:05, 13 April 2020 (UTC)

@IceWelder: Thanks for spotting that and for the accurate fix. I've updated to main module to include it. Cheers --RexxS (talk) 17:27, 14 April 2020 (UTC)

Bug?

Hello. name in native language (P1559) is a value in Nepali (Q33823), on Wikidata Sandbox 3 (Q15397819). But:

  • {{#invoke:WikidataIB|getLang|P1559|qid=Q15397819|fwd=ALL|spf=none|osd=no}} → en

Is this a bug, or am I doing something wrong? Rehman 14:54, 28 March 2020 (UTC)

@Rehman: Sorry I'm a bit late. The getLang function simply gets the language of the current wiki, not a value from Wikidata:
  • {{#invoke:WikidataIB |getLang}} → en
  • {{#invoke:WikidataIB |getLang |style=full}} → English
I don't recall writing a function that returns the language that a value is in, although I think we were doing something that passed a language code when we were working on PSunits, but my memory is poor.
There is a function called getValueByLang which gets the value of a property which has a qualifier P407 ("language of work or name") whose value has a given language code.
There is a function called getValueByQual which gets the value of a property which has a qualifier with a given entity value, so it could get a value which has a name in native language (P1559) equal to Nepali (Q33823)
But it's hard to know what to recommend without seeing what you're trying to do. Cheers --RexxS (talk) 22:53, 7 April 2020 (UTC)
Thank you, RexxS. I'm trying to work my way though cleaning up {{Infobox mountain}} and making it Wikidata compatible. Is there a better way to add wd support for the native_name_lang parameter? Rehman 05:13, 14 April 2020 (UTC)
name in native language (P1559) is monolingual text, I am not sure {{#invoke:WikidataIB|getValue}} works properly for monolingual text beyond the current wiki's language. What are you trying to do? One thing I notice is that name in native language (P1559) seems to be for names of people not mountains. Shouldn't you be using native label (P1705)?
{{#invoke:WikidataIB|getValue|qid=Q39231|P1705|fwd=ALL|spf=none|osd=no}} →
{{#invoke:Wd|property|eid=Q39231|P1705}} →
{{#invoke:Wd|property|multilanguage|eid=Q39231|P1705}} → 富士山
You might be able to use {{#invoke:Wd|property}} with |multilanguage as I demonstrate above where I pull the native label (P1705) claim from Mount Fuji (Q39231). I am not sure how to get the actual language code with either module though and for an article one probably does not want to use such text without properly marking it in its language, e.g., Japanese on English Wikipedia should always be marked with the proper HTML attribute via something like {{lang|ja}}. Uzume (talk) 06:27, 16 April 2020 (UTC)
Thank you. I will look into this suggestion, and comment again. Cheers, Rehman 07:12, 16 April 2020 (UTC)

Line breaking for long URLs

Hello. What is the best way to go about in stopping infobox-widening caused by long URLs on Wikidata? For example Warradarge Wind Farm. Rehman 15:55, 4 March 2020 (UTC)

If you specify the URL locally, you'll have the same issue. However, if you wrap the URL in {{Url}}, it wraps (Which is the templates purpose, or at least one of them). Possibly could borrow something from the Url template for WikidataIB. -- ferret (talk) 19:52, 4 March 2020 (UTC)
Yes, it makes sense to fix it here, rather than implement a manual fix on each infobox that uses it... Rehman 09:00, 24 March 2020 (UTC)
User:Ferret, after a bit of searching, I realised WikidataIB already has a feature that (seems) to do this. Module:WikidataIB#Function_url2. It seems to work alright so far. I wonder, though, why the function requires the code to be nested, rather than be a part of the same call. Anyway, it works, and I'm happy with that! Happy editing, Rehman 14:15, 28 March 2020 (UTC)

Unfortunately, this does not seem to work as expected. Can someone have a look at Watts Bar Nuclear Plant and see what is causing that output? Rehman 05:05, 14 April 2020 (UTC)

 Done: The IB |website= parameter is supposed to be a bare URL not an wikimarkup external link. I updated the official website (P856) claims on Watts Bar Nuclear Generating Station (Q1739496) and then removed the URLs from the IB and EL causing them to pull the values from WD. Uzume (talk) 05:27, 16 April 2020 (UTC)
Thanks Uzume. But why isn't it working properly with local values? I've temporarily reversed your goodfaith edit on Watts Bar Nuclear Plant. As you can see there, the local usage is not displaying as expected... Rehman 07:09, 16 April 2020 (UTC)
It works fine for local values but local values are supposed to be URLs and not general wikitext markup (Watts Bar Nuclear Plant was providing |website=[https://www.tva.gov/Energy/Our-Power-System/Nuclear/Watts-Bar-Nuclear-Plant Watts Bar Nuclear Plant]) because since 947790029 {{Infobox power station}} is formatting both the local parameter argument |website= and official website (P856) as URLs by pushing them through {{#invoke:WikidataIB|url2}}. You need to either rethink URL formatting for local values on the template or change all the calls to the template to adhere to a URL. I attempted the same thing recently on another IB sandbox (see 951238581) and decided to not use that in the live IB because such local values might come from the likes of {{Official URL}} (which also has an {{EditAtWikidata}} icon), etc. Uzume (talk) 13:21, 16 April 2020 (UTC)
BTW, if you are working on IBs like {{Infobox power station}} you should consider which Wikidata access mechanisms you are using, e.g, {{#invoke:Wikidata|function}} is unmaintained and deprecated and should be replaced with something else like {{#invoke:WikidataIB|function}} (of course such changes need ot be tested). Some of these changes are straightforward and easy, e.g., Special:Diff/947793208/951305116 but some functions are harder, e.g., {{#invoke:Wikidata|ViewSomething}} and {{#invoke:Wikidata|getImageLegend}} are not implemented in {{#invoke:WikidataIB|function}}. Uzume (talk) 14:12, 16 April 2020 (UTC)
Fixed by User:WOSlinker. Thank you! Rehman 02:39, 18 April 2020 (UTC)

Create Graphs and tables from Wikidata Values

Hi, I know Module:WikidataIB is intended to be used only inside the Infobox of an article. Is there any modules available so that we can construct graph and create tables using the data from Wikidata.-❙❚❚❙❙ JinOy ❚❙❚❙❙ ✉ 12:14, 24 April 2020 (UTC)

@Gnoeee: It depends on what you want to do.
Modules are good at extracting data from single entries, so it would be realistic, for example, to pull the figures for population (P1082) from New York City (Q60):
  • {{wdib|fwd=ALL|osd=n|P1082|qid=Q60|qual=P585}} → 8,405,837 (2013), 8,175,133 (2010), 2,507,414 (1890), 1,911,698 (1880), 1,174,779 (1860), 696,115 (1850), 1,478,103 (1870), 391,114 (1840), 242,278 (1830), 152,056 (1820), 119,734 (1810), 79,216 (1800), 49,401 (1790), 21,863 (1771), 13,046 (1756), 11,717 (1746), 10,664 (1737), 7,248 (1723), 5,840 (1712), 4,937 (1698), 8,516,502 ±10000 (2015), 3,437,202 (1900), 4,766,883 (1910), 5,620,048 (1920), 6,930,446 (1930), 9,454,995 (1940), 7,891,957 (1950), 7,781,984 (1960), 7,894,862 (1970), 7,071,639 (1980), 7,322,564 (1990), 8,008,288 (2000), 8,537,673 ±10000 (2016), 8,398,748 ±10000 (2018), 8,804,190 (2020) Edit this on Wikidata
It wouldn't be difficult to use those figures to create a chart.
Modules are very poor when you want to scan across multiple entries to extract a value from each one. That's usually done via the Wikidata Query Service (WDQS). This query is an example of cities with a population greater than 12 million. Unfortunately there's presently no way to use those results directly in Wikipedia pages. You'd have to use an external charting tool and embed the result in a Wikipedia page. --RexxS (talk) 17:48, 24 April 2020 (UTC)
@RexxS: Thank you for providing the information. It was just for a confirmation about the usage of the above mentioned template outside that of Infobox. I have created a model table using the template you have mentioned at here to display daily updates of 14 items. So that the data changes according to the changes in Wikidata.-❙❚❚❙❙ JinOy ❚❙❚❙❙ ✉ 19:16, 24 April 2020 (UTC)

Label

@RexxS: I am confused by something. {{#invoke:WikidataIB|getLabel}} lets one obtain a WD label but it requires a QID and will not fetch a label based on the QID linked to the current page. {{#invoke:WikidataIB|labelorid}} does something similar (and calls the same internal function to get the heavy lifting accomplished) but I can apparently call it without a QID and nil gets passed into the internal function and the mw.wikibase API then fetches the label for the QID linked to the current page just fine, however, this module's invocation frame function was passing back to the wikitext invocation everything the internal function returned and the internal function returns two values: the label and true or the QID and false. I fail to see how that is very useful. Is anyone actually using this? The wikitext template code would have to parse off the trailing boolean value somehow (since Scribunto just converts all the returned values and concatenates them together before handing it back to Mediawiki). What is the best way to obtain the label for the current page with this module and is there a way to do this without getting the QID back as a fallback or somehow otherwise testing if the label exists (having a QID fallback makes testing for label existence painful)? I added another set of parenthesis to labelorid so it chops off the boolean (the comment about the return value mentions nothing about returning the boolean so I assume this is a bug) returned by the internal function; see: 953800705. Example: {{#invoke:WikidataIB|getLabel|Q42}} yields "Douglas Adams" where as {{#invoke:WikidataIB|labelorid|Q42}} was yielding "Douglas Adamstrue" and now yields "Douglas Adams". Let me know if this was the wrong to do or if someone screams loudly. Thank you, —Uzume (talk) 03:28, 29 April 2020 (UTC)

@Uzume: Thanks for updating to the latest API calls. The original code here predates the regularisation of the mw.wikibase calls, so needed that.
The getLabel call is intended for use where a template passes a qid of another page to it, probably using followQid or getQid (the output of which could be an empty string). So if that qid is empty, the template doesn't want a fallback to the current page, it just wants to know that nothing was passed. That gets used when dealing with categories, for example. I didn't anticipate that anybody would want to use the label for the current page, as the sitelink is much more difficult to vandalise, and BASEPAGENAME is usually all that's needed.
As it says in the annotation, "labelorid is a public function to expose the output of labelOrId()". I only created it to debug all of the output of the local labelOrId function so that I could see what was going on without going to the trouble of opening up a debugging console. I never use it now, as I've got used to using {{examine}} to have a look inside the Wikidata from any edit window. Nobody is going to scream about changing it return just the label.
I've just added a new function label to get the label or nothing for you:
  • {{#invoke:WikidataIB|label|qid=Q42}} → Douglas Adams
  • {{#invoke:WikidataIB|label|Q42}} → Douglas Adams
  • {{#invoke:WikidataIB|label}} →
Pasting and previewing the last one in Douglas Adams gives Douglas Adams
I don't know a page where's there's no English label off the top of my head, so I'll leave it to you to test that it returns nil if you give it a qid of a Wikibase entity that has no English label. Let me know if you get any problems. --RexxS (talk) 15:11, 29 April 2020 (UTC)
@RexxS: Okay, thanks for the new invoke API {{#invoke:WikidataIB|label}}. Perhaps we can remove {{#invoke:WikidataIB|labelorid}} as I doubt anyone was using it since it was broken.
There are plenty of QIDs that have no English labels, e.g. Module:Biblio/Ouvrage (Q19805408).
  • {{#invoke:WikidataIB|label|Q19805408}} → Module:Biblio/Ouvrage
Notice it does yields the empty string and not its QID as you intended. The following code you wrote seems questionable:
	if qid == "" then qid = mw.wikibase.getEntityIdForCurrentPage() end
	if qid == "" then return end
I believe mw.wikibase.getEntityIdForCurrentPage always returns a QID or nothing (resulting in nil) so testing for empty string again will always fail. I fixed that, added the new function to the comment documented API at the bottom of the module and added documentation. —Uzume (talk) 18:40, 29 April 2020 (UTC)
@Uzume: thanks for spotting that and for the fix. I'm in the habit to normalising 'string variables' to "" instead of nil (as I always do for parameters passed via frame), and I neglected to add or "" after the getEntityIdForCurrentPage. But testing for nil is just as good in this case. I tend to use "", rather than allow variables that are expected to be strings to be nil, because sometimes when the code gets modified, string handling functions get used and they almost always throw an error when called with a nil argument. Whereas I prefer to see them fail gracefully for most purposes. It sometimes makes debugging a bit harder, but generally leads to fewer complaints in the long run. Cheers --RexxS (talk) 19:27, 29 April 2020 (UTC)

Problem with shortname

Hello, and sorry for the repeated posts. Why does:

  • {{#invoke:WikidataIB|getValue|1=P2044|2=|qid=Q15397819|qual=P459|qualsonly=Y|shortname=true|ps=1}} = North American Vertical Datum of 1988

And not, NAVD 88? Rehman 06:39, 9 May 2020 (UTC)

@Rehman: it's because |shortname= only applies to the value, not its qualifiers:
  • -> {{wdib |ps=1 |P369 |qid=Q15397819}} →
  • -> {{wdib |ps=1 |P369 |qid=Q15397819 |shortname=t}} →
I've now added a parameter |qshortname= (alias |qsn=):
  • {{#invoke:WikidataIB|getValue|1=P2044|2=|qid=Q15397819|qual=P459|qualsonly=Y|qshortname=true|ps=1}} →
Hope that helps. --RexxS (talk) 18:28, 9 May 2020 (UTC)
Thank you, RexxS. Works like a charm! Rehman 02:09, 10 May 2020 (UTC)

Getting the nth value and the last value

Hi RexxS. Suppose we have a list of values: 

{{#invoke:WikidataIB |getValue |ps=1 |P8011 |qid=Q84055514}}
579,957, 625,309, 716,733, 770,764, 830,201, 902,654, 976,363, 1,046,450, 1,107,233, 1,191,946, 1,276,781, 1,357,413, 1,437,788, 1,523,213, 1,609,037, 1,673,688, 1,759,579, 1,854,250, 1,947,041, 2,039,952, 2,134,277, 2,227,642, 2,302,792, 2,404,267, 2,512,388, 2,615,920, 2,719,434, 2,834,798, 2,943,421, 3,033,591, 3,126,119, 3,242,160, 3,362,136, 3,483,838, 3,611,599, 3,737,027, 3,837,207, 3,966,075, 4,103,233, 4,242,718, 4,386,379, 4,524,317, 4,666,386, 4,774,434, 4,916,116, 5,061,332, 5,213,140, 5,363,445, 5,507,182, 5,658,614, 5,774,133, 5,921,069, 6,084,256, 6,249,668, 6,426,627, 6,616,496, 6,807,226, 6,950,493, 7,137,716, 7,352,911, 7,560,782, 7,776,228, 7,996,707, 8,227,802, 8,398,362, 8,608,654, 8,826,585, 9,056,173, 9,297,749, 9,540,132, 9,789,066, 9,969,662, 10,211,092, 10,473,771, 10,740,832, 11,024,491, 11,307,002, 11,587,153, 11,806,256, 12,092,503, 12,412,664, 12,739,490, 13,072,718, 13,433,742, 13,791,869, 14,047,908, 14,381,303, 14,724,546, 15,075,369, 15,428,170, 15,849,068, 16,291,331, 16,806,803, 17,334,885, 17,743,740, 18,190,382, 18,832,970, 19,358,659, 19,821,831, 20,202,858, 20,864,750, 21,484,402, 22,149,351, 22,788,393, 23,387,171, 24,106,535, 24,583,558, 25,281,848, 26,015,297, 26,845,688, 27,694,416, 28,563,095, 29,309,703, 30,041,400, 30,941,264, 31,742,782, 32,661,252, 33,467,237, 34,491,073, 35,292,220, 35,902,137, 36,827,520, 37,651,512, 38,576,510, 39,477,848, 40,406,609, 41,461,636, 42,307,914, 43,324,834, 44,337,201, 45,509,380, 46,679,145, 47,738,491, 48,831,145, 49,551,507, 50,650,128, 51,804,677, 52,934,433, 54,097,975, 55,189,226, 56,260,928, 57,239,428, 58,312,273, 59,429,115, 60,565,728, 61,572,343, 62,454,254, 63,661,060, 64,392,594, 65,325,779, 66,279,462, 67,436,031, 68,928,440, 70,269,975, 71,257,836, 71,967,230, 73,110,041, 74,196,729, 75,619,781, 76,717,728, 77,850,403, 78,992,534, 79,982,394, 81,071,797, 82,271,654, 83,465,975, 84,634,680, 85,798,698, 86,877,242, 87,872,093, 88,945,107, 90,090,122, 91,226,305, 92,254,927, 93,254,017, 94,224,190, 95,083,976, 96,116,771, 97,200,379, 98,670,363, 100,113,085, 101,382,564, 102,523,469, 103,462,778, 104,420,894, 105,487,680, 106,563,440, 107,728,088, 108,796,064, 109,887,303, 110,743,103, 111,789,350, 112,998,959, 114,208,384, 115,429,095, 116,542,304, 117,736,791, 118,572,192, 119,615,857, 120,769,151, 121,962,509, 123,101,739, 124,031,230, 124,836,819, 125,698,525, 126,542,907, 127,480,186, 128,508,389, 129,591,786, 130,657,808, 131,733,134, 132,582,730, 133,682,275, 134,841,307, 135,931,545, 137,062,749, 138,220,354, 139,503,803, 140,379,976, 141,349,298, 142,445,949, 143,557,647, 144,727,749, 145,885,512, 146,986,575, 147,787,656, 148,814,055, 149,836,767, 150,759,726, 151,632,223, 152,697,399, 153,711,833, 154,566,990, 155,560,655, 156,646,280, 157,805,240, 158,918,646, 160,090,514, 161,198,195, 162,098,329, 163,170,557, 164,268,721, 165,308,366, 166,305,762, 167,159,289, 168,102,657, 168,818,054, 169,801,749, 170,922,030, 172,049,274, 173,111,694, 173,941,658, 174,899,783, 175,635,761, 176,531,997, 177,463,405, 178,400,995, 179,336,364, 180,253,315, 181,096,622, 181,755,831, 182,652,887, 183,489,114, 184,232,305, 184,962,401, 185,765,491, 186,544,868, 187,093,036, 187,802,827, 188,566,947, 189,347,782, 190,148,024, 190,985,119, 191,766,871, 192,337,117, 193,062,694, 193,613,120, 194,338,773, 195,081,079, 195,837,408, 196,588,372, 197,092,635, 197,752,057, 198,473,178, 199,216,019, 199,931,795, 200,672,589, 201,368,378, 201,900,614, 202,587,752, 203,324,655, 204,023,840, 204,789,784, 205,533,389, 206,230,512, 206,716,634, 207,332,298, 207,977,229, 208,703,791, 209,474,862, 210,261,480, 210,931,530, 211,551,746, 212,230,431, 213,036,275, 213,829,658, 214,661,465, 215,435,383, 216,231,106, 216,858,774, 217,618,057, 218,403,277, 219,178,908, 219,940,742, 220,692,677, 221,430,507, 221,968,271, 222,716,796, 223,479,877, 224,258,293, 224,998,638, 225,839,273, 226,703,641, 227,407,413, 228,280,763, 229,249,784, 230,313,163, 231,370,546, 232,431,517, 233,565,119, 234,445,774, 235,413,233, 236,438,861, 237,503,882, 238,604,638, 239,769,553, 240,950,842, 241,864,161, 242,650,025, 243,672,940, 244,798,621, 245,912,587, 246,959,192, 248,125,908, 249,019,657, 250,231,269, 251,439,598, 252,677,379, 254,041,584, 255,214,803, 256,626,850, 257,806,986, 259,207,108, 260,618,866, 262,003,415, 263,476,625, 264,972,022, 266,538,416, 267,894,549, 269,414,035, 271,053,392, 272,705,103, 274,445,653, 276,199,222, 277,918,810, 279,321,177, 280,979,877, 282,703,789, 284,471,979, 286,392,086, 288,337,385, 290,142,339, 291,647,037, 293,310,779, 294,852,078, 296,775,209, 298,601,699, 300,410,043, 302,275,471, 303,750,077, 305,600,187, 307,583,991, 309,448,585, 311,324,100, 313,017,193, 314,850,143, 316,423,658, 318,292,881, 320,301,177, 322,356,187, 324,417,870, 326,484,155, 328,607,937, 330,536,064, 332,594,176, 334,811,496, 336,969,353, 339,039,861, 341,119,909, 343,183,748, 344,866,883, 346,792,257, 350,057,330, 353,782,648, 357,433,846, 361,174,142, 364,746,522, 366,334,111, 368,207,596, 370,193,563, 372,198,253, 374,242,384, 376,232,162, 378,132,474, 379,624,626, 381,375,984, 383,306,971, 385,238,220, 387,167,696, 389,207,637, 391,019,083, 392,407,782, 394,072,142, 395,973,198, 397,832,667, 399,568,448, 401,819,892, 404,265,101, 406,371,279, 408,139,287, 410,100,044, 412,021,494, 414,251,520, 416,416,463, 418,254,953, 419,777,457, 421,424,881, 423,332,097, 425,225,897, 427,016,605, 429,041,970, 430,885,470, 432,317,813, 434,058,138, 435,973,639, 438,011,958, 440,023,239, 442,021,954, 443,958,663, 445,422,256, 447,341,133, 449,193,273, 450,911,712, 452,939,545, 454,570,811, 456,289,567, 457,444,011, 459,164,121, 460,900,978, 462,629,773, 464,650,723, 466,427,038, 468,216,510, 469,645,494, 471,294,789, 473,142,307, 474,893,363, 476,533,650, 478,316,964, 480,039,185, 481,767,232, 483,278,545, 485,056,507, 487,370,196, 523,184,293, 528,240,038, 553,621,766

To get the nth value, you have previously recommended the following solution: 

{{#invoke:String2 |split |txt={{#invoke:WikidataIB |getValue |ps=1 |P8011 |qid=Q84055514}} |sep=", " |idx=3}}
716,733

Later you have introduced {{stringsplit}} and {{wdib}} templates to simplify the task: 

{{stringsplit |txt={{wdib|ps=1|P8011|qid=Q84055514}} |sep=", " |idx=3}}
716,733

Which, of course, is better written as: 

{{stringsplit|{{wdib|ps=1|P8011|qid=Q84055514}}|", "|3}}
716,733

I have come up with an even better, more natural way of writing it using the list parameter and {{pn}} templates:

{{wdib|ps=1|P8011|qid=Q84055514|list=p3}}

Unfortunately, there is no good analogue to get the last value. There's {{lastbut0}}, but it is not used anywhere and has a very inefficient implementation that stops working if the list has more than a hundred items: 

{{{100|{{{99|{{{98|{{{97|{{{96|{{{95|{{{94|{{{93|{{{92|{{{91|{{{90|{{{89|{{{88|{{{87|{{{86|{{{85|{{{84|{{{83|{{{82|{{{81|{{{80|{{{79|{{{78|{{{77|{{{76|{{{75|{{{74|{{{73|{{{72|{{{71|{{{70|{{{69|{{{68|{{{67|{{{66|{{{65|{{{64|{{{63|{{{62|{{{61|{{{60|{{{59|{{{58|{{{57|{{{56|{{{55|{{{54|{{{53|{{{52|{{{51|{{{50|{{{49|{{{48|{{{47|{{{46|{{{45|{{{44|{{{43|{{{42|{{{41|{{{40|{{{39|{{{38|{{{37|{{{36|{{{35|{{{34|{{{33|{{{32|{{{31|{{{30|{{{29|{{{28|{{{27|{{{26|{{{25|{{{24|{{{23|{{{22|{{{21|{{{20|{{{19|{{{18|{{{17|{{{16|{{{15|{{{14|{{{13|{{{12|{{{11|{{{10|{{{9|{{{8|{{{7|{{{6|{{{5|{{{4|{{{3|{{{2|{{{1|no input}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}

May I ask you to please create {{p-1}} that would return its last unnamed parameter? Then we would be able to write: 

{{wdib|ps=1|P8011|qid=Q84055514|list=p-1}}

And stop worrying about {{stringsplit}}'s separators potentially clashing with data. Thank you. — UnladenSwallow (talk) 02:39, 15 May 2020 (UTC)

@UnladenSwallow: That's a neat idea. I had forgotten that the list parameter actually pipes the output through an arbitrary template.
We already have support for negative indices in {{stringsplit}}:
  • {{stringsplit|{{wdib|ps=1|P8011|qid=Q84055514}}|", "|-1}} → 553,621,766
But I like the idea of a utility that returns a given parameter from a list of those provided, so I've created Module:Pn to return a given positional parameter, and Template:P-1 as you requested. The module can generate as many wrappers as desired simply by supplying an index. For example, setting idx=-2 would make a template {last but one}, etc. Check to see if the behaviour is what you want (I've arbitrarily set idx=0 and any idx beyond the number of parameters to return the last one). Do you think indices outside the range should return nothing instead? Cheers --RexxS (talk) 18:21, 15 May 2020 (UTC)
@RexxS: You're awesome! Thank you! Now I will be able to greatly simplify Indian rows in Template:COVID-19 testing by country subdivision.
Yes, indices outside the range should definitely return nothing. For example, if we have a custom 3-column table for displaying a 3-value property, but a certain Wikidata item only has two values for that property, we want the third table cell to be empty, not repeat the second value.
Also, {{wdib|…|maxvals=n|list=p-1}} can now be used to get the nth value for any n. Is it okay if I add this to {{wdib}}'s documentation? — UnladenSwallow (talk) 20:22, 15 May 2020 (UTC)
@UnladenSwallow: I've made the changes to return nothing if idx=0 or idx>(number of parameters). The only default behaviour left is when idx has a value that can't be recognised as a number (when it returns the first value). You can edit the documentation freely; it's not protected, and I have no feelings of ownership over it.
I've just realised that wdib may return an empty list, so it's better not to throw an error in Module:Pn, but just gracefully return nothing. --RexxS (talk) 21:22, 15 May 2020 (UTC)

Tracking function

Template:Track fallback is a newly created template which I recently came across. Does it makes sense to integrate this within WikidataIB so that it can be used with more complex calls? I'm not sure if such a function/template already exists though. Just posting here for better visibility. Rehman 07:49, 6 May 2020 (UTC)

@Rehman: I've just added a logic table to the template's documentation so folks can see what outputs they can get, and how to get them. It would probably benefit from being re-written in Lua to improve the logic, but I don't think it should be subsumed into WikidataIB, as it presently can make a call to any module and I don't want to disturb that option. --RexxS (talk) 21:14, 6 May 2020 (UTC)
Thank you RexxS! Rehman 23:54, 6 May 2020 (UTC)

Feature request

Hello RexxS. I'm currently working on getting {{Infobox mountain}} on track for a Wikidata-enabled future. In order to support this, one of the WikiProject members require all articles which does not have a local value and uses a value from Wikidata, to be added to a tracking category, for each parameter separately. If you look at Template:Infobox mountain/sandbox (parameter parent_peak, for example) , you can see that it is possible to do this, but still a bit manual and messy.

Would it be possible to add a |track=true function to this module, such that if the above condition is met, the article would simply be added to a generic category:

  • [Template name] using Wikidata value for [parameter name based on |name=] (example)

The categories are of course temporary, and once the necessary checks are done, |track=true could simply be removed from {{Infobox mountain}}. Would it be possible to implement this? Rehman 15:27, 9 May 2020 (UTC)

Sorry, Rehman but I think that's the wrong logic for doing checks. No infobox should become wikidata-enabled without consensus to do so. Most infoboxes need to be opt-in, that is, editors have to enable the wikidata functionality on an article-by-article basis by adding |fetchwikidata=all in each article. That ensures that the display of the infobox is checked by an editor, who takes the blame if the infobox contains erroneous information. If they want to add a tracking category at the same time, that's fine, but I don't want to repeat the unpleasant time I endured at Wikipedia:Village pump (policy)/Archive 128 #RfC: Wikidata in infoboxes, opt-in or opt-out?. I think my comment at the time is just as relevant now:

... the problem may arise if a normal infobox is changed (I'd say upgraded) to a Wikidata-enabled infobox. At that point, the display in each article using the infobox has the potential to draw in additional information from Wikidata without that additional information showing on the watchlists containing those articles (subsequently, any changes to Wikidata will show on watchlists as D and will be spotted). The problem can only happen if the infobox implements a scheme where it fetches Wikidata for fields that are not already filled-in an article - the so-called "opt-out" scheme. Most of the time it is likely to be something obscure like an OCLC number that nobody will worry about, but Sarah gives an example of where she had deliberately omitted the genre field as problematic, but the Wikidata-enabled infobox re-inserted it without warning. It's a genuine concern, but banning 'opt-out' schemes wholescale in response is using a sledgehammer on a walnut. Infobox template editors will need to implement fetching Wikidata values carefully when they upgrade infoboxes. Where the number of transclusions is small, it should be sufficient to monitor the effect on the affected articles, so using an 'opt-out' template should be manageable. Where the number of transclusions is larger, I'd recommend using a more flexible implementation, for example like the demo at Template:Infobox book/Wikidata/Sandbox, which only fetches Wikidata when that is specifically enabled on an article-by-article basis by adding a |fetchwikidata=parameter. Since that also allows fetching Wikidata on a field-by-field basis, if required, it should enable editors to make use of it in their articles in the manner they choose. The bonus is that it can also suppress any field(s) with a |suppressfields=, so Sarah could explicitly ensure that 'genre' was never displayed in Night (book) by adding |suppressfields=genre.

It's a huge debate, but it demonstrates the misconceptions and the issues that face anyone wanting to make Wikidata-aware infoboxes on Wikipedia. --RexxS (talk) 17:01, 9 May 2020 (UTC)
Thanks for taking the time to explain this, RexxS. Yes, it makes sense. We have consensus, but tracking and article-by-article checks is requirement. I will take your comment regarding trackers back to discussions, and see how it goes. Before I do that, I have one more question. From above, it seems like we are still in a deadlock in terms of tracking "which articles don't have a local value and thus uses/would use a Wikidata value".
While |fetchwikidata=NONE is set on the infobox as the default (as a start), would it be possible to add the above tracker without showing Wikidata values? We could then look up that tracking category, check the Wikidata contents of an article (although it is not displaying wd values yet), then add |fetchwikidata=ALL to the article. Once all articles in that tracking category is checked, we can remove |track=true and change the default for that particular parameter in the template to |fetchwikidata=ALL. The |fetchwikidata=ALL in the articles can be left as it is (as it now does nothing) and removed casually. What do you think? Rehman 02:07, 10 May 2020 (UTC)
I'll be as clear as I can, Rehman. I don't accept that Module:WikidataIB is the right place to do field-by-field tracking, nor that such tracking is a reasonable prerequisite for enabling Wikidata in infoboxes. I've already put a lot of effort into creating a mechanism that can ensure every deployment is checked, and I won't spend any time in changing the module to meet unnecessary demands. Anyone is free to get consensus to make changes, or to fork their own version that works the way they want it to, of course.
The alternative to the tracker scheme is to use a Wikidata-enabled infobox where the template is coded like this: | fwd = {{{fetchwikidata|}}} | spf = {{{suppressfields|}}} in every call to WikidataIB. In each article to be checked, it is only necessary to add | fetchwikidata = ALL to the infobox, thus enabling Wikidata for the entire infobox, and previewing it. Any unwanted fields can be suppressed or a local value substituted before saving. That achieves exactly the same result without the complication of tracking. There are no downsides to working like that. --RexxS (talk) 21:30, 10 May 2020 (UTC)
I hear you, RexxS. I'm not a fan of such trackers myself, and I only ask as it seems to be the key requirement of a WikiProject editor, before I am allowed to enable Wikidata there. The solution you suggested above works, but the problem I'm trying to address is slightly different. Please do correct me if I'm not following you correctly.
{{Infobox mountain}} is used by roughly 25,000 articles (via local parameters). Only a maximum of roughly 1,500 articles have local values missing and have the corresponding properties populated on Wikidata (i.e. 1,500 articles will display a Wikidata value in a given parameter if Wikidata is enabled, as there is no local value stated currently), the rest of the articles have assigned local values and/or barely has any data populated on Wikidata.
So instead of going through all 25,000 articles and enabling them by adding |fetchwikidata=ALL (which cause no change to about 23,500), I'm looking for a way to track articles that would use Wikidata before actually enabling Wikidata, and apply the |fetchwikidata=ALL for those only, before actually enabling Wikidata as default at the infobox-level (we have consensus for this).
Please let me know if you feel that I'm looking to solve this problem in the wrong way, or if you know of any solution to this without amending the module. The discussion at the mountain infobox is still ongoing, so I'm simply getting things clarified here before commenting there. Kind regards, Rehman 02:46, 11 May 2020 (UTC)
@Rehman: It's going to take you a long time to check 1,500 articles. If I had to have a tracking category, my solution would be to code the it into a temporary version of the template, of course, something like:
{{#if:{{{paraname|}}}|{{{paraname}}} | | {{#if:{{wdib|...}} | [[Category:Wikidata value available for paraname]] }} }}
whenever you would normally use
{{wdib|... |paraname}}
You are still going to have to check and apply |fetchwikidata=ALL for the other 23,500 articles before you return the template to its non-tracking version, though. --RexxS (talk) 17:17, 11 May 2020 (UTC)
@Rehman: I've thought about this some more. I could simply add a parameter that would contain text to be returned instead of whatever is returned from Wikidata. That would have a general functionality, rather than a narrow use. --RexxS (talk) 18:33, 11 May 2020 (UTC)
@Rehman: New parameter |replacetext= (alias |rt=) I've set this up in Module:WikidataIB/sandbox:
highest point (P610)
elevation above sea level (P2044)
  • {{wdib/sandbox |ps=1 |P2044 |qid=Q1286}} →
  • {{wdib/sandbox |ps=1 |P2044 |qid=Q1286 |rt=}} →
  • {{wdib/sandbox |ps=1 |P2044 |qid=Q1286 |rt=[[:Category:Wikidata available for elevation]]}} →
location map (P1943)
  • {{wdib/sandbox |ps=1 |P1943 |qid=Q1286}} →
  • {{wdib/sandbox |ps=1 |P1943 |qid=Q1286 |rt=}} →
  • {{wdib/sandbox |ps=1 |P1943 |qid=Q1286 |rt=[[:Category:Wikidata available for location map]]}} →
Optionally you could just use something like Category:Wikidata available for Infobox mountain. If that does what you want, I can update the main module to implement the functionality. --RexxS (talk) 19:01, 11 May 2020 (UTC)
Yes a broader feature such as above is definitely a much better approach than what I proposed. After testing the above for parent_peak/parent peak (P3137) at Template:Infobox mountain/sandbox by {{Infobox mountain/sandbox|qid=Q15397819|parent_peak=abc}} it seems like the only bug is that the pen icon (alone) is still displayed when the text is replaced and no local value is present, other than that, it works great. Using a single tracking category also makes a lot of sense, in the way that we don't have to visit the same article over and over for different parameters. I will pass these to the discussion there. Please do go ahead and enable this when you feel it's ready. Thank you for this, RexxS. Rehman 02:24, 12 May 2020 (UTC)
Would it make sense/be possible to ignore |fetchwikidata= if |replacetext= is non-blank? This would allow me do run the code as follows:
  • {{#invoke:WikidataIB/sandbox|getValue|1=P3137|2={{{parent_peak|}}}|name=parent_peak|qid={{{qid|}}}|rank=best|fetchwikidata={{{fetchwikidata|NONE}}}|suppressfields={{{suppressfields|none}}}|onlysourced={{{onlysourced|no}}}|replacetext={{#ifeq:{{{fetchwikidata|}}}|ALL||[[Category:Wikidata available for Infobox mountain]]}}}}
Allowing the person(s) checking and enabling Wikidata to simply add |fetchwikidata=ALL once the check is done, while reducing a lot of code. What do you think? Rehman 04:06, 12 May 2020 (UTC)
@Rehman: I've moved the replacement to the output module so that the replacetext also replaces the pen icon.
The above will work for all the usual functions. I've only set |fetchwikidata=ALL when replacetext exists in getValue, but that should still find almost all of the articles for you.
You'll still have to have two versions of the infobox template available, I think. One will need |replacetext=[[Category:Wikidata available for Infobox mountain]] coded in to each call, which will replace the current infobox template and generate the list of articles in the category. Then you'll need a second version without replacetext, so that you can use it in each article for checking what is actually returned from Wikidata when you add |fetchwikidata=ALL to the article. After you've finished all of the checking, you can simply replace the tracking version of the template with the second version. Cheers --RexxS (talk) 17:59, 12 May 2020 (UTC)
Many thanks for this. This should do, I will test the new version and confirm again. I think two versions are not needed as I plan to add:
  • |replacetext={{#ifeq:{{{fetchwikidata|}}}|ALL||[[Category:Wikidata available for Infobox mountain]]}}
So after checking a particular article, the checker simply adds |fetchwikidata=ALL, which enables Wikidata and removes the category at the same time. And once all checks are done (the category is empty), we simply remove |replacetext= from the infobox. Cheers, Rehman 02:33, 13 May 2020 (UTC)
RexxS, I've tested the above. In terms of functionality it now works well. There is a bug though, but I'm not sure if its coming from Module:WikidataIB/sandbox or Template:Infobox mountain/sandbox. If we preview {{Infobox mountain/sandbox|qid=Q15397819}}, you will see that "Parent peak" shows a blank value. Would you know what is causing that? Rehman 06:24, 13 May 2020 (UTC)
@Rehman: You'll still need two versions, of course, but if you use your coding, you don't need them at the same time. That's fine. The blank field is as expected, and it's because Module:Infobox "sees" the category string as a field value (not a blank value), so it creates the field label for it. That's the problem with using the module to return the category, rather than coding it into the template. --RexxS (talk) 11:25, 13 May 2020 (UTC)
Oh :( I'm not too sure if there is a way around this, but I have posted at Module talk:Infobox to see if something can be done. This is too bad. A feature of this sort would surely come in handy with the "onboarding process" of infoboxes not yet with Wikidata support. Rehman 12:51, 13 May 2020 (UTC)

Thanks for helping at Module talk:Infobox. I'm very glad we now have this feature. I've did some more tests, and everything now seems to work seamlessly. When you're ready, could you move the WikidataIB code from sandbox to live please? Cheers, Rehman 03:40, 14 May 2020 (UTC)

 Done --RexxS (talk) 19:29, 14 May 2020 (UTC)
Thank you RexxS. Not sure if this is due to the above change, but there seems to be a bug in the main functions:
  • {{#invoke:WikidataIB|getValue|1=P2660|qid=Q15397819|rank=best|fetchwikidata=all|suppressfields=none|onlysourced=no|noicon=true}} →
  • {{#invoke:WikidataIB|getValue|1=P2660|qid=Q15397819|ps=1}} →
I'm not able to trace the cause of it though... Rehman 05:25, 15 May 2020 (UTC)
@Rehman: |fetchwikidata=all doesn't work - it would whitelist just a field called "all" because field names are case specific. Use |fetchwikidata=ALL.
|suppressfields=none doesn't work - it would blacklist just a field called "none". Usually that makes no difference, except that any value for |suppressfields= requires a |name= parameter so that it knows the name of the field it has to check on the blacklist. The same goes for |fetchwikidata= when it has any value other than "ALL", when it needs to know the field name to check on the whitelist.
  • {{#invoke:WikidataIB |getValue |1=P2660 |qid=Q15397819 |rank=best |fetchwikidata=ALL |onlysourced=no |noicon=true}} →
  • {{#invoke:WikidataIB |getValue |1=P2660 |qid=Q15397819 |rank=best |fetchwikidata=ALL |onlysourced=no |suppressfields=field1 |noicon=true |name=prominence}} →
  • {{#invoke:WikidataIB |getValue |1=P2660 |qid=Q15397819 |rank=best |fetchwikidata=field1, field2, prominence |onlysourced=no |noicon=true |name=prominence}} →
  • {{#invoke:WikidataIB |getValue |1=P2660 |qid=Q15397819 |rank=best |fetchwikidata=field1, field2, prominence |onlysourced=no |noicon=true}} →
  • {{#invoke:WikidataIB |getValue |1=P2660 |qid=Q15397819 |rank=best |fetchwikidata=ALL |onlysourced=no |suppressfields= |noicon=true |name=}} →
In the cases where the name parameter is missing (other than when |fetchwikidata=ALL), the call will always return empty. --RexxS (talk) 15:42, 15 May 2020 (UTC)
I'm quite certain these basic calls didn't work yesterday even when I tried uppercase. Probably a glitch/lag somewhere, or just me having a moment. I've gone ahead and changed all sandbox instances to uppercase anyway, in case it was me missing something. Thank you for explaining! Cheers, Rehman 04:15, 16 May 2020 (UTC)

Image captions

Hello. Any suggestions on getting accurate image captions? I'm aware of the old {{#invoke:Wikidata|getImageLegend|FETCH_WIKIDATA}}, but Module:Wikidata is outdated and the output isn't accurate when there are multiple images.

I tried to put together something like {{#invoke:WikidataIB|getQualifierValue|P18|pval={{#invoke:WikidataIB|getValue|P18|qid=Q15397819|ps=1|maxvals=1}}|qual=P2096|qid=Q15397819|ps=1|maxvals=1}}, but that of course didn't work. Rehman 06:49, 8 May 2020 (UTC)

The call I'm currently using to do this (in commons:Template:Wikidata Infobox) is {{#invoke:WikidataIB |getValue | rank=best |P18 |qid={{#invoke:WikidataIB |getQid |qid={{{qid|}}} }} |fwd={{{fwd|ALL}}} |osd=no |noicon=y |qual=P2096 |qualsonly=yes | maxvals=1}}. Thanks. Mike Peel (talk) 07:40, 8 May 2020 (UTC)
Thanks Mike Peel. Just what I was looking for! Cheers, Rehman 07:49, 8 May 2020 (UTC)

Mike Peel, would you know if the Commons caption saved as structured data could be made use of if a caption on Wikidata is missing? Or even vice versa, if the Commons caption could be prioritised if preferred? Rehman 13:16, 16 May 2020 (UTC)

No idea, sorry. You can access Commons captions on Commons using WikidataIB and the media files M-id, but I've never tried outside of Commons. Thanks. Mike Peel (talk) 13:18, 16 May 2020 (UTC)
Thanks Mike. It would be nice if that is implemented in the future, especially considering Commons files themselves have useful machine-readable captions. Cheers, Rehman 13:26, 16 May 2020 (UTC)

Qualifiers

I've done a fairly significant re-write of how qualifiers are handled. The effects are to allow DATES to be mixed with other parameters; to process start time (P580) and end time (P582) separately, so they are always last in the list of qualifiers rendered (and use ndashes, regardless of the value of qsep); and to clean up the code internally, reducing recalculation of certain objects every time a loop is iterated. I've tested as many cases as I can think of, but there may still be issues that require the code to be rolled back while they are sorted out. --RexxS (talk) 15:03, 13 June 2020 (UTC)

Infoboxes still using Template:Wikidata

According to "What links here", the following infoboxes are still using {{Wikidata}} and may benefit from conversion to Module:WikidataIB:

According to "What links here", the following infoboxes are still using {{Wikidata}} and may benefit from conversion to Module:WikidataIB:

It seems likely that some of these templates are pulling unsourced data from Wikidata into infoboxes. – Jonesey95 (talk) 20:01, 1 July 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:WikidataIB/Archive_6&oldid=1019634054"