Jump to content

Wikipedia:Templates for discussion/Log/2017 January 24

Add links
From Wikipedia, the free encyclopedia
< January 23 January 25 >

January 24

[edit]

Template:Me

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was userfy per request. Primefac (talk) 14:27, 1 February 2017 (UTC)[reply]

poorly named template with only one use, should be moved to userspace to avoid confusion with Template:ME. Frietjes (talk) 21:46, 24 January 2017 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Kustendorf Main Guests

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was Delete. Primefac (talk) 03:12, 3 February 2017 (UTC)[reply]

Guests at a film festival not a suitable topic for a navbox. Rob Sinden (talk) 16:36, 24 January 2017 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Infobox person/Wikidata

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was keep. Based on the discussion and comments from the template creators, it is clear that this is still a work-in-progress. That, in and of itself, is not a valid reason to delete a template, but it is grounds for making sure all usage is extremely vetted to ensure everything is working as designed.

There is clearly more work to be done to ensure this template does what it should 99% of the time (nothing is perfect), but the proponents of this template have made a convincing argument for its use over the on-wiki infoboxes. That being said, there do seem to be some valid concerns about its use and ease of maintenance. While the overall consensus at the moment is to keep this template (with some modifications necessary), there is NPASR in 3-6 months if the accuracy/reliability/etc is not satisfactorily improved. And to reiterate, continued usage of this template must be carefully observed to ensure that bugs are tweaked and errors are corrected. Primefac (talk) 17:57, 8 February 2017 (UTC)[reply]

An unnecessary version of Template:Infobox person. Everything that this template shows can be shown in the standard template, but without the added visual clutter (see e.g. Olav Duun, where every entry in the infobox has a pencil icon, and the bottom has an added "Edit on Wikidata" line; note also how the template doesn't calculate the age, and doesn't respect the mdy date order used in the article).

