Module talk:Wikidata/Archive 1

Archive 1

Archive 2

Why

I don't quite get the point of this module. I though that a Wikidata property can simply be transcluded by using {{#property:pXXX}}, e.g. {{#property:p26}} returns "Hillary Rodham Clinton" (sans quotes) on Bill Clinton's page, and [[{{#property:p26}}]] returns as expected Hillary Rodham Clinton. So what does this module do that the straight use of properties doesn't?
PS & off-topic: When will property transclusion be available for items other than the calling page, i.e. {{#property:p26|of=Bill Clinton}} or {{#property:p26|id=Q1124}} -- Michael Bednarek (talk) 13:46, 29 August 2013 (UTC)

I have the same question as you. They're usefull to build a list of redlinks for certain projects. Bennylin (talk)

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. --RexxS (talk) 18:06, 22 September 2013 (UTC)

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, although I haven't tested in other languages yet. --RexxS (talk) 18:18, 22 September 2013 (UTC)

Article is not yet available in this wiki

I've altered the text returned when the article does not exist in the local wiki so that it displays the text of the Wikidata label for the entry, rather than Qnnnn. I've also changed the abbreviation marker that has the message "Article is not yet available in this wiki" as its title from small '?' to a normal '*' as I expect that to be less obtrusive for the reader if this module is called from an infobox, for example. --RexxS (talk) 11:56, 19 July 2014 (UTC)

Display en label if no article exists

For the sample

{{#invoke:Wikidata|getValue|p26|FETCH_WIKIDATA}}

when used in the article "Bill Clinton", is there a way to display a string with the English label of d:Q6294
if d:Q6294 had no link to Wikipedia? -- 签名 _sig at 21:20, 23 September 2013 (UTC)

Actually, it's "getRawValue". -- 签名 _sig at 21:26, 23 September 2013 (UTC)

Update: If there's no local article for a returned value, the "getValue" call should now display the localised label of the Wikidata entry - this is linked to the Wikidata entry so that there is somewhere for the reader to see more info if they want. There's a small marker that is an abbreviation for "Article is not yet available in this wiki" that should look like this: [*]

Is that any better? --RexxS (talk) 12:03, 19 July 2014 (UTC)

Connecting arbitrary page to Wikidata-item for testing

I made a sandbox page at Template:Infobox_drug/sandbox3. I am testing the infobox here: User:Tobias1984/Infobox drug test Is there any way to pretend-connect the page with the WD-item for Warfarin, so I don't see the template error? --Tobias1984 (talk) 09:42, 22 October 2014 (UTC)

You can't pretend-connect pages. You should connect Wikidata's sandbox item to a page in your userspace if you need to test temporarily. Jackmcbarn (talk) 11:59, 22 October 2014 (UTC)

You can use Special:ExpandTemplates for a very basic "pretend-connect pages". --Mps (talk) 13:42, 22 October 2014 (UTC)

Date error for years of 1st century

Trying to fetch a date value of the first century defined only with year it returns a date format error. Checked on Abgar V with {{#invoke:Wikidata|getDateValue|p570|FETCH_WIKIDATA}} (p570=50) while it works on Martial (p570=104) or Nero (p570=7 June 68). Not sure if this can be fixed here or it should be reported on Wikidata. --Vriullop (talk) 15:17, 17 July 2014 (UTC)

The problem occurs because wikidata - for some reason - internally stores the dates 50 CE and 104 CE in different length strings:

+000000050-01-01T00:00:00Z
+00000000104-01-01T00:00:00Z

I can fix that here but there will still be the problem that Wikidata stores 50 CE as 1 January 50 (likewise for 104 CE of course). Without a qualifier that shows the precision of the stored value, I don't know how to differentiate the returned value from an actual date of 1 January YYYY. Perhaps there's some discussion already over at Wikidata? --RexxS (talk) 16:07, 17 July 2014 (UTC)

I've implemented a modification to deal with years <100. I suppose we ought to deal with BCE dates. How would this best be done: append 'BCE' or 'BC' or pass another flag to fit the usage in the article (as we do with dmy/mdy)? --RexxS (talk) 16:30, 17 July 2014 (UTC)

Thanks. Commented at d:Wikidata:Project chat#Date format for years<100. --Vriullop (talk) 19:44, 17 July 2014 (UTC)

Was the BCE question ever resolved? I'm doing something like this:

    local birthtable = entity:formatPropertyValues( 'P569' )
    local birthsplit = mw.text.split(birthtable["value"], " ")
    local l, count = mw.ustring.gsub(birthtable["value"], "%S+", "") -- count = number of words
    if string.find(birthsplit[count], "^%d") then
      birth = birthsplit[count]
    elseif string.find(birthsplit[count], "BCE") then
      birth = birthsplit[count - 1]
    end

It looks at the value of the Birth ID (P569), which might be "4 January 54 BCE" or "6 May 2001" .. takes the last word and checks if it's a number or word, if a number then returns the last word ("2001"), if the later then return the second to last word ("54"). I don't know how robust this is but seems to be working. -- GreenC 15:32, 15 October 2014 (UTC)

That's a sensible implementation and looks robust. It does rely on entity:formatPropertyValues() to provide 'BCE' from the raw string that is stored, so it won't use 'BC' as far as I can see. You may find that you need to offer 'BC' as an option for use in articles where that is the style used. Cheers --RexxS (talk) 12:37, 16 October 2014 (UTC)

Might run into problems with "12th. Century" or "ca. 1890s" and other outlier date formats. That's separate from the BC question but same general problem. -- GreenC 17:24, 22 October 2014 (UTC)

Sources from Wikidata

Is it already possible to get the source from Wikidata with this module? The German module for Wikidata seems to have a function for it "function getReferences(claim)". @Mps and JakobVoss: Is that possible to add that here? --Tobias1984 (talk) 09:38, 22 October 2014 (UTC)

As far as I see it is not possible with the current state of the English module. The main issue with with the English module is that it does not support all data types provided by Wikidata, only strings, Wikidata links and dates (partially), but not the "novalues" datatype, the "somevalue" datatype, times, numbers, coordinates, monolingual text, or parts thereof. Also the user needs to select which module method to use based on the date type. The module also ignores the rankings and sorting orders. The German module is doing all of this automatically. For the sources this is important, as these may use all data types. So the short version is: additionally to getReferences one would also need to add the complete datatype handling of the German version. On a side note, this would also solve the #Qualifiers question from above.

The documentation for the German version can be found under de:Wikipedia:Lua/Modul/Wikidata/de#claim: its in German but the examples ("Beispiele") there should be understandable nonetheless. --Mps (talk) 12:37, 22 October 2014 (UTC)

@Mps: Thank you for the detailed answer. I will try if I can include those parts in the en-wiki module. Deutsch wird nicht das größte Problem sein :) -Tobias1984 (talk) 09:58, 23 October 2014 (UTC)

Linking to Wikidata

@RexxS: I would like to put a link at the bottom of an infobox that says "Edit data on Wikidata" and that should link to the connected Wikidata-item. Is that possible yet? ---Tobias1984 (talk) 15:35, 21 October 2014 (UTC)

The entry in the toolbox that says 'Wikidata item' obviously has a means of retrieving the Q value associated with the current page. Sadly, I'm not aware of a call to the API that does that job for us yet - although the opposite (finding an article label from its Q value) has been available for quite some time. Perhaps somebody can suggest a work-around? --RexxS (talk) 15:33, 23 October 2014 (UTC)

The Q value of the current page can be retrieved by calling mw.wikibase.getEntityObject().id. --Mps (talk) 16:41, 23 October 2014 (UTC)

For better convenience I added a pageId function to this module. --Mps (talk) 16:50, 23 October 2014 (UTC)

@Mps: Thanks a lot. I tested it and it works perfectly. I also added an example to the documentation. -Tobias1984 (talk) 17:52, 23 October 2014 (UTC)

getDateValue issue

There's a little problem inside getDateValue fuction in Module:Wikidata. If the qualifier contains only a year, function prints 1 January 1986 instead of 1986.

{{#invoke:Wikidata|getDateValue|P577|{{{published|FETCH_WIKIDATA}}}}}

--Rezonansowy (talk | contribs) 11:41, 25 October 2014 (UTC)

Maybe some admin could help. Someone from WP:Lua. --Rezonansowy_akaRezy (talk | contribs) 12:00, 18 February 2015 (UTC)

@Rezonansowy: Admins are not necessarilyly technically qualified - you would do better to ask at WP:VPT where the gurus hang out or, if that fails, at the talk page WT:LUA. JohnCD (talk) 12:04, 18 February 2015 (UTC)

The problem is that Wikidata actually stores a year such as 1986 as the date 1 January 1986. Sadly, there's no way knowing whether the stored value was actually meant to be that date or the year. Would you like me to add a call that stripped the date down to the year? You'd have to decide then to use that call rather than requesting a date value, of course. --RexxS (talk) 18:09, 18 February 2015 (UTC)

Update: I had a look and somebody had already done the job more elegantly. If you supply a third parameter to getDateValue then it sets the date format. The option to use 'y' for just the year has been added. Try:

{{#invoke:Wikidata|getDateValue|P577|{{{published|FETCH_WIKIDATA}}}|y}}

Does that solve the problem for you or is there something more? I'll update the examples in the documentation in any case. --RexxS (talk) 18:24, 18 February 2015 (UTC)

Translate error messages

The error messages are in German. Would be nice if someone could translate those... --Lucie Kaffee (WMDE) (talk) 13:20, 27 February 2015 (UTC)

Data type in getRawQualifierValue

A possible bug is discussed at Wikipedia:Village pump (technical)/Archive 135#Wikidata problem. PrimeHunter (talk) 21:06, 1 March 2015 (UTC)

(copied from Village pump (technical) to make sure it stays visible for this module)

The more I've looked at this, the more I become convinced that you can't write a generic call to fetch just the value of a given qualifier associated with a given property because of the possibility of multiple values. For example, if you look at Richard Burton (d:Q151973), he has 3 spouses (P26) listed, two of whom have qualifiers for start time (P580) and end time (P582). What should a call asking for Richard Burton's spouse's start time return? Should it return nil for Elizabeth Taylor? or 3 July 1983 for Sally Burton? or 1949 for Sybil Christopher? Of course we could have it return 1949 and 3 July 1983, but what value would they be without knowing which spouse they referred to? It would be possible to write a call that fetched e.g. the value of first given qualifier from the first given property, but that becomes vulnerable to someone adding another value for the property. How would you want to deal with the situation if Santa Fe (d:Q316370) had 30 sitios -- Wikidata shows it has 10 Barangays by using the property "has part(P527)=barangay" with the qualifier "quantity(P1114)=10" -- and someone added "has part=sitio" with a qualifier of "quantity=30"? Should getRawQualifierValue|P527|P1114 return 10 or 30? Sorry to be negative about the problem, but I can't see a general solution. --RexxS (talk) 14:50, 2 March 2015 (UTC)

Is it possible to get value(s) in structured tree by this Module?

What I want to ask is... for example, frontal lobe (d:Q749520) has structured data tree as follows.

• frontal lobe (d:Q749520) -> described by source (d:P:P1343) -> Gray's Anatomy (20th edition) (d:Q19558994) -> page (d:P:P304) -> 821

In this case, can we get value "821" by Module:Wikidata?

Motivation of the question is... now there is a discussion about "Which is best way to store data. Creating new property or using structure?" for Gray's Anatomy text page data, at property proposal (wikidata:Wikidata:Property_proposal/Natural_science#Gray.27s_Anatomy_1918_page). So I want to know whether it is possible to get value the data in structured tree. Thank you! --Was a bee (talk) 16:34, 17 March 2015 (UTC)

I added some diagnostic method V to get anything. Try this {{#invoke:Wikidata|V|claims|P1343|1|qualifiers|P304|1|datavalue|value}}. Paweł Ziemian (talk) 18:51, 17 March 2015 (UTC)

Wow! Paweł, thank you very much for new code. This would help the project very much! --Was a bee (talk) 20:52, 17 March 2015 (UTC)

@Paweł Ziemian: I experimented that code at article "Frontal lobe", and I can get page data "821"! That works nicely. Thank you very much. Then, but, can I get data at reference URL (d:P:P854) section? I tried some variations of your code above, but I can't retrieve the URL data (for example, "http://www.bartleby.com/107/189.html#58"). Is there any key? or Storing data in reference section is not appropriate? Thank you.--Was a bee (talk) 17:23, 20 March 2015 (UTC)

Added another function {{#invoke:Wikidata|Dump|claims}} to spy the structured data. It uses the same arguments as V. Try this with preview only to see results. That helps me a lot in developing Lua scripts that access the data. If used without arguments (here claims) it dumps everything including labels, descriptions and interwiki links. Paweł Ziemian (talk) 17:46, 20 March 2015 (UTC)

Oh.. so awesome. I figured out how to retrieve data through V function. I can retrieve a (first) URL and title in reference section by this code.

• {{#invoke:Wikidata|V|claims|P1343|1|references|1|snaks|P854|1|datavalue|value}} (first) URL in reference section
• {{#invoke:Wikidata|V|claims|P1343|1|references|1|snaks|P1476|1|datavalue|value|text}} (first) title in reference section

Thank you @Paweł: very very much! P.S. Though I don't know why you named the function as V, it would be better if the name is more longer and easier to search, wouldn't it? I think your function would be used in wide and various situations. Thanks. --Was a bee (talk) 20:08, 20 March 2015 (UTC)

I don't mind if you change the name. It is short time the function was introduced so there is no risk in it. I choose one letter after ViewSomething to avoid a lot of typing. Paweł Ziemian (talk) 20:41, 20 March 2015 (UTC)

Fucntion name was changed from V to its full style ViewSomething. I like the name because it shows what this function can do concisely. Thanks! --Was a bee (talk) 00:57, 21 March 2015 (UTC)

Not correct result for qualifier from the claim function

When I use {{#invoke:Wikidata|claim|P225|qualifier=P574}} I expect to get qualifier d:Property:P574 from property d:Property:P225 for example for d:Q243242, but I receive 1767 which is not the correct value of the qualifier (1768). Is this a bug? --Termininja 07:42, 29 April 2015 (UTC)

Yes it is a bug. The data stored can be examined with {{#invoke:Wikidata|Dump|claims}} and it shows it is stored correctly:

["P574"] = table#97 {
  table#98 {
	["datatype"] = "time",
	["datavalue"] = table#99 {
	  ["type"] = "time",
	  ["value"] = table#100 {
		["after"] = 0,
		["before"] = 0,
		["calendarmodel"] = "http://www.wikidata.org/entity/Q1985727",
		["precision"] = 9,
		["time"] = "+00000001768-00-00T00:00:00Z",
		["timezone"] = 0,
	  },
	},
	["hash"] = "a80524ae0ea81065106bbb27209f52f2a74f35f3",
	["property"] = "P574",
	["snaktype"] = "value",
  },
},

In fact the (undocumented) "parameter" parameter in the claim function can be invoked to check a date/time value like this: {{#invoke:Wikidata|claim|P225|qualifier=P574|parameter=time}} - which returns 1768-00-00T00:00:00Z when tested at European green toad. This shows the claim function is working up to a point. I suspect that there's something not quite right in the formatDate function and it may have to do with having a timezone affecting a date that should be an exact year (precision=9), but haven't the time right now to track it down. I'll ping @Tobias1984: who imported the code from de-wiki to see if he can shed any light on it. --RexxS (talk) 21:02, 29 April 2015 (UTC)

You are right, I found that the problem comes on line 369 (the last return in the formatDate function): mw.language.new(wiki.langcode):formatDate(formatstr, date). In our case we have: mw.language.new('en'):formatDate('Y', '1768-00-00T00:00:00Z') = 1767. I found also that this will work if we have a date format with month and day different from 00, for example '1768-01-01T00:00:00Z'. But better variant I think is for precision >= 9 to make date = year, then mw.language.new('en'):formatDate('Y', 1768) = 1768 --Termininja 12:32, 30 April 2015 (UTC)

I've made a quick&dirty fix for the case when precision is year and so we expect just a year by isolating the case when (precision == 9). There's no internationalisation, but no doubt it could added if anyone thought that a simple year value would benefit from it (although I don't think we adjust for non-Gregorian calendars, or do we?). {{#invoke:Wikidata|claim|P225|qualifier=P574}} works now at European green toad, returning 1768 as expected. Perhaps you can check it at other articles that you are working with? Cheers --RexxS (talk) 15:20, 30 April 2015 (UTC)

Yes, now is ok :) --Termininja 17:01, 30 April 2015 (UTC)

Bacalar (municipality) error

Bacalar (municipality) has a Lua error, . Looking at the code it does look wrong as v2 is undefined but it’s unclear what to replace it with. No obvious change triggered this, but somehow it’s now hitting this code.--JohnBlackburne^words_deeds 22:16, 4 June 2015 (UTC)

Well, it is Friday - probably another API change. Alakzi (talk) 22:32, 4 June 2015 (UTC) I might have to take the blame for this one. Anyway, fixed. Alakzi (talk) 22:36, 4 June 2015 (UTC)

Request for comments on "edit in Wikidata" links, for templates using Wikidata

You are invited to join the discussion at Wikipedia talk:Wikidata#Edit in Wikidata links. Thanks. Evad37 [talk] 01:46, 5 June 2015 (UTC)

Fetching years BC

If I try {{#invoke:Wikidata|getDateValue|P569|FETCH_WIKIDATA|y}} to get the birth year as documented at Module:Wikidata#Testing getValue, getRawValue and getDateValue, on page Horace it returns "Lua error: mw.language:formatDate() only supports years from 0". --Vriullop (talk) 14:52, 14 June 2015 (UTC)

That's true. There has been some discussion about the fact that Wikidata doesn't store dates BC in line with the extended ISO 8601 standard, so I left that part of the code to see if that would change. It hasn't changed yet, and if there is now a need for the module to return dates BC, I'll implement a mechanism for doing that - give me an hour or so. I should warn you that if the way that Wikidata stores dates changes again - it last changed sometime around the beginning of last month - then we may possibly have to revisit this. Perhaps you can keep an eye on Horace and note any problems here? --RexxS (talk) 16:00, 14 June 2015 (UTC)

Update: I've modified the code to deal with negative dates. The suffix is "BC" by default, but adding a fourth parameter will override that. I've also taken the opportunity to suppress leading zeros when the display is just a year. Try

• {{#invoke:Wikidata|getDateValue|P569|FETCH_WIKIDATA|y}}

and

• {{#invoke:Wikidata|getDateValue|P569|FETCH_WIKIDATA|y|BCE}}

in Horace now and see if it gives the result you want. Any problems, please note here. Cheers --RexxS (talk) 17:14, 14 June 2015 (UTC)

Thanks. It works fine. It is currently used in ca.wiki for categorizing by death year. If the format changes again it will be noted soon. --Vriullop (talk) 17:40, 14 June 2015 (UTC)

Is it possible to call single value from the property which has multiple values?

Is it possible to call single value or each values one by one, from the property which has multiple values? What i wnat to ask is...

For example, code {{#invoke:Wikidata|getValue|p26|FETCH_WIKIDATA}} in Richard Burton (wikidata:Q151973) returns

-Sally Burton, Sybil Christopher, Elizabeth Taylor

This is because of 'spouse' property at wikidata:Q151973 has 3 values. In such situation, can we get single value from WikiData? (for example only first one), like...

-Sally Burton

Motivation of this question is as follows. Now I am maintaining anatomical property which could have multiple values (wikidata:Property_talk:P1323#Multiple values). But link syntax in infobox template ({{infobox anatomy}} using {{TA98}}) doesn't go well if P1323 has multipul values. So I'm wondering whether there is a method to avoiding the problem. Thank you for reading. --Was a bee (talk) 01:20, 21 September 2014 (UTC)

The module was originally intended to return multiple values, each individually linked to the relevant article. There is a getRawValue call that just returns values unlinked, if that is any help to you. The problem that I foresee with trying to return just one value is in determining which one you want when there are multiple values? To take your example, how would we know whether you want "Sally Burton" or "Sybil Christopher" or "Elizabeth Taylor"? I could easily add another call to simply return the first value stored, but would that always be the one you want? --RexxS (talk) 03:04, 21 September 2014 (UTC)

@Was a bee: I've created a call in this module that returns the formatted links and text for TA98 directly, bypassing the {{TA98}} template. I've modified Template:Infobox anatomy to use the call. It looks ok in Ear, for example, which has two TA98 values. Human nose seems ok with just one TA98 value. Do you have any different test cases? (I do need to get rid of the html break, but I can do that later). --RexxS (talk) 23:26, 21 September 2014 (UTC)

Wow! thank you @RexxS:! That is exactly what I hoped for. I have tested 3 values case at Ear article, and that worked. It seems all fine. I'll care how this update works in various situations. Again, thank you RexxS. --Was a bee (talk) 02:08, 22 September 2014 (UTC)

@RexxS:, does this work more generally? It seems that some wikidata entries have multiple image entries, e.g. [1], and it would be good to have the option to only return the entry that has a 'preferred' rank, where that exists. Thanks. Mike Peel (talk) 19:36, 17 June 2015 (UTC)

The call to getValue makes use of the library function 'formatPropertyValues', which by default only returns the best values - i.e. only "preferred" if it exists, otherwise only "normal". I tried {{#invoke:Wikidata|getValue|P18|FETCH_WIKIDATA}} in Atacama Cosmology Telescope and it only returns "Atacama cosmology telescope toco.jpg" (in plain text, but [[File:{{#invoke:Wikidata|getValue|P18|FETCH_WIKIDATA}}]] works as expected). Does that help? --RexxS (talk) 11:47, 18 June 2015 (UTC)

@RexxS: that's because I made this edit to remove the second picture. Try reverting that and trying the module calls again! Thanks. Mike Peel (talk) 16:27, 20 June 2015 (UTC)

Ok, Mike, I've restored two images to d:Q753067. I can see what was happening - the call to 'formatPropertyValues' was set to return all values, not just the best values. By a stroke of luck, both getValue and getRawValue did the same thing; I've now changed it so that getValue only returns the best values when the property is not a linkable item, but getRawValues still returns all values. Check the difference between

• {{#invoke:Wikidata|getValue|P18|FETCH_WIKIDATA}}

and

• {{#invoke:Wikidata|getRawValue|P18|FETCH_WIKIDATA}}

in Atacama Cosmology Telescope. Does that give you the flexibility you wanted? --RexxS (talk) 18:30, 20 June 2015 (UTC)

I think so, thanks! Mike Peel (talk) 18:33, 20 June 2015 (UTC)

Offset in months?

@DSGalaktos has pointed out that months are being offset by -1 month through this template: wikidata:Q1513315 has a start build time of November 2006 and an end time of February 2007, but these are appearing in South Pole Telescope as October 2006 and January 2007 respectively. Any ideas why this is happening? Thanks. Mike Peel (talk) 20:25, 3 July 2015 (UTC)

Also see [2]! Thanks. Mike Peel (talk) 20:27, 3 July 2015 (UTC)

Wikibase gives a day value of "00", which Scribunto's formatDate parses as the last day of the previous month; therefore, "2006-11-00" becomes "2006-10-31". Alakzi (talk) 20:39, 3 July 2015 (UTC)

The work-around is to input dates including a day of the month and set the precision to 'month', so setting "1 November 2006 (precision: month)" and "1 February 2007 (precision: month)" in d:Q1513315 gives the correct display in South Pole Telescope. --RexxS (talk) 02:38, 4 July 2015 (UTC)

Thanks for the work-around! Rather than using this work-around everywhere (which is susceptible to mistakes), would it be easier to check the date and add one to the day of the month if it's 0? Are there any cases where that could happen deliberately? Thanks. Mike Peel (talk) 21:03, 4 July 2015 (UTC)

Somebody should just get Wikibase to stop mangling dates. If we shove any more hacks into this module, it might just come crumbling down. Alakzi (talk) 22:47, 4 July 2015 (UTC)

@Alakzi: will you be at Wikimania this year? Perhaps that would be a good opportunity to try to resolve some of the issues like this. Thanks. Mike Peel (talk) 23:24, 4 July 2015 (UTC)

It's a fundamental problem of how we store and interpret dates. At present the interface allows a date to be stored as a timestamp with a month and/or day set to '00'. One way of looking at that is the zero value represents an unknown value, but we really don't want to be doing that, in my humble opinion, because we already store a precision along with the timestamp that tells the reader what part of the date is known. If we force the timestamp to be a valid date (by always supplying a day and month) then we have data that is cleaner, in the sense that we can apply date functions and parsers that assume the date is valid. We owe it to third-parties to make the data in Wikidata as usable as possible. We ought to be discouraging any timestamps that look like "2015-00-00", because nobody needs that value and most of us can't use it .

If you like, we could test for zero month and zero day and replace them with ones, but that complicates what is presently a simple (and otherwise robust) formatting routine. The downside is that every module and every re-user will end up doing the same data validation. Logic says that data validation is almost always most efficient on input, not output. --RexxS (talk) 00:19, 5 July 2015 (UTC)

I didn't even know it's in two weeks' time! Alakzi (talk) 03:01, 5 July 2015 (UTC)

mw.wikibase.entity:getBestStatements

For those managing this module (jackmcbarn +++), it would great if the module was able to be updated to either use getBestStatements as the default or as an option to pull data from Wikidata. I was pointed to mw:Extension:Wikibase Client/Lua for new bits with mw.wikibase.entity and getBestStatements . Thanks for what you can do, as then Wikisource can pull your version to maintain consistency of development. :-))) 14:38, 5 August 2015 (UTC)

I can't see how mw.wikibase.entity:getBestStatements( propertyId ) differs from mw.wikibase.entity:formatPropertyValues( propertyLabelOrId ), as by default the latter returns only the best values. The call to getValue in this module should already only be returning the best claims as discussed above at #Is it possible to call single value from the property which has multiple values?. If you can give me an example of where it doesn't do that, I'll try to fix it. Cheers --RexxS (talk) 22:46, 5 August 2015 (UTC)

Getting the nation of the born place for a biography

Hello!

I will try to explain this experiment with an example. I'm working on a fully automatized biography template for Basque Wikipedia. After some research on my own, I got this here eu:Patrice de Mac-Mahon using this eu:Txantilioi:Biografia infotaula automatikoa. Some of the parts have been created using some tricks, but I'm quite stuck on getting the country where the born place of a person is. For example, here I called

{{#invoke:Wikidata|getValue|P19|FETCH_WIKIDATA}}

to get that Patrice de Mac-Mahon was botn in Sully... but can't get after the comma that Sully is part of France. I've manually tried to invoke this:

{{#invoke:Wikidata|getRawQualifierValue|P17|Q1424681|FETCH_WIKIDATA}}

But of course, is not working. Furthermore, I would need to have automatically the ID of Sully, and I'm a bit lost with this. -Theklan (talk) 23:33, 5 April 2015 (UTC)

Hi, I don't know if you watch the Wikidata development but it is not possible to access arbitrary Wikidata items, you can only access the connected one. I.e. you cannot get a country for an item a person was born in if you are at the page for the person. I'm sure it will come very soon. Matěj Suchánek (talk) 18:21, 8 April 2015 (UTC)

Hi, arbitrary access is now working, but a question. How might you gain access to the Q id needed to compose a nested request like this? For example, (1) an article about a person 'Joe' is linked to wikidata item that has a claim on it like 'birthplace New York' and you would like to display information about the population of New York on the article about Joe. It would be really powerful to be able to do this sort of thing based on looking up the Qid by inspecting the results of the property request rather than needing to know the Qid of New York in advance to make it work. We have a key use case for this in molecular biology. gene item -> encodes prop -> protein item -> cell component prop -> nucleus item. Given that chain, we would like to be able to show the information about the cell component property on the article tied to the gene. It seems like this should definitely be possible but I haven't figured out the trick yet. (using the gene RREB1 for testing). Any help greatly appreciated. --Benjamin Good (talk) 05:11, 17 September 2015 (UTC)

I always find the first thing to do is use {{#invoke:Wikidata|Dump|claims}} to get a full dump of the Wikidata related to a given article, so that you can see where the value you want is inside the structure. Taking your example, I'd recommend first looking at the dump for "Joe" to see how you can get at the Qid for his birthplace, then look at the dump for "New York" to see where and how the population information is stored. Once you can see the place of the data in the structure of the entry, you can start constructing Lua functions to retrieve that data in the format you want. You can now use your user sandbox as a testing environment for the invocations of any functions you write; or you can use the trick of pasting the #invoke into an article and previewing (but not saving it). --RexxS (talk) 15:45, 17 September 2015 (UTC)

Thanks RexxS, I started down that road last night. I think it would be really enabling if we could extend the core 'getValue' function here to optionally return the Qid rather than the label of the value for the property. With that function, these kinds of nested requests should be pretty easy. Guess its time to learn Lua.. --Benjamin Good (talk) 16:28, 17 September 2015 (UTC)

Okay, I've created a function in my module sandbox as an example that should do what you want. Try:

• {{#invoke:Sandbox/RexxS/AA |getQIDFromID |Q151973 |P26}}

which should fetch the QID of the first value for the spouse (P26) of Richard Burton (Q151973):

• Q34851

That returns Q34851 and d:Q34851 is indeed Elizabeth Taylor. You should be able to pick Lua up quite quickly if you've done any programming. Help:Lua isn't a bad starting point - or follow the documentation as you read through a working module. Feel free to take, modify and re-use any of my code if you can find a use for it. Cheers --RexxS (talk) 17:50, 17 September 2015 (UTC)

Testing environment

Is there any way to set up a testing environment for this module, to see how changes affect the content of different pages? --Tobias1984 (talk) 19:55, 10 May 2015 (UTC)

Not yet. I'm expecting any day now that the devs will add the ability to call up data from pages other than the one from where the module is invoked. In the meantime, I simply paste the relevant {{#invoke|Wikidata|...}} (or more likely {{#invoke|Wikidata/Sandbox|...}}) into a short section of the article I want to test and preview it without saving. Not efficient, but it works. Cheers --RexxS (talk) 20:55, 10 May 2015 (UTC)

Actually, this functionality, which Wikidatans and the Wikidata dev team are calling "arbitrary access", is beginning rollout in a very limited sense to a handful of wikis this week (one degree of separation i.e. I can get United States data from Oregon since those are two linked items in Wikidata, but to get information from say United States census on Oregon is not possible yet). See this announcement on wikidata-l. --Izno (talk) 21:27, 10 May 2015 (UTC)

I've been looking at how we might implement arbitrary access and I have a sandbox module at Module:Sandbox/RexxS/AA. Testing it out using {{#invoke:Sandbox/RexxS/AA|getValueFromID|Q151973|P26|FETCH_WIKIDATA}} - to fetch the values of 'spouse' (P26) from 'Richard Burton' (Q151973) - works when previewing at Richard Burton, but obviously fails at the moment when invoked from my sandbox User:RexxS/sandbox with an error message "Access to arbitrary items has been disabled". Interestingly, it also works when previewing at nl:Richard Burton (acteur), and works when invoked from nl:Gebruiker:RexxS/Kladblok. Sadly I don't speak enough Dutch to be comfortable with using this as a testing environment, but others might. --RexxS (talk) 22:18, 11 May 2015 (UTC)

Would it be possible to use this to nest arbitrary access. For instance I wanted the coordinate location of Richard Burton's place of birth. Julialturner (talk) 04:37, 22 September 2015 (UTC)

Yes, we can now. We would need to have a Lua call that took an extra parameter for the indirectly referenced property ('coordinate location' is P625) and could then return that property's value for Burton's 'place of birth' (P19). Unfortunately, we would need to ensure that each property had a value at each step and that the value is valid for the purpose intended. At present, Burton's place of birth in Wikidata is given as Wales (d:Q25), rather than the more precise Pontrhydyfen (d:Q3072939). This would result in the erroneous return of the coordinates of (52°20'58.56"N, 3°38'16.26"W), which is an astonishingly precise location for Wales, but the Dutch Wikipedia says it's true. So how would we spot that we have invalid data returned? Without assured quality of data in Wikidata, tracking down errors of this sort becomes much more difficult once we move to indirectly accessing the data via other data. --RexxS (talk) 16:42, 22 September 2015 (UTC)

Units

Wikidata now has units, yay. :-) As a test, I've added the elevation above sea level to d:Q1513315, and added the standard invocation to Template:Infobox telescope, but at South Pole Telescope it's appearing as "Altitude: 2.8±0.1 http://www.wikidata.org/entity/Q828224" - could the module be updated to show the unit rather than the wikidata URL please? Thanks. Mike Peel (talk) 20:15, 15 September 2015 (UTC)

FTR, this was tracked as T112737, and has been fixed for now (displays the label of the unit), though it can still be improved (display a short version instead of the full label – “km” instead of “kilometre”). —Galaktos (talk) 21:55, 22 September 2015 (UTC)

That's great, thanks! BTW, there's a discussion about the assumed uncertainties going on at T105623 (in the example above, the ±0.1 was assumed by Wikidata, and is incorrect). Thanks. Mike Peel (talk) 07:57, 23 September 2015 (UTC)

Compatible Templates

Are there any pre-existing templates that work well with the output of this module or that take a comma delimited list as input? Thanks. Julialturner (talk) 20:06, 28 September 2015 (UTC)

Well, it was designed originally to work with infoboxes (which are templates, of course), because that is the only area where we have consent for the community to include data drawn from Wikidata. That's why the calls like getValue take a parameter which is one of: a local value, which is returned instead of the Wikidata value; FETCH_WIKIDATA, which explicitly returns the value from Wikidata; or blank, which returns blank and results in the infobox not displaying that row. Specialised calls have been written on request to cater for numerous special cases like Terminologia Anatomica. What use were you thinking of? and I'll see if I can help. --RexxS (talk) 20:22, 28 September 2015 (UTC)

I have a list of images that I want to be able to display nicely in an infobox. Currently, I am pulling each one out via {{#invoke:Wikidata|ViewSomething|claims|P692|1|mainsnak|datavalue|value}} (d:Q18031325) for each of three images. However, I would like something more flexible if I had more/less images. I was hoping someone had already come across something similar. Julialturner (talk) 21:22, 28 September 2015 (UTC)

Using {{#invoke:Wikidata|getValue|P692|FETCH_WIKIDATA}} produces a comma separated list of the filenames on Commons: PBB GE RREB1 gnf1h02462 at tn.png, PBB GE RREB1 203704 s at tn.png, PBB GE RREB1 217411 s at tn.png. I've made a draft of a function at Module:Sandbox/RexxS/GetImages that returns all of the images in a standard wiki image syntax with default separator of space and default size of 220px. You can try the call by previewing it anywhere in the article RREB1:

• {{#invoke:Sandbox/RexxS/GetImages|getImages|P692|FETCH_WIKIDATA}}

For use in your infobox, you may want to supply parameters for separator and size:

• {{#invoke:Sandbox/RexxS/GetImages|getImages|P692|FETCH_WIKIDATA|<br>|250px}}

Is that the sort of thing you want? If so, I could incorporate it into this module. --RexxS (talk) 14:07, 30 September 2015 (UTC)

That is perfect and exactly what I was looking for. Thank you! Julialturner (talk) 21:34, 30 September 2015 (UTC)

I've added the function to Module:Wikidata. You can now call it like this:

• {{#invoke:Wikidata|getImages|P18|FETCH_WIKIDATA}}
• {{#invoke:Wikidata|getImages|P18|FETCH_WIKIDATA|<br>|250px}}

I'll update the documentation. --RexxS (talk) 13:27, 1 October 2015 (UTC)

getSiteLink

Could someone here more generally implement the recently-created Module:Wikivoyage such that any language and any project will return the sitelink's name of the ID? --Izno (talk) 21:31, 10 February 2014 (UTC)

Hi Izno. Added a function based on entity:getSitelink(). Hope someone improves it. --ᛒᚨᛊᛖ (ᛏᚨᛚᚲ) 22:58, 2 October 2015 (UTC)

New function

I think it might be useful to have new function getRawValueFromID which can be used in very restrictive templates, where is accepted only clean textual values. --XXN, 14:52, 3 October 2015 (UTC)

Qualifiers

How can you for example access qualifier P1129 @ Q172221 @ P54 from [3]. I see this module has a getQualifierValue method, but there is no example on how to use it. --Sporti (talk) 06:08, 16 October 2014 (UTC)

The method was added with this edit by @Jackmcbarn:. He should be able to confirm it, but I think the methods are intended to be called like this:

• {{#invoke:Wikidata |getQualifierValue |propertyID |qualifierID |FETCH_WIKIDATA}}
• {{#invoke:Wikidata |getRawQualifierValue |propertyID |qualifierID |FETCH_WIKIDATA}}
• {{#invoke:Wikidata |getQualifierDateValue |propertyID |qualifierID |FETCH_WIKIDATA |dmy }}

In the case of Boštjan Cesar, trying {{#invoke:Wikidata |getRawQualifierValue | P54 |Q172221 |FETCH_WIKIDATA}} fails because the method assumes that each of the property values has a qualifier, which isn't true in Boštjan Cesar's case as we can see at d:Q346712. The current code should work where there is a single value for the property and it then copes with multiple qualifiers, but I think it needs more work to deal with multiple property values which may or may not individually have qualifiers.

The question that I think needs an answer is how do we wish to display the results of requesting the data, when it's as complicated as 'member of sports team' (P54) for Boštjan Cesar? At present, if we call the method that returns just the properties:

• {{#invoke:Wikidata |getValue | P54 |FETCH_WIKIDATA}}

in Boštjan Cesar, we get the expected result:

A.C. Chievo Verona, NK Croatia Sesvete, Olympique de Marseille, West Bromwich Albion F.C., NK Olimpija Ljubljana (defunct), Slovenia national football team, GNK Dinamo Zagreb

but how do we want to display the qualifiers? Are you thinking about something like this:

• A.C. Chievo Verona, NK Croatia Sesvete, Olympique de Marseille, West Bromwich Albion F.C., NK Olimpija Ljubljana (defunct), Slovenia national football team (start date:2003; national team caps:79±1; number of points/goals scored:6±1), GNK Dinamo Zagreb

It makes sense to me to program the method to return a specified display format, once we've agreed what that display should be. --RexxS (talk) 13:23, 16 October 2014 (UTC)

I believe it will be used by {{Infobox football biography}} eventually, also by lists like List of Slovenia international footballers, but I guess we're not quite there yet... --Sporti (talk) 13:53, 16 October 2014 (UTC)

I'll have a look at how that infobox is used and see if I can put together something suitable as soon as I get time (unless someone beats me to it). Cheers --RexxS (talk) 14:34, 16 October 2014 (UTC)

Is there any way to retrieve data for p1129 with #property parser function? I guess it must be a little more complicated then {{#property:p54|id=q177221 .. ???}}. --Pinky sl (talk) 18:00, 16 October 2014 (UTC)

@Tobias1984: I'm trying to use {{#invoke:Wikidata|getQualifierValue|P348|P577|FETCH_WIKIDATA}} in Akka (toolkit), but it returns

Lua error in Module:Wikidata at line 155: attempt to concatenate field 'numeric-id' (a nil value).
Backtrace:
Module:Wikidata:155: in function "chunk"
mw.lua:511: ?

--Ilya (talk) 03:21, 15 October 2015 (UTC)

Getting Values like the Wikipedia Entry from wikidata

Have you written any code that accesses the entries on the bottom of the wikidata pages ie Wikipedia entries, Wikiquote entries, Wikivoyage entries, Wikibooks entries, etc? Julialturner (talk) 06:20, 27 October 2015 (UTC)

Getting list boxes from Wikidata for use in articles

There was some recent discussion on WP:ANI (and a failed deletion proposal) about the WikiProject Airlines practice of including large tables of which airlines operate flights between which cities. It struck me that this information was structured, and could be of benefit to all projects, so I wondered why it wasn't being maintained in and drawn from Wikidata. (This would have the side benefit of mooting any deletion proposal here.) I found that Wikidata has some of the necessary vocabulary, and much of the information, although it's not entirely consistent. As an experiment, I threw together a module to extract a table similar to the one used today, as described here. Comments are welcome. (BTW, this was my first Lua module, so it's a little rough. It could easily be re-written to be much more generic.) Cheers, Bovlb (talk) 16:54, 28 October 2015 (UTC)

I'm confused--where is the module at? I would like to take a look. --Izno (talk) 17:06, 28 October 2015 (UTC)

Also, this usage per the RFC for Wikidata usage isn't approved at this time, though it is one of the reasons why one might want to use Wikidata. It might be time to think about a second RFC. --Izno (talk) 17:07, 28 October 2015 (UTC)

Sorry. I did link it above, but it's a little buried. I put a description here: Wikipedia_talk:WikiProject_Airlines#Why_maintain_structured_data_here_instead_of_at_Wikidata.3F. It wasn't clear to me that the previous RFC precluded a specific WikiProject from doing this style of "infobox". Bovlb (talk) 17:11, 28 October 2015 (UTC)

Found it--user error (RTFM in this case). As for the RFC, it's explicitly only for infoboxes, not what is being proposed here, which would be article-proper content. --Izno (talk) 17:19, 28 October 2015 (UTC)

Hmm. Maybe you're right, but looking at the summary in Wikipedia:Wikidata#Lua_module I see two main prohibitions: not using Wikidata in infoboxes when local information is provided; and not using Wikidata in running text. The latter does not apply here as it is not running text. The former may be applicable, but it seemed to me to be within the remit of a WikiProject to decide to drop the project-specific version, especially as it was already contentious. Maybe I'm relying to much on a summary. Cheers, Bovlb (talk) 17:45, 28 October 2015 (UTC)

Syntax

I might misunderstand the documentation, but I'm looking for this option:

1. When local data is provided, use that; 2. when Wikidata has data, use that, 3. else, show nothing (blank).

While at the moment,

| data55 = {{#invoke:Wikidata|getValue|P26|{{{spouse|FETCH_WIKIDATA}}} }}

returns a blank when iunput is |spouse= while there might be Wikidata available. -DePiep (talk) 14:07, 8 December 2015 (UTC)

Try: | data55 = {{{spouse|{{#invoke:Wikidata|getValue|P26|FETCH_WIKIDATA}}}}}. The module call getValue returns whatever parameter is given to it (including a blank), unless the parameter is 'FETCH_WIKIDATA', when it returns the value from Wikidata, or nothing if no data is present in Wikidata for that property. You fail to include the case when Wikidata is present, but you still want to suppress the display in the infobox. That sometimes is what is required, so I made use of the call being able to distinguish between no parameter supplied at all (when null is passed to the module) and the parameter being set to blank (i.e. |spouse=). Does that help? --RexxS (talk) 23:53, 8 December 2015 (UTC)

• This method works always for me: | data55 = {{#if:{{{spouse|}}}|{{{spouse}}}|{{#invoke:Wikidata|getValue|P26|FETCH_WIKIDATA}}}}. Paweł Ziemian (talk) 21:56, 9 December 2015 (UTC)

Efficient pattern for gathering many attributes from wikidata?

When generating an infobox with many data chunks coming from wikidata, the temptation is to use module:wikidata calls for each independent item. e.g. if you need 5 pieces of data in your infobox, you might end up with 5 requests in the template like #invoke:Wikidata|getValue . As I understand this module, that means the json blob associated with the item in question is being sent over and parsed 5 times. Is that right? When considering complex infoboxes that must use arbitrary access and sometimes deeply nested queries into the wikidata graph (e.g. see the WIP Template:Infobox_gene, this seems like it could be a performance problem - and can make code organization a challenge. I'm looking for a good code pattern/style to handle this kind of infobox. I made a prototype that reduces wikidata calls (Module:Sandbox/genewiki/alllua) by first making one request for the main json blob associated with the item in question and then passing that blob off to the functions that parse out the needed data. Does this seem like a good approach? It seems to mean that the whole template would need to be generated in Lua - is that a good thing or a bad thing? Any thoughts on this? --Benjamin Good (talk)

I'm certain you're correct that calling mw.wikibase.getEntityObject() multiple times is less efficient in programming terms than calling it once. Nevertheless, I'm also confident that we'll be told if we start causing performance problems - as we are with expensive functions such as arbitrary access. The other side of the coin is the ability to make functions like the ones in this module available to a lot more editors. I believe that there are far more editors comfortable using those to upgrade their templates than are comfortable re-writing their templates in Lua - and that's the reason I developed this module in the first place. My experience with citation templates (prior to the introduction of Lua) tells me that it's likely the calls to the parser for the template wrapping the #invoke hit server performance more than the Lua code inside it. Anyway, the two approaches are not mutually exclusive: anybody who wants to re-code a complete template in Lua can do so, but there are tens of thousands of templates, so the task may never be completed. Having said that, I'd encourage template editors who intend to make use of arbitrary access to consider writing a single module that can minimise the expensive calls, for all the reasons outlined in Wikipedia:Template limits. --RexxS (talk) 01:16, 17 October 2015 (UTC)

I didn't mean to imply that the pattern I described above was a replacement for this module. I think the great majority of infobox use cases will work just fine based on what you have provided here. The infobox gene template is a particularly complex example both on the presentation side here and over in the data model side at wikidata. The challenge of using module:wikidata in its current form for this template really comes down to the difficulty of getting deeper into the graph while maintaining decent error checking and code organization. It seems that it could be possible to abstract that process into a re-usable arbitrary-access-focused module but I think, at least as a first step, we will build a specific version for our particular use case. If others think what we do there makes sense, we can see about making a module of some kind for others to use. --Benjamin Good (talk) 22:30, 19 October 2015 (UTC)

No, I'm sorry if I gave the wrong impression, Benjamin. Module space is cheap and the more modules that become available to do complete jobs, the happier editors (including me) will be. I'd love to see a Lua module that can reliably pull data from a chain of multiple Wikidata items and assemble it into an infobox comparable to the manually filled ones we have now, and I'm keen to help you where I can. But I should warn you that the RfC that defines what we are permitted to do (Wikipedia:Requests for comment/Wikidata Phase 2) restricts us "to modify existing infoboxes to permit Wikidata inclusion when there is no existing English Wikipedia data for a specific field in the infobox." It's worth a good look at the questions addressed and the views expressed in that RfC. I've always taken the summary to mean that I can modify infoboxes to draw data from Wikidata as long as I ensure that it can be overridden by a local value. That's easy to do for a single call, but gets harder when you're following a chain to fetch data, as it multiplies up the number of test cases you need to consider every time. Anyway, just making a Wikidata-aware infobox gene template would be a great proof-of-concept and exemplar for other developers and I applaud your efforts to take on that task. --RexxS (talk) 23:48, 19 October 2015 (UTC)

Here is the functional Template:Infobox gene. It is populated with the same data as Template:GNF_Protein_box , but now uses lua functions (in sandbox module:geneboxdev) to gather data from wikidata sources. To preview this infobox go to a gene page and add the {{infobox gene}}.

Eg: ARF6

{{infobox gene}} ---add this code

<!-- The PBB_Summary template is automatically maintained by Protein Box Bot. See Template:PBB_Controls to Stop updates.-->

{{PBB|geneid=382}}---this is the old template

If it is not run from a gene page it will generate errors, as it needs to know what gene item to start from. These are the same errors that can be seen in the Template:Infobox gene itself. If I was continuing to move forward with this code I would error check for every input value to eliminate these lua errors, but since we will be moving forward with rewriting the template in lua (per above discussion) I will do these checks in the next version of code and will post the updated version once it is completed. Julialturner (talk) 21:09, 20 October 2015 (UTC)

Any tips on reconstructing the formatting code in Template:Infobox gene directly within Lua would be appreciated! --Benjamin Good (talk)

And here is a link to A version of the ARF6 gene page with the wikidata-only template

Template:Infobox gene now exists in Lua at Module:Infobox gene. A version of the ARF6 gene page with the lua/wikidata is updated with {{#invoke:Infobox_gene|getTemplateData}}. Suggestions for improvement are appreciated as this was my first Lua coding experience. Julialturner (talk) 06:18, 11 December 2015 (UTC)

Suggested test case: New French Regions

On 1 January 2016, the number of regions in Metropolitan France (on the European mainland, excluding Corsica & overseas regions) will be reduced from 22 to 13. Six will be unchanged but the remaining 16 will be merged to form 7 regions, of which only one has a new name (Upper Normandy & Lower Normandy will merge to become "Normandy"). The problem is that the permanent names for these new regions will not be chosen until their new legislatures meet and agree on a new name (ie. after 1 January). They have until 1 July to select a new name which must then be approved by the Conseil d'État. Until then, the new regions will be known by provisional names formed from hyphenating the names of the current regions that will be merged, eg. Alsace-Champagne-Ardenne-Lorraine (ACAL) is the merger of Alsace, Champagne-Ardenne, & Lorraine. In general, articles for arrondissements and communes exist on English Wikipedia (cantons don't have articles in general, so for ACAL alone there will be 10 departments (infobox template for regions & departments), 44 arrondissements (infobox template), and 5189 communes (infobox template) that will need their infoboxes changed to Alsace-Champagne-Ardenne-Lorraine and later to the permanent name for the region.

This will be a large task as far as updating infoboxes on all subunits of these regions. First, the infoboxes will need to be updated on 1 January to change the region parameter of the infobox to the provisional name (in the case of Normandy, the name change on 1 January is the permanent name). Then, as new names are approved by the government, the infoboxes will need to be changed to the permanent name. I don't have any programming knowledge to run bots, but if my understanding is correct, a simple change isn't too difficult. However, what happens if the new name is approved by the Conseil d'État (at which point the new name would be official) and someone updates the page name on Wikipedia, but no one requests a bot to change the name in every affected infobox? I was about to request a bot at Wikipedia:Bot requests for the 1 January change, but then I realized that there would be subsequent changes from the provisional to permanent names. While the name changes could be made with a simple bot, I think this could be a good opportunity to try the Wikidata integration so that the names can be adjusted quickly (would simply need to change the Wikidata name, not request a bot and wait) after the permanent name is approved and made official. AHeneen (talk) 19:39, 27 November 2015 (UTC)

In general, it will be better to use Wikidata (eventually) to hold the sort of data that may change over time, particularly as it is then updated in all projects. Unfortunately, in this case, the name of the region will be the article name and we don't have the facility (yet) to deploy dynamically-named articles. No matter how the names like Alsace, Champagne-Ardenne, & Lorraine eventually end up, we'll still have to rename articles, either manually or by bot. The infobox can already read the name of the article via {{BASEPAGENAME}}, so once the article name changes, it can be made to reflect into the infobox without any complications, simply by omitting the |name= parameter (apart from cases like Lorraine (region), where we'll want the undisambiguated name in the infobox). Hope that helps. --RexxS (talk) 20:14, 27 November 2015 (UTC)

I don't fully understand your response and how it relates to the original post. It seems to me like you thought the request is to change the article name and infobox on the region articles. I didn't make the suggestion that Wikidata be used to change the name of articles on Wikipedia, but change the region parameter in the infoboxes of tens of thousands of articles for subunits of regions. In France "regions" are divided into departments, which are divided into arrondissements, which are divided into cantons (this level of government generally doesn't have articles on en-WP), which are divided into communes (towns). Articles already exist for the new regions (using the provisional name) and the current region articles will be kept. Except for departments, the wikidata item for the subunits lists the department it is located in. For departments, the region is the "located in the administrative territorial entity" property. The regions have a property called "replaced by" which gives the name of the new region and the date of the change (1 January 2016), eg. d:Q1142 for Alsace. I presume that when a new name is officially adopted, that there is a property (on wikidata item for the new region, eg. d:Q18677983) to change the name. Again, I don't understand a substantial amount about code and what is/isn't feasible in using wikidata for Wikipedia infoboxes. It just seemed to me like the large volume of changes might be more easily accomplished by using wikidata than running bots multiple times on WP to change all of the infoboxes. AHeneen (talk) 00:31, 29 November 2015 (UTC)

Ok, yes I understand your point now. I was confused by your linking to the actual articles for the regions, but you only want to change the value for the region in the infobox of numerous lower-level articles. I'm having difficulty in finding many from the 'What links here' in, e.g. Special:WhatLinksHere/Alsace, but I've now found that Ardennes (department) has an infobox that contains Region: Champagne-Ardenne, and I assume it's cases like that that would benefit from having the region fetched from Wikidata. Of course, somebody or some bot will have to amend each article to enable fetching from Wikidata, but after that the updating would be automatic. I agree it's a good use of Wikidata, and I'll have a look at the size of the job during next week if somebody doesn't beat me to it. Cheers --RexxS (talk) 19:48, 29 November 2015 (UTC)

See the infoboxes in Hattmatt (a commune), Arrondissement of Saverne (an arrondissement), and Bas-Rhin (a department). They mention and link to the region in the infobox. In the new Alsace-Champagne-Ardenne-Lorraine region alone, there are 5243 infoboxes that will need to be changed. AHeneen (talk) 21:22, 29 November 2015 (UTC)

@RexxS: Another user started a discussion on my talk page about changing the infoboxes, but I do not know if he would be able to do so with the Wikidata integration. Are you still interested/able to change the infoboxes so that they use the Wikidata value? The first name change occurs in two weeks (1 January). AHeneen (talk) 19:54, 17 December 2015 (UTC)

Why the references from Wikidata get dropped?

Can someone clarify why am I not getting any references when using this module? I see there's some code that has something to do with references, as well as local references = frame.args["references"] mentions, but doing something like {{#invoke:Wikidata|getValue|P275|FETCH_WIKIDATA||references=true|}} does not seem to bring up any references; I see that in ru:Модуль:Wikidata these get referred to as frame.args.references = toBoolean( frame.args.references, true );, are officially documented (as set to true by default), and references do appear correctly in many infoboxes, including ru:Шаблон:Карточка ОС. I think we need something similar for Template:Infobox OS here, too (as well as many other infoboxes), see Template talk:Infobox OS#Contested addition of .7C forked from, for example. Cheers, MureninC (talk) 20:44, 30 December 2015 (UTC)

getRawValue?

I'm trying to fetch catalog code (P528) from GRB 101225A (Q5514425) using Template:Infobox astronomical event, but it doesn't seem to be working as usual, nor through getRawValue. Is there an incantation that will work here, please? Thanks. Mike Peel (talk) 23:02, 15 February 2016 (UTC)

Pasting {{#invoke:Wikidata|getValue|P528|FETCH_WIKIDATA}} into a section of GRB 101225A produces GRB 101225A, Christmas burst as expected, so the module seems to work. The real problem was in Template:Infobox astronomical event which had two |data12= and no |data2=. Fixed now. --RexxS (talk) 00:15, 16 February 2016 (UTC)

Ah, thanks for the fix! Mike Peel (talk) 00:19, 16 February 2016 (UTC)

@RexxS: something just changed, the module is now saying "Lua error in Module:Wikidata at line 179: attempt to index field 'claims' (a nil value).". :-/ Thanks. Mike Peel (talk) 00:45, 16 February 2016 (UTC)

Ah, never mind, it's only happening from the template page, not from the articles. Thanks. Mike Peel (talk) 00:47, 16 February 2016 (UTC)

That's not unusual as each #invoke is also called on the template page, which doesn't have the associated claims you expect on an article page. The simplest way to avoid that is to test the #property before calling each #invoke and only make the call if the property exists in the wikidata item corresponding to the calling page. For example, {{#if:{{#property:P1090}}|{{#invoke:Wikidata|getValue|P1090|{{{redshift|FETCH_WIKIDATA}}}}}|}} like you do for |website=. Cheers --RexxS (talk) 17:44, 16 February 2016 (UTC)

Help retrieving properties embedded as references.

Author of {{Taxonbar}} here. My template retrieves everything from Wikidata and I am running into problems because the functions and syntax accepted by this module are not very well documented.

Here is the problem I have right now: I'm trying to retrieve data from Q194314 (California condor). Specifically from within the Property:P141 (IUCN conservation status) references. I need to retrieve referenced Property:P627 the (IUCN-ID). Which would be "22697636".

I am disappointed the ViewSomething command is not better documented for those of us who are not experts on these function calls and Wikidata tree structure. If you can help me it would be very appreciated.--MCEllis (talk) 16:05, 21 February 2016 (UTC)

I figured it out, it was {{#invoke:Wikidata|ViewSomething|claims|P141|1|references|1|snaks|P627|1|datavalue|value}}. I do still wish ViewSomething syntax and usage were documented in this Module.

Hi @RexxS: or @Paweł Ziemian:Is there a way to ViewSomething from a specified Wikidata ID? can ViewSomething be made to accept a |from= parameter? Or does a ViewSomethingFromID function need to be made? For example, I'd like to retrieve claims|P141|1|references|1|snaks|P627|1|datavalue|value(IUCN-ID) from Q194314 without being on the California condor page. Thanks.--MCEllis (talk) 18:07, 21 February 2016 (UTC)

@MCEllis: I added parameter id=... to the function ViewSomething. Try {{#invoke:Wikidata|ViewSomething|id=Q194314|claims|P141|1|references|1|snaks|P627|1|datavalue|value}} → 22697636. Paweł Ziemian (talk) 19:35, 22 February 2016 (UTC)

@Paweł Ziemian: Awesome, thanks! --MCEllis (talk) 19:42, 22 February 2016 (UTC)

@Paweł Ziemian: or @Nyuszika7H: Is it possible to apply Nyuszika7H's last edit ("Don't error if entity is not found") to the ViewSomething|id= tag as well? I can't use the id=... tag if it's going to shoot out crazy errors when it's blank. I really wanted it to search based on the id of the page if the id= property was not found.

Right now my code in {{Taxonbar/sandbox}} says

{{#invoke:Wikidata|ViewSomething|id={{{from|}}}|claims|P141|1|references|1|snaks|P627|1|datavalue|value}}

And if {{{from|}}} is not specified it returns:

<strong class="error"><span class="scribunto-error" id="mw-scribunto-error-0">The ID entered is unknown to the system. Please use a valid entity ID.</span></strong>

If {{{from|}}} is specified it works great, but I really would like to keep {{{from|}}} in the code. ViewSomething should be able to use the wikidata id of the current page as the alternative to an unspecified id= parameter, instead of spitting out an error.

See {{Taxonbar/sandbox}} to see how fatal this error is for my template. Ideally {{Taxonbar}} would be completely blank if no id is found.--MCEllis (talk) 02:08, 23 February 2016 (UTC)

Let me know if it's me doing something wrong here, thanks. --MCEllis (talk) 02:13, 23 February 2016 (UTC)

@RexxS: I believe your last update broke Viewsomething for everyone. "Lua error in Module:Wikidata at line 732: Tried to read nil global data" Notice the error on User:Paweł Ziemian's comment above. I will revert your edit in about 5-10minute if you don't. Here is my template which didn't have an error before your last edit:

And the sandboxed version which had the earlier error:

--MCEllis (talk) 04:12, 23 February 2016 (UTC)

(edit conflict) I've just edited the module to explicitly use getEntityObject() when no id is supplied, i.e. it will attempt to get the data for the current page, although if no id is supplied, I would have expected getEntityObject(f.args.id) to give the same result. There's still an error in preview when I try it out so I'll revert now. I'll have to take a snapshot into a module sandbox as it's obviously taking more than a few minutes to track down the problem. --RexxS (talk) 04:20, 23 February 2016 (UTC)

Update: Previewing in California condor, both {{#invoke:Wikidata |ViewSomething |id=Q194314 |claims|P141|1|references|1|snaks|P627|1|datavalue|value}} and {{#invoke:Wikidata |ViewSomething |id=Q194314 |claims|P141|1|references|1|snaks|P627|1|datavalue|value}} return 22697636, so the module is working as intended. There are problems with some of the parameters being sensitive to leading or trailing spaces in the invocation, so I'll have a look in the template sandbox next. --RexxS (talk) 04:30, 23 February 2016 (UTC)

@RexxS:I don't see any difference in the code of your two examples.

Here is the code that I really really do not want to receive an error from and it's result below:

{{#invoke:Wikidata |ViewSomething |id=|claims|P141|1|references|1|snaks|P627|1|datavalue|value}}→

--MCEllis (talk) 04:40, 23 February 2016 (UTC)

@RexxS: The California condor page is not a good testcase at this point. If Viewsomething|id= were working properly the way I'm requesting, there would be no errors at all at the bottom of Wikipedia:Wikidata/Wikidata_Sandbox. --MCEllis (talk) 05:11, 23 February 2016 (UTC)

@MCEllis: It's 05:21 here so I might be excused for tiredness. I meant to say:

• "Previewing in California condor, both {{#invoke:Wikidata |ViewSomething |id=Q194314 |claims|P141|1|references|1|snaks|P627|1|datavalue|value}} and {{#invoke:Wikidata |ViewSomething |claims|P141|1|references|1|snaks|P627|1|datavalue|value}} return 22697636, so the module is working as intended."

and I stand by that. Just paste those two invocations into California condor anywhere and see that you get 22697636 22697636 when you preview it. The error is being spit out by the call via Taxonbar/Link which is failing to provide a valid ID to the ViewSomething call. I'm still trying to figure out how {{replace}} is expected to work in Template:Taxonbar/Link, without much success. California condor is the best place to test, trust me. You can't reliably test a module that expects a linked wikidata page to have a particular structure, i.e. an IUCN conservation status with a reference related to an IUCN-ID, on a page without that structure. --RexxS (talk) 05:50, 23 February 2016 (UTC)

OK - it appears that {{#invoke:Wikidata |ViewSomething |id=|claims|P141|1|references|1|snaks|P627|1|datavalue|value}} is the format that gives the error, while the other two above do not. I'll sandbox the ViewSomething call and figure out how to make that explicitly call getEntityObject(). --RexxS (talk) 05:59, 23 February 2016 (UTC)

(edit conflict) @RexxS: by all means go to bed! Thank you very much for your help, but I assure you the error is not coming from my template.I just want this module not to give an error if id= is empty!!!!!!!! Just a simple if statement would do the trick. If id is empty, disregard the id parameter! I just don't know Lua programing at the moment but I can tell you the error is coming from lines 727 and/or 726 because it's being too strict and requires id to NOT BE EMPTY.

As an aside, {{replace}} in Template:Taxonbar/Link is simply replacing the $1 in http://www.iucnredlist.org/details/$1/0 with the IUCN id. But pay no attention to my code as it is irrelevant to the error.

Look at Wikipedia:Wikidata/Wikidata_Sandbox#Specific_Testcase and you will see the error is produced without my template being involved what-so-ever.--MCEllis (talk) 06:33, 23 February 2016 (UTC)

@RexxS:I put sandbox testcases at Wikipedia:Wikidata/Wikidata_Sandbox#Specific_Testcase for you. But I didn't want anyone to loose sleep over this.--MCEllis (talk) 06:33, 23 February 2016 (UTC)

Yes, that's absolutely right. The error is only coming from your template in the sense that it explicitly calls the module with the empty |id=. Unfortunately I didn't code the ViewSomething function and I've just spent the last few hours trying to get that simple 'if' statement to work - you can follow my frustration in the history of Module:Wikidata/sandbox. For tomorrow's reference, I'll drop the 3 test calls here - that's what I've been previewing for the last hour in California_condor. All 3 should return the same in that article:

• >> 22697636
• >>
• >>

Thanks for the explanation about the replace - I was misdirected by the $1, which is normally a parameter in the call, but I can see how someone has used it in a url as a placeholder for the bit that needs replacing. I agree that the error definitely shows up without a template, so I was wrong in thinking the module was performing as expected because I hadn't considered that setting id to be blank might be different from omitting it altogether. I should have known better. Cheers --RexxS (talk) 07:11, 23 February 2016 (UTC)

• I made another fix that accepts an empty id parameter in the ViewSomething function. Sorry for trouble. Paweł Ziemian (talk) 20:40, 23 February 2016 (UTC)

Resolved

 – @Paweł Ziemian: Thank you so much! This module is well on it's way to greatness! --MCEllis (talk) 21:06, 23 February 2016 (UTC)

Thanks, Paweł - test for id existing and having a size of 0 - why didn't I think of that? The three calls I was testing and {{taxonbar/sandbox}} in California condor now show up error-free in preview. Cheers, --RexxS (talk) 21:29, 23 February 2016 (UTC)

Time to move this out of alpha?

This is becoming an increasingly useful module that I hope will be used much more in mainspace in the near future than it currently is. Perhaps this would be a good time to move it out of alpha and into a stable version, and to set up a development version for future improvements? Thanks. Mike Peel (talk)

I support efforts to develop this module further and moving the Module out of alpha soon, but documentation of functions such as ViewSomething needs to be greatly improved.

I also think it would be best for the Wikipedia community if this English module shared more code, functions, and syntax with the more widely used Wikidata modules of other Wikipedia languages.

For example, according to tools.wmflabs.org:

• fr:Module:Wikidata is transcluded 1,245,357 times (is that possible?)
• es:Módulo:Wikidata is transcluded 536,334 times
• de:Modul:Wikidata is transcluded 155,758 times

Compare:

• en:Module:Wikidata is transcluded 21,577 times

I think if large numbers of editors are already familiar with how to use some of the other versions of this module, it would be helpful for our module to work with nearly identical functionality so that template designers and editors can still borrow code and inspiration from languages when possible.--MCEllis (talk) 22:02, 23 February 2016 (UTC)

I'm also no Lua expert but shouldn't we be following some of the syntax standards set by MW:Extension:Wikibase_Client/Lua?--MCEllis (talk) 22:13, 23 February 2016 (UTC)

@MCEllis: When this module was originally written in May 2013 the mediwiki page looked like this, and that was all the documentation we had for the API. As updates and new features have become available, they have been incorporated as people have asked for them. The present module is made up of a number of different functions that have been written and amended by numerous different editors. The functions I wrote were designed specifically to be used in infoboxes because that's the only place we have community consensus to use them - see Wikipedia:Requests for comment/Wikidata Phase 2. They all have the clunky "FETCH_WIKIDATA" so that it would be easy to supply any parameter (except "FETCH_WIKIDATA") locally and have that override the value from Wikidata. That's what the community wanted. I've tried hard to document all the functions I wrote, but if you feel any are deficient, then please let me know and I'll do my best to improve that documentation.

If you have specific suggestions for code, functions, and syntax that you would like to see shared with the more widely used Wikidata modules of other languages, then please feel free to request them, but it's important to understand that other language Wikipedias may have completely different consensuses about how data from Wikidata can be used in their wiki. I also think we should be following standards for syntax, but I've been unable to discern any from MW:Extension:Wikibase_Client/Lua. Perhaps you could point out which ones you feel are most important? --RexxS (talk) 00:43, 24 February 2016 (UTC)

about monolingualtext

I'm a user, not a developer. I want for e.g. P1449 nickname or P1549 demonym etc., to show the property by language, or better still, only what's wanted. 194.75.238.182 (talk) 13:33, 8 March 2016 (UTC)

Problem property P150 contains administrative territorial entities

Problem is that provinces in Philippines have a number of both cities and municipalities below them. They need to be collected by type, but there is no currently way of knowing. I can add each value to have a qualifier, such as P31 "instance of" +Q104157 "city of the Philippines" or P31+Q24764 "municipality of the Philippines". But then what??

Alternative could be to {{#property:P150}} then use each item in turn and get its own P31.

What is easy?? 194.75.238.182 (talk) 19:02, 8 March 2016 (UTC)

Weird doc description

/doc nonow says, in #Example in Infobox template: Optionally, it could be called as:

• | data55 = {{#invoke:Wikidata|getValue|P26|{{{spouse|}}} }}

which should behave as the parameter does now [sic1], unless the parameter is set [sic2] to FETCH_WIKIDATA when it displays the linked value(s) fetched from Wikidata [sic3].

I do not understand this. What ius this trying to explain? What is "now"? Why re-introduce 'the parameter is set' point when you want to illustrate the parameter is not set situation? In general, what is exactly the effect of omitting that parameter (what the ext purports to explain)? -DePiep (talk) 20:37, 28 February 2016 (UTC)

@DePiep: Here's how the documentation reads at present:

Inside an infobox definition, it may be called like this:

• | data55 = {{#invoke:Wikidata|getValue|P26|{{{spouse|FETCH_WIKIDATA}}} }}

which causes the infobox to:

1. not display spouse if the infobox parameter |spouse is set to be blank (as "| spouse ="}
2. display the linked value(s) from Wikidata if the infobox parameter |spouse is not supplied
3. display the local infobox parameter |spouse if it is supplied (e.g. "|spouse = Hillary Clinton")

Optionally, it could be called as:

• | data55 = {{#invoke:Wikidata|getValue|P26|{{{spouse|}}} }}

which should behave as the parameter does now, unless the parameter is set to FETCH_WIKIDATA when it displays the linked value(s) fetched from Wikidata.

This is trying to explain how to code an infobox using a call to this module. It is giving different examples of how you could use the call to produce different results.

Do you understand the first example? It allows an infobox to be created that will autofill the values from wikidata if the parameter is omitted. Some people want this behaviour. It still allows a local value to override the Wikidata value, or for the Wikidata value to be suppressed, but the editor has to make the effort to override the value from Wikidata.

"Now" is the current default behaviour for an infobox without any call to Wikidata, i.e. if you supply a value for the parameter, it is displayed after a fixed label; so if you set |spouse = Hillary Clinton in {{infobox person}} in an article, it shows Spouse(s) Hillary Clinton. If you leave the parameter blank, i.e. |spouse= or omit the parameter completely, it displays nothing.

The second example is suggesting a way where an infobox could be coded so that it behaves almost identically to the way an infobox behaves now, with the sole exception of when the editor of an article supplies "FETCH_WIKIDATA" as the value for the parameter, which then causes the value from Wikidata to be displayed. If the parameter is omitted (or set to blank), it displays "exactly" nothing, just as happens with e.g. {{Infobox person}}. This is the situation where an editor has to make a specific effort to get a value from Wikidata, and could be used to upgrade an existing infobox without any visible effect on existing articles. Some people want that.

I'm not trying to illustrate "the parameter is not set situation", as I'm writing the documentation from the point-of-view of the template creator, who wants to define a particular behaviour in terms of outputs, not inputs. In other words, the template coder is interested in "how do I get the the infobox to display x, y, or z", not "what do I want the infobox to display when the parameters are a, b or c". There is an ambiguity in thinking in terms of "parameter not set", as that could represent either the parameter is omitted or is set to blank, and those are different cases as far as Lua is concerned.

There are other ways to make use of the call to the module, as it has been designed to make it easier to distinguish between 3 possible outcomes: (1) display the value from Wikidata; (2) display the locally supplied value; (3) display nothing (whether or not a value is available from Wikidata).

Another possible alternative coding is:

• | data55 = {{{spouse|{{#invoke:Wikidata|getValue|P26|FETCH_WIKIDATA}}}}}}

which behaviour I leave as an exercise for you.

There are some examples of how the calls can be implemented in {{Infobox person/Wikidata}} and {{Infobox telescope}} if you need more to examine. --RexxS (talk) 19:44, 8 March 2016 (UTC)

Thanks for this reply. Will respond later. -DePiep (talk) 09:41, 10 March 2016 (UTC)

getDateValue for imprecise dates, eg year or century only

Tracked in Phabricator
Task T103378

When wikidata only holds a year-precision or century-precision dates, getDateValue returns odd values. Specifically it returns "1823" instead of "1824", and "30 November 1799" instead of "18. century". The example I have tried is Mai Sukhan, where oldid 709368001 shows the odd output. Template "Infobox person/Wikidata" gives the same results (see oldid 709365383). Wikidata shows "date of birth 18. century" and "date of death 1824" Batternut (talk) 15:07, 10 March 2016 (UTC)

This is a known (and tracked) bug. See phab:T103378. --Izno (talk) 15:20, 10 March 2016 (UTC)

By default, Wikidata stores a date entered as 1824 as time="+1824-00-00T00:00:00Z" precision=9 - which is a non-existent date. Not very clever, particularly when the mw.language:formatDate() function used in the Scribunto API interprets it as the day before 1 January 1824, i.e. 31 December 1823 - which naturally shows 1823 as the year. I've just edited Mai Sukhan to set P570 (death date) as 1 January 1824 with precision of 'year'. It displays the same in the Wikidata interface, but now returns the correct year using the formatDate() function. That's obviously just a work-around and there's not much I can do as a work-around for the cases of century or decade precision. Mai Sukhan's date of birth is presently stored as time="+1800-00-00T00:00:00Z" precision=7 which is meant to represent "18th century". I suppose I could re-write getDateValue to look at the precision first and and then return something understandable for centuries, decades, etc. but I anticipate a lot of edge cases like "4th millennium BC", "960s AD", "early first century" and so on. In the meantime, it makes sense to just override any incorrect return values by supplying the correct value locally. --RexxS (talk) 19:02, 10 March 2016 (UTC)

Update: as it happens, the module already contains most of the formatting by precision code. I've re-arranged the module and updated getDateValue to make use of this, so handling of centuries, etc. should be a lot better. I'll need to check that I haven't broken dates BC and within the first centuries BC and AD, as well as adding the ordinal suffixes for centuries - it displays "18 century" at present. Then they will have to be internationalised. --RexxS (talk) 20:35, 10 March 2016 (UTC)

I'm putting the calls to paste & preview in a section of an article to see how birth and death dates would display:

* >>{{#invoke:Wikidata|getDateValue|P569|FETCH_WIKIDATA|dmy}}<<
* >>{{#invoke:Wikidata|getDateValue|P570|FETCH_WIKIDATA|dmy}}<<
{{#invoke:Wikidata|Dump}}

Here are some of the articles mentioned in previous discussions, so that I can test the current implementation:

• Abgar V
• Mai Sukhan
• Franz Kafka
• Martial
• Nero
• Augustus

So far, just the dates BC seem to be broken. Any further problems anyone finds, please report here. --RexxS (talk) 21:06, 10 March 2016 (UTC)

Update: I've modified getDateValue to use the working bits of the local parseDateValue and formatDate functions. Any further problems anyone finds, please report here. --RexxS (talk) 23:17, 10 March 2016 (UTC)

@RexxS: great work! Batternut (talk) 00:34, 11 March 2016 (UTC)

Further to your changes, I've been looking around for something to generate ordinal numbers to feed into the century and millennium templates, eg 21st century or 2nd millenium. The internationalization aspect of it cropped up once before on wikidata. So I put together a simple function in Module:Sandbox/Batternut/Ordinal as a proposal. Probably wm.language would be the long-term destination for it, but perhaps this Wikidata module is a good place to start. Batternut (talk) 00:34, 11 March 2016 (UTC)

Thanks, Batternut. Inspired by your suggestion, I've taken a slightly different route to internationalisation. For modules we only need to provide the English version, as long as we define the content specific to English in a place where it can be translated if the module is imported into other languages. I've added to the i18n section the English ordinal suffixes ("st", "nd", "rd", "th") and written a short local function makeOrdinal() to return the ordinal number from the cardinal (like 21 -> 21st). I've incorporated that into the getDateValue call so that it returns the ordinal number for centuries and millennia. Mai Sukhan now seems to display the proper values when called from Wikidata. Cheers --RexxS (talk) 02:14, 11 March 2016 (UTC)

Subproperty oddity

It seems that the {{{val|FETCH_WIKIDATA}}} approach doesn't work when you're including a subproperty, see this diff - the newer version on the right works fine, while the older version on the left only shows values from Wikidata and not any declared locally. A bit of an oddity, but the work-around of only calling this module if the parameter isn't set seems to work OK. Thanks. — Preceding unsigned comment added by Mike Peel (talk • contribs) 07:14, 29 March 2016 (UTC)

@Mike Peel: A caption is not an alt tag (as you seem to have caused the default to be at [4]). --Izno (talk) 11:23, 29 March 2016 (UTC)

@Izno: That's true, there should probably be another entry on Wikidata for the alt tag, but for now I figure that defaulting to a wikidata caption where there isn't a locally-defined alt tag makes sense (it's better to have an alt tag saying something relevant, rather than not having an alt tag). Thanks. Mike Peel (talk) 06:44, 31 March 2016 (UTC)

Actually, Mike, no, it's better to have an empty alt tag than to repeat the caption. A screen reader user would simply hear the same information twice, and that isn't something we should be subjecting our visually impaired readers to. --RexxS (talk) 11:00, 31 March 2016 (UTC)

(WP:ALT.) --Izno (talk) 11:09, 31 March 2016 (UTC)

WP:ALT #Captions and nearby text to be precise. I'd recommend the |alt=refer to caption as the least worst option. It can always then be over-ridden on an article-by-article basis with a local value. --RexxS (talk) 13:45, 31 March 2016 (UTC)

OK, good to know - I've reverted the alt tag change. I think the original issue still remains, though? Thanks. Mike Peel (talk) 16:53, 31 March 2016 (UTC)

Yes, it's the way the module is coded to fetch sub-properties. The property has to exist otherwise there's an error in trying to reference the sub-property. As I'm not convinced that fetching sub-properties can ever work properly,† I've not put any effort into resolving those sort of issues. But the work-around of checking #property first in the template is perfectly sensible. --RexxS (talk) 22:31, 31 March 2016 (UTC)

† [Aside:] Richard Burton (d:Q151973) had three wives and was married four times; If we fetch the value for the start date (d:Property:P580) of his marriage (d:Property:P26), how do we know which wife it refers to, and how do we get the date of his second marriage to Elizabeth Taylor? --RexxS (talk) 22:31, 31 March 2016 (UTC)

Talk page

Why are we having these wide-ranging discussions on a module talk page? Would anyone object if we centralised discussion at WT:Wikidata? — Martin (MSGJ · talk) 21:28, 26 April 2016 (UTC)

Probably because most of these types of questions are going to arise in the context of the programming rather than the (presently) descriptive page at WP:Wikidata, I would gather. --Izno (talk) 23:00, 26 April 2016 (UTC)

I'm for whatever has the most page watchers czar 23:13, 26 April 2016 (UTC)

I tend to concentrate on trying to solve the problems of importing stuff from Wikidata into Wikipedia by writing Lua code and storing it in this module. For me, it keeps those issues together. Conversely, I'm not terribly interested in inter-language links, Authority control, etc. so the S/N ratio at WT:Wikidata means I don't watchlist it. I suppose if discussion moved there, I'd have to follow it. --RexxS (talk) 00:06, 27 April 2016 (UTC)

find

I was skimming the code while pondering stuff for Module:Convert/sandbox and noticed a problem in function p.getUnits:

    result = mw.ustring.sub(result, mw.ustring.find(result, " ")+1, -1)

That's Python! In Lua, a failed find returns nil. Another point is that mw.ustring can be slow and is often not needed because strings will always be UTF-8. One of the following would work well:

    result = result:sub((result:find(' ', 1, true) or 0)+1)
    result = result:match(' (.*)') or result
    result = result:match('%S.*') or ''  -- (BROKEN: see below)

The equivalents without using the ":" syntax would also be fine. The slowness of mw.ustring is not a real problem in a case like this, so it might be used for consistency. Johnuniq (talk) 11:57, 9 May 2016 (UTC)

Thanks for spotting that, John. These days I tend to skip about between C++, Javascript, Lua and Python, depending on what I'm working on, and each language has string handling that has similarities but important differences as you point out. My preferred style is usually to employ syntax that I think is most obviously self-documenting (so others can read it as easily as possible). In this case, I went for a construction that I was hoping would show it was returning a substring from the character after the first space to the end of the string (i.e. the units from e.g. "10.0±0.1 metre"). The documentation at mw:Extension:Scribunto/Lua reference manual #string.sub and #string.find would seem to indicate that my choices are valid Lua within the Scribunto implementation. I can see it would give an unusable result if there were no space in the formatted quantity (perhaps a temperature), but I don't think any of the alternatives would fare any better. Wouldn't result = mw.ustring.sub(result, (mw.ustring.find(result, " ") or 0) + 1, -1) also avoid the "attempt to perform arithmetic on a nil value" error? Regexes are certainly compact, but they are also not consistent across language implementations, and are not the easiest of syntax to follow. I'm agnostic about the use of the Mediawiki Ustring library, but the documentation does state that "The ustring library is intended to be a direct reimplementation of the standard String library, except that the methods operate on characters in UTF-8 encoded strings rather than bytes.", which suggests to me that it would ease internationalisation to Japanese characters, for example, if others wished to port it into other languages. Anyway, you should feel free to fix any errors you spot, I can usually work out what has been done. --RexxS (talk) 14:03, 9 May 2016 (UTC)

P.S. I can't get the third one to work at my usual test spot for fragments result="10 square metres"; print(result:match('%S.*') or '') - am I missing something? --RexxS (talk) 14:15, 9 May 2016 (UTC)

Further: I think we should try to cope with the possibility that a quantity might not have a space between the numbers and the units (although I haven't found one yet - e.g. Vega has a temperature (P2076) of "9,600±200 kelvin"). So I suggest the following code would be workable and legible:

local unitpos = result:find('%d %a')  -- find digit, space, letter
if unitpos then
  result = result:sub(unitpos + 2)    -- return substring from the found letter to the end
else
  unitpos = result:find('%d%a%a')     -- find digit, letter, letter
    if unitpos then
      result = result:sub(unitpos +1) -- return substring from the first found letter to the end
    else
      result = "no units"             -- modify to taste
  end
end

Obviously if the Ustring library were preferred, we'd have to use mw.ustring.find(result, '%d %a') and mw.ustring.sub(result, unitpos + 2, -1), etc. as mw.ustring.sub() doesn't seem to quite handle the omission of the parameter for the end of the substring in the same way as the Lua string sub() function, depending on whether you do arithmetic on the value (probably because find() returns 2 numeric value). It's not elegant, and it's not compact, but it should be easy to understand and modify. It also offers a consistent return string if it doesn't find any units. What do you think? --RexxS (talk) 16:28, 9 May 2016 (UTC)

Sorry about wasting your time—you are right that my third option is broken (it was an afterthought from some code I had recently worked on). I had not seen that very nice Lua demo, but I'm too lazy to try tricky development like this module without having Lua installed for testing.

Re i18n: Unicode is so hazy that safety-first is the only sane approach, but my first two options above work for any Unicode characters given that the encoding is UTF-8. I'll happily expand on that if wanted; the essence is that characters are just sequences of bytes in UTF-8, where each byte is guaranteed to have its "normal" ASCII meaning if below 128, or to be part of a multi-byte character otherwise. Searching for "%d" using Lua's functions will only find ASCII digits, so if digits in any language are needed, mw.ustring is essential. However, searching for things like " " works in plain Lua, in any language.

Re finding the unit name, I'm still trying to absorb how Wikidata is supposed to work, but it seems to me that trying to parse the output from formatPropertyValues will occasionally fail due to weirdnesses introduced by the Wikidata developers. I could very easily be wrong, but I don't think there is a specification for what output that function produces, and, for example, they might one day decide to replace the space with a non-breaking space. Johnuniq (talk) 00:35, 10 May 2016 (UTC)

By the way, I don't know if this module is intended to parse output from, say, zhwiki, but they do not use spaces. The following shows the wikitext output at enwiki and at zhwiki for the same two converts. At zhwiki, some tricky MediaWiki extensions are installed which allow users to specify certain dialects, and text like "zh:" is not visible there.

• {{convert|12.3|m2|sqyd|abbr=off}} → 12.3 square metres (14.7 square yards)
• {{convert|12.3|+/-|0.4|m2|sqyd|abbr=off}} → 12.3 ± 0.4 square metres (14.71 ± 0.48 square yards)
• {{convert|12.3|m2|sqyd|abbr=off}} → 12.3平方-{zh:米;zh-cn:米;zh-tw:公尺;zh-hk:米;}-（14.7平方碼）
• {{convert|12.3|+/-|0.4|m2|sqyd|abbr=off}} → 12.3正負0.4平方-{zh:米;zh-cn:米;zh-tw:公尺;zh-hk:米;}-（14.71正負0.48平方碼）

Johnuniq (talk) 00:46, 10 May 2016 (UTC)

Way to get ID from page title?

For a template I currently prepare, I need to get an Q-ID from given page title and wiki (e.g. wiki=de|name=Periodensystem). Is there a way how to achieve this? I need to check if there (enwiki) exists an article connected with that one given. My template will use that ID for function getSiteLink() in this module. Or is there any better way how to achieve this? --Dvorapa (talk) 17:30, 14 May 2016 (UTC)

See #QID lookup from enwp article title above, it's a very similar question. -- ferret (talk) 17:33, 14 May 2016 (UTC)

Thank you. It looks like it is not possible :/ --Dvorapa (talk) 17:47, 14 May 2016 (UTC)

Importing units from wikidata

Moved from User talk:Mike Peel

Hi, I've noticed you've done some work on using wikidata in infoboxes. I wanted to ask your opinion on using quantity datatypes. I've noticed that the unit generally comes out singular rather than plural (e.g. 1000 foot instead of 1000 feet). Also is there a good way to feed the quantity through {{convert}} to get it displayed in metres as well? Thanks — Martin (MSGJ · talk) 10:01, 25 April 2016 (UTC)

Hi @MSGJ:. I'm away at the moment, so I can only reply briefly. This is something I want to look into in more detail, at the moment I haven't seen a way to put it through convert, but it should be possible - you just need to be able to fetch the number and the unit separately. @RexxS: might be able to help more with the implementation here.

There's the added problem with units in that Wikidata currently assumes an uncertainty in the last significant figure, which isn't always right (e.g. see South Pole Telescope, where a diameter of 10 +- 0.1m is given, but I'm sure that the diameter is much more accurate than that in reality - we should just be saying 10m there). However, as an initial step in using wikidata for numbers with units, it seems to be OK to me - and hopefully things will get better over the course of the year. :-) Thanks. Mike Peel (talk) 17:27, 25 April 2016 (UTC)

Martin, The call to getRawValue(PropertyID) will return the raw numeric value, with the presumed precision (like 10.0). I've written a call (getUnits(PropertyID)) at line 636 in Module:Wikidata/sandbox to crudely fetch the units (I think).

Try pasting:

• {{convert|{{#invoke:Wikidata|getRawValue|P2386|FETCH_WIKIDATA}}|{{#invoke:Wikidata/sandbox|getUnits|P2386|FETCH_WIKIDATA}}}
• {{convert|{{#invoke:Wikidata|getRawValue|P2386|FETCH_WIKIDATA}}|{{#invoke:Wikidata/sandbox|getUnits|P2386|FETCH_WIKIDATA}}}}

into South Pole Telescope #See also and previewing it.

It needs a lot more testing and probably some refining, but once we can get a usable version, we can copy it into the main Module:Wikidata without disturbing what's already there. See what you think. --RexxS (talk) 20:30, 25 April 2016 (UTC)

@RexxS: you're missing a closing bracket in the code sample, but this seems work very well - nice work. :-) It would definitely be a good feature to add to module wikidata. Although, it may need some liaising between Wikidata (maybe with @Lydia Pintscher (WMDE)'s help) and {{convert}}-coders to make sure that all units are supported, e.g. try this one in the SPT article:

• {{convert|{{#invoke:Wikidata|getRawValue|P2046|FETCH_WIKIDATA}}|{{#invoke:Wikidata/sandbox|getUnits|P2046|FETCH_WIKIDATA}}}}

Thanks. Mike Peel (talk) 21:51, 25 April 2016 (UTC)

Sorry about the bracket, Mike. The problem with the units, of course, will always be that there are divers ways of writing units. Wikidata exports one format, like "square metre" and {{convert}} expects another, like "m2" or "sqm", but doesn't understand "square metre" or even "sq m" (which I expected it to). I could write a lookup table in the module to take the Wikidata format and return the format that {convert} expects, but I think that first I'd rather explore the possibility of convincing the maintainers of {convert} to accept more natural unit formats such as those that Wikidata exports. --RexxS (talk) 01:38, 26 April 2016 (UTC)

I'm glad this has generated some interest. I agree that code would be a good addition to Module:Wikidata, and it would be ideal if {{convert}} accepted the unit that wikidata exported. Before I post on Template talk:Convert about this, clarify one thing for me: if someone changed the label of square metre (Q25343), would that potentially disrupt all articles using this unit, or could the lookup be based on the item number? — Martin (MSGJ · talk) 08:05, 26 April 2016 (UTC)

I just asked the question at Template talk:Convert #Interoperability with Wikidata before coming here where I saw your question, Martin. Sorry if I've jumped the gun. The formatting of the unit name is performed by a call to the Wikibase API, whose only documentation that I can find is at mw:Extension:Wikibase Client/Lua #mw.wikibase.entity:formatPropertyValues. That was changed not so long ago to give us the actual unit name, rather than the link to the unit page that is stored in Wikidata. Consequently, I can't be sure that the call is making use of the label on the page for the unit (because the conversion is performed in the API, not in our Module) - although I'd be surprised if it didn't use the label for internationalisation reasons.

I can see your concern: any vandal on Wikidata could cause multiple problems here that will not be obvious as to the source. But that's going to be the case every time we fetch information from Wikidata, although the scale could be far worse. My solution would be to protect some Wikidata pages like d:Q25343 (square metre). I can't see any point in having something so fundamental being editable by any drive-by IP vandal. In any case, the disruption here would be limited to seeing something like Area 78.5 square leg, which wouldn't be too difficult to track down for anyone who had seen it before. --RexxS (talk) 09:42, 26 April 2016 (UTC)

I don't think using the label is ever going to fly, and not just for reasons related to vandalism. What about gallon (Scots) (Q5519125), gallon (US) (Q23925413), gallon (UK) (Q23925410), beer gallon (Q23925527) or even dry gallon (Q5309589) or wine gallon (Q8024928)? All different units, but all could feasibly and in good faith be called just "gallon". Change their labels, you may say, but there are probably articles where the context is clear and you wouldn't want to keep using "US gallon" or "imperial gallon". I think we need to use the item number (if possible) and then use a lookup to convert that into what {{convert}} is expecting. — Martin (MSGJ · talk) 11:42, 26 April 2016 (UTC)

We could perhaps find articles that contained quantities in gallons (of differing kinds) and see what is returned. The item number for the unit is actually trivial to recover: a quantity has its unit stored as a raw url which links to the relevant page, so the last part of the url is the item number (QID). For example, South Pole Telescope has an area (P2046) property which contains mainsnak.datavalue.value.unit which is the url "http://www.wikidata.org/entity/Q25343". The bit after the last '/' is always the QID for the unit - in this case square metre (Q25343). However, as we will have to get the string "square metre" from somewhere, I'm hard-pushed to see what it could be if it's not the label at d:Q25343, which is not guaranteed to be unique (AFAIK). If so, we're back to square one with the vandalism problem and disambiguating gallons. --RexxS (talk) 00:26, 27 April 2016 (UTC)

Can I suggest that this discussion is moved to Module talk:Wikidata? I think it's something that will be of general interest there, and the discussion's already going beyond that which should take place on a user talk page. ;-) Thanks. Mike Peel (talk) 12:34, 26 April 2016 (UTC)

IMO there should be a Lua table which converts QIDs to natural text (of both the plural and the singular). This protects Wikipedia from the trivial vandal sort changing the title of the item and can be used by Module:Convert. --Izno (talk) 13:13, 26 April 2016 (UTC)

I tend to agree, assuming that is possible, which according to RexxS above is not clear — Martin (MSGJ · talk) 21:26, 26 April 2016 (UTC)

I think you'll find that Wikidata items don't have titles. They have QIDs and labels as far as I can tell. What you see at d:Q25343 is not like a Wikipedia page; it's just a convenient interface to display a page at https://www.wikidata.org/wiki/Q25343 and the "Title" at the top is the site label. You can change your language preferences to francais and you'll see the same page now has a "title" of "mètre carré". --RexxS (talk) 00:35, 27 April 2016 (UTC)

Having said that, I do like the idea of having a module that was just a Lua table which is indexed by a QID and contains multiple values for let's say singular, plural, abbreviation, convert code, and maybe anything else we might need. I just made a demo of the sort of structure I was thinking of at Module:Sandbox/RexxS/Units. That sort of content could be generated from a simpler input such as csv like {Q11573, metre, metres, m, m}. Once made, that module could be imported into other modules to vandal-proof units and their conversions (we can apply whatever level of protection to the module that we like, as it's effectively read-only after it's settled). How much work it needs could be estimated from the number of entries at Module:Convert/documentation/conversion data/doc #Conversions. I think that has 1176 units, possibly. That could be a lot of work to match completely. --RexxS (talk) 01:31, 27 April 2016 (UTC)

Perhaps we could put 10-20 entries in for now, which will be sufficient for a proof of concept. Could you sandbox some code which will obtain the QID, push it through this lookup module, and then pass to convert? — Martin (MSGJ · talk) 08:50, 27 April 2016 (UTC)

I'll have a go, probably tomorrow, now. The table I was creating isn't a lookup module, rather it's for importing into other modules, but I could knock up a front-end as a demo and try it out with {convert}. --RexxS (talk) 11:48, 27 April 2016 (UTC)

I had a bit more time than I thought (birthday was quiet after all), so I've revamped the lookup table, made a demo module that imports it, and done some testing:

• Module:Sandbox/RexxS/Units = lookup table with a dozen sets of units
• Module:Sandbox/RexxS/Unitsdemo = demo module that imports the lookup table: 4 functions that will return names, abbreviations, or convert code when a QID is supplied
• Module talk:Sandbox/RexxS/Unitsdemo = checking and testing and a test that uses {{convert}}

Is that a decent start for a proof-of-concept? I can also write an extra call like getUnits that returns the QID of the unit instead of its name - or I could actually just import the lookup table so that the call to getUnits returns the convert code instead. Or some combination. Thoughts? --RexxS (talk) 17:00, 27 April 2016 (UTC)

Does WP:ENGVAR matter? meter = metre... according to some sources. :) --Izno (talk) 17:11, 27 April 2016 (UTC)

If anybody wants alternative spellings of units, they are welcome to write their own module. This is really intended for use inside other modules, so that should be no problem. --RexxS (talk) 18:45, 27 April 2016 (UTC)

I suspect that anything we do with units will be pushed through {convert}. So the variant spellings can be handled by that template/module as usual. — Martin (MSGJ · talk) 20:47, 27 April 2016 (UTC)

Nice work on all this. However please wait before deploying. I'd like to see how the work on {convert} pans out. In particular I'd like to hear Johnuniq's thoughts on all this. — Martin (MSGJ · talk) 22:20, 27 April 2016 (UTC)

I notice we also have conversion to SI unit (P2370). Could this be useful, or is it better just to use {{convert}}? — Martin (MSGJ · talk) 08:52, 27 April 2016 (UTC)

As far as I can tell, that is a property of a Wikidata unit item that tells us its conversion into SI. So millimetre (Q174789).["P2370"] will contain "0.001 metre". I don't think those are going to change often enough to require a dynamic lookup, so I'd just go with a plain lookup table or use {convert}. --RexxS (talk) 11:48, 27 April 2016 (UTC)

Module updated

I've updated Module:Wikidata to include two new functions: getUnits and getUnitID. The latter is capable of supplying the QID of the unit that a property uses on a given page. So on South Pole Telescope you can paste and preview:

• {{#invoke:Wikidata|getValue|P2046|FETCH_WIKIDATA}}
• {{convert | {{#invoke:Wikidata|getRawValue|P2046|FETCH_WIKIDATA}} | {{#invoke:Wikidata|getUnits|P2046|FETCH_WIKIDATA}} }}
• {{convert | {{#invoke:Wikidata|getRawValue|P2046|FETCH_WIKIDATA}} | {{#invoke:Sandbox/RexxS/Unitsdemo|conv|{{#invoke:Wikidata|getUnitID|P2046|FETCH_WIKIDATA}}}} }}

This will display:

• 78.5±0.1 square metre
• 78.5 square metre^{[convert: unknown unit]}
• 78.5 square metres (845 sq ft)

• The first call returns the entire quantity, including precision and units.
• The second supplies the numeric value (fetched by getRawValue) and the unit name separately to {{convert}}. It shows that {{convert}} doesn't understand a unit called "square metre" at present.
• The third is similar but fetches the unit QID instead of the unit name, then uses the lookup to change the QID into the code that {{convert}} requires ("m2" in this case).

Are we at the stage yet where we could move the sandboxed modules into module space and think about a wrapper to hide most of the code? --RexxS (talk) 19:27, 27 April 2016 (UTC)

Revert please. You are impulsive, aren't you ;) Just 2 hours after asking for thoughts you have updated the module. I think this needs more thought, and will depend to a large degree on how the work in Module:Convert is implemented. For a start (and for reasons I tried to explain earlier today) I oppose maintaining a separate list of units, plurals and abbreviations because convert will do all already that and duplication is not good. All you need is to link the item number of the unit with its convert code, nothing else. — Martin (MSGJ · talk) 20:46, 27 April 2016 (UTC)

I work quickly when I'm trying to solve problems. Further:

1. I'm disinclined to revert for no good reason, since increasing the functionality of a module is only an improvement.
2. Please keep your comments on the subject - I don't appreciate your personal smears, and I'd be grateful if you'd strike that particular piece of calumny.
3. I'm interested in thoughts about the Units lookup module and the best way to create a wrapper to make the functionality more accessible to the average editor, not the calls to Module:Wikidata.
4. I note your opposition to a lookup table that can be used to convert from a unit's QID to the unit's name or abbreviation. You need to understand that convert does not have that functionality. So, what is your opposition actually based on?
5. As someone who's been programming since the 1960s, I find your attempt to dictate "all I need to do" comical.

If it's all the same to you, I'll decide the scope of my programming projects, thanks. --RexxS (talk) 21:36, 27 April 2016 (UTC)

This sounds like a good improvement to the module regardless of the {{convert}} issue. Thanks RexxS for making the change. Mike Peel (talk) 21:47, 27 April 2016 (UTC)

Apologies for any offence, no "calumny" was intended ;) Had to look that up. However I was taken aback at the speed of this. How about a little more reserve on a module with 61000 transclusions? The guidelines suggest you should not be making these kind of changes without substantial consensus. That said I do appreciate your efforts to solve this problem. Will expand on this later — Martin (MSGJ · talk) 22:17, 27 April 2016 (UTC)

Sorry - I do tend to invest a huge effort into getting a solution when I'm faced with a technical problem and the speed I work at sometimes makes it hard for others to follow my thought processes. Sadly I'm too old to change my ways now.

I'm astonished that Module:Wikidata has that many transclusions, as I still think of it as a little piece of code that Tom Morris and I knocked up one afternoon at a Lua workshop. Whatever happened to "may be used on a few pages to see if problems arise"? and does that mean that we might have to take it out of alpha now?

My only defence for rashly introducing new functions into the existing module is that I always write them as self-contained blocks, in the sense that any error in a new function can't pollute the working of any of the existing code. Yes I know, "famous last words", but it hasn't failed me yet. Anyway, I'll do my best to generate a substantial consensus next time. I've been spoilt by never having been faced with any objections so far. After all, I'd be almost sad to have to give up the opportunity of spending so many hours finding solutions to problems like these. --RexxS (talk) 23:01, 27 April 2016 (UTC)

I thought of a thing that I had forgotten about: in keeping with the base assumption on Wikidata that certain statements aren't limited, there are some places where a unit may not end up being what we associate commonly as a unit (namely, a unit specified in e.g. the SI system or the Imperial system). So I could theoretically make "feet" (as in, my human feet) be a unit. There should be a graceful fallback for these cases, and where identified on a systematic basis, should probably have default support. The "population" property would be one of the first ones I'd peg as providing for units that are not identified in a system--it makes sense to me that the count of "population" should naturally include "300 humans".... This may be accounted for above, but I wanted to make sure that we were careful on the point. --Izno (talk) 12:14, 19 May 2016 (UTC)

The way that data is stored in Wikidata still offers constraints on values, even if they are somewhat artificially constructed. The designers made a mistake in not making countable quantities distinct from non-countable ones, but fortunately the implementation seems to always use the value "1" as the unit for such properties (even thought it shows as no value in the Wikidata interface at (P2237)). As long as that remains a single exception, it's easy to trap and take action on. You are right though, a robust implementation of getUnits will need to catch the non-countable properties and return sensible results. As this was mainly intended to supply parameters to {{convert}}, and Johnuniq has developed a sandbox version of its module that directly accepts property values and fetches the Wikidata within the module, I'm not likely to develop this call any further unless somebody needs a bugfix for a particular implementation. --RexxS (talk) 14:03, 19 May 2016 (UTC)

Module:Wikidata-i18n

I have noticed that many pages are showing transclusions of Module:Wikidata-i18n, which does not exist, and traced it back to this module. given that this module doesn't exist, can we simplify the loadI18n function, or is there something else going on here. Frietjes (talk) 18:49, 24 February 2016 (UTC)

@Frietjes: If the Module:Wikidata-i18n were to exist - as it may in other language wikis, or here at some point in the future - then the code in this module (lines 70-94) would load that first and then merge in the specific internationalisations for en-wp. I don't know how we could keep that functionality in any other way. I guess it's a question of whether to keep code portability into other wikis and some future proofing or to fix the situation where MediaWiki software is indicating a non-existent transclusion. If there's a way of resolving both, I'd be happy to see it incorporated, but if not, my preference is for the current position. --RexxS (talk) 22:33, 24 February 2016 (UTC)

@Frietjes and RexxS: I fixed that issue by creating a placeholder Module:Wikidata/i18n (as a submodule following other language wikis that are already using i18n. Also fixed an issue where the module attempts merging in an empty table. Many optimizations are possible, but as a stop-gap I chose to keep it as simple as possible. Regards, PanchoS (talk) 11:52, 20 May 2016 (UTC)

Infobox management

Following discussions at Template talk:Infobox book #Wikidata and Wikipedia:Village pump (policy) #RfC: Wikidata in infoboxes, opt-in or opt-out?, I've written a stand-alone function at Module:Sandbox/RexxS/IB specifically for use in infoboxes. The function is similar to the existing Wikidata|getValue, but implements:

1. a blacklist of fields that are never to be displayed, i.e. the function must return nil in all circumstances;
2. a whitelist of fields that are to be fetched from Wikidata (unless blacklisted or a local value exists);

There should be enough documentation at the module page to understand its design.

I've sandboxed a demo infobox at Template:Infobox book/Wikidata/Sandbox using the module, with more documentation and examples that can be pasted and previewed into any book article.

As with the 'Image legend' above, I'm considering merging this function - probably renamed to fetch() - into Module:Wikidata because it also does the job of returning values from Wikidata. However, because it is specifically designed for use with infoboxes, perhaps it should be in a Module:InfoboxUtils or Module:WikidataIB or something with a cleverer title? --RexxS (talk) 17:02, 18 May 2016 (UTC)

As nobody has commented in over a week, I've moved the sandbox module to Module:WikidataIB. I'll mark it up as alpha for folks to try out. --RexxS (talk) 22:00, 27 May 2016 (UTC)

How to get coordinates with proper format?

If I call P625 I get directly the text (XºY'Z"N...). But... how could I get it in a correct way in order to display it with coord templates? -Theklan (talk) 15:36, 8 April 2015 (UTC)

I've written a sandbox routine to fetch the coords from property P625 at Module:Sandbox/RexxS/PipedCoords. It's annoying that coordinates use ' and " as part of the string, but I can work around that. Testing it in London by pasting

• {{#invoke:Sandbox/RexxS/PipedCoords|getPipedCoords}}

into a short section and previewing it shows it returns "51|30|26|N| 0|7|39|W" which ought to work with the {{coord}} template like this:

• {{coord|{{#invoke:Sandbox/RexxS/PipedCoords|getPipedCoords}}|display=inline}}

but sadly that doesn't work because the Coordinates module used by {{coord}} doesn't recognise the output of my sandbox as a number - even though I can paste the result into {{coord}} manually and it works. I suspect that the Coordinates module call occurs before the call to getPipedCoords, so it fails at that point. If that's the case, then there's no way of using the output of the Wikidata module as parameters to templates that also use Lua.

Given the time, I could create a new version of the {{coord}} template/module that automatically fetched the coordinates from Wikidata as I suspect that's what you want to do. The problem with that is that we don't have agreement to use Wikidata calls outside of infoboxes at present. Look at the summary of Wikipedia:Requests for comment/Wikidata Phase 2 which is the RfC that decided. Hope that helps --RexxS (talk) 23:56, 8 April 2015 (UTC)

I mean, in other languages there is a formatStatements section in Module taht works with this. We've been using that system in eu:wp sometime, but now we changed to this module code, as it is more complete... and is not working anymore. But wait, maybe with yours we could create something that fetches the text in parts and makes it work with {{coord}} -Theklan (talk) 16:38, 9 April 2015 (UTC)

I'm here: User:Theklan/sandbox/coord -Theklan (talk) 18:16, 9 April 2015 (UTC)

@Theklan: Sorry it's been a while, but I've just been looking at {{Infobox telescope}} and came up against the same problem with coordinates. There is already a module written that deals well with the sort of problems we faced above, so I've made use of it in Infobox telescope. The call is {{Coord|nosave=1|display=inline,title}} which you can check in any article where Wikidata has coordinates. Or check first if coordinates exist: {{#if:{{#Property:P625}} | {{Coord|nosave=1|display=inline,title}} }} which avoids error messages. Is that any help? --RexxS (talk) 21:40, 6 June 2015 (UTC)

I'll look over it! Thanks about the reference! -Theklan (talk) 21:39, 14 June 2015 (UTC)

@Theklan: When I but {{coord|{{subst:#invoke:Sandbox/RexxS/PipedCoords|getPipedCoords}}|display=inline}} in some page its work so good but I found it doesn't work at 23 Marina because {{#invoke:Sandbox/RexxS/PipedCoords|getPipedCoords}} result 25|5|23|32|N| 55|9|2|20|E :

• {{coord|25|5|23|32|N| 55|9|2|20|E|display=inline}} and it should be like 25|5|23.32|N| 55|9|2.20|E {{coord|25|5|23.32|N| 55|9|2.20|E|display=inline}} :) --Mr. Ibrahem (talk) 21:49, 29 March 2016 (UTC)

@Mr. Ibrahem:. Currently we are using eu:Txantiloi:Cal coor for this, based on catalan Wikipedia. -Theklan (talk) 10:29, 4 April 2016 (UTC)

@Mr. Ibrahem and Theklan: Update: There's a call in the new module Module:WikidataIB that reads coordinates from Wikidata and sends them to the {{coord}} template in one call. For example, {{#invoke:WikidataIB |getCoords |name=coordinates |fetchwikidata=ALL}} in 23 Marina (23 Marina (Q216264)) would give: 25°05′23″N 55°09′02″E. --RexxS (talk) 23:22, 9 July 2016 (UTC)

Thanks for the info! As said, we are using eu:Txantiloi:Cal coor that makes all the calculations. Even we can get only one of the arguments (i.e. latitude minutes) so we can use it with other automated templates. -Theklan (talk) 08:56, 10 July 2016 (UTC)

Find QID using enwiki article pagename

Is it possible to get the ID (Qid) of an enwiki page by entering its pagename? Eg, in my sandbox I need a property of Apollo 11. How to find its Qid in code (being Q43653)? Having to look for its Qid is cumbersome. -DePiep (talk) 10:27, 26 July 2016 (UTC)

I was told that finding the qid of an article required editing any section of the page to preview what the following displays:

{{Q|{{#invoke:Wikidata|pageId}}}}

One problem with a scheme to translate a page title to a qid is that a title can easily be changed, so a simple lookup of some database would not be sufficient (and there is no database which tracks current page titles and qid). Johnuniq (talk) 10:36, 26 July 2016 (UTC)

See #QID lookup from enwp article title and #Way to get ID from page title? above. QIDs do not have unique names in Wikidata. You can get the QID on any article by viewing it and hovering (or clicking if you want) the "Wikidata item" link on the left navbar under Tools. -- ferret (talk) 11:18, 26 July 2016 (UTC)

Image legend

Following discussions at Template talk:Infobox telescope #Caption in another language, I've written a stand-alone module at Module:Sandbox/RexxS/ImageLegend to fetch the appropriate language version of the media legend (P2096) (i.e. image caption) for the best-ranked image (P18), principally to use in an infobox. The idea is that it helps creation of automatic infoboxes for articles as they are translated into other languages.

Both User:Mike Peel from the Astronomy wikiproject and his Lithuanian counterpart seem happy with how it is working. As this is a call to fetch data from Wikidata (albeit a specialised one), it seems that Module:Wikidata would be an appropriate home for it, rather than a stand-alone module. It also is useful exemplar code for anyone dealing with the raw ranks used by Wikidata. My plan is to merge it in as a new global function unless there are any objections. --RexxS (talk) 16:28, 18 May 2016 (UTC)

I have no objection to a merge, but I do have a thought: We might want to consider having a core Wikidata module and then a series of smaller Wikidata modules, based e.g. on data type extracted or on property or something. An e.g. Module:Wikidata images which would deal with images and image-related properties. --Izno (talk) 16:33, 18 May 2016 (UTC)

Well, I'm not too fussed about how we organise functions, but I'm not seeing any real advantage of multiple modules. The disadvantage is having to duplicate any internal local functions that are needed as well as the internationalisation. Then multiply that by the number of other language wikis who translate our modules. It's not as though we're working with objects that can inherit. Is there a point where a big module starts to impact performance? --RexxS (talk) 17:07, 18 May 2016 (UTC)

The largest pages with Help:CS1 still break I think, but besides that, I'm not aware of any cases where big modules cause performance issues (besides the known issue with syntax highlighting on the module pages in question of text over 100(?) kB). Of course, CS1 has the luxury of working only with the API, rather than (and in addition to) the WD API. I think there may end up being an organizational crisis within the module at some point as we continue to add functions here-and-there, but would agree that today is not that day. --Izno (talk) 17:19, 18 May 2016 (UTC)

I did a bit of housekeeping a few weeks ago and moved all of the local functions above the global functions, because I was having problems with calling local functions that hadn't already been defined in the module at the point of calling (I thought that failure mode went out with BCPL). Most of the time I try to write self-contained functions with all the code in-line as it's easier for others to re-use or translate, and adding new functions is less of a hassle that way. Anyway, it all looks a bit neater now. --RexxS (talk) 19:10, 18 May 2016 (UTC)

As there have been no further comments for over a week, I've updated the module to include the getImageLegend code. --RexxS (talk) 17:30, 27 May 2016 (UTC)

Thanks. Nemo 20:44, 14 August 2016 (UTC)

Labels for piped wikilinks

@RexxS:, could you ponder a way to pull a different property for the label of piped links? Short name can be used to define a shorter alias than the typical label, which may be verbose. Short name is monolingual. Example would be single-player video game (Q208850) versus single-player, which is the display we would want for Template:Infobox video game. Other uses would be with genres, such as action-adventure game versus action-adventure. -- ferret (talk) 18:40, 21 July 2016 (UTC)

I had a look at Pages that link to "Property:P1813" to get a feel for what the snags might be. I'm not sure that short name (P1813) is necessarily being used the way we want it to. For example the English label for Lionel Messi (Q615) is "Lionel Messi", but the entry for his short name property shows up as "Leo Messi (Spanish)" - which is actually "Leo Messi" with a mandatory "es" language qualifier.

I think you would have to duplicate the getValue function as getShortValue or something descriptive, and add a section to it (at current line 529 perhaps) which checked for the existence of entity.claims[P1813] and if entity.claims[P1813].mainsnak.value.language == "en". If so, then replace label with entity.claims[P1813].mainsnak.value.text. Actually, to account for possible multiple values, you'll have to iterate using k, v through the table of entity.claims[P1813].mainsnak.value for a match of v.language with "en" and store the corresponding v.text as label. You could draft that modified function in a sandbox module. Then prepare a sandbox version of the template that used getShortValue (or whatever) so that you could check it out in as many articles as possible to see if there are any errors such as entity.claims[P1813].mainsnak.value.language not existing even when entity.claims[P1813] does. My gut tells me it can't, but I could easily be wrong. Does that help? --RexxS (talk) 19:29, 21 July 2016 (UTC)

Been discussing this at Template talk:Infobox video game, but bumping the discussion here. I have added a getValueShortName to Module:Wikidata/sandbox. -- ferret (talk) 18:01, 11 August 2016 (UTC)

Will be looking to move getValueShortName live in the next day or two. -- ferret (talk) 01:31, 19 August 2016 (UTC)

I support the addition of the new function - will you update the documentation when you've made the change, please? --RexxS (talk) 02:00, 19 August 2016 (UTC)

 Done. Please notify if anyone feels it should be reverted as it will be used in an infobox template shortly. -- ferret (talk) 13:32, 19 August 2016 (UTC)

Broadening getImageLegend

It would be nice to be able to call legends for non-images too, e.g. sounds. I've been trying this at User:Mike Peel/Sandbox (try including it at e.g. Common cuckoo), but it doesn't work as it stands, presumably because it's linked to P18. Perhaps it could be widened to P51 (audio files) as well, and perhaps also videos? Thanks. Mike Peel (talk) 18:18, 14 September 2016 (UTC)

getThumb

it would be awesome if there was an easy way to generate thumbnail images with captions with getImages. basically combine the output of getImages and getImageLegend to generate the thumb images with their captions. if you search for 'insource:/property:P18/' you will see several articles where this would be useful. Frietjes (talk) 21:32, 27 September 2016 (UTC)

WMF grant for Russian module

I've just heard that the WMF have funded meta:Grants:Project/Putnik/Wikidata module, which aims to develop the Russian version of this module. I'm not sure how that links in with the development of this theme (or the one on the French Wikipedia)... It might be worth investigating this. Thanks. Mike Peel (talk) 18:18, 7 October 2016 (UTC)