Module talk:Wikidata/Archive 2

Archive 1

Archive 2

Icon to indicate no Wikipedia article

When a value is fetched from Wikidata that has a corresponding entry on Wikidata, but no article (yet) on Wikipedia, this module supplies a link to the Wikidata entry and a marker that indicates "Article is not yet available in this wiki" when hovered over. Even though Wikidata is a sister project and links there can use the wiki-markup for an internal link, e.g. [[d:Q151973]], the argument has been made that when following a link, readers don't expect to be redirected to different project without warning.

At a discussion at Template talk:Infobox video game #Ugly "page missing" buttons, there was a suggestion to use the external links icon instead of the present [*] marker. I've made a version in Module:Wikidata/sandbox2 using the icon. This is the comparison for the occupation (P106) of Richard Burton (Q151973):

• Module : film actor, diarist, stage actor, actor, film director, film producer, producer[*], director
• Sandbox: film actor, diarist, stage actor, actor, film director, film producer, producer , director

In the sense that a link to Wikidata is unexpected here, and it may therefore be considered an "external" link, is the external links icon a suitable indicator? In my opinion, it's aesthetically more pleasing, but other opinions would be very welcome. --RexxS (talk) 20:58, 13 August 2016 (UTC)

While external link might not be the BEST icon, it looks a lot more natural to me than the [*]. -- ferret (talk) 21:39, 13 August 2016 (UTC)

The icon does look better than the asterisk, but I'm not sure it's the right icon to use since links to Wikidata aren't external... Maybe a small Wikidata symbol? Thanks. Mike Peel (talk) 13:55, 14 August 2016 (UTC)

That's what I was inclined to, as well. Alternatively, "WD" in plaintext, or perhaps "D"... either way, needs a span with a title attribute to indicate our intentions with the link. --Izno (talk) 14:10, 14 August 2016 (UTC)

You would prefer a <span>...</span> with a title attribute rather than the <abbr>...</abbr> with a title attribute that I'm using now? --RexxS (talk) 17:05, 14 August 2016 (UTC)

It's not an abbreviation? I'd have to go look at the html 5 spec on the point. Span seemed better off the cuff. --Izno (talk) 19:19, 14 August 2016 (UTC)

Neither https://www.w3.org/wiki/HTML/Elements/abbr nor https://www.w3.org/TR/html5/text-level-semantics.html#the-abbr-element are very specific. My logic was that a marker like "WD" would be an abbreviation semantically and literally and we could clearly use <abbr>...</abbr>; whereas if "WD" were replaced by an icon, it couldn't change the semantics - the icon would still be the element being 'expanded' (even if no longer literally). I'm always loathe to use <span>...</span> unless its inner-html really has no semantic value. Must be just how my antediluvian mind works. --RexxS (talk) 22:05, 14 August 2016 (UTC)