This template is the cause of edit wars already (see e.g. User talk:Nikkimaria#Your edits removing Template:Infobox person/Wikidata. To get it somewhat right, one needs to add parameters not provided by Wikidata, suppress parameters provided by Wikidata but unwanted, indicate that only things sourced at Wikidata may be included (for what that's worth), and so on. See e.g. here. Problems include duplicate images [1] (the mage was already included in the article, but the Wikidata infobox "helpfully" automatically includd it as well).

Here the Wikidata infobox added a precise date of birth to a BLP, while our article only had a year. The infobox was set to "only fetch sourced data", but while Wikidata had the exact date, the source only gave the year, as did our article. In this case, Wikidata was correct[2] but enough examples of the too numerous errors at Wikidata have been given at Wikipedia talk:Wikidata/2017 State of affairs to make it clear that outsourcing our infoboxes to this unreliable wiki is not a good idea. That's why I propose

Convert to standard infobox person and delete. Fram (talk) 12:53, 24 January 2017 (UTC)[reply]

  • Speedy keep Another flagrant breach of WP:POINT, as part of Fram's ongoing, and increasingly disruptive, crusade against Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 24 January 2017 (UTC)[reply]
    • Anything substantial to say about my actual points? You are usually the great proponent of the merger of all infoboxes, so why not this one? You are right that I don't like most uses of Wikidata on enwiki. This template is a good example of it, and I have given reasons why its use is a bad idea and why I want it to be deleted. That's not pointy and no reason to speedy keep, that's normal. If this gets deleted, nothing gets disrupted, all articles still work like they used to (or even better), so no WP;POINT violation is being made with this nomination. Fram (talk) 13:13, 24 January 2017 (UTC)[reply]
Also, in this thread: "WP:NPA: Accusations about personal behavior that lack evidence. Serious accusations require serious evidence": Fram's ongoing, and increasingly disruptive, crusade against Wikidata. [3], I was referring to your current, not potential, disruption [4], and DePiep was canvassed into this discussion by Fram [5].
Andy, you did not address my remarks re OTHERSTUFF and BAD FAITH. -DePiep (talk) 15:53, 24 January 2017 (UTC)[reply]
"You are right that I don't like most uses of Wikidata on enwiki - Fram, from seven posts above answers your off-topic question about lacking evidence for Fram's ongoing, and increasingly disruptive, crusade against Wikidata. And that's all it is: no reasons, just "I don't like". Don't be surprised he gets called out on it. --RexxS (talk) 12:41, 25 January 2017 (UTC)[reply]
Ah, that I don't like Wikidata is "evidence of an ongoing and increasingly disruptive crusade"? And every example of problems with the template I presented, from policy violations to useless spam and visual clutter, is just "no reasons"? There is a difference between "no reasons" and "reasons I don't agree with", you know? Just like there is a teeny bit of difference between nominating things you see as negative for enwiki for deletion, and "an increasingly disruptive crusade". Perhaps it disrupts your (and a few others) attempts to spam Wikidata on enwiki, no matter what is needed (the number of factual errors told by pro-Wikidata editors in these discussions get dazzling), but that is hardly something I feel sorry about. Fram (talk) 12:50, 25 January 2017 (UTC)[reply]
Yes, the fact that you state clearly that you don't like Wikidata is indeed evidence of of your ongoing and increasingly disruptive crusade. As are many other diffs that either of us could supply. But your behaviour is a subject for another venue. And every example of the the problems you perceive with the template have been thoroughly refuted. There are no policy violations. There is no spam. There is no clutter. Just policy- and consensus-compliant extra functionality, completely customisable by the end-user. You're spreading untruths again. You have no reasons. Give some examples of these so-called "factual errors told by pro-Wikidata editors in these discussions", and I happily knock them down as the thin tissue of fabrications that you're relying on. --RexxS (talk) 13:12, 25 January 2017 (UTC)[reply]
If you are unable even to recognise the visual clutter the Wikidata version of the infobox adds to articles, then I see no point in rahshing all other points with you again. (never mind the fact that explaining such things to someone unwilling or unable to see that "I don't like it" is not and never will be "evidence of an ongoing and increasingly disruptive crusade" is probably futile as well) Feel free though to take my "behaviour" to "another venue". Drawing more attention to this tfD can only be beneficial. Fram (talk) 13:19, 25 January 2017 (UTC)[reply]
I'm glad you chose to self-revert your own very disruptive edit though[6]. A very bad idea indeed. Fram (talk) 13:30, 25 January 2017 (UTC)[reply]
That would be the edit described by RexxS in his edit summary as a "temp[orary] fix". Nonetheless, how is this relevant here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:37, 25 January 2017 (UTC)[reply]
An edit made here to fix a problem on Wikidata that otherwise can't be fixed? Seems relevant, yes, as it shows once more how intrusive (in a negative way) Wikidata becomes. Fram (talk) 15:22, 25 January 2017 (UTC)[reply]
And yet it fixed the problem. Sounds like sour grapes to me, and yet another gripe about Wikidata. There's no issue with this template that hasn't been solved rapidly. The template offers improved functionality and has no drawbacks that haven't been remedied within hours, if not minutes. No reason exists to delete it. --RexxS (talk) 15:45, 26 January 2017 (UTC)[reply]
You are aware that that "fix" you are so proud of didn't fix the template at all, it fixed just one lonely instance of the problem, in a rather roundabout way (changing a redirect here to an "article" because you couldn't create an item for a redirect at Wikidata)? Every other redirect which appears in the infobox still has the same problem... Fram (talk) 15:57, 26 January 2017 (UTC)[reply]
That's because there's no problem with the template. The lack of a link from Wikidata to an en-wp article has nothing to do with this template; I just fixed it to stop you whining off-topic about Wikidata in general. The fact that errors exist elsewhere is no grounds for deletion of this highly-functional template. --RexxS (talk) 16:02, 26 January 2017 (UTC)[reply]
  • Keep The point of this template is to be a technical test to show how an infobox could be used with Wikidata. As far as I can tell, it is only used in a few hundred articles. As with so many things on Wikipedia, this has become a needlessly contentious subject for argument. The infobox is designed in such a way that it can be overridden when local consensus differs from Wikidata. Where it fails to do this properly, we should change the functioning of the template. Ultimately, we should be very cautiously moving towards using Wikidata (hopefully with better sourcing policies, and with widespread use of semi-protection or pending changes). Deleting a template that's intended to be cautiously used as a way to test out that functionality hinders rather than helps with finding amicable and reasonable ways to integrate Wikidata and Wikipedia. —Tom Morris (talk) 14:11, 24 January 2017 (UTC)[reply]
    • Then find a way to keep it from getting used in the mainspace, and use it in other namespaces instead. The main page is not a testing ground for things like this, and people are already edit warring to keep this template in articles just for the sake of it. Changing it so that only reliably sourced data from Wikidata can be used would be a start to perhaps make this someday acceptable. Fram (talk) 14:20, 24 January 2017 (UTC)[reply]
      • 'a technical test' as you say. So not fit for mainspace. Then again, what if a test fails (e.g. in the DOB example provided)? How can an enwiki editor correct that, without having to understand the Wikidata model & intrications (=an other, not enwiki site)? -DePiep (talk) 14:46, 24 January 2017 (UTC)[reply]
        • A test can be done on a small number of articles. Like, say, the 300 or so articles this is on. You can correct something on Wikidata by editing it on Wikidata (just like you occasionally have to engage with Commons to sort out images). Or you override it in the infobox by replacing the value. That doesn't benefit the wider community because the point of Wikidata is to share that kind of data among other Wikipedias (and Wikisource, Wikinews projects etc.) —Tom Morris (talk) 02:27, 25 January 2017 (UTC)[reply]
          • "A test can be done ..."? What do you mean, "can be done"? Exactly what is tested this way? How to edit Wikidata for 300 articles?, or a sandbox template? And, why cannot/isnot this tested in a different way? -DePiep (talk) 02:11, 26 January 2017 (UTC)[reply]
  • Convert & delete as proposed. By now we know that Wikidata input cannot be fetched that simple into an enwiki infobox. Template documentation becomes already overloaded for enwiki editors (having to grasp the Wikidata data model, source qualities, managing parameters, ...). With this, the 'edit this Wikidata-value' link (the pencil, btw a semi-external link) is not safe to be the editors tool. By current definition better: add one Wikidata link per infobox. Compare: how does one edit an image? And let's not forget: for consistence, we want a single infobox, to bring consistency for our Readers. -DePiep (talk) 14:55, 24 January 2017 (UTC)[reply]
    • Note that DePiep was canvassed into this discussion by Fram, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:05, 24 January 2017 (UTC)[reply]
    • To discuss your attacks, yes (and even then he was just pinged). Not to give his comment on the actual merits of the TfD. Note that I also "canvassed" Tom Morris by adding a note to his talk page about this deletion. I suppose in his case you don't feel the need to point this out? Please, after you have read WP:POINT and WP:SK, read WP:CANVASS as well. Throwing around wild accusations left and right really won't help you save this template from deletion. Fram (talk) 15:16, 24 January 2017 (UTC)[reply]
      • No, not WP:CANVASSED. I was pinged. By misusing the difference, Andy, you are smearing Fram while Fram acted correctly and in good faith (PA warning). Anyway, being pinged was my opening text here. Full disclosure: I was pinged before: [Wikipedia:Administrators' noticeboard/3RRArchive334#User:Pigsonthewing_reported_by_User:Fram_.28Result:_Stale.29]. -DePiep (talk) 15:35, 24 January 2017 (UTC)[reply]
      • You're required to notify the creator of a template you nominate here; you're cautioned by WP:CANVASS not to do things like selectively inviting one editor with whom someone opposing your viewpoint has had a number of past disagreements, during which they were cautioned by uninvolved editors for their behaviour. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:39, 24 January 2017 (UTC)[reply]
        • Can you link to where DePiep was cautioned by uninvolved editors wrt his behaviour in past disagreements with you? I am not aware of any such situations, but I haven't followed the career of either you that closely. Fram (talk) 15:41, 24 January 2017 (UTC)[reply]
        • re Andy. "WP:TFD: Please notify the creator" clearly shows it is not 'required'. Also, I do not see how notifying the creator has anything to do with me being canvassed or not. Next: I came here on my own free will without being asked or instructed or suggested to take whatever position. I wrote my posts here as my own writings. -DePiep (talk) 16:00, 24 January 2017 (UTC)[reply]
  • Speedy keep - this is a test template to use Wikidata to auto-fill Infobox Person. In the long run it will be merged in to the main template, but for now it is essential to keep this. Thanks. Mike Peel (talk) 16:04, 24 January 2017 (UTC)[reply]
Why speedy? So again, a "test". In that case: not for mainspace.
But. Maybe you mean to say: "Use this one in Preview only, it nicely shows Wikidata values, then save the parent template". If that's the intention, again it should not be saved in mainspace. And workings & documentation should clarify this. -DePiep (talk) 16:12, 24 January 2017 (UTC)[reply]
@DePiep: "Speedy" because this is a WP:POINTy nomination that is resulting in a distraction from working on the articles and template. It's a "test" in a transitional way - we already use this setup in mainspace with other infoboxes, but it will take time (and live article examples) to get this working for this specific infobox. In other cases I've been working with the main template directly - using this separate version was an attempt to avoid unnecessary drama with a high-use infobox, not cause more!
Using it in preview/substitute mode only isn't a good long-term solution - it's more efficient and scalable to use the template call to fetch the wikidata values, than to have separate calls in each article (which also unnecessary clutter up the wikitext). Thanks. Mike Peel (talk) 22:55, 24 January 2017 (UTC)[reply]
Your explanation of why it is "essential to keep this' doesn't make sense, and doesn't explain why preview only wouldn't work for the test. There is no agreement that it is even allowed to display data from a different, unreliable site directly into Wikipedia articles, as it violates WP:V: "do not use websites that mirror Wikipedia content or publications that rely on material from Wikipedia as sources." and "self-published media, such as [...] open wikis, [...] content farms, [...] are largely not acceptable as sources." The template either includes material already in the article, in which case the standard infobox can easily deal with it; or it introduces material not in the article, in which case it is unacceptable. Fram (talk) 09:07, 25 January 2017 (UTC)[reply]
That's untrue. There is agreement. You're perfectly aware of the large RfC that established the principle of importing information from Wikidata into infoboxes. You have not chosen to challenge that strong consensus, but to attempt to subvert it. Your characterisation of Wikidata is mistaken. The information on Wikidata is no more or less unreliable than the information on the various Wikipedias, whence it originated. The information imported by this infobox is not "drawn directly" from Wikidata, but via a filter that rejects unsourced information. That is an improvement on the current scheme where an editor can locally supply unsourced information directly into an infobox. The template either includes material already in the article, in which case it is just as good as the standard template, or it includes information not in the article, which opens up other beneficial possibilities that you're unaware of: (1) the information may have been updated, and our article hasn't caught up yet – when Manchester United change manager, it's advantageous to update that centrally and have all Wikipedias updated at once; (2) a new fact may have arisen and a decision needs to be made on whether to include it or not in our infobox. Bringing in that information from Wikidata at least indicates a source is available, so it is an aid to local editors who make the decision to accept it, suppress it, or replace it with a local value. There's nothing "unacceptable" about that. --RexxS (talk) 13:04, 25 January 2017 (UTC)[reply]
Funny. I just linked to the last RfC on this, some 7 months ago, which clearly showed no consensus, but leaning towards "no Wikidata in infoboxes" (not my conclusion, but the conclusion of the closing admin). That you can't see the many problems with the template and scheme is clear by now. "it's advantageous to update that centrally and have all Wikipedias updated at once" could be somewhat true if Wikidata is more reliable than enwiki, not when it simply opens up a new and better venue to vandalize articles en masse, or to add incorrect information to many articles at once. And even without incorrect information, it is not certain that what is an improvement on one wiki is an improvement on others (e.g. taking the image directly from Wikidata). Every wiki has its own rules about what constitutes reliable sourcing, and something added to Wikidata may be welcome on one but not on others (say, an item sourced to the Daily Mail).
"(2) a new fact may have arisen and a decision needs to be made on whether to include it or not in our infobox. Bringing in that information from Wikidata at least indicates a source is available, so it is an aid to local editors who make the decision to accept it, suppress it, or replace it with a local value. There's nothing "unacceptable" about that." That's what we have talk pages for. Create a Wikidata alert system indicating that a new sourced item for the article is available on Wikidata, fine! Don't insert it directly into articles though. Fram (talk) 13:27, 25 January 2017 (UTC)[reply]
Perhaps you should read that RfC then: Wikipedia:Village pump (policy)/Archive 128 #RfC: Wikidata in infoboxes, opt-in or opt-out?. The question asked was "whether Wikidata in infoboxes should be opt-in or opt-out". There was obviously no consensus either way for that because such decisions depend on the infobox under consideration. It was clear that {{Infobox telescope}} works as an 'opt-out' template, but {{Infobox book}} needs to be 'opt-out'. It was as a result of the issues raised there that I put the effort into creating a functionality in Lua that allowed either sort of infobox to be constructed easily. You need to read all of the closer's comments, not make up your own conclusions. Here's a free clue: the words 'leaning towards, and "no Wikidata in infoboxes"' don't appear anywhere in the closer's remarks. You will find one of the pertinent comments directed to the closer was "Above, RexxS states: "...we've not been debating whether we use Wikidata but only how." That was the truth of that RfC, and any suggestion that another RfC was needed to re-examine the question of the inclusion of Wikidata in infoboxes went precisely nowhere. You're welcome to try to revive it with a new RfC, but until then, the four-year old consensus still applies, and your case here hasn't a leg to stand on.
That's what we have talk pages for. What a complete non-sequitur. The addition of a new field in an infobox will demand exactly the same scrutiny, sometimes on the talk page, whether it was added by a local editor or someone providing a sourced statement on Wikidata. The difference is not how the new entry is discussed, but that this infobox doesn't add the filed if there is no source. Unlike the local edit. Now matter how you try to bend the facts, this infobox offers additional functionality that will be welcome to all but the most die-hard opponents of Wikidata. Anyone looking objectively at the evidence can see which of us is arguing "purely on ideological grounds, and are too blind to see any problems with it, even when they are demonstrated to you step by step", as you tried to describe me. At every stage in its development this infobox has taken feedback and attempted to address perceived problems for the benefit of Wikipedia editors and readers. You just want stagnation and no progress. Your solution of combating vandalism by preventing editing is a very long way from the ideals of this project. Thankfully the majority of us reject that philosophy. --RexxS (talk) 19:18, 25 January 2017 (UTC)[reply]
I have read the RfC, thank you. I tried to put the conclusion in gentler words: "the words 'leaning towards, and "no Wikidata in infoboxes"' don't appear anywhere in the closer's remarks.", instead they said "Of the last 11 votes that went one way or the other, 10 were for opt-in (roughly speaking, the anti-Wikidata-in-infoboxes position).", "when a pattern develops toward the end, that tends to signal which way things are going in the future." and "the tone of the RfC changed as it progressed, so that "opt in" was less likely to mean "I'm in favor of having the gadget work a certain way" and more likely to mean "Ugh, Wikidata is awful". " Emphasis mine. If, three years after you started adding Wikidata, you can't get consensus on an RfC about it and many of the votes were of the "Wikidata is awful" variety, then it is a bit too much to claim that there is consensus for the inclusion of Wikidata. As for your second point, I don't see the benefit for Wikipedia readers and editors in your changes at e.g. John S. Duncan, where your insistence on using the Wikidata version caused the loss of information in the infobox, and the duplication of the website for some reason, all for no gain at all for readers or editors. If that's not "editing" (vandalizing would be more appropriate) on ideological grounds, then please tell me what is? Fram (talk) 08:04, 26 January 2017 (UTC)[reply]
Then read it again, and try not to cherry-pick one phrase as if it represented the whole debate. It didn't. We have consensus for updating infoboxes to draw information for Wikidata from the 2013 RfC. There's no wikilawyering your way out of that. The later RfC that you seem unable to comprehend was on the question of how to get the information from Wikidata. For that there was indeed no consensus. In John S. Duncan you chose to revert this Wikidata-aware template that was filtering out 'alma mater' because it was unsourced, and then manually added the unsourced information to the infobox yourself. The information "lost" in my edit was completely unsourced. You clearly proved the point that this template has the advantage of not displaying unsourced information and that's one of the clearest benefits to Wikipedia that's obvious to everyone except you. --RexxS (talk) 15:57, 26 January 2017 (UTC)[reply]
re this is a WP:POINTy nomination. A 'Speedy' closure is only to be used here when that is obvious. That is not the case here, the TfD nomination is worth discussing (as there are already valid arguments). Your "POINTy" argument is circular: You claim that outcome, and then you say that that your outcome is the only one in view. Quite illustrative its that you (correctly) have the need to expand and detail your argument once more. So, not that obvious. -DePiep (talk) 10:51, 25 January 2017 (UTC)[reply]
  • Keep, the small amount of visual clutter produced is worth it for raising awareness of Wikidata. We are still in the learning phase of combing Wikipedia's freeform interface with the structured system provided by Wikidata, and should not delete uses of Wikidata at this point. (And of course for every individual article, superior results can be achieved by hand than by templates, but we still tend to use templates to standardise things). —Kusma (t·c) 16:17, 24 January 2017 (UTC)[reply]
We have many more REaders than Editors. The visual clutter is affecting all of our Readers. Also, infoboxes should be consistent over articles. We don't want two versions for one box. -DePiep (talk) 17:09, 24 January 2017 (UTC)[reply]
Make it only display when logged in then. —Kusma (t·c) 17:19, 24 January 2017 (UTC)[reply]
But what about the editors who choose not to register accounts? Pppery 18:16, 24 January 2017 (UTC)[reply]
Their choice. No need to let the perfect be the enemy of the good. —Kusma (t·c) 21:32, 24 January 2017 (UTC)[reply]
"Make it only display when logged in then." What, and the vast majority of the readers simply get to see no infobox at all? Fram (talk) 09:07, 25 January 2017 (UTC)[reply]
No, Fram , "it" means the "edit" pencils and the "edit on Wikidata" link at the bottom, not the whole infobox. Pppery 17:11, 25 January 2017 (UTC)[reply]
Oh, right, that's indeed a more logical way to read that statement. My mistake. Fram (talk) 08:04, 26 January 2017 (UTC)[reply]
Thanks for confirming what this is about. "raising awareness of Wikidata." is misusing the mainspace for ulterior motives (aka spam). Fram (talk) 09:07, 25 January 2017 (UTC)[reply]
I don't know what ulterior motives the creator may have had, I just note something I think this is useful for. From a reader perspective, the edit buttons on this template are as much "spam" as the edit buttons everywhere else. Will you argue for the abolition of edit buttons next? —Kusma (t·c) 15:11, 25 January 2017 (UTC)[reply]
There is a difference between asking people to edit this site, and to ask them to edit another site. Fram (talk) 15:19, 25 January 2017 (UTC)[reply]
Like the Commons, Wikidata is only "another" site because it is a shared resource. Treating it as a foreign object is rather against the spirit of the Wikimedia movement. —Kusma (t·c) 17:29, 25 January 2017 (UTC)[reply]
  • Convert to a wrapper and make subst-only per nom, to allow people to make infoboxes initially filled from Wikidata, while still letting them be edited locally. Pppery 18:20, 24 January 2017 (UTC)[reply]
  • Keep The template adds nothing but additional functionality and does no harm. The consensus for using Wikidata in infoboxes was established in Wikipedia:Requests for comment/Wikidata Phase 2 and attempts to re-litigate the issue by the backdoor by a handful of die-hard anti-Wikidatans need to be seen in the light of the overwhelming consensus in that RfC. If they want to change that consensus, then set up a new RfC: using AfD for that purpose is unworthy of any respectable editor. To address Fram' "points":
    1. Nothing on Wikipedia is "necessary", so "unnecessary" isn't a deletion rationale, but being able to take information indirectly from other sources via Wikidata is an extension of the pool of potential contributors to an article and is therefore an advantage. I reject the "little England" mentality of making walled gardens around our articles as if no improvements could be made. That is the sort of elitist philosophy that is killing Wikipedia by pushing away new contributors.
    2. If you don't like the edit icon (pen) in your favourite article then simply use |noicon=true and it does not appear.
    3. I'll write the code to calculate the age when I'm ready, or someone else may beat me to it, but for the moment using {{birth date and age}} as a local parameter takes precedence over anything pulled from Wikidata, so where's the problem?
    4. I only wrote the code to fetch dates in mdy or year-only format last week, so give the infobox developers a chance to incorporate it into templates such as this. Rash efforts at trying to remove harmless templates simply stifles development work done to incorporate feedback. If we deleted every piece of coding that didn't work the way we wanted first time, we'd never have had a wiki in the first place.
    5. Edit wars occur when perfectly functional templates are being reverted for absolutely no good reason. The whole point of the template is that it can directly replace {Infobox person} without any visual changes whatsoever. Only when an editor chooses to enable it in an article does the extra functionality kick in.
    6. The extra parameters like |noicon=, |onlysourced=, |dmy=, and |bc= offer additional optional functionality such as only allowing sourced information to be returned, or fixing the date format (dmy/mdy and BC/BCE) for every date in the infobox. It gives editors extra control and always allows a local parameter to override anything Wikidata-related. In other words, editors who want to continue adding information to the infobox in the way they always have need learn nothing more. Those who want to make use of the extra features have the scope to enable information from Wikidata and the tools to filter it and display it as they choose.
    7. It is helpful to have an image included where one is available. When Sic19 added the infobox to Alfred John Kempe, it did indeed duplicate the existing lead image. How is that any different from any editor adding an infobox, but not removing the existing lead image? What has that to do with this template? any editor adding any infobox could have made the same mistake, and deleting this template won't cure human error.
    8. As for the date of birth of Alain Supiot, if the source (https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=idn%3D1313000910) is misrepresented on Wikidata, then how is that any different from an editor misrepresenting a source directly on Wikipedia? It took me all of two seconds to click the edit link (pen icon) and fix it on Wikidata. Where's the problem? If someone wants to add https://www.college-de-france.fr/media/alain-supiot/UPL2909853095061303688_CV_CdF_Sept13.pdf as a reference for the full date of birth, then they can, but per WP:BLPPRIVACY, I'll leave it as 1949 until someone can make the claim that it is among "dates of birth that have been widely published by reliable sources".
    9. Wikipedia talk:Wikidata/2017 State of affairs is nothing but a collection scare-mongering and outright untruths, initiated by the nominator of this AfD, as part of his campaign against Wikidata. The comments expressed there are no more reliable than statements on Wikidata whose provenance is "Imported from Xyz Wikipedia". --RexxS (talk) 19:52, 24 January 2017 (UTC)[reply]
1. "Nothing on Wikipedia is "necessary", so "unnecessary" isn't a deletion rationale" "Redundant" is a standard deletion rationale for templates. We don't usually keep two templates who do the same thing, and if one of them does the same thing in a worse way (and violating WP:V while doing it), it should go. "but being able to take information indirectly from other sources via Wikidata is an extension of the pool of potential contributors to an article and is therefore an advantage." No, this is a vilation of WP:V. Using another wiki / content farm as the source of data is not allowed per WP:V. And adding edit links to Wikidata, and linking to Wikidata items instead of Wikipedia articles, is not an extension of the pool of potential contributors, it is an attemmpt to siphon editors away from here to Wikidata.
2. "If you don't like the edit icon (pen) in your favourite article then simply use |noicon=true and it does not appear." Whihc still leaves the coloured "doesn't exist on Wikipedia" bars (which are usually incorrect), and the "edit on Wikidata" label. This is a good example.
3. "I'll write the code to calculate the age when I'm ready, or someone else may beat me to it, but for the moment using {{birth date and age}} as a local parameter takes precedence over anything pulled from Wikidata, so where's the problem?" I know, we can add everything as a local parameter. Why use the Wikidata one then?
5. "Edit wars occur when perfectly functional templates are being reverted for absolutely no good reason. The whole point of the template is that it can directly replace {Infobox person} without any visual changes whatsoever. Only when an editor chooses to enable it in an article does the extra functionality kick in." If it isn't enabled, it is useless, and it is easier then to use the standard one (no need to send editors to a page with a lot of documentation if it isn't enabled anyway, just show them the template you are actually using instead). And when it is enabled, it does change the visual appearance (both with added clutter, and with suddenly appearing fields of usually unsourced information). These seem like very good reasons to me.
6. *# "editors who want to continue adding information to the infobox in the way they always have need learn nothing more." Those who want to remove unwanted, policy-violating information from the infobox need to learn how it works and how to exclude said information. Those who want to keep an eye on the article now need to add "wikidata changes" to their watchlist, and check all changes that that check returns as well (which is often hard to interpret, I only can find which article the Wikidata change may impact by visiting it in many cases like "D Wikipedia:Wikidata (Q183); 21:20 . . Hejsa (talk | contribs) (‎Added [da] description: forbundsrepublik i Centraleuropa)").
7. "It is helpful to have an image included where one is available." Not always, no, and no need to have the one arbitrarily added to Wikidata. "When Sic19 added the infobox to Alfred John Kempe, it did indeed duplicate the existing lead image. How is that any different from any editor adding an infobox, but not removing the existing lead image? What has that to do with this template? any editor adding any infobox could have made the same mistake, and deleting this template won't cure human error." The template under discussion adds the image by default. A human editor would have had to deliberately add it. This reduces the chance of such an error.
8. "*# As for the date of birth of Alain Supiot, if the source (https://portal.dnb.de/opac.htm?method=simpleSearch&cqlMode=true&query=idn%3D1313000910) is misrepresented on Wikidata, then how is that any different from an editor misrepresenting a source directly on Wikipedia? It took me all of two seconds to click the edit link (pen icon) and fix it on Wikidata. Where's the problem?" WP:V. The template is adding data straight from an unreliable source (Wikidata). We wouldn't allow the display of data from another wiki, even though we can correct these as well. A template that violates one of our core policies in such a way should not be tolerated. Considering the much lower vandalism reversion rate at Wikidata (just imagine that someone moved Superman to UGLY on enwiki, it would be reversed in seconds: on Wikidata, it took more than an hour[7]. (Apparently that "label" is also shown to al enwiki users on mobile? I haven't checked this).
9 "*# Wikipedia talk:Wikidata/2017 State of affairs is nothing but a collection scare-mongering and outright untruths, initiated by the nominator of this AfD, as part of his campaign against Wikidata. The comments expressed there are no more reliable than statements on Wikidata whose provenance is "Imported from Xyz Wikipedia"." While I initiated that page, many others have contributed. No outright untruths have been shown, although some Wikidata defenders have tried their hardest to unearth them. And of course, comparing the reliability of personal comments and opinions with facts shown in the mainspace of BLPs shows the problem and lack of perspective you seem to have. Fram (talk) 09:07, 25 January 2017 (UTC)[reply]
re RexxS: a. The RfC you link to concluded, in bold: "modify existing infoboxes ...". This proposal is exactly aiming at that: merge into the existing template. BTW, that RfC is from 2013. b. re Your qualification of Fram and writing collection scare-mongering and outright untruths, initiated by the nominator of this AfD, as part of his campaign against Wikidata. Accusing an editor of "scare-mongering" ... does this help the discussion? Is that the best you can come up with? the backdoor by a handful of die-hard anti-Wikidatans - That's called Discussing a Template. This is criticism of Wikidata-in-enwiki. If you cannot stand that, that still is no reason to attack an editor's GF. -DePiep (talk) 11:10, 25 January 2017 (UTC)[reply]
@DePiep: (a) This proposal is not aimed at modifying existing infoboxes. It is a petty attempt to stifle the development of a modified version of {infobox person} which respects the established consensus. You seem to imply that a consensus established by a large RfC is somehow problematical because it has stood for four years. The longer a consensus holds, the more certain we are that it is a useful consensus. If the nominator wishes to change that consensus, then the way to do it is via RfC, not by backdoor attacks on implementations of that consensus which he doesn't like. (b) I am a plain, blunt man and I call a spade a spade. When Fram is scare-mongering and spreading untruths, I'll call it "scare-mongering and spreading untruths", as I have done here. It is beneficial to this discussion to understand the background to the dispute, so yes, it does help people to understand. This debate is nothing to do with discussing a template and everything to do with Fram advancing an anti-Wikidata agenda. Good faith is not a suicide pact and Fram's efforts to damage a sister project have long exhausted any stock of GF. --RexxS (talk) 12:33, 25 January 2017 (UTC)[reply]
What "efforts to damage a sister project"? We are still at enwiki, no? Feel free to edit Wikidata to your hearts delight. Truly, be my guest, no one is stopping you. As for consensus, the most recent discussion about this was Wikipedia:Village pump (policy)/Archive 128#RfC: Wikidata in infoboxes, opt-in or opt-out? from 6 months ago, which closed as "no consensus" but with the remarks that "the tone of the RfC changed as it progressed, so that "opt in" was less likely to mean "I'm in favor of having the gadget work a certain way" and more likely to mean "Ugh, Wikidata is awful". and " Of the last 11 votes that went one way or the other, 10 were for opt-in (roughly speaking, the anti-Wikidata-in-infoboxes position)." So claiming that you have a consensus which has stood for four years is bending the truth a bit, as 7 months ago there was no consensus for your position and it tended to go in the opposite direction. Fram (talk) 12:58, 25 January 2017 (UTC)[reply]
No, the most recent discussion about whether to use Wikidata in infoboxes was Wikipedia:Requests for comment/Wikidata Phase 2. You're confused about what the question was. --RexxS (talk) 16:14, 26 January 2017 (UTC)[reply]
re RexxS. 1. nom says "Convert to standard infobox person and delete". That's TfD-language for: "Merge & redirect". Even without this, you or anyone else could have brought that up: "I propose to merge, because [arguments go here, but better no personal issues]". 2. "You seem to imply that ..." - If you think so, just ask me. No need to speak for me. 3. RexxS, as you very well know there is no policy, guideline, nor established practice on how to use and implement Wikidata in enwiki infoboxes. About every template I work on has a different angle of approach. You use of "respects the established consensus" is cherry-picked, and only a 2013 consensus at that (2013 =babyyears for WD). Even your replies here too show that development is going on. Now I don't mind development and various routes. But I do object to you claiming this infobox has the one and only route, while breaching many other well-established practices in wiki re infoboxes, editing & development. 4. Nom correctly addresses these concerns, and I see no argument or helpfulness in a "stifle the development" statement. For me, it's those non-argumental attacks that spoil the development. -DePiep (talk) 13:45, 25 January 2017 (UTC)[reply]
It's no use trying to pretend the 2013 RfC – which was an en-wp RfC, so not 'baby-years' – does not carry the full weight of the hundreds of comments made. We have consensus to to modify existing infoboxes to permit Wikidata inclusion. Of course the development is on-going, but you're not constructively proposing an alternate route; you're just objecting and putting words into my mouth. When have I ever refused a good-faith request to fix a problem, modify a template, or proceed in a different manner? Come to me with sensible, concrete proposals and I'll be happy to work with you on them. --RexxS (talk) 16:14, 26 January 2017 (UTC)[reply]
  • Keep for now. There is a need to consistently refine and improve what we do and this appears to be a beta version of a viable and needed update to {{Infobox person}}. To me, this falls under the WP:DONOTDEMOLISH standard and it is a bit POINT-y to be trying to delete a proposal while it's being worked up and tested. Montanabw(talk) 23:19, 24 January 2017 (UTC)[reply]
    • All fine, except that there is no reason why this development should be mainspace, splitting a major infobox. It's just a sandbox, as everybody here confirms. -DePiep (talk) 02:15, 26 January 2017 (UTC)[reply]
      • Actually, there's a very real reason why development should be in mainspace. Unless we use different, expensive calls to Wikibase, the functionality of any Wikidata-aware infobox only works in the article in question. This template is what developers would consider a 'fork' of the main template, not a sandbox. The idea is that when the functionality and reliability of this version is proven, we can seek consensus to merge it back into the main branch. But that is likely some time away, especially when the developers' time is wasted on spurious efforts to destroy the work, like this nomination. --RexxS (talk) 16:24, 26 January 2017 (UTC)[reply]
        • "Expensive" is about perfomance. As you know, Performance is not an issue unless ... it is an issue. This is not the case (no performance issue), so it is not an argument. -DePiep (talk) 10:48, 27 January 2017 (UTC)[reply]
          • There are hard limits on expensive calls from templates. A large template with multiple expensive calls might not work (especially in a heavily sourced article, because the citation templates are a bit expensive themselves). Also, PERF doesn't prohibit an experienced template programmer from voluntarily choosing a less expensive approach. WhatamIdoing (talk) 15:53, 30 January 2017 (UTC)[reply]
  • Keep per Rexx: "Edit wars occur when perfectly functional templates are being reverted for absolutely no good reason." Its a test; let's test it and refine it if needed to see if it creates progress for the encyclopedia. There is a tendency on WP to stay with the old; if we want to progress we have to, at the least, be open to try the new. Nothing lost by trying it and refining it.(I made this comment earlier but had accidentally scrolled into another discussion)(Littleolive oil (talk) 00:05, 25 January 2017 (UTC))[reply]
    • But the template isn't "perfectly functional". If it isn't enabled, it is useless. If it is enabled, it adds all kind of problems, going from lots of visual clutter, bluelinks going to Wikidata instead of the existing items on enwiki (because the term happens to be a redirect), to violations of WP:V (specifically) WP:SPS and WP:CIRC). We even have pages where it is enabled, but then adds nothing at all to the page, like Rino Rappuoli where all fields in the infobox are local. The only thing it does there is add a "edit on wikidata" link to the bottom. Why should such Wikidata spam be allowed here? Perhaps we should change the template to add "edit on simple, commons, wikiquote, ..." as well. After all, they are also all WMF projects. And perhaps add a link to the translation tool as well, and "create on de, fr, nl, ..." Okay, it would make the infobox somewhat larger, but it would remain "perfectly functional" and would encourage the spreading of knowledge throughout the world. Fram (talk) 09:07, 25 January 2017 (UTC)[reply]
      • That's quite wrong. The template is perfectly functional. If it isn't enabled, it is far from useless because once it is there, it can be enabled whenever an editor wants to make use of it. It doesn't add problems because the visual presentation is customisable and the bluelinks to Wikidata are a positive advantage as they show that although a linked item has no Wikipedia article, it has a Wikidata entry and hence an entry in another Wikipedia. That's a great starting point for finding notable topics that could have an entry here. The missing links that are redirects are simple to fix, and I'd be happy to show you how, as you don't seem to be aware of how that can be done. The concept of "Wikidata spam" is merely a transparent smear taken from a campaign against one of our sister projects. I notice you don't complain about the much larger advert for Commons that appears on many more articles. Why not? If editing an article on "simple, commons, wikiquote ..." brought benefit to en-wp in the same way that editing the corresponding entry on Wikidata does, I'd be more than pleased to write the code to do just that job for you. After all, we're all part of the same Wikimedia project and I'm in the business of pulling down artificial barriers such as the ones you seem to want erected. --RexxS (talk) 12:13, 25 January 2017 (UTC)[reply]
        • Your definition of useless differs from mine. The only "useful" thing you have to say when it is not enabled is "then it can be enabled"...
        • "the bluelinks to Wikidata are a positive advantage as they show that although a linked item has no Wikipedia article, it has a Wikidata entry and hence an entry in another Wikipedia." This claim contains two glaring errors: often, the linked items have a Wikipedia article, but not at that exact term but through a redirect. To go back to the example of Charmian Clift (but there are plenty of others): Short story writer gets a link to Wikidata (with the colour icon added as a bonus), even though it could be a good bluelink to enwiki instead. And that link perfectly shows the second error in your claim here: the Wikidata entry links to no other Wikipedia article: there is no entry for "short story writer" in any Wikipedia. And this is the case for many, many Wikidata entries, ranging from individual journal articles like Identification of sites on chromosomal protein HMG-I phosphorylated by casein kinase II to Unreferenced BLPs to ... "Random item" gave me as first result an unsourced entry with no Wikipedia articles
        • "The missing links that are redirects are simple to fix, and I'd be happy to show you how, as you don't seem to be aware of how that can be done." Oh yes, it is very easy to do. Just use the infobox that worked and works instead of the one that requires extra work for no extra benefits to enwiki.
        • "The concept of "Wikidata spam" is merely a transparent smear" Then how would you describe it when on quite a few instances of this template, all it does is to add an "edit on Wikidata" link and absolutely nothing else? A template that adds, in the mainspace, a link to edit another site is spam for that site.
        • "If editing an article on "simple, commons, wikiquote ..." brought benefit to en-wp in the same way that editing the corresponding entry on Wikidata does[...]" Indeed, such editing brings about the same benefit to enwiki.
        • "After all, we're all part of the same Wikimedia project and I'm in the business of pulling down artificial barriers such as the ones you seem to want erected." No thanks. I don't care about the susets of the project that produces the tourist folders called Wikivoyage, the copyright violations called Wikiquote, the nonsense called Wikiuniversity (or whatever its name) and the rubbish called Wikinews, not to mention the entity pushing things like Flow, Gather, ... I'm an enwiki editor, and I try to make enwiki the best possible (in my own small way, I can't tackle everything). If that means "raising barriers" between enwiki and wikidata, why not? If I don't believe that in general, Wikidata is beneficial to enwiki (or at least the parts of Wikidata we are discussing here), then I will try to get consensus for such barriers. That Wikidata is also a WMF project is not important. If the WMF tomorrow buys Findagrave and calls it Wikigrave, I would still oppose all inclusions of links to it, just like we do now with Findagrave. Fram (talk) 12:42, 25 January 2017 (UTC)[reply]
          • If you don't think the ability to enable extra functionality on demand is useful, then you do indeed have a different definition from me.
          • No errors on my part, glaring or otherwise. Fixing the link to a redirect only needs to be done once. I've fixed short story writer (Q15949613) for you and it took all of 30 seconds. See Charmian Clift. You're welcome.
          • Manusela–Seti is a language family from Indonesia. Are you really contending that it's not notable, rather than just another topic where nobody's written an article yet? These are great starting points for expanding the encyclopedia, not inconveniences to be carelessly dismissed.
          • You don't fix a problem by ignoring it. If everybody had stuck to your way of thinking, we'd still be living on a flat Earth with the sun and stars going around it.
          • "A template that adds, in the mainspace, a link to edit another site is spam for that site." - you mean like the [Wikidata item] link in the tools menu on the left of articles is spam? Nonsense, the [edit at Wikidata] link is there because people asked for it, as a convenience for new editors who didn't spot that sidebar link. Personally, I'd turn it off wherever the pen icons are enabled. Would you like me to do that?
          • Thank you for your agreement that "such editing brings about the same benefit to enwiki". You can look forward to me making available such edit links to other relevant projects at some point in the future.
          • I know you don't believe that Wikidata is beneficial to enwiki, and I feel sorry for you. It makes me sad to observe your desire to generate consensus to erect barriers between sister projects. I understand that you would oppose links to Wikigrave if it existed; I would work to make such a sister project functional and reliable for all Wikipedias. That's the difference between us. --RexxS (talk) 13:42, 25 January 2017 (UTC)[reply]
            • You don't seem to reply to the arguments I made (and don't seem to recognise sarcasm either). Anyway, no errors? "the bluelinks to Wikidata [...] show that although a linked item has no Wikipedia article, it has a Wikidata entry and hence an entry in another Wikipedia." This clearly wasn't true. Writing something that isn't true is the definition of an error (unless it was a deliberate lie). In the next sentence, you state twice that you fixed it. Fixed what? There was no error! The defense os Wikidata proponents seem to be "everything that is wrong just needs to be fixed". Oh, really? Who would have guessed. "You don't fix a problem by ignoring it. If everybody had stuck to your way of thinking, we'd still be living on a flat Earth with the sun and stars going around it." Not agreeing with your solution is not ignoring a problem. "Manusela–Seti is a language family from Indonesia. Are you really contending that it's not notable"? Um, no. I contend that it is a Wikidata bluelink without any corresponding article, you know, the kind you claimed don't exist.
            • ""A template that adds, in the mainspace, a link to edit another site is spam for that site." - you mean like the [Wikidata item] link in the tools menu on the left of articles is spam?" You know the difference between our articles and the sidebar? Like e.g. links to the Wikipedia store would be unacceptable within our articles, yet can be found in that same sidebar where your "wikidata item" link is?
            • "I understand that you would oppose links to Wikigrave if it existed; I would work to make such a sister project functional and reliable for all Wikipedias. That's the difference between us." And you are welcome to try to change our policies to allow inclusion of Wikidata info in our articles once that project is functional and reliable. At the moment, you are replacing a poor system (enwiki) with a worse one (Wikidata, purely on ideological grounds, and are too blind to see any problems with it, even when they are demonstrated to you step by step. i'm glad there is a difference between us, I really don't want to become like that. Fram (talk) 14:27, 25 January 2017 (UTC)[reply]
              • I only seem not to reply to your arguments because you're not making any. In what sense is "the bluelinks to Wikidata [...] show that although a linked item has no Wikipedia article, it has a Wikidata entry and hence an entry in another Wikipedia." not true? If you mean that not every entry in Wikidata has a corresponding entry in a Wikipedia yet, then I agree. But you don't seem to understand Wikidata's inclusion criteria, which require Wikidata entries to be notable in the sense that a Wikipedia article exists or could exist. Don't nit-pick a tiny number of exceptions to the general rule that applies to over 25,000,000 data items, and pretend it invalidates that general rule. As for "fixed what - there was no error", that's playground logic. I fixed a dispaly issue that you complained about, not an error in any meaningful sense of the word. You're just trying to play games instead of engaging with the real issue, which is that the infobox you've named for deletion on spurious grounds performs its job very well, without errors.
              • We have no policies or guidelines that disallow inclusion of information fetched by this infobox from Wikidata, and you know it, otherwise you'd have quoted them. Put or shut up instead of hand-waving vaguely. On the contrary we have a strong and long-lived consensus that Wikidata may be included in infoboxes. Period. You have no argument, just a desire to do an end-run around a result you don't like. Your assertion that restricting the source of edits to editors on Wikipedia only will somehow magically make the edit "more reliable" is pure nonsense. How does the standard infobox prevent a local editor from adding an unsourced statement? It doesn't. How does the present infobox prevent the display of a field like 'genre' when editors at the article have reached a consensus that it should not be included? It can't. Yet the infobox that you want to get rid of gives editora the functionality to do both of those things. And you have the nerve to call that a "poorer system"? Not on the planet where the rest of us are living.
              • The sidebar is a collection of links and tools, and in a perfect world, every editor would realise they can edit the corresponding Wikidata item via that link. But the link is in the infobox because editors asked for it. If you want to change that consensus, the place to raise it is at the template talk page, although you'd better have some better arguments than the process-wonkery of your claim that such links are "unacceptable" in an infobox. Unacceptable to whom? You? You won't get very far like that.
              • Don't call me blind. Particularly when you can't see an improvement when it's staring you in the face. You've demonstrated nothing. Each one of your false claims about this infobox have been demolished. You still don't address the main issue: that this infobox provides editors with extra functionality if they choose to use it, and has no detrimental effect if they choose not to. Your entire and multiple contributions to this page consist of you either making false claims or venting your spleen about Wikidata. You've provided no reason to delete this on-going piece of work other than your simple dislike. You could at least be honest about that. --RexxS (talk) 18:46, 25 January 2017 (UTC)[reply]
                • "In what sense is "the bluelinks to Wikidata [...] show that although a linked item has no Wikipedia article, it has a Wikidata entry and hence an entry in another Wikipedia." not true?" Really? You still don't get this? Hopeless. "But you don't seem to understand Wikidata's inclusion criteria, which require Wikidata entries to be notable in the sense that a Wikipedia article exists or could exist." Not according to our notability criteria, no. We won't have Wikipedia articles for all articles in scientific journals, which you happily add to Wikidata. (Nor will there be enwiki articles for properties like this or this or this, of course).
                • "We have no policies or guidelines that disallow inclusion of information fetched by this infobox from Wikidata, and you know it, otherwise you'd have quoted them. Put or shut up instead of hand-waving vaguely." Read this very discussion, I have quoted some of the relevant bits from WP:V, which is policy. That I don't repeat them at every occasion is a futile attempt to limit my wordcount here.
                • "Your assertion that restricting the source of edits to editors on Wikipedia only will somehow magically make the edit "more reliable" is pure nonsense. How does the standard infobox prevent a local editor from adding an unsourced statement? It doesn't." I didn't claim that. But the vandalism reversion rate is a lot better at enwiki than at Wikidata. That's why I said "you are replacing a poor system (enwiki) with a worse one (Wikidata)".
                • "the infobox you've named for deletion on spurious grounds performs its job very well, without errors." Not true, see your edit to John S. Duncan. And of course, we have an infobox which works very well, without errors, already...
                • "How does the standard infobox prevent a local editor from adding an unsourced statement? It doesn't. How does the present infobox prevent the display of a field like 'genre' when editors at the article have reached a consensus that it should not be included? It can't. Yet the infobox that you want to get rid of gives editora the functionality to do both of those things. " Really? So with the infobox up for deletion I can't add an unsourced statement in it, and I can't add a parameter you want to see suppressed? That's of course demonstrably not true. An editor can still add the field "genre" in the Wikidata version of the infobox, and obviously they can just as easily remove the genre value from "suppressfields" as they can add the genre parameter in the current version (the same applies to sourced vs. unsourced). Adding a false sense of security which in reality achieves nothing we can't have now, but is needed to avoid some of the additional problems caused by including Wikidata, just shows that the Wikidata template is worse, not that it is better.
                • "Each one of your false claims about this infobox have been demolished." True. This leaves only my true claims to deal with. "You still don't address the main issue: that this infobox provides editors with extra functionality if they choose to use it, and has no detrimental effect if they choose not to." You leave out the "has detrimental effects if they choose to use it" part, which is the crux of the issue. That you continue to put your head in the sand about the many issues demonstrated so far is not my problem. Fram (talk) 08:30, 26 January 2017 (UTC)[reply]
                  • You're like a dog with a bone about links to Wikidata. I tell you what, if you don't believe me, for every example of a Wikidata entry that doesn't have a corresponding article yet, I'll give you 10 that do, and we'll see who runs out of examples first. Now do you understand what I'm trying to tell you? Links to Wikidata have a beneficial value 99.9% of the time when there's no article on English Wikipedia. WP:BUILDTHEWEB.
                  • There is absolutely nothing in WP:V that this infobox does not respect. Do I need to remind you of the debacle you created at John S. Duncan when you removed a Wikidata-aware infobox that was filtering out unsourced information and added an unsourced alma mater to the infobox? Which of us is showing understanding of WP:V?
                  • Vandalism by adding a piece of false data at Wikidata has no effect here when our infoboxes filter out unsourced information. Vandalism by adding a piece of false data on en-wp has no such safeguard. That's why you're wrong to think that the system we're developing isn't better than the current one.
                  • There are no errors in the version of John S. Duncan that you reverted. You're removing things you don't like, not correcting errors. This template works at least as well as your preferred version on that article. And edit-warring with four reverts in two days to preserve your version when there is a debate open on the talk page is no way to behave on Wikipedia.
                  • It's not me who's making decisions about only including sourced information. That's WP:V, remember? As for suppressing fields, it not me making that decision either. I'm merely giving tools to editors like Sarah who has a consensus on a featured article she curates, Night (book), that 'genre' should not appear in the infobox. At present there is nothing to stop a new, uninformed editor adding things like 'novel', but this infobox can ensure that it is not displayed. That's a good reason to keep these developments not delete them.
                  • You have no true claims. There is not a single extant example of any detrimental effect from using this infobox. Nobody upgrading an article from {{Infobox person}} to {{Infobox person/Wikidata}} today would see any detrimental effect. Nothing you've claimed is reason to delete this template and the obvious advantages demonstrated throughout this discussion are clear evidence that it should be kept. --RexxS (talk) 17:00, 26 January 2017 (UTC)[reply]
  • Make subst-only wrapper that converts this into a standard infobox per Pppery. The ongoing sourcing issues with Wikidata are too great, and changes there often do not show up on watchlists. But it can continue to exist as a subst-only template for initially populating infoboxes; that use is not problematic, as long as it's a human doing the substing and checking the quality of the results. —David Eppstein (talk) 17:08, 25 January 2017 (UTC)[reply]
  • Delete or make subst-only wrapper per David Eppstein above. Wikidata is profoundly unreliable, and no claim from there should ever be automatically imported and displayed in a Wikipedia article without being individually vetted and checked against sources by editors. Using Wikidata for initially populating a box may be okay, if done responsibly. But as it is, placing this template on an article currently seems to amount to a blanket license for somebody on, say, the Telugu Wikipedia to add a fake birth date or a copyvio image to the article there, for this to be harvested into Wikidata some time later and then to appear on our article without anybody noticing. If this is possible, that's deeply disturbing. Fut.Perf. ☼ 08:14, 26 January 2017 (UTC)[reply]
    Wikidata is intrinsically no more reliable or unreliable than any other project that relies on user contributions, such as Wikipedia. Claims from Wikidata are not automatically imported by this infobox, but filtered to remove any unsourced information. The standard infobox does not offer that facility. This infobox only imports form Wikidata when it is enabled at the article level, and the opportunity is there for the editor who enables that functionality to vet and check against sources (in the full knowledge that they are not seeing unsourced information}. Any subsequent changes can be seen on the watchlist by editors who curate the article, so the Telugu scenario doesn't happen. Now, do you have any further objection? --RexxS (talk) 17:09, 26 January 2017 (UTC)[reply]
    • "Claims from Wikidata are not automatically imported by this infobox, but filtered to remove any unsourced information. " False. Claims are automatically imported "unless you set an extra filter on". On e.g. the BLP Samir Amin, the infobox now includes information from Wikidata which has "references" like "Imported from English Wikipedia", or no references at alll. So yes, we are seeing unsourced information. In this case, probably correct information, but that doesn't make your claims true. Fram (talk) 17:27, 26 January 2017 (UTC)[reply]
      "Claims from Wikidata are not automatically imported by this infobox, but filtered to remove any unsourced information. " True. Every editor at the article level has the opportunity to set |onlysourced=yes or |onlysourced=no - maybe they want to see all the information available from Wikidata. I'm giving them the choice. Samir Amin was so easy to fix and now only sourced information is displaying in the infobox. If you're trying to tell me in your round-about way that you want |onlysourced=yes to be the default, then I can make that happen anytime. Or you could - just alter the default in Module:WikidataIB; it's on lines 108 to 121. --RexxS (talk) 18:10, 26 January 2017 (UTC)[reply]
      As far as I can see, unsourced claims aren't filtered in the default state of the template, unless you set an explicit "onlysourced" parameter. The current doc recommends to set this parameter for BLPs, but to leave it out for other articles. However, (1) even your own current practice in this test run doesn't live up to this modest standard, as the template has in fact been added to BLPs without that parameter, so no filtering is in fact being done now, and (2) unsourced information in non-BLPs is only marginally less bad than in BLPs anyway. I checked about four or five random articles, both BLPs and non-BLPs, and every single one of them displayed a birth date that was unsourced or circularly sourced (although, of course, most of these had already been in the articles before, and most may well be correct). As for the watchlist notifications, how does that work? I can't find anything about that in the doc. Fut.Perf. ☼ 17:38, 26 January 2017 (UTC)[reply]
      I apologise for the mistake in omitting |onlysourced=yes in some of the BLPs. I'll ping Mike Peel just to let him know of that concern. Actually, I'm coming to the conclusion that having |onlysourced=no would be better as default, as it's more failsafe. Would you agree? You enable Wikidata watchlisting by unticking the little box for Hide: Wikidata near the top of your watchlist. --RexxS (talk) 18:18, 26 January 2017 (UTC)[reply]
      Actually, scratch that question. I've flipped the default for |onlysourced= so that leaving the parameter out defaults to applying the filter. It's almost certainly better that way. --RexxS (talk) 18:27, 26 January 2017 (UTC)[reply]
  • Delete per Fut.Perf. Ealdgyth - Talk 13:46, 26 January 2017 (UTC)[reply]
  • Comment. Tom, adding unsourced or poorly sourced data about living persons is a violation of WP:BLP, so I'm surprised to see that this was created, and that it's being added to BLPs. Wikipedia:Requests for comment/Wikidata Phase 2 was closed as: "It is appropriate to modify existing infoboxes to permit Wikidata inclusion ... There is sufficient support for option 3 however, to indicate that this modification should be done carefully and deliberately, at least at first." Option 3 was "Wikidata would be integrated in a very limited way, only with local editorial consensus, and can be reversed easily on that specific article."
    We need an RFC to get clear consensus from the community that it wants material from Wikidata in BLPs, whether in the body, infobox, external links or anywhere else. Tom, can you say how you see this as consistent with the BLP policy? Can we agree that it will not be used in BLPs until there's community consensus? SarahSV (talk) 16:46, 26 January 2017 (UTC)[reply]
    • SlimVirgin: When I created this template, the intention was to show that it was possible using an extremely small number of articles (under 5, if I recall correctly) as a technical test, using a small number of uncontentious properties, on generally uncontentious people, and with the intention of allowing the local community to override material locally. At that stage, the intention was simply "let's see if it is technically possible", and the articles I tested it on, I quickly self-reverted in a matter of a few minutes. No readers were harmed in said experiment. In retrospect, living people is probably not the best domain to start such an experiment. I can't comment on whether it adheres to the relevant RfCs because the technical testing I did was before any RfCs were actually held. I don't know what has happened to this template since because, like a busy magpie, I quickly got distracted by other shiny things (actually, life just got a lot busier). I still think Wikidata has plenty of possible value. Based on the discussions, I've been working on some code to try and check and validate referencing and sourcing on Wikidata. I think there's way too much heat in the discussions on enwiki about Wikidata, and instead of "I spotted one mistake on a BLP once, burn it all to the ground" (an attitude which sees only cost and no potential benefit from, say, centralised consistency checking), there ought to be more productive good-faith efforts to try and see how to make Wikidata and Wikipedia work together better. —Tom Morris (talk) 17:10, 26 January 2017 (UTC)[reply]
      • Tom. when you get a minute, perhaps you could look at the documantation for Module:WikidataIB, which is where your original efforts have lead over the last (almost) four years. The ability to whitelist or blacklist fields and to enable or disable, as well as filter out unreferenced information, all on a per-article basis has been developed following considerable feedback. I'd be really pleased to work on any suggestions you might care to make for further improvements. Cheers --RexxS (talk) 17:18, 26 January 2017 (UTC)[reply]
      • Tom, thanks for explaining. I think there would have to be an agreement that this not be used on BLPs for now. Otherwise deletion makes sense. SarahSV (talk) 17:35, 26 January 2017 (UTC)[reply]
  • Keep I am suspicious of WikiData and the quality of live links based on it. But that issue of principle already seems to have been decided in the implementation of the interwiki links. I was showing a new editor how to do this for a BLP the other day and there is no alternative in that case. This new template is obviously tentative and a work-in-progress. It should be allowed some space in which to try and work out the issues which arise. A deletion discussion is not an appropriate forum or method for resolving the scope of this. There should be a separate guideline page for such work where the parties can make their case for and against. Andrew D. (talk) 17:49, 26 January 2017 (UTC)[reply]
  • Keep – Ample consensus in 2013 to go along this path, now steady steps in efforts to improve integration of Wikidata into Wikipedia. This is similar to the integration of inlterlanguage links that happened years ago. No reason to stifle progress for fear of disruption which is not happening. — JFG talk 09:51, 27 January 2017 (UTC)[reply]
  • Delete Or other technical measure (subst etc) to prevent the template directly displaying data on articles it has drawn from Wikidata - where less than 25% of the information is likely to be sourced. Let alone reliably sourced by our criteria. Only in death does duty end (talk) 10:25, 27 January 2017 (UTC)[reply]
    • Why would you need to prevent this template from directly displaying data on articles it has drawn from Wikidata, when it has been designed to filter out any unsourced data? --RexxS (talk) 03:19, 28 January 2017 (UTC)[reply]
  • Conditional It is asserted that this is an "experimental" template. This experiment is clearly contentious, and the intended goal is to impact a staggering number of articles. If the primary editor(s) adding this template agree to cap this experiment to the current articles, and agree to seek a more specific mandate at Village Pump before adding this to additional pages, then this can be a "Keep for capped experimentation". If not, then consider this a "Delete to prevent disruption" of disputed edits&issues from spilling out across unbounded thousands of article pages. Alsee (talk) 07:23, 28 January 2017 (UTC)[reply]
  • Keep – as stated above, the 2013 RfC showed clear consensus for this. The concerns about Wikidata being mostly unsourced are laughable, I could say exactly the same thing about Wikipedia. There is a huge amount of standard infoboxes that are unreferenced, migrating them to Wikidata neither makes it better nor worse. Laurdecl talk 14:32, 28 January 2017 (UTC)[reply]
No, she isn't really that old, she died in 1986
Using the firsl line of the article as the image caption? Useful!
She died
  • In the past week, this template (claimed to work without problems) has produced at least the following errors
    • Showing the website twice in the infobox
    • Showing "Died" without a date or further information as only field in the infobox
    • Calculating an "age" when the birth date was sourced in Wikidata, but the death date wasn't, giving e.g. in Margaret Blackwood an infobox which as only information "born 26 april 1909, age 107"
    • Trying to introduce references from Wikidata here, which resulted in tons of bare urls, wikisource as a reference, duplicate references...

This thing is not ready to be used in articles at all. Fram (talk) 08:26, 30 January 2017 (UTC)[reply]

That's a lie. it's perfectly ready, if not yet perfect. At least in a limited number of articles where it can be monitored. You might not be aware, but changes to a template as it is developed reflect in many different ways on articles. All templates have that issue, but that doesn't make it a reason for deleting all templates.
  • Website showing twice: fixed.
  • Showing 'Died' label without date: that was so simple to fix, you actually fixed that one yourself, Fram!
  • Calculating age: fixed
  • References: fixed
Where are your examples of these problems today? You brought no diffs, because you know that each and every problem has been promptly addressed.
If you ask me if I think the development of the template should be slower, I'd say "in an ideal world, yes". But the exposure this template is getting from your rants is now bringing in new editors keen to work on its development, and it is a consequence of the way Wikipedia works ("anyone can edit") that the pace of change is increasing. --RexxS (talk) 14:40, 30 January 2017 (UTC)[reply]
RexxS, can you please address a difference of opinion in other words than "that's a lie". I don't consider a template with this many problems "ready to be used", you do. There is no lie involved in any of this. You notice the signature at the end of my comment? That means that it is my opinion of this infobox, not something that is binary true or false. The problem that was "so easy to fix" that Mike Peel fixed individual articles where it happened, instead of the template? None of these problems were found by you, all were raised by those opposing the template because we actually monitor these articles on accuracy and stupid infobox errors, not just to check that no one has removed our precious infobox from it. The calculating age is not fixed, people who have a birth date and death date in enwiki but only a sourced birthdate in Wikidata still get a wrong age on enwiki. References isn't fixed, you only have the options "show poorly formatted references" or "show no references" on enwiki, neither is really a good solution. All these are in accition to the fundamental problems enumerated enough times already. Fram (talk) 14:59, 30 January 2017 (UTC)[reply]

And of course, after compiling the above list, things just got worse. User:Laurdecl, another proponent of this infobox, succeeded in sourcing a BLP [8] to a porn site (linked at ANI report, I'll not link it here as well). Fram (talk) 09:50, 30 January 2017 (UTC)[reply]

  • Delete or make subst-only wrapper per David Eppstein. Wikidata is simply too flawed for its data to be indiscriminately imported into the English Wikipedia, and users (especially IPs and inexperienced editors) should not have to go off site, to an unfamiliar and often extremely clunky interface, to make corrections in articles. Deor (talk) 12:30, 30 January 2017 (UTC)[reply]
  • Keep. The strategic importance of Wikidata to Wikimedia becomes increasingly clear, over time. It presents opportunities, rather than threats. The tactical issues do have to be hammered out, and this template is obviously at the sharp end. I'm concerned about the misleading comments in circulation. But let me just focus on one particular point here. Wikidata allows for the distinction between Gregorian and Julian dates: it is wired in. Sorting out the calendar in use bedevils British history over a period of around 170 years, and I come across worries of this kind on a daily basis. There really has been no effort here to do anything comparable. Going forward, I can see the potential advantage, in terms of a step-change in the scholarly standards applied. So I think the anecdotal evidence that such infobox development is going to be problematic should be treated in a measured way. Templates have talk pages, and what we need more of is the talk page motto, of addressing comments towards improvement, rather than anything else. Charles Matthews (talk) 13:42, 30 January 2017 (UTC)[reply]
    • You are focusing on one particular point which hasn't brought an improvement to any article with this template so far. Wouldn't it be better or more convincing if you a) focused on some real current benefits from this template, and b) actually discussed some "misleading comments" instead of just insinuating that these are thrown around without providing anything concrete? Basically, att he moment all you have is "keep for reasons which have nothing to do with the current template". Fram (talk) 14:06, 30 January 2017 (UTC)[reply]
      • Please do not use terms like "insinuating", which connotes some sort of manipulation. You and I have discussed one source of that kind kind recently. No, I don't accept any of that. If you propose a template for deletion, you are deliberately trying to cut off a line of software development. What I'm talking about might be just a tweak away. I dispute that my comment has "nothing to do with the current template", and you say that without real justification. Also, talking about one advantage also doesn't mean there are no other advantages: it is a civilised habit to say, "for instance, X". I know developers who say "there is no use case for ...". but the way they deploy that argument, in my experience, does not require the statement of a full use case in reply. It tends to mean "my agenda should trump your agenda". Charles Matthews (talk) 15:17, 30 January 2017 (UTC)[reply]
      • This template provides functionality that {infobox person} does not. Using it provides: up to date information from a central repository; the guarantee that unsourced data does not appear; the ability to suppress a field completely; and the potential to automatically include new, sourced information as it becomes available or becomes referenced. The fact that you've studiously ignored these benefits because they don't fit your theory that "Wikidata is evil" is a complete indictment of the narrow-mindedness of automatically trying to destroy anything related to one of our sister projects. You also ignore that whatever we develop here and improvements we make to Wikidata as a result of our experiences with importing data, will all become available to another 300 Wikimedia projects. I understand that you don't care about other language Wikipedias, but most of the rest of us do. --RexxS (talk) 14:40, 30 January 2017 (UTC)[reply]
        • "Up to date information"? Not really, there is no guarantee that the information at Wikidata is any more up to date, and in general is less so. "the guarantee that unsourced data does not appear" is useless if the data is as poorly sourced as it is at Wikidata. A false sense of security is worse than a known lack of sources on the enwiki infobox. "the ability to suppress a field completely" is something you have in the Wikidata template and not in the standard infobox person? Really? Please exaplin how you will achieve this, as at the moment it is just as easy or as hard to suppress and unsuppress something in either variant. "the potential to automatically include new, sourced information as it becomes available or becomes referenced." has, apart from the sourcing problems, also watchlist problems, and the fact that not everything that gets added to Wikidata is welcome at enwiki (e.g. "citizenship" should only be rarely used on enwiki, but is supplied standard by /Wikidata. I have not ignored these "benefits", I just see the problems these have (in theory, and over the last few days in practice as well). Feel free to create and test this template on another language wikipedia though, they may suffer the benefits for a change. Feel free to come back once you have a good template and a site with much better data and sources to support it, in 5 or 10 years time. But replacing what we have with something worse because one day it may become better is not the way to go. Fram (talk) 15:07, 30 January 2017 (UTC)[reply]
            • Well, now we have disinformation: "if the data is as poorly sourced as it is at Wikidata". We have to distinguish what "poorly" might mean, don't we? For it is clear and definite whether a given statement on Wikidata is referenced or not. Not so here: a reference at the end of a Wikipedia paragraph might support the whole paragraph, or just the last sentence, and there is no way at all of telling. And it will not be possible here until references are explicitly tied to areas of text. Conclusion: what is unreferenced on Wikidata is clear, in a way that can be automated. One can indeed go into a more granular discussion of acceptable sources, and then verification of whether the source supports the statement. These issues are identical for the two sites. Since Wikipedia is 11 years older than Wikidata, it may appear that Wikipedia does better, but I expect that is mainly to do with contentious areas where people work hard on source-criticism. There are really poor areas of enWP when it comes to sourcing, believe me. Per the pot calling the kettle black, which I have mentioned to you before, I think we have to face up to the argument that you are using being selective with the evidence. My experience with BLP, for example, which I avoid but have been involved in when I couldn't escape, is that here they can be gamed by a number of methods. Incrementally, the proposed use of Wikidata (in which I have no personal stake, since I don't add infoboxes to biographies) can be very helpful. I care about dates, and as soon as you get away from well-known historical figures, there are problems to which a central repository, with discriminating referencing, is the best solution. Charles Matthews (talk) 15:38, 30 January 2017 (UTC)[reply]
              • What about that statement is "disinformation", given the many examples of poorly sourced examples used in this very discussion? Poorly as in using a 1911 source for a 1928 death? Or as using unrelated porn sites for information on a BLP. Giving the website for an entity disbanded in 1970, and where the supposed website has no information on that entity? Or sourcing full dates to sources which only list years? "What is unreferenced on Wikidata is clear" is true, but what is actually referenced on Wikidata (and not just "has a reference added to it") is very unclear, but is accepted (and even promoted as a quality) blindly by the people promoting this infobox. In a future, Wikidata may become the solution: but this discussion is about a live infobox, used in live articles, now, not about what might happen one day. Enwiki is not the sandbox for Wikidata. Fram (talk) 16:32, 30 January 2017 (UTC)[reply]
    • Again, no reason to accept your argument. I have challenged you with selective use of evidence, i.e. a well-known fallacy. Anecdotal evidence, or even a Matthews family joke, "generalising from one or fewer instances" (see below, universities are not persons), is not a defence. A fair-minded approach would help. You also seem to think that your role as nominator here means we have to follow some guidelines you lay down. Not so.
    • But to be more constructive: the automation available on Wikidata means that the referencing of a particular type of statement, say "place of birth", to URLs, could be monitored in terms of a blacklist and whitelist. In other words, it is quite within reach to query Wikidata and scrutinise web referencing, for all pages here that use any given template. This is not quite something I could do today, but given a couple of hours I could probably use SPARQL and Petscan to extract those as a column of data. Experts would be quicker. I think this advances the discussion: "acceptable" referencing for invoked statements could be monitored. As you have pointed out, the verification that the reference supports the claim is tougher. Indeed so, but note that Wikipedia has the extra layer of paraphrasing (even translation) of the source text to deal with; not a problem in quite the same way for Wikidata. Charles Matthews (talk) 17:17, 30 January 2017 (UTC)[reply]
      • "Universities are not persons": thanks :-) The University example appeared in a person infobox though, as the employer of someone, so it is an actual example from this infobox under discussion, not something irrelevant. Note that "all" (not really all, but most) information in this infobox needs to be in the Wikipedia article in the first place, and must be sourced in the article (and then not necessarily in the infobox). We will now get information in the article, and the same information in the infobox sourced to another source, or to the same source formatted differently, or different information, or... The synchronization between articles and infoboxes, which should be there now, is lost with this /Wikidata approach. Coupled with the strong impression that Wikidata at the moment is still less reliable and less monitored than enwiki, and I don't believe we should use this. Fram (talk) 17:27, 30 January 2017 (UTC)[reply]
        • Parts of enWP are more reliable and monitored than parts of Wikidata, true. But also vice versa. What would be good would be if we could source data to some of the less reliable parts of enWP, from parts of Wikidata that have been well worked-over. A refusal to see value in anything of the sort seems to me obtuse. There is the reasonable case for monitoring Wikidata differentially, to which I have given some substance above. Your style of argument here is not really designed to persuade, you know. I see plenty of need for: documentation; discussions of good practice; tech support; rationing of statements drawn from Wikidata. I see no need for denigration of either community's efforts, given that I belong to both of them, and they are supposed to be on the same side anyway. I have for a long time championed the view that a fundamental community principle that issues should not be forced (and I see faults on both sides on this issue, which is what I would expect). There is a win-win outcome to be had, but it is hardly going to arise from acrimony. The case of dates is more subtle than it may seem, and we know that there can be rewards simply at that level. (Synchronisation of dates here is poor: plenty of date categories are wrong, and one main cause seems to be simple human error, so there is a lot of work to be done simply at a baseline level.) Charles Matthews (talk) 19:10, 30 January 2017 (UTC)[reply]
          • "A refusal to see value in anything of the sort seems to me obtuse." True. That's why I haven't opposed (or nominated for deletion) things like infobox telescope, where you have a clearly defined, exact set of values which can go in an infobox, not some fuzzy, often harder to reference facts about a person. Some infoboxes are much more logical to attempt to convert to Wikidata than others, and infobox person (and by extension all person-related infoboxes) are at the bottom of that list, not at the top. Wikidata isn't ready yet for this kind of thing. Fram (talk) 08:08, 31 January 2017 (UTC)[reply]
        • As an example, a Wikidata page you are aware of, since you added a fake link to enwiki to it yesterday[9] (that link is a redirect to another article which is about a different Wikidata subject). That page also, since yesterday as well, lists the official website of the "University of Strasbourg (1538-1970)". Weird, a university which no longer exists since 1970 but whch has an official website? This is it, the website of the Académie de Strasbourg, [10], an institution which has its own Wikidata page [11] which doesn't list a website... The website given for the 1538-... university doesn't have any results for "1538" or about this historic aspect of the current university. So much for "accurate, up to date, sourced information". Like I said, a false sense of security, but not a site to base infoboxes or articles on. Fram (talk) 15:25, 30 January 2017 (UTC)[reply]
  • Keep: template has potential benefits which should be explored and developed further as Wikidata becomes more refined, accepted and integrated into Wikipedia. — Martin (MSGJ · talk) 21:12, 30 January 2017 (UTC)[reply]
  • Delete If only to stop the disruption being caused on dozens of BLPs; the data being imported is not adequately sourced and, as has been demonstrated, this "experimental" template is now being added to articles by some inexperienced people stirring up even more problems. SagaciousPhil - Chat 11:50, 31 January 2017 (UTC)[reply]
  • Keep agree with the points made by Charles Matthews and Mike Peel above. Duncan.Hull (talk) 22:59, 31 January 2017 (UTC)[reply]
  • Keep. I agree with some of the concerns raised, but I don't think this is the right forum to resolve broader concerns about Wikidata. As far as I can tell this template complies with the existing consensus on use of Wikidata. Another RfC would be needed to change that. Mike Christie (talk - contribs - library) 10:43, 1 February 2017 (UTC)[reply]
  • Make subst-only or delete. Unless Wikidata's sourcing policy is at least as strong as Wikipedia's, would violate WP:BLP in articles on living persons. I haven't checked Wikidata's policies, but Wikidata accepts sources from Wikipedias which have weaker verification policies. — Arthur Rubin (talk) 09:28, 3 February 2017 (UTC)[reply]
    • Could you give some examples of Wikidata accepting sources from Wikipedias which have weaker verification policies? I'd be happy to look at ways of improving the filtering available in this template to exclude problematical data is it actually exists. Two pages on Wikidata that would shed some light on your fears are d:Wikidata:Verifiability and d:Wikidata:Requests for comment/Verifiability and living persons and I doubt that the participants at Wikidata really want weaker verifiability than we strive for here. In any case, adding unreferenced information is easy to do directly here; at least this template can filter out information that is unsourced or simply "Imported from Xyz Wikipedia". --RexxS (talk) 14:53, 3 February 2017 (UTC)[reply]
      • @RexxS: I see that the Verifiability page has been tagged as proposed since 2014 - I've actually seen many pages there so tagged but the implications of that are unclear to me. Are proposed pages considered accepted practice? Can they be "enforced", a la WP:BURDEN? (And quite honestly, that RFC is more concerning than reassuring). Nikkimaria (talk) 00:54, 4 February 2017 (UTC)[reply]
        • You're right on all counts, Nikkimaria. I'm really doing my best to give a fair picture of the state of play over verification at Wikidata. As far as I can tell, proposed pages document normal practice, but I can't tell whether there's any will to enforce them. I'm not an uncritical supporter of Wikidata, despite accusations to the contrary. Nevertheless, I want us to be able to take advantage of the potential resource there. If editors on Wikipedia simply decide to erect barriers to Wikidata use, then we do lose out on that potential, and this template is an attempt to explore what can be done and what issues it presents if it is scaled up. The problem, of course, is that all of the things wrong with Wikidata won't fix themselves; there needs a critical mass of editors from the Wikipedias who are prepared to engage with the community over at Wikidata constructively to fix the perceived problems. The belief that Wikidata has weaker sourcing policies is a meme that has gained traction from repetition. It would be interesting to see just what evidence there is of that – and more importantly, what needs to be done to fix either any shortcomings or the mistaken perception if there are none. --RexxS (talk) 03:54, 4 February 2017 (UTC)[reply]
          • @RexxS: I do see clear differences in terms of written "policy", for example in our more expansive explanation of what is and is not considered "reliable" as a source, on top of the "proposed" question. I also understand how that meme developed: Wikidata imported large quantities of data from various Wikipedias, and while the data may or may not have been sourced on those Wikipedias, existing sources were not also imported except manually (so far as I am aware) - leaving "Wikipedia" as the only listed source. But discussions like that RfC, as well as my own experience there, suggest to me that policy changes or even "enforcement" of current (proposed) policies would be challenging, and that there may not be will among the current community to accomplish that. I'm sure a "critical mass" of Wikipedians could force such changes if they all went over there, but I don't think such a move would be "constructive" even if it resulted in (what we would consider) positive change in policies. I am far less certain that a mass of Wikipedians advocating for change would not be viewed as "forcing" it, no matter their intentions, by the existing community. Compare for example the reaction here to people seen as "forcing" Wikidata integration ;-) Nikkimaria (talk) 04:33, 4 February 2017 (UTC)[reply]
  • Yet another problem with the infobox: at the moment, if for some parameters there is more than one sourced value in Wikidata, it only shows one of these, seemingly at random (perhaps the most recently retrieved value or so?). This was the case at Paul Sabatier (theologian) and at Concha Espina[12], and probably elsewhere as well. If we can't even be sure that the sourced values at Wikidata are shown here, then there is even less reason to use this. It has become quite clear during this week that the template, if wanted at all, is not ready to be used in the mainspace. Fram (talk) 11:12, 6 February 2017 (UTC)[reply]
    • At any time that a piece of information is not straightforward, there is a good case for leaving it out of an infobox, or at best using a local parameter if the complexity can be summarised succinctly (which is rare). In the case of Paul Sabatier, where I initially pointed out the difference in the BnF and Encyclopedia sources on Talk:Paul Sabatier (theologian), you eventually accepted the argument that both possible dates should be acknowledged. Using the local parameter |birth_date = 3 or 9 August 1858 works just as well in {{Infobox person/Wikidata}} as it does in {{Infobox person}}. If not for this template being used on Paul Sabatier (theologian), the article would still be reporting only one possible birth date – and with almost no usable referencing except to the 1911 Britannica, which could only cover the first half of his life. This template certainly is useful and helps spotlight inadequacies in the articles where it has been used. That's an extra reason to keep it. --RexxS (talk) 16:56, 6 February 2017 (UTC)[reply]
      • That when checking this template, I notice how shoddy it yet again is, and while I replace it I also improve articles, is a reason to keep the template? That's very convoluted reasoning. "At any time that a piece of information is not straightforward, there is a good case for leaving it out of an infobox" True, but infobox Wikidata doesn't follow this advice, it randomly(?) takes one bit of information and ignores another. We can leave out all information from the Wikidata infobox, just to prevent this kind of thing from happening, but then what's the point of using the template in the first place? "Using the local parameter |birth_date = 3 or 9 August 1858 works just as well in {{Infobox person/Wikidata}} as it does in {{Infobox person}}." Yes, but not using the local parameter gives no problems in infobox person, but gives problems in the /Wikidata version. You can exclude it, but who knows what the next parameter will be to give problems? Much easier to simply use the local infobox and manually synchronize it with the article. No more claims that Gevorg Geodakyan is alive and 88 years old[13], but accurate information instead.
      • Why make things complicated, with an infobox that fetches some values, but you have to exclude X and Y, and specifically include local parameter A and B, when you can simply use the local, tried and tested infobox instead? Considering the many cases of problematic information coming from Wikidata or displayed through this template we have had during this discussion, it seems a bit strange to claim that one can just as well continue to use it instead of replacing it with the standard infobox. "This template certainly is useful and helps spotlight inadequacies in the articles" Nope, it helps to find inadequacies in Wikidata (plenty), and indicates what we knew all along, that many of our articles need massive improvements. We have plenty of tags for that, one which pretends to be an infobox but in reality is a cleanup tag is not really necessary or wanted. Fram (talk) 17:36, 6 February 2017 (UTC)[reply]
        • Using this template provides an improvement for over 90% of the articles where it has been tried. The data can now be fetched from a central resource, which is updated by a much larger pool of editors that just those here, and filtering is applied to endure that any information received has a source. That's two things that the old template can't do. I think you'll find it was I who spotted that two birth dates were given by different sources, and you merely tried to pick one at random until another editor convinced you you were wrong. If you'd like the Wikidata-aware template to return two dates when two are given in Wikidata, that will only take a few lines of code to do. However, that's not a very productive use of my time because we will either omit such cases or use a local parameter whenever these rare cases arise. Why make things difficult and use local parameters for A, B, C, D, ... X, Y, Z when you only need supply Y and Z locally - and even then only in a handful of cases? Most of us already know what the shortcomings of Wikidata are, as well as the advantages and potential of a central resource. Fortunately only a few are so blinded by animosity towards a sister project that they can only see the molehills and magnify them into mountains. --RexxS (talk) 03:43, 7 February 2017 (UTC)[reply]
          • "Using this template provides an improvement for over 90% of the articles where it has been tried." Strange, in my experience replacing this template with a local one, synchronized with the article, gave an improvement in 100% of the cases. "The data can now be fetched from a central resource, which is updated by a much larger pool of editors that just those here". Nonsense. The editor pool at enwiki is still considerably larger than the one at Wikidata. "I think you'll find it was I who spotted that two birth dates were given by different sources, and you merely tried to pick one at random until another editor convinced you you were wrong." No, I replaced the 1911 date with a much more recent one from a reliable source (not "one picked at random"), you complained that the two were different (duh), and another editor actually showed that recent sources still use the other date. "Why make things difficult and use local parameters for A, B, C, D, ... X, Y, Z when you only need supply Y and Z locally - and even then only in a handful of cases?" Again, nonsense. All the Wikidata templates lacked a lot of essential data. I either need to add these to Wikidata, where I then need to add items for the sources, and probably items for the items of the sources, and then hope that the right values get returned and the references shown in an enwiki-acceptable format: or I just add them here, where anyone editing the article can immediately see them, and where anyone updating the article can easily and logically update them accordingly. Why would I maintain two sites (the article here, and the values for the infobox on Wikidata) when I can do it all here? Certainly when I see how many problems the template and Wikidata both have? Using local parameters for A, B and C is easier than adding them to Wikidata in a good format, so it is not "making things difficult". "Fortunately only a few are so blinded by animosity towards a sister project that they can only see the molehills and magnify them into mountains." Nice way of offending everyone who !voted "delete" or the equivalent of it here. Perhaps, just perhaps, there may be objective reasons why a lot of people don't think this particular use of a sister project is beneficial enough to encourage? Fram (talk) 07:51, 7 February 2017 (UTC)[reply]
            • "in my experience replacing this template with a local one, synchronized with the article, gave an improvement in 100% of the cases." Rubbish, you've not shown any improvement whatsoever by using the old template over this one when the same parameters are used. "I replaced the 1911 date with a much more recent one from a reliable source." But then on the talk page you couldn't defend your insistence on a single date, an arbitrary choice on your part. Why make things difficult and use local parameters for A, B, C, D, ... X, Y, Z when you only need supply Y and Z locally - and even then only in a handful of cases? You need to answer the question. "All the Wikidata templates lacked a lot of essential data" is complete nonsense and merely demonstrates a lack of understanding that this template can accept exactly the same local values ("Y and Z") when required. "there may be objective reasons why a lot of people don't think this particular use of a sister project is beneficial enough to encourage" - if there are, you've failed completely to show any of these objective reasons. All we've heard from you is rhetoric, not reasoning. --RexxS (talk) 17:29, 7 February 2017 (UTC)[reply]
  • Keep Probably will have to coexist for a while as wikidata gets refined and purified. flag Redflag when going to Wikidata supplied data the "occupation" property should be specifically enumerated according to a standard. The standard to which it conforms should be recorded, including the standard's year. Multiple assignments should be possible for each person (such as an older standard title code, and an updated title code; and for different occupational roles the person has played over time.) In Wikidata the person data will be stored only once. To use it in different language versions of Wikipedia will need the ability to cross reference occupational titles prepared under different systems. See for example in the U.S. O*NET [[14]]
  • Comment while wikidata gets up to snuff and centralizes data that should not change across multiple language Wikis (birth &death dates & places), and presumably someone can add a switch for mdy or dmy outputs and standardization of some fields. However, if this template, properly used cannot output accurate data then whether it's kept or not, it's on each individual user and if they insert a template that says the subject is alive and kicking 30 years after her death, errors can be reported to the appropriate noticeboard and continuing them will likely get some admin to wield the cluebat. Carlossuarez46 (talk) 21:11, 6 February 2017 (UTC)[reply]
    The date of birth this template could fetch for Gevorg Geodakyan would be either 12 August 1928 Edit this on Wikidata or August 12, 1928 Edit this on Wikidata. As you can see, both dmy and mdy date formats are already selectable by parameter, which only needs to be set once in the infobox and all dates will display in that format. The template did not previously return a date of death because, although Geodakyan only died a few weeks ago, it is essentially unreferenced - i.e. only referenced to the English Wikipedia. The online newspaper report at http://168.am/2015/12/22/578012.html has now disappeared and the only other sources Google finds are this Wikipedia and its mirrors. I've just found an Internet archive snapshot at https://web.archive.org/web/20151223042550/http://168.am/2015/12/22/578012.html, and I'll add that to his Wikidata entry, then the date of death will be referenced and will become available. The template does output accurate data, but unless it's referenced, you won't get anything at all. I find that an advantage, not a disadvantage. --RexxS (talk) 04:14, 7 February 2017 (UTC)[reply]
    • The source for the death of Geodakyan, [15] works perfectly allright for me. "Ս. թ. դեկտեմբերի 20-ին, 87 տարեկանում կյանքից հեռացել է ՀՀ արվեստի վաստակավոր գործիչ, երաժշտագետ և երաժշտական քննադատ, արվեստագիտության դոկտոր, պրոֆեսոր Գեորգի Շմավոնի Գյոդակյանը:" Anyway, the Wikidata template returned no date of death, and an age with the birth date, because the often acclaimed advantages of Wikidata (larger editor pool (doubtful) and more up to date) clearly didn't apply here, as is the case in many of the examples above. As long as Wikidata is an underreferenced, slower, smaller sister to enwiki, replacing local infoboxes with Wikidata ones is in general a bad idea. Fram (talk) 07:51, 7 February 2017 (UTC)[reply]
  • One more triumph for this template. Vasil Glavinov has an unsourced year of birth, 1872. Now the /Wikidata template is added, providing only "sourced" data, and the only data it returns is the year of birth. It is sourced at Wikidata to "ISBN-10: 0904526321" (that's it, that's the full reference). This was added late in December by RexxS. Coincidentally, the same ISBN, with all necessary information, is included in our article aa a source. That book doesn't give 1872 as the year of birth of Glavinov though. So yes, the infobox has once again highlighted an error here, which was not only copied to Wikidata (which is understandable) but then directly sourced there to a source which doesn't contain this information; and then brought back here with additional legitimation as being reliable, secure information. I'll once again change the infobox to a local one, and correct our article. Fram (talk) 09:26, 7 February 2017 (UTC)[reply]
  • Comment Just to point out to the poor soul that closes this discussion that, although Fram has been dominating the discussion here (and at AN/I, and at "Wikidata 2017 state of affairs") in a manner aimed at causing the most drama possible about any and every mistake, Fram has raised *none* of these issues at template talk page (or Template talk:Infobox person), the talk pages for the Wikidata modules (Module talk:WikidataIB, Module talk:Wikidata), or in a lot of cases (such as Vasil Glavinov) on the talk pages for the articles - which is where these discussions are supposed to take place! Attempts to be helpful and reply to concerns (particularly by the never-tiring RexxS) are often returned with a dramatic rebuttal, which rather than working to resolve the issues just flare up tempers instead. This is not the kind of behaviour that I'm used to here, which is why I haven't been avoiding this TfD far more than I should have (article creation work is so much more pleasant than this!), and I'm left hoping that this TfD is not closed based on who has been shouting loudest. Thanks. Mike Peel (talk) 10:30, 7 February 2017 (UTC)[reply]
    • Why would I spend time at the talk page of a template I want to see deleted (or at the other talk page, whoich is for the working, better version of this template)? I already fixed one error in this template for you, to prevent ongoing damage to multiple articles (while you were correcting one or two individual articles where the problem was already known instead). I found lots of errors caused by this template, which should have been found by the ones creating, changing, adding to articles, defending it (or better yet, found in sandboxes, not in the mainspace). "Attempts to be helpful and reply to concerns (particularly by the never-tiring RexxS)": you mean the obfuscation and nonsense he has sprouted here in most of his replies, never mind at the ANI discussion where uninvolved admins clearly indicated where he was rong, only to be met by selective deafness? Where has he "tried to be helpful"? When he sourced a 1928 death to a 1911 encyclopedia? When he sourced an 1872 year of death to an ISBN he copied from enwiki, even though that "fact" wasn't in that book anyway? He has given 'one' example of where he actually improved an article, Paul Sabatier (theologian), and it turned out that his help was not really an improvement at all. Still, he claims that every improvement actually made to our articles here (usually by removing the /Wikidata template) is evidence that this template is useful and working. Right... This is the kind of behaviour I'm used to here, sadly, but not the kind of behaviour we should encourage in any way, which is what you seem to be doing.
    • This TfD will not be closed based on who has been shouting loudest, but based on who has the best arguments. Your attempt to poison the well and somehow invalidate my comments because I didn't comment at your template talk page will be treated by the closing admin with the contempt they are worth. Fram (talk) 10:42, 7 February 2017 (UTC)[reply]
      • Thank you for proving my point. Mike Peel (talk) 10:51, 7 February 2017 (UTC)[reply]
        • Which was...? That I prefer to have this template deleted, and have supported my preference with actual arguments about the template? That you care about Wikidata, this template as a link to it, and the poor defenders of this template? But that you don't care a lot about providing actual arguments and having a real discussion about the merits and problems of this template? I don't think you needed me to prove those points, anyone reading the above discussion can see that for themselves. I always love it when people feel the need to point out to the closing admin that they should disregard person X and instead listen to hardwaorking, helpful person Y (who just happens to have the same opinion you do), as if the closing admin is too stupid to make up his own mind and is so gullible. Fram (talk) 11:08, 7 February 2017 (UTC)[reply]
          • I'd say that was a pretty good dramatic rebuttal, full of emotive words aimed at putting others down, which has been consistent throughout this discussion. If you'd kept things to the facts, I'd have felt a lot more able to participate in this discussion. Mike Peel (talk) 11:52, 7 February 2017 (UTC)[reply]
            • If you present any facts to rebut, I'll be more than happy to try my best. Until then, I'll try to avoid "dramatic" posts full of "emotive words" like "poor soul", "dominating the discussion", "a manner aimed at causing the most drama possible", "never-tiring", and so on. Fram (talk) 12:19, 7 February 2017 (UTC)[reply]
              • Here are the facts: you moaned about 'visual clutter'. I explained that the pen icons linking to the Wikidata entry (which many see as a desirable feature, not clutter) were optional and could be turned off. You complained that "one needs to add parameters not provided by Wikidata", carefully omitting to mention that you have to add more parameters to the old infobox. You even complained that "Wikidata was correct", but somehow, even that wasn't good enough for you. On the other hand, I've ensured that only sourced information is returned by default; that fetching Wikidata has to be a positive decision by editors at an article (otherwise the behaviour defaults to that of the old infobox); that dates are displayable in either dmy or mdy format consistently within the infobox; and that the documentation insists on editors checking for consistency between article and infobox wherever it is deployed. During the course of this debate, errors in both articles and Wikidata have been discovered - and all of them have been resolved. All of them. Not one problem that you or I have found remains today. This template does indeed expose these issues quite quickly, but simply because of your animosity to anything Wikidata-related, you're not able to acknowledge that. --RexxS (talk) 17:29, 7 February 2017 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Wikidata image

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was keep. Recent changes to this template appear to have mitigated most of the concerns by the delete camp. If these changes do not adequately fix the issue, there is NPASR. Primefac (talk) 17:10, 8 February 2017 (UTC)[reply]

