Jump to content

Template talk:Infobox person/Wikidata/Archive 1

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

References

@Laurdecl: It was great to see these added, but understandably they were removed given that there are some issues with them still (e.g. see Module talk:Wd). Perhaps we could add them back as an optional feature, so that we can test them on individual articles for now? Should be simple to wrap them in a parser statement - something like {{#ifeq:{{{refs|no}}}|yes|<refcode here>}} should do the job. Thanks. Mike Peel (talk)

Hi Mike Peel, I removed the refs mostly because thought someone would complain about clutter in the infobox. I didn't realise there were issues with the template I used (or I didn't see any at least), as far as I remember they didn't duplicate local references. I'm not sure though, wrapping it as an option like you have above and testing is probably a good idea. Laurdecl talk 06:08, 31 January 2017 (UTC)
Hi, Laurdecl. Thank you for your attempts to add extra functionality to the template. I'm really grateful for your interest and keenness, and I'm very sorry to see that you were dragged into the inexplicable dispute going on at ANI. The biggest problem with references is that Wikipedia does not have a single style of referencing, yet requires consistency in the style of referencing used in any given article. Although it's relatively trivial for a human to spot what style is in use, that information is not easily available to an infobox, and certainly isn't available from Wikidata. That makes coding the fetching of references for display in an infobox a difficult problem, and my gut reaction is that we need yet another additional parameter for the infobox to specify the reference style. That brings me to the question of how to generate a good reference from what we can draw from Wikidata. My preference would be to start by using the existing {{cite web}}, {{cite journal}}, {{cite book}}, etc. and when that's working, add switches for other styles. Fortunately the Lua implementation here allows us to return a call to a template, by assembling its parameters into a table and passing that. You can see an example at lines 296-319 in Module:WikidataIB as the getCoords() function returns via {{coord}}. Have a think about that as a way forward. You may find it less hassle by working on changes in the sandbox and then previewing articles with the sandbox version to spot bugs, before committing changes to the main template. That way there's nothing for the nay-sayers to complain about happening to articles until you're sure that the change works 100%. Cheers --RexxS (talk) 14:45, 31 January 2017 (UTC)
Hi RexxS. What I wanted to do was add an automated age calculator to the template and an "aged x" after the birth/death date. I've done that, and it seems to work well in every case I've tested (example (dead), example (alive)). The references were just a side thing I added (and commented out) to not make it seem like the dates were pulled out of thin air. Thanks for the advice, I'll see if I can do something when I have more time. Laurdecl talk 06:06, 1 February 2017 (UTC)
@RexxS and Laurdecl: I've added the reference code back as an optional parameter, with a test case at Juana Rosa Aguirre (no other articles should be affected). It seems to work quite well, which is a fantastic step forward, except for the duplicate reference issue. In this case that isn't a problem as the article has been unreferenced and was tagged as such back in 2010, which is a rather bigger problem! Looking at {{Wd}}, I think this uses {{cite web}}, which is a sensible place to start, but adding options for other ref formats would be good. Thanks. Mike Peel (talk) 01:16, 2 February 2017 (UTC)

Suggestions

As a side note Mike Peel, I suggest you have a look at fr:Modèle:Infobox_Biographie2, which appears to be the same as this infobox, but with many more features and seems to be commonly used throughout the French wiki. Take a look for example at this article. Also, I don't think the edit bar at the bottom looks too good at the moment (I assume it's this template), perhaps making it look like a footer as the French do is a good idea. Cheers, Laurdecl talk 05:26, 3 February 2017 (UTC)

@Laurdecl: The French infobox is constructed entirely in Lua, so can only be developed by Lua programmers. That means that every time they want to upgrade an new infobox to be Wikidata-aware, they have to write a new section in Lua to deal with the labels and parameters for that infobox. We have hundreds of different types of infoboxes and that is a daunting task for anyone to undertake here. I have taken a different approach by writing smaller functions in Lua to be the building blocks that template editors can use to upgrade existing infoboxes field-by-field. This has also facilitated the development of the whitelist/blacklist that allows infoboxes to be 'opt-in' or 'opt-out' (see Wikipedia:Village pump (policy)/Archive 128 #RfC: Wikidata in infoboxes, opt-in or opt-out?). There's no such feature on the French version, nor is there the ability to reject unsourced data, as far as I can see, other than using |field= - in each field that the editor doesn't want to be displayed.
At some point in the future, I'm sure that infoboxes written entirely in Lua will be the norm here. But first we have to get acceptance that Wikidata-aware infoboxes offer advantages and that debate will inform the features that should exist in our infoboxes.
I'm considering turning off the [edit on Wikidata] link when the pen icons are displayed next to each field, and only having the link display when the display of the pen icons is turned off with |noicon=true. What do others think? --RexxS (talk) 15:46, 3 February 2017 (UTC)
Ah, thanks for the clarification, I was wondering why no one had just used the French template. Removing the link at the bottom when there are pen icons is a great idea. Laurdecl talk 21:05, 3 February 2017 (UTC)
I think the French version of the template mostly has the same features that are available in WikidataIB, or are there specific extra ones you're referring to? I was hoping to update this template to match (as much as we reasonably can) the property numbers from that template, but then the TfD started and put that plan on hold.
Turning off the [edit on wikidata] link when the pen icons are there sounds fine to me. Thanks. Mike Peel (talk) 21:31, 3 February 2017 (UTC)
I've eventually got the {{EditOnWikidata}} template working as I wanted, so that the default is selectable at the infobox level. Have a look at the documentation now, and decide whether you want the display off or on by default if |noicon= isn't supplied by an article. I'd recommend 'off' as the pen icons are 'on' by default. --RexxS (talk) 12:35, 4 February 2017 (UTC)

Age bug at Boris Pilnyak

Hi @Laurdecl There seems to be a bug in the date handling code, see this version. It's possibly caused by the presence of a Julian date / specified calendar system. The same bug is also present at Charles Blount, 8th Baron Mountjoy when the death_date isn't locally defined. Could you or @RexxS have a look, please? I can't spot anything obviously wrong. Thanks. Mike Peel (talk) 22:26, 6 March 2017 (UTC)

Yes, the problem is caused because "/Julian" is appended to the end of the dates. There should be something in Template:Wikidata to just get the raw value. Laurdecl talk 11:39, 7 March 2017 (UTC)

This template violates WP:REDLINK by substituting Wikidata links for redlinks. This is both confusing for readers (who will not expect to be taken to a different site when clicking on the link) and counterproductive as it discourages the creation of missing articles on Wikipedia. We should instead present the reader with a redlink when an article doesn't exist, just like any other template. Kaldari (talk) 07:48, 24 March 2017 (UTC)

Additionally, it even subsitutes Wikidata links for bluelinks, if the bluelink is a redirect. The template should not point any links to Wikidata items (it can link via the pencil icons or the general "edit on Wikidata" link, if necessary).
This is not specific to this template, it's the way that Module:WikidataIB is coded. I've requested a new option that would provide redlinks. (Although Kaldari, I'd tag both of your claims with citation needed ;-) ). Thanks. Mike Peel (talk) 15:05, 25 March 2017 (UTC)
@Kaldari: So you'd prefer not to let anybody know that information is available on a particular topic, just because the information is available on a sister project? What's next on your agenda, delete Template:Interlanguage link because that might take the "unsuspecting reader" to another language Wikipedia? The Wikidata link is marked by default with the Wikidata logo, inside a span which has its title set to "Article is available on Wikidata, but not on Wikipedia". It is anything but counterproductive because it gives an editor an immediate resource of information on the topic, pointing them to the references supporting that information.
Additionally, it does not substitute Wikidata links for "bluelinks" when the item is a redirect, because the "bluelink" doesn't even exist at the source (Wikidata). Your time would be better spent persuading the folks over at Wikidata to allow those "bluelinks" (actually sitelinks) to exist in the first place.
As for your assertion that "The template should not point any links to Wikidata items", I'll treat that with the contempt it deserves. Of course we should have links to Wikidata items, and a perusal of the archives at Module talk:Wikidata will show you the considerable consensus for those, as well as provide you with some clue about the thought and effort that has gone into making sure they are well marked as links to Wikidata.

Please remove citizenship

Citizenship is usually included in Wikidata, but in template:infobox person, it should rarely be used: "Country of legal citizenship, if different from nationality. Rarely needed. See usage notes for nationality above. Should only be used if citizenship cannot be inferred from the birthplace; note that many countries do not automatically grant citizenship to people born within their borders. Do not link if a commonly known country. Do not use a flag template." (from the template documentation). Basically, it should usually not be linked, and it should "rarely" be used, not standard like this version of the infobox does. Please remove it from the /Wikidata infobox (people can still add it here for the relatively few cases where it is actually needed). Fram (talk) 08:44, 8 May 2017 (UTC)

I agree that it's too difficult to programmatically decide whether the country is "commonly known", so there's no way of knowing whether to link it or not; similarly there's no simple means of distinguishing between countries that automatically grant citizenship to everyone born within their borders (like the USA) and those that do not (like GB). I've disabled fetching country of citizenship (P27) from Wikidata. The parameter |citizenship= remains in the template to allow values to be added manually in the minority of cases where it is needed. --RexxS (talk) 16:19, 8 May 2017 (UTC)
Thanks. Fram (talk) 20:29, 8 May 2017 (UTC)

Avoid showing the same thing twice

In Wikidata, the same info is often added twice to an item. This Wikidata problem should not propagate to enwiki but be checked at the gate. E.g. Gottfried Benn has "Awards Georg Büchner Prize, Officer's Cross of the Order of Merit of the Federal Republic of Germany, Officer's Cross of the Order of Merit of the Federal Republic of Germany". Please remove this possibility from the template (or preferably from Wikidata). Fram (talk) 07:21, 9 May 2017 (UTC)

"Often" = "this was a mistake in this specific case" (or are there other examples of this?). As far as I can see, this didn't show up on enwp, and even if it did it was trivial to fix this on Wikidata. Thanks. Mike Peel (talk) 01:10, 10 May 2017 (UTC)
It did, and has in other cases, and it seems like it would be trivial to prevent. Nikkimaria (talk) 02:21, 10 May 2017 (UTC)
Mike Peel, it is always trivial (to you) to fix an individual error on Wikidata once someone has pointed it out. This ignores that a) many such errors are floating around, even in the few test cases we have here, b) many very serious errors on Wikidata remain for a very long time, because very few people at Wikidata do any damage control, vandalism reversion, and so on, and c) I don't come here to ask you to fix this instance of the problem, but to fix it at the root. This thing (the same info added twice to Wikidata) happens often enough, and it should be prevented from showing twice here (for other information, e.g. date of death, you succeed in only showing the incorrect, ruwiki-sourced version, but not the correct, BNF-sourced version; but for this, you show it all, even when it is the same info given multiple times...). And please, next time I present you with an error and give the actual quote from the enwiki article, it would be graceful if you didn't doubt that this showed up on enwiki. I don't make up errors (I don't need to as I have plenty to choose from anyway). Fram (talk) 06:30, 10 May 2017 (UTC)

Individual errors

I think there's an important point here to consider more broadly. This template is currently used on c. 400 articles. If we intend to have it be used more broadly, we should look beyond "this specific error is trivial to fix on Wikidata" to think about what types of errors can or should be avoided by design. Is "issue X" in that category? That's open for debate, but if this template is to work the default answer to every bug raised shouldn't be "just fix it on Wikidata". |onlysourced= is a great step in that direction, cutting down significantly on passing through material that doesn't meet local verifiability standards without requiring that we go through and source or remove every detail about every subject on which the template is used. Nikkimaria (talk) 01:57, 11 May 2017 (UTC)

@Nikkimaria: It is simply a fabrication to say that the default answer to every bug raised shouldn't be "just fix it on Wikidata". In response to concerns raised over time, I've incorporated the following:
  • Whitelisting and blacklisting to give the editor control over data at the article level (solving the "opt-in vs opt-out" issue), |fetchwikidata= and |suppressfields=;
  • The ability to show or hide the 'edit-on-Wikidata-icon' for each infobox field, |noicon=;
  • The ability to enable or disable a filter that removes any data not sourced to something better than Wikipedia, |onlysourced=;
  • Better handling of cases where the target link is a redirect, as well as the ability to enable or disable a link to the Wikidata entry when no entry exists on Wikipedia, |wdl=;
  • The ability to enable a simple alphabetic sort of multiple values, |sorted=.
Now I don't want to be rude, but nothing seems to please some people. You have to understand that some issues, like duplicate values and lack of an English label, are best fixed on Wikidata, and that's what I've explained. I find it disgraceful that my good-faith efforts to produce the best solutions to problems are twisted into the default answer to every bug raised shouldn't be "just fix it on Wikidata". I thought you were better than that, Nikki. --RexxS (talk) 14:48, 13 May 2017 (UTC)
@RexxS: I think you've interpreted my statement in a way completely different to how I intended it to be seen - I apologize for being unclear, as I did not mean at all that you've done nothing to address concerns (and specifically raised onlysourced as an example of how you had). What I was trying to raise as a broader point is, we as a group should consider what issues are isolated cases (which can and should be addressed by simply editing the Wikidata item) and which would likely be regular occurrences if this template were to be widely adopted (and so should be addressed systemically, either with changes to the template or to Wikidata where necessary). I personally think the Q-number issue falls in the latter camp; you of course may disagree. Nikkimaria (talk) 16:41, 13 May 2017 (UTC)

Onlysourced=yes should eliminate all "imported from Wikipedia" information

Stefan Andres has "onlysourced=yes" and gives "Died 29 July 1970 Edit this on Wikidata (aged 64)" The article gives 29 June (instead of July) as date of death. Looking at Wikidata, I can find both dates, but 29 July is only sourced to "Imported from Russian Wikipedia", while the correct 29 June is sourced to the BNF and the IAF. Please make sure that, when we only want sourced information, we don't get any information "imported from ... Wikipedia". Fram (talk) 08:03, 9 May 2017 (UTC)

@Fram: Please accept my apologies for taking so long to get around to this, but I've not found time earlier to research the problem beyond looking at Stefan Andres and Stefan Andres (Q68036). I can confirm that several problems exist around the handling of date of birth (P569) and date of death (P570) and I do not doubt that you saw a problem, even though I could not see it myself when I looked.
On Wikidata, the properties for date of birth and date of death are designated as "single value", which means that only one value should exist, but there may be exceptions. When exceptions exist, the usual means of handling such exceptions is to either remove inaccurate multiple values or deprecate them. In some cases, it may be best to mark one value as 'preferred'. When that is done, the code in Module:WikidataIB returns the single preferred (or non-deprecated) value. I've now been looking through d:Wikidata:Database_reports/Constraint_violations/P570 #Single_value and not only are there far more exceptions that I would have anticipated, many of them don't possess a preferred value. Unfortunately, because WikidataIB uses the API call formatPropertyValues() for dates, it returns an unpredictable value when multiple values exist with the same preferred rank. Most of the time, there will be a value which is clearly better, as in Émile Zola (Q504), and we can mark those as 'preferred' on Wikidata. But there will be other cases where two conflicting dates of death are stored on Wikidata, as in the case of Paul Morand (Q272): 23 July 1976 (sourced to http://data.bnf.fr/ark:/12148/cb11916728t) and 24 July 1976 (sourced to http://www.britannica.com/EBchecked/topic/391846/Paul-Morand and the Integrated Authority File). There are also very rare cases where multiple dates of death have been mistakenly reported as in Abubakar Shekau (Q2822101). In very rare cases there are as many as four possible dates of birth – see Saint Walpurga (Q160686), where a locally supplied value is probably the best course.
So we need to decide how we want to handle cases where multiple valid values exist on Wikidata, where we would only expect one in an infobox:
  1. We could display all of the sourced values and let editors decide whether they wanted to edit Wikidata to mark one as preferred, supply a local value, or suppress the field as needing a proper discussion in the body text. The problem would be of displaying multiple values in an infobox (not desirable) until editors decided which they wanted.
  2. We could display nothing if multiple sourced values exist for these sort of dates. The problem would be of having valid information available, but giving no indication of that in the infobox.
  3. There may be some other solution.
In any case, I will need to overhaul the date-handling code in Module:WikidataIB so that it doesn't rely solely on the API call and preferred ranks, but it would be helpful if we could decide on what we want to do when there are multiple sourced values with equal preference for fields like date of death, so that I can incorporate that at the same time. Constructive suggestions are welcome. --RexxS (talk) 17:27, 15 May 2017 (UTC)
Update: today I've overhauled the entire getValue code in Module:WikidataIB and ensured that the date-handling no longer uses the wikibase formatting call. That should ensure that when multiple dates exist, each date is processed from its raw timestamp and each one that is definitely sourced is added to the list to be returned. It will cause issues with cases like Paul Morand (Q272) where the BnF and Britannica disagree, but that's best solved by editors reaching a consensus on a locally supplied value.
It's possible that my re-write may have altered some articles in an undesirable way: please let me know asap if you spot any. Cheers --RexxS (talk) 17:52, 16 May 2017 (UTC)

Don't show Q-numbers in infobox please

Please change the template to make sure that this can not happen again. It shows "Works Q3213238" in the infobox, which is definitely not wanted here. It has been avoided now in this specific article, but it shouldn't be possible to happen in general. Fram (talk) 08:33, 8 May 2017 (UTC)

The same happened here as well: [1].

It's a signal to an editor that the entry has no English site label. That means that anyone who is interested in maintaining our projects as a whole can choose to add labels to entries such as The Treason of the Intellectuals (Q3213238) and Morgue and other poems (Q22281590). Why would we want to discourage editors from doing that? --RexxS (talk) 16:06, 8 May 2017 (UTC)
We display infoboxes for the reader, not for the editor. The reader has no message with Q21545, they only see an unintelligible bit of mumbo-jumbo. Fram (talk) 20:30, 8 May 2017 (UTC)
Would it be possible to display only for those who are logged in, for example? Of course it is always possible that an IP would be interested in editing Wikidata, but most are readers only. Nikkimaria (talk) 00:16, 9 May 2017 (UTC)
This is the Wikidata equivalent of a redlink. It's easy to fix - just add a new English label on Wikidata (as RexxS has). Or should redlinks only be shown to logged in users now? Thanks. Mike Peel (talk) 01:09, 9 May 2017 (UTC)
A typical redlink is understandable to any reader, whereas the "Wikidata equivalent" is not. Even if the article doesn't exist, you have some idea what Independent Publisher Book Award might represent, just from looking at it. Nikkimaria (talk) 01:41, 9 May 2017 (UTC)
Agreed. A redlinked or unlinked piece of text is still understandable text, this is just a bit of coding which should never appear in our articles (not even for logged in readers, but certainly not in general). Fram (talk) 07:18, 9 May 2017 (UTC)
Whereas here, you click on the link and see the label in French of "La Trahison des Clercs". Since it's a French author, that's a close second to seeing the translated name. And if you want, you can then quickly add a translation. Mike Peel (talk) 11:45, 9 May 2017 (UTC)
And next time it will be a Kazakh, Pakistani, Lebanese, Nahuatl, ... author and I will not even see the label (when I go to Wikidata, I only see the labels in a few languages), never mind be able to correctly translate it (i.e. finding an actual published title if one exists, not making up a translation!). No, having a Qnumber is not acceptable as it is in itself unintelligible and in most cases not easily corrigible for our readers. Fram (talk) 12:09, 9 May 2017 (UTC)
And what if you were a reader from those countries (given how many readers we have whose native language is not English)? Or someone who is interested in the topic that's covered and knows the language? Or someone who can provide a translation (creating a new translation is not "making one up" - unless we've made up most of our interwiki links). No, this limited thinking is not acceptable. (But then, just saying "no, this is not acceptable" is not a proxy for community consensus).
Perhaps we should try to default to showing an available language version, perhaps matching that to the nationality of the topic where possible. That would probably be quite difficult to code, but it would be a more productive outcome than just saying "don't mention that we don't have a translation of this yet". Mike Peel (talk) 01:05, 10 May 2017 (UTC)
That would only be true if you assume the available language version is something that is meaningful to readers here - which becomes less likely as we move into less-spoken languages or those with different alphabets. We may potentially help the minority of readers by confusing and alienating the majority. And if you're going to bring up community consensus, recall the glass houses principle and that the question under consideration here has not yet been subjected to community consensus. Nikkimaria (talk) 02:18, 10 May 2017 (UTC)
Indeed, starting about "community consensus" seems to me something that could seriously backfire, as I doubt that most people on enwiki (outside of the samll Wikidata-bubble) would support showing Qnumbers, and the reluctance of the more ardent Wikidata-proponents to realise this, and the way this discussion shows how far they are out of touch with standard community norms and with what is our priority here (not correcting and improving Wikidata, but showing useful, readable information to our readers), will only reflect badly on further attempts to introduce Wikidata more widely here. I came here with my remarks, instead of creating a fuss about them, as a show of goodwill. But the response here (and below, where even when I provide an actual example the reality of the problem is doubted by you) makes me wonder whether such an approach can be really fruitful. Fram (talk) 06:25, 10 May 2017 (UTC)
Unfortunately for your thesis, it's wikidata-haters like yourself who are out of touch with the community. Sure, you can whip up some artificial indignation about "community norms", but the truth is that 99% of readers couldn't care less about your campaign to remove everything wikidata-related from Wikipedia. And editors – apart from yourself – are perfectly willing to support measures that both show useful, readable information to our readers and correct and improve Wikidata, because they know it has a beneficial knock-on effect to other language Wikipedias. You present a false dichotomy – it's not either one or the other. You found there wasn't community support for getting rid of this template as you wanted, and your concerns in that debate have been addressed or fixed; so you now come nit-picking over very minor edge cases that can be quickly solved by anybody willing to make a simple edit on Wikidata. A value on Wikidata is wrong? Correct it! Somebody has duplicated a value on Wikidata? Get rid of the duplicate! An English label is missing from Wikidata? Add the missing label! It's not rocket science. --RexxS (talk) 21:34, 10 May 2017 (UTC)
@RexxS: What do you think about the possibility of displaying Q-numbers only to logged-in editors? This will display them to the set of users who are most likely to have the knowledge and inclination to improve Wikidata, and not display them to the set of readers who will generally not find them useful and readable. Of course not a perfect solution, but seems a good balance of the two competing goals. And to all: could we ratchet down the rhetoric? Nikkimaria (talk) 01:50, 11 May 2017 (UTC)
I agree. The average reader has no idea what "QXXXXXXX" is, nor do they care. Laurdecl talk 02:55, 13 May 2017 (UTC)
Thank you RexS for again showing that you haven't got a clue about most of this. Do you really believe that most editors are willing to check and correct two sites to get an article right, when it can be done on one just as well? Do you really believe that most editors hare think it's fine to have an infobox importing errors from another site which you simply have to fix there (despite that other site having different standards, editing environment, rules...) once someone notices the error (which usually takes a lot longer than on enwiki in the first place)? Not even the few people adding the template care about these problems, they just want to include it in more and more articles and damn the consequences. That you consider including a wrong date, based on Russian wikipedia, instead of the right date which is present in both our article and in reliable sources in Wikidata, a "minor edge case" is typical. Fram (talk) 06:56, 11 May 2017 (UTC)

