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)