Template talk:Infobox person/Wikidata

Lack of redlinks

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.

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)

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)

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. Charlemagne (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)

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:

Died	7 January 1943 (aged 86) New York City, New York, United States
Cause of death	Coronary thrombosis

That would become:

Died	7 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
Born	5 July 1899 Sainte-Foy-lès-Lyon
Died	4 September 1974 (aged 75) From diabetes mellitus Paris
Occupation	Playwright

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:

• George Washington: Y
• Thomas Jefferson: N
• Abraham Lincoln: Y. This uses only what Wikidata calls manner of death. Nikkimaria (talk) 01:01, 8 June 2017 (UTC)
• Ronald Reagan: Y
• Lyndon B. Johnson: Y

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
Born	5 July 1899 Sainte-Foy-lès-Lyon
Died	4 September 1974 (aged 75) From diabetes mellitus Paris
Occupation	Playwright

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)

• Yes, obviously. Laurdecl ^talk 06:14, 9 June 2017 (UTC)
• No. Without evidence regarding "notable circumstances", and given the stats and discussions noted above, it makes more sense to have the minority of cases where this parameter should be used add it, rather than make it the default and force the majority of cases to exclude it. Also pinging participants from the {{infobox person}} discussion: Connormah, Binksternet, SMcCandlish. Nikkimaria (talk) 11:57, 9 June 2017 (UTC)
• Yes for improvement of English and other wikis, it will be a good practice to fetch Wikidata in a "Wikidata" infobox. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 14:55, 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)

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)

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)

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)

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)

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)

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)

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)