This template incorrectly checks whether an article has no image while the Wiidata entry has one. As shown on the talk page, way too many of these are false positives (C. Yarnall Abbott, Stephen Albair, Carlos Albán, Charles Aaron, Rowena Meeks Abdy, Fuad Abdurahmanov...) while others have an image on Wikidata which isn't really wanted anyway (Al-‘Abbas ibn ‘Abd al-Muttalib, Sabina Abdullayeva, ...)

This template is used on more than 400,000 pages, results in a maintenance category Category:No local image but image on Wikidata of some 6,500 pages, but doesn't really provide a useful list since way too many of these don't belong in the category.

I tried to disable the category a being disfunctional, allowing people to correct it. This was reverted without improvements. Fine by me, then let's simply delete it. Fram (talk) 12:39, 24 January 2017 (UTC)[reply]

  • Speedy keep Flagrant breach of WP:POINT. See the template's talk page, and note that prior to this nomination, I reverted Fram's blanking of the (protected, high-use) template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:52, 24 January 2017 (UTC)[reply]
    • And what negative effect had that blanking of a template-editor protected (not admin protected) template? It didn't break anything, it just slowly depopulated that incorrectly filled "maintenance" category. Please don't shout "point" every time you feel the need to revert one of my actions out just because. Fram (talk) 12:55, 24 January 2017 (UTC)[reply]
    • Speaking of WP:POINT violations, I have reverted your addition of a really terrible image at Sabina Abdullayeva, which just happened to be an example I gave above.
  • Comment (and e/c), let not the perfect be the enemy of the good-enough? 6k/400k is still "98% accurate" roughly speaking. If there are 'too many' false positives, it would be nice for the category to be 99% or even 99.999% accurate, sure... but that does not sound like we better delete this sucker that sounds like when somebody has time to fine-tune this thing it will be appreciated. Is the category harming the encyclopedia? If not, and at least one person finds it useful.... 47.222.203.135 (talk) 12:57, 24 January 2017 (UTC)[reply]
    • The other 394k do nothing, a check is done on articles and nothing is done with it. So this 98% is not useful to anybody at all. The question is how many of the 6k are just plain wrong or useless. It seems to me to be close to 50%, which is way too high. Fram (talk) 13:15, 24 January 2017 (UTC)[reply]
      • So there are two possible practical problems here, that I can see, plus one a bit more theological: one pragmatic concern is, maybe there is some kind of unacceptably-high server load, related to the ~3k of 'not-even-wrong' entries in the category? And the other is, that you would like (or some hypothetical somebody would like) to work on correcting the 'really-do-belong' other ~3k of category-members, and the miscategorizations are hurting productivity. And if that is all this is about, then I would argue for a weak keep; because frankly, when I search for AfD refs on search engines, even specialized ones like scholar.google.com, I would be utterly delighted to get HALF the search-result-hits as *actually* useful to me. I'm getting the vibe from comments by others below, that about half the entries in the category *are properly* therein, and ought to be there, AND ought to be Fixed (properly fixed -- i.e. not by rote swapping the enWiki-preferred infobox-image in favor of the wikidata-preferred-default infobox-image). 47.222.203.135 (talk) 16:24, 25 January 2017 (UTC)[reply]
      • That said, there is also (possibly) a potentially-much-more-important 'theological'-type of issue here, however: a possible design-bug, from the example of T.Bach you mention below, and especially the revert of C.Aaron, and doubly-especially the case of S.Abdullayeva, indicating that maybe the current design of wikidata and infoboxes, might be poorly thought out and/or over-rigid?... *Is* there really no way to properly update wikidata, so that the 'non-standard' infobox image being used at enWiki in the infobox there, on articles like Sabina Abdullayeva, does NOT cause misplacement into the maintenance Category:No local image but image on Wikidata, and can instead be correctly detected and placed into the new (hypothetical) Category:Local enWiki image needs syncing with Wikidata alt-image-array identifiers aka Category:image not the same as on Wikidata or somesuch? In other words, does the current design of wikidata and infoboxes *require* that there be a single imagefile which is the 'official' wikidata image *and* also the infobox image, on all wiki-language-projects, otherwise false positives and other productivity problems result? That would be a bad design-assumption methinks, since as I understand it enWiki has some WP:NFCC-type fair use imagefiles, and maybe those are not allowed on wikidata, and definitely those are not allowed on esWiki in Spanish. But surely, templates can at least theoretically detect whether the imagefile in question is NFCC-versus-libre, and adjust accordingly? Unless the design of wikidata does not permit this scenario, as the T.Bach/C.Aaron/S.Abdullayeva incidents suggest, thereby 'encouraging' editors to replace perfectly-okay infobox images in mainspace enWiki articles with 'alternative' imagefiles because does-not-match? To me at least, that would be a design-bug, in wikidata's storage of imagefile-metadata related to infoboxes implemented as a singleton, meguesses. But iff it is *possible* to correctly populate the category in question, with few false-positives, then there is not a design flaw and thus WP:AFDISNOTFORCLEANUP probably applies. 47.222.203.135 (talk) 16:24, 25 January 2017 (UTC)[reply]
  • Note: I've no-included the deletion notification, as the template is transclued, via other templates, on over 400K pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 24 January 2017 (UTC)[reply]
  • See e.g. Thomas Bach. It has a good image in the infobox, but it isn't the same one as the image added to Wikidata, so hey pronto, this gets added to the maintenance category. The only way to get it out of this category is either change the image on Wikidata (probably causing the addition of the article in other languages to their maintenance category), or changing the image in our infobox. The ultimate goal is apparently that every language uses the same Wikidata image in an infobox, no matter if you don't want an infobox or want another image at enwiki. Fram (talk) 13:24, 24 January 2017 (UTC)[reply]
    • Cases like Thomas Bach should be in a separate "image not the same as on Wikidata" category. That is a change that needs to be made, but not a reason for deletion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:06, 24 January 2017 (UTC)[reply]
      • Why? We don't have "image not the same as on" dewiki, frwiki, nlwiki, ... why single out Wikidata? Who gives a flying fuck whether we use the same image as Wikidata or not? Filling the hidden categories with even more pointless tracking categories, obscuring the actual things that really need maintenance, is just making enwiki worse. Fram (talk) 14:29, 24 January 2017 (UTC)[reply]
  • Note that Pigsonthewing is pointily changing all mentioned articles. PLease check the edit histories to see the situation as described at the start of this TfD. Fram (talk) 13:43, 24 January 2017 (UTC)[reply]
  • Delete. Gives false positives. And: no maintenance job to be made from this category. -DePiep (talk) 15:23, 24 January 2017 (UTC)[reply]
  • This needs to be changed in order to become truly useful. As it says on User:Taketa/Wikidata Images: "some pages cannot be improved and will clutter the category, ignore these." How many people use this category? How cluttered is it? Could there be a way to add a flag that removes items that have been checked from the category, at least for a year or so? Pinging @Taketa: for expert knowledge. —Kusma (t·c) 16:26, 24 January 2017 (UTC)[reply]
    • Thank you for your note Kusma. I made this category as part of my own mini-project to add images to articles. Using this category I have added images to about 3300 articles that did not have an image, and another 40.000 articles in other languages. I do not have any overview whether or not other people use the category. I am still using the category, so I would prefer to keep it. There is no possibility to improve it, that I am aware of. All the best, Taketa (talk) 17:25, 24 January 2017 (UTC)[reply]
  • Keep and fix Causing no discernible harm as far as I can tell. If editors are behaving inappropriately, WP:ANI is that way. Cleanup categories and the template mechanics that make them work are no substitute for good sense. If this hidden category is helping users like Taketa improve Wikipedia by adding more images, I don't even really care if there are false positives, though it would obviously be better if they got fixed. If the images are inappropriate or unhelpful, other editors are free to revert their addition and have a discussion about their appropriateness. —Tom Morris (talk) 02:43, 25 January 2017 (UTC)[reply]
    • I tend to agree, but this line of thought seems to assume the false positives *can* be fixed, i.e. in the case of Sabina Abdullayeva it would be sub-optimal to *force* the imagefile used on enWiki in the infobox... to match the one on wikidata... to match the imagefiles used on other-language-wikis. Does the design of wikidata (or of infoboxes) require such cross-wiki conformity? If not then WP:TIND for fixing the categorization, but if so, I would be a bit leery of a category which inherently contains false-positives-with-no-possibility-of-detecting-them-as-false. 47.222.203.135 (talk) 16:24, 25 January 2017 (UTC)[reply]
  • Keep per Tom Morris. --Rschen7754 05:41, 26 January 2017 (UTC)[reply]
  • Keep per Tom Morris. --RexxS (talk) 17:12, 26 January 2017 (UTC)[reply]
  • Delete every Wikipedia has its differences, and Wikidata should not be forcing all of them to become unified. Pppery 20:11, 26 January 2017 (UTC)[reply]
  • Keep per Tom Morris. Note that you can link multiple images in a single Wikidata entry, so if this template isn't already checking the existing one against all set at Wikidata then it probably should do. In the case of Thomas Bach, though, it looks like this is because Template:Infobox officeholder apparently has *three* image calls, which is weird. Thanks. Mike Peel (talk) 20:38, 26 January 2017 (UTC)[reply]
  • Delete. Spot-checking found too many false positives for this to be helpful. —David Eppstein (talk) 01:15, 27 January 2017 (UTC)[reply]
  • Keep. Two days ago I examined 50 articles in Category:No local image but image on Wikidata (from "Aa" through "Ai"). I found 66% with a suitable image which I added or moved to the infobox (example). The remaining 34% had either a second non-embedded infobox without an image (example) or an image name at Wikidata which was not used (example). I updated those to exclude the article from this hidden tracking category by adding |nocat_wdimage=yes to the infobox. This new parameter was added to the infoboxes currently using {{Wikidata image}}: Infobox person and templates calling Infobox person, Infobox sportsperson and templates calling Infobox sportsperson, Infobox football biography, Infobox bandy biography, and Infobox aircraft begin. Now that articles can be removed from the category even when an image is not added, the category can eventually be emptied. I would also suggest that {{Wikidata image}} not be added to any more infoboxes until the category backlog is cleared. -- Zyxw (talk) 03:24, 30 January 2017 (UTC)[reply]
  • Keep per Tom Morris and Zyxw. It seems to be useful and is not causing any real issues as it just seems to put articles into a tracking category based on some criteria. 50.53.1.33 (talk) 20:01, 7 February 2017 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Events at the 2014 ASEAN School Games

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was Delete; deleted as G8 by RHaworth (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) AnomieBOT⚡ 12:09, 27 January 2017 (UTC)[reply]