I'm generally agreed, but in my mind the title attribute on the tag should be a call to action e.g. "edit on Wikidata", which is not "WD"'s expansion, and thus abbr becomes the wrong tag to use, according to 2 of the three areas of use (the third not being relevant here since we aren't interested in the consistent abbreviation styling). Izno (talk) 01:41, 15 August 2016 (UTC)

I think we may be at cross-purposes. The point of these markers is not to get people to edit Wikidata. It is to warn readers who may otherwise click on the link thinking they were going to a Wikipedia article on e.g. satiric novel and finding themselves on another site (i.e. Wikidata) at satirical novel (Q6045975). I've actually had that complaint levelled when we were using just an asterisk as a marker. There was a small consensus early on that it was good to have the link to the Wikidata item whenever there was no corresponding Wikipedia article, but I'm beginning to wonder whether it's worth the effort. I was thinking of changing the tool-tip to "Article is available on Wikidata, but not on Wikipedia", which would be more accurate. What do you think? --RexxS (talk) 07:56, 15 August 2016 (UTC)

Yes, that's why I stated my expectation, because I was pretty sure we were too. :D I'm fine with your proposed title text, but that's certainly not abbr content. --Izno (talk) 11:24, 15 August 2016 (UTC)

Little edit tags

A little off-topic

Animal Farm Author George Orwell  Pages 92  It's a little off-topic, but it's worth pointing out that the French Wikipedia put little edit tags next to values from Wikidata, see e.g. fr:South Pole Telescope. They do that for all values drawn from Wikidata, which looks a little cluttered to me, but might be worth thinking about here too. Thanks. Mike Peel (talk) 06:20, 15 August 2016 (UTC) @Mike Peel: That idea was shamelessly stolen some time ago: see Module:WikidataIB. --RexxS (talk) 07:56, 15 August 2016 (UTC)

Status

Where do we sit on this? This is a relatively impactful change to Module:Wikidata and hits every infobox that has implemented it. I am currently in support of the external link icon, versus the current [*]. The technical discussions on the exact tag mechanism is above the basic decision on whether to switch or not. Let's do it. Where else should this be advertised? -- ferret (talk) 14:22, 19 August 2016 (UTC)

That's a tough question. I don't think we could notify every Wikiproject that uses an infobox. However, there are currently 189 infoboxes in the Category:Templates using data from Wikidata, so it may be possible to pick out a number of active WikiProjects that already use the module. In any case, we should put a notice at WP:VPT and maybe at WP:CENT, if it was thought that far-reaching. Optionally we could create an WP:RFC here, if there were a well-defined choice that we could poll on. --RexxS (talk) 18:46, 19 August 2016 (UTC)

I think this [*] is ridiculous. Why stop there? Why not mark everything is not there? For instance, mark "everything" which isn't blue. 213.205.251.75 (talk) 10:54, 14 September 2016 (UTC)

The mad [*] are strange and useless. If you can't remove them, the least to do is to have the marks as optional. Alice 张梦平 10:14, 29 September 2016 (UTC)

Of course we could remove them. But then what would you do about all of the folks who would be complaining that they followed a link and it took them to Wikidata? The indicators are not useless, because they perform the function of alerting readers to the fact that a link is available to the subject on Wikidata, but not on Wikipedia. It's easy to whine about what you don't like, but I don't see any constructive suggestions on how we might best do that job. --RexxS (talk) 16:29, 29 September 2016 (UTC)

How about using - would that work? Thanks. Mike Peel (talk) 18:49, 29 September 2016 (UTC)

I've made a version in Module:Wikidata/sandbox3 using the Wikidata-logo, with span instead of abbreviation and an expanded tool-tip. This is the comparison for the occupation (P106) of Richard Burton (Q151973):

• Module  : film actor, diarist, stage actor, actor, film director, film producer, producer[*], director
• Sandbox2: film actor, diarist, stage actor, actor, film director, film producer, producer , director
• Sandbox3: film actor, diarist, stage actor, actor, film director, film producer, producer , director

What do folks think? --RexxS (talk) 19:19, 29 September 2016 (UTC)

Sorry for the late reply. I dig sandbox3. I might suggest the alt text read "Information available on.." rather than "Article available on..." -- ferret (talk) 22:30, 12 October 2016 (UTC)

getValue not handling no value claims correctly

On Wikidata, there are 3 different types of values for claims (technically, they are called "snak types"): no value, unknown value, and custom value. Currently if the value type is set to "custom value" (i.e. snaktype == "value"), getValue returns the actual value that is set (which makes sense). However, if the value type is set to "no value" (i.e. snaktype == "novalue"), getValue returns the string "no value", which isn't really helpful. Ideally it should return an empty string instead so that calls to getValue can be used intuitively in #if statements and elsewhere. It should probably do the same for unknown values. For an example of a "no value" claim, see the country claim at South Pole. The purpose of a "no value" claim is to affirm that no value exists, e.g. "The South Pole belongs to no country." Kaldari (talk) 00:43, 12 October 2016 (UTC)

@Kaldari: I'm not sure if "correctly" is the right description. When claims[1].mainsnak.snaktype contains "value", the function does its job of constructing a list of linked values. When claims[1].mainsnak.snaktype contains anything else, the function returns entity:formatPropertyValues(propertyID).value, which is a call available in the Wikibase API to return the best value, formatted. So from that point of view, it's the "correct" value that the developers designed in.

Nevertheless, I've created a version in Module:Wikidata/sandbox that traps a snaktype of "novalue" and returns nil. If you paste {{#invoke:Wikidata/sandbox|getValue|P17|FETCH_WIKIDATA}} into South Pole and preview it, you'll see that it returns nothing (as opposed to {{#invoke:Wikidata|getValue|P17|FETCH_WIKIDATA}}, which returns "no value").

Sadly, I've been told that I have to get consensus before making any changes to this module, so I'm no longer actively developing it, because of the sheer bureaucracy involved in waiting weeks to see if anybody bothers to comment even on small changes like this.

As we only have consent to use Wikidata in infoboxes, wouldn't it be just as easy to test for "no value" (rather than nil) if you want to display something like "Country none" in cases like South Pole? --RexxS (talk) 17:08, 12 October 2016 (UTC)

A problem with Wikidata is that there is no practical way to test the effect of a change like that. Indeed, a change could conceivably cause an infobox on an obscure article to show something wrong (perhaps due to bad design of a template), and no one would ever know. Special:ExpandTemplates allows the title of the page to be specified, and that appears to work, but automating that to build a thousand test cases would be monumentally difficult. At any rate, my vote would be to return an empty string for novalue to give the compatibility mentioned by Kaldari. Technically an empty string is different from novalue (which I guess is like NULL), but from a template's point of view, they should have the same effect. Johnuniq (talk) 22:28, 12 October 2016 (UTC)

@RexxS: Yes, we could test directly in the infobox code, but I can't really think of any situation in which I wouldn't want to test for "no value", as we would obviously never want to output "no value" to the infobox. I understand your argument about the current behavior being "correct" as far as the API is concerned, but I think if any layer of the stack is going to convert "no value" to nil, this would be the best place to do it. Thanks for your work on the sandbox code. I tested it at South Pole (via preview) and it seems to work well. Regarding consensus for the change, I hereby support it! Maybe Mike Peel would have an opinion on this as well. Kaldari (talk) 22:31, 12 October 2016 (UTC)

I have a few problems here. a) I'm not sure that a "no value" entry on Wikidata is actually useful - it makes more sense to me if the property simply isn't defined, than if it's set to "no value". b) The problem with "no value" being shown in South Pole Telescope's infobox is caused by {{#if:{{#Property:P17}}... - *not* this module. So Wikibase would also need to be fixed here to correctly handle "no value" if we are going to use that. c) I didn't think that consensus was needed to change this template for uncontroversial changes, particularly during the current rapid development process, just that we should use a sandbox to check for code errors before deploying a new version.

That said: I've just tested the sandbox version at Template:Infobox telescope, and the issue (b) described above results in the location being given as "Amundsen–Scott South Pole Station," (i.e. including an extra comma at the end). So if the sandbox version is deployed, then we'll need to switch the property check to also use this template (which is a slightly more expensive call). Thanks. Mike Peel (talk) 21:05, 13 October 2016 (UTC)

No value is for when we know there isn't a value. Wikidata, of course, has the need for no value and unknown value because it operates under the open world assumption.

One of the problems with Wikipedia's infoboxes is that we don't distinguish between "doesn't have a value", "don't know if it has a value", and "isn't important" (and of course, "it's too complex to factoidize"). "No value" (and it's friend "unknown value") make the first two questions explicit. And so, from that perspective, I would prefer to see Wikipedia saying "this doesn't exist" where it makes sense. --Izno (talk) 11:26, 14 October 2016 (UTC)

@Mike Peel: Wikidata needs a "no value" value type since there are cases where we want to assert that an item doesn't have a particular property. For example, I may want to query for all the islands that don't belong to a country (rather than islands that simply don't have a country set yet), or once we have human cloning I may want to query for all people that don't have a father. You're right that the #Property parser function has the same problem. I've filed phabricator:T148357 for that. Kaldari (talk) 07:12, 17 October 2016 (UTC)

How to get Q IDs from Property:P150 of a Wikipedia page

In the province of Nueva Vizcaya (Q13866), I wanted to get the Q IDs of all items under statement Property:P150 (contains administrative territorial entity), but I don't know how.

For Nueva Vizcaya province,
{{#invoke:Wikidata|getValue|P150|FETCH_WIKIDATA}}

gives (wikilinked) results:

Alfonso Castañeda, Ambaguio, Aritao, Bagabag, Bambang, Bayombong, Diadi, Dupax del Norte, Dupax del Sur, Kasibu, Kayapa, Quezon, Santa Fe, Solano, Villaverde

but what I wanted to get are the IDs of these items like:

Q51474 Q51475 Q51477 ...etc...

{{#invoke:Wikidata|getUnitID|P150|FETCH_WIKIDATA}}

on the other hand gives a blank result.

Please advise on what to do and what code to use. Thanks. Sanglahi86 (talk) 14:06, 29 September 2016 (UTC)

I've adapted getValue in a sandbox: Module:Sandbox/Rexxs/PropIDs. You can try pasting and previewing the following in Nueva Vizcaya (or whatever article you are interested in):

{{#invoke:Sandbox/Rexxs/PropIDs |getPropertyIDs |P150 |FETCH_WIKIDATA}}

You should get something like: Q51474, Q51475, Q51477, Q51478, Q51479, Q51480, Q51481, Q51483, Q51484, Q51485, Q51486, Q51487, Q51493, Q51494, Q51496.

If that's what you need and it tests properly, feel free to move the code into module space, or make a request here for it to be incorporated into this module. HTH --RexxS (talk) 17:26, 29 September 2016 (UTC)

Thank you very much. This is exactly what is needed. I tested it on some province articles and it works perfectly. Yes, please incorporated the code into the module as it is a tedious task to keep on highlighting the properties in Wikidata and manually copying them. Sanglahi86 (talk) 06:35, 30 September 2016 (UTC)

Hello. The code doesn't seem to be incorporated into this module yet, even though it works properly. If you could please move it as I am not familiar with modules and its codes. Thank you. Sanglahi86 (talk) 05:44, 1 November 2016 (UTC)

I have been hoping that someone else would comment. As usual, it's really hard to make progress when consensus is demanded in order to make changes, but nobody comments in a month to create that consensus. In the absence of opposition, I've gone ahead and added it to this module as a stand-alone function. Call it like this:

• {{#invoke:Wikidata |getPropertyIDs |P150 |FETCH_WIKIDATA}}

Hope that works for you now. --RexxS (talk) 21:37, 1 November 2016 (UTC)

Year bug

The infobox shows '1964' instead of '1965' in Gina Miller if the infobox fetches Wikidata. After some tests, it seems that the infobox removes 1 to the year, please fix, thanks. --Thibaut120094 (talk) 15:29, 5 November 2016 (UTC)

Previewing {{#invoke:Wikidata|getDateValue|P569|FETCH_WIKIDATA|dmy}} in Gina Miller did show 1964 because Wikidata has decided to store 1965 as "+1965-00-00T00:00:00Z" which is not a valid date. The built-in Lua function formatDate corrects that to 31 December 1964 (i.e. the day before 1965-01-01) and that returns the year as 1964. The fix for that (if precision is year, just return the year) is already in the module but is no longer called from getDateValue.

The workaround is to force Wikidata to store a valid date. I just set Miller's dob to 1 June 1965 but manually set the precision to 'year'. The shows 1965 as before, but works correctly with this module.

Incidentally, previewing {{#invoke:Wikidata|getValue|P569|FETCH_WIKIDATA}} shows 1965, but that is only going to work when a year, rather than a date is expected, as US date format can't be set when using getValue. Maybe it's time to ask Wikidata to fix storing invalid dates? --RexxS (talk) 22:40, 5 November 2016 (UTC)

@RexxS: Thank you for your reply. Maybe you should report this on Phabricator or to d:Wikidata:Contact the development team? Regards. --Thibaut120094 (talk) 17:37, 6 November 2016 (UTC)

Question - check if there is certain "instance of"

Hi all, I am new to all this but I am trying to set up a template on Czech Wikipedia using this module and I'd like it to check if certain item has certain instance of (P31) and assign values.

{{#invoke:Wikidata|getRawValue|property=P31}} | Q3957 = city | Q257978 = statutory city | Q5119 = capital | obce }}

However this does not often work because many items have more than one instance of (P31) statements and it the invoke function only returns the first. Can anyone please help? Thanks --Vojtěch Dostál (talk) 14:55, 6 November 2016 (UTC)

I used Module:String.--Vojtěch Dostál (talk) 23:26, 6 November 2016 (UTC)

getValueFromID returns Lua error - sometimes

I met this: Q4917184 = Bisalbuminemia

• {{#invoke:Wikidata|getValueFromID|Q4917184|P1995|FETCH_WIKIDATA}}

→

clinical chemistry

(insert by Rexxs to maintain the sense of the OP: Lua error in Module:Wikidata at line 609: attempt to index field 'claims' (a nil value).)

(today, it says: "Lua error in Module:Wikidata at line 609: attempt to index field 'claims' (a nil value)."

In certain pages (mainspace?), the error does not occur.

• Or anything wrong with d:P1995? Discogs label ID, medical specialty? Oops, wrong number.

-DePiep (talk) 11 December 2016 (UTC) (multiple edits)

The best way of linking and referring to a property on Wikidata is to use the same {{Q}} template as we do for items, like this: {{Q|P1995}} → health specialty (P1995)

The error is caused because Bisalbuminemia (Q4917184) has no claims (really useful item, not). I've modified getValueFromID() to match getValue() which already tests for the existence of claims before trying to assign them to an object. An item with no claims will now return an empty string from the call. Apologies for refactoring within your post, but once I modified the function, it modified the sense of your post. Cheers --RexxS (talk) 22:12, 11 December 2016 (UTC)

 Solved

Now returns: >clinical chemistry< (no value)

I understand your {{Q}} ref is help only, not bug-related. -DePiep (talk) 01:30, 12 December 2016 (UTC)

getQualifierValue for a specific property value?

In South Pole Telescope using Template:Infobox telescope, I'm fetching construction dates based on significant event (P793), qualifiers start time (P580) & end time (P582). This works fine at the moment. However, a problem might occur in the future if someone adds another significant event with start and end times to the Wikidata entry: I guess that both sets will be fetched rather than just the construction dates. It would be good to be able to restrict the call to just qualifiers for the property value construction (Q385378). Would this be feasible? (@RexxS) Thanks. Mike Peel (talk) 17:04, 18 December 2016 (UTC)

Not generically. For any entry, we don't know how many values exist for a particular property; nor do we know how many qualifiers exist for a particular value of that property. I didn't write getQualifierValue and I don't believe it can work in the general case, because to single out a particular qualifier, we need to already know the value of the property in order to filter out other qualifiers that relate to other values.

In your case, we could write a custom call because we know that we're only interested in when the significant event is construction. That would filter out other significant events, but it still can't cope with editors adding extra start and finish times (although logically, that should not happen). I'll make a new call in Module:WikidataIB like this: getQualifierValue( Property | pval=TargetValueOfProperty | qual=Qualifier | etc. ) so that will return the value(s) of Qualifier when TargetValueOfProperty is present for Property - and nothing otherwise. I'll update when I'm done. --RexxS (talk) 18:37, 18 December 2016 (UTC)

Update: OK, Mike, if you paste

• {{#invoke:WikidataIB |getQualifierValue |P793 |pval=Q385378 |qual=P580 |name=xyz |fetchwikidata=ALL }}

into a section of South Pole Telescope, you'll get

• November 2006 

Similarly

• {{#invoke:WikidataIB |getQualifierValue |P793 |pval=Q385378 |qual=P582 |name=xyz |fetchwikidata=ALL }}

gives

• February 2007 

In an infobox you can add parameters for |suppressfields= for a blacklist and you can specify |onlysourced=yes if you want to only deal with sourced data. The call in the infobox might look something like

• {{#invoke:WikidataIB |getQualifierValue |P793 |pval=Q385378 |qual=P580 |name=constructed |fetchwikidata={{{fetchwikidata|}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|}}} }}

if you want "opt-out", then simply use |fetchwikidata=ALL instead. I assume you'll use something like {{{start_date|{{#invoke:WikidataIB |getQualifierValue ...}} }}} to create a local override if desired. Let me know how it goes. --RexxS (talk) 21:59, 18 December 2016 (UTC)

Thanks @RexxS: it's now in use at Template:Infobox telescope and seems to be working nicely! One minor issue: it doesn't seem to be wikilinking values, see "Altazimuth mount" in the South Pole Telescope infobox. Thanks. Mike Peel (talk) 22:20, 18 December 2016 (UTC)

That's because I used the API call mw.wikibase.renderSnaks() which saves all the hassle of decoding dates, etc. Unfortunately, the devs didn't think it should return a pre-linked value. I already have a solution for that, so bear with me while I apply the fix. --RexxS (talk) 22:38, 18 December 2016 (UTC)

Update: That should be working now. But I realised I didn't implement the 'edit at Wikidata' pen icon (because I thought, wrongly, that qualifiers were meant to just qualify properties, not hold values that don't have a property of their own). Still, we can do that later if somebody complains. Cheers --RexxS (talk) 23:34, 18 December 2016 (UTC)

Thanks, the linking seems to be working nicely. :-) Yes, I found this setup a bit odd, but see the discussion at [1]. Thanks. Mike Peel (talk) 09:59, 19 December 2016 (UTC)

Capitalization of first letter in fetched content?

Using this module to fetch the "field" parameter of medical diseases, I want the first letter of the fetched phrase to be capitalized. Using the {{ucfirst:}} function doesn't work on the fetched information. Is there any such functionality built into the module? It all happened here: Template:Infobox medical condition (new), example: Gout

Best, Carl Fredrik 💌 📧 16:35, 21 December 2016 (UTC)

See {{Infobox video game}} and the data15 and data16 fields, for an example on this. We had the same issue. ucfirst counts the "[" of the wikilink as the first character so doesn't work. Rexx's String2 "sentence" call is "link aware". -- ferret (talk) 16:45, 21 December 2016 (UTC)

That's useful to know. So the code to use is {{#invoke:String2|sentence|...}}. Note that UPPER has some issues (at least when used with Module:WikidataIB), and that 'title' capitalises every word *except* for the first. Thanks. Mike Peel (talk) 17:51, 21 December 2016 (UTC)

I've implemented sentence case for |field= in Template:Infobox medical condition (new). As an example, syntax like {{#invoke:String2|sentence|[[pain management|pain control]]}} produces Pain control and a piped link is what getValue() normally returns from Module:Wikidata. You should see that Specialty shows as Rheumatology in Gout now. I took the opportunity to clean up the template because, by convention, templates don't support alternate capitalisation of parameters - the default is lowercase, except for parameter names which are proper nouns or acronyms like Mesh or ICD. That allows us to make the template much easier to read and amend, which is important when we are looking at increasing the fields that might be fetched from Wikidata. I've tidied all of the pages that transclude the template and updated a few Wikidata items to check that our article is pulling good data from Wikidata for the medical speciality. It all seems to be working well. It's worth noting that Orthopedics (Q27712680) is not the same as orthopedics (Q216685); the former is a journal and the latter on English Wikipedia is a redirect to Orthopedic surgery - not quite the same thing, IMHO.

@Mike: Take a look at the documentation for Module:String2 and see if there's anything you want changing. It should offer superior string handing to the parser functions. --RexxS (talk) 19:41, 21 December 2016 (UTC)

getDateValue returns wrong value

When you invoke getDateValue to get a date that's only entered into Wikidata as a year, it seems to consistently return a value 1 less than the actual year. For example, try adding {{#invoke:Wikidata|getDateValue|P569|FETCH_WIKIDATA|dmy}} to Crystal Bennett. It returns 1917 instead of 1918. It's currently breaking the functionality of {{Infobox person/Wikidata}}, which an editor is using as an excuse to mass remove it from articles, so if anyone could take a look that'd be great. – Joe (talk) 04:29, 1 January 2017 (UTC)

If a date is entered as just a year like '1918', it is stored in Wikidata as ""+1918-00-00T00:00:00Z", which translates to midnight on the 0th day of the 0th month of 1918. Unfortunately the standard date handling libraries available treat that as the day before 1 January 1918, i.e. 31 December 1917 – which returns 1917 as the year, of course. I did provide a fix for that some time ago, but that function isn't used now, in an attempt to make the Module more compatible with the German version. The simplest fix is to make the date in Wikidata into a valid date - I usually just set the date to 1 January (or anything) in that year and then set the precision back to 'year' manually. At least all the other re-users of Wikidata get a valid date to work with then. --RexxS (talk) 05:30, 1 January 2017 (UTC)

That "1917" result is not wrong per se. In ISO 8601 time notation, Thursday, "24:00:00" is exactly the same time moment as Friday, "00:00:00". While the ISO allows a lesser accuracy (like writing "2017-05" for the whole month of May 2017), but that probably requires a different internal notation (meaning era instead of moment). A true era notation would include two time moments. -DePiep (talk) 10:30, 1 January 2017 (UTC)

It's wrong in the sense that someone entered 1918, it's displayed on Wikidata as 1918, and yet it comes across here as 1917, though... – Joe (talk) 14:27, 1 January 2017 (UTC)

Yes that is wrong. But it can be fixed simply by ensuring that Wikidata has a valid date stored. The Wikidata display is a "work-around" – everybody else has to deal with the actual stored value. --RexxS (talk) 15:47, 1 January 2017 (UTC)

As a present (considering the time of year), I've applied a fix that I believe eliminates the issue. Check the version of Crystal Bennett that had the wrong birthdate – it's now displaying 1918 for me. Of course that won't do anything to help other re-users of the Wikidata, but I suppose you can only do so much. Cheers --RexxS (talk) 17:49, 1 January 2017 (UTC)

Thank you, very much appreciated. – Joe (talk) 18:08, 1 January 2017 (UTC)

You're welcome. It's a shame that we have to apply work-arounds on en-wp because of a GIGO problem when retrieving Wikidata. I do agree that it would be better to ensure that all data held on Wikidata was valid, but I really don't have the fortitude to take on that task. --RexxS (talk) 18:20, 1 January 2017 (UTC)

enwiki labels and article name

Is it possible to return the enwiki article name rather than the English label on Wikidata for a certain QID? Nikkimaria (talk) 00:02, 3 January 2017 (UTC)

Sure, Nikki. I've made another demo to show how you can do it. Try {{#invoke:RexxS|getAT|Q42}} – you should get Douglas Adams. Of course you won't get anything if the article doesn't exist on the local wiki. --RexxS (talk) 00:23, 3 January 2017 (UTC)

Just checking (see A. Durpoix (Q2818912)): >{{#invoke:RexxS|getAT|Q2818912}}< → ><. --RexxS (talk) 00:32, 3 January 2017 (UTC)

How do I get the enwiki label, and link, from QID?

I have an external (non-article) QID. How do I get the enwiki label, and the enwiki article linkname? Example in case. Mercury (element) (article Mercury) has QID=Q925. -DePiep (talk) 23:16, 2 January 2017 (UTC)

It depends on what you want to do with it. I've knocked up a demo in my sandbox module [Module:RexxS]] that shows how to do it in Lua. You can use {{#invoke:RexxS |getLink |Q925}} to get mercury. If you want capitals, then {{#invoke:String2 |sentence |{{#invoke:RexxS|getLink|Q925}} }} → Mercury (you could write a wrapper template for that sort of job). Is that a help or is there a specific implementation you need? --RexxS (talk) 23:59, 2 January 2017 (UTC)

Thanks. Could you put that in Module:Wikidata or in Template:Wsuch -requests-we-should-fulfill?

The cause (for now) is the 120 chemical elements, non-mainspace info. But to me it looks like a reasonable question in general. -DePiep (talk) 00:29, 3 January 2017 (UTC)

So it is: {{Q|Q925}} → mercury (Q925) then. I'll look for the {{Q/doc}} options. -DePiep (talk) 00:52, 3 January 2017 (UTC)

(edit conflict) @DePiep: If there's no article on en-wp (like A. Durpoix (Q2818912)), is it OK to return just the label? {{#invoke:RexxS |getLink |Q2818912}} → A. Durpoix. Also what do you want the behaviour to be if there's no label? (I've set it to return the QID in that case). It's hard to add new calls to Module:Wikidata, because I'm supposed to get consensus for any changes. I can add it to Module:WikidataIB without having to wait for consensus here, so you can use {{#invoke:WikidataIB |getLink |Q925}} to get mercury while we wait.

The template {{Q}} produces a link to the Wikidata entry. I thought you wanted the link to the en-wp article? --RexxS (talk) 00:59, 3 January 2017 (UTC)

When on anypage, I want to show something about QID=Q925 (happens to be Mercury (element), mercury (Q925)). As a labeltext "Mercury", or as a link Mercury. I know about "expensive". I do not know about: why is this an issue at all. -DePiep (talk) 01:13, 3 January 2017 (UTC)

I'm sorry, I really don't understand you. What is the issue you're referring to? --RexxS (talk) 01:24, 3 January 2017 (UTC)

About WP:ELEMENTS. See Template:Infobox element/symbol-to-name/doc, a template doc page. It knows that the QID for mercury is Q925. With that QID, I want to return (show) 1. 'Mercury' or 2. 'mercury' (I will select option 1/2 by parameter). So my question for this module is: how to return & show one such value from Wikidata? QID in, enwiki label or enwiki wikilink out. -DePiep (talk) 01:45, 3 January 2017 (UTC)

OK - I can see there's a lookup table in Template:Infobox element/symbol-to-QID that accepts Hg and returns Q925. So that means you can use:

1. {{#invoke:WikidataIB |getLink | {{Infobox element/symbol-to-QID|Hg}} }} →
2. {{#invoke:WikidataIB |getLabel | {{Infobox element/symbol-to-QID|Hg}} }} →

Obviously, you can replace the Hg with {{{1|}}} in a template and pass the symbol in. Use Module:String2 to convert to sentence case (it's link-aware). None of these calls are expensive. --RexxS (talk) 02:58, 3 January 2017 (UTC)

That's great, and well-described. Thanks a lot. -DePiep (talk) 09:49, 3 January 2017 (UTC)

Method claim and #property do the same?

In an article (infobox), I can use:

• {{#invoke:Wikidata|claim|P628}}
• {{#property:P628}}

All other the same, are they interchangeable? If so, shall I prefer to use #property:? (To me it looks like, either when a value exists or does not exist=blank). -DePiep (talk) 09:01, 16 February 2017 (UTC)

I was wondering about that recently while contemplating {{PH wikidata}} (background at Talk:Cebu). That template translates a word such as "seat" to the appropriate property. Using "seat" as input to the template gives this output:

{{#if:{{#property:P36}}|{{#invoke:Wikidata|getValue|P36|FETCH_WIKIDATA}}}}

I have no idea whether the above is desirable but thought I would mention it. Johnuniq (talk) 10:27, 16 February 2017 (UTC)

I think your example produces wikilinked values, while #property: does not add the link. And btw, function p.claim(frame) is working but not mentioned in this's documentation. -DePiep (talk) 12:08, 16 February 2017 (UTC)

One problem with archiving is that frequently asked questions get asked, well, frequently. The very first comment on this page was Module talk:Wikidata/Archive 1 #Why. The response I gave was:

If a property has multiple values then sticking [[...]] around the data returned by #property from Wikidata doesn't create multiple links. For example Franz Kafka's (d:Q905) countries of citizenship (d:P27) are Austria-Hungary, Czechoslovakia, not Austria-Hungary, Czechoslovakia. Lots of properties in Wikidata have multiple values and if we want to populate infoboxes from a central resource, then we need to handle linking of multiple results automatically.

Additionally, #property returns an undisambiguated value, so for William Ellery (d:Q567964) you'd get his place of birth as 'Newport'. Blindly making that into a link takes you to the page Newport which is not where Ellery was born. This module correctly returns Newport, Rhode Island (d:Q54264). As a bonus, it should work in other language wikis where a corresponding article exists because it looks for the title of the article in that language to create the link.

You might want to look at the newer function {{#statements}} which aims to duplicate some of the functionality of our Wikidata-related modules. HTH --RexxS (talk) 14:56, 16 February 2017 (UTC)

Is {{#statements}} documented? It seems hard to find. Jheald (talk) 20:13, 19 February 2017 (UTC)

Found mw:Wikibase/Notes/Inclusion_syntax about {{#property}}. (I'm happy I also found mw:Wikibase/DataModel/Primer btw). -DePiep (talk) 20:29, 19 February 2017 (UTC)

Linking to Wikidata when a redirect might exist

Maybe it would be a good idea for the module to check, where it currently outputs a Wikidata-linked value, to check to see if that Wikidata-linked value a) exists as an EN.WP page or b) is a redirect (at least b--a might be expensive)--and if b, again, at the least--link to the English Wikipedia page rather than to the Wikidata page. This might help resolve some of the Bonnie and Clyde problems we have. B could be accomplished by checking mediawikiwiki:API:Info. --Izno (talk) 18:00, 16 March 2017 (UTC)

@Izno: I can't find the documentation for how the Scribunto implementation of Lua is able to access the MediaWiki API (which seems to be expected to work with php). Nevertheless, it is possible using the documented mw.title library (mw:Extension:Scribunto/Lua reference manual #Title library) to check whether a page exists and whether it is a redirect. I've knocked up a couple of functions in my sandbox Module:RexxS that can perform the required logic:

• {{#invoke:RexxS|checkRedirect|art=Theologian}} → Redirect
• {{#invoke:RexxS|checkRedirect|art=Theology}} → Not Redirect
• {{#invoke:RexxS|checkRedirect|art=Theol}} → Does not exist
• {{#invoke:RexxS|checkPage|art=Theologian}} → 70579
• {{#invoke:RexxS|checkPage|art=Theol}} → 0

Perhaps your suggestion can be implemented by someone who is less disillusioned with the intransigence of the Wikidata community to recognise the problem that refusing to link to valid redirects causes for the use of Wikidata in Wikipedia. Personally, I've lost interest in having to continually create work-arounds in code because of bad design in the source. --RexxS (talk) 20:34, 16 March 2017 (UTC)

I may be wrong, but I believe an RFC on Wikidata approved linking items to redirects. The issue is that it has to be implemented by Mediawiki. -- ferret (talk) 21:02, 16 March 2017 (UTC)

That is one of the lowest of low priority items on the development team list. In addition, the original RFC was not well-informed about the implications of making such a change (and I !voted in the affirmative to make the change in question)--which makes it difficult to say "yes, there's definitely support to do this". Regardless, the original design decision was made to stop users from adding the morass of anchor links and duplicate links that we had prior to Wikidata--and was quite deliberate (so I have issue with the notion that it is "bad" design--what the users want and what is good design are not always or possibly even ever the same). --Izno (talk) 21:16, 16 March 2017 (UTC)

When the source is designed to prevent Howard Carter's occupation of archeologist being returned as a valid site-link, then yes, I would call it bad design. Giving clients what they want is a fundamental principle in any business and designers thinking they know better is a recipe for a software enterprise to fail. If Wikidata fails to understand what's needed to make it usable, then it will become a white elephant, unused by the very encyclopedias that really could benefit from a central, functional database. --RexxS (talk) 22:18, 16 March 2017 (UTC)

Generating html lists

it would be great if we could have something like getValue, but with output as an HTML list. sure, I could post process the output (in most cases), but it gets tricky when there are commas in the entries, and all I want to do is shove the list inside something like {{plainlist}} or {{flatlist}}. can we make this happen? I would use it in {{PH wikidata}}, for example. Frietjes (talk) 21:27, 27 September 2016 (UTC)

The code for getValue creates a Lua table of values (called 'out'), with each one wikilinked either to Wikipedia or Wikidata. That table is merely concatenated using a comma and space as separators to create the text returned. That happens on line 536 in the present version. Since the getValue function is completely self-contained, the lines 511–547 can be copied elsewhere and re-used as a new function where you can then create whatever html you want wrapped around the values. If you wanted an html list, then something like this would probably work in place of line 536:

if #out>1 then
  return "<ul><li>" .. table.concat(out, "</li><li>") .. "</li></ul>"
else
  return out[1]
end

Assuming you don't want a list if there's only one value to be returned. As I'm not exactly sure how you want to shove it into {{plainlist}} or {{flatlist}}, I can't be any more precise. Does that give you enough to make a start? --RexxS (talk) 16:48, 29 September 2016 (UTC)

RexxS, in Toledo, Cebu the collapsed list of barangays in the infobox is generated by {{#invoke:sorted plain list|asc|{{#property:P150}}}}. if you notice in that article, one of the entries is "Juan Climaco‚ Sr. (Magdugo)" which has a comma in it. since the list is being returned as a comma delimited list, an IP hacked that entry to use "‚" for the comma instead of the typical ",". these two look the same, but they are not the same character. it would be better if we could just call this module directly to get a sorted html list instead of going through the "LUA table" -> "comma list" -> "LUA table" -> "sort" -> "HTML list" sequence. alternatively, if we had an optional parameter, say |delimiter=, I could use |delimiter=; to change it to a semicolon delimited list by overriding the comma used on line 536 (and line 759, and possible other places). one one hand, generating the sorted list directly would be the least convoluted, but on the other hand, having the option to change the delimiter would require the fewest modifications here. I don't know which is the best option. or, a third option would be that I could modify module:sorted plain list to fetch wikidata properties. Frietjes (talk) 13:26, 25 March 2017 (UTC)

@Frietjes: I've added the |delimiter= parameter to Module:Wikidata/sandbox. Previewing {{#invoke:Wikidata/sandbox|getValue|P150|FETCH_WIKIDATA|delimiter="; "}} in Toledo, Cebu gives the list separated by semicolon space as expected. It works with other delimiters such as <br>, {{!}} and "". Leaving out the parameter completely defaults to ", " for backwards compatibility (note that using |delimiter= actually does use the empty string as a delimiter). Is that enough to allow you to use the output of this module for the job you want now? --RexxS (talk) 14:07, 25 March 2017 (UTC)

RexxS, yes, thank you. I have been experimenting with the third option that I mentioned as well. I'm still not sure which is the best option, so it will be good to have the |delimiter= available. thank you! Frietjes (talk) 14:11, 25 March 2017 (UTC)

Hindi Wikipedia

I am using this module on hi:साँचा:ज्ञानसन्दूक व्यक्ति and trying to fetch date. It fetches month in hindi, but date and year is still fetched in english. Can they be fetched in hindi too? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 04:49, 19 May 2017 (UTC)

If you're using getValue, then it relies on the formatPropertyValues call at line 630.

If you're using getDateValue, then it relies on reading the local Wiki's language (lines 13 and 239) and formatting it using the formatDate function.

Both are supplied by the MediaWiki Scribunto extension, and I don't have any way of checking how they work with Hindi, sorry. --RexxS (talk) 08:50, 19 May 2017 (UTC)

OK, is there anything that can be done in that case? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 14:50, 20 May 2017 (UTC)

You'll probably need somebody who is familiar with Hindi numerals and WP:Phabricator to file a report there explaining that there may a problem with either mw.wikibase.entity:formatPropertyValues or mw.language:formatDate (whichever is giving you the wrong results). --RexxS (talk) 14:58, 20 May 2017 (UTC)

Script error

Resolved

Please fix the following error:

“ लुआ त्रुटि Module:Wikidata में पंक्ति 780 पर: attempt to index local 'entity' (a nil value)।

बैकट्रेस (बुलाए गए फंक्शन): Module:Wikidata:780: फंक्शन "chunk" में mw.lua:511: ? [C]: फंक्शन "getAllExpandedArguments" में mw.lua:188: ? [C]: फंक्शन "pairs" में Module:Arguments:207: फंक्शन "mergeArgs" में Module:Arguments:320: ? [C]: फंक्शन "pairs" में Module:TableTools:112: फंक्शन "numKeys" में Module:TableTools:214: फंक्शन "compressSparseArray" में Module:Separated_entries:15: ? (tail call): ? mw.lua:511: ?

”

-- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:54, 21 May 2017 (UTC)

Context is needed. What is the source wikitext? Where is it used? Johnuniq (talk) 03:10, 21 May 2017 (UTC)

Height

I want to fetch P2048 (height) in feet and inches and P2067 (weight) in kgs. Is there any possible way for the same? Currently using {{#invoke:Wikidata|getValue|P2048|FETCH_WIKIDATA}} -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 04:49, 21 May 2017 (UTC)

@Capankajsmilyo: I've been using {{convert}} for this - see {{Infobox telescope}}'s "height" and "mass" lines. It's currently converting from the input unit (fetched from Wikidata) to another unit (e.g. m -> ft, or ft -> m), rather than always converting the unit to a standard one, but that should also be possible using convert. Thanks. Mike Peel (talk) 05:01, 21 May 2017 (UTC)

Unfortunately there are lots of practical problems using convert or possibly any other standard system. The following uses Anthony Joshua (Q573463) and height (P2048) as examples.

• {{convert|input=P2048|qid=Q573463|abbr=on}} → 198 cm (78 in)
• {{convert|input=P2048|ftin|qid=Q573463|abbr=on}} → 198 cm (6 ft 6 in)

If these converts were used at the article, the |qid=Q573463 would not be needed. Notice that convert defaults to converting cm to inches which is not what is wanted. Specifying the wanted output unit can be done (ftin in above) but would not be useful on an article where the input should be converted to cm, so it is not a general solution. I don't think I contemplated feet and inches for the input when used with Wikidata, so that very likely will not work. Do you know an article where the height is given in feet and inches? Johnuniq (talk) 05:47, 21 May 2017 (UTC)

I've been using #if statements to handle some of those issues - so if the unit is in feet, then the conversion is to cm, otherwise it's to feet. But having a logic that catches all cases is tricky. Thanks. Mike Peel (talk) 06:20, 21 May 2017 (UTC)

Age

Most infoboxes use {{Birth date and age}} and {{Death date and age}}. Is there any way to use it with this module? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 14:50, 20 May 2017 (UTC)

Not as far as I know. Although I can't see any reason why it wouldn't work with {{Birth-date and age}}. I might be prepared to look at a new call in Module:WikidataIB to call {{Birth date and age}} directly at some point in the future. --RexxS (talk) 15:09, 20 May 2017 (UTC)

Talk to me if you do because I have implemented many date/age functions and could make it interface more easily for a module. See Module:Age and Module:Date. Birth date and age is not implemented, but dates and ages are. Johnuniq (talk) 01:23, 21 May 2017 (UTC)

@Johnuniq: Would you like to help in integrating age in this module? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:17, 21 May 2017 (UTC)

Not really thanks. All the hard work has been done and the next step would be planning if a new feature would be helpful and whether, if implemented, it would have any problems due to the strangeness of Wikidata. That is up to RexxS and any others maintaining this module. Planning would involve thinking about all the weird ways Wikidata handles the data in question and working out how to handle things like partial dates (year only, year/month only). Finally, there has been a lot of pushback against using Wikidata in infoboxes and birth dates are sensitive and should only be displayed if reliably sourced. That is all strategy stuff. Johnuniq (talk) 03:16, 21 May 2017 (UTC)

Thanks for that John. My first thoughts were to simply reuse the getValue code in Module:WikidataIB to fetch the date and then pop its parts into a table that can be passed to frame:expandTemplate{title = 'Birth date and age', args = dateTable}}. Then I remembered that there are 8791 Wikidata entries with multiple dates of death and over 1000 with multiple dates of birth, with the Egyptian singer Mohammed Abdel Wahab (Q467895) having 6. I think there are going to be far more than just coding problems when it comes to coping with that, and I'd rather not fight any more of those battles just yet. Cheers --RexxS (talk) 10:39, 21 May 2017 (UTC)

Totally agreed. Wikidata is a lot of fun, but, umm, some other time. Johnuniq (talk) 11:02, 21 May 2017 (UTC)

Limiting the no of results

This module shows all the results in a property. Is it possible to limit the no. of results, for example P18, we generally require only single result. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 04:59, 4 May 2017 (UTC)

Yes, if you can devise an algorithm that decides which value of the property is required in every case. I can't because I'm not a mind-reader. The documentation for property image (P18) at d:Property talk:P18 #Documentation shows it to have a "Single value" constraint, but there are 28,391 violations as of today - see d:Wikidata:Database reports/Constraint violations/P18 #Single value. One could remove all of the extra images from Wikidata, or decide that one image among many is the preferred one (as is done for Template:Infobox telescope and the image caption), and amend the Wikidata entry for each item to make one image the preferred rank, as is done for telescopes (e.g. Very Large Telescope (Q265628) #image). However, none of those solutions can guarantee that another editor won't perfectly legitimately add more images or change the ranks on Wikidata. I don't have a solution for that. --RexxS (talk) 12:23, 4 May 2017 (UTC)

Can't we fetch only the first result? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:37, 4 May 2017 (UTC)

@Capankajsmilyo: How do you know that is the result you will want? What are you trying to do? --Izno (talk) 12:48, 4 May 2017 (UTC)

I am trying to add an image to infbox from wikidata. Editor can change the image, if the default is not a good one using |image=. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:51, 4 May 2017 (UTC)

I've been using the preferred rank marking on Wikidata, and so far I haven't encountered issues with that. Personally, I'd love to see us rotating through preferred-rank images, but that's probably a bit beyond where things are currently at. Perhaps a good approach would be to have a parameter that sets the maximum number of elements returned, and we add that to the calls to this template in infoboxes if we need it (with the default being infinite elements returned)? Thanks. Mike Peel (talk) 23:09, 4 May 2017 (UTC)

The problem is that programmers are trained to know that some data is purposefully not ordered—there is no "first". Documentation for Wikidata is incredibly vague but when I last looked it strongly suggests there is no ordering, other than that given by the preferred and normal ranks. A programmer would prefer implementing a request to produce a random result from the list of all possible values. Johnuniq (talk) 23:24, 4 May 2017 (UTC)

From what I've seen, qualifiers are time-ordered, although that is not guaranteed. Properties used to be time-ordered, but there now seems to be some sort of default ordering applied (although I don't know where that is documented). So it seems somewhat reliable that if you fetch the first entry, it will give the same result over time, but who knows what will happen in a few years time. If we want something that will definitely work, then I think we'd need to specify random selection from the different entries each time the module is called. ;-) Thanks. Mike Peel (talk) 23:43, 4 May 2017 (UTC)

For completeness, I should mention that I have noticed "qualifiers-order" (when qualifiers are present) and "snaks-order" (when references are present) in some Wikidata results. I'm in the mood for ranting, so I will add that Wikidata is a splendid example of an excellent design for storing data—you can put any damn thing you like in it. However, not much thought has been given to retrieving useful data—it is absurd that modules need to dance around with kludged (and probably buggy) code to achieve what people will obviously want. Johnuniq (talk) 23:59, 4 May 2017 (UTC)

@Mike Peel: The default ordering of statements is applied by the statement sort gadget for all users. --Izno (talk) 03:03, 5 May 2017 (UTC)

@Izno: According to its talk page, that gadget is no longer active and sorting is controlled by d:MediaWiki talk:Wikibase-SortedProperties somehow. Surely a gadget can't work for a user who has JavaScript switched off or who uses a browser that doesn't support JavaScript? Or is it being applied server-side in this case? In any case, doesn't that gadget merely affect the display within the JavaScript-generated UI on Wikidata, not the values returned via the mw.wikibase extension?

@Johnuniq: Amen to that. --RexxS (talk) 15:31, 20 May 2017 (UTC)

@RexxS: I am 99% certain it's still Javascript applying the sorting, only to the UI. --Izno (talk) 15:28, 21 May 2017 (UTC)

BTW, at Ayutthaya Historical Park I just had the odd incident that I ranked one image as the preferred one, but the media caption for the unpreferred one was shown. I've changed the preferences, but thought I should mention this oddity. Thanks. Mike Peel (talk) 02:04, 5 May 2017 (UTC)

Novalue

From Lua modules using getRawValue to loop values, how to evitate a "novalue"? Do you suggest a more consistent (and less local) way than looking for the "no value" string? --Valerio Bozzolan (talk) 09:55, 1 July 2017 (UTC)

I think getRawValue was written before "novalue" became established as a viable value for a property, so there's no special handling built-in. Can you give me an example of what you're doing so I can understand better? Do you think getRawValue should return nothing if the value is "novalue"? Or perhaps keep that as it is and change getValue to do the job for you? --RexxS (talk) 10:04, 1 July 2017 (UTC)

Qualifiers

I am trying to obtain the value of a particular qualifier for a particular property, usually for the current item, but sometimes for another item.

Am I right in thinking that Module:Wikidata can't support this (specifically, can't support getting the qualifier value for a 'foreign' item ?)

Is there another module I can use, or do I need to make a new specific one?

And: might this be a quite useful functionality to offer generally, that might be worth adding to Module:Wikidata? Jheald (talk) 20:18, 19 February 2017 (UTC)

@Jheald: Indeed it would, but lately I've concentrating on Module:WikidataIB which is easier for me to develop. The problem with trying to get a value for a qualifier of a property is that Wikidata allows a property to have multiple values and each of those values to have qualifiers that may have multiple values, and the scheme is by no means regular. For example, if you look at Richard Burton (Q151973), and examine property spouse (P26), you'll see five values, including Elizabeth Taylor (Q34851) twice! How would anyone be able to select the date of Burton and Taylor's second marriage (29 July 1976)? Contrast that with finding the population (population (P1082)) of Geneva (Q71), which currently shows two values, each with a different qualifier, point in time (P585) – of course, that could be updated at any time.

Anyway, I've developed a call that will work when we already know which value of the property that we want to find the qualifier for. For example, in Richard Burton (Q151973), to find the start time (P580) for his marriage when his spouse (P26) was Sally Burton (Q3469983):

• {{#invoke:WikidataIB |getQualifierValue |P26 |pval=Q3469983 |qual=P580 |fetchwikidata=ALL |qid=Q151973}} →

Specifying the |qid= allows arbitrary access (I think that's what you mean by "foreign"), but makes it an expensive call. You simply leave it out when you're fetching information for the current page. Hopefully that might fit what you're looking for.

Incidentally, trying the same call for his marriage to Elizabeth Taylor (Q34851) gives a predictably unpredictable result:

• {{#invoke:WikidataIB |getQualifierValue |P26 |pval=Q34851 |qual=P580 |fetchwikidata=ALL |qid=Q151973}} → 15 March 1964 

That's because I can't guarantee which "Elizabeth Taylor" value is found first. It really needs to have Elizabeth Taylor once, with two start/end times, but we have no means of enforcing that regularity on Wikidata. Hope all that helps with what you're trying to do. Cheers --RexxS (talk) 00:37, 20 February 2017 (UTC)

@RexxS: That sounds perfect, exactly what I need. Thank you so much!

I take the point about multiple values for the property. At the moment that already breaks my template, so the values have to be put in by hand. But luckily it only applies to about 50 cases out of the 8,500 that the template could potentially be used on (and only about 5 of the 750 or so where it's currently deployed). It's a link template to an external database, and I've contacted the database management about the 50 apparent duplicate entries they have; I'm hoping for a reply (only sent the email on Friday), but it may be some time before changes can researched and approved and made visible by them.

Primarily the template sits on artist's own articles, with only a handful of cases (so far) where it's used from another. So thanks for the warning about not using qid= if I don't have to.

Now, off to experiment! Thanks again, Jheald (talk) 08:59, 20 February 2017 (UTC)

Application to infobox

I have been trying to implement this module in Template:Infobox epic character, and have implemented certain params. However, while trying to fetch "position held" and its qualifier "of", I am unable to apply both Wikidata and WikidataIB. I have tried applying it in header8, let me know if anyone has a solution. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:53, 24 April 2017 (UTC)

Bump

@RexxS: you seem to be the expert in the room on this. I'm trying to implement the qualifier value call in an infobox (Template:Ordination). I've tried it on Template:Ordination/sandbox for the date of consecrationparameter, but am not having luck in the testcases page. Do you think you could tell me what I'm doing wrong? Many thanks. Ergo Sum 21:15, 17 September 2017 (UTC)

@Ergo Sum: you're trying to use this sort of code:

• {{#invoke:WikidataIB|getQualifierValue|P793|pval=Q125375|qual=P585|fetchwikidata=ALL|onlysourced=no|{{{date of consecration|}}}

That would fetch a the value of the point in time (P585) qualifier for the property significant event (P793) that has the value consecration (Q125375). But the Template:Ordination/testcases only has Pope John Paul II, and his wikidata entry John Paul II (Q989) didn't have the significant event (P793) property, so it's to be expected that you didn't see anything when checking by using the 'testcases'.

I've now added 28 September 1958 as the date of his (episcopal) consecration by adding a signifcant event (consecration) with a point in time qualifier. I've also made a small amendment to the sandbox to natch the code I suggest above.

Ordination history of Pope John Paul II
History Episcopal consecration Date 28 September 1958  Place Wawel Cathedral

If you try a blank ordination/sandbox in Pope John Paul II, you'll now get this, which shows "Date of consecration 28 September 1958" when expanded. You can set the |onlysourced= to yes if you only want values that have a reference better than "imported from xyz Wikipedia". Is that what you were looking for? --RexxS (talk) 22:46, 17 September 2017 (UTC)

@RexxS: Yes, I believe so. Thank you for the help. The one issue, though, is that in testcases, the parameter does not show up at all, even though there is the parameter that is locally coded, which should override the Wikidata value.

Also, is there a way to code a suppressfetch into the template so that calls from wikidata can be suppressed? Ergo Sum 23:18, 17 September 2017 (UTC)

@Ergo Sum: Well, I don't know what's happening in the testcases, as I've never trusted it, so I always test my code by previewing in the actual articles. I've just fully implemented the whitelist (|fetchwikidata=), blacklist (|fetchwikidata=) and source-filtering (|onlysourced=) in the date of consecration field. To test it, edit Pope John Paul II #Presbytariate and:

1. change "Ordination" to "Ordination/sandbox", then preview it - you should see the local value (change it and re-check);
2. remove the local parameter, then preview it - you should still see "28 September 1958" (fetched from Wikidata);
3. change "Ordination/sandbox" to "Ordination/sandbox |suppressfields=date of consecration", then preview it - you should see that the date of consecration has disappeared;
4. re-add the local parameter and check that it does not display - suppressfields even overrides a local parameter.

Obviously, don't save the changes (!), but you can experiment with the parameters. If you add |onlysourced=yes to an article, it will only import Wikidata values that are sourced to something other than Wikipedia.

See if that does the job for you now. Cheers --RexxS (talk) 15:38, 18 September 2017 (UTC)

@RexxS: All checks out except for no. 1. When I change the local parameter, the date from Wikidata still appears. This might be the same issue that is causing the parameter to not display on the testcases page. Could it be an issue with how the {{{date of consecration|}}} parameter is entered in the template? Without the local override functionality, the Wikidata call would not be very useful to have in the template, since few Wikidata articles have the requisite information as of yet. Again, thanks a bunch for your help. Ergo Sum 16:46, 18 September 2017 (UTC)

@Ergo Sum: I've now fixed the code in Module:WikidataIB to make sure that any local parameter supplied definitely overrides any fetching of Wikidata:

• {{#invoke:WikidataIB |getQualifierValue |P793 |pval=Q125375 |qual=P585 |name=date of consecration |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|}}} |qid=Q989 |1 April 2017}} → 1 April 2017
• {{#invoke:WikidataIB |getQualifierValue |P793 |pval=Q125375 |qual=P585 |name=date of consecration |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|}}} |qid=Q989 }} → 28 September 1958 

When you get a chance, perhaps you could re-check no. 1 and make sure you are satisfied with the template's behaviour. Please let me know if any problems remain. --RexxS (talk) 01:11, 19 September 2017 (UTC)

@RexxS: Yes, it all works now. Thank you for your help. One last question that is related to the above, for parameter denomination on the same template, can I just insert the qid, suppressfields, and onlysourced parts of the above code to allow for the same functionalities (the parameter uses Modeule:Wikidata, not Module:WikidataIB)? Ergo Sum 01:40, 19 September 2017 (UTC)

@Ergo Sum: Sorry, but the two modules are not that compatible. I wrote most of Module:Wikidata over four years ago to try to find out what designers wanted, so it has limited functionality for what you want. I wrote Module:WikidataIB specifically for infoboxes after a lot of feedback in an effort to meet the needs of designers who wanted the ability to control what fields were used at the article level and to filter the incoming data for verifiability. Unfortunately I haven't yet implemented the getRawValue() call in WikidataIB, but I did update the Wikidata version to allow the call to be made outside of an article using a qid like this for John Paul II (Q989):

• {{#invoke:Wikidata|getRawValue|P140|qid=Q989|{{{denomination|FETCH_WIKIDATA}}} }} → Catholic Church, Catholicism

so you could add |qid={{{qid}}} in the 'abovestyle' call to Wikidata to enable that functionality. I will write the code for getRawValue() in WikidataIB when I get a chance, but that will take me rather longer. --RexxS (talk) 02:11, 19 September 2017 (UTC)

Got it. Thanks again for the help. Ergo Sum 03:34, 19 September 2017 (UTC)

@RexxS: One last question related to the above. The headers in the template (e.g. header9) are designed to be displayed only if one of the parameters within their section is used. If calling from Wikidata, the parameter is not locally used, so the header is not displayed. Do you know how to code "header9" in such a way that if either the parameter is used or the value for that parameter is called from Wikidata, the header will be displayed? I tried using

• |header9 = {{#if:{{#invoke:Wikidata|getQualifierValue|P793|pval=Q7519600|qual=P585|{{{date of consecration|}}} }}|<div style="width:100%;border-top: 5px solid #800080">Episcopal consecration</div>}}
  but that didn't seem to work. Also, since implementing |qid={{{qid}}} in the abovestyle that uses Module:Wikidata, the template no longer calls the Wikidata value of "religion", which the color of the template is based on. This is a rather major part of the template. Do you know how to fix this? Would |qid=FETCH_WIKIDATA do it? Ergo Sum 16:56, 19 September 2017 (UTC)

When you use a parameter that may not have a value, you have to write it like this: {{{qid|}} with the pipe character '|'. Otherwise it literally returns the exact text "{{{qid}}}" when no parameter is supplied to the template. I've fixed that for you, so the colour looks right again when I checked in Pope John Paul II.

The only way to be sure that the headers are displayed when one of the fields is displayed is to test whether the field has a value, as you are attempting. You have to remember, though, that the call you're using is in Module:wikidataIB, not Module:wikidata; the |fetchwikidata= parameter needs to be encoded; and you ought to respect the settings of |suppressfields= and |onlysourced= as well. If you want to check for the date of consecration, this is what you need to set |header9= to:

• {{#if:{{#invoke:WikidataIB |getQualifierValue |P793 |pval=Q125375 |qual=P585 |qid={{{qid|}}} |name=date of consecration |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|}}} |{{{date of consecration|}}} }}|<div style="width:100%;border-top: 5px solid #800080">Episcopal consecration</div>}}

Note: (i) #invoke:WikidataIB; (ii) you still need all of the relevant parameters; (iii) Q125375 is 'consecration', while Q7519600 is 'ordination'. You need to be sure which one you're looking for.

On Pope John Paul II, the code above would produce:

• Episcopal consecration

Hope that helps. --RexxS (talk) 17:51, 19 September 2017 (UTC)

Thank you. Ergo Sum 00:48, 20 September 2017 (UTC)

Wikidata module appears to be calling nonexistent modules

Please see this discussion. – Jonesey95 (talk) 22:27, 19 October 2017 (UTC)

Critical performance improvement

Yesterday we discovered the following inefficiency when trying to deploy usage tracking on a per statement basis on ca.wikipedia:

		-- otherwise, iterate over all properties, fetch their labels and compare this to the given property name
		for k, v in pairs(entity.claims) do
			if mw.wikibase.label(k) == property then return v end
		end

This can also be expressed with:

		property = mw.wikibase.resolvePropertyId(property)
		if not property then return end

		return entity.claims[property]

The advantaged of the second version is that it doesn't need to iterate over all Statements (which is badly discouraged), thus the pages in question don't "use" all Statements. The problem has been solved on cawiki by now (see also T178114 and ca:Special:Diff/18943332#Critical_performance_improvement). Cheers, Hoo man (talk) 09:50, 13 October 2017 (UTC)

Pinging User:Pppery, User:RexxS, User:Izno who recently made edits in the module. Ladsgroup^overleg 17:21, 16 December 2017 (UTC)

My edits to this module have solely been for the purpose of getting rid of rampant duplicate code, and thus I have no opinion on this change. {{repeat|p|3}}ery (talk) 17:26, 16 December 2017 (UTC)

My edits to this module have only been to the original functions. The code in question was imported in this edit by Tobias1984 (adding more stuff from de-module). Since the code has been fragmented into so many sub-functions without documentation, I can no longer tell what the dependencies are for any part of this module. --RexxS (talk) 17:50, 16 December 2017 (UTC)

I guess I'm not helping with that matter ... {{repeat|p|3}}ery (talk) 23:32, 16 December 2017 (UTC)

It's a good thing to reduce duplication in code, but it's also necessary to help other people who are developing the code by documenting private functions. They may be obvious at the time, but months later it can be a nightmare of jumping back-and-forth, trying to understand what foo( x, y, z) does precisely, when trying to debug or expand the functionality. Keeping a list of dependencies for each function is also pretty essential when trying to re-use the code or the modules in other language Wikipedias, etc. --RexxS (talk) 14:24, 17 December 2017 (UTC)

Sorry to play the role of an old fart but Module:Wikidata has 232,788 transclusions so it should not be directly edited. Make adjustments in the sandbox, test them, think about them, let time pass, then put the final code in the main module. The recent edits by Pppery are excellent because duplicated code is an abomination, but the edits also introduced a bug because addon_sep is needed as a parameter to the new function. Johnuniq (talk) 23:22, 16 December 2017 (UTC)

 Done I used TemplateSandbox to test the change on multiple pages. Thanks for the improvement Hoo :) Legoktm (talk) 18:47, 18 December 2017 (UTC)

Request: add |id= or |qid= to getSiteLink

@RexxS, Izno, Legoktm, Paweł Ziemian, and Johnuniq: Could |id= or |qid= be added to getSiteLink to retrieve data from specified entries like the other functions can? This is needed for something I am working on.

Example (Result is blank if not working):

{{#invoke:Wikidata|getSiteLink|frwiki|id=Q13833438}} –Result–>

Thanks in advance. ~ Mellis (talk) 21:46, 6 January 2018 (UTC)

Removing duplication and adding functionality are not the same thing. {{3x|p}}ery (talk) 21:47, 6 January 2018 (UTC)

Yes, I am requesting added functionality. Sorry if you didn't want to be tagged.~ Mellis (talk) 21:50, 6 January 2018 (UTC)

That was the intended content of that message. Also, why did you ping Legoktm twice? {{3x|p}}ery (talk) 22:11, 6 January 2018 (UTC)

Clearly, a mistake. Fixed now.~ Mellis (talk) 22:18, 6 January 2018 (UTC)

getSiteLink for Commons

What is the syntax to get the Commons page of the article? Like {{#invoke:Wikidata|getSiteLink|enwikivoyage}}, I see enwiki and enwikiquote but what is the code for Commons page? --Traveler100 (talk) 10:02, 20 January 2018 (UTC)

@Traveler100: Fairly sure it's commonswiki. --Izno (talk) 16:48, 20 January 2018 (UTC)

@Izno: Appears to work, thanks. --Traveler100 (talk) 17:07, 20 January 2018 (UTC)

Testing getSiteLink

• {{#invoke:Wikidata |getSiteLink |enwiki |qid=Q25169}} → The Hitchhiker's Guide to the Galaxy
• {{#invoke:Wikidata |getSiteLink |dewiki |qid=Q25169}} → Per Anhalter durch die Galaxis (Romanreihe)

sub parameters

So I can request population (P1082) of a town and it appears to give me the latest values if there are multiple (which I want). Is there a way to get the associated values of that entry such as point in time (P585) and determination method (P459). Take for example d:Q316500 how would I get the values 1 August 2015 and census of the latest population figures?--Traveler100 (talk) 11:07, 23 June 2018 (UTC)

@Traveler100:

• {{wdib|P1082|qid=Q316500|fwd=ALL|rank=best|qual=ALL}} → 263,048 (census, 2020) 
• {{wdib|P1082|qid=Q316500|fwd=ALL|rank=best|qual=P459}} → 263,048 (census) 
• {{wdib|P1082|qid=Q316500|fwd=ALL|rank=best|qual=P585}} → 263,048 (2020) 
• {{wd|qualifier|Q316500|P1082|P459}} → census
• {{wd|qualifier|Q316500|P1082|P585}} → 1 May 2020

I don't know how you want to use those values, but one or another of the above may be useful. --RexxS (talk) 19:40, 23 June 2018 (UTC)

@RexxS: Great, thanks. --Traveler100 (talk) 20:07, 23 June 2018 (UTC)

Problem with special characters in template

When retrieving coordinates from Wikidata they are handled differently in string module functions like sub and find than when the equivalent text is input (working on template to convert to decimal then work out distances between places).

• Correctly {{#invoke:Wikidata|getValueFromID|Q85|P625|FETCH_WIKIDATA}} → 30°2'40"N, 31°14'9"E
• Correctly {{#invoke:String|len|30°3'22"N, 31°14'22"E}} → 21
• Incorrectly {{#invoke:String|len|s={{#invoke:Wikidata|getValueFromID|Q85|P625|FETCH_WIKIDATA}} }} → 36
• Correctly {{#invoke:String|find|source=30°3'22"N, 31°14'22"E |target=,}} → 10
• Incorrectly {{#invoke:String|find|source={{#invoke:Wikidata|getValueFromID|Q85|P625|FETCH_WIKIDATA}} |target=,}} → 18

Can someone explain why this is happening and more importantly how I can fix it? --Traveler100 (talk) 05:06, 27 July 2018 (UTC)

The why is that the Wikidata module is actually returning:

30°3&#39;22&#34;N, 31°14&#39;22"E

I'm not sure how best to fix it. Johnuniq (talk) 06:08, 27 July 2018 (UTC)

Module:Coordinates already has conversion functions, so you could use those. Jc86035 (talk) 07:04, 27 July 2018 (UTC)

Sound like a better solution, what is the syntax though? --Traveler100 (talk) 07:20, 27 July 2018 (UTC)

• {{#invoke:Coordinates | dms2dec |30°3'22"N, 31°14'22"E|lat}} →
• {{#invoke:Coordinates | dms2dec |{{#invoke:Wikidata|getValueFromID|Q85|P625|FETCH_WIKIDATA}}|lat}} →
• {{#invoke:Coordinates | dms2dec |30°3'22"N|lat}} →

@Traveler100: Where is this needed? What is the purpose? Can you give an example of an article that you would want to change (or at least, where you want to change the wikitext)? Johnuniq (talk) 07:26, 27 July 2018 (UTC)

@Traveler100: You can also use Module:WikidataCoord and the coord2text function of Module:Coordinates. You shouldn't really need to do most of this, though. Jc86035 (talk) 09:55, 27 July 2018 (UTC)

I will take a look at that. Actually working on Wikivoyage articles. We are finding that often there is an error with the coordinates of towns on Wikidata (often when extracted from Russian Wikipedia) and the Geo values in Wikivoyage articles are better. Was setting up a check to see where there is a difference and highlight them for fixing. See voy:Template:Geo/sandbox. --Traveler100 (talk) 10:36, 27 July 2018 (UTC)

The getValueFromID function in Module:Wikidata returns the raw values stored in Wikidata for coordinates, which means that html entities are returned. The newer getValue function from Module:WikidataIB substitutes the actual characters °, ', ".

• {{#invoke:WikidataIB |getValue |qid=Q85 |P625 |fwd=ALL |osd=no |noicon=true}} → 30°2′40″N 31°14′9″E
• {{#invoke:String|len|s={{#invoke:WikidataIB |getValue |qid=Q85 |P625 |fwd=ALL |osd=no |noicon=true}} }} → 19

However, it uses just the space to separate latitude and longitude, not a comma and a space. --RexxS (talk) 13:24, 27 July 2018 (UTC)

Preferred rank

The documentation says the module only fetches preferred-rank values if some are marked as preferred, but it doesn't seem to work like that. e.g.:

{{#invoke:Wikidata|getValueFromID|Q1339|P106|FETCH_WIKIDATA}}

gives Bach's entire list of occupations rather than the preferred-rank ones only:

composer, organist, harpsichordist, violinist, violist, conductor, choir director[*], concertmaster, musicologist, music educator[*], virtuoso, school teacher

Is there are recent change which removed this functionality? Deryck C. 15:03, 20 August 2018 (UTC)

@Deryck: I don't know the answer to that question, but while somebody is sorting that out, you could use Module:WikidataIB:

{{#invoke:WikidataIB |getValue |qid=Q1339 |P106 |fwd=ALL |osd=no}} → composer, organist, harpsichordist, violinist, conductor, choir director, concertmaster, musicologist, music educator, virtuoso, school teacher 

{{#invoke:WikidataIB |getValue |qid=Q1339 |P106 |fwd=ALL |osd=no |rank=best}} → composer, organist, harpsichordist, violinist, conductor, choir director, concertmaster, musicologist, music educator, virtuoso, school teacher 

That also has all of its links pointing to Wikipedia, not Wikidata. Cheers. --RexxS (talk) 15:21, 20 August 2018 (UTC)

@RexxS: What does WikidataIB do if the item label is a redlink on the site? Deryck C. 15:34, 20 August 2018 (UTC)

@Deryck::

1. If the Wikidata item has a sitelink, it strips disambiguators and uses that as the displayed text, linked to the full sitelink.
2. If there is no sitelink, but there is a label, it checks the local Wikipedia to see if there is a redirect with the same text as the label. If so, it links to the redirect.
3. If the label is not a redirect, it returns the unlinked label.
4. If there is no sitelink or label, it returns the entity-ID (e.g. Q12345) and puts the article in the Category:Articles with missing Wikidata information.

Does that make sense? --RexxS (talk) 15:47, 20 August 2018 (UTC)

@RexxS: Yep. And does it try to fetch a label from another language if the local language doesn't have a label? Deryck C. 10:44, 21 August 2018 (UTC)

@Deryck: Not explicitly. The normal language fallback is implemented (e.g. zh-mo → zh-hk → zh-hant → zh-hans → en), but I haven't written code to offer anything beyond that for a couple of reasons. There's no collection of sitelinks or labels available via the api exposed to Lua. That means we would have to load the entire entity and scan what is there - very inefficient and screws up watchlists. Additionally, there's no good algorithm that I've been able to come up with which would determine which label to return if more than one existed. Cheers --RexxS (talk) 16:40, 21 August 2018 (UTC)

That's totally fine - it's good to know there is some language fallback so if I use this of the Cantonese Wikipedia it'll try to scan some other languages (most importantly zh and en) before giving up and displaying the Q-number! Deryck C. 16:50, 21 August 2018 (UTC)

Module:No globals

I am curious, what does "require('Module:No globals')" line do? I might use it in some of my modules, if I know what to expect. --Jarekt (talk) 15:25, 12 November 2018 (UTC)

The documentation. Is that insufficient? --Izno (talk) 16:00, 12 November 2018 (UTC)

I guess I was confused by "This module causes an error if any nil global is read or if any global is written to", although it makes more sense after few rereads. I guess I will just need to experiment with it to see what it does. --Jarekt (talk) 19:25, 12 November 2018 (UTC)

Suppose template A invokes module B which requires module C. Module B does not require no_globals but module C does. Depending on the parameters in A, some code in B might execute a particular function which works and everything is good. However, with some other parameters, another function in A might be executed and that function has a variable with "local" missing. That is, the variable is global. When that variable is accessed (either to read it or to write it), the script will crash and the page with A will be added to Category:Pages with script errors. That is good because global variables are usually a sign of a bug, for example, due to a typo in the variable name. I mentioned Module:C to make it clear that it does not matter which module requires no_globals. Johnuniq (talk) 21:49, 12 November 2018 (UTC)

Wikidata Bridge

(Reposted from Module talk:WikidataIB § Wikidata Bridge.)

I'm guessing that the module maintainers might be unaware of this? The WMDE developers have been working on mw:Wikidata Bridge, which will allow some Wikidata statements to be edited directly through infoboxes and other templates. There's currently a semi-interactive prototype. I think it would be useful for the module maintainers to provide feedback, if there are any issues that haven't already been addressed.

There's an early draft of a documentation page that might help explain how the software's supposed to be enabled inside template code. Jc86035 (talk) 08:32, 3 July 2019 (UTC)

Using getValue to get the next or previous episode of a given TV series

How would I use the getValue function to get the next or previous episode of a given TV series? --Gonnym (talk) 07:06, 9 August 2019 (UTC)

@Gonnym: If the data exists on Wikidata, then it's fairly easy. Take Friends S1 E4, as an example. It has a Wikidata entry, The One with George Stephanopoulos (Q20785929). That has two statements with properties follows (P155) and followed by (P156). So:

• {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |P155 |qid=Q20785929}} → The One with the Thumb 
• {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |P156 |qid=Q20785929}} → The One with the East German Laundry Detergent 

Note that the first one (S1 E3) has its own article, and the second (S1 E5) is a redirect. WikidataIB should handle those okay.

Using Module:Wikidata:

• {{#invoke:Wikidata |getValue |P155 |qid=Q20785929 |FETCH_WIKIDATA}} → The One with the Thumb
• {{#invoke:Wikidata |getValue |P156 |qid=Q20785929 |FETCH_WIKIDATA}} → The One with the East German Laundry Detergent

That also works fine. --RexxS (talk) 14:40, 9 August 2019 (UTC)

Is there a way to get the |qid= with the episode name? I'm researching if there is a way to add this feature to {{Infobox television episode}}, but if the episode ID needs to be manually added, then it won't work. --Gonnym (talk) 14:44, 9 August 2019 (UTC)

@Gonnym: You mean use the current page's linked qid? Just don't supply it and the function uses the associated qid for whatever page it's on. That works on all of the functions. You can paste the following into a section of The One with George Stephanopoulos and preview it to test:

• {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |P155 |qid={{{qid|}}}}}
• {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |P156 |qid={{{qid|}}}}}
• {{#invoke:Wikidata |getValue |P155 |qid={{{qid|}}} |FETCH_WIKIDATA}}
• {{#invoke:Wikidata |getValue |P156 |qid={{{qid|}}} |FETCH_WIKIDATA}}

Obviously, once it's used in a infobox, you can then supply the |qid= to test the infobox outside of the article (the whole purpose of the qid parameter is to allow testing and examples like this). --RexxS (talk) 15:06, 9 August 2019 (UTC)

Ah, I didn't know; that's exactly what I wanted. Thanks RexxS, I'll test this now. --Gonnym (talk) 15:18, 9 August 2019 (UTC)

There is a scenario where the title of the episode is a crossover (Touch of Death (crossover event)) and I know the TV series name and the "current" episode name. Is there a way to get the |qid= from these names? --Gonnym (talk) 11:23, 10 August 2019 (UTC)

@Gonnym: I'm not sure I understand what you want by Is there a way to get the |qid= from these names? There needs to be more data available at Touch of Death (Q65049550) if you want to use it - consider adding has part(s) (P527) for each constituent episode. However if you just want the qid of a value of a property, then the function followQid will do that for you (check the documentation in the code). For The One with the Thumb (Q20785993) and followed by (P156):

• {{#invoke:WikidataIB |followQid |props=P156 |qid=Q20785993}} → Q20785929

That gives the qid for The One with George Stephanopoulos (Q20785929). Cheers --RexxS (talk) 14:44, 10 August 2019 (UTC)

followQid takes three optional parameters: qid, props, and all. If qid is not given, it uses the qid for the connected page - if I'm understanding this correctly, then this isn't helpful in my scenario. I'll explain again. I want to invoke getValue() from page A and get results for a different WikiData item (page B). So let's say I'm on the page of The One with the Thumb, I want to know if it's possible to pass the title of another en.wiki article and use getValue with it (again, without using qid, only article title). --Gonnym (talk) 14:51, 10 August 2019 (UTC)

Any Scribunto module that wants to access data from Wikidata has to determine which Wikidata entity it is going to use. Each of those entities is uniquely identified by its entity-ID, the Q-number (qid), not by a title because Wikidata is a fully multilingual site and the same Wikidata entity can be associated with articles in many different languages. Because the association between a particular Wikipedia article title and the corresponding Wikidata entity is only stored in that Wikidata entity, the data that is exposed to Scribunto is a one-way association: that is, if you know the qid of a Wikidata entity, you can simply determine the title of the associated en-wiki article using code that runs anywhere, but not the other way round. Sorry I can't help with that.

On the other hand, if page B is the value of a property for page A, then we can use getPropOfProp on page A to retrieve values of properties on page B, but that's not using the title of page B. If we want to get info (for example: Rotten Tomatoes ID (P1258)) for The One with George Stephanopoulos (Q20785929) from the The One with the Thumb (Q20785993) article, we can use the relationship that Q20785929 follows Q20785993:

• {{#invoke:WikidataIB |getPropOfProp |prop1=P156 |prop2=P1258 |fwd=ALL |osd=n |noicon=t |qid=Q20785993}} → tv/friends/s01/e04

which is the Rotten Tomatoes ID for The One with George Stephanopoulos. Incidentally, that ID is useful because it tells you the season and episode. --RexxS (talk) 16:03, 10 August 2019 (UTC)

Thanks for that explanation. I was hoping there was a reverse lookup using the en.wiki title value which produces a valid wikidata ID (which tbh, should really be a valid method). Adding the information to wikidata while overall good, isn't helpful in this situation, as I'm trying to automate this. --Gonnym (talk) 16:36, 10 August 2019 (UTC)

I just noticed you added getEntityFromTitle() to Module:WikidataIB which if I'm not mistaken is exactly what I needed. --Gonnym (talk) 17:58, 12 August 2019 (UTC)

Error related to i18n

@RexxS: At Malaybalay, {{PH wikidata}} causes an error as it calls this module, which calls Module:i18n to load i18n data, but Module:Wikidata/i18n is empty and does not contain the required res.i18n table. I think line 89 should be commented as it's clearly not used (yet). Thayts ••• 16:42, 29 September 2019 (UTC)

Hi, Thayts, I stopped active work on Module:Wikidata over three years ago when I shifted my efforts into creating Module:WikidataIB specifically for use in infoboxes. The functions in there are now much more up-to-date and I'd really recommend using that in preference to this module, which contains an amalgamation of all sorts of code from different Wikipedias.

The Module:Wikidata/i18n returns an empty table, which is pretty much what I'd expect as the internationalisation for en-wiki is in lines 16–80. The point of the Module:Wikidata/i18n was to allow other wikis to create their own values, which would overwrite those in lines 16–80 as needed when the module was loaded. If you were to comment out line 89, that would mean that other wikis would have to re-enable it every time they do an update from here.

The code that used to handle it (without problem as far as I can recall) was changed in these edits, so I can't tell you what the reasoning was.

Instead, I suggest you check line 83 of Module:WikidataIB:

if 'en' ~= mw.getContentLanguage():getCode() then

which may offer a solution for you, while retaining the ability of non-English wikis to use the code from here, along with their own internationalisation from their version of Module:Wikidata/i18n. --RexxS (talk) 19:29, 29 September 2019 (UTC)

Alright. Well, I don't know how, but the error(s) suddenly disappeared. Thayts ••• 20:09, 29 September 2019 (UTC)

So this happened. Probably not related to this module then. Thayts ••• 07:05, 30 September 2019 (UTC)

@RexxS: Turns out I have to reconsider again. This is a problem with this module (as we found out). However, I don't have the rights to change this module... Thayts ••• 20:47, 30 September 2019 (UTC)

@Thayts: I've modified the code to only load Module:Wikidata/i18n on non-English wikis. See if that helps. --RexxS (talk) 21:04, 30 September 2019 (UTC)

That is not a solution for the other wikis, but alas. Thayts ••• 21:47, 30 September 2019 (UTC)

The real solution for other wikis is not to use this module. It has no regular maintainer and doesn't get updated. For example, it still uses the expensive mw.wikibase.getEntityObject() calls, which were replaced more than a year ago in Module:WikidataIB. --RexxS (talk) 23:38, 30 September 2019 (UTC)

It would be great if we had just one wikidata module and you all worked together to keep it maintained :) — Martin (MSGJ · talk) 10:54, 11 October 2019 (UTC)

Get a single QID

Hello. How can I get only the preferred value (i.e. limit to only the best ranked value), when using this code: {{#invoke:Wikidata|getPropertyIDs|P516|qid={{{qid|}}}|FETCH_WIKIDATA}}? I'm looking for something like the |rank=best and/or |maxvals=1 functions in Module:WikidataIB. Rehman 10:49, 13 October 2019 (UTC)

@Rehman: I've implemented the function in WikidataIB so that you should have full use of ranks, onlysourced, maxvals, sorted, etc. as usual.

• {{#invoke:WikidataIB/sandbox |getPropertyIDs |qid=Q151973 |P26 |fwd=ALL |osd=n}} → Q34851, Q7659507, Q16770428, Q34851, Q3469983

Let me know if any features are missing. I've set |noicon= to default to true but you can enable it with |noicon=false, if required. Cheers --RexxS (talk) 18:02, 13 October 2019 (UTC)

Thank you, RexxS. It works great! Rehman 02:33, 14 October 2019 (UTC)

Maxvals & inverted

Hi, I have two question :

First question :

{{#invoke:wd|properties|normal+|Q55|P1082}} display :"17,942,942, 17,590,672, 17,407,585, 17,282,163, 17,181,084, 17,081,507, 17,000,000, 16,829,289, 16,779,575, 10,026,773",

how can I display just three first number for to have just : "17,181,084, 16,829,289, 16,779,575" ?

I have unsuccessfully tested "maxvals" and "numval" :

{{#invoke:wd|properties|normal+|Q55|P1082|maxvals=3}} (display ever :"17,942,942, 17,590,672, 17,407,585, 17,282,163, 17,181,084, 17,081,507, 17,000,000, 16,829,289, 16,779,575, 10,026,773")

and

{{#invoke:wd|properties|normal+|Q55|P1082|numval=3}} (display ever :"17,942,942, 17,590,672, 17,407,585, 17,282,163, 17,181,084, 17,081,507, 17,000,000, 16,829,289, 16,779,575, 10,026,773")

Second question :

{{#invoke:wd|properties|normal+|Q55|P1082}} display :"17,942,942, 17,590,672, 17,407,585, 17,282,163, 17,181,084, 17,081,507, 17,000,000, 16,829,289, 16,779,575, 10,026,773",

how can I to reverse the chronological order for to display : "17,132,854 17,000,000, 10,026,773, 16,779,575, 16,829,289, 17,181,084" ?

I have unsuccessfully tested "sorttype = inverted" :

{{#invoke:wd|properties|normal+|Q55|P1082|sorttype = inverted}} (display ever :"17,942,942, 17,590,672, 17,407,585, 17,282,163, 17,181,084, 17,081,507, 17,000,000, 16,829,289, 16,779,575, 10,026,773")

My project is to do this table on page http://fr.wiki.x.io/wiki/Épidémie_de_maladie_à_coronavirus_de_2020_en_France#Localisation_des_cas to http://en.wiki.x.io/wiki/2020_coronavirus_outbreak_in_France.

Thanks, --Viruscorona2020 (talk) 08:24, 12 March 2020 (UTC)

Looking at both questions: Module:WikidataIB has the code to fetch the first 3 values:

• {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |noicon=y |qid=Q55 |P1082 |maxvals=3}} → 17,942,942, 17,590,672, 17,407,585

However, those will depend on the order that they are stored in Wikidata. The module has the code to sort property values, and to sort qualifier values, but it's not able to sort property values by qualifier value at present, mainly because of the logic difficulties of defining behaviour when there are multiple values of a single qualifier.

If you can find a module that does sort property values by qualifier values, then you could use a unique separator like "; " to return all of the values, and then use string handling functions to give you just three values. This example shows how you might use a string function to extract the first three sorted values:

• {{wdib|fwd=ALL|osd=n|noicon=y|qid=Q55|P1082|sep="; "|sorted=y}} → 10,026,773; 16,779,575; 16,829,289; 17,000,000; 17,081,507; 17,181,084; 17,282,163; 17,407,585; 17,590,672; 17,942,942
• {{#invoke:String |match |s={{wdib|fwd=ALL|osd=n|noicon=y|qid=Q55|P1082|sep="; "|sorted=y}} |pattern=[^;]*; [^;]*; [^;]* }} → 10,026,773; 16,779,575; 16,829,289

But, of course, the WikidataIB call ({{wdib}}) above sorts property values on property value, not property values on qualifier value. Perhaps someone knows a module that can do the sort you want. --RexxS (talk) 13:05, 12 March 2020 (UTC)

Deprecation

This module was marked as deprecated but has 487,638 transclusions. I'm assuming this most come from a few highly transcluded templates. Can anyone help finding those usages? It will give us a star start with converting to Module:WikidataIB and Module:Wd. --Gonnym (talk) 15:27, 2 January 2020 (UTC)

Here are the transclusions in template space. From that page, click on "links" next to any template name and then click "Transclusion count".

• {{Infobox AFL biography}}: 13,600
• {{Infobox CFL biography}}: 6,161
• {{Infobox Gaelic Athletic Association player}}: 4,187
• {{Infobox anatomy}}: 4,449
• {{Infobox award}}: 7,361
• {{Infobox book}}: 44,111
• {{Infobox college coach}}: 10,000
• {{Infobox lighthouse}}: 2,535
• {{Infobox religious building}}: 9,368
• {{Infobox volleyball biography}}: 4,734
• {{Wikidata sitelink}}: 6,819 (used in the "Expand xxx" templates, so if you get this one, at least 145 templates will be removed from the list)
• {{Wikisource author}}: 4,681
• {{Infobox video game}}: 24,086

That looks like about 150,000 transclusions. Start there, and if you get through that list, come back and I'll take another look. – Jonesey95 (talk) 17:23, 2 January 2020 (UTC)

Your assumption is probably correct; remaining requires uses are limited to sandboxes. I suppose someone could invoke the module through wikitext in a module by preprocessing, but I find that less likely (for the curious; most look like documentation and comments). --Izno (talk) 18:23, 2 January 2020 (UTC)

This is a search of template space for #invoke. There are some 200 templates using the module. --Izno (talk) 18:25, 2 January 2020 (UTC)

That's a good search. That led me to:

• {{Birth date}}: 269,902 transclusions
• {{Infobox power station}}: 2,471 transclusions
• {{Death date}}: 8,443 transclusions
• {{Birth year and age}}: 25,891 transclusions
• {{Wikidata redirect}}: 25,963 transclusions

Have fun! – Jonesey95 (talk) 18:36, 2 January 2020 (UTC)

Thanks for the lists!

Anyone know how to find an article that uses {{Infobox AFL biography}} and gets the image from wikidata? [2] fails. --Gonnym (talk) 18:43, 2 January 2020 (UTC)

Query for the presence of P3546 and P18 in the same item. I don't know how to do it. – Jonesey95 (talk) 23:28, 2 January 2020 (UTC)

@Gonnym: Looks like 25,260 results on Wikidata: see this query. I can't easily tell you how many of those have articles, though. --RexxS (talk) 23:57, 2 January 2020 (UTC)

P.S. Category:Pages using Wikidata property P3546 shows 13,302 articles using {{Infobox AFL biography}} and having a AustralianFootball.com player ID (P3546). You need the intersection of those two sets. --RexxS (talk) 00:01, 3 January 2020 (UTC)

Your first link helped me find an article that has a Wikidata:Q5214052 image. On Dan Moriarty (footballer, born 1875) I'm using {{#invoke:WikidataIB|getValue|P18}} on the page to test the code but it doesn't return the image. What am I doing wrong? --Gonnym (talk) 00:12, 3 January 2020 (UTC)

@Gonnym: Because WikidataIB|getValue is used in articles where the editors insist that fetching Wikidata has to be enabled (i.e. it is disabled by default), you always have to specify further parameters to enable the fetch. The simplest way is to use |ps=1 like this for Dan Moriarty (Q5214052):

• {{#invoke:WikidataIB|getValue|P18|ps=1|qid=Q5214052}} → Dan Moriarty (before 1903).jpg

Obviously, you don't need the qid if you're calling it from the article's own page. HTH --RexxS (talk) 00:22, 3 January 2020 (UTC)

Is |ps= missing from the doc? I couldn't find it there. Anyways, {{Infobox AFL biography/sandbox}} seems to work.

Deprecation progress

Template name	No. of transclusions	Test page(s)	Status
{{Infobox AFL biography}}	13,600	Dan Moriarty (footballer, born 1875)	Waiting sandbox review
{{Infobox CFL biography}}	6,161
{{Infobox Gaelic Athletic Association player}}	4,187
{{Infobox anatomy}}	4,449
{{Infobox award}}	7,361
{{Infobox book}}	44,111	The Red Pyramid (Library of Congress) Under Fire (Blackwood novel) (website) - Not able to get website to show using the infobox.	Waiting sandbox review
{{Infobox college coach}}	10,000
{{Infobox lighthouse}}	2,535
{{Infobox religious building}}	9,368
{{Infobox volleyball biography}}	4,734
{{Wikidata sitelink}}	6,819		Done
{{Wikisource author}}	4,681		Done
{{Infobox video game}}	24,086		Done
{{Birth date}}	269,902	Atia Abawi (no value on wikidata) Abraham Lincoln (has value)	Done
{{Infobox power station}}	2,471		Done
{{Death date}}	8,443		Done
{{Birth year and age}}	25,891		Done
{{Wikidata redirect}}	25,963	Abel	Done

Following the discussion at Template talk:Medical resources #Template-protected edit request on 3 December 2019, I was hopeful that somebody else would add the documentation for a change, so I apologise for not doing it sooner. It's documented now. There's probably no more than a handful of undocumented parameters and calls left now. --RexxS (talk) 18:01, 3 January 2020 (UTC)

I updated the "Deprecation progress" table above but I believe there are quite a few items missing from that table. For example, I can find many hits in searching template source for "FETCH_WIKIDATA". So far as I know only Module:Wikidata seems to use that sentinel value and that is definitely not an all inclusive use use of the module (as we can search in source for "#invoke:Wikidata|" or similar and go beyond "Template" namespace, etc.). —Uzume (talk) 03:04, 7 June 2020 (UTC)

Infobox AFL biography

When I remove the |image= value from Dan Moriarty (footballer, born 1875) (leaving a blank parameter), no image is shown, using either the live template or the sandbox template. It seems like an image should be shown. – Jonesey95 (talk) 16:16, 3 January 2020 (UTC)

Some template editors decide to code parameters as A|B which means that if A is there, even blank, it doesn't show B. I personally code with {{If empty |A |B }} which means that if A is empty, it checks B. I didn't change the syntax there, just the module invoke. --Gonnym (talk) 16:19, 3 January 2020 (UTC)

@Gonnym and Jonesey95: To produce its image, Template:Infobox AFL biography calls Module:InfoboxImage, which returns empty if the image parameter is missing or empty. So it should be no surprise that removing the value of |image= from an article results in no image. However, Module:WikidataIB treats a blank parameter the same as a missing parameter, so in the #invoke:InfoboxImage|InfoboxImage, if you use the syntax:

• |image={{#invoke:WikidataIB |getValue |P18 |ps=1 |maxvals=1 |{{{image|}}} }}

it will return the Wikidata value whenever |image= is empty or missing in the article. It relies on getValue always returning the local parameter if one is supplied to it as the second unnamed parameter, and is intended to simplify the template coding. This is possibly what Jonesey95 was looking for. --RexxS (talk) 17:52, 3 January 2020 (UTC)

That works for me in the sandbox. – Jonesey95 (talk) 18:10, 3 January 2020 (UTC)

Porting Guide

I think we need a porting guide. In many cases it is straightforward to change from {{#invoke:Wikidata|function}} to {{#invoke:WikidataIB|function}} but there are several interface functions (all functions that can be directly invoked by a template, i.e., returned functions that directly process frame arguments) that are not implemented in the later. Uzume (talk) 14:59, 16 April 2020 (UTC)

Conversions

{{#invoke:Wikidata|function}}	{{#invoke:WikidataIB|function}} or other options
{{#invoke:Wikidata|inspectI18n|...}}
{{#invoke:Wikidata|descriptionIn|...}}
{{#invoke:Wikidata|labelIn|...}}
{{#invoke:Wikidata|getValue|...}}	{{#invoke:WikidataIB|getValue|...}}
{{#invoke:Wikidata|getValueShortName|...}}	{{#invoke:WikidataIB|getValue|shortname=yes|...}}
{{#invoke:Wikidata|getValueFromID|...}}	{{#invoke:WikidataIB|getValue|qid= |...}}
{{#invoke:Wikidata|getRawValue|...}}	{{#invoke:WikidataIB|getValue|linked=no|...}}
{{#invoke:Wikidata|getUnits|...}}	use {{stringsplit}} to extract from getValue
{{#invoke:Wikidata|getUnitID|...}}
{{#invoke:Wikidata|getDateValue|...}}	{{#invoke:WikidataIB|getValue|...}}
{{#invoke:Wikidata|getImages|...}}	{{#invoke:WikidataIB|getValue|P18|linkprefix="File:"|linkpostfix="{{!}}{{{size|220px}}}"|sep=" "|...}}
{{#invoke:Wikidata|getImageLegend|...}}	{{#invoke:WikidataIB|getValue|P18|qual=P2096|qualsonly=y|...}}
{{#invoke:Wikidata|getTAValue|...}}	construct from getValue with |linkprefix= and |linkpostfix=
{{#invoke:Wikidata|getQualifierValue|...}}	{{#invoke:WikidataIB|getQualifierValue|...}} or {{#invoke:WikidataIB|getValue|qual= |qualsonly=y|...}} depending on use
{{#invoke:Wikidata|getRawQualifierValue|...}}	{{#invoke:WikidataIB|getValue|qual= |qualsonly=y|linked=n|...}}
{{#invoke:Wikidata|getQualifierDateValue|...}}	{{#invoke:WikidataIB|getValue|qual= |qualsonly=y|...}}
{{#invoke:Wikidata|pageId|...}}	{{#invoke:WikidataIB|pageId|...}} or {{#invoke:WikidataIB|getEntityFromTitle|...}} or {{#invoke:Wd|label|raw|...}}
{{#invoke:Wikidata|ViewSomething|...}}
{{#invoke:Wikidata|getSiteLink|...}}	{{#invoke:WikidataIB|getSiteLink|...}}
{{#invoke:Wikidata|Dump|...}}
{{#invoke:Wikidata|getPropertyIDs|...}}	{{#invoke:WikidataIB|getPropertyIDs|...}} or {{#invoke:Wd|properties|raw|...}}
{{#invoke:Wikidata|claim|...}}
|FETCH_WIKIDATA	|fwd=ALL or |ps=1 or |ps=2

The philosophy has shifted away from separate specific calls to handle linked items, dates, quantities, etc. toward customising getValue with parameters to deal with specific cases. An almost up-to-date list of parameters to getValue is at Module:WikidataIB/doc #Parameters to getValue. In particular, qualifiers are much better handled. The parameters linkprefix, linkpostfix, prefix, postfix, and the corresponding ones for qualifiers allow the construction of complex outputs containing internal or external links.

When experimenting, please remember that unless |fetchwikidata= (alias fwd) is set, nothing will be returned from getValue. Also by default, only sourced values (i.e. that have a reference other than a language Wikipedia) are returned unless |onlysourced= (alias osd) is set to no/false/0. The shortcut parameter |ps=1 will set |rank=best, |fetchwikidata=ALL, |onlysourced=no and |noicon=true, a common set to use when developing. The template {{wdib}} simply #invokes WikidataIB|getValue, so may make wikitext more readable.

Some specialised calls are implemented and documented at Module:WikidataIB/doc #Overview. Functions such as getPropOfProp, which returns the property values of property values, can be useful to reduce the template coding in some infoboxes. Also, there are some calls to help generate category titles, allowing an infobox to automatically add articles to a particular category. --RexxS (talk) 19:45, 16 April 2020 (UTC)

Yes, I realized things have changed but the idea is to come up with a porting guide and then move as much as possible off the older module. I am not surprised you would know much about them as you wrote most (if not all) of both of them. I might have to move this to a section on Module:Wikidata/doc Thanks for contributing. Uzume (talk) 04:25, 17 April 2020 (UTC)

Just stumbled here after spotting changes to Template:Infobox power station/sandbox by Uzume. In the future when this module is no longer used, it would be nice to see Module:WikidataIB renamed to Module:Wikidata. That sounds neater. Anyways, good luck! Rehman 13:38, 16 May 2020 (UTC)

My intention in developing Module:WikidataIB was to create a tool for template coders to use specifically for creating infoboxes in any language. As a result, it's in use on over 60 projects. Because many projects already had their own custom modules called Module:Wikidata, it's been quite fortuitous that WikidataIB is a unique name that doesn't clash with anything else when copied to other projects. It would be nice to think that at some point every project would be able to share a common codebase, but that doesn't look like happening anytime soon, particularly given enwiki's inherent insularity. Cheers --RexxS (talk) 22:32, 16 May 2020 (UTC)

getPropertyIDs

Hi Uzume and RexxS. Per the porting guide, I tried testing to change (1) to (2) for {{Infobox power station}}, but it doesn't seem to work:

1. {{#invoke:Wikidata|getPropertyIDs|P31|qid=Q5001029|FETCH_WIKIDATA}} → Q1003207
2. {{#invoke:WikidataIB|getPropertyIDs|P31|qid=Q5001029|ps=1}} →

Is this something that's still being implemented? And since we're on the topic, would it be possible to allow qualifiers to work this way as well? For instance, I want to get the QID of "longitude" in wikidata:Q15397819#P2043. Would this be possible? Rehman 08:02, 17 May 2020 (UTC)

@Rehman: I only implemented |ps= as a convenience for development work in getValue. All of the other related calls still have to use |fwd=ALL |osd=n, etc.

Because ps=1 and ps=2 let through unsourced data, they don't satisfy the Community's express wish that some assurance is given that information is reliable. That means the parameter sets are not generally suitable for production code on the English Wikipedia, so I didn't bother duplicating them in every call.

• {{#invoke:WikidataIB|getPropertyIDs|P31|qid=Q5001029|fwd=ALL|osd=n}} → Q1003207

I'll make a start on writing getQualifierIDs for you. --RexxS (talk) 15:59, 17 May 2020 (UTC)

@Rehman: I have some provisionally working code. It has an optional parameter |qlist= which is a free-form list of property-ids that it will match the qualifier properties against. It implements the usual parameters: fwd, osd, ranks, maxvals, etc.

• {{#invoke:WikidataIB |getQualifierIDs |fwd=ALL |osd=n |P2043 |qid=Q15397819}} →
• {{#invoke:WikidataIB |getQualifierIDs |fwd=ALL |osd=n |P2043 |qid=Q15397819 |qlist=}} →
• {{#invoke:WikidataIB |getQualifierIDs |fwd=ALL |osd=n |P2043 |qid=Q15397819 |qlist=All}} →
• {{#invoke:WikidataIB |getQualifierIDs |fwd=ALL |osd=n |P2043 |qid=Q15397819 |qlist=P7469}} →
• {{#invoke:WikidataIB |getQualifierIDs |fwd=ALL |osd=n |P2043 |qid=Q15397819 |qlist=P26}} →
• {{#invoke:WikidataIB |getQualifierIDs |fwd=ALL |osd=n |P2043 |qid=Q15397819 |qlist=P26, P7469}} →
• {{#invoke:WikidataIB |getQualifierIDs |fwd=ALL |osd=n |P2043 |qid=Q15397819 |qlist=P74691}} →

Would you be kind enough to test it in a few different cases that interest you and let me know if any problems crop up, please? --RexxS (talk) 19:28, 17 May 2020 (UTC)

Thank you for explaining ps and for the above feature, RexxS. I will test and update here again. Rehman 02:05, 18 May 2020 (UTC)

In the mean time, would you also be able to see why:

• {{#invoke:Wikidata|ViewSomething|labels|en|value}} → Hambantota Solar Power Station
• {{#invoke:WikidataIB |getLabel}} →

When previewing the code on Hambantota Solar Power Station? I could then change those instances as well. Rehman 03:06, 18 May 2020 (UTC)

The getLabel function only works with a supplied qid and does not fall back to the current page qid:

• {{#invoke:WikidataIB |getLabel |qid=Q5001029}} → Hambantota Solar Power Station

That call was designed to return nothing if no qid is supplied for use on Commons where we're often dealing with the qid/label for a category's main topic (different from the qid/label for the category, so we don't want fallback).

The label function does fall back to the current page, however:

• {{#invoke:WikidataIB |label |qid=Q5001029}} → Hambantota Solar Power Station
• {{#invoke:WikidataIB |label}} →

The last call works when previewed in Hambantota Solar Power Station. Cheers --RexxS (talk) 03:48, 18 May 2020 (UTC)

Nice! Thank you. I will get back regarding the test for getQualifierIDs. Cheers, Rehman 03:51, 18 May 2020 (UTC)

No issues with getQualifierIDs. Many thanks! Cheers, Rehman 17:13, 18 May 2020 (UTC)

Multilingual qualifier

How to get a specific value of a multilingual qualifier e.g. the official UNESCO name of Q351 in german? The function getQualifierSnak should use the parameter language if a qualifier is given, currently only the first matched entry is always returned (if qualifier then return qualifier[1] end).--Sinuhe20 (talk) 19:29, 16 July 2020 (UTC)

@Sinuhe20: You can do it with WikidataIB's getValue function:

• {{#invoke:WikidataIB |getValue |fwd=ALL |qid=Q351 |P1435 |qual=P1448 |qualsonly=y |lang=de}} → Nationalpark Yellowstone 

--RexxS (talk) 17:16, 9 September 2020 (UTC)