Jump to content

Module talk:Wikidata/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Module talk:Wikidata
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 04:26, 15 August 2016 (Archiving 1 discussion(s) from Module talk:Wikidata) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 1Archive 2

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. --RezonansowyakaRezy (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.

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, Lua error in Module:Wikidata at line 190: attempt to index global 'v2' (a nil value).. 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.--JohnBlackburnewordsdeeds 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)Template:Z48

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)

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

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 wikidata: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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Wikidata/Archive_1&oldid=734559819"