All the event articles pointed to have been deleted as per AfD. No longer used. Peter Rehse (talk) 10:25, 24 January 2017 (UTC)[reply]

Delete per nom. Sportsfan 1234 (talk) 05:30, 26 January 2017 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Ciudad Delicias TV

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was Delete. (non-admin closure) feminist 07:42, 31 January 2017 (UTC)[reply]

This template is now effectively a subset of {{Chihuahua TV}}, much like the now-deleted Cuauhtémoc TV template. A 25-day-long RFC over the status of the XHDEH and XHCDE articles yielded very few participation, and as a result of no objections being raised to those pages' conversion to redirects, this template no longer has a reason to exist. There are no actual real local stations in Delicias. Raymie (t • c) 03:46, 24 January 2017 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Pinktulip

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete after replacing as discussed. Primefac (talk) 00:10, 5 February 2017 (UTC)[reply]

Useless. Use {{ipsock|Pinktulip}}. KATMAKROFAN (talk) 03:30, 24 January 2017 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Famous players

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was subst and delete. {{Famous players}} is a wrapper for {{Famous}}, so there is nothing to merge. Primefac (talk) 01:47, 5 February 2017 (UTC)[reply]

Propose merging Template:Famous players with Template:Famous.
Not substantially different enough from {{famous}} to warrant being separate. Ten Pound Hammer • (What did I screw up now?) 01:41, 24 January 2017 (UTC)[reply]

  • merge. Finding a better name wouldn't hurt either, I would never guess the content and use of either template by its name. Unfortunately I have no better suggestion... Nabla (talk) 19:49, 4 February 2017 (UTC)[reply]
  • Merge there is no need for a separate template here; they both have the same purpose. --Tom (LT) 00:24, 5 February 2017 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Human-centric

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was keep. There is minor support for updating the notice text and/or the /doc, but the exact wording should be discussed at the template's talk page. Primefac (talk) 16:35, 6 February 2017 (UTC)[reply]

