Module talk:WikidataIB/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 → Archive 5

Can't get this working

Wikidata has the property:

About en:Prussian P 10, item: Prussian P 10 (Q882458). It has P176=Borsig (Company). So Wikidata seems OK.

In this case I test: 

-{{#invoke:WikidataIB|getValue|qid=Q882458|P176}}-

Returns empty string: --

Also, when previewing in article page itself (no |qid= used), it returns a blank. Am I missing something? -DePiep (talk) 17:32, 15 January 2017 (UTC)

@DePiep: Remember that this is designed for use in an infobox, therefore there are extra parameters that have to be enabled otherwise it won't return anything. The call matches the name of the field you're using it in with a list of fields that are to enabled ("whitelisted"). What you call the field doesn't matter as long as it's on the whitelist. So you can use:
  • {{#invoke:WikidataIB |getValue |qid=Q882458 |P176 |name=def |fetchwikidata=abd, def, ghi, jkl, etc}} →
And it will return manufacturer (P176) for Prussian P 10 (Q882458). I'll miss out the qid in the first part of the following examples as you won't need it other than for testing on pages like this.
Rather than having to list every fieldname on the whitelist, you can use "ALL". So the call you probably want is something like:
  • {{#invoke:WikidataIB |getValue |P176 |name=manufacturer |fetchwikidata=ALL}} →
Although if you're designing an infobox, you'll probably want to pass the whitelist (and blacklist) as parameters so the article editor supplies them once and the infobox passes them to each call in the design. Lets say we give them the names |whitelist= and |blacklist=. Then the code in the infobox design for the 'Manufacturer' field would be:
  • {{#invoke:WikidataIB |getValue |P176 |name=manufacturer |fetchwikidata={{{whitelist|}}} |suppressfields={{{blacklist|}}} |{{{manufacturer|}}} }}
The second unnamed parameter allows a local parameter (called 'manufacturer' in this case) to override the Wikidata call as ususal.
The infobox in use in an article could look something as simple as:
{{infobox something
| whitelist = ALL
}}
Does that make sense? Let me know if you're still having problems. Cheers --RexxS (talk) 02:03, 16 January 2017 (UTC)
Thanks, will process this. Could this be in the documentation? Sort of basic "required parameters" list? To me, the description & examples there are already quite abstract (into high end usage). Quite an object that requires studying. -DePiep (talk) 09:16, 16 January 2017 (UTC)

Coordinates

Just to note that it would be nice to be able to set the coordinates to display both inline and in the title (passing "|display=inline,title" to {{coord}}); this module just seems to allow inline coordinates. Thanks. Mike Peel (talk) 17:37, 18 December 2016 (UTC)

@Mike: I've implemented the 'display' parameter now. This is how it would work in Kitt Peak National Observatory (Q592248):
  • {{#invoke:WikidataIB |getCoords |qid=Q592248 |name=coord |fetchwikidata=ALL}} → 31°57′30″N 111°35′48″W / 31.9583°N 111.5967°W / 31.9583; -111.5967
You should see 31°57′30″N 111°35′48″W in the title position of this page as well.
You can't see multiple examples because the of title coordinates.
If you want to test the "title" or "inline" values, change the above to
  • {{#invoke:WikidataIB |getCoords |qid=Q592248 |display=title |name=coord |fetchwikidata=ALL}}
  • {{#invoke:WikidataIB |getCoords |qid=Q592248 |display=inline |name=coord |fetchwikidata=ALL}}
Of course, you don't need this so much now that the coord templates are Wikidata-aware, but it's useful if you want to implement the white/blacklists. --RexxS (talk) 11:55, 16 January 2017 (UTC)

Date handling

If more extensive date handling is ever needed, consider Module:Date which can parse dates in various formats, including a Wikidata date, and perform date arithmetic. However, the module is limited to four-digit years. The template {{extract}} can be used for quick tests although it does not expose options to choose the BC/BCE format.

  • {{extract|+2016-06-21T14:30:00Z}} → 14:30 21 June 2016
  • {{extract|+2016-06-21T14:30:00Z|show=ymd}} → 14:30 2016-06-21

Johnuniq (talk) 23:41, 20 January 2017 (UTC)

Thanks John. I think I had most of that functionality, as well as the BC/BCE and dmy/mdy/y functionality in Module:Wikidata in the getDateValue function, which dealt with any date BC or AD - I needed that for dob of notable Romans, etc. although the code was hard to read because I was using the timestamp and manipulating that directly. For greater flexibility in this module, I decided to use the mw.wikibase.formatPropertyValues() function – which always returns dmy format dates with BCE as appropriate – because that can be used on properties that are qualifiers as well. I'll need that later as fewer properties are defined and more values are stored as properties of qualifiers (like property:creator - qualifier:has role - item:video game artist instead of property:video game artist). Things like marriages have start-date and end-date that are in qualifiers. Anyway, I think I've managed to create a local function that takes the date in dmy+BCE format and outputs it in whatever format is wanted for use in article infoboxes. I've put a wrapper around it so that it's exported and can be invoked. --RexxS (talk) 04:00, 21 January 2017 (UTC)
Good, and I'm sure Wikidata has many quirks which require dedicated code. I just wanted to say that if more stuff such as date differences or adding time deltas were ever needed, Module:Date is available. Johnuniq (talk) 05:59, 21 January 2017 (UTC)

Alternative field names

{{Contains Chinese text}}

Hi, I'm from Chinese Wikipedia. How can I give an alternative name to a field? Because the Chinese language has multiple writing systems (traditional + simplified), each parameter usually both has a traditional and simplified (and sometimes, English) name. How to make the fetchwikidata or suppressfields field work when a traditional or simplified name of a parameter is filled in? Such as:

Jackie Chan (Q36970) 

{{Infobox entertainer/WD
<!-- English Wikipedia does not have this template, but this template is available on Chinese Wikipedia. It is called {{藝人/WD}} -->
| fetchwikidata = 出生地点
| name          = Jackie Chan
| type          = Actor
}}

or 

{{Infobox entertainer/WD
<!-- English Wikipedia does not have this template, but this template is available on Chinese Wikipedia. It is called {{藝人/WD}} -->
| fetchwikidata = 出生地點
| name          = Jackie Chan
| type          = Actor
}}

or 

{{Infobox entertainer/WD
<!-- English Wikipedia does not have this template, but this template is available on Chinese Wikipedia. It is called {{藝人/WD}} -->
| fetchwikidata = birth_place
| name          = Jackie Chan
| type          = Actor
}}

These will fetch place of birth from Wikidata. But now I can only use one of them to do that. --Dabao qian (talk) 16:24, 5 February 2017 (UTC)

@Dabao qian: I'm not sure I understand all that happens on Chinese Wikipedia when multiple labels are available. Nevertheless, I'll try to explain as much of WikidataIB as I can. Both fetchwikidata and suppressfields work by looking for the label/name of the field that is passed in the invocation, within the string that is passed by the article to |fetchwikidata= and |suppressfields=. So if the template defines 'Birth place' as something like {{#invoke:WikidataIB |getValue |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced={{{onlysourced|}}} |noicon={{{noicon|}}} }}, then |fetchwikidata=birth_place, birth_date, death_place, death_date (for example) would match the "|name=birth_place" in the infobox definition, and the call would return place of birth (P19). Using |fetchwikidata=ALL in an article would return all properties that are invoked in the infobox definition.
I think that you can avoid the multiple labels by deciding on using just one style of field name and documenting it, so that editors use just the string you specify in the list of fields passed to fetchwikidata and suppressfields. If you use "|name=birth_place" in the infobox definition, then editors have to use "|fetchwikidata=abc, def, ..., birth_place, ..., xyz".
I've just realised that your two examples you have 出生地點 ("Birth place") and 出生地点 (also "Birth place"). Does that mean you want to use both of those in your infoboxes? If so, then make two invocations in the infobox definition, one with |name=出生地點 and the other with |name=出生地点. Then use |fetchwikidata =abc, ..., 出生地點 出生地点, ..., xyz and both will be displayed, if that's what you want.
Please ping me again if I've not answered your query with something useful, and let me know if I can be more specific. Cheers --RexxS (talk) 19:32, 5 February 2017 (UTC)

Unsafe use of labels

Code like this: 

    local label = mw.wikibase.label("Q" .. v.mainsnak.datavalue.value["numeric-id"])
    if label == nil then label = "Q" .. v.mainsnak.datavalue.value["numeric-id"] end
    if sitelink then
        out[#out + 1] = "[[" .. sitelink .. "|" .. label .. "]]"

or like this: 

    local label = mw.wikibase.label(valueID)
    if not label then label = valueID end
    if sitelink then
        out[#out + 1] = "[[" .. sitelink .. "|" .. label .. "]]"

is not safe. Labels may contain any characters including [|]{} so a label could be constructed to generate e.g. any internal or external links. I suggest that you add mw.text.nowiki(label) before using labels in wikitext. The same applies to any string and text values from Wikidata. Best regards, Dipsacus fullonum (talk) 07:15, 3 February 2017 (UTC)

That's interesting. As it is clearly necessary to apply the mw.text.nowiki() function to every call to mw.wikibase.label() (without exception for the reasons given), it makes you wonder why the nowiki function is not applied to the mw.wikibase.label() internally. --RexxS (talk) 20:23, 5 February 2017 (UTC)

Bug in fetching referenced data

At Edward Bergh I added a second date at d:Q5572078 with year-only accuracy, as that's what I can easily find a reference for atm. Now that there's a reference, it displays the date in the infobox. However, it fetches the *unreferenced* date (with day-accuracy) rather than the referenced one (with year-accuracy). Not a big deal, since changing the rank causes the correct one to show, but this is probably an edge-case that should be fixed (@RexxS). Thanks. Mike Peel (talk) 16:35, 28 January 2017 (UTC)

(Note: I've found a ref for the day-accuracy one, so I've now removed the year-accuracy one from the entry, but this can be found in the history. Thanks. Mike Peel (talk) 16:39, 28 January 2017 (UTC)
Thanks, Mike. I'll have a think about how best to solve this issue. I originally thought that allowing date format to be set to "y" in the article would be enough, but sometimes there are two different date fields displayed with different precisions. It would be a shame to have to import the hugely complex date parsing code from Module:Wikidata that works from the raw timestamp just to ensure that we can respect the precision set by an referenced date. In many ways, the rank system at Wikidata is the "proper" solution – because a referenced date is always going to be preferred to an unreferenced one, and it makes that clear to other users of the Wikidata – but I know that we'd all prefer not to have to do that manually. Maybe a bot could be run on Wikidata which changed the rankings of unsourced statements to be lower than those of sourced ones? Can you see any downside in that? --RexxS (talk) 18:17, 28 January 2017 (UTC)
I think this is just a question of how the code should select which value to use, rather than having to affect the date formatting code. This could easily happen with a plain-text/Q-linked value as with a date. I haven't figured out the details of the ranking system on Wikidata myself yet - I'm not sure whether you can have more than one "preferred rank" value or not. Thanks. Mike Peel (talk) 18:30, 28 January 2017 (UTC)
@Mike: As far as I know, you can have many of each rank as you wish. The question is how should we deal with the case where multiple values of the property exist with the same rank? We would want to return as a list multiple values of most fields, e.g. occupation, but surely we wouldn't want multiple dates of birth returned? --RexxS (talk) 20:56, 28 January 2017 (UTC)
Apparently sometimes multiple dates of birth do need to be returned, e.g. from d:Q885424. So maybe just return all of the referenced statements for the highest rank available? Thanks. Mike Peel (talk) 22:52, 6 February 2017 (UTC)
I'd prefer to use a local parameter for such a case. We could then have "3 or 9 August 1858", rather than the list that the call would naturally return: "3 August 1858, 9 August 1858". That's because the call doesn't know that we would write the list of dates in the former way for disputed dates of birth. I could certainly make the list output with "or" separating the dates, but shorthand styles like "3 or 9 August 1858" and "30 July or 9 August 1858" are a lot more work to program, and hence more room for errors and edge cases, and I'd want to see a lot more testing in sandbox if we went down that route. --RexxS (talk) 04:34, 7 February 2017 (UTC)

Linking only to Wikipedia

Would it be possible to add an extra parameter that forces all links to be local, rather than to Wikidata, even if the article does not yet exist? E.g. something along the lines of Template:Wikidata list's "links=red" parameter (demo). That might then solve the concern raised at Template_talk:Infobox_person/Wikidata#Lack_of_redlinks. (@RexxS) Thanks. Mike Peel (talk) 15:04, 25 March 2017 (UTC)

@Mike: Well, as it happens, I was intending this weekend to update the getValue() call to check whether there is a redirect available to link to when there is no sitelink corresponding to the label on Wikidata, so I've taken the opportunity to do that job and add a new boolean parameter |wdlinks= which turns on or off the links to Wikidata. I've set the default to "no" links for now (i.e. just plain text if there's no enwiki article). Here is an example for Richard Burton's occupations (showing the redirects) and a couple of examples of George Orwell's awards (showing the wikidata links no/yes):
What do you think? --RexxS (talk) 18:25, 25 March 2017 (UTC)
P.S. I won't create automatic redlinks because making such a link must require a conscious decision that an article with that title should exist. It's not suitable for an automated task. --RexxS (talk) 18:27, 25 March 2017 (UTC)
Thanks @RexxS:, that seems like a good improvement. :-) I still think that it would be useful to have an option to fetch redlinks, though - this wouldn't have to be completely automatic, we could selectively enable it in individual infobox template lines, or in individual articles, as desired, so that they are added in a curated way. Thanks. Mike Peel (talk) 21:24, 25 March 2017 (UTC)
The problem is, Mike, that templates don't work like that. If we enabled red links for Richard Burton's occupation at the article level, we can't tell what occupation (P106) might be added in future - would we want, for example, Dog whisperer to be created as an article? How could we possibly judge ahead of time what property values might be added on Wikidata, and that we would definitely want an article on them? What if there were multiple values for a property and we only wanted to redlink some of them? --RexxS (talk) 00:54, 26 March 2017 (UTC)
That then comes down to editor judgement - it's an editor that would cause the redlink to exist (by editing Wikidata), and it's also an editor that would decide whether to create a new article, or remove the redlink. I'm suggesting an optional parameter, which could easily be added or removed as needed on a template/article-level basis, not something that is automatically used everywhere (i.e., it should not be the default). Thanks. Mike Peel (talk) 01:04, 26 March 2017 (UTC)
And editor judgement is exactly the problem. The editor (or bot) who adds the value on Wikidata probably won't even know that they would be creating a redlink in an infobox in an article on English Wikipedia. The Wikidata-haters would be the first to spot an inappropriate redlink in an infobox, and it would just be more ammunition for them in their mission to stop Wikidata being used anywhere on Wikipedia. I don't intend to waste any more time than I already do on arguing with them, especially on an issue that seems to me to be wholly preventable. --RexxS (talk) 10:10, 26 March 2017 (UTC)
Don't worry, I'm sure they'll use the fact that redlinks aren't supported as ammunition anyway. ;-) Personally I'm a big fan of redlinks, and think that they could be useful in some cases in the infoboxes, hence this request, but I can cope without them for now. Thanks. Mike Peel (talk) 10:43, 26 March 2017 (UTC)

New testcase

I have started developing a new testcase to support this initiative, where I am using this module in Template:Infobox deity/Wikidata, which is a wrapper of Template:Infobox deity. The module seems to not work for sibling and child, can someone please explain. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 18:33, 27 April 2017 (UTC)

I can only assume you're looking at articles where those parameters are unsourced on Wikidata. Using calls from WikidataIB, they will only display if sourced. I tried previewing {{Infobox deity/Wikidata |fetchwikidata=ALL |onlysourced=false}} in Rama and could see the Weapon/Spouse/Parents/Siblings/Children/Texts/Born fields. None of those show up using the default {{Infobox deity/Wikidata |fetchwikidata=ALL}} because none of them are sourced on Wikidata. The fix is to add proper sources to the Wikidata entries. --RexxS (talk) 22:34, 27 April 2017 (UTC)
Got it now, thanks. I couldn't add the qualifier and had to comment it in affiliation. Are qualifiers only allowed for specific QID's? Is there a way to add qualifier without mentioning the pval? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 05:20, 28 April 2017 (UTC)
You may have seen Module talk:Wikidata #Qualifiers where I discussed this problem in more detail. The core of it is that properties can have multiple values and each value can have multiple qualifiers, so how would anybody know which of the possible multiple results is the one you want? The usual example I give is that Richard Burton (Q151973) was married five times, so the property spouse (P26) has five values, each of which has a start time (P580). So if we tried to fetch the start time of Burton's spouse, which of the five start times would you expect to be returned? None of the calls in the earlier Module:Wikidata to retrieve qualifiers works properly for that very reason. Try previewing {{#invoke:Wikidata|getQualifierDateValue|P26|P580|FETCH_WIKIDATA}} in a section of Richard Burton and you get "15 March 1964, 3 July 1983, 5 February 1949, 21 August 1976, 10 October 1975". What use is that to anybody? If, and only if, you can guarantee that the property will have exactly one value, then you can simply fetch the qualifier(s) for that. But as you have no control over someone who might add more information at Wikidata, you can't possibly guarantee there will always be just one property value. --RexxS (talk) 17:04, 28 April 2017 (UTC)
The way I see it, if we link the qualifiers to property and fetch property instead of qualifiers, we might be able to solve it. See |sibling= for example. By default, it fetches all and show as comma separated values. We can fetch properties as br separated and qualifiers as comma separated. Another example, The case I'm using, Rama, I want to show "Avatar of Vishnu". So I can fetch Vishnu using getvalue. If it's possible, allow to fetch all values of incarnation as br separated values and give some formats to display. Examples Qualifier of Propertyval, Propertyval (Qualifier), etc. I might have missed something, so please elaborate if I'm wrong somewhere. `-- Pankaj Jain Capankajsmilyo (talk · contribs · count) 17:20, 28 April 2017 (UTC)

Alphabetical output?

@RexxS: Would it be possible to have an option to sort the Wikidata values alphabetically? This shouldn't be on by default, but it would be useful in cases like the "includes" part of Belfries of Belgium and France. Thanks. Mike Peel (talk) 00:48, 9 May 2017 (UTC)

{{#invoke:WikidataIB |getValue |qid=Q151973 |P26 |fetchwikidata=ALL |onlysourced=no}} → Elizabeth Taylor, Sybil Christopher, Suzy Miller, Elizabeth Taylor, Sally Burton Edit this on Wikidata
{{#invoke:WikidataIB |getValue |qid=Q151973 |P26 |fetchwikidata=ALL |onlysourced=no |sorted=yes}} → Elizabeth Taylor, Elizabeth Taylor, Sally Burton, Suzy Miller, Sybil Christopher Edit this on Wikidata
@Mike Peel: That's a first attempt – just a simple alphabetical sort on the text. It's not smart, so it treats links as '[['; sorts given names before last names; doesn't de-duplicate, etc. Would you have a look at the particular example you're interested in and see whether the |sorted= parameter is adequate for your purposes, please? If not, it's a lot more messy to code it into what we might consider a "smarter" sort. Cheers --RexxS (talk) 21:38, 9 May 2017 (UTC)
@RexxS: Thanks! I've implemented it in the includes parameter of Belfries of Belgium and France. It seems to work very well, although there is the oddity between "Ypres Cloth Hall" (link) and "Cloth Hall, Ypres" (Wikidata label), which appears at the end of the list - it look more natural if it were sorted on the displayed name rather than the linked name. But that's a minor thing. :-) Thanks. Mike Peel (talk) 21:46, 9 May 2017 (UTC)

Birthplace

Birthplace only shows the city / village in which the person was born in. Is it possible to fetch the state as well from wikidata? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:26, 10 May 2017 (UTC)

Broken

@RexxS and Pppery: Something has gone seriously wrong - values aren't being fetched from Wikidata through this template at South Pole Telescope or any other telescope article. The values that are being shown are through {{convert}}, not this template. This is possibly something to do with onlysourced=no? Thanks. Mike Peel (talk) 11:33, 16 May 2017 (UTC)

YEs, I many a silly typo when I refactored some duplicate code. Now fixed. Pppery 11:35, 16 May 2017 (UTC)
Phew, thanks. :-) Mike Peel (talk) 11:37, 16 May 2017 (UTC)

New parameters: sorted, sep and list

I've implemented three new parameters that still need to be documented:

  • |sorted= is a boolean passed to enable sorting of the values returned. No parameter, or an empty string, or "false", or "no", or "0" disable sorting. It's only a very dumb alphabetical sort and sorts linked values as "[["
  • |sep= allows the separator between multiple returned values to be defined. The default is ", ". If the separator has leading or trailing spaces, enclose it in double quotes (e.g. |sep=" - ").
  • |list= allows multiple returned values to be displayed as a horizontal list (|list=hlist), or a vertical unbulleted list (|list=ubl). These override the separator and do not display the 'pen icon' linked to "Edit at Wikidata"

If any problems occur, please ping me and I'll try to sort them out. --RexxS (talk) 16:14, 18 May 2017 (UTC)

getQualifierValue only works for properties that are Q-number valued ?

It seems getQualifierValue only works for properties that are Q-number valued.

Is there a good reason for this? I had been hoping to use it to extract a qualifier from a property that is external-identifier valued, for example:

  • {{#invoke:WikidataIB |getQualifierValue |P1367 |pval=simpson-charles-walter-18851971 |qual=P1114 |fetchwikidata=ALL |qid=Q5083334 }}
->

to extract the number of works at Art UK associated with Charles Walter Simpson (English artist) (Charles Walter Simpson (Q5083334)).

Also, is it possible to omit the value for pval= in cases where there is only one pval, since my template is not currently written to handle cases when there is more than one anyway? Thanks. Jheald (talk) 09:35, 20 February 2017 (UTC)

@Jheald: Indeed, I only wrote the function getQualifierValue to deal with properties that are wikibase-entities because I knew that infoboxes will normally only be dealing with those sort of values for qualifiers (because of the multi-lingual nature of Wikidata). If somebody comes up with an exception, I can handle that with extra code, but as this module is specifically intended for use in creating infobox templates, I was lazy.
Now, in your case, handling of external identifiers for use in different templates is worth making a separate module for, as we don't need any of the black/white-listing and source-filtering facilities of WikidataIB. So I've made Module:WikidataIdentifiers to hold functions related to that. Try previewing {{#invoke:WikidataIdentifiers |getIdentifierQualifier |P1367 |qual=P1114}} in Charles Walter Simpson (English artist) and you should get 27 (unless somebody changes it in Wikidata). If you want to use it outside of his article, then the expansive call is available:
  • {{#invoke:WikidataIdentifiers |getIdentifierQualifier |P1367 |qual=P1114 |qid=Q5083334}} → 27
The function assumes that there is only one value for the property Art UK artist ID (P1367) – list of exceptions are at d:Wikidata:Database reports/Constraint violations/P1367 #Single_value – and that the value has only one qualifier which is a quantity. I can expand the code to cater for other types of qualifiers, but you'd have to tell me what other types you anticipated. Naturally, the #invoke can be wrapped in a template to sweeten the syntax for others. Hope that does the trick for you. Cheers --RexxS (talk) 15:39, 21 February 2017 (UTC)
I feel I've now been given a fantastic early birthday present, all wrapped up in a bow!
{{Art UK bio}} is now starting to update across 750 transclusions, with a potential further 6,500 ready to add.
I sent an email to Art UK on Friday with the list of potential duplicates from Wikidata (all of which seem pretty plausible); but no response from them as yet.
Thank you again for such-appreciated Lua magic, and very best regards, Jheald (talk)
Would it also be possible to have a routine that pulls source properties, in particular P813 "retrieved" ? (And perhaps a pretty date formatter?) I should perhaps be including that information when the external id is being cited as a ref. Jheald (talk) 19:27, 22 February 2017 (UTC)
@Jheald: I'm not very good at working in the abstract, as it involves too much second-guessing what folks want. But if you could give me a concrete example of a Wikidata entry and the information you want retrieved from it, I could have a bash at writing the code. This module already supports date-formats as |df= with allowed values of "dmy", "mdy" and "y" – is that what you were thinking of for the dates? as I could just re-use that code in the other module. --RexxS (talk) 20:07, 22 February 2017 (UTC)
On second thoughts, no worries. Mostly when people are using the site for a reference, it probably makes more sense to keep the retrieved date hard-coded as to when they looked at the site; rather than when the link was most recently verified, and the number of paintings updated. At least that's what I'm doing at the moment. But let me get back to you if I find a case where using the sourcing from Wikidata would be useful. Jheald (talk) 20:13, 22 February 2017 (UTC)

Update: It seems that quantity (P1114) has been superseded by number of works (P3740) for this sort of application. Fortunately this requires only a minor tweak:

  • {{#invoke:WikidataIdentifiers |getIdentifierQualifier |P1367 |qual=P3740 |qid=Q5083334}} → 27

--RexxS (talk) 15:07, 23 May 2017 (UTC)

King

I have recently created {{Infobox royalty/Wikidata}} and trying to find a way to use this module to fetch (position held=king), (reign=starttime-endtime), (predecessor=replaces), (successor=replacedby), (succession="King of"+of). For an example, you can check Jayasimha Siddharaja and its associated Wikidata item. Please help. Thanks. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:58, 15 May 2017 (UTC)

References

If we are ever going to heavily use this module, we need an option to fetch references with the data value, something like |getValue refs=yes, which would append references to the end of the fetched string (before the pen icon). Template:Wikidata can do this. Maybe this module should call it, so we are not duplicating code and effort? Laurdecl talk 07:44, 19 June 2017 (UTC)

This would be really useful. Note that the way we're currently using this module to fetch the info, and the other module to fetch the references, means that sometimes the wrong references get fetched from a different value of the property than is shown. Fetching both at the same time with consistency always would be good. Thanks. Mike Peel (talk) 12:20, 19 June 2017 (UTC)
(BTW, I know fully supporting references with all the different reference templates would be a lot of work, but the basic setup of just using cite web is working reasonably well so far, and is better than nothing.) Thanks. Mike Peel (talk) 12:22, 19 June 2017 (UTC)
The problem is, Mike, that Wikipedia supports so many different styles of references (I don't mean types like web, journal, etc.) that it's not possible, as far as I am able to tell, to format the resulting reference so that it matches the existing style in an article. I'm sick of having the arguments about citation formatting – see Talk:Jane Austin for example – and I'm not prepared to put in time and effort to create solutions that just give the whiners something else to complain about. When Wikipedia grows up and creates a "house style" for references, then it would make the effort worthwhile. --RexxS (talk) 09:59, 20 June 2017 (UTC)

Wrapper template

We currently can't pass the result of this module to templates like {{convert}} because the Lua is processed after the Wikitext template. This means we can't use things like {{If empty}} as well. If we had a wrapper template that called this module, would that be solved? That seems better than invoking a module anyway. This would instantly solve the problem with computing ages for Template:Infobox person/Wikidata. RexxS? Laurdecl talk 07:25, 20 June 2017 (UTC)

It's easy enough to create a template to wrap the module – why not make one and see if it forces the order of evaluation that you want? My usual solution is to write a new call inside the module that manipulates the table in getValue and then passes that table to frame:expandTemplate(), see how {{hlist}} is called around line 341 in the current module here. Module:Wikidata has a separate function that passes its output to {{coord}}, but it isn't used much. I suppose I ought to re-write this module to uncouple the output formatting from the part that fetches the data into two separate functions internally, then it would be easier to write new outputs, either by passing an additional parameter to getValue, or by making a new public function that only had to modify the processing of the output. --RexxS (talk) 09:59, 20 June 2017 (UTC)
If we use a template, we might as well call Module:Wd with a few qualifiers and attach the pen icon on the end. Is there a good reason we have Module:Wd, Module:Wikidata, and Module:WikidataIB? The other two can handle references, and use different templates, etc. The code for getting only sourced values could easily be merged in. We're maintaining three different forks for no reason... Laurdecl talk 00:45, 22 June 2017 (UTC)
As Module:Wikidata dates from 19 May 2013 and Module:Wd dates from 20 August 2016, you might want to address that question to User:Thayts. If you want to go ahead and merge all three modules, please feel free to go ahead. You'll still find that the problems are not in writing the code, but in meeting all of the conflicting demands of the users. --RexxS (talk) 09:24, 22 June 2017 (UTC)

qid= if needed

Template:Infobox lighthouse is used on articles about lighthouses and also in more general articles. Sample: Vuurtoreneiland. To enable it to read d:Q2921152, I added item=Q2921152 and used "qid={{{item|}}}" in the template when calling this module, but it looks like it doesn't work when the article doesn't need it (e.g. Kõpu Lighthouse). Is there way to have it default to the item that goes with the article? Jura1 (talk) 18:45, 20 July 2017 (UTC)

Actually, it works as expected. There was another problem. Jura1 (talk) 22:52, 20 July 2017 (UTC)

Mannar Island Lighthouse (old)

Mannar Island Lighthouse (old) is displaying "Lua error in Module:WikidataIB at line 271: attempt to index field 'datavalue' (a nil value)." for Deactivated in the infobox. No relevant recent edit has occurred at the article. Is the problem wikitext in the article or is it a problem in this module? Johnuniq (talk) 06:12, 25 July 2017 (UTC)

Thanks, John, the problem was in the module. I hadn't checked for the possibility of time values being set to "somevalue" in Wikidata. Should be fixed now. Cheers --RexxS (talk) 13:44, 25 July 2017 (UTC)

Lua error on unknown value

{{#invoke:WikidataIB|getValue|P195|qid=Q2246489|fetchwikidata=ALL|onlysourced=no}} is currently returning Unknown, Isabella Stewart Gardner Museum, unknown Edit this on Wikidata as the second value there is "unknown value". Thanks. Mike Peel (talk) 00:03, 2 July 2017 (UTC)

Ok, Mike. I think I've resolved the error by checking for values that have a snaktype of "somevalue" (which is what is actually stored in the database), and returning "Unknown value" as you can now see above. I'm not sure what you wanted the code to do when it found a value like that, but at least you can explicitly test for "Unknown value" if you want to handle it in a template. Otherwise, let me know what action you want the code to take. Cheers --RexxS (talk) 23:12, 2 July 2017 (UTC)
Update: to keep it in line with the time handling, I've amended the return value to just "Unknown" (exactly that). I think it looks better if it's used raw than "Unknown value". Hope that doesn't cause problems. Cheers --RexxS (talk) 16:22, 25 July 2017 (UTC)

Short names

Hi @RexxS: I'm working on a revised version of {{Infobox video game}} that uses this module rather than Module:Wikidata. The template currently uses getValueShortName, would you be able to add support for that here as well please? getPreferredValueShortName would also be useful (or perhaps a shortname=yes parameter would be a more general solution). Thanks. Mike Peel (talk) 01:35, 8 August 2017 (UTC)

Building

Hello, I just noticed that there might be less opposition in using wikidata in {{Infobox historic site}} as these are mostly developed on wikidata being famous sites. Therefore, I have initiated {{Infobox historic site/Wikidata}}. You are invited to help build and deploy it in mainspace articles. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 16:39, 18 September 2017 (UTC)

getRawQualifierValue & sub-template use

Hi @RexxS: Thanks again for your help on Template:Ordination. I'm trying to gradually convert the majority of its parameters to Wikidata-enabled. In the template's sandbox, I'm trying to call the non-linked value of a qualifier and then have it appear after a comma which is after the place of consecration parameter. These are two separate questions, which I have run into trouble with. Do you know how this might be done? I've tried the following, just out of intuition, but it does not seem to work:
{{comma separated entries | {{#invoke:WikidataIB |getQualifierValue |P793 |pval= Q125375 |qual=P276 |name=place of consecration |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|}}} |qid={{{qid|}}} |{{{place of consecration|}}} }}
| {{#invoke:WikidataIB |getRawQualifierValue |P793 |pval= Q125375 |qual= P131 |name=place of consecration |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|}}} |qid={{{qid|}}} |{{{place of consecration}}} }} }}
I do not think my use of {{Comma separated entries}} is right and I'm not sure if getRawQualifierValue exists. If it makes it clearer, the output I'm trying to achieve is (e.g. on Pope Francis article): "Buenos Aires Metropolitan Cathedral, Buenos Aires" in the place of consecration parameter. Ergo Sum 01:56, 22 September 2017 (UTC)

@Ergo Sum: It's best to start with a concrete example, so I always take a look at what the Wikidata entry contains. For Pope Francis (Q450675), we find a significant event (P793) with a value consecration (Q125375) that has three qualifiers: point in time (P585), location (P276), located in the administrative territorial entity (P131). We don't need the first qualifier, but the other two are what you're looking for. So we can construct two getQualifierValue calls. In Pope Francis they would return:
  • {{#invoke:WikidataIB |getQualifierValue |P793 |pval= Q125375 |qual=P276 |name=place of consecration |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|no}}} |qid={{{qid|}}} |{{{place of consecration|}}} }} → Buenos Aires Metropolitan Cathedral Edit this on Wikidata
  • {{#invoke:WikidataIB |getQualifierValue |P793 |pval= Q125375 |qual=P131 |name=place of consecration |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced={{{onlysourced|no}}} |qid={{{qid|}}} |{{{place of consecration|}}} }} → Buenos Aires Edit this on Wikidata
Now, the snags are:
  1. You have to use |onlysourced={{{onlysourced|no}}} to make it default to fetching unsourced values because there's no good reference for Francis' place of consecration in Wikidata - otherwise you won't see anything. It would be good to fix that.
  2. As you have guessed, there's no getRawQualifierValue call written yet, so Buenos Aires is wiki-linked. The problem will be that some places like Ouagadougu really need to be linked, whereas London almost certainly doesn't. I don't have a simple algorithm to make that sort of decision, so it's hard to write the code to automate the process.
However, if you can put up with the value of located in the administrative territorial entity (P131) being linked for now, then using {{Comma separated entries}} with the two calls as its parameters is exactly the right way to go. Hope that helps. --RexxS (talk) 12:48, 22 September 2017 (UTC)
@RexxS: I tried the code you cited above (at Template:Ordination/sandbox), but now when the parameter is locally supplied, it shows up twice as comma separated entries. I am trying to make it so that if the parameter place of consecration is used, neither Wikidata qualifier value is called. Ergo Sum 15:59, 22 September 2017 (UTC)
@Ergo Sum: yes, if the Wikidata call has a local parameter supplied, it returns it (in order to simplify the construction of infoboxes). Of course if we make two calls and supply the local paramter twice, we get the local parameter returned twice. I've demonstrated two solutions (and tested them in Pope Francis):
  • A simple change - this calls the Wikidata only if the local parameter is absent. However, if the local parameter is supplied but set to blank (i.e. |place of consecration=), then the field is suppressed.
  • A slightly more complex change - this calls the Wikidata if the local parameter is absent or supplied but set to blank.
I'd recommend the latter, as editors at the article level are accustomed to treating a blank parameter as if it were absent. Although we can distinguish between the two cases inside a template, my experience with Module:Wikidata (which exploited that) tells me that we cause too many difficulties when we try to go against what editors expect. Cheers --RexxS (talk) 16:37, 22 September 2017 (UTC)
Thanks @RexxS: I've implemented the latter option and it works fine. Ergo Sum 19:13, 22 September 2017 (UTC)

Century date problem

Hi @RexxS: Odd things are happening when using this module to fetch birth/death date values from Wikidata that are along the lines of "15. century". See Lorenzo Veneziano (Q2656102) and Absolon Stumme (Q332331) as examples. Using {{Infobox person/wikidata|fetchwikidata=ALL|onlysourced=no}} on the enwp pages for those two returns incorrect values, namely 1390 in the first (rather than 14th century) and 1500 in the second (rather than 15th century). Over in the ptwp articles the code throws an error rather than displaying the values, "Erro Lua em Módulo:WikidataIB na linha 141: attempt to call global 'makeOrdinal' (a nil value).", which may be related or may be a different problem. Any chance you could have a look, please? (also @Sturm.) Thanks. Mike Peel (talk) 11:55, 25 September 2017 (UTC)

Ah, there are some local changes to the module on ptwp for dates, see [1], so that's probably where the error is being caused there... Thanks. Mike Peel (talk) 11:58, 25 September 2017 (UTC)
Hi Mike. It's not terribly surprising that Lorenzo Veneziano's date of death was returned as 1390 as that's the value actually stored in Wikidata. Similarly Absolon Stumme's date of birth is stored as 1500. I've now added code to WikidataIB to cater for centuries properly and taken the opportunity to internationalise a bit more, as well as further sorting out the different precisions. At present, "century" is the largest epoch the code will deal with, as I don't have an experience of timestamps bigger than that. No doubt they will eventually crop up and I've got a placed marked in the module to handle those as soon as I have concrete examples to work from.
Sadly the Portuguese have imported part of Module:Wikidata as well (presumably for the internationalisation), but forgot to import the function that goes with it - "makeOrdinal()" converts 15 to 15th, etc. Nevertheless, the present module is much more capable of being internationalised, so if you know any of the folks on ptwp, ask them to either re-import the latest WikidataIB from here (and redo the words they need in Portuguese), or at least copy over the makeOrdinal function from near the top of this module. Cheers --RexxS (talk) 16:33, 25 September 2017 (UTC)
Thanks @RexxS. I've made some i18n tweaks to the sandbox version, can you check that they look OK please? I'll ping the ptwp people about updating this there. Thanks. Mike Peel (talk) 22:04, 25 September 2017 (UTC)
@RexxS: Also, I'd forgotten that there was functionality in the sandbox for the minor planet links (in {{Infobox telescope}} and {{Infobox observatory}}, which is now removed. Can that code be recovered and moved into the main version now, please? Thanks. Mike Peel (talk) 22:32, 25 September 2017 (UTC)
Thanks Mike. Those are good, except I've had to revert one of your changes (at line 336) because that instance of "BCE" is only internal, and isn't output. The idea is to make use of function format_Date() which I wrote to take a formatted date that looks like "1 August 30 BCE". i.e. the format produced by some of the library calls. The result is that function looks for "BCE" specifically to indicate a "negative" date, so may not do what you expect if you feed it something else - it will need a re-write to fully internationalise it, although the output is still fully internationalised. However, the parameter |bc= is expected to be "BC" or "BCE" (if present) for now, so deeper changes would be needed to translate those. --RexxS (talk) 22:36, 25 September 2017 (UTC)
I'm sorry, Mike. It's late and I can't figure out what's been lost. Why were those changes left in the sandbox? can you remember? I really do have problems with failing memory now, and anything more than a day or so old is hazy, so I'm probably best off starting again from the version from before today. That's a lot of work and I'll have to find time in the next few days if I can. --RexxS (talk) 22:45, 25 September 2017 (UTC)
It's OK, go get some rest! :-) I think we were testing the links out in articles, and just didn't get around to moving the code into the main module. I think that the edits for the dates and the link formatting are in separate parts of the code, so hopefully it won't be too difficult to merge them back together. Thanks. Mike Peel (talk) 23:01, 25 September 2017 (UTC)
[Update:] Mike, I think I've rescued all of the lost code from the earlier sandbox. It seems to be working so I've updated the main module to the rescued code in the sandbox, and updated Template:Infobox telescope accordingly. Please keep an eye out for any glitches. --RexxS (talk) 19:37, 28 September 2017 (UTC)
Thanks @RexxS:, it all seems to be working again. :-) I'll let you know if I spot any problems! Thanks. Mike Peel (talk) 23:16, 28 September 2017 (UTC)

getPreferredValue error

@RexxS: Try the following code at Giant Magellan Telescope: {{#invoke:WikidataIB|getPreferredValue|P3439|name=angular_resolution|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|{{{angular_resolution|}}}}} It gives an error "Lua error in Module:WikidataIB at line 503: attempt to index local 'claim' (a nil value).". If you change it to use getValue, then the error goes away. Any ideas? Thanks. Mike Peel (talk) 13:40, 29 September 2017 (UTC)

@Mike: Well it worked with the original version of getPreferredValue that I wrote, dated 17:35, 17 July 2017 and all subsequent versions until my last edit. I think there's a problem with trying to use preferred ranks as well as formatPropertyValues(), but I made an error by not looping through all values, as it left the loop variable unset. Anyway I've implemented a specific handler for quantities now, and it's returning the 'amount' as a number plus the Wikidata label associated with the 'unit'. It's sanitised against malicious code injections, but not against normal vandalism. I suppose I'll have to look at handling ranges next. --RexxS (talk) 16:16, 29 September 2017 (UTC)
Thanks for the quick fix! Mike Peel (talk) 21:35, 29 September 2017 (UTC)

Internationalisation

It is helpful for editors working in other languages to see exactly what needs to be changed to achieve the same functionality in their language. So 

local function makeOrdinal (cardinal)
	local ordsuffix = i18n.ordinal.default
	if cardinal % 10 == 1 then
		ordsuffix = i18n.ordinal[1]
	elseif cardinal % 10 == 2 then
		ordsuffix = i18n.ordinal[2]
	elseif cardinal % 10 == 3 then
		ordsuffix = i18n.ordinal[3]
	end
	-- In English, 1, 21, 31, etc. use 'st', but 11, 111, etc. use 'th'
	-- similarly for 12 and 13, etc.
	if (cardinal % 100 == 11) or (cardinal % 100 == 12) or (cardinal % 100 == 13) then
		ordsuffix = i18n.ordinal.default
	end
	return tostring(cardinal) .. ordsuffix
end

is deliberately specified for each exception to the default. In general, the code is written at present to prioritise debugging and ease of reading/translation. Condensing it and removing sections into local functions makes that job more difficult and should not be attempted until the code is stable and out of alpha. --RexxS (talk) 21:54, 29 September 2017 (UTC)

Did you intentionally revert my changes that weren't related the the restructuring of makeOrdinal. Pppery 00:14, 30 September 2017 (UTC)
@Pppery:. Yes, when you make multiple changes like that, you need to make them as separate edits, otherwise somebody else has to go thorough and unpick each bit; and as I was in the middle of more work on the module, you made the main module unsynchronised with the local copy I where I was working, so it was simpler to just restore the previous version. Is there any reason why you don't use the sandbox to try out changes first? As for the other changes, I'm just about to revert them again, as they alter the behaviour of the module. The prior version allowed me to isolate the entire handling of each data type that I'm writing handlers for, which is helpful for debugging and introducing requested features. In other words, the algorithm I envisaged priorities the test for data type as the first level. By moving the loop through the properties to the top level, and then checking for somevalue/novalue, we loose the ability to customise either of those on a per data-type-handler basis. That loss of flexibilty in a module that is still under active development is pointless. --RexxS (talk) 10:16, 30 September 2017 (UTC)

getAT with PAGENAMEBASE & sorting chronologically

@RexxS: I'm trying to allow Template:Ordination the ability to have the title of a Wikidata item's associated Wikipedia article called when the appropriate QID is entered. However, currently, the template calls {{PAGENAMEBASE}}, not the {{PAGENAME}}. Is there a way to have the same done for the Wikidata call? E.g. use getAT and have it fed through PAGENAMEBASE (or something similar)? The order of preference in which parameters should go is name otherwise qid otherwise PAGENAMEBASE.
I'm also running into a conceptual issue. The template has two ordination sections: Diaconal and Priestly. Currently, ordination (Q7519600) is being called and used for Priestly Ordination in the template, along with the qualifier point in time (P585). However, rather than creating a new property or item, I would like to enter ordination and point in time twice on a given item and have the template call both, with the one qualified by the earlier date going to the diaconal ordination parameters and the one with the later date going to the priestly ordination parameters. Is this at all possible? Ergo Sum 17:19, 30 September 2017 (UTC)

I'm sorry, Ergo Sum, I really don't understand what you want in the first part. Which title, which item is it you want? Can you give me concrete example so that I can analyse it, please?
You can use getQualifierValue to get multiple values for point in time (P585) if they exist as qualifiers for significant event (P793) = ordination (Q7519600) in Wikidata, but I would have to write a new call to return just the first or second sorted value. Then you'd have to specify how you wanted to handle the cases where there is just one point-in-time or when there are three or more values for point-in-time present in Wikidata. Wouldn't it be easier to create new items in Wikidata for "priestly ordination" and "diaconal ordination" as they are distinct and different events as far as I can see. --RexxS (talk) 20:41, 30 September 2017 (UTC)
@RexxS: Sorry for not being clear. I'm trying to use getAT so that when parameter qid is used in the template, e.g. {{Ordination|qid=Q450675}}, the name of the Wikipedia article (in this case "Pope Francis") that Francis (Q450675) is linked to is called. When called, it would be displayed in the above area of the template where name or PAGENAMEBASE currently goes, as well as in the header21 area, where it would override PAGENAMEBASE, but would be overridden by name, which in turn could be overriden by surname. However, the article name called by inserting the QID would be overridden by name and would default to PAGENAMEBASE when both name and the getAT value are absent.
As for the second part, I would gladly do that, but I thought one of the Wikidata rules is that an item must be linked to some other Wikimedia page, i.e. a Wikipedia article. There is no Wikipedia article for priestly ordination or diaconal ordination, only for "ordination" in general. I may be mistaken about this rule (since I focus more on Wikipedia). Is this not the case? Ergo Sum 20:57, 30 September 2017 (UTC)
If it makes it clearer, I've tried to implement part of the first part of what I'm talking about at Template:Ordination/sandbox, but it's not quite working out at Template:Ordination/testcases, so something must be going wrong. What I haven't tried to do though, is call a PAGENAMEBASE through getAT, only the article title. Ergo Sum 21:41, 30 September 2017 (UTC)
(edit conflict) @Ergo Sum: Sure, in defining the template "above" parameter you could use {{#invoke:WikidataIB |getAT |{{{qid|}}} }} to get Pope Francis from Pope Francis (Q450675). I'm not sure what problem you're having.
d:Wikidata:Notability is the relevant policy. It says

Wikidata in its first phases has two main goals: to centralize interlanguage links across Wikimedia projects and to serve as a general knowledge base for the world at large. An item is acceptable if and only if it fulfills at least one of these two goals, that is if it meets at least one of the criteria below:
2. It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references.
3. It fulfills some structural need, for example: it is needed to make statements made in other items more useful.

Could you find serious and publicly available references that describe "priestly ordination" and "diaconal ordination"? or make the argument that infoboxes have distinct fields for these items, so they would serve a structural need? --RexxS (talk) 22:02, 30 September 2017 (UTC)
@RexxS: I've just edited the Template:Ordination/sandbox so that the problem is visible there. I've implemented the code as you suggest. The template behaves properly when using name or qid, but when placing a blank template, instead of returning PAGENAMEBASE, it now returns ' and I'm not sure why.
Also, yes I could certainly make the case for the latter. Do I have to literally do so, or can I go ahead and create those items on Wikidata under the premise that they are justified as such. Ergo Sum 22:10, 30 September 2017 (UTC)
@Ergo Sum: I've picked apart the testing:
  1. if |name= is given, use that;
  2. otherwise if {{#invoke:WikidataIB |getAT |{{{qid|}} has a value, use that;
  3. otherwise use PAGENAMEBASE
That seems to work. Can you follow that now?
Why don't you just create the items - look at ordination (Q7519600) and see what properties you could add to your new items. Start with instance of (P31) set to 'ordination'. --RexxS (talk) 23:59, 30 September 2017 (UTC)
@RexxS: Yes, thank you for the help. I'm not tremendously familiar with Lua, so you've been a huge help. I've gone ahead and implemented your edits on the sandbox. The one remaining question, though is whether it is possible to have getAT filter out the same part of the title that {{PAGENAMEBASE}} filters out. For instance, on Luciano Giovannetti (bishop), the title includes the parenthetical part, which getAT would include in its called value. {{PAGENAME}} would call the whole title: "Luciano Giovannetti (bishop)", while {{PAGENAMEBASE}} would call all of it except the parenthetical: "Luciano Giovannetti". Is there a way to have getAT do the same thing that PAGENAMEBASE would do in this case? Ergo Sum 00:17, 1 October 2017 (UTC)
Also, is there a way to do the same this as was done with the above area to the surname area? In this case, though, there would be an additional level: surname > name > qid > PAGENAMEBASE. Ergo Sum 00:53, 1 October 2017 (UTC)
@Ergo Sum: See if you can figure it out from these:
  • {{#invoke:WikidataIB |getAT |Q1782078 }} → Luciano Giovannetti (bishop)
  • {{#invoke:String|match|{{#invoke:WikidataIB |getAT |Q1782078 }}|^[^%(]+}} → Luciano Giovannetti
  • {{#invoke:String|match|{{#invoke:WikidataIB |getAT |Q450675 }}|^[^%(]+}} → Pope Francis
  • {{#invoke:String|match|{{#invoke:WikidataIB |getAT |{{{qid|}}} }}|^[^%(]+}}
Don't add extra spaces! --RexxS (talk) 01:13, 1 October 2017 (UTC)
@RexxS: I tried a couple different things and each one produced "Target string is missing." Is it something along the lines of replacing {{{qid|}}} with another {{#invoke:WikidataIB...}}? Ergo Sum 18:19, 1 October 2017 (UTC)
I figured out the solution and implemented it. Thank you for the help. Ergo Sum 02:18, 3 October 2017 (UTC)

Page label being returned with dimensionless unit?

@RexxS: {{#invoke:WikidataIB|getValue|P1090|qid=Q41161882|name=redshift|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|{{{redshift|}}}}} returns "0.11 GW170814" when used in GW170814 (although oddly, here it returns "0.11 ±0.04 Edit this on Wikidata"). However, it should return either 0.11 or (better) 0.11±0.04. Somehow the page label is getting mixed in, but only when it's used in the article, not here... Thanks. Mike Peel (talk) 12:10, 1 October 2017 (UTC)

@Mike Peel: The unit for a dimensionless unit is stored as "1", whereas other units are stored as a url to their Wikidata entry, e.g. "http://www.wikidata.org/entity/Q829073". Taken together, not a very clever idea. The code I wrote extracts the Qnnn. The labelOrId function then uses the nnn to find the label associated with that Wikidata entry as the unit. Unfortunately, if there is no Qnnn, we get a nil result; calling labelOrId with a nil value returns the Wikidata label for the current page as if it were the unit. This page doesn't have a Wikidata label, so we don't get anything here.
I've fixed the problem in the sandbox and tested it in a few places. I'll now look at making it render the range. --RexxS (talk) 14:24, 1 October 2017 (UTC)
@Mike Peel: Ranges now added in sandbox:
  • {{#invoke:WikidataIB/sandbox|getValue|P1090|qid=Q41161882|name=redshift|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|{{{redshift|}}}}} → 0.11 ±0.04 Edit this on Wikidata
Please have a look for edge-case errors. Thanks --RexxS (talk) 14:55, 1 October 2017 (UTC)
@Pppery: Can you have a look at merging this in from the sandbox, please, since your recent edits have diverged from the sandbox? Thanks. Mike Peel (talk) 17:00, 7 October 2017 (UTC)
My recent edits to this module made no changes for the code for displaying (non-unknown-value) quantities, other than dedenting it two or three levels. Merging shouldn't cause any conflicts. {{repeat|p|3}}ery (talk) 22:17, 7 October 2017 (UTC)
@Pppery: Could you merge one way or the other - either from the sandbox to the main version, or the main version to the sandbox, please? Thanks. Mike Peel (talk) 22:21, 7 October 2017 (UTC)
 Done (only merged the quantity handling changes from the sandbox to main) {{repeat|p|3}}ery (talk) 22:26, 7 October 2017 (UTC)

Error on 'unknown value'

Edward the Confessor (Q130005) has "unknown value" for date of birth (P569), with qualifiers giving the range of possibilites. Currently if you do {{#invoke:WikidataIB|getValue|P569|qid=Q130005|fetchwikidata=ALL}} then you get an error message, "Lua error in Module:WikidataIB at line 306: attempt to index field 'datavalue' (a nil value)." Thanks. Mike Peel (talk) 11:29, 9 October 2017 (UTC)

If it's any help:
{{#invoke:WikidataIB/sandbox|getValue|P569|qid=Q130005|fetchwikidata=ALL}} →
{{#invoke:WikidataIB/sandbox|getValue|P569|qid=Q130005|fetchwikidata=ALL|onlysourced=no}} → Unknown Edit this on Wikidata
Perhaps Pppery can try again at syncing the sandbox with the main module? --RexxS (talk) 14:19, 9 October 2017 (UTC)
Fixed. {{repeat|p|3}}ery (talk) 17:27, 9 October 2017 (UTC)
Thank you. Is there a way to do getQualifierValue in this kind of case? Mike Peel (talk) 18:34, 9 October 2017 (UTC)

Linguistic variants

Hi, I'm from ptwiki and I have a question: In Wikidata, we have two linguistic variants of Portuguese (Portuguese (from Portugal) and Brazilian Portuguese). This module in ptwiki gets label content in the following order if the previous is not available: 1. Portuguese (pt), 2. in Brazilian Portuguese (pt-br), 3. English (en) and 4. QID.

Brazilian Portuguese is the most spoken (75% of lusophone people, +-20 times the European Portuguese), so I was wondering if there's a way to invert the order the module gets the labels to 1. pt-br, 2. pt, 3. en and 4.QID ? Thanks for your help! Ederporto (talk) 04:55, 10 October 2017 (UTC)

Also, theres a concern of some portuguese editors that the content should not be presented if there's no pt or pt-br label for it (i.e. no label in english or QID should be presented in that case). Is that possible? Ederporto (talk) 05:00, 10 October 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:WikidataIB/Archive_1&oldid=1086699624"