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)