Only two transclusions, neither of which actually seems to be relevant. This seems to be way too specific a problem to ever require its own template. Ten Pound Hammer • (What did I screw up now?) 01:36, 24 January 2017 (UTC)[reply]

  • Delete. Useless. KATMAKROFAN (talk) 01:38, 24 January 2017 (UTC)[reply]
  • Weak keep with the {{humor}} template. I can see some amusing applications for this -- space aliens, viruses, artificial intelligence... But please remember I am being completely tongue in cheek here. Montanabw(talk) 23:24, 24 January 2017 (UTC)[reply]
  • Delete, we are supposed to be human centric as most of our readers I assume are humans. This should be changed from a "Warning" to a badge of honor if kept. Doc James (talk · contribs · email) 03:34, 29 January 2017 (UTC)[reply]
    • Humans are also interested in things that are not human. You are making unwarranted assumptions about what other readers might be interested in. Boghog (talk) 11:07, 29 January 2017 (UTC)[reply]
    • Have you actually read the message in the template? This article appears to be written from a human-centric perspective. Please help by rewriting it from a point of view that treats humans as one of many relevant species rather than the only one to which it applies (my emphasis). It does not suggest deleting any relevant content about humans, it implies adding relevant and balanced (WP:DUE) content referring to other life forms. Human-centric refers to the content being unbalanced, not to the target audience. If that is fair comment on the article, it is an issue that should be addressed. This is an encyclopedia, not a medical reference. Obviously, as with any other maintenance template, it should be removed where not applicable. • • • Peter (Southwood) (talk): 06:10, 30 January 2017 (UTC)[reply]
      • I wonder if the template should support a "for example" option. Instead of asserting that there are "many" relevant species, it'd be nice to be told that this medical condition notably affects dogs, or that this virus is a serious problem for pig farming, or whatever. (And what if there are only one or two relevant species, instead of "many"? A small copyedit might be helpful.) WhatamIdoing (talk) 06:38, 30 January 2017 (UTC)[reply]
        • That's an irrelevant comment WhatamIdoing. What is relevant here has nothing to do with articles on "medical conditions". It's the articles that concern general anatomy and general physiology. The medical project on Wikipedia has traditionally claimed as these as its own, subjecting them to guidelines inappropriate for animal taxa. As a result, many of the overview or core articles in these areas are grossly deficient in relevant material on other animal taxa, and the apposite comparative and evolutionary content. --Epipelagic (talk) 07:05, 30 January 2017 (UTC)[reply]
  • Comment: This thread is dismaying. There is are specific areas on Wikipedia where this template is desperately needed. Those areas are animal anatomy and animal physiology. The medical project hijacked anatomy and physiology some years ago, claiming it owned the areas and imposing its own values and guidelines. Editors with an interest in building relevant content in these areas on animal species, and in comparative and evolutionary biology, have become disheartened. I don't know of any regular editors on animal species left now who go near the root articles if they include material on humans. There would be many dozens, if not hundreds of such articles, and the template would be applicable and long overdue for most of them. Doc James has further poisoned the well by canvassing the medical project members, and only the medical project members, and by unlinking the articles that originally displayed the template. I appreciate Doc James is massively engaged with medicine, both professionally and on Wikipedia, and it is understandable that when he looks at the world he inhabits he sees mostly a world of human medical concerns. That's fine. But it's not fine to bulldoze so relentlessly those of us who see the world in other ways. It is not "a badge of honor" to be so one-eyed. – Epipelagic (talk) 06:25, 29 January 2017 (UTC)[reply]
  • Comment: I am also really disturbed by Doc James' "badge of honor" comment. There is a tendency within WP:MED to prioritize medical subject matter above all else and to assume readers are only interested in medical content. This medical first approach is damaging the encyclopedia. Boghog (talk) 07:49, 29 January 2017 (UTC)[reply]
  • delete per nominators rationale--Ozzie10aaaa (talk) 10:10, 29 January 2017 (UTC)[reply]
  • Keep it, see this issue a lot in articles about medical conditions, also physiology and anatomy articles and the like. While I certainly do not support removing good quality "human centric" content, I do agree that many such articles do not yet provide a well-rounded and complete summary of the topic. I guess it is a case by case thing. If a topic is identified as largely concerning humans and therefore the article be weighted as such, this does not rule out the possibility of more specialised sub articles, linked from dedicated sections on the parent article, which consider the topic from different perspectives. Matthew Ferguson (talk) 13:28, 29 January 2017 (UTC)[reply]
  • Keep but should not be used on articles that are inherently human-centric; may help enhance articles that will benefit from broader coverage. — soupvector (talk) 17:47, 29 January 2017 (UTC)[reply]
  • Keep - If uses of the template have been systematically removed without resolution of the problem itself (as per Epipelagic), then lack of use does not imply lack of usefulness. Sizeofint (talk)
  • Keep - Useful in selected cases to restore balance and to remind editors that the scope of Wikipedia is wider than medicine. Boghog (talk) 04:10, 30 January 2017 (UTC)[reply]
  • Keep per Boghog, Matthew Ferguson 57 and Epipelagic. Humans are a small part of the biota. Not every article on Wikipedia is within the scope of WPMED, and even those which are can be relevant to other life forms. Current usage is irrelevant. Potential usage is far more important, and there are potentially a large number of topics where the current content may omit relevant information on other forms of life. I have run into this several times, but as I didn't know that the template existed, I just expanded the content or added a new section. • • • Peter (Southwood) (talk): 06:03, 30 January 2017 (UTC)[reply]
