Jump to content

Module talk:Wikidata/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Module talk:Wikidata
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 05:42, 24 January 2019 (Archiving 1 discussion(s) from Module talk:Wikidata) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 1Archive 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):

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
AuthorGeorge Orwell Edit this on Wikidata
Pages92 Edit this on Wikidata
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 {{{1}}} on Wikidata - 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):
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

Wikidata has the property:

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 Edit this on Wikidata
Similarly
  • {{#invoke:WikidataIB |getQualifierValue |P793 |pval=Q385378 |qual=P582 |name=xyz |fetchwikidata=ALL }}
gives
  • February 2007 Edit this on Wikidata
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:

-- 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 Edit this on Wikidata
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
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 }} →
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:
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. Ladsgroupoverleg 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)

@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)

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)
  • {{#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) Edit this on Wikidata
  • {{wdib|P1082|qid=Q316500|fwd=ALL|rank=best|qual=P459}} → 263,048 (census) Edit this on Wikidata
  • {{wdib|P1082|qid=Q316500|fwd=ALL|rank=best|qual=P585}} → 263,048 (2020) Edit this on Wikidata
  • {{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}} → Lua error in Module:Coordinates at line 235: attempt to perform arithmetic on local 'degrees' (a nil value).
  • {{#invoke:Coordinates | dms2dec |{{#invoke:Wikidata|getValueFromID|Q85|P625|FETCH_WIKIDATA}}|lat}} → Lua error in Module:Coordinates at line 235: attempt to perform arithmetic on local 'degrees' (a nil value).
  • {{#invoke:Coordinates | dms2dec |30°3'22"N|lat}} → Lua error in Module:Coordinates at line 235: attempt to perform arithmetic on local 'degrees' (a nil value).
@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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Wikidata/Archive_2&oldid=879915170"