As you can't be bothered to take this and the errors below serious and have no intention to prevent Wikidata errors and problems from polluting our articles, instead requiring people to correct Wikidata to get a correct article here, i've just renominated this for deletion. Th etemplate isn't ready for the mainspace, Wikidata isn't ready to be used as a reliable source or database for biographical articles (as it is filled from unreliable sources which don't get adequately filtered out, has problems reverting vandalism in a timely manner, and has no BLP or V policies, never mind enforcing them). Feel free to spout the usual attacks at the TfD. Fram (talk) 12:15, 11 May 2017 (UTC)

People would take your supposed attempts to improve this template more seriously if you didn't nominate it for deletion every time you don't get what you want. Laurdecl talk 02:55, 13 May 2017 (UTC)
Fram's deletion nomination found "no consensus to delete". So the community consensus is now clear. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:03, 30 May 2017 (UTC)
Congratulations on interpreting a "no consensus" closure as a "clear consensus". Fram (talk) 09:07, 30 May 2017 (UTC)

Age again

Mária Bátorová is currently set to supress |birth_date=, but the age is still displaying. I wondered if this might have been because of recent changes to the template, but that doesn't appear to be the case. Nikkimaria (talk) 03:34, 30 May 2017 (UTC)

The logic used in the template suppresses the display of the birth date, but still allows the age to be calculated and displayed unless the death date is also suppressed. As that section of the coding is particularly impenetrable, the simplest work-around for now is simply to suppress the death_date field as well. If there are any circumstances where we want to show death date, but not birth date or age, let us know the article and someone can use it to update the template code and check that it's working. Thanks for spotting that.
At some point, someone is also going to have to sort out how the template should display age when a local value of birth_date is supplied which is different from that in Wikidata, not to mention what we want to do with subjects who have more than one date of birth there (there are thousands of them, e.g. Charles the Great (Q3044) has five). --RexxS (talk) 16:39, 30 May 2017 (UTC)
@RexxS: Robert McNeill Alexander has death date but not birth date; no age is displayed. Alexandra Adler has a local birthdate and Charles Conrad Abbott a local death date; both display age. However, those two examples have local settings because there are multiple values being provided by Wikidata, and when both values were displaying age was still displayed - and in the case of Abbott, one of the provided values was year-only. See this version for Adler and this one for Abbott. Nikkimaria (talk) 23:26, 30 May 2017 (UTC)
We should move the age code to the WikidataIB module. It is currently the only part of the infobox using Template:Wikidata instead of the Lua module. As RexxS notes, the code is very messy to check so many edge cases, especially in wikicode. I imagine it would be easier in Lua. Laurdecl talk 07:13, 31 May 2017 (UTC)

Convert to wrapper

I think this template should be converted to a wrapper of {{Infobox person}}, as suggested in last Tfd. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 01:46, 5 June 2017 (UTC)

This will supress fields not permitted on {{Infobox person}} (eg. religion and ethinicity), import styling and keep it updated and synced with the main infobox. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:49, 6 June 2017 (UTC)

No. This is intended to (eventually) replace {{Infobox person}}. The end goal was never to have an obscure side template. Laurdecl talk 09:17, 6 June 2017 (UTC)

Indeed, there's no point having two templates for the same thing in the long run, so this template has been designed so that it can be merged in with the main template once the Wikidata code/logic and expectations for how it displays things are worked through. Also, there's a risk that people will then think it can be substituted, which would make a right mess. Thanks. Mike Peel (talk) 23:39, 6 June 2017 (UTC)

Marriage year, where it is clear and sourced

When there is only one year / date mentioned on wikidata along with WP:RS, is it possible to fetch marriage year in that case? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:41, 6 June 2017 (UTC)

How are you going to fetch only instances with RS? What would you do with marriage end? Nikkimaria (talk) 03:30, 6 June 2017 (UTC)
If you are not aware, let me introduce you to the magical param built by RexxS called |onlysourced=, which is by default set to "yes". -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 04:01, 6 June 2017 (UTC)
I'm well aware of the parameter. What you seem to be unaware of is that it does not ensure the data is supported by RS, as you assert. Nikkimaria (talk) 10:54, 6 June 2017 (UTC)
Nikki is right, Capankajsmilyo. I can write code that ensures that a value is sourced, even that it's sourced to something better than "Imported from Xyz Wikipedia" (or any other fixed condition that we can agree on); but I can't write code that guarantees that the source on Wikidata meets our definition of a reliable source in the context of a particular article. I'm pretty sure that's what she's trying to tell you. Although to be fair, in non-Wikidata-enabled infoboxes, there's no guarantee the the information therein is reliably sourced either. We have to just do our best, and improve referencing whenever we can, I guess. Cheers --RexxS (talk) 12:55, 6 June 2017 (UTC)
Agree with you @RexxS:, not with Nikkimaria. At present also editors discuss and decide on reliability of source of each article on Wikipedia, same can continue in Wikidata. This will help in improving reliability of not just English Wikipedia, but data across language barriers. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:02, 7 June 2017 (UTC)
That only works if Wikidata and English Wikipedia have the same standards/consensus regarding what is and is not a reliable source. Nikkimaria (talk) 03:11, 7 June 2017 (UTC)
Please share examples where you faced issues in arriving at consensus due to difference between policies of the two wikis. Have you even tried? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:17, 7 June 2017 (UTC)
Yep. Have you? Are you aware of discussions there regarding eg. sourcing of items about living people? Nikkimaria (talk) 03:23, 7 June 2017 (UTC)

See my Wikidata history, so far I haven't found any conflict on Wikidata. One more interesting thing, you might not be aware of, the quantum of vandals and IPS are much lesser on Wikidata as compared to English Wikipedia. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:37, 7 June 2017 (UTC)

And the quantum of vandalfighters as well - see this discussion. Both projects have their challenges. Nikkimaria (talk) 03:44, 7 June 2017 (UTC)

Years active

Why should it not be fetched when sourced? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 18:44, 6 June 2017 (UTC)

You yourself have only just raised concerns about this parameter at the main person infobox. Nikkimaria (talk) 22:55, 6 June 2017 (UTC)
Perhaps a better approach here would be to ask @Nikkimaria: What are the uncontroversial parameters that we can enable here? Thanks. Mike Peel (talk) 23:36, 6 June 2017 (UTC)
We've already implemented most of the other parameters considered "basic" for {{infobox person}}. This particular one though, the OP himself expressed concerns about only yesterday, so why on earth does he want to implement it today with those so far unanswered? Nikkimaria (talk) 00:28, 7 June 2017 (UTC)
Please read the concerns raised in toto, not by cherry-picking. I wrote "I guess this should either be sourced appropriately or not used at all". In this infobox it will appear only when sourced due to |onlysourced= being set to "yes" by default. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:58, 7 June 2017 (UTC)
You cherry-pick yourself by quoting your final sentence, but not the questions you raised about defining the meaning of the parameter nor the point about support in the article text. I don't understand why you felt these were valid questions yesterday but not today. Nikkimaria (talk) 03:15, 7 June 2017 (UTC)

Why shoulder not disclose years active for Shreyas Talpade, Kriti Sanon, Amitabh Bachchan, Abhishek Bachchan or any other actor, when it was/is being displayed when using {{Infobox person}}. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:45, 7 June 2017 (UTC)

Why do you suddenly feel your own concerns about doing so are no longer valid? Nikkimaria (talk) 03:48, 7 June 2017 (UTC)
If you haven't read it, my concern was appropriate sourcing. How have I changed my stance? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:50, 7 June 2017 (UTC)
If you don't recall, what you wrote was What does this signify? How is it determined? I don't see any content in article supporting the data mentioned in this param nor any source. I guess this should either be sourced appropriately or not used at all. How has the definition of the parameter changed since yesterday? How is it now clear what it signifies or doesn't, how it is determined, how it relates to article text? And per above, how are you getting "appropriate" sourcing? Nikkimaria (talk) 04:01, 7 June 2017 (UTC)

Height

What about height? I think it will be mostly sourced for actors and models only. Hence, it should be fetched, untill suppressed, when sourced. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 18:41, 6 June 2017 (UTC)

For most people it is irrelevant. Nikkimaria (talk) 22:53, 6 June 2017 (UTC)
From your comments, it seems everything besides name and image is irrelevant. Are you suggesting replacing infobox with File/image? It would be better if you can list the params, you don have problem with, since you seem to have problem with every param. I hope you are not suggesting getting rid of "Module:Infobox" since everything it includes, be it parents, height, death cause, etc are irrelevant for every page according to you. Maybe his/her name is irrelavant too, right? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:51, 7 June 2017 (UTC)
You might try reading what I've said rather than making silly overgeneralizations. The parameters you've proposed are generally trivial or otherwise inappropriate - that does not mean that all parameters are so, but it does mean you should take the time to read through previous discussions, consider the value of your proposed additions, and actually present a coherent argument in their favour. Nikkimaria (talk) 03:20, 7 June 2017 (UTC)
How are parents of Abhishek Bachchan or Ranbir Kapoor inappropriate in infobox? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:39, 7 June 2017 (UTC)
How is height of Urvashi Rautela, Kriti Sanon or any other person in modelling industry inappropriate? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:42, 7 June 2017 (UTC)
There's nothing preventing you or anyone else from adding the parameter locally, when appropriate. But the use of this template is not limited to people in the modelling industry, or those whose parents are notable. Nikkimaria (talk) 03:47, 7 June 2017 (UTC)
I have given examples of where it need to be fetched. You need to give examples of cases where it "must" not be fetched and you can't suppress fetching once the proposed params are added. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:52, 7 June 2017 (UTC)
It doesn't need to be fetched in those cases; it shouldn't be fetched in most cases. Nikkimaria (talk) 04:02, 7 June 2017 (UTC)

Image

Moving on, could someone explain how I fetch image captions using Module:WikidataIB? The best I have got so far is {{#invoke:WikidataIB |getQualifierValue |P18 |pval=? |qual=P2096}}. What am I supposed to supply for |pval=? Laurdecl talk 09:20, 6 June 2017 (UTC)

@Laurdecl: Ah, sorry - I haven't found time to re-write that call from Module:Wikidata yet. You can use something like: {{#invoke:Wikidata |getImageLegend | <PARAMETER> | lang=<ISO-639code> |id=<QID>}}. It's used in Template:Infobox telescope, and as an example the caption used in South Pole Telescope (d:Q1513315) can be fetched like this:
  • {{#invoke:Wikidata |getImageLegend |FETCH_WIKIDATA}} → The South Pole Telescope in November 2009
or (if you prefer it in Lithuanian):
  • {{#invoke:Wikidata |getImageLegend |FETCH_WIKIDATA |lang=lt}} → Pietų ašigalio teleskopas 2009 m. lapkritį
It deals with the language of the monolingual text by default by checking which wiki it is being used on (see lt:Pietų ašigalio teleskopas, which uses the same call, for example). You can't use getQualifierValue because I wrote that to cope with multiple acceptable values of the property (like people with multiple spouses), so it needs to know which of the multiple values to pick in order to retrieve the corresponding qualifier (like date of marriage). I really need to copy the functionality of getImageLegend into Module:WikidataIB, and perhaps add a crude 'getSingleQualifierValue' for the cases where we can sensibly assume that there will be only one value for a given property so we can fetch a qualifier without having to know the value of the property beforehand. --RexxS (talk) 13:30, 6 June 2017 (UTC)
Yes, it uses Module:Wikidata at the moment. I was trying to transition it to WikidataIB so there's no need to maintain two modules (for infobox use) which perform very similar tasks. Also, the pen icon is a bonus. We just need a way to select the image; I tried using the filename instead of a Q value, but it obviously didn't work. Cheers, Laurdecl talk 08:38, 7 June 2017 (UTC)
@Laurdecl: The current code does not appear to allow suppression of the caption; please correct this. Nikkimaria (talk) 01:51, 8 June 2017 (UTC)
@Nikkimaria: In case you haven't read anything in this section, that's what we're trying to do. Laurdecl talk 08:38, 8 June 2017 (UTC)
Until I find time to write a version of getImageLegend for Module:WikidataIB, you could always check whether suppressfields contains the word "caption":
{{#iferror:{{#invoke:String |match |List of Suppressed Fields |caption}} |{{#invoke:Wikidata |getImageLegend |FETCH_WIKIDATA |id=Q1513315}} | }} → The South Pole Telescope in November 2009
{{#iferror:{{#invoke:String |match | |caption}} |{{#invoke:Wikidata |getImageLegend |FETCH_WIKIDATA |id=Q1513315}} | }} → The South Pole Telescope in November 2009
{{#iferror:{{#invoke:String |match |List of Suppressed Fields has caption in the list |caption}} |{{#invoke:Wikidata |getImageLegend |FETCH_WIKIDATA |id=Q1513315}} | }} →
Obviously, you pass the suppressed fields list in the {{{suppressfields|}}} parameter. The technique should work for anywhere that we still have to use Module:Wikidata. Does that help for now? --RexxS (talk) 15:17, 8 June 2017 (UTC)

This is insane

What is the problem in fetching "sourced" signature, father and mother? Why have they been removed? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:47, 6 June 2017 (UTC)

If nothing is to be fetched, get rid of this infobox. What is the use, if editor has to add everything here itself. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:48, 6 June 2017 (UTC)
Indeed, this is insane - you're proposing and/or adding things seemingly at random. If you'd like to get rid of the template, the proper venue for that is thataway. If you'd like to suggest parameters to be fetched, make a decent argument for them, taking into consideration their utility and our practices. For example, the documentation for the main Person infobox suggests that |mother=/|father=/|parents= should be included "only if they are independently notable or particularly relevant"; automatically fetching them, whether sourced or not, would not account for that. Nikkimaria (talk) 03:30, 6 June 2017 (UTC)
Why do you want to put |father= and |mother= in by default? It's not usually a defining characteristic about the person or something someone would want to know at a glance, which is the point of infoboxes. This template is supposed to duplicate the normal person infobox, but fetch from Wikidata.
Obviously we should fetch |signature= from Wikidata (if that's possible), as it is commonly used in biographies. I don't see that code ever existing, so I'm not sure what you mean by removed? Laurdecl talk 07:43, 6 June 2017 (UTC)
@Capankajsmilyo and @RexxS: I've added signature fetching from Wikidata. Feel free to revert if there's any errors. Examples are on the doc page and [2]. Laurdecl talk 08:32, 6 June 2017 (UTC)
@Laurdecl: thanks -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:42, 6 June 2017 (UTC)
@RexxS: Shouldn't the [edit on Wikidata] link be disabled by default, if the pen icons show (opt-in, not opt-out)? This should be done at Template:EditOnWikidata not at the infobox where it is transcluded, otherwise we have to update every infobox using it with the logic. Template:Infobox telescope has both it, and the pen icons. Laurdecl talk 11:20, 7 June 2017 (UTC)
@Laurdecl: The display of the pen icons is governed by the |noicon= parameter. Opt-in vs opt-out is a completely different debate (about whether to fetch Wikidata is enabled or disabled by default). People commented that if we had the pen icon, we didn't need the [edit at Wikidata] link. The Template:EditOnWikidata is used in other places, so we can't alter its default. Therefore, I amended Template:EditOnWikidata so that it could be turned-off by supplying |noicon=false. That gives infobox designers the flexibility to allow editors at the article level to have either the pen icon or the [edit at Wikidata] link; or they could code the infobox to always display one of them; or neither; and the default for when the |noicon= parameter is not supplied at the article level is similarly programmable. I don't see any good reason to reduce the flexibility offered to infobox designers. In the case of Template:Infobox telescope, Mike, the designer, has chosen to always display the [edit at Wikidata] link (see the 'below =' line in that template and compare it with the corresponding line here – thank you for changing it to 'below =', by the way). On this template, there were complaints about "clutter", so I set it to display either the link or the pen icon, depending on the state of |noicon=, but not both. I'm not sure why you would want to alter that logic. --RexxS (talk) 12:44, 7 June 2017 (UTC)
@RexxS: I mean opt-in/out for Template:EditOnWikidata (I'm confusing myself now). You say we can't alter its default, but that's what I meant. I'm trying to say it should be disabled by default (so writing {{EditOnWikidata}} produces nothing), since the pen icons are enabled by default. That's what I mean by opt-in – one would have no supply |noicon=true for it to appear. Laurdecl talk 12:50, 7 June 2017 (UTC)

Parents

If we want to add Wikidata infobox on pages like Amitabh Bachchan, we should have an option to fetch |mother= and |father= from Wikidata. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 04:29, 10 June 2017 (UTC)

Using Wikidata label as infobox title

Currently the infobox uses {{PAGENAMEBASE}} as the title. I suggest we use getLabel. This way, supplying a QID would be all that is needed for a correct infobox. The documentation page examples have to manually set |name=. There is a common practice of putting biographical infoboxes in an article not about the person. For example, some articles about crimes have a section about the attacker. At the moment, doing that with this template would set the title as the page name. Of course, we would fall back to the page name if the label is missing or invalid. Laurdecl talk 08:18, 7 June 2017 (UTC)

There is some code to do this already at {{Infobox telescope}} - although I wasn't using getLabel there. Since this is something that will be useful in all infobox templates in the long run, perhaps it would be worth doing this as a subtemplate. Thanks. Mike Peel (talk) 13:09, 7 June 2017 (UTC)
@Mike Peel: A subtemplate? AFAIK the code would be: | above = {{#if:{{{name|}}}|{{{name}}}|{{#invoke:WikidataIB |getLabel |{{{qid|}}} }}}}. Laurdecl talk 08:50, 8 June 2017 (UTC)
@Laurdecl: Ideally a check that a label has been set would be a good thing to include, and fallback to {{PAGENAMEBASE}} if not. Thanks. Mike Peel (talk) 23:44, 8 June 2017 (UTC)
@Mike Peel: | above = {{If empty|{{{name|}}}|{{#invoke:WikidataIB |getLabel |{{{qid|}}} }}|{{PAGENAMEBASE}}}}. Laurdecl talk 07:02, 10 June 2017 (UTC)

Reason for revert

Why is my addition of P509 being reverted again and again? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:42, 5 June 2017 (UTC)

@Capankajsmilyo: First off, you don't yet have consensus for that change, which means it stays out until you do - you should not be edit-warring to keep it in once it's been reverted. Second, the change itself is not an improvement - that parameter is low-value and should not be used indiscriminately. If you look at the documentation for the main Template:Infobox person, you will note a requirement that the parameter be clearly defined and sourced. Please revert your edit. Nikkimaria (talk) 03:46, 5 June 2017 (UTC)
In case you are not aware, the parameter is fetched only when it is sources. Further, Wikidata does not accept ambiguous data. It allows only clearly defined data (Wikidata item) to be added. In case, you have any issues, you can raise them here, preferably with examples. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 04:02, 5 June 2017 (UTC)
Wikidata accepts values that discussions on this project have considered ambiguous, such as "natural causes". And again: please revert your edit. Nikkimaria (talk) 04:05, 5 June 2017 (UTC)
That value need to be sourced to be reflected on Enwiki, which doesn't seem to be a likely case. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 05:09, 5 June 2017 (UTC)
You really don't know that. This parameter should provide value to be included by default, which doesn't seem a likely case. You have yet to present any argument in favour of including it. Nikkimaria (talk) 12:00, 5 June 2017 (UTC)

I think that both sides here have valid points. In terms of including the information available from any property available on Wikidata, I suggest that the presumption should be that it is valid to do so in a Wikidata-aware infobox that that is opt-in and which only fetches sourced values by default. In terms of cause of death (P509) specifically, Nikki raises an interesting point: are some properties of such intrinsically low value that they ought not be fetched from Wikidata even if sourced and used only in an opt-in infobox? I suspect that we need more opinions and perhaps some examples from non-enabled infoboxes of where this parameter is used and where it is deliberately suppressed (if that decision is documented). Hopefully some concrete examples will help us reach a consensus on the issue of some data never being fetched from Wikidata. --RexxS (talk) 13:39, 5 June 2017 (UTC)

Thanks RexxS, Eg. is Mahatma Gandhi. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 13:54, 5 June 2017 (UTC)
@RexxS: I don't think that's a valid presumption. To give a deliberately obvious example, it is almost always sourced on Wikidata that a person is a human, and it will almost never be valuable to pass that through. More broadly, decisions about what should and shouldn't be passed through should be based on local practices rather than simply what is available. Good examples of this are religion and ethnicity, which by consensus on this wiki we generally do not include. @Capankajsmilyo: You raise another problem: your example uses a (presumably consensus-based) value for cause of death that is actually not reflected in the Wikidata item for Gandhi; the closest thing there is "homicide" as manner of death. In other words, Wikidata actually has two different properties (cause and manner of death) which we have generally combined into a single parameter here. Nikkimaria (talk) 00:31, 6 June 2017 (UTC)
Here are some links to previous discussions regarding the use of a cause of death parameter: Cause of death vandal, person 2015, writer 2010, military person 2013, MLB player 2011, writer 2009. I'm going to revert the parameter for now pending further discussion here. Nikkimaria (talk) 00:50, 6 June 2017 (UTC)
This is {{Infobox person}}. As of now, wikipedia has separate infoboxes for writers, military person and sportspersons. So all of those disussions, except Person, doesn't directly apply here. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:45, 6 June 2017 (UTC)
All of those discussions demonstrate opinions about use of the parameter in biographical infoboxes - largely negative opinions. Where are your counterarguments to those? Do you have evidence of support for automatic fetching of this information, or even for non-automatic widespread use? Do you have responses to the concerns raised above? Nikkimaria (talk) 03:30, 6 June 2017 (UTC)
  • What about a compromise? This parameter seems somewhat common to me from a quick glance at some articles, and I do think it has some value. Instead of giving it its own field, let's add it below the death date. For example, Nikola Tesla currently looks like this:
Died7 January 1943 (aged 86)
New York City, New York, United States
Cause of deathCoronary thrombosis
That would become:
Died7 January 1943 (aged 86)
New York City, New York, United States
Coronary thrombosis
Also, manner and cause of death are obviously separate. One discussion gave suicide (as manner) and asphyxia (as cause) as examples. Thanks, Laurdecl talk 08:01, 6 June 2017 (UTC)
No. While this improves the aesthetics, that's a relatively minor concern in this discussion. Nikkimaria (talk) 10:56, 6 June 2017 (UTC)
I think I'll defend my presumption, Nikkimaria. Nobody is suggesting that every property on Wikidata should be reflected in a Wikipedia infobox – in biographies we don't normally have entries for gender, species, lifestyle, or any number of classifications that are primarily used for housekeeping on Wikidata. So I think the "instance of human" is a bit of a straw-man, wouldn't you agree? What I'm really concerned about are the fields that exist regularly in our Wikipedia-only infoboxes that can be directly mapped to a Wikidata property. For the most part those fields are accepted when containing local values unless there's a reason not to. And that's the presumption that I think should apply to Wikidata-aware infoboxes. In other words, we should not be preemptively disabling Wikidata from particular fields before we've had the discussion. I do think you're right that some fields should not be automatically fetched from Wikidata, and I disabled country of citizenship (P27) because of the obvious strength of argument that it's just too complicated a topic to be auto-included. It may be that cause of death (P509) is in the same category, but I do feel that the default should be to fetch fields for which there is no consensus to disable, and that the burden of evidence should fall on whoever is arguing that a given infobox field with a direct mapping to Wikidata should never be fetched. I do understand that other may disagree with that stance, but I guess it's another question we need to find consensus on. In any event, whatever state this infobox is in, I hope that both parties won't edit-war to try to decide the issue. Please let's have a sensible debate here instead. --RexxS (talk) 12:47, 6 June 2017 (UTC)
I did say that was a deliberately obvious example ;-)
But I do want to avoid assuming that every parameter that exists in a biographical infobox should be fetched by default. Many of them are rarely used, or have some constraints on their use, or for some classes of people provide minimal value - issues that have been frequently discussed prior to the creation of this template - and the OP seems to be disregarding these issues in his multitude of proposals. There is also the issue of "directly mapped" - as noted above, what we have called "cause of death" on this wiki actually maps to two properties on Wikidata, there called "cause of death" and "manner of death". That's probably not a good thing, but it is a well-established one not easily disregarded. Nikkimaria (talk) 23:02, 6 June 2017 (UTC)

I tested a possible implementation of death cause that isn't garish. On Marcel Achard the infobox looked like this:

Marcel Achard
Born5 July 1899
Sainte-Foy-lès-Lyon
Died4 September 1974 (aged 75)
From diabetes mellitus
Paris
OccupationPlaywright

Death cause is common in infoboxes as is, and the purpose of this template is to replicate the standard one. This isn't the place to discuss removing parameters. Nikkimaria, if you don't like cause of death as a parameter, you should start an RfC at Template:Infobox person. Until then, consensus is that cause of death should be included. Laurdecl talk 08:08, 7 June 2017 (UTC)

No, it's not. Consensus is that cause of death should be available, and it is - anyone can add it locally if they feel it's appropriate. But discussions around the use of this parameter have demonstrated a belief among many editors that it shouldn't be used by default. Even if we assume every instance of the string "cause of death" on Wikipedia appears in an instance of infobox person, only about 2% of transclusions use it - and in reality that number is smaller. I've also pointed out a discrepancy between how enwiki and Wikidata have interpreted cause vs manner of death, which has yet to be addressed - there is a not insignificant chunk of instances using things like "homicide" as cause of death. Nikkimaria (talk) 10:47, 7 June 2017 (UTC)
Where did you get that 2% statistic from? If editors want to disable it, that's what suppressfields is for. I don't see what the problem re manner vs cause is. As I said above, take suicide by hanging. The manner is suicide but the cause is asphyxia. So? Laurdecl talk 11:26, 7 June 2017 (UTC)
I'll take your assertion with a huge grain of salt. I looked at the articles for five US presidents, to see if cause of death was included:
So not 2% then? More like 75%. Laurdecl talk 11:33, 7 June 2017 (UTC)
If you're wanting to replicate {{infobox person}}, why choose five articles that don't use it? The template page states it is used on 700,000 pages; there are 15165 instances of the string "cause of death" in mainspace; even we assume every single one of those is used in an instance of infobox person - and many are not - we get 2% usage. Using the stats from this tool for infobox person and its wrappers we get 5% usage. Heck, even disregarding the wrappers and using only the main person template, we still get only 6% - and as you've demonstrated, many instances of "cause of death" will be in templates other than this one, while many others will simply be in the article text, so even that is generous. Given these stats, it makes more sense to exclude by default and allow editors to include it when they feel it's appropriate, than to include by default and force editors to exclude it. Nikkimaria (talk) 01:01, 8 June 2017 (UTC)
The number of biographies that even have this parameter on Wikidata is incredibly tiny, and the number that have this both on Wikidata and sourced is even smaller. The version I wrote doesn't even use an extra label, so it's barely even noticeable. Again, if you don't think this parameter is worthwhile, then you should raise it at Template:Infobox person. If there is sourced data that is useful it is silly to not use it. Both I and Capankajsmilyo think it should be there, and the only person saying it shouldn't wants this template deleted anyway. In the rare case someone finds one extra line invasive, they can suppress it. I have added it so you can judge for yourself whether it is clutter, assuming you can find more than one article that it makes a difference to. Laurdecl talk 09:09, 8 June 2017 (UTC)
And I have reverted it. Previous discussions around this parameter in biographical infoboxes indicate that far more people than just me think it is often clutter. I'm not advocating removing the parameter entirely - people can still add it manually if they choose to. But you have not shown that it should be fetched by default. It may be rare that it would be fetched, but it is also rare that people want it included. Nikkimaria (talk) 11:45, 8 June 2017 (UTC)

Straw poll

Since Nikkimaria is determined to not use Wikidata in a Wikidata infobox, I am asking for others' opinions. Please indicate whether you think this is worthwhile:

Marcel Achard
Born5 July 1899
Sainte-Foy-lès-Lyon
Died4 September 1974 (aged 75)
From diabetes mellitus
Paris
OccupationPlaywright

Trying to compromise, I have made it a single non-invasive line. Cause of death is practically only ever defined on Wikidata in notable circumstances, and it must be sourced to appear as well. This is a good use of Wikidata in a succinct form. As always, the parameter can be suppressed. Pinging Capankajsmilyo, RexxS, Mike Peel. Laurdecl talk 06:13, 9 June 2017 (UTC)

Further, since Nikki is already in violation of three revert rule, I guess this attracts warning and further proceedings. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 14:55, 9 June 2017 (UTC)
  • No. For starters, nothing in the infobox is required to be included in any biography – every part of the infobox, and the infobox itself, are all subject to local consensus in each biography article. It has always been my stance that an infobox parameter should not be utilized unless the information is important to the topic. Regarding the cause of death parameter: Somebody dying of old age is never important to the topic (well maybe if they are famous solely for being a supercentenarian), and somebody dying of natural causes is rarely important to the topic. I would not like to see this parameter made into a default that must be explicitly removed. Let's not fall into the trap of homogeneity, the idea that each biography must have the same presentation. Binksternet (talk) 14:59, 9 June 2017 (UTC)
That's why I said "Cause of death is practically only ever defined on Wikidata in notable circumstances, and it must be sourced to appear as well." There are extremely few Wikidata items that actually define this parameter, and practically none that source it. It is only ever really used where the cause of death is notable. Laurdecl talk 22:06, 9 June 2017 (UTC)
Do you have evidence of this? Nikkimaria (talk) 00:05, 10 June 2017 (UTC)
Yes. Look at the average item for a dead person. No cause of death. Laurdecl talk 01:02, 10 June 2017 (UTC)
Well, if we go by your "pick five examples and assume they're representative" methodology from above...Douglas Adams (Q42) does, Jane Austen (Q36322) does, Mark Twain (Q7245) does, T. S. Eliot (Q37767) does, J. R. R. Tolkien (Q892) does not. So per your math above that's...more like 75%, right? Nikkimaria (talk) 01:38, 10 June 2017 (UTC)
Hehe. Yes, you have demonstrated cherry picking very nicely. Those are very famous people with well-kept items, and documented causes of death. Try using Special:Random, and see the quality you get. Laurdecl talk 01:46, 10 June 2017 (UTC)
Pot, kettle. Are you suggesting this template will never be used for famous people? And it's not just famous people who have documented causes of death. Nikkimaria (talk) 02:03, 10 June 2017 (UTC)
I doubt it will be used anywhere once you're done with it. Anyway, only 1 (!) of your cherry-picked examples would actually show cause of death, and that is Douglas Adams. The others are unreferenced, and would not be fetched, like I said. So you have inadvertently proved my point. Laurdecl talk 02:23, 10 June 2017 (UTC)
That picking five random examples is a poor methodology? Removing the ability to add parameters manually or suppress unwanted parameters is far more likely to reduce usage of the template than not automatically fetching a parameter we usually don't want to fetch. Nikkimaria (talk) 02:44, 10 June 2017 (UTC)
  • My personal view is yes (reminding readers that not everyone dies of terrorism is good. ;-) ). However, I think this discussion is more about whether or not cause of death should be shown in the infobox - which is a wider topic that should be at Template talk:Infobox person - not whether we should draw that cause of death from Wikidata. So I'd like to suggest an alternative: we have an optional Wikidata parameter. We can do this relatively straightforwardly (something like {{#ifeq:{{{wddeath|no}}}|yes[wikidata code here>}}) - or if @RexxS: could do something like the suppression code but for inclusion. It's not something we should do by default (since having lots of parameter calls to show the infobox makes that code very messy again, and it's turning the code into a double-opt-in), but for specific cases maybe it would be a good approach to take. Thought? Thanks. Mike Peel (talk) 23:09, 9 June 2017 (UTC)
I see where you're coming from, and I thought about the same thing. I think that if someone specifies fetchwikidata=ALL, they mean fetch everything from Wikidata, not fetch everything but one parameter. Of course, this shouldn't be displayed in every infobox, and in practice it won't be. Having both cause of death defined and sourced is very rare and only happens when the cause of death is extraordinary. While enabling this by default in theory makes it appear everywhere, in reality it only really appears in notable circumstances, where someone has bothered to define cause of death at Wikidata. Laurdecl talk 23:22, 9 June 2017 (UTC)
You know you can supply a list of fields to be included, instead of "ALL" to the |fetchwikidata= parameter? I guess if the number of fields gets big, it becomes unwieldy, but the option is always there to just supply the commonly used fields (suppressfields still takes precedence of course). --RexxS (talk) 00:02, 10 June 2017 (UTC)
That's what I'm saying...? ALL means all – cause of death as well, not just parameters Nikkimaria thinks are good. Laurdecl talk 01:02, 10 June 2017 (UTC)
@Laurdecl and RexxS: I'm suggesting an approach of "these are the basics, always fetch these from Wikidata", combined with an extra layer of "also, these are important in this specific case, please also fetch these from Wikidata", as opposed to "please fetch everything from Wikidata except for these things". I don't like this, as I'd prefer an approach of "let's fetch everything that's relevant from Wikidata" that could then be displayed in the infobox. However, I can't see that being acceptable to people like @Nikkimaria. So I'm trying to suggest a compromise approach that could work in this situation, combined with the flexibility for this to work in other situations, so that we can still say "let's create this infobox using Wikidata" while also saying "except these statements are controversial, so we should allow for nuances here". Thanks. Mike Peel (talk) 02:13, 10 June 2017 (UTC)
So fetch them only when they are specifically called by name, not as part of the =all? That could work. At the moment it looks like Laurdecl has disabled even manual adding of the parameter. Nikkimaria (talk) 02:22, 10 June 2017 (UTC)
@Nikkimaria: No, read what I said again. I'm suggesting "BASIC plus THESE", which is different from "ALL", "ALL minus THESE", and "NONE plus THESE". It's also different from "BASIC plus NOTHING" or "NOTHING AT ALL". I'm trying to find the middle ground where we can have a useful infobox that includes the relevant information from Wikidata, while not including too much Wikidata information that isn't welcome here. Thanks. Mike Peel (talk) 02:44, 10 June 2017 (UTC)
...That actually makes things more confusing. What would you anticipate the template code looking like in each of the cases you describe? Nikkimaria (talk) 02:46, 10 June 2017 (UTC)
I'm sorry Mike, but this is just ridiculous. You want to hardcode a list of properties that are "basic" into Module:WikidataIB to appease one person? I've already tried to compromise by putting this in the death field, not even giving it its own label. The world is not enough for these people. Did setting |onlysourced=yes by default stop them complaining about unsourced information? No, it gave them good screenshots of empty infoboxes to use at TfD. I suspect we'll be back there again within the week. |fetchwikidata=ALL should fetch everything from Wikidata, hence the "ALL". At least Fram had the decency to stop after losing two TfDs, instead of staying around for the sole purpose of reverting others to make this inbox worse, and continuing to remove it from articles. Thanks, Laurdecl talk 08:42, 10 June 2017 (UTC)
You might want to step back and take a breath. Just because "these people" disagree that proposed changes are improvements, or check how changes impact articles, doesn't mean they're here for the sole purpose of making this "inbox" worse. The largest decline in the number of transclusions was because Fram deleted a number of sock-created articles that used it. And as I said above, removing functionality - making parameters that can't be suppressed or preventing parameters from being manually added - decreases the usability of the template far more than limiting which are automatically fetched. Nikkimaria (talk) 14:00, 10 June 2017 (UTC)
  • Neutral: I agree this really seems to be a debate about whether CoD should be included, and it really has little to do with wikidata. I agree CoD, of the sorts where WikiData will have that info, is encyclopedic information, but I don't detect consensus about whether it should or should not be in the infobox.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:42, 19 June 2017 (UTC)

Capitalisation bug, Module:String2

The occupation section of the infobox here is incorrectly capitalised. The problem is solved when |sort= is true. Any guesses? Laurdecl talk 07:00, 10 June 2017 (UTC)

Yup. Linguist is a redirect, so doesn't have piped text, while all the others do. Module:String2 looks for a pipe character if the fragment starts with a link.
  • {{#invoke:String2 | sentence | linguist, professor, historian}} → Linguist, professor, historian
  • {{#invoke:String2 | sentence | [[linguist]], [[professor]], [[historian]]}} → Linguist, professor, historian
  • {{#invoke:String2 | sentence | [[linguist]], [[professor|professor]], [[historian|historian]]}} → Linguist, professor, historian
I'll have to modify Module:String2. I'll have a look tomorrow. --RexxS (talk) 23:47, 2 July 2017 (UTC)

Year of birth bug

The infobox can not figure out if there is more than one birth date. Its only takes one of them. Christian75 (talk) 21:49, 2 July 2017 (UTC)

That's because there is code in the template to calculate age, either currently or at death. If there were more than one birth date, that could not work. As most people are only born once, I feel that the functionality of calculating age is more useful than giving two or more birth dates in an infobox. In those cases, it's probably better not to include dob in the infobox (or use a locally supplied value, if you must), but to explain why the subject had multiple birthdays somewhere in the text. Similarly for date of death. YMMV. --RexxS (talk) 23:32, 2 July 2017 (UTC)
We have a lot of article where different sources gives different date or year of birth (oftentimes, because the reference says the person was x years in year y). Right now, this infobox is broken and choice one of them arbitrary, and ignore the other. Christian75 (talk) 00:28, 3 July 2017 (UTC)
What's broken? Give me an example. If a person has multiple dates of birth, leave them out of the infobox and use a section in the article to explain that we don't know the date of birth. That's how we've always dealt with any contentious or ambiguous information in infoboxes. Surely that's not difficult to comprehend? --RexxS (talk) 00:36, 3 July 2017 (UTC)
No we have not dealt with it that way. There is not much to explain. It obvious if the infobox says "1986 or 1987" that we do not know exactly the year of birth. Thats doesn't need a section to explain that. Here are a few examples CocknBullKid, Marko Cheseto, and Class Actress. I have seen examples with more sources for different years, but didn't write the name of the articles down. I bring it up because it was my impression that Wikidata infoboxes should replace ordinary boxes, and if it cant deal with more than one year of birth we will end up with infoboxes where half of the data are loaceted at Wikidata and the other half at enwiki. And thats confusing for editors, IMHO. Christian75 (talk) 01:00, 3 July 2017 (UTC)
Yes we have dealt with it that way. Infoboxes are not the places to deal with anything other than simple facts. If equally reliable sources disagree about the date of birth, then we attribute and report both: that's basic WP:Neutral point of view. There's no space in an infobox to deal with attribution, so it needs to be done in the body text.
CocknBullKid has a single date of birth (P569) at CocknBullKid (Q5139642) which is completely unsourced. Do you want the infobox to fetch that from Wikidata:
Born: 1985 Edit this on Wikidata
Do you think the editors of that article are going to accept an unsourced value, rather than the referenced information that they have now:
Born: (1985 or 1986 (age 38–39))?
Wikidata-aware infoboxes are strongly opposed by several editors, as are infoboxes themselves, so why give them more ammunition by changing useful locally-supplied values to inaccurate and unsourced ones from Wikidata? Marko Cheseto (Q6771130) has no date of birth (P569) in their Wikidata entry, nor does Class Actress (Q5127971). What do you want this template to do, given that there is no information to fetch?
Fetching information from Wikidata is a good thing most of the time, but wherever there is uncertain or ambiguous information, we have to be able to use an editor's discretion here on Wikipedia to override what is on Wikidata with a locally-supplied value, or nothing at all. Cases where there are multiple values for date of birth are a clear example of that. --RexxS (talk) 16:52, 3 July 2017 (UTC)

Bug: Import of caption when images is local

The template should not retrieve the wikidata image caption when we use a "local" image in the infobox. I.e. if the infobox has image=some_image.jpg but no caption= then the current infobox will get the caption from Wikidata which is wrong. Christian75 (talk) 01:03, 3 July 2017 (UTC)

I think Mike tried to fix it. I made a change to so local images gets captions (it was not included), and wikidata images only gets caption from wikidata (and captions can not be inserted locally). Reason: It gets messy to have local captions when images are changed on wikidata. But it will probably be messy anyway, because when you change an image on Wikidata it doesn't automatically delete the old captions. Christian75 (talk) 16:38, 9 July 2017 (UTC)

suggestion (pencil icons)

Would you consider removing the "edit" pencil icon after each item and instead add a link to the bottom of the infobox instead? I think the icons are distracting and you only need one link to Wikidata, since as soon as you edit one, you can scroll down and edit them all. The French version, which although it also has the pencil icons, has "edit Wikidata" at the bottom of the infobox (see this example). I really like this idea but I think people will be reluctant to use it instead of manual infoboxes bc of the aesthetics. Just an idea! —МандичкаYO 😜 13:08, 15 July 2017 (UTC)

@Wikimandia: You can set this at the article level - |noicon=on will display an edit link at the bottom of the box and remove the pencils. Nikkimaria (talk) 13:59, 15 July 2017 (UTC)
Oh fantastic - can I suggest someone add an example with no icons to the template, so people checking it out can readily see that's an option? Thank you. —МандичкаYO 😜 14:01, 15 July 2017 (UTC)
@Wikimandia: Done. Nikkimaria (talk) 14:16, 15 July 2017 (UTC)

Capitalization

Why are some values for a parameter capitalized and others not? See for example |occupation= at Charles Conrad Abbott. I've checked Wikidata and they seem to be displayed as lowercase. Nikkimaria (talk) 18:44, 22 July 2017 (UTC)

Occupation uses #invoke:String2|sentence to render the output from Wikidata in sentence case. Unfortunately, the values are linked, so the first character is actually '[', and although Module:String2 looks for a pipe character to attempt to find the displayed text, some of the occupations are redirects and therefore don't have pipe characters. I thought I had amended the code to add them, but I obviously didn't. I'll look at fixing String2 first chance I get. --RexxS (talk) 03:17, 23 July 2017 (UTC)

Muliple values as lists

The two awards, for example, on Essi Viding are comma-separated. How can we arrange for such values to be in a list, using {{Plainlist}} or equivalent ma!rkup? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:58, 25 July 2017 (UTC)

Module:WikidataIB allows its output to be automatically piped through {{hlist}} or {{ubl}} by setting the (as yet undocumented) parameter |list=hlist or |list=ubl. See Module talk:WikidataIB #New parameters: sorted, sep and list.
  • {{#invoke:WikidataIB |getValue |P166 |name=awards |qid=Q15637656 |suppressfields={{{suppressfields|}}} |fetchwikidata=ALL |onlysourced={{{onlysourced|}}} |noicon={{{noicon|}}} |list= | {{{awards|}}} }}
    → Spearman Medal, Rosalind Franklin Award, Wiley Prize in Psychology Edit this on Wikidata
  • {{#invoke:WikidataIB |getValue |P166 |name=awards |qid=Q15637656 |suppressfields={{{suppressfields|}}} |fetchwikidata=ALL |onlysourced={{{onlysourced|}}} |noicon={{{noicon|}}} |hlist = | {{{awards|}}} }}
    →
  • {{#invoke:WikidataIB |getValue |P166 |name=awards |qid=Q15637656 |suppressfields={{{suppressfields|}}} |fetchwikidata=ALL |onlysourced={{{onlysourced|}}} |noicon={{{noicon|}}} |list=ubl | {{{awards|}}} }}
    →
That should do the trick for you. Either pick which one you want and add the parameter to the article, or get the infobox updated to use a fixed format for the awards in all articles where it is used. I've done a demo of the first option for you at Essi Viding. Feel free to revert my change or amend it to your wishes. Cheers --RexxS (talk) 16:54, 25 July 2017 (UTC)
@RexxS: Thank you, that's just the effect I wanted on Essi Viding. I would like to see "ubl" become the default presentation, though. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:32, 25 July 2017 (UTC)
That should be straightforward by setting the parameter in the infobox design to {{{list|ubl}}}, shouldn't it? It would still allow a per-article override because writing |list=none in an article infobox turns off passing the values to {{hlist}}/{{ubl}}. --RexxS (talk) 00:38, 26 July 2017 (UTC)

Template on cywiki

Hi all. I've copied the template to cywiki and it looks good other than a couple of glitches as you can see on the article on Lev Tolstoy. I can't work out how the months are called up or where the calculation of age is done (see red error). I'm also thinking of expanding this one so that it has two or three headers eg Personal information, education, work. Any help would be appreciated! Thanks! Llywelyn2000 (talk) 14:36, 13 July 2017 (UTC)

@Llywelyn2000: - This sanboxed version should fix it (see test cases), it strips the /Julian out of the raw value, and also fixes the the placement of |qid= param for {{wikidata}}. For ideas on the headers see the sanboxed version and testcases on Ilowiki. --Lam-ang (talk) 18:37, 15 July 2017 (UTC)
@Lam-ang: Many thanks for your suggestions. Birth, however, seems to cause an error. Feel free to experiment! Llywelyn2000 (talk) 08:05, 16 July 2017 (UTC)
@Llywelyn2000: Fixed with this edit. --Lam-ang (talk) 13:50, 16 July 2017 (UTC)
Whow! Many many thanks @Lam-ang:! Llywelyn2000 (talk) 08:18, 17 July 2017 (UTC)

@Lam-ang and RexxS: - Two things remain, which are the translations of month date and the word 'aged'; any ideas where these are kept please, so that they can be translated? Llywelyn2000 (talk) 11:24, 20 July 2017 (UTC)

@Llywelyn2000: Both are hard-coded - search for "(age " in cy:Nodyn:Infobox person/Wikidata and "["Months"]" in cy:Modiwl:WikidataIB. Thanks. Mike Peel (talk) 12:11, 20 July 2017 (UTC)
I tried the first one here, but the other changes might have been sticks in the spokes! Changed it now, on its own and it works a treat! Thanks Mike! Months - all done and works perfectly! Thanks for your help, once again! Llywelyn2000 (talk) 12:40, 20 July 2017 (UTC)

Another glitch with time ('Died') + cy:Aelhaearn ('Born'). Also happens on en-wiki. Llywelyn2000 (talk) 05:25, 27 July 2017 (UTC)

Values imported from Wikipedia that have a reference

If you use the infobox with onlysourced=yes (the default) it doesn't retrieve Wikidata values that are marked as "imported from Wikipedia", even if those values also have a reference. That doesn't seem like the intended behaviour? – Joe (talk) 06:54, 9 August 2017 (UTC)

That is the intended behaviour. Wikipedia is not a reliable source, and for the English Wikipedia "imported from Wikipedia" is not a reference in any meaningful sense of the word. So for Richard Burton (Q151973), the image statement is only sourced to "imported from Wikipedia":
  • {{#invoke:WikidataIB |getValue |P18 |fetchwikidata=ALL |qid=Q151973 |onlysourced=yes}} →
  • {{#invoke:WikidataIB |getValue |P18 |fetchwikidata=ALL |qid=Q151973 |onlysourced=yes}} → Richard Burton - The Robe.jpg Edit this on Wikidata
It should return Wikidata values where those values are also sourced to something that is not "imported from Wikipedia", for example, Richard Burton (Q151973) is an instance of a human and has two "references", one "imported from English Wikipedia" and the other is "http://data.bnf.fr/ark:/12148/cb13892004p" so the value is returned:
  • {{#invoke:WikidataIB |getValue |P31 |fetchwikidata=ALL |qid=Q151973 |onlysourced=yes}} → human Edit this on Wikidata
If you know of an article where that is not happening, please give an example. --RexxS (talk) 15:10, 9 August 2017 (UTC)
@RexxS: I think Joe is referring to Margarida Davina Andreatta (Q28028886). As a test, I've undone his edit there, and the date of death at Margarida Davina Andreatta (which was shown before the revert) is no longer shown. In this case there is both an "imported from" and a reference URL. Thanks. Mike Peel (talk) 15:43, 9 August 2017 (UTC)
Ah, @Joe Roe: this edit on Wikidata fixed it. The problem is that there was only one reference on Wikidata that had *both* imported from and the URL in it, rather than two separate ones. Thanks. Mike Peel (talk) 15:45, 9 August 2017 (UTC)
Aha, that makes sense, thanks. It looks like I introduced that error myself back in January. Oops! – Joe (talk) 15:53, 9 August 2017 (UTC)

Empty infoboxes

There is a need of a tracking category to group all articles with empty infoboxes, with no one field shown in article, just like at Sergiu Balan. In past I saw few more such articles. XXN, 06:47, 9 August 2017 (UTC)

This was due to the transition from onlysourced=no to onlysourced=yes by default. Ideally this shouldn't happen to new articles, and the easiest way to fix them when you see them is to add some references on Wikidata. ;-) Thanks. Mike Peel (talk) 16:08, 9 August 2017 (UTC)
Thanks, Mike. A tracking category would be helpful, then, to help identify articles whose Wikidata entries would benefit from more sourcing. --RexxS (talk) 16:27, 9 August 2017 (UTC)

Age issue

@Laurdecl and RexxS: There is an odd syntax bug with the age template in the infobox in this edit, please could you have a look? Thanks. Mike Peel (talk) 00:56, 11 October 2017 (UTC)

Not an isolated error - see also here. Nikkimaria (talk) 01:50, 11 October 2017 (UTC)
Actually, seems to be happening in just about every article that employs that age template. Suggest disabling that functionality for now, unless/until it can be sorted. Nikkimaria (talk) 02:00, 11 October 2017 (UTC)
Hmm, it seems to work now. The only change I can spot is [3] by @Pppery:, maybe that fixed it. Thanks. Mike Peel (talk) 10:16, 11 October 2017 (UTC)
@Mike Peel: As the error is now recurring with no subsequent changes to that page, the problem lies elsewhere. Nikkimaria (talk) 00:32, 12 October 2017 (UTC)
That's very wierd. :-/ I've disabled the code for now, will investigate more on the morrow. Thanks. Mike Peel (talk) 00:43, 12 October 2017 (UTC)
I did not get the above ping, but my change there seems like it could have easily fixed that bug. @Nikkimaria: Are you sure that the pages where it reoccurred didn't just need a purge? {{repeat|p|3}}ery (talk) 01:38, 12 October 2017 (UTC)
Wait a moment, the things that would have caused this are my edits to Module:Wd, where I made and corrected a few mistakes. Perhaps it works now? Module:Wikidata doesn't seem to be used by this code. Sidenote: The names of these three modules are too close to eachother, perhaps someone should start a requested move? {{repeat|p|3}}ery (talk) 01:41, 12 October 2017 (UTC)
(after ec) Yes, I tried that. At the time Mike said the issue was fixed it did appear to be, and the problem re-emerged later on the same articles, which is why I thought it must be caused by something unrelated to the change he pointed out. Nikkimaria (talk) 01:43, 12 October 2017 (UTC)
@Pppery: Ah, you're right, it's Module:Wd rather than Module:Wikidata. That explains why I couldn't find the edits that were changing things. :-) It looks like everything is workin again now, so I've re-enabled the code (@Nikkimaria: for awareness). Thanks. Mike Peel (talk) 17:53, 12 October 2017 (UTC)

Creating a wrapper using this template

Is it possible to use this template as a parent when creating a wrapper? For example the non wikidata Template:Infobox scientist is a wrapper of Template:Infobox person. I tried to make an analogous wikidata version of the scientist infobox at Template:Infobox scientist/Wikidata/sandbox, but the testcase isn't working?

D Wells (talk) 00:34, 30 November 2017 (UTC)

@D Wells: Nice start! You needed to pass through some Wikidata-specific parameters such as qid, I've added these and the test case should look a bit more complete now. :-) Thanks. Mike Peel (talk) 01:25, 1 December 2017 (UTC)
@Mike Peel: Awesome thanks!! D Wells (talk) 08:51, 2 December 2017 (UTC)

In Pierre-Roland Giot, this template is creating a spurious link to Order of the Ermine, which (1) is a DAB page and (2) does not mention the correct award, which is Ordre of the Ermine [fr] (only in French Wiki). The link isn't blue; but User:DPL bot picks it up from the DAB page. The problem is almost certainly caused by an #ifexist test buried deep within the code. {{Infobox journal}} does the same thing, but has a field which disables the problem; see Template talk:Infobox journal#Links to DAB pages. Is there a way of fixing this other than to rewrite the infobox in conventional format? Narky Blert (talk) 18:25, 13 January 2018 (UTC)

Is Order of the Ermine (France) not the correct page? Pierre-Roland Giot is listed as a recipient on that page. If so then you could link that wikipedia page to the wikidata entry which would at least make the link correct. Not sure about why it shows up in what links here in Order of the Ermine without being a blue-link. D Wells (talk) 18:56, 13 January 2018 (UTC)
So it turns out you can't do as I suggested because the Order of the Ermine (France) page is a mixture of the chivalric order and the award so only the wikidata item for the order (Q1059128) and not the award (Q17355430) is linked. D Wells (talk) —Preceding undated comment added 19:41, 13 January 2018 (UTC)
@D Wells and Narky Blert: Shouldn't that article be split in two, one on the original and one on the new award? Thanks. Mike Peel (talk) 20:22, 13 January 2018 (UTC)
@D Wells: I think Mike Peel is right - the article should be split. A 20th-century revival of an award which fell into disuse in 1524 isn't exactly the same thing; not least because the old order was chivalric, in the gift of a duke, and the new one is a distinction awarded by a pressure group. Breton Wiki also treats the two orders as one; it's only French Wiki which makes the distinction.
Another reason: recipients of the old and new awards look like prime possibilities for categories somewhere within Category:Awards, provided that there are enough of them; and the two groups should be separate.
I now think that the split-out article should be Order of the Ermine (modern), because the old French one also related to Brittany. I have modified existing redlinks (except for the one I posted in here) accordingly (see Michael Jones (historian)). Narky Blert (talk) 20:53, 13 January 2018 (UTC)
@Narky Blert: I've split the article accordingly, and reverted the infobox at Michael Jones (historian)]]. How does that look? Thanks. Mike Peel (talk) 07:28, 14 January 2018 (UTC)
@Mike Peel: it looks very good. I've added the split-out article to the DAB page. Yrs, Narky Blert (talk) 13:11, 14 January 2018 (UTC)

Sentence case for "Occupation" param

I see this template uses the String2 module so that the entries in the Occupation parameter comport with the MOS stipulation that the first entry in the list should start with a capital letter. This doesn't appear to be working, however; see, for example, the infobox at Florence Bascom.

(Update: I see this has been discussed before, twice. This is obviously something that's being worked on. My apologies for raising it as a new bug.)

Thanks. — Hugh (talk) 01:28, 23 February 2018 (UTC)

@Hugh: Thanks for reminding me. The problem is now caused because I updated Module:WikidataIB to output horizontal lists {{hlist}} and unbulleted lists {{ubl}} to improve accessibility.
I've now made a fix for Module:String2 so that the sentence function now recognises when it has an html list passed to it and capitalises the first alphabetic letter beyond the list markup (<li>) and any piped links that may be there. I haven't tested it extensively, but it seems to be working in Florence Bascom now. Please report any errors that may crop up. Cheers --RexxS (talk) 20:06, 23 February 2018 (UTC)

Caption help

I can't get the caption to appear using the infobox at Julia Evelina Smith. I've tried several different ways, including adding the caption to her Wikidata item. Can anyone figure out what i'm doing wrong? Gamaliel (talk) 21:10, 9 March 2018 (UTC)

Because Wikidata entries like Julia Evelina Smith (Q6306404) could have multiple images, it is necessary to associate each caption (i.e. media legend (P2096)) with the image it refers to by adding it as a qualifier of that image. If you have a look at her Wikidata entry, you should now be able to see how that is done. I think that fixes the problem, but ping me if you get further problems. Cheers --RexxS (talk) 23:15, 9 March 2018 (UTC)
RexxS Thank you! I was adding P2096 as a separate property and not as a qualifier, but obviously the latter makes more sense, as you explained. Gamaliel (talk) 04:20, 10 March 2018 (UTC)
RexxS Your solution[4] introduced an old bug which where solved with the "{{#if:{{{image|}}". The template should not fetch legend from Wikidata if the template is using a "local" image with image=. Christian75 (talk) 09:27, 10 March 2018 (UTC)
@Christian75: That may be so, but the code I changed:
  • {{#if:{{{image|}}}|{{{caption|}}}|{{#invoke:Wikidata|getImageLegend|FETCH_WIKIDATA}}}}
prevents the use of a locally supplied caption when the image is supplied from Wikidata. That's an absolute no-no, because the overriding principle here is that locally supplied values must always override whatever is present on Wikidata. I'll fix that now using:
  • {{#if:{{{image|}}} | {{{caption|}}} | {{#invoke:Wikidata |getImageLegend |{{{caption|FETCH_WIKIDATA}}} }} }}
Please let me know if you observe any problems. --RexxS (talk) 20:33, 10 March 2018 (UTC)

Two images

Jean Chamant has two images on Wikidata. This revision shows the Wikidata infobox trying to call both at the same time, with the result that neither appears. Is there a way to fix this other than by removing one at Wikidata? Nikkimaria (talk) 11:52, 23 March 2018 (UTC)

@RexxS: Could the maxnum parameter be enabled in Module:WikidataIB please? The sandbox code you wrote to do this works fine, so I think it just needs moving into the main version. That should then fix this issue. Thanks. Mike Peel (talk) 14:56, 23 March 2018 (UTC)
Sorry, as soon as I wrote that, I realised that the param was 'maxvals' which is supported. So @Nikkimaria: this should now be fixed. Thanks. Mike Peel (talk) 14:57, 23 March 2018 (UTC)

Stated as

The template needs to take account of object named as (P1932) qualifiers. For example, in this article the alma mater show as "University of Glamorgan" and "Birmingham City University", when they should be " Polytechnic of Wales" and "Birmingham Polytechnic" respectively. This can apply to several fields, not just alma mater. Can someone make this work, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:59, 15 March 2018 (UTC)

Because the functions used to fetch properties are used in internationalised applications, they are not intended for use with qualifiers such as object named as (P1932) which have a 'string' data-type (i.e. monolingual). There is always going to be a fundamental tension between directly quoting a source and supplying a readable word for multiple languages. It seems to me that the educated at (P69) for Pete James (Q50562391) ought to be "Polytechnic of Wales" and "Birmingham Polytechnic" if that's what you want to be seen in an infobox. Since "University of Glamorgan" no longer exists, just as "Polytechnic of Wales" doesn't, I don't understand why the former would be used in the entry for Pete James, as he wasn't educated at that university, and it's not the current name of the successor institution. --RexxS (talk) 17:45, 15 March 2018 (UTC)
"It seems to me that..." Yes, that's my point. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:26, 16 March 2018 (UTC)
It should be noted that object named as (P1932) qualifiers are used to show information stated in a reference and as such, the qualifier values can be intentionally erroneous to match the reference not unlike "sic" is used in prose text. I believe what we need here is a different monolinguage text qualifier (and of course an easy way to fetch such data). 2600:1700:EDB0:A060:14D0:1D18:969:4211 (talk) 11:15, 17 April 2018 (UTC)
Well, I can make it do this:
But it helps if we don't have IPs simply removing the qualifiers from Wikidata. --RexxS (talk) 13:31, 17 April 2018 (UTC)

Debugging

I tried using the {{infobox person/Wikidata|fetchwikidata=ALL}} template with Lee Ridley (comedian), but it stayed empty despite having links in both directions. Could we have debug tips/instructions?

@Back ache: The simplest debugging is to set |onlysourced=no, so that you can see the values that have been filtered out by default because they are unsourced. Try:
  • {{infobox person/Wikidata | fetchwikidata=ALL |onlysourced=no}}
That gives you date of birth and occupation, so you can see that the infobox is working. Beyond that, you need to follow the link to the Wikidata item, in this case Lee Ridley (Q20709483). As you can see on that page, there isn't much available on Wikidata to be fetched. At present this template can make use of the following properties:
  • P18
  • P119
  • P136
  • P2096
  • P1455
  • P1477
  • P569
  • P19
  • P570
  • P109
  • P856
  • P1581
  • P3373
  • P800
  • P69
  • P509
  • P1636
  • P20
  • P69
  • P106
  • P108
  • P26
  • P166
So if more of those were added (and referenced) on Wikidata, this infobox could supply more fields. Does that help? --RexxS (talk) 22:32, 25 April 2018 (UTC)

Unable to suppress website param

I'm unable to suppress the website at Juan Avilés Farré, if someone can please take a look czar 19:43, 29 April 2018 (UTC)

@Czar: The name of the field is given as 'url' in Template:Infobox person/Wikidata. I've used url for now in the article, but I wonder if Mike Peel agrees that 'website' would be a more intuitive name for the field when used in the blacklist? If so, one of us can amend the template. Cheers --RexxS (talk) 20:07, 29 April 2018 (UTC)
Thanks! Template:Infobox person/Wikidata mentions |website= but not |url= so might be useful to change one to the other for continuity & clarity. (not watching, please {{ping}}) czar 20:11, 29 April 2018 (UTC)
Yes, the parameter is |website= or |homepage=, and the label is Website, so I think that is most likely to be assumed as the name of the field to suppress. As Juan Avilés Farré is the only article where website is suppressed, I'll go ahead and amend Template:Infobox person/Wikidata to look for "website" as the name for the field when suppressing or fetching. I've also restored |suppressfields=website in the article. --RexxS (talk) 20:34, 29 April 2018 (UTC)
I just ran some code to double-check through the uses of the template, and there weren't any others using 'url', so I'm happy with this change. Thanks RexxS for sorting it out. Thanks. Mike Peel (talk) 21:18, 29 April 2018 (UTC)

Maintenance category

Angela Warnick Buchdahl is in Category:No local image but image on Wikidata. There is an image on Wikidata and it is being pulled into the infobox.MB 16:28, 19 May 2018 (UTC)

The logic for {{Wikidata image}} doesn't work when the image is pulled from Wikidata. However, there's no point in testing for an image on Wikidata when the article uses this template. Any image will already be imported, or locally overridden, or suppressed. In any of those cases, {{Wikidata image}} would have no useful function, so I've removed it from this template. Angela Warnick Buchdahl is no longer in Category:No local image but image on Wikidata. --RexxS (talk) 17:26, 19 May 2018 (UTC)
It looks like at least several hundred articles are no longer in that category either. MB 17:29, 19 May 2018 (UTC)

Dates with both full date and year-only

See the infobox on Elisabeth Schiemann. The born and died years have the year duplicated, because the Wikidata has sourcing for each way. Can this be handled so that the infobox only displays the "fullest" date available? -- JHunterJ (talk) 20:51, 4 June 2018 (UTC)

Note: while this feature might be useful in the general case, in this specific case I've removed the "fuller" dates from Wikidata as I can't find them in the cited source. Nikkimaria (talk) 00:29, 5 June 2018 (UTC)

Wikipedia:Wikidata/2018_Infobox_RfC#Discussion

Per the closure of this RfC, I've updated the template to require sourced data, other than for image and website. Let me know if this causes any unexpected issues - pretty much all articlespace implementations already used this default behaviour. Not sure whether there are any other changes, to either the template itself or its documentation, to be made as a result of this RfC - thoughts? Perhaps something about verifying accuracy/reliability? Nikkimaria (talk) 22:06, 18 June 2018 (UTC)

@Nikkimaria: I've trimmed the code as there's no point manually setting what is the default option for the module. Per the RfC outcome, should we also display the inline references from Wikidata as well? Thanks. Mike Peel (talk) 22:16, 18 June 2018 (UTC)
Not sure... on the one hand that might help with verifiability, but on the other could cause inconsistencies in reference formatting, particularly on articles that use some sort of manual style. Might be a can of worms we don't want to open right at the moment. Nikkimaria (talk) 22:39, 18 June 2018 (UTC)
Reference formatting clashes are almost a given, since there are so many different ones here. But the RfC 3A option said "All such statements must display a reference, even if they repeat a statement that is referenced in the body of the article." Thanks. Mike Peel (talk) 23:11, 18 June 2018 (UTC)
The closing statement didn't appear to delve into that bit, just reliability more broadly - not sure whether that was intentional on their part or not. Nikkimaria (talk) 00:00, 19 June 2018 (UTC)
(edit conflict) @Nikkimaria and Mike Peel: The infobox now works exactly as it did before your two edits, except that now I can't preview an infobox with |onlysourced=no to see what other data would be available (and how it would look) if it were sourced. On the other hand, the code is neater, so maybe it's an improvement; I'm not sure.
I wouldn't enable references because the whiners will immediately bring up a load of examples of where the infobox references don't match those in the article, then demand we make the references format like those. That can't be done, so the only way to meet WP:CITESTYLE would be to go back to a non-Wikidata infobox. Your call, though.
I'll add that "All such statements must display a reference" is nonsense. Other than parenthetical referencing, we don't have statements displaying references, only a link to the reference. Each statement imported from Wikidata already has a link to its supporting reference (on Wikidata). You need just the same number of clicks to verify it. --RexxS (talk) 00:13, 19 June 2018 (UTC)
Yeah, your middle paragraph is basically what I was referring to above with "can of worms". As to your first: perhaps for your proposed use-case, {{infobox person ii}} could be revived? Nikkimaria (talk) 00:27, 19 June 2018 (UTC)
I switched to maintenance-only mode for the Wikidata infoboxes here a while back - although there's a whole bunch of improvements I'd like to make to them here, it just doesn't seem worth the pointless arguments, particularly when it comes to the strict matching requirements for the style guides. Better to spend the time supporting other projects instead, sadly, and to let enwp miss out on the benefits. Mike Peel (talk) 00:49, 19 June 2018 (UTC)
On that last point, Mike, I remain determined to keep the modules on enwiki and commons synchronised, so that folks like yourself and Nikki can make use of the potential that is created when we incorporate feedback into improved code. There's no doubt that the functionality we have now owes a great deal to both of you for your constructive suggestions and comments. Thank you! --RexxS (talk) 13:30, 19 June 2018 (UTC)
And thank you for your work in adapting the modules!
Mike, I understand why you mightn't want to devote a lot of time to these templates atm, but perhaps make a list somewhere of those improvements you'd like to see? Nikkimaria (talk) 21:48, 19 June 2018 (UTC)

Sourcing circumstances

María Errázuriz's birth date is sourced only to Spanish Wikipedia at Wikidata, and so did not display when this template was added - but the sourcing circumstances for it (circa) did. Adding suppressfields and a blank birth_date parameter had no effect. Nikkimaria (talk) 00:34, 3 May 2018 (UTC)

@Nikkimaria: The template uses {{wd}} to fetch the sourcing circumstances and unfortunately that doesn't obey onlysourced, suppressfields, etc. I can solve it by checking to see if date values have sourcing circumstances (P1480) and adding those to the date in each case. That would allow Mike Peel to simplify the template code by using just a single call to WikidataIB (probably the sandbox until we know what is happening in the RfC). I'll have a crack at that tomorrow. --RexxS (talk) 01:15, 4 May 2018 (UTC)
Excellent, thanks. Nikkimaria (talk) 02:52, 4 May 2018 (UTC)
I've added checkBlackList to the circa statement for now, so suppressfields=birth_date works. It would be useful to incorporate the functionality in WikidataIB in the longer term, though. Thanks. Mike Peel (talk) 10:11, 4 May 2018 (UTC)
@Mike Peel and Nikkimaria: It's now incorporated into Module:WikidataIB/sandbox (so it works with {{wdib}}). Examples:
  • In Philip the Arab: {{wdib |P569 |qid=Q1817 |fwd=ALL |osd=no}} → c. 204 Edit this on Wikidata
  • In Philip the Arab: {{wdib |P570 |qid=Q1817 |fwd=ALL |osd=no}} → 249, September 249, October 249 Edit this on Wikidata
  • In Gas lighting: {{wdib |P575 |qid=Q856548 |fwd=ALL |osd=no}} → c. 300, 1786 Edit this on Wikidata
Note that Philip the Arab (Q1817)'s date of birth (P569) has 'sourcing circumstances', but his date of death (P570) does not. You can use {{#invoke:WikidataIB/sandbox |getValue ||P569 |qid=Q1817 |fwd=ALL |osd=no}} if you're more comfortable with that. For now, I've just set it to work with years, but we could arrange for it to work with other precisions easily enough. Similarly for floruit (Q36424), near (Q21818619), presumably (Q18122778), etc. if those were wanted. I'll leave it to you if you want to simplify the infobox. Cheers --RexxS (talk) 19:48, 4 May 2018 (UTC)
A possibly related issue: on Pascale Montpetit the birth date is sourced on Wikidata but to IMDb, so I added suppressfields to hide it - but the age marker still showed up. (Now fetching only image to avoid this issue). Nikkimaria (talk) 01:18, 26 June 2018 (UTC)
Thanks Nikkimaria. The age marker shows because the logic in the template doesn't suppress it when birth_date is suppressed. I doubt if Mike Peel will set any priority to fixing that, although the whole field ought to be re-written as WikidataIB now deals with 'circa' internally, so that will eventually show up as a problem for Template:Infobox person/Wikidata. I'll try to have a look later.
Of course, the problem there is that Pascale Montpetit (Q3367698) has so little referenced information that there's almost nothing worth fetching. I've had a look at fr:Pascale Montpetit but the references there are not helpful for her date of birth. Your solution of using |fetchwikidata= as a whitelist is the best for cases like this. --RexxS (talk) 12:30, 26 June 2018 (UTC)

Double circa

Anyone know why Rowland Laugharne has a double circa on his date of birth? There is only one at Wikidata. Nikkimaria (talk) 23:53, 26 July 2018 (UTC)

Same with Tan-Che-Qua. Nikkimaria (talk) 01:33, 11 August 2018 (UTC)
@Nikkimaria: Just spotted this. I had included some extra code in the infobox to display the 'circa', but it's now included in WikidataIB, so I've removed the extra code now. Thanks. Mike Peel (talk) 21:38, 31 October 2018 (UTC)

getPreferredValue

"getPreferredValue - obsoleted: use getValue|rank=best instead." [1] --grin ✎ 09:22, 8 October 2018 (UTC)

References

  1. ^ Module:WikidataIB
@Grin: Done. Thanks. Mike Peel (talk) 21:38, 31 October 2018 (UTC)

Locations

Other than turning off the wikidata link is there any way to make the locations of events into the more usual "foo, country" rather than the sometimes unclear "foo". MilborneOne (talk) 10:21, 31 October 2018 (UTC)

@RexxS: Perhaps you could adapt the location code we're using on Commons so that it just shows the first location, then skips to the country, rather than displaying everything in the middle? We could then use that here. Thanks. Mike Peel (talk) 21:32, 31 October 2018 (UTC)
@Mike Peel: That's perfectly possible: I added a |skip= parameter. But to give the results you want it takes a lot more messing about than just skipping.
It's fine outside of the UK and US. For Taj Mahal (Q9141)
  • {{#invoke:WikidataIB/sandbox |location |Q9141 |first=yes |skip=yes}} → Taj Mahal, India
  • {{#invoke:WikidataIB/sandbox |location |Q9141 |first=yes}} → Taj Mahal, Uttar Pradesh, India
But for the USA, we normally miss off the "US" part (as requested). So I had to put it back and change Wikidata's "USA" to enwiki's "US" when skip was true. For Empire State Building (Q9188)
For British locations, your algorithm would skip to United Kingdom (Q145) which is the first instance of country (Q6256). I expect you wanted England (Q21), but unfortunately that's not an instance of a country, but an instance of a constituent country of the United Kingdom (Q3336843), according to Wikidata. So I had to also test for Q3336843 when skip is true. For Milton Keynes Dons F.C. (Q248188)
The only problem is I don't know how many exceptions there are, so I guess we have to just wait for folks to find them. --RexxS (talk) 22:52, 31 October 2018 (UTC)

debugging

I have added the most basic version to an actresses webpage but it is not populating, how can we make debugging quicker (before an aggressive editor removes the template from the artical) https://en.wikipedia.org/wiki/Fleur_Bennett Back ache (talk) 16:15, 30 November 2018 (UTC)

First of all, the Wikidata entry for Fleur Bennett (Q629020) has only three statements that are included in the list of properties used by Template:Infobox person/Wikidata - namely date of birth (P569), occupation (P106), educated at (P69), so that's the most that we could expect to fetch from Wikidata. Unfortunately, those three statements are unreferenced on Wikidata, so the code will not import them to Wikipedia. The way to fix that would be to add genuine references for those three properties to Fleur Bennett (Q629020).
Secondly, the way to debug the template for these sort of issues would be to include |osd={{{onlysourced|}}} in every call to WikidataIB in the template. That would enable us to add |onlysourced=no to an article and see what would appear if we added references to the Wikidata entry.
Optionally you could paste {{#invoke:Sandbox/RexxS/WdRefs|seeRefs}} into a section of an article and preview it. That will generate a table showing what claims exist on Wikidata and what references they have. Sadly a significant proportion of Wikidata entries are unreferenced, so that severely limits the usefulness of this template. HTH --RexxS (talk) 21:45, 30 November 2018 (UTC)

Website with URL template

Hello. The website parameter should wrap the site inside of {{URL}} just like {{Infobox person}} does. Normally this is supposed to be done manually, but as this template is all automated, it looks like it should be handled here. Opencooper (talk) 10:34, 24 January 2019 (UTC)

@Opencooper: This template is intended to be a drop-in replacement for {{Infobox person}}. It therefore handles its parameters in the same way, otherwise editors would have to remove the {{url}} from the parameter value when changing to this template. I can't see the benefit of having to do that every time. --RexxS (talk) 18:01, 24 January 2019 (UTC)
@RexxS: Ah, I guess I was mistaken, because I assumed it was more like an infobox that just autofetches everything from Wikidata. Would you know how to still get the website from Wikidata but wrap it in {{url}}? Opencooper (talk) 17:31, 28 January 2019 (UTC)
@Opencooper: The infobox will only autofetch from Wikidata if each article where it is used adds |fetchwikidat=ALL to the infobox. This is because editors object to having the decision on whether to not to use Wikidata made at the infobox design level – see Wikipedia:Village pump (policy)/Archive 128 #RfC: Wikidata in infoboxes, opt-in or opt-out? – so these sort of infoboxes ("opt-in") allow the editors of each article to choose at the article level.
The code in |data66 fetches the website from Wikidata, but it would need to be reformatted somewhat to wrap the website url in {{url}}, like this:
  • | data66 = {{if empty | {{#if:{{#invoke:WikidataIB | getValue | rank=best |P856 |name=website |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced=no |noicon=y | {{{website|{{{homepage|}}}}}} }} | {{url|{{#invoke:WikidataIB | getValue | rank=best |P856 |name=website |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced=no |noicon=y | {{{website|{{{homepage|}}}}}} }} }} }} | {{#invoke:WikidataIB | getValue | rank=best |P1581 |name=blog |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |onlysourced={{{onlysourced|no}}} |noicon={{{noicon|}}} }} }}
It's necessary to test whether the website has a value before wrapping it in {{url}} because url displays a message if called with an empty parameter. I could create a fork of {{url}} that returned nothing if its parameter is blank, which would simplify the code a lot. --RexxS (talk) 18:44, 28 January 2019 (UTC)
Egads, I just discovered {{Official URL}}. Opencooper (talk) 04:08, 20 March 2019 (UTC)

Span tags not working properly after recent edit

I recently attempted to fix this template's use of span tags for birth and death places, but I was reverted by RexxS with an explanation that {{If then show}} actually uses empty unnamed parameters to do its work (God help us all).

Whether or not that is good programming practice I will leave for a different discussion (hint: it is not). The current problem with this template is that this template currently fails to render the opening span tag for birth and death places, and then it follows the birth information with a closing span tag that has no opening tag. For example, at Marietta Alboni, the infobox is called thus:

{{infobox person/Wikidata | fetchwikidata=ALL | onlysourced = yes |caption = Marietta Alboni ''[[carte de visite]]'' by [[André-Adolphe-Eugène Disdéri]] }}

The birth and death information render thus:

<th scope="row">Born</th><td>6 March 1826 [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P569|Edit this on Wikidata]]<br /></span> [[Città di Castello|Città di Castello]] [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P19|Edit this on Wikidata]]</td></tr><tr><th scope="row">Died</th><td>23 June 1894 [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P570|Edit this on Wikidata]] (aged 68)<br /></span> [[Ville-d'Avray|Ville-d'Avray]] [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P20|Edit this on Wikidata]]</td></tr>


Note the closing span tags and the lack of opening span tags. RexxS, please fix. Thanks. – Jonesey95 (talk) 10:36, 2 April 2019 (UTC)

@Jonesey95: Thanks for spotting the problem; the fix was trivial. Using unnamed parameters gives errors when one of the parameters contains an = sign, and the fix is to explicitly use numbered parameters, which I've now done. The rendered html at Marietta Alboni now looks like this (I've snipped the pen icons for clarity):
<th scope="row">Born</th><td>6 March 1826  ...snip... <br><span class="birthplace"><a href="/wiki/Citt%C3%A0_di_Castello" title="Città di Castello">Città di Castello</a>  ...snip... </span></td>
<th scope="row">Died</th><td>23 June 1894  ...snip... (aged 68)<br><span class="deathplace"><a href="/wiki/Ville-d%27Avray" title="">Ville-d'Avray</a>  ...snip... </span></td>
Please let me know if you think any errors remain.
I am concerned that you think there is a problem with empty unnamed parameters. That is standard practice on thousands of {{#if:test|value-if-true|value-if-false}} statements in templates across Wikipedia. Either of those values is commonly omitted and the wiki hasn't fallen over yet.
The Template:if then show is a very simple adaptation of the {{#if: ... parser function. It works like this:
{{if then show |Parameter1|Parameter2|Parameter3|Parameter4}} → Parameter3Parameter1Parameter4
so that Parameter1 is enclosed between parameters 3 and 4, allowing us to add spans, etc. around a Wikidata call:
{{if then show |1=Call to Wikidata|2=|3=<span class="something">|4=</span>}} → Call to Wikidata
If the first parameter is blank, then the second parameter alone is returned.
{{if then show ||Parameter2|Parameter3|Parameter4}} → Parameter2
For an infobox we will want that second parameter to be blank. I hope that makes it clearer for you now. --RexxS (talk) 14:02, 2 April 2019 (UTC)
Thanks for fixing. The fragility of unnamed parameters and the equals sign is one of many reasons that templates with multiple unnamed parameters are a bad idea. As for blank sections of if statements, that's a totally different thing, since if statements are not templates and do not take parameters. And as for {{if then show}}, first of all, the parameters seem out of logical order to me, having worked for decades with if-then-else statements (yours is more like if-else-then-implied-also, or something; awkward). Second, I'd rather just see an if statement used; the syntax is more familiar to more editors. Something like this untested code: {{#if:Wikidata value exists|<span class="something">Wikidata value</span>|else show this plain thing}} seems more straightforward than deliberately using blank parameters and hoping that experienced template editors won't helpfully "tidy them up" for you. – Jonesey95 (talk) 19:51, 2 April 2019 (UTC)
I agree that unnamed parameters are fragile, but look at templates like Template:Talk quote or Template:Talk quote inline, which I (ab)use all the time. I've gotten in the habit now of typing {{talkquote|1= before I paste the quoted text, as I then don't have to think about whether it contains equals signs.
It would be nice if a simple #if: statement would do the job, as it does very well for static parameters. But when we fetch something from Wikidata, (1) it's bad practice to make the same call twice (normally you'd just assign it to a variable and use that, but there aren't any general purpose variables in templates); and (2) it clogs up the template enormously if the full use of the available parameters is made. To give an example, for |birth_date= the code using an #if: statement would be:
{{#if: {{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }} | <span class="birthplace">{{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }}</span> }}
which I can replace with a single Wikidata call by using Template:If then show:
{{if then show |1={{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }} |2=|3=<span class="birthplace"> |4=</span> }}
Do you think it would be clearer if I aliased the unnamed parameters with named ones? I've made an example in {{if then show/sandbox}}, so we could write:
{{if then show |test={{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }} |else=|prefix=<span class="birthplace"> |suffix=</span> }}
We could actually just leave out the |else= in that case. What do you think? --RexxS (talk) 21:35, 2 April 2019 (UTC)
My purpose in using the word "multiple" above was to emphasize that having multiple unnamed parameters is a bad idea, since if someone ever wants to add aliases to any of the parameters, the numbers start moving around. {template|foo|bar} will behave differently from {template|name=foo|bar}, causing all sorts of messes ("bar" moves from being 2= to being 1=, which editors do not expect). I recommend converting all unnamed parameters to named parameters and discontinuing the use of unnamed parameters in {{if then show}}. – Jonesey95 (talk) 04:32, 3 April 2019 (UTC)

Span tags not working properly after recent edit

I recently attempted to fix this template's use of span tags for birth and death places, but I was reverted by RexxS with an explanation that {{If then show}} actually uses empty unnamed parameters to do its work (God help us all).

Whether or not that is good programming practice I will leave for a different discussion (hint: it is not). The current problem with this template is that this template currently fails to render the opening span tag for birth and death places, and then it follows the birth information with a closing span tag that has no opening tag. For example, at Marietta Alboni, the infobox is called thus:

{{infobox person/Wikidata | fetchwikidata=ALL | onlysourced = yes |caption = Marietta Alboni ''[[carte de visite]]'' by [[André-Adolphe-Eugène Disdéri]] }}

The birth and death information render thus:

<th scope="row">Born</th><td>6 March 1826 [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P569|Edit this on Wikidata]]<br /></span> [[Città di Castello|Città di Castello]] [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P19|Edit this on Wikidata]]</td></tr><tr><th scope="row">Died</th><td>23 June 1894 [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P570|Edit this on Wikidata]] (aged 68)<br /></span> [[Ville-d'Avray|Ville-d'Avray]] [[File:Blue pencil.svg |frameless |text-top |10px |alt=Edit this on Wikidata|link=https://www.wikidata.org/wiki/Q269130?uselang=en#P20|Edit this on Wikidata]]</td></tr>


Note the closing span tags and the lack of opening span tags. RexxS, please fix. Thanks. – Jonesey95 (talk) 10:36, 2 April 2019 (UTC)

@Jonesey95: Thanks for spotting the problem; the fix was trivial. Using unnamed parameters gives errors when one of the parameters contains an = sign, and the fix is to explicitly use numbered parameters, which I've now done. The rendered html at Marietta Alboni now looks like this (I've snipped the pen icons for clarity):
<th scope="row">Born</th><td>6 March 1826  ...snip... <br><span class="birthplace"><a href="/wiki/Citt%C3%A0_di_Castello" title="Città di Castello">Città di Castello</a>  ...snip... </span></td>
<th scope="row">Died</th><td>23 June 1894  ...snip... (aged 68)<br><span class="deathplace"><a href="/wiki/Ville-d%27Avray" title="">Ville-d'Avray</a>  ...snip... </span></td>
Please let me know if you think any errors remain.
I am concerned that you think there is a problem with empty unnamed parameters. That is standard practice on thousands of {{#if:test|value-if-true|value-if-false}} statements in templates across Wikipedia. Either of those values is commonly omitted and the wiki hasn't fallen over yet.
The Template:if then show is a very simple adaptation of the {{#if: ... parser function. It works like this:
{{if then show |Parameter1|Parameter2|Parameter3|Parameter4}} → Parameter3Parameter1Parameter4
so that Parameter1 is enclosed between parameters 3 and 4, allowing us to add spans, etc. around a Wikidata call:
{{if then show |1=Call to Wikidata|2=|3=<span class="something">|4=</span>}} → Call to Wikidata
If the first parameter is blank, then the second parameter alone is returned.
{{if then show ||Parameter2|Parameter3|Parameter4}} → Parameter2
For an infobox we will want that second parameter to be blank. I hope that makes it clearer for you now. --RexxS (talk) 14:02, 2 April 2019 (UTC)
Thanks for fixing. The fragility of unnamed parameters and the equals sign is one of many reasons that templates with multiple unnamed parameters are a bad idea. As for blank sections of if statements, that's a totally different thing, since if statements are not templates and do not take parameters. And as for {{if then show}}, first of all, the parameters seem out of logical order to me, having worked for decades with if-then-else statements (yours is more like if-else-then-implied-also, or something; awkward). Second, I'd rather just see an if statement used; the syntax is more familiar to more editors. Something like this untested code: {{#if:Wikidata value exists|<span class="something">Wikidata value</span>|else show this plain thing}} seems more straightforward than deliberately using blank parameters and hoping that experienced template editors won't helpfully "tidy them up" for you. – Jonesey95 (talk) 19:51, 2 April 2019 (UTC)
I agree that unnamed parameters are fragile, but look at templates like Template:Talk quote or Template:Talk quote inline, which I (ab)use all the time. I've gotten in the habit now of typing {{talkquote|1= before I paste the quoted text, as I then don't have to think about whether it contains equals signs.
It would be nice if a simple #if: statement would do the job, as it does very well for static parameters. But when we fetch something from Wikidata, (1) it's bad practice to make the same call twice (normally you'd just assign it to a variable and use that, but there aren't any general purpose variables in templates); and (2) it clogs up the template enormously if the full use of the available parameters is made. To give an example, for |birth_date= the code using an #if: statement would be:
{{#if: {{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }} | <span class="birthplace">{{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }}</span> }}
which I can replace with a single Wikidata call by using Template:If then show:
{{if then show |1={{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }} |2=|3=<span class="birthplace"> |4=</span> }}
Do you think it would be clearer if I aliased the unnamed parameters with named ones? I've made an example in {{if then show/sandbox}}, so we could write:
{{if then show |test={{#invoke:WikidataIB | getValue | rank=best |P19 |name=birth_place |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |fetchwikidata={{{fetchwikidata|}}} |noicon={{{noicon|}}} | {{{birth_place|}}} }} |else=|prefix=<span class="birthplace"> |suffix=</span> }}
We could actually just leave out the |else= in that case. What do you think? --RexxS (talk) 21:35, 2 April 2019 (UTC)
My purpose in using the word "multiple" above was to emphasize that having multiple unnamed parameters is a bad idea, since if someone ever wants to add aliases to any of the parameters, the numbers start moving around. {template|foo|bar} will behave differently from {template|name=foo|bar}, causing all sorts of messes ("bar" moves from being 2= to being 1=, which editors do not expect). I recommend converting all unnamed parameters to named parameters and discontinuing the use of unnamed parameters in {{if then show}}. – Jonesey95 (talk) 04:32, 3 April 2019 (UTC)

Does not work

Why it does not work in Mariam Lortkipanidze? Wikisaurus (talk) 19:58, 3 June 2019 (UTC)

@Wikisaurus: The template passes through only that data which has a non-Wikipedia source. If you add such a source on Wikidata, as I've just done for employer, it will appear here. Nikkimaria (talk) 20:44, 3 June 2019 (UTC)
Thank you! I added a comment in documentation. P. S. Quite unusual for me - in Russian Wikipedia not only all common infoboxes have Wikidata support, but they take data without any sources. Wikisaurus (talk) 20:48, 3 June 2019 (UTC)

"stated as" qualifiers

The instance of this infobox on Mildred Ratcliffe currently displays:

but on Mildred Ratcliffe (Q63872518), both values are qualified using object named as (P1932) with "Rochester Grammar School for Girls" and "Post Office Savings Bank" respectively.

Can the template be made to show the latter values, while linking to the former articles, thus:

please?

The same should apply to subject named as (P1810). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:00, 24 May 2019 (UTC)

The simplest solution is to use local values. --RexxS (talk) 15:26, 24 May 2019 (UTC)
Perhaps; but this is a very common use case ({{cite Q}}, for example, also needs this for author and venue names); and these are parameters that often have multiple values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:31, 25 May 2019 (UTC)
Once you get multiple values, I don't see any easy way of making the template show the 'stated as' values, linked to the relevant article.
  • {{#invoke:WikidataIB |getValue |ps=1 |P108 |qid=Q63872518}} → Civil Service, National Savings and Investments
  • {{#invoke:WikidataIB |getValue |ps=1 |P108 |qual=P1932 |qualsonly=y |qid=Q63872518}} → Post Office Savings Bank
It would need amendments to the code in WikidataIB to first check whether the object named as (P1932) qualifier exists, then to retrieve the value of employer (P108) and then retrieve the article link and finally to create the linked wikitext. It would also have to do the same for qualifier subject named as (P1810). That raises some questions: (1) If both qualifiers are present, which one takes precedence? (2) Under what circumstances should this checking for qualifiers take place? We clearly can't insist on doing the check every time; so do we create yet another parameter to switch the checking on, or do we create a new function in the module?
Maybe somebody else can see a better way? --RexxS (talk) 22:00, 3 June 2019 (UTC)

Wrong age at death

As can be seen here [5] for someone with a birth recorded in Wikidata as "1930s" and death in 2011, the age at death is shown by this template as 81. They were in fact 76. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:48, 8 June 2019 (UTC) 

table#1 {
    table#2 {
        ["id"] = "Q53502280$581b9982-4e4b-4e31-8516-867438b43f67",
        ["mainsnak"] = table#3 {
            ["datatype"] = "time",
            ["datavalue"] = table#4 {
                ["type"] = "time",
                ["value"] = table#5 {
                    ["after"] = 0,
                    ["before"] = 0,
                    ["calendarmodel"] = "http://www.wikidata.org/entity/Q1985727",
                    ["precision"] = 11,
                    ["time"] = "+1935-05-27T00:00:00Z",
                    ["timezone"] = 0,
                },
            },
            ["property"] = "P569",
            ["snaktype"] = "value",
        },
        ["rank"] = "normal",
        ["references"] = table#6 {
            table#7 {
                ["hash"] = "e866efbb3b2074d73e0b13d263078c285339de4a",
                ["snaks"] = table#8 {
                    ["P813"] = table#9 {
                        table#10 {
                            ["datatype"] = "time",
                            ["datavalue"] = table#11 {
                                ["type"] = "time",
                                ["value"] = table#12 {
                                    ["after"] = 0,
                                    ["before"] = 0,
                                    ["calendarmodel"] = "http://www.wikidata.org/entity/Q1985727",
                                    ["precision"] = 11,
                                    ["time"] = "+2019-06-08T00:00:00Z",
                                    ["timezone"] = 0,
                                },
                            },
                            ["property"] = "P813",
                            ["snaktype"] = "value",
                        },
                    },
                    ["P854"] = table#13 {
                        table#14 {
                            ["datatype"] = "url",
                            ["datavalue"] = table#15 {
                                ["type"] = "string",
                                ["value"] = "https://www.ryemuseum.co.uk/brian-hargreaves/",
                            },
                            ["property"] = "P854",
                            ["snaktype"] = "value",
                        },
                    },
                },
                ["snaks-order"] = table#16 {
                    "P854",
                    "P813",
                },
            },
        },
        ["type"] = "statement",
    },
}
Yup, Wikidata doesn't really know when he was born: as you can see it stores 1930. This template doesn't seem able to cope with a person whose birthdate is not known, but whose age at death is known. You could try changing the date of birth on Wikidata to 'circa 1935' and see if that helps. Or you could try lower/upper limits of 1 October 1934 and 30 September 1935. Otherwise we have to supply a custom value for |date_of_death= in the article. By the way, Wikidata has Country’s top butterfly artist dies, aged 76 as a reference for his dates of birth and death, but neither are certain from the article. The opening sentence is ambiguous about whether he died on 30 September, or whether he died later following a heart attack on 30 September. I think we can assume the former, but it would be good to have another source for confirmation. --RexxS (talk) 13:48, 8 June 2019 (UTC)

Wikidata knows: 

          ["precision"] = 8,
          ["time"] = "+1930-00-00T00:00:00Z",

where "8" is a precision of "decade" (resulting from me literally typing "1930s"), so treating it as an exact year gives at best 90% chance of being wrong. I have since added the full date of birth to Wikipedia, using a source that gives both dates, but was holding off adding it to Wikidata until you'd seen what was happening in the infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 9 June 2019 (UTC)

@Pigsonthewing: I disagree that knowing a birth-date to within a decade is sufficient to calculate age at death. I've just added "1930s" for date of birth (P569) to Wikidata Sandbox (Q4115189); and testing the call used in this template you get this result:
  • {{wikidata|property|raw|Q4115189|P569}} →
That call doesn't understand precision. As I said, this template doesn't seem able to cope with a person whose birthdate is not known. The solution is still either to fix the date in Wikidata or use a local custom value in the article. --RexxS (talk) 18:35, 10 June 2019 (UTC)
Where did I say that "knowing a birth-date to within a decade is sufficient to calculate age at death"? My point is that it is not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 10 June 2019 (UTC)
You didn't say it. You implied it when you said "Wikidata knows". It doesn't. All Wikidata knew was the decade. I'm sure we both agree that that's not enough to calculate an age at death. --RexxS (talk) 21:24, 10 June 2019 (UTC)
RexxS, do you contest that Wikidata "knows" 1930s [that is where Andy used the word] and the year of death? Pigsonthewing didn't imply that knowing "1930s" is sufficient, he also posted the year of death. Then the age at death can be calculated - with nearly the same precision (+-5) as the date of birth. If only the year of death is known the resulting precision is +-6. 77.13.54.171 (talk) 07:43, 11 June 2019 (UTC)
"Wikidata doesn't really know when he was born: as you can see it stores 1930. This template doesn't seem able to cope with a person whose birthdate is not known ..." - which, if any, of those three statements do you disagree with? This template is incapable of calculating an age of death other than as a simple number of years. Yes, you can calculate an age at death ±5 years, but the template can't. If I stored any date from 1930-00-00 to 1939-12-31 as date of birth (P569) and set the precision to '8' (decade), Wikidata would still treat that as '1930s' (although this template would give a different age at death for each case). Please feel free to upgrade this template to cater for varying precisions in the two dates: I'm sure Andy and I would appreciate it. --RexxS (talk) 11:08, 11 June 2019 (UTC)

Icon error

This revision shows a redlinked "edit this on wikidata", linking to Special:Upload. Other articles appear to be displaying correctly. Nikkimaria (talk) 00:48, 20 June 2019 (UTC)

@Xaosflux: possibly a bug in the changes you were making to the icon yesterday? Thanks. Mike Peel (talk) 06:32, 20 June 2019 (UTC)
@Nikkimaria and Mike Peel: It's probably the use of String2|sentence on what is returned from Wikidata – see Module talk:WikidataIB, section #icon errors caused by #invoke:String2 | sentence. Let me know if my "kludge" doesn't fix the problems. Cheers --RexxS (talk) 09:41, 20 June 2019 (UTC)
Let me know if you need me to look at anything else, most of my updates were just changing the icon file. — xaosflux Talk 11:10, 20 June 2019 (UTC)
@Xaosflux: Thanks for helping to get some consistency in the icons we use. I must admit, I just picked one that looked right when I first wrote that bit of code. It probably makes sense to have all-lower-caps redirects for common icon files, then we don't have to worry about editors down the line transforming entire strings into sentence case. Those redirects are cheap. Cheers --RexxS (talk) 13:26, 20 June 2019 (UTC)
@RexxS: I just happened to come upon it when processing some other edit request and got some input from a WMF UX person, Volker E. (WMF). See also Module talk:EditAtWikidata. The link colors are likely going to change closer to that new image as well, though the one in the side bar is still grayish right now. — xaosflux Talk 13:35, 20 June 2019 (UTC)
@Xaosflux: yes, I saw the original request, and I'm happy with the updated icon, especially as it's named for its function (UI edit) rather than its characteristics (blue), so hopefully further tweaks to the icon itself won't require any action from us. Cheers --RexxS (talk) 13:42, 20 June 2019 (UTC)

Omitting employer fields if there's end date

Currently all previous employers are listed in the infobox, though only the current employer is relevant in most cases. For example, David_Goodsell is currently listed at Scripps Research, Scripps Research, University of California, but only one of those is a current position. The others have end times listed on the Would there be a sensible way to have the ended ones hidden by default, or with some 'Previous employer' field for those where they're relevant to the infobox? T.Shafee(Evo&Evo)talk 06:21, 12 July 2019 (UTC)

What about cases like Anatole Abragam? Nikkimaria (talk) 10:39, 12 July 2019 (UTC)
We could use qualifiers set to DATES. For David Goodsell (Q19878497) and Anatole Abragam (Q487491):
{{#invoke:WikidataIB |getValue |fwd=ALL |P108 |qual=DATES |qid=Q19878497}} → Scripps Research (1987–1992), University of California, Los Angeles (1992–1994), Scripps Research (1994–), Rutgers University (2016–) Edit this on Wikidata
{{#invoke:WikidataIB |getValue |fwd=ALL |P108 |qual=DATES |qid=Q487491}} → Collège de France (1960–1985), Leiden University (1979–) Edit this on Wikidata
That wouldn't need much changing in the infobox code. --RexxS (talk) 11:21, 12 July 2019 (UTC)
@Evolution and evolvability, Nikkimaria, and RexxS: Using qual=DATES seems like a sensible improvement, so I've implemented it. It looks good at David Goodsell. Thanks. Mike Peel (talk) 19:09, 12 July 2019 (UTC)
Splendid, thanks! That looks like it should work in most cases. T.Shafee(Evo&Evo)talk 05:30, 13 July 2019 (UTC)

Works field and MOS-T

Hey,

I've been sandboxing the use of the infobox for Russell T Davies, and I've got a question about the works field. Running {{#invoke:WikidataIB |getValue |fwd=ALL |P800 |qid=Q361981}} gives

Doctor Who, The Sarah Jane Adventures, Torchwood, Bob & Rose, Queer as Folk, The Second Coming, Cucumber, Banana, Years and Years Edit this on Wikidata

As these are all names of television series, by WP:MOS-T, they should be italicised. Compare this with Beethoven: {{#invoke:WikidataIB |getValue |fwd=ALL |P800 |qid=Q255|osd=no}}, which gives the result

Für Elise, Symphony No. 9, Piano Sonata No. 14, Missa solemnis, Piano Sonata No. 8, Symphony No. 5, Symphony No. 6, Piano Sonata No. 21, Piano Sonata No. 23, Violin Sonata No. 9, Symphony No. 3, Fidelio Edit this on Wikidata

"Für Elise" should be in quotes, and the Missa solemnise and Fidelio should be in italics.

Is there a way to look at these works' data (e.g., for Doctor Who: {{#invoke:WikidataIB |getValue |fwd=ALL |P31 |qid=Q34316|osd=no}} → television series Edit this on Wikidata) and format their titles accordingly? I feel as if there should be, but Lua modules make my brain hurt. Sceptre (talk) 03:19, 15 September 2019 (UTC)

@Sceptre: You can add a prefix and suffix to each item returned by using the |prefix= and |postfix= parameters. So to italicise each series title for Russell T Davies (Q361981) you can use:
But there isn't an easy way to automatically detect that "Für Elise" should be in quotes, and the Missa solemnise and Fidelio should be in italics. In these sort of cases, the simple option is to supply the values locally as an editor will know the correct formatting.
There is a call, getPropOfProp, that fetches a property value of a property's value, so:
But you need to do that lookup for each individual item. That means we would need a specialised call, similar to getValue, that reads each value's instance of (P31) and adds formatting depending on that value. I could write that when I have some time, but I'd need to assemble a comprehensive list of values and their formatting:
I'm not convinced that Wikidata's P31 classifications will necessarily fit with all of MOS:ITALICTITLE and MOS:QUOTETITLE, but it's worth giving it a try. Can you suggest more Q-numbers for P31 that require italics and quotes? --RexxS (talk) 12:47, 15 September 2019 (UTC)
As far as italics go, here's the list of P31 classifications I can think of off the top of my head:
book (Q571) (literary trilogy (Q13593966), book series (Q277759)), film (Q11424) (film trilogy (Q13593818), film series (Q24856)), television series (Q5398426), album (Q482994), extended play (Q169930), comic book (Q1760610), video game (Q7889), video game series (Q7058673), play (Q25379), musical (Q2743), epic poem (Q37484).
There are probably some more edge-cases (e.g. American Horror Story: Coven (Q7478205) should be italicised but Game of Thrones, season 7 (Q25150794) shouldn't, even though they share the same classification), but these are the ones I can think of. Sceptre (talk) 15:18, 15 September 2019 (UTC)
@Sceptre: I've knocked up a demo in the Module:WikidataIB/sandbox. It loads a submodule called Module:WikidataIB/titleformats which is just the two lists and a bit of code to massage them into a more usable format. This is the result for Russell T Davies (Q361981):
and for Ludwig van Beethoven (Q255):
You might want to test it out. If you spot any more instances that should be in either of the lists, just add them to Module:WikidataIB/titleformats using the same format – it's not protected. Incidentally, why aren't you a template editor? --RexxS (talk) 18:15, 15 September 2019 (UTC)
I've never felt the need to ask for them (there's nothing too time sensitive it can't wait for an editprotected), though given permissions are WP:NOBIGDEAL and I've used it more recently… I might as well ask? Sceptre (talk) 19:25, 15 September 2019 (UTC)

Ahmed Tantawi

Why does {{infobox person/Wikidata|fetchwikidata=ALL}} in Ahmed Tantawi fail? P31, P102, P27, P21 are all in the Wikidata entry d:Q74317467, all with a URL ref and an archive URL ref, and on the rendered Wikipedia page I only get Tantawi's name and none of the other three properties.

Is a birth date obligatory for the template to work? Boud (talk) 03:59, 10 November 2019 (UTC)

A birth date is not obligatory; however, the template does not pass through every single referenced property, but rather a selection. See the list of properties on the right side of the documentation page. Nikkimaria (talk) 04:21, 10 November 2019 (UTC)
Sure, that's clear, but doesn't explain the problem. The list of properties on the right side of the documentation page includes d:Property:P102 and d:Property:P27, which are both present with references at d:Q74317467. Why don't P102 and P27 - member of political party and citizenship - appear on the Wikipedia Wikidata-fetched-infobox if I make an edit to uncomment {{infobox person/Wikidata|fetchwikidata=ALL}} and I preview the result? Boud (talk) 04:35, 10 November 2019 (UTC) (trying to fix the property links Boud (talk) 04:37, 10 November 2019 (UTC))
Er, no, they don't seem to be on the list? Citizenship was removed following this discussion. Nikkimaria (talk) 14:15, 10 November 2019 (UTC)
Thanks, now I see - my error. I confused "on the right side" (and even quoted it back to you :P) with the "Subject-specific parameters" table. Probably I assumed that they were identical. I've edited the header to clarify this to reduce the chance of others making the same error as me. Boud (talk) 14:46, 10 November 2019 (UTC)
So I presume that in the case of Ahmed Tantawi, either I should volunteer to start Template:Infobox officeholder/Wikdata or I should wait until someone else does. Boud (talk) 14:58, 10 November 2019 (UTC)
It exists, although it is underdeveloped at this point so will need some considerable work. Nikkimaria (talk) 15:10, 10 November 2019 (UTC)
I am curious why P102 does not appear when Infobox person/Wikidata is used. Ahmed Tantawi has a sourced value for P102, and P102 is apparently fetched by the template, per this code below:
| label47    = Political party
| data47     = {{#invoke:WikidataIB | getValue | rank=best |P102 |name=party |qid={{{qid|}}} |suppressfields={{{suppressfields|}}} |{{{party|}}} }}
| class47    = org
It seems to me that P102 should be fetched. – Jonesey95 (talk) 15:31, 10 November 2019 (UTC)
There are several parameters like that that are not fetched and are missing |fetchwikidata=. Nikkimaria (talk) 16:06, 10 November 2019 (UTC)
My impression from the documentation is that |fetchwikidata=ALL is supposed to get all available parameter values (that are sourced, in this template). – Jonesey95 (talk) 17:02, 10 November 2019 (UTC)
See if this edit helps clarify. Probably there should be a comment about why there is a different list of parameters in the main, wide column of the page. Something like The list of parameters below shows parameters, some of which are enabled, others that are currently disabled. Please [[Talk:Template:Infobox_person/Wikidata|discuss proposals]] to enable or disable some of these parameters. Boud (talk) 19:11, 10 November 2019 (UTC)
Does that list in the documentation somehow control what is actually fetched? As far as I can tell, the template code I pasted above should fetch P102, but it does not. Where in the actual template code is the list of fetched Wikidata values? – Jonesey95 (talk) 23:45, 10 November 2019 (UTC)
I'm making an educated guess, without fully understanding the code, based on Nikkimaria's comment and browsing the code: if a parameter "paragraph" (what looks to me something like a paragraph, not in any formal sense) in the template code includes |fetchwikidata= in a correct way, then it is fetchable (e.g. by ALL); otherwise, it is unfetchable. The P102 "paragraph" (that you quoted) does not include |fetchwikidata=. Somewhere in the code that generates the right-column box in the template there is, I presume, an instruction that collects together these fetchable items, so that someone wishing to use the template doesn't have to view the template code. Boud (talk) 01:25, 11 November 2019 (UTC)

@Boud, Nikkimaria, and Jonesey95: This problem has arisen because the template has not been maintained for some time. I'll try to answer your queries:

First, the underlying code from Module:WikidataIB always needs a fetchwikidata parameter, because there was a considerable strength of feeling among the community that an editor had to take responsibility for enabling Wikidata fetching on each article where Wikidata-aware infoboxes were used (the only exception being low-use infoboxes, e.g. {{Infobox telescope}}, where an editor could check all the articles themselves). So each #invoke:WikidataIB|getValue call will need a fetchwikidata={{{fetchwikidata|}}} parameter, otherwise you'll get nothing.

Next, when this infobox was being developed, there were numerous fields that had no corresponding Wikidata property at the time. However, if there was a chance that a property could be created, the code was added using "P0" as the property and omitting the |fetchwikidata= parameter to avoid possible errors.

Finally, over time, some more properties have become available, and editors have updated the template code "P0" to an appropriate value, but sometimes they have not added the necessary fetchwikidata={{{fetchwikidata|}}} to the template in that call. You're seeing the result of that.

Some time ago, I updated the code in WikidataIB to never return a Wikidata value or give an error message if "P0" were passed as the property, so now we won't get error messages or spurious values for the fields that don't yet have a relevant property. Consequently, I've just updated this template's code to include fetchwikidata={{{fetchwikidata|}}} on each call (I think - someone might check). Would you please see if the template is behaving more as expected now, and let me know if any problems, arise? Cheers --RexxS (talk) 15:02, 12 November 2019 (UTC)

Thanks for that explanation. I did not see this explicit explanation in the module's documentation, which is why I was so confused. The wikidata infobox appears to be working better in the above article now. – Jonesey95 (talk) 15:12, 12 November 2019 (UTC)
For me, the Ahmed Tantawi (uncomment near the top and preview) generates a box with P27 nationality and P102 political party - thanks for the explanation. I'll revert my recent edits of explanation, since now they're misleading (it seems like the right-hand box is not generated automatically...).
However, in this version of the sandbox, I've tried adding P39 - position held - as thing (parameter or othing) number 77. Editing and previewing Ahmed Tantawi, which right now has the sandbox version in the comment, does not give me the entry for his membership of parliament. My guess is that this is because of the non-transitivity of the following sequence of relationships:
So while a human would interpret this to mean that Tantawi holds a position with a particular social role and set of powers called 'member of parliament' and this is for the Egyptian example of this type of role, the Infobox_person/Wikidata/sandbox does not understand that. :( It wouldn't make sense to classify Tantawi directly with P39 (except as a temporary hack - I didn't test this) - classifying at the most specific level makes the most sense. Should a relationship be added in the above? (I haven't listed all the details of these objects here - click for details.) Or should one or more of the relationships be changed? Boud (talk) 22:15, 12 November 2019 (UTC)
@Boud: I'm afraid the answer is much simpler: the getValue call by default only fetches values that have a source, and "imported from xyz Wikipedia" is discounted as a source - we can't use Wikipedia as a source for itself. You can check this with a simple call, using position held (P39) in Ahmed Tantawi (Q74317467) (|fwd= is a shortcut alias for |fetchwikidata=):
  • {{#invoke:WikidataIB |getValue |P39 |qid=Q74317467 |fwd=ALL}} → Member of the House of Representatives of Egypt Edit this on Wikidata
  • Compare that with the same call when the parameter |onlysourced=no, which switches off the requirement for sourcing:
  • {{#invoke:WikidataIB |getValue |P39 |qid=Q74317467 |fwd=ALL |onlysourced=no}} → Member of the House of Representatives of Egypt Edit this on Wikidata
It's useful to be able to turn off sourcing for testing and for some fields (like images) that don't have sourcing, but otherwise, consensus is that we mustn't create infoboxes that import unsourced values from Wikidata. Hope that helps --RexxS (talk) 00:56, 13 November 2019 (UTC)
@RexxS: Thanks for checking, and for the code examples. I was aware of the onlysourced=yes default, which I think could be argued to implement a variant of Asimov's Laws 1 and 2 in this context, in which Law 2 overrides Law 1 if the human gives an overt command, on the grounds of robots not (yet) being better than humans at judging what will harm a human.
The transitivity works perfectly here. The bug was mine - I had added references for Tantawi's MP-ness to the existing WP-imported reference, instead of adding them as a separate reference. (They do happen to be the same.) I've fixed that, finding a higher quality reference to show that he was elected in 2015 (not at a later by-election, for example), directly from the electoral commission. I do have a new question, but I'll start a new subsection, since it's somewhat orthogonal. Boud (talk) 11:52, 13 November 2019 (UTC)

native_name, native_name_lang

How should these be handled via Wikidata and automatic Wikidata extraction? A complication will be the situation of people with multiple native languages in which their official or publicly used formal name is defined in parallel in the different languages and scripts - for these cases a list of native_name_lang values will have to be allowed.

Leaving that aside for the moment, it seems to me that native_name is useless in the Wikidata context, since a valid value in native_name_lang will be sufficient to select the name in that language. But we do in fact have d:Q12189043 - native name template, while we don't seem to have native_name_lang. Probably we should ignore native_name, or if it's non-null, then provide a warning that only native_name_lang and the main name of the wikidata element should be used. Or use it as a fallback if native_name and native_name_lang are defined and the latter is valid, but the main name of the element in native_name_lang is absent?

I think it would be useful to have some code that does the equivalent of the native_name function in the non-Wikidata infobox. Obviously, we don't want to print out native_name = ... in the rendered output - it could be considered derogatory in any country in which there's a risk of colonial interpretations, as if someone's native_name is not his/her real, civilised name in "our" language (whatever "our" happens to mean). My guess at the moment (looking at the code without testing) is that we would need to create the property native_name_lang (as a non-admin, I can only create elements, not properties). Boud (talk) 11:52, 13 November 2019 (UTC)

@Boud: The only help I can offer is to observe that Wikidata has a property, name in native language (P1559), which has the description "name of a person in their native language. Could be displayed in addition to the label, if language has a different script". It also has a property, native label (P1705), which has the description "label for item in its official or original language". Both of these are monolingual text, so can be rendered in whatever language and script is used for the statement on Wikidata. For example, fetching name in native language (P1559) for Vladimir Putin (Q7747):
  • {{#invoke:WikidataIB |getValue |P1559 |qid=Q7747 |fwd=ALL |osd=no}} → Владимир Владимирович Путин Edit this on Wikidata
I can't find an entity with multiple values right now, but WikidataIB has a full set of capabilities to render multiple values in whatever list format we have available. Let me know if the documentation at Module:WikidataIB/doc #Formatting multiple returned values and Module:WikidataIB/doc #Parameters to getValue doesn't make sense to you.
The "native label" is used almost exclusively for geographic locations, so fetching native label (P1705) for Japan (Q17):
  • {{#invoke:WikidataIB |getValue |P1705 |qid=Q17 |fwd=ALL |osd=no}} → 日本 Edit this on Wikidata
If you think that a particular infobox would benefit from having a new field to display a particular piece of information, then you should start a discussion on that template's talk page. You'll probably want Template talk:Infobox person in the first place if you're working with biographies. --RexxS (talk) 20:01, 13 November 2019 (UTC)
@RexxS: Thanks for finding that property (and native label). So I guess that this property P1559 needs to be added "by hand" to a wikidata element (unless a property native_name_lang is created and if that can use the name field for the element). This probably makes sense and is only a minor redundancy, since by default, none of the languages for an element are by default marked as the "native language". Most elements will not have a native language (e.g. physics, world, shoe, cat, tree). The parameter native_name is already part of the non-wikidata infobox person. I've updated the Infobox person/Wikidata code - this worked correctly for me from the sandbox and now looks OK live. You can see the effect at Ahmed Tantawi. This is not quite complete: it does not include the language code as a lang="ar" or whatever in the html element. If you know how to fix that, please do so; at the moment this is a (hidden) regression compared to the non-Wikidata version.
I agree that (at least at the moment) it would be more natural to propose new fields at the non-wikidata infobox talk page, not the /Wikidata talk page.
It's also my guess that at the moment, it would in general be pointless to create/propose a new infobox directly as a /Wikidata infobox, especially for the technical reason that an ordinary editor would first have to propose new properties to Wikidata, which would take at least a week to discuss and put in place. Do you (or anyone following this thread) agree?
I'm asking this new question because I've been sort of thinking of creating Template:Infobox peace process (we have an impressive amount of structured encyclopedic info about battles and wars in en.Wikipedia, and not too much concrete peace-process-related info or even articles (we do have Category:peace processes; and Category:peace mechanism with what I would see as the main parameters, with the armed conflict article that the peace process relates to being an obligatory parameter), and I had thought that it would make more sense to make the Wikidata version the default preferred version, with a non-Wikidata version only if someone cared to create one. This would be a new infobox template, so the risk of messing up big numbers of articles would be low if it started directly as a /Wikidata template and had bugs. However, it now seems to me more reasonable to first create it as a standard non-Wikidata template and let the /Wikidata version be created later. Opinions welcome. Boud (talk) 22:16, 13 November 2019 (UTC)

"archives at" property

There are over 20,000 people in Wikidata with the "archives at" property. Would it be possible to add this property as a parameter in the infobox? For many historical figures who have papers preserved by an archival institution, this is an important piece of information in a similar way as, for example, notable works and awards. Dominic·t 18:58, 3 December 2019 (UTC)

I don't object to it per se, but it seems like it would run afoul of MOS:INFOBOXPURPOSE for almost every article that could use it. – Jonesey95 (talk) 20:03, 3 December 2019 (UTC)
I'd suggest it'd be more valuable to link to the archives or a finding aid in the EL section. Nikkimaria (talk) 02:07, 4 December 2019 (UTC)

Nationality

At the moment the template is passing through P27 (country of citizenship) as a value for |nationality=. While in many cases the two countries will be the same, that is not universally true. Additionally, the overlinking issues discussed here are now back. Suggest disabling automatic fetching of this parameter. Nikkimaria (talk) 01:30, 14 November 2019 (UTC)

I agree. Please disable it. --RexxS (talk) 11:42, 14 November 2019 (UTC)
Done. Nikkimaria (talk) 12:35, 14 November 2019 (UTC)
I assume it should be OK to enable P27 for nationality, while keeping it disabled for citizenship. This seems to be the intention from the above discussions. The issue is that some countries (Russia? I think) have both "nationality" and "citizenship" concepts. So I'm enabling P27 for nationality. Feel free to revert if I've misunderstood. Boud (talk) 00:56, 29 November 2019 (UTC)
The problem remains that Wikidata is unable to distinguish between "nationality" and "country of citizenship". Take a look at d:Property talk:P27 for a complete shambles of confused definitions. As a practical example, this is what is returned as country of citizenship (P27) for Mahatma Gandhi (Q1001):
{{wdib |ps=1 |P27 |qid=Q1001}} → India
Are those sensible values for "Nationality"? I always thought Gandhi's nationality was "Indian". --RexxS (talk) 01:54, 29 November 2019 (UTC)
OK, so the idea is to suspend use of both nationality and citizenship until the mess gets sorted out :) - this seems reasonable; overrides can be used from Wikipedia while waiting for this to be tidied. For obvious historical/political reasons (world history/politics, not Wikipedia/Wikidata history), that could require quite a bit of work, which would include disambiguating various past and present situations in different countries.
Based on a quick look at the present lead of nationality, I would think that favouring citizenship by default, and allowing nationality as a replacement if citizenship is absent, would be reasonable. That lead argues that in the current world, there's essentially no difference between the terms, so the differences would occur for people (typically) at least a century or so in the past. Since the modern idea of nation-states caught on only a few centuries ago, more ambiguity could occur for older historical figures.
In the specific case of Mohandas Gandhi, describing him as Indian is reasonable as a descriptive term, but a more accurate result of using Wikidata should be, it seems to me, something like Indian (British Raj, 1869-1947; Dominion of India, 1947-1948). So in this case, this seems to me a problem in terms of Wikidata properties and the specific Infobox person/Wikidata template. It seems to me that we would need to have adjectives as properties associated with nation-states or historically older informally defined countries (like principalities or ethnic groups when no state existed in the place where that group mostly lived); and then the template would have to extract those adjectives. The template could, in principle, also check if the nation-state(s) have begin/end dates, and if those begin/end dates imply a conflict with the lifetime of the person, and if so, then there should be a constraint that requires years for those nationalities in order that the reader has a neatly set out explanation rather than being forced to sort things out him/herself). Not hugely complicated, but not completely trivial for wikidata newbies like me, who are unlikely to try coding that. Boud (talk) 03:15, 29 November 2019 (UTC)
One issue with privileging citizenship over nationality though is that {{infobox person}} does the opposite. Nikkimaria (talk) 11:39, 29 November 2019 (UTC)
That's because for many biographical figures their nationality is far more important to their notability than their citizenship. Carles Puigdemont is a Spanish citizen, but isn't notable for that – he's notable for being President of the Government of Catalonia. --RexxS (talk) 16:15, 29 November 2019 (UTC)
I agree that Puigdemont's role as having Catalonian identity, as a social construct with a hoped-for political nation-state recognised internationally aspect to the identity, is more notable than his formal Spanish nationality. But my understanding of English usage matches that of nationality (I didn't check wikt:nationality), in which an ethnic-identity that you and many others with you would like to formalise as an independent nation-state is not considered a nationality. How about the UK case as a useful guide? British nationality law. While about half (more or less) the people living in Scotland want independence, the other half don't, and in any case, at the moment, we cannot talk about Scottish nationality, even though there is clearly a Scottish ethnic identity, and a strong political/governmental structure. So it seems to me that the implicit proposal here would be that for the present epoch and last roughly a century, we should create/allow ethnic identity as a parameter - which I suspect could open a Pandora's box (with some people sliding towards... race) - that I wouldn't recommend opening. My guess is that in the case of a living person such as Puigdemont, we could invoke BLP and suppress the Spanish value from being shown, on the grounds that he (if there's a source stating this) considers himself not Spanish, and we respect the subject's preference to not be declared Spanish, but in the other direction, we would avoid saying that he "has" (or "is of") Catalonian nationality, because that would effectively mean that we claim the existence of Catalonia as a nation-state, which under international law it is not (AFAIK).
Regarding the UK case, see WP:UKNATIONALS. Nikkimaria (talk) 01:11, 30 November 2019 (UTC)
(edit conflict) Your understanding of nationality doesn't match its use in the real world. Nationality is a relationship of the nation to which a person belongs. You're quite wrong to think that we cannot talk about Scottish nationality. My nationality is English; Dylan Thomas's nationality was Welsh; Nicola Sturgeon's nationality is Scottish; and so on. We are or were all British citizens, but nobody would deny that each of Great Britain's constituent nations exist in their own right, nor that people are accepted as belonging to each of those. There's no need to make up a word like "ethnic identity" that isn't used in the sources. When we read that Ryan Giggs was a Welsh international footballer, we're not reading he was "an international footballer whose ethnic identity is Welsh"; we're reading that he was "a footballer who represented the Welsh nation internationally". We don't determine usage. We follow the usage in the mainstream sources. --RexxS (talk) 01:16, 30 November 2019 (UTC)
Further: this is very important. When you deny the existence of minority group which has traditionally seen itself as a nation, you enable the oppression of such minority groups. If you're so impressed by Wikipedia definitions, take a look at Nation, "a stable community of people, formed on the basis of a common language, territory, history, ethnicity, or psychological make-up manifested in a common culture." That article takes the time to explain the difference between an ethnic group and a nation. So, in answer to your implied question, yes, Catalonia is a nation, just as Scotland and Wales are nations. There is no doubt in most peoples' minds that Puigdemont's nationality is Catalan, even though he is a Spanish citizen. We should not be confusing those terms in our infoboxes. --RexxS (talk) 01:28, 30 November 2019 (UTC)
I think that WP:UKNATIONALS represents a wider consensus than our individual understandings of the "true" meaning of nation/nationality here. :) It's worded in terms of the UK, but I think it could reasonably be extended to other formal/informal ethnic groups and nation-states. Since Wikipedians' support for the idea of nationalism is likely to vary, our degree of confidence in the meaning of "nationality" vs "ethnicity" is also going to vary (I think this discussion shows that for a tiny number of editors!). I think that any resolution of the nationality/citizenship parameter issue in infoboxes will have to take into account the present consensus/advice at WP:UKNATIONALS (which seems reasonable to me) and preferably provide a convenient link to it for people who are editing and likely to be unsure. The idea would be to avoid edit wars and claims of "the true" solution. Boud (talk) 06:15, 30 November 2019 (UTC)
The case of UKian/British/English/Scottish/... completely escaped my mind on this issue. So is the idea that any persons for whom either nationality or citizenship is considered sufficiently notable for the infobox has to have that given as an override when using infobox person/Wikidata, as a deliberate editorial decision in the Wikipedia context rather than the Wikidata context?
I'm not convinced in terms of current well-accepted usage of the UKian ;) language that the situation is clear cut, although the existence of multiple meanings seems well-established. The adjective wikt:nationality does not necessarily have a one-to-one relationship with the noun wikt:nation. In terms of wikt:nationality, my understanding tends to follow meaning 1 (is everyone born in England necessarily English? can you naturalise to become English rather than British)? while the meaning that seems to be proposed here seems closer to meaning 2. Anyway, I don't want to continue this discussion ad infinitum; a yes/no answer would be welcome for my "So is... ?" question in the paragraph immediately above this one. Boud (talk) 23:15, 10 December 2019 (UTC)

Various problems at Agnes Geijer

At Agnes Geijer, I am observing various problems related to this template.

First, the string handling in "Occupation", possibly combined with an invalid entry in Wikidata, was causing the article to be placed in Category:Articles with missing wikidata information (note the lower-case w, presumably caused by the string handling). I removed the string handling as a workaround.

Second, when I removed the string handling as a workaround, and then fixed the apparently invalid occupation in Wikidata, her occupation still does not show. (There is not a non-Wikipedia source for her occupation, so it is valid that occupation is not shown.)

Third, the infobox is attempting to transclude the articles Oscars Assembly and Uppsala Cathedral Assembly and a template called {{Fetchwikidata}}, none of which exist, and which probably should not be transcluded.

It looks like either the template needs some debugging, or this person's Wikidata has some problems, or both. – Jonesey95 (talk) 15:33, 10 December 2019 (UTC)

I've restored the processing of 'Occupation' using the String2 function ucfirst. That should avoid the problems caused by the 'sentence' function, which renders the rest of the string in lower case.
Her occupation will not show because both of the given occupations are sourced to a Wikipedia. Wikipedias are not reliable sources and by default the code won't import values without sourcing.
The infobox uses calls to Module:WikidataIB. When no sitelink exists in the current wiki (as happens with Uppsala Cathedral Assembly (Q10710237) and Oscar Parish (Q10612973)), the code there takes the label (if it exists) and examines whether a redirect exists with that name on the current wiki. A side-effect of that examination is that an entry is made in the table of transclusions for the term representing the label. That has no concrete consequences as can be seen by checking Special:WhatLinksHere/Agnes_Geijer.
I can't find why there is a transclusion for a template called {{fetchwikidata}}, so I'll investigate further when I get a chance. Again, it doesn't show up in 'What links here'. --RexxS (talk) 18:25, 10 December 2019 (UTC)
I think the fetchwikidata template call was just due to a missing bracket, [6] has fixed it. Thanks. Mike Peel (talk) 19:04, 10 December 2019 (UTC)
Well done, all. I still don't understand the transclusion thing, and I don't know why checking Special:WhatLinksHere/Agnes_Geijer instead of Special:WhatLinksHere/Oscars_Assembly would tell us something useful, but it does not appear to break Agnes Geijer in any way, so I imagine it's fine for now. – Jonesey95 (talk) 21:09, 10 December 2019 (UTC)
@Jonesey95: My bad. I had meant to check Special:WhatLinksHere/Oscars_Assembly, but got distracted by the fetchwikidata issue and got the logic the wrong way round. Anyway, the transclusion doesn't count for anything (and it's actually an artefact of the way that mw:Extension:Scribunto/Lua reference manual #Title library was coded to re-use the table of transclusions so that it also keeps track of the title objects created). We probably shouldn't worry about it for now. Cheers --RexxS (talk) 23:42, 10 December 2019 (UTC)
@RexxS and Jonesey95:Although the connection is not obvious, it seems too much of a coincidence that supernova SN 2004dj now shows the same _w_ikidata category when it wasn't yesterday and hasn't been edited for weeks. Any ideas? Le Deluge (talk) 14:21, 11 December 2019 (UTC)
@Le Deluge: It's exactly the same problem. Template:Infobox astronomical event used the String2|sentence function, which renders the first character in upper-case and the rest of the text in lower-case. I've now changed that to String2|ucfirst, which only renders the first character in upper-case and solves the problem. Cheers --RexxS (talk) 16:17, 11 December 2019 (UTC)

Parents

{{wikidata infobox|qid=Q79678636}} Parents don't seem to be appearing in this infobox. See, for example, William Henry Jackson (priest) and Molly Blake Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 23 January 2020 (UTC)

Correct. At this time, the template is supposed to show only those Wikidata values listed in the "This template uses the Wikidata properties:" sidebar. – Jonesey95 (talk) 22:35, 23 January 2020 (UTC)
This infobox was created by taking {{infobox person}} and adding calls to Wikidata for some fields that had a direct equivalent as a Wikidata property. This was never finished as Mike got sick of the arguments and obstruction, and shifted his attentions to Commons. I don't think Wikidata has a "parents" property, does it? On the right is the equivalent {{wikidata infobox}} for William Jackson (Q79678636) and the nearest I can see is the field for mother (P25). The parents field still exists in this template, of course, so a local parameter can still be used to supply values exactly as in {{infobox person}}. Nevertheless, I've enabled father (P22) and mother (P25) for the field, so it will pick up values for those if |parents= isn't used. Maybe somebody will update the documentation? --RexxS (talk) 00:11, 24 January 2020 (UTC)
Thank you, RexxS. I've updated the documentation, but I wonder whether |mother= and |father= should be used, where only one value is available, and |parents= when both are? I can quite understand why Mike would put his efforts elsewhere, though! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:18, 24 January 2020 (UTC)

Some issues with this template

  • Sam Zeloof uses this infobox (with some local values), and has "Position held American" in the displayed infobox. I can't find anything in the article code or the Wikidata item that would case this, so I suppose it is something to do with the template? Same happens with Shashikala Dahal and Sara Szyber.
  • Ángel Viñas gives "Born 1941 (age 78)". There are no local values given for the age. If the date of birth is solely a year, no age should be given (or a range of two possible ages). Also happens with Eduardo González Calleja.
  • Sigrid Maurer, position held: "member of the National Council of Austria, Austrian Students' Association chairperson, member of the National Council of Austria, member of the National Council of Austria, member of the National Council of Austria": either the years should be given with the position, or each position should be only given once. The same happens with Michael Brand (composer).

And of course, it causes Wikidata vandalism to be visible on enwiki, like with the birth place of Melba Escobar. Fram (talk) 12:59, 13 November 2019 (UTC)

The position_held/nationality error was mine, sorry!- fixed;
The age calculation is a bug that used to exist in templates like {{Birth year and age}}. We added code to show a range of two possible years when no actual day of birth is provided. Something similar should be done here. – Jonesey95 (talk) 15:32, 13 November 2019 (UTC)
@Fram: I'm genuinely pleased to see you back with us, and thank you for illuminating those problems. I'll do my best to solve those that are within my power to do so.
In Sigrid Maurer (Q1618939), some information was given in three different statements. Consolidating them and deleting two has removed two of the duplicates – they even showed up on Wikidata as having issues, but of course it takes someone who is actually making use of the information to see how to fix the problems. I agree that the positions should be qualified with dates, so I've gone ahead and implemented that in the template.
In Michael Brand (Q64905707), the issue is not with position held (P39), but with occupation (P106), so I've also added the dates qualifiers for that field as well.
The vandalism on Melba Escobar (Q63041747) was disgraceful because it had been there for a month until you spotted it, Fram. Many thanks to Jonesey95 for reverting the vandalism. I suppose one way of looking at that is that the anti-vandalism resources of English Wikipedia are so much greater than those available on Wikidata that importing values from Wikidata to here is the surest way of countering vandalism on Wikidata. Which is a sad reflection on the state of affairs. I know that Fram and many others consider that to be a misuse of enwiki editors' time, and I have a certain sympathy with that view. It certainly shows that those who want to increase the amount of Wikipedia content imported from Wikidata have a lot of issues to contend with, beside mere technical ones, if they want to generate consensus for that to happen. --RexxS (talk) 20:38, 13 November 2019 (UTC)
Thanks. I have no issue with people correcting vandalism on Wikidata of course, it just is a problem that changes on Wikidata which directly affect an article here, don't get reported in the page history here (same goes for Commons, but we get less long-lived vandalism that way it seems). Not an issue anyone here or at Wikidata can solve though, it's something for the developers which has been raised years ago already. Fram (talk) 11:11, 14 November 2019 (UTC)
Fixed what seemed to be a bug, so now it will only try to calculate age at death if both date of birth and death are at least month precision. I believe a perfect solution would require access to the actual precision value, but I couldn't figure out how to do that with either Template:Wikidata or Module:WikidataIB. --Inteloff (talk) 05:49, 4 February 2020 (UTC)
@Inteloff: That seems to be a useful utility, so I've implemented a new function getDatePrecision in Module:WikidataIB. It takes the property-ID as the first unnamed argument and optionally the entity-ID as the |qid= parameter. It uses the current page if no qid is supplied. It returns the number representing the precision of the first best date value for the given property, or nothing if that doesn't exist:
The values are: 0 = 1 billion years .. 6 = millennium, 7 = century, 8 = decade, 9 = year, 10 = month, 11 = day
There's no easy way to always ensure you don't have to call it twice in a template like this: {{#if:{{#invoke:WikidataIB |getDatePrecision |P570 |qid={{qid|}}} }} | test value of precision }}. I could alter it to return something like -1 when the precision doesn't exist, but that only helps for tests less than a number. Let me know if you prefer that. --RexxS (talk) 17:15, 4 February 2020 (UTC)
I'm not sure but I guess blank is fine. I used the new feature to improve the calculation a bit, now it uses Template:age in years to calculate a range. But there are still a few issues, I added testcases for all those I could think of. Any of #date or any of the age templates that deal well with
  • Julian calendar dates
  • BCE dates
  • Month precision dates
? Also, is it possible to add to the WD module an option for dates specifically in a YYYY-MM-DD or YYYY format? --Inteloff (talk) 09:10, 5 February 2020 (UTC)
@Inteloff: The WikidataIB module already accepts |df=y (dateformat) to return just the year:
But did you specifically want it padded to 4 digits?
I've make a quick addition to the date handling routine in WikidataIB to allow |df=ymd
This one zero-pads each item by default, but that behaviour can be changed if needed. --RexxS (talk) 13:32, 5 February 2020 (UTC)
Just fixed month precision dates. Two things remain: what to do with sourcing circumstances (P1480) (circa and so on) ? Say "aged approx. X" for circa and avoid display for others? Other issue is BCE:
  • date of birth (P569) for Augustus (Q1405) (for calculation) {{wdib |ps=1 |P569 |qid=Q1405 |df=ymd}} → -0062-09-23 - Missing a minus in the beginning. And I'm quite sure that Template:age in years and Module:Age use Year_zero#Astronomers, so it needs an adjustment.
  • date of birth (P569) for Augustus (Q1405) (for calculation) {{wdib |ps=1 |P569 |qid=Q1405 |df=y}} → 63 BC - This one is fine for display, but it will probably cause problems if used for the case where either of the dates is not day precision, which expects something like "-0063". However I believe the better fix is improving the age calculation template.
  • date of death (P570) for Augustus (Q1405) (for display) {{wdib |ps=1 |P570 |qid=Q1405 |df=dmy}} → 19 August 0014 - A AD or CE and no padding would be nice. Best to change wikidataIB or use a data formatting template?
Also, Template:age in years doesn't seem to work for bce ymd dates. I suspect going there or into Module:Age and making a new template/improving of the many that there are already would be better than trying to adapt the infobox template to already existing templates.
@Inteloff: For approximate dates, I'd recommend adding them manually using a local parameter override. There are just too many possibilities to try to code it reliably.
Nevertheless, it's easy enough to make changes to new functionality, so we can play around with the ymd format dates to get what you want. But as soon as we look at the other three fromats, we are locked into the functionality provided by complex date because the module is in use on 50+ different language wikis, which may make use of different month names and scripts.
In the sandbox, I've amended the code to return a "year zero fixed" value for BCE dates:
I can't do much about changing the display for |df=y because it's already passing through Module:Complex date to internationalise. For example
That's the point at which it needs better handling in the age templates. Let me know when you think we're close enough to a solution for me to update WikidataIB from its sandbox. Cheers --RexxS (talk) 00:46, 6 February 2020 (UTC)

Date errors

@Inteloff: Recent edits at this template have put about 50 articles in Category:Age error (which is normally empty). I've looked at a couple and they are due to Wikidata dates being unsuitable for a template that is expecting a precise date. I've gone off attempts to parse Wikidata items because they have a "put anything you like here, someone else will figure it out" approach that is not compatible with passing data to a template. Any thoughts on how to fix this? Related discussion is at #Some issues with this template above. See Louise Stevens Bryant for example. He died on 29 August 1956 in one ref and 1959 in another. That cannot be parsed by a date template. Johnuniq (talk) 06:41, 6 February 2020 (UTC)

@Johnuniq: Thanks for the warning. The changes I made actually were meant to improve handling of imprecise dates(such as Born 1490 - Dead 1510 (Aged 19-20), but I forgot to check what happens if there's multiple ages listed. Solution is in my opinion very simple: If there's only one date at preferred or normal rank, which I believe is usually the case, use that date. Else, don't calculate age. --Inteloff (talk) 06:51, 6 February 2020 (UTC)
Made a temp fix for that issue, but some of those are actually caused either by mixing WD or by circa dates, which almost invariably are year precision dates, which the new system considers. Fix for the second is check the qualifiers, for the first I'm not sure, guess going page by page and adapting things? Manually setting age? --Inteloff (talk) 07:11, 6 February 2020 (UTC)
Thanks but per my above comment I'm not sure that trying to parse data designed to be unparsable is going to work. Is there a "do not display a value" setting that could be manually added to the birth or death dates in a template? Then fixing the article could wait until someone with knowledge of the topic investigates. Johnuniq (talk) 07:15, 6 February 2020 (UTC)
The problem is not birth or death dates themselves, it's the age calculation. Adding a manual option is a good idea yes. Although in general I don't see what data is designed to be unparseable? Isn't the whole point of Wikidata that data be machine accessible? --Inteloff (talk) 07:40, 6 February 2020 (UTC)
I'm a bit of a grump, as RexxS well knows. Wikidata is designed and operated by people who like collecting things but unfortunately they haven't got a programmer to work out how to make the data available in any useful way. Look at all the layers of pain you have had to apply just to get a date, and I think all of that is built on layers of pain that RexxS had to write in a module. There should be a function provided by Wikidata that a module can use to say "get a valid human-scale date (Gregorian calendar from say 2000 BCE onwards) or nil if you haven't got a single plain date". Another function could provide all of the weird stuff: circa, this date or that date, and so on. There is nothing to stop Wikidata from introducing new features that break modules we write when all we want is to know whether a particular person has a simple birth date that can be put in an infobox. Johnuniq (talk) 08:40, 6 February 2020 (UTC)
@RexxS:, could you please help? Could you tell why this doesn't work: {{#invoke:WikidataIB |getQualifierValue |P569| qid=Q7682000|pval={{wdib |ps=1 |P569 |qid=Q7682000 }} |qual=P1480 |name=sourcing circumstances |fetchwikidata=ALL }} →  ?
And getPreferredDate gets confused a bit if there's more than one date , one of which is not validly sourced, for example: Joseph Pletz (Q47067551) --Inteloff (talk) 08:00, 6 February 2020 (UTC)

I've gone through and dealt with the age errors. Nikkimaria (talk) 12:52, 6 February 2020 (UTC)

@Inteloff: When working with Wikidata, we always have to account for the possibility that anything we ask for may have multiple values. The getQualifierValue function needs the value of the property that the qualifier refers to, in case there are multiple property values. The value that is expected is the raw value stored in the database, which is okay for values that are strings and wikibase-entities, but hopeless for times and other datatypes. Basically, it's best not to use getQualifierValue, other than in very specific circumstances when you know the target value beforehand. The best way to retrieve a property qualifier normally is to call getValue with |qual=ALL and with |maxvals=1 if you suspect there may be more than one value.
Unfortunately for this case, the code already looks for when sourcing circumstances (P1480) has the value circa (Q5727902) and prefixes the date with 'circa' or 'c.' in the appropriate language. That means it skips P1480 when checking for qualifiers:
However, you can force it by specifying |qual=P1480:
and you can return just the qualifier by setting |qualsonly=yes (shortcut is |qo=y):
Optionally, if all you are trying to do is see whether the date returned is 'circa', you can just check whether the date returned begins with <abbr title="circa"> – or just <ab, which is enough to distinguish it from links that start <a href. Not that any dates are linked at present, but you never know what might happen in the future.
As for Joseph Pletz (Q47067551), he has two values for date of death (P570) which are of equal rank. There's no way to distinguish between them programmatically, so just pick one. It's the best you can do until somebody improves the Wikidata entry or sets a preferred rank for one of them.
  • {{wdib |ps=1 |P570 |qid=Q47067551}} → 30 March 1840, 1841
  • {{wdib |ps=1 |P570 |qid=Q47067551 |maxvals=1}} → 30 March 1840
Let me know if that doesn't work for you. --RexxS (talk) 16:04, 6 February 2020 (UTC)
@RexxS: Thanks for the tips about circa. On the other issue, yes I understand the cause of the problem, and I already fixed the calls to wdib (at least temporarily). The issue I still have is with your new getDatePrecision function. I think it's getting confused because it picks just one precision to return, without checking sourcing. So if I call wdib with "onlysourced=on| maxvals=1" on a page with multiple dates, one sourced and the other not, it may return the value of a different date than the precision from getDatePrecision. tl;dr: getDatePrecision needs a onlysourced parameter. --Inteloff (talk) 22:23, 6 February 2020 (UTC)
@Inteloff: I've made changes to getDatePrecision in WikidataIB/sandbox to implement |onlysourced=
It would be really helpful when requesting changes if you could give some examples of where problems occur. For rare cases like multiple birth dates, it time-consuming for me to scratch around trying to find examples to test with, so I'll leave that to you this time. --RexxS (talk) 23:44, 6 February 2020 (UTC)

Curiously little information displayed with this template

Hello,

I am surprise to see very little information displayed with this template in some biographies. For instance, Justin Bonaventure Morard de Galles only shows the name and image, dates of birth and death and place of death. Numerous informations are present and sourced in Wikidata, notably the place of birth.

Does anybody have an idea of the reasons for this to happen? Thank you very much in any case. Rama (talk) 19:06, 19 April 2020 (UTC)

@Rama: The template only shows referenced information, and imported from Wikimedia project (P143) doesn't count. Improve the sourcing, and the template will show more info here. Thanks. Mike Peel (talk) 19:12, 19 April 2020 (UTC)
Ah, splendid! I had not noticed the imported from Wikimedia project (P143) snag. Many thanks! Rama (talk) 19:17, 19 April 2020 (UTC)

Avoid items sourced only to Wikimedia projects

See e.g. Frederick Smith (entomologist), which lists as occupation "arachnologist", which is sourced to "imported from Wikimedia project Wikispecies" (but isn't even supported by our article). Can all things only sourced to an "imported from Wikimedia project" be excluded please? Fram (talk) 08:50, 4 June 2020 (UTC)

Another example of the same issue is Johann Andreas Wagner. Fram (talk) 08:55, 4 June 2020 (UTC)

@Fram: thanks for spotting those. It hadn't occurred to me that folks would use Wikispecies as a reference. I've now filtered out all wiki projects being used for references. You may have to clear your cache to see the fixes in the articles above. --RexxS (talk) 15:49, 4 June 2020 (UTC)
Thank you! Fram (talk) 07:16, 5 June 2020 (UTC)

Please don't duplicate the name / native name

See Alan Heusaff. His native name is Alan Heusaff as well, which is correct but shouldn't be reduplicated here in that case. Removing it on Wikidata would be wrong, as it may be useful information for other languages. Such duplicates should be suppressed in the template here. Fram (talk) 12:38, 4 June 2020 (UTC)

Perhaps Mike Peel will be able to look at that. --RexxS (talk) 16:49, 4 June 2020 (UTC)
 Done [7]. I'm not sure how much I want to contribute to the discussions here right now, though, given four new sections suddenly posted here, accompanied by removals of this template and edit wars in articles. Mike Peel (talk) 17:16, 4 June 2020 (UTC)
"Four new sections suddenly posted here" is a problem because...? If there are still many issues with this template, then there will be many sections here. I'm not demanding that some new functionality gets implemented immediately, I'm raising some existing bugs and asking people to take a look and correct them if and when they can. "Removals of this template" is an issue because...? I guess you are referring to some of my edits, where I replaced (not removed) the /Wikidata version with the standard version, whic should not be problematic (and for which I gave reasons in each case). "Edit wars" = 1 edit war, already over, over one issue. You don't have to contribute to discussions (but are of course free to do so), but your arguments for this are not really convincing. Fram (talk) 07:22, 5 June 2020 (UTC)
But thank you for fixing this issue. Fram (talk) 07:24, 5 June 2020 (UTC)
From past experience, this pattern of rapid criticism of the way that the template works, followed by its removal in various articles, tends to indicate an impending deletion discussion. I don't want to waste my time developing a template and implementing it in articles only to see the edits to the articles reverted and the template deleted. If you can reassure me that this isn't where these discussions are heading, then I will be more willing to spend time developing this template and fixing issues. Thanks. Mike Peel (talk) 19:07, 5 June 2020 (UTC)
At the moment, I have no intention of nominating this template for deletion. Fram (talk) 06:34, 8 June 2020 (UTC)

Jean-Michel Huon de Kermadec: place of death is Balade (New Caledonia). It exists on Wikidata, without an enwiki link (correctly). So why is it then linked in his infobox here to the redirect Balade? Fram (talk) 10:19, 4 June 2020 (UTC)

On his Wikidata entry, I see "Balade", so that is what is linked to here (Balade, a disambiguation page). It looks like someone either needs to update Q2880407 (Balade) to link to a nonexistent en.WP page, or change Balade to be a redirect to a nonexistent en.WP page. – Jonesey95 (talk) 14:41, 4 June 2020 (UTC)
No, if you actually click on the link in Wikidata, it doesn't go to "our" Balade page, but to a different, unrelated one. Wikidata doesn't use diambiguations, so simply the name of a page says nothing (well, not enough) about the actual subject. Fram (talk) 14:45, 4 June 2020 (UTC)
Jean-Michel Huon de Kermadec now has his place of death at Balade, New Caledonia. The Wikidata sitelink and the redirect Balade now point there. All of the other titles on the dab page are spelled "Ballard" with a double-l. --RexxS (talk) 16:47, 4 June 2020 (UTC)
As is too often the case, when an issue is raised here, the incident, the anecdote is solved; the underlying issue is ignored. When you get a value from Wikidata, then the link added to it should be the same as the enwiki link for that value on Wikidata (or no link if no enwiki article exists). Adding a wrong link, as was done here, should not happen. Fram (talk) 07:18, 5 June 2020 (UTC)
@Fram: Unfortunately, there is not a 1-to-1 mapping of enwiki articles and Wikidata entries.
Where there is such correspondence (the majority of the time), I'm unaware of any problems as the code uses the robust sitelink from Wikidata to construct what is linked and displayed.
Where there is a Wikidata entry but no Wikipedia article (far less common), the unlinked Wikidata label in English is used if it is available. This is less than ideal because of vandalism, but generally this gets spotted fairly quickly and corrected.
Part of the problem with labels is that sometimes we have a Wikidata entry, for example egyptologist (Q1350189), but the enwiki article for the profession Egyptologist is actually a redirect to the study Egyptology and Wikidata doesn't want to link to redirects, so we have no sitelink, but a label that is the same as the title of a redirect on enwiki. In those cases (not very common) the code creates a link to the redirect and displays the label. That works almost all of the time for those uncommon cases.
Unfortunately, in a very rare set of cases, a redirect has been created that points to a disambiguation page. That produces the unwanted result that you raise above. However, since redirects to dab pages are almost always useless, I've been able to provide a bespoke fix every time anybody has raised the issue (which is not at all common).
If we took your line, then we would have no links to any article that is referenced via a redirect (for example a lot of professions), which would be a disservice to our readers. My opinion is that it's worth my time fixing the anecdote because it's so rare, in order to offer them relevant links even if it is via a redirect. YMMV. --RexxS (talk) 00:17, 9 June 2020 (UTC)

Media legend in other languages

Please don't show the caption (the "media legend" in Wikidata speak) when it is in another language than English. See for example Caroline Vigneaux for a current example. Yes, I know, this example, any example, can be changed by adding an English caption. But that's not the point, the issue is that until that is done, no caption should be shown here. Fram (talk) 07:16, 2 June 2020 (UTC)

Other example, better illustrating the problem: Karine Le Marchand, with the caption "Karine Le Marchand à la manifestation en faveur du mariage homosexuel en France, à Paris, le 27 janvier 2013." Fram (talk) 07:18, 2 June 2020 (UTC)

I thought that when the information fetched from Wikidata was inappropriate, it was normal to supply a local value? Adding |caption=Caroline Vigneaux in 2018 and |caption=Karine Le Marchand at a demonstration in support of gay marriage in France, Paris, 27 January 2013 to the respective infoboxes would be the usual course of action, I believe. Optionally, the captions could be added to Caroline Vigneaux (Q2940075) and Karine Le Marchand (Q3193297), of course, but that's not necessary. --RexxS (talk) 21:16, 2 June 2020 (UTC)
No, the usual course of action is to prevent this infobox from fetching the wrong captions in the first place, since these (images and captions) can be added at Wikidata after the infobox has been placed here, meaning that whoever placed the infobox, even if they checked this issue at the time, can not prevent this happening afterwards. Fram (talk) 06:53, 3 June 2020 (UTC)
If data changes on Wikidata, anyone with the article on their watchlist can see the change. The only time that doesn't happen is when the infobox is first placed, and the onus to ensure the information is correct then falls on whoever adds the infobox. Both of those scenarios are fully equivalent to what happens with infoboxes that do not draw data from Wikidata. We delegate the task of ensuring information is correct on Wikipedia to humans when the information is added locally, so why would we not expect an editor to realise what a "wrong caption" is? --RexxS (talk) 17:09, 3 June 2020 (UTC)
I found that showing Wikidata changes on my watchlist is impractical. There are so many bot and trivial changes that they overwhelm my watchlist. I don't think that bot changes on Wikidata only can be excluded from the watchlist. -- Michael Bednarek (talk) 02:02, 4 June 2020 (UTC)
Indeed. Knowingly allowing unwanted information to be added to our articles because a local editor can perhaps see it on their watchlist and then can suppress it again is not the way to go if you want templates like this to get widely accepted. Just like unsourced information isn't welcome on enwiki, so should information in other languages not be automatically added either. We did the same for Qnumbers, suppressing these from appearing in this infobox as well (e.g. when an occupation had no English label). Automation like this should make the life of editors easier, not harder. Fram (talk) 06:52, 4 June 2020 (UTC)
Apparently we didn't remove the Qnumbers from this template either though, it turns out, as e.g. Shigeru Kayano displays two of those. Can this please be solved as well? Saying that someone was educated at Q24887554 and won the Q11413087 in 1989 is not really helping anyone here and just looks stupid. Fram (talk) 07:53, 4 June 2020 (UTC)
Of course we didn't. We put them in Category:Articles with missing Wikidata information and periodically empty it. I'll do that this evening, as promised, unless someone beats me to it. --RexxS (talk) 15:17, 4 June 2020 (UTC)
If you can detect them (which is necessary to put them in a category, no?), then why can't you hide them at the same time? I have no objection against the category of course, nor against people emptying it; but neither is an excuse to show the Qnumbers in the meantime. No idea why this would be an "of course we didn't" and not an "oh shit, we forgot". Fram (talk) 15:30, 4 June 2020 (UTC)
Indeed, sufficiently trivial that I was able to implement a quick (and somewhat hacky, since it still shows a "edit on Wikidata" pencil icon) fix in Template:Infobox person/Wikidata/sandbox in less than 10 minutes. * Pppery * it has begun... 15:54, 4 June 2020 (UTC)
@Fram: Yes, they are detected, but if it doesn't display anything, nobody knows what needs to be fixed. It would just make a lot of detective work for anyone improving the content on Wikidata. The issue was discussed to death already and left as is once the tracking category was implemented. If you just want to be ignorant and insulting, go find another target.
@Pppery: it would be even more trivial to change line 644 in Module:WikidataIB to set disp = i18n.missinginfocat, but I don't see good reason to do so.--RexxS (talk) 20:00, 4 June 2020 (UTC)
I wasn't insulting (or please explain to me how "of course we didn't" is not insulting, but "oh shit, we forgot" is?), but you seem to insist to not only take offence, but escalate it with "if you just want to be ignorant and insulting", which is a direct personal attack. Please strike it. Fram (talk) 07:15, 5 June 2020 (UTC)
There was considerable discussion in the past about the issue, and having thought it settled, I felt unfairly attacked by your "Apparently we didn't remove the Qnumbers from this template either though" (the "We" meaning me). So who started the personalisation? If you don't want to end up exchanging escalating insults, you need to stop going down that road in the first place. Who's going to strike first? --RexxS (talk) 19:18, 5 June 2020 (UTC)
That was not intended as an attack on you (or anyone else for that matter), I honestly thought that earlier discussion had settled that Qnumbers should not appear in this template (just like they are unwanted in the body of an article), but apparently I misremembered and we (the people discussing this template) did not remove it after all. Fram (talk) 06:36, 8 June 2020 (UTC)
@Fram: You were not the only one who didn't want Q-numbers displayed to readers. If I can figure out a way to suppress their display for enwiki but leave the tracking category, would that be an acceptable compromise in your view? I'll take a look tomorrow and do my best to make that happen. --RexxS (talk) 00:24, 9 June 2020 (UTC)
That would be perfect, thanks. Fram (talk) 06:34, 9 June 2020 (UTC)
@Fram: I've amended the code in the module sandbox to suppress the Q-numbers. I've also suppressed the pen icon if the only content is the tracking category:
  • {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |rank=p n |P527 |qid=Q4115189}} →
  • {{#invoke:WikidataIB/sandbox |getValue |fwd=ALL |osd=n |rank=p n |P527 |qid=Q4115189}} →
  • {{#invoke:WikidataIB |getValue |fwd=ALL |osd=n |rank=n |P527 |qid=Q4115189}} →
  • {{#invoke:WikidataIB/sandbox |getValue |fwd=ALL |osd=n |rank=n |P527 |qid=Q4115189}} →
If you look at the bottom of the page, you'll see it has been placed in Category:Articles with missing Wikidata information.
I think that gives the result we want, although it needs to be tested in infoboxes. The worst that can happen is we get a label with a blank value (because it's the tracking category). I want to make reasonably sure that there are no bugs before I update the main version to the sandbox version, so please bear with me while I try to do some more tests. --RexxS (talk) 23:14, 9 June 2020 (UTC)

Pppery, thanks. Fram (talk) 07:15, 5 June 2020 (UTC)

Qualifiers

@Mike Peel: While your later revision is better than the ALL option, I think the original date presentation was more reader friendly - it presented dates as [start date]–[end date], making it clear that it's a range, while this version presents dates as [start date], [end date], meaning it is not as clear what the dates represent. Nikkimaria (talk) 20:52, 27 May 2020 (UTC)

@Nikkimaria and Mike Peel: Without prejudice to either outcome, don't forget that the |qsep= parameter allows some degree of customisation if it helps to change the default ", " to something else (and sometimes |qprefix= and |qpostfix= come in handy as well). Cheers --RexxS (talk) 21:34, 27 May 2020 (UTC)
@Mike Peel: would that work for what you're intending? Nikkimaria (talk) 18:38, 31 May 2020 (UTC)
Sorry, I missed this discussion, I thought this was resolved by using the specified qualifiers. The case I was looking at was Derek McNally, where the organisation where the position was held was relevant and not displayed. It now displays "secretary (International Astronomical Union, 1988, 1991)" - which is better than "secretary (1988-1991)". I don't think a standard separator would help here - @RexxS: we've talked before about always including the dash between start/end dates, even with different sets of qualifiers rather than just DATES, would that be possible? Thanks. Mike Peel (talk) 18:50, 31 May 2020 (UTC)
@Mike Peel: It's possible, but a lot of work given the multiplicity of ways in which a list of qualifiers could be supplied. Do you want to see (1988-) and (-1991) if there is just one start/end date? It would need the table of qualifiers to be scanned and then start and end dates extracted and dealt with separately. That section needs a re-write anyway, so I'll take a look at it. --RexxS (talk) 19:17, 31 May 2020 (UTC)
I suspect that @Nikkimaria: cares about the exact formatting here a lot more than I do, so may be the best placed to provide input here. Thanks. Mike Peel (talk) 19:20, 31 May 2020 (UTC)
That seems reasonable, if it's possible. Thanks for looking into that RexxS. Nikkimaria (talk) 19:48, 31 May 2020 (UTC)

[Update] @Mike Peel and Nikkimaria: Turned out to be even more work than I anticipated. Nevertheless, I have what I think is a working version of the new code in Module:WikidataIB/sandbox:

  • It deals with "DATES" as just a shortcut for "P580, P582".
  • It renders the results from a list of properties (which can include DATES) in the same order as the list is given, except P580/P582 are placed at the end with an ndash separator (qsep is used for the other separators).
  • If only one of P580 or P582 are present or requested they are rendered with a trailing (P580) or leading (P582) ndash.
  • P1326 and P1319 are trapped and rendered as "before <date>" and "after <date>" but in the order given in the list.

I've got some test cases at Module talk:WikidataIB/sandbox/testing #Getting value and qualifiers but as it's a big rewrite, I can't be certain I've anticipated every possible combination of input and data. It really would benefit from a sizeable amount of testing before rolling out as production code. All feedback and testing results are most welcome. --RexxS (talk) 22:18, 1 June 2020 (UTC)

Testing:

Property-ids, DATES, etc, are case-insensitive. --RexxS (talk) 22:27, 1 June 2020 (UTC)

Thanks! As previously, I don't think ALL would be the best choice for this template, but the second test example looks great. Nikkimaria (talk) 22:44, 1 June 2020 (UTC)
@Nikkimaria: when the sandbox version goes live, |qual=DATES; P642 will be same as |qual=P642,P580,P582 (and any combination of punctuation characters and whitespace already work in the live code), but I'm very hesitant to make it live until we've all had a good chance to find any bugs in the new code. Thanks for helping out; it's really appreciated. --RexxS (talk) 00:34, 3 June 2020 (UTC)
[Update]: The code is now live as I've done all the tests I can think of. You should be able to get more specific displays of qualifiers now. --RexxS (talk) 15:42, 14 June 2020 (UTC)

Stated as

d:Q100875779 has Award received="Knight Commander of the Order of the British Empire (Q12201445)", qualified with: Stated as="Knight Commander of the Most Eminent Order of the Indian Empire" and the template displays this on Colin Campbell Garbett as:

[[Knight Commander of the Order of the British Empire]] (1941, Knight Commander of the Most Eminent Order of the Indian Empire)

whereas it would be more sensible to display this as:

[[Knight Commander of the Order of the British Empire|Knight Commander of the Most Eminent Order of the Indian Empire]] (1941)

The same would apply to "named as" qualifiers, and both forms may apply to a number of parameters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:13, 29 October 2020 (UTC)

Age at death error

In, for example, this version of an article an error is caused by a locally-specified |birth_date=1967 or 1968 (not an uncommon use-case); presumably the template is attempting to use this to calculate the age at death. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:17, 21 April 2020 (UTC)

Anyone? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:27, 21 June 2020 (UTC)
The documentation for birth date says date of birth (P569) (can use qualifier sourcing circumstances (P1480) -> circa (Q5727902) if needed), but that is Wikidata gibberish to me. It implies, but does not state, that if "circa" is used somehow, the date calculations should be affected, but I do not see any indication in the code that there are any such effects. An example of how to use that qualifier in the infobox would be helpful, and better error handling than this template and {{age in years}} currently provides may be needed. – Jonesey95 (talk) 16:11, 22 June 2020 (UTC)

@Inteloff: I think you wrote the current version of the birth/death code, can you look into it please? Also, at Darach Ó Séaghdha there is date of birth: 20th century, which is erroneously returning 'age 119'. Thanks. Mike Peel (talk) 10:24, 10 July 2020 (UTC)

Actually, it's fixed now, thanks to @RexxS:'s off-wiki assistance. Also, @Pigsonthewing:, the error you were finding should also be fixed. Thanks. Mike Peel (talk) 17:08, 10 July 2020 (UTC)
@Mike Peel: It doesn't seem fixed, see Francisco Antônio de Almeida Júnior. ~★ nmaia d 15:37, 16 November 2020 (UTC)

Encountering "(aged Error: Need valid year, month, day)"

I attempted to add this template to Gisela of France. However, the resulting infobox had the following for the death field: "c. 920 ✎ (aged Error: Need valid year, month, day)". I expected it instead to not try to calculate an age, since both the birth and the death date are circa. Since I didn't want to leave the article in a bad state, I chose not to save the edit. If this bug could be fixed, I would be obliged. -Thunderforge (talk) 02:16, 1 December 2020 (UTC)

@Thunderforge: Any field in the infobox can be overridden by supplying a local parameter, for example |death_date = c. 920. I made a temporary edit to Gisela of France to demonstrate the use of a local parameter when the Wikidata value causes an error. --RexxS (talk) 01:16, 2 December 2020 (UTC)
@RexxS: Thank you for telling me about that override. Is it better to wait until the bug is fixed, or to use the override (perhaps adding a comment explaining why it's used)? Not sure what the best practices are with this template. -Thunderforge (talk) 02:07, 2 December 2020 (UTC)
@Thunderforge: the template calculates the age at death by making some assumptions about what might be returned from Wikidata. It's not yet sophisticated enough to deal with those "circas" and will probably need quite a bit more work to catch all the possible edge cases, and the coder(s) are unlikely to see that as priority right now. So, for the moment, I recommend using a local value for any parameter that displays poorly when fetched from Wikidata. Template:Infobox person/Wikidata supports all of the parameters that Template:Infobox person does (it just doesn't need them, most of the time). Cheers --RexxS (talk) 02:26, 2 December 2020 (UTC)

The problem is that this infobox calls {{age in years}} which uses Module:Age. For Gisela of France, I think the effect would be to call {{age in years|0895-00-00|0920-00-00}} which would give the error message because -00-00 specifies an invalid month and day. That could be fixed with any of the following:

  • {{age in years|0895|0920}} → 24–25
  • {{age in years|0895|0920|range=no}} → 25
  • {{age in years|0895-01-01|0920-01-01}} → 25
  • {{age in years|0895-00-00|0920-00-00|fix=on}} → 25

Using fix=on is dubious because it regads zero as "minus one unit"; {{extract}} shows the result:

  • {{extract|0895-00-00|fix=on}} → 30 November 894
  • {{extract|0920-00-00|fix=on}} → 30 November 919

That's sort-of ok if both dates have the same 00 problem but could conceivably give an off-by-one error otherwise. Johnuniq (talk) 02:46, 2 December 2020 (UTC)

Thanks, John. I encountered the "00-00" issue when developing Module:WikidataIB and use this Lua code around lines 353-357 to fix it:
  • timestamp = timestamp:gsub("%-00%-00T", "-01-01T")
Perhaps Module:Age would benefit from a similar fix? The code above sets the month and day to 1 January, but 2 July ("-02-07", the midpoint of the year) might be better for use in age calculations. --RexxS (talk) 11:58, 2 December 2020 (UTC)
Hey RexxS, surely you know it's a feature not a bug!? It emulates {{#time}}. Behold:
  • {{#time:j F Y|0895-00-00}} → 30 November 0894
A complication is that the module can receive the date in various formats (dmy, mdy, ymd or separate parameters using y|m|d or year=N|month=N|day=N). There could be some logic which checks for -00-00 in the birth date and the death date. It could do the right thing for that particular case. But then there would be a case where one has a month (or a month and day) and the other doesn't. Ugly. Johnuniq (talk) 03:57, 3 December 2020 (UTC)
It's a bug for me, John. If somebody adds a date as a year (for example, 1872) on Wikidata, then it's stored as a timestamp that looks like this: "+1872-00-00T00:00:00Z". If you pass that to something like the standard php time parser strtotime() – as I believe lang:formatDate('Y', timestamp) does – it interprets the 00 for month and day as the values before 01 (as you pointed out above). That date is before 1 January 1872, and that is in the year 1871, so the value for the year returned is 1871, not 1872:
{{#time:Y|+1872-00-00T00:00:00Z}} → 1871
However, if someone has stored the date previously with day precision, and later the precision is changed to year, then we subsequently get the correct year returned. The Wikidata entity display looks just the same, but the underlying timestamp stored is different, and we get a different (correct) returned value for the year from the parser function:
{{#time:Y|+1872-01-01T00:00:00Z}} → 1872
I can't imagine a scenario where it's useful to store 1872 and retrieve 1871 some of the time. I just find it easiest to turn all timestamps into valid dates at the earliest opportunity and never run the risk of encountering the "features" that {{#time}} provides. Cheers --RexxS (talk) 16:24, 3 December 2020 (UTC)
The age templates use Module:Age which uses Module:Date for date parsing and date calculation. Module:Date provides the ability to do date arithmetic with |fix=on and it does that in a way that is compatible with {{#time}}. I forget why I added it or why it is not documented, but Module:Date also decodes Wikidata timestamps although the module has no concept of Wikidata's date precision.
With {{age in years}}, |fix=on is needed if an invalid date should be "fixed" (by adjusting the date forwards or backwards). Zero fields in a Wikidata timestamp are not regarded as invalid. Also, |range=no is needed to avoid it giving a range of possible ages. Examples:
  • {{extract|+1872-00-00T00:00:00Z}} → 1872
  • {{age in years|+0895-00-00T00:00:00Z|+0920-00-00T00:00:00Z}} → 24–25
  • {{age in years|+0895-00-00T00:00:00Z|+0920-00-00T00:00:00Z|range=no}} → 25
  • {{age in years|+0895-04-00T00:00:00Z|+0920-05-00T00:00:00Z}} → 25
  • {{age in years|+0895-04-00T00:00:00Z|+0920-03-00T00:00:00Z}} → 24
  • {{age in years|+0895-04-00T00:00:00Z|+0920-00-00T00:00:00Z|range=no}} → 25
Johnuniq (talk) 23:49, 3 December 2020 (UTC)
The problem with regarding zero as valid values for month and day in a timestamp is that they give erroneous results when used with any standard library (C, php, mediawiki, etc.). That means that every piece of software using such timestamps has to apply a "fix" to correct the error, which is a waste of resources, IMHO. It's nice to have a value that indicates "month and day are unknown", but what use is ever made of that? From my point of view, the problem is compounded by the fact that Wikidata editors can store a timestamp on Wikidata in either a fixed or unfixed format with no indication of which is stored. The issue in this template is not only that it calls {{age in years}} without |fix=on twice in the data14 field for dead people, but it does its own calculation for living people in the data10 field. --RexxS (talk) 15:19, 4 December 2020 (UTC)
I have ranted before how Wikidata is a write-only database where no one has thought about how data might be used and where every tiny operation might lead to a run-time error. Re zero month/day, #time behaves the way it does because it uses the PHP mktime function. Module:Date regards a Wikidata timestamp as valid even if it contains a zero month or day. However, if found, zero is interpreted as "missing" which results in what Module:Date calls a partial date. That is, the module does not allow zero for a month or day, except to indicate a partial date (year only, or year and month only). That allows the module to give the results shown above where it knows the age is 25 if the person died in May but 24 if they died in March. Re this template, I hate complex template syntax and am not volunteering to refactor it. If someone braver than me has time for that, they could think about whether to pass the entire timestamp to the age template. I can't even handle parsing the wikitext for data10. Johnuniq (talk) 02:39, 5 December 2020 (UTC)

Implausible age

On Colin Campbell Garbett (born 1881, cited on Wikidata; died 1975, included but not yet cited on Wikidata) the template shows "age 139". The item is d:Q100875779. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 29 October 2020 (UTC)

I tested it today and the age was displayed as 91, which matches the Wikidata entry saying he died in 1972. So I suppose that means the error is fixed. -Thunderforge (talk) 02:20, 1 December 2020 (UTC)
That's because in the meantime, we've found full dates for Garbett and added them to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:21, 1 December 2020 (UTC)

Another case

Marcelle Lender (edit | talk | history | protect | delete | links | watch | logs | views) is certainly setting a world record for longevity. I noticed a couple of things about her Wikidata entry: (1) her birth year is not a full date, which should disable the calculation according to documentation here. (2) her death date is full, but completely unsourced, which should also disable the calculation. So why are we still making the calculation in the face of these inaccuracies? 2600:8800:1880:68:5604:A6FF:FE38:4B26 (talk) 17:41, 12 June 2021 (UTC)

fetchwikidata

Is it possible to display the information by default even if the fetchwikidata parameter does not have any values?--Épine (talk) 03:16, 19 July 2021 (UTC)

Model effectiveness

Hello everyone. How could it be that the model gives so little information, while it seem to be very effective in other languages such as French and Spanish?

For instance, see Jacques Chevalier, fr:Jacques Chevalier (philosophe) and es:Jacques Chevalier (filósofo). Why is there not more lines in the infobox in English?

83.228.175.86 (talk) 19:50, 29 December 2020 (UTC).

Most of the information in the French version is added locally. The Spanish version does not require that information be sourced, while the version here does. Nikkimaria (talk) 20:14, 29 December 2020 (UTC)
Requiring sourced data is all very well, but Adam Loftus, 1st Viscount Loftus (sourced date of birth 1568, unsourced date of death 1643) is described as 643 years old. jnestorius(talk) 12:52, 31 January 2021 (UTC)
See #Implausible age above. I've fixed this case by adding a source for the date of death. Nikkimaria (talk) 14:32, 31 January 2021 (UTC)
Nikkimaria, which line of code forces this if I may ask? Épine (talk) 09:18, 21 July 2021 (UTC)
data10. Nikkimaria (talk) 13:11, 21 July 2021 (UTC)

fair use image

When there is only a fair use image could this be included and spliced in to the wikidata based info? Victuallers (talk) 07:59, 7 September 2021 (UTC)

Yes, you can add it locally. Just do it as you would normally. Nikkimaria (talk) 12:06, 7 September 2021 (UTC)

Poor formatting of dates

About 1 in 2 pages that use this version of the infobox and have dates in it, have display issues, e.g.

No idea what is causing it or what the difference is with pages without this issue. Fram (talk) 08:38, 7 September 2021 (UTC)

@Fram: They look fine to me, I don't see the stray ' at all. Can you check again? Thanks. Mike Peel (talk) 10:05, 7 September 2021 (UTC)
I saw them at Jesús Vaquero when Fram posted the above. Now they're gone. -- Michael Bednarek (talk) 10:24, 7 September 2021 (UTC)
Gone at Vaquero, still there at Fenwick. Weird... Fram (talk) 10:39, 7 September 2021 (UTC)
@Fram, Mike Peel, and Michael Bednarek: See Wikipedia:Village_pump_(technical)#Date_formatting_and_WikidataIB. Nikkimaria (talk) 12:06, 7 September 2021 (UTC)
Thanks. Fram (talk) 12:40, 7 September 2021 (UTC)

Severino Albarracín

Any ideas why this article's infobox isn't showing any parameters besides the image? czar 08:40, 27 December 2021 (UTC)

Because information that is unsourced or sourced only to Wikipedia, other than images, is not passed through. Nikkimaria (talk) 13:33, 27 December 2021 (UTC)
I know that's the default but |onlysourced=no is set, so shouldn't those parameters pass through? czar 15:10, 27 December 2021 (UTC)
No - other than a few parameters such as image or signature, information must be sourced in order to appear. Nikkimaria (talk) 15:58, 27 December 2021 (UTC)
Thanks. I'll update the documentation to reflect this. czar 16:58, 27 December 2021 (UTC)
Resolved

Alma mater

As per the documentation for the main template, |alma_mater= is kept deliberately concise, listing only the institution. If there is a concern about ordering being unclear, that would be better addressed by changing the ordering rather than adding to the display - although it does not appear to be the case that this parameter is listed alphabetically but rather based on statement order at Wikidata. Nikkimaria (talk) 04:02, 28 February 2022 (UTC)

Agreed, but this template is still so error-filled that it is hardly worth complaining about an additional issue. David Aikman had "Born 1944 (age 78)" while it either shouldn't have an age, or an age range. I removed the infobox. On Walter Wangerin Jr., the infobox listed him as alive, the article as dead... Johan Falkberget has an infobox which doesn't even list his main reason for notability, being a writer (the same happens on many of these Wikidata-fed infoboxes). Adrian von Bubenberg: we have the date of birth "c. 1434", on Wikidata it is a certain, fixed 1434, and they have it sourced to the GND, which states... 1424.[8]. Infobox removed here as well. Fram (talk) 14:28, 28 February 2022 (UTC)
Another toxic discussion. Nope. Mike Peel (talk) 08:52, 2 March 2022 (UTC)

Potential age errors when only year is available

For some reason, this template tries to reinvent the wheel when calculating age. See this revision for an example. Someone born in 1944 could be either 77 or 78 in 2022, depending on when their birth date falls in the year. This template should use {{birth date and age}} (if living) or {{birth date}} (if dead), per the instructions at {{Infobox person}}, since those templates account for this age ambiguity. – Jonesey95 (talk) 22:37, 18 May 2022 (UTC)

Stated as

The infobox in Daphne Padden currently displays:

Alma mater Rosebery School for Girls
          Surrey Institute of Art & Design

but the prose has this as:

[[Rosebery School for Girls|Rosebery County School]] and at [[Epsom & Ewell School of Art]]

with the latter link being a redirect to Surrey Institute of Art & Design.

In Wikidata these are represented as:

  • Rosebery School - object stated as - Rosebery County School
  • Surrey Institute of Art & Design, University College - object stated as - Epsom & Ewell School of Art

The template should recognise the qualifiers, and display them using piped links. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:55, 14 August 2022 (UTC)

Circa birth date causes error

The template fails on Pierce A'Court-Ashe, with "Error: Need valid year, month, day)", presumably because the birth date is "circa 1707". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 1 January 2023 (UTC)

What to do when there are more than one qid?

Greetings to all you great wikipedians out there :-) I want to utilize the {{Infobox person/Wikidata | fetchwikidata=ALL}} for a person who I have discovered has two entries on Wikidata (QIDs). One of the entries is associated with more information than the other. Is there somehow a way to "direct" the fetch to the preferred QID? Picturesqua (talk) 13:11, 23 June 2023 (UTC)

In case you haven't done it already, you should merge the QUIDs so that there is only one QUID for the person (Tools > Merge with). David Nind 11:50, 22 August 2023 (UTC)

Suppression error

On Mark Farrow, I attempted to suppress birth_date as it is unsourced, which was successful, but the template continued to show age. Other than manually creating an infobox template, can age be automatically suppressed should the birthdate be eliminated?☾Loriendrew☽ ☏(ring-ring) 19:24, 27 October 2023 (UTC)

Unsourced? What about MoMA where Wikidata gets it (1960) from? What's wrong with that? -- Michael Bednarek (talk) 00:53, 28 October 2023 (UTC)
Thank you for pointing out that link, as I am unfamiliar with how wikidata works as that is not en.wiki. Unsupported infobox fields should be removed, especially on BLP articles so my question about the template are still valid: if dob is suppressed, should not the age should be removed as well.--☾Loriendrew☽ ☏(ring-ring) 01:20, 28 October 2023 (UTC)
I am unfamiliar with {{Infobox person/Wikidata}} and I've never used it. However, the documentation says this template only retrieves data that is sourced, excluding "imported from Wikipedia". But it doesn't seem to offer a mechanism to display those sources. If you're not happy with the way the template works, don't use it. -- Michael Bednarek (talk) 02:05, 28 October 2023 (UTC)
Claims in the infobox should appear in the body of the text and should be sourced, per MOS:INFOBOXREF. The bigger problem here is big enough that I put it in a new section below. – Jonesey95 (talk) 05:09, 28 October 2023 (UTC)
There appears to be a bug in the #if statement logic that decides whether to show the age. If |birth_date= is suppressed, the age should not show. That is not happening. It appears that you can work around it using |suppressfields=birth_date death_date. This template does not appear to be suitable for widespread use. I recommend using a well-maintained infobox template instead. – Jonesey95 (talk) 05:22, 28 October 2023 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_person/Wikidata/Archive_1&oldid=1245739266"