Keep This is a highly relevant template for many articles. When writing articles on fossil taxa its a pain to try to link to anatomy articles for bones described, only to see that the article on tibia has ONLY a single sentence mentioning other animals having that bone, and does nothing to cover the variations seen in the mammals, let alone all other tetrapods.--Kevmin § 06:51, 30 January 2017 (UTC)[reply]
  • User:KDS4444, I'd like to hear what you hoped to accomplish by creating this. WhatamIdoing (talk) 06:38, 30 January 2017 (UTC)[reply]
  • Comment: I expect a real use of the template would have been in this deleted article, where my argument concerning veterinary nasopharyngeal stenosis applications was met with short shrift. CV9933 (talk) 09:51, 30 January 2017 (UTC)[reply]
    • WhatamIdoing - What I had hoped to do by creating this template is allow editors to make readers aware that the text of a given article was oriented around the human experience/ human physiology and that it likely did not address other equally legitimate uses of the term in non-human animals. I kept coming across instances where I was looking for something broad and general in the biology articles, and I kept getting articles about "the human [article title] is" when what I had actually been looking for was an article about "the [article title] is"— everything from cerebellum to rectum, as if either no other animals had such structures or that the human version of them was so central that their existence elsewhere only needed mention in passing or could be ignored altogether. Invertzoo, if I am recalling rightly, expressed the same sentiment to me once. I will concede that most people coming to Wikipedia wanting to learn more about the cerebellum likely want to learn more about the human cerebellum... But a balanced and scientifically accurate encyclopedia article begins by discussing what a cerebellum is in vertebrates before narrowing down to the human version so immediately. I had high hopes for applying the template myself to these numerous human-centered articles. Then I hesitated, as there were so many that the task soon seemed pointless, and I didn't want to start slapping "badges of shame" on so many of these very legitimate (if, in my opinion, skewed) articles. I still consider it a legitimate template and a legitimate concern, and I had hoped that the template would find use. I did not create it as a joke. But I also did not want to try to fight any tide of opposition to its deletion if others thought it was pointless. I continue to come across ample evidence that the vast majority of Wikipedia articles on biology overemphasize the human aspect, and I consider that a flaw. But I have no wish to appear disruptive by insisting that this template be retained, even if I feel it's message is important and useful. Anyway, those are my thoughts. I had not been watching this discussion, but will do so from now on. KDS4444 (talk) 12:09, 30 January 2017 (UTC)[reply]
      • I agree that we're pretty bad at the classic field of "comp vert", even though it's the scientific basis for much of anatomy. WhatamIdoing (talk) 15:37, 30 January 2017 (UTC)[reply]
        • Yes, and a tag like this points out those discrepancies, so they can be addressed. If an anatomical article is titled "Organ (human)" then it is clear what the scope is, but if it is titled "Organ", then the scope is anything and everything that has that organ, and it should be reasonable to expect a comprehensive coverage. • • • Peter (Southwood) (talk): 18:00, 30 January 2017 (UTC)[reply]
  • Keep with conditions: The purpose of this template as explained above was to encourage editors to either expand an article or create a more general one, e.g. on an anatomical feature that is shared, often with differences, between humans and other animals. If we accept that the reader is most likely to be looking for the human-centric version, my preference would be to encourage the creation of the general article. I should add that it's not fair to blame WPMED for the lack of coverage about other animals, when the solution is always in the hands of the editors complaining: to create a forked article themselves. If this template is kept, I think the documentation should be revised to place far more emphasis on using the template to encourage editors to create a fork than to attempt to shoe-horn potentially myriad variations of a feature or condition into what might be an already lengthy article. Also, the editor placing the template ought to be required to at least initiate a discussion on the article talk page, i.e. make the |talk= parameter linking to a section compulsory. --RexxS (talk) 14:02, 30 January 2017 (UTC)[reply]
    • I haven't seen anyone blaming WPMED for lack of coverage of other animals, but there remains a need to provide the non-human information somewhere, some time. I also think that a compulsory explanation should be required, as mentioned below. No-one is obliged to act on the tag, though it might turn out to be a barrier to GA and FA. There will be work-arounds for this, like renaming to limit scope, and creating a more general article to cover the rest. • • • Peter (Southwood) (talk): 18:09, 30 January 2017 (UTC)[reply]
  • Keep I agree the focus should be on humans for anatomy articles, but it's good to include non-human animals as well (like lung and heart do).   User:Dunkleosteus77 |push to talk  14:46, 30 January 2017 (UTC)[reply]
Almost all people, when they look up things like "lung" or "heart", generally are looking for human anatomy. It's also important to discuss non-human animals, but, since the average user will be wanting human anatomy, these anatomy articles should focus largely on humans. Take the lung article, for example; it focuses mainly on human lungs, and it also has a specific section discussing lungs in other animals.   User:Dunkleosteus77 |push to talk  04:27, 31 January 2017 (UTC)[reply]
    • Wikipedia should eventually have complete coverage of human and non-human anatomy and physiology, and, for that matter, anything else that is shared with the rest of living organisms - behaviour, psychology, whatever. Even non-living things if this is relevant. This can be achieved either by sections or separate articles. In principle either way can be appropriate, depending on the amount of content. This tag does not blame anyone, (or should not be seen that way), it should be seen as pointing out a lack where it exists, like many other tags do, or should do. It would be preferable if the person who uses the tag should clarify what they think is missing, otherwise it becomes just another weapon for indiscriminate drive-by tag-bombers. We already have too many of those. This and many other improvement tags should require the person adding them to provide a serious motivation, otherwise they could be reverted with the summary stating that they are not properly motivated. The onus should always be on the tagger to be as specific as is necessary to be useful. • • • Peter (Southwood) (talk): 18:00, 30 January 2017 (UTC)[reply]
  • Keep and modify It's phrased somewhat inartfully, but there is a real problem I've repeatedly encountered in WP where human aspects of a large topic are treated as justification for exclusive content or redirections; I distinctly remember a protracted dispute over the proper scope of Swimming, Human_swimming, Swimming_(sport) and Aquatic_locomotion, in which I was successful at overriding several user's insistence that Swimming only cover humans and everything else be shunted aside to a disambiguation or "see also", but only by sheer persistence. Remember: Nothing in biology makes sense except in light of evolution. The human skull is just an irrationally jumbled-together pile of bones with no rhyme or reason without understanding the skulls of various ancestors (sharks are a particularly good lab study example). I realize that most people coming to WP anatomy or physiology articles are probably pre-med students or other interested people, and that's fine, but we shouldn't shunt off non-human content to mere "see also" pages, nor should we make claims in the lede which are flatly false unless restricted to humans (e.g. "The heart is a four-chambered organ which pumps blood" (hypothetical example, the actual heart page avoids this)). HCA (talk) 19:28, 30 January 2017 (UTC)[reply]
  • Keep It's not just anatomy and physiology get overwhelmed with human content while giving other animals short shrift. Pathogenic organisms and diseases can suffer from the same problem. For example, Anthrax#Other_animals gets 3 lines in a 73kb article, even though it anthrax infections are more common in livestock than humans. Plantdrew (talk) 19:51, 30 January 2017 (UTC)[reply]
  • Keep Like with other templates I think that this has a place when used appropriately. It lets editors and readers know there might be a great deal more animal-related content that is not included, and by being placed encourages it to be added. There is a general lack of information about anatomy, physiology, medicine and other areas relating to animals that are not human here. --Tom (LT) 07:43, 31 January 2017 (UTC)
Addit: I would also support rewording the template to encourage the addition of more content (lack of appropriately sourced content is generally the problem) rather than just reworking of existing content (wnhose sources if used in a human-centric way will likely not be talking about other animals). --Tom (LT) 07:57, 31 January 2017 (UTC)
I don't think the intention is to get people to rewrite content that is specific to humans to refer to other organisms without using appropriate references, but agree that this could be made more clear. • • • Peter (Southwood) (talk): 09:02, 31 January 2017 (UTC)[reply]
How about This article appears to be written from a human-centric perspective. Please help by rewriting expanding it from a point of view that treats humans as one of many relevant species rather than the only one to which it applies? Cheers, • • • Peter (Southwood) (talk): 09:09, 31 January 2017 (UTC)[reply]
I like it. Very much. KDS4444 (talk) 10:24, 1 February 2017 (UTC)[reply]
@Pbsouthwood I also find this much better. I also find this changes the nature of the template from something quite controversial to a more straightforward appeal for more editing --Tom (LT) 00:27, 5 February 2017 (UTC)[reply]
Agreed - this is constructive. — soupvector (talk) 05:17, 5 February 2017 (UTC)[reply]
  • Delete. While I agree that any notable non-human content should be added to biology and health articles, I would be dismayed if the absence of such content led to the appearance of a nasty box at the top of the article. The talk page is the right place to raise concerns about missing content. Or {{sofixit}} JFW | T@lk 20:34, 31 January 2017 (UTC)[reply]
JFW is a medical editor, which perhaps explains why he finds references to non-human animals "nasty". The rider, which he didn't add, is that medical editors on Wikipedia rarely find content about non-human animals "notable". --Epipelagic (talk) 21:10, 31 January 2017 (UTC)[reply]
I don't think sweeping generalizations are going to advance this discussion. Could we stick to talking about principles rather than other editors? — soupvector (talk) 01:13, 1 February 2017 (UTC)[reply]
(JFW We can argue that cleanup tags should not exist, and that the talk page and it alone should always be used for any concerns anyone might have about an article... But instead we do have "nasty" (?) maintenance tags for use on article pages when we spot problems, and my own sense is that the community agrees most of these are useful. But this is not supposed to be a discussion about the usefulness or appealing appearance of maintenance tags generally, yes? KDS4444 (talk) 10:21, 1 February 2017 (UTC))[reply]
@KDS4444: @Epipelagic: I don't think this kind of maintenance requirement warrants a nasty box. If you review my editing history you will see that I have strived actively to discuss other species in articles I have written (e.g. rhabdomyolysis and hypothyroidism). I am generally of the view that all maintenance boxes are nasty, but that they are a necessary evil if the article underneath is in dire need of improving. Many thanks for giving me an opportunity to be more specific about my views. JFW | T@lk 12:04, 6 February 2017 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

People's Choice Awards templates

[edit]
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was Relisted on 2017 February 3 Primefac (talk) 03:10, 3 February 2017 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Templates_for_discussion/Log/2017_January_24&oldid=1089810344"