Wikipedia

Wikipedia:Templates for discussion/Log/2017 September 15

< Wikipedia:Templates for discussion‎ | Log
< September 14 September 16 >

September 15 edit

Template:Infobox Dalai Lama and Template:Infobox religious biography 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 September 23. Primefac (talk) 17:58, 23 September 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:Cite Q 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 no consensus. The arguments made in this discussion are largely similar to those made in the TFD for {{infobox person/Wikidata}}. Those opposed to this template are concerned that it is not accurate, is not easy to edit in these instances, and is less prone to oversight than material hosted on Wikipedia itself. Those in favour argue that because it is a work in progress there will undoubtedly be errors, but that it will allow for more accurate usage down the line and easier syncing between languages, and that Wikidata is just as good as Wikipedia at finding/reverting bad info.

As discussed previously, simply being a work in progress or not being perfect are not reasons to delete a template, but on the other hand works-in-progress should rarely be used in the article space until they are 99% finished/accurate/etc. Until the matter of transcluding Wikidata on Wikipedia is resolved (most likely with a huge and contentious RFC) usage of this template should be extremely vetted to ensure that all of the transcluded information is accurate.

As this template is a work-in-progress, there is no prejudice against re-nomination in 6 months if there is no improvement over the accuracy/ease-of-editing issues, but only if diffs can be provided to demonstrate that either a) no action to change it has been taken, or b) the concerns simply cannot be fixed. However, I personally feel a better use of time would be to determine a community-wide consensus about Wikidata and it's role in templates used on Wikipedia. Primefac (talk) 15:51, 2 October 2017 (UTC)[reply]

This template is a baffling thing when one comes across it while editing. It creates a properly formed citation. Turns out it is pulling data from Wikidata somehow. This is used in about 225 places which is unfortunate. But based on the deprecation of template:doi per Template talk:Cite doi#RfC: Should cite doi template be deprecated?, this should not have been implemented. Citation data should be in the article where the citation is used, not somewhere else, and not in another project altogether.

See also discussion at Wikipedia_talk:Wikidata/2017_State_of_affairs#UNREADABLE_WIKIDATA_REFS which is what made me aware of this. -- Jytdog (talk) 08:23, 15 September 2017 (UTC)[reply]

  • Strong keep - Just because you don't like it doesn't make it good enough for deletion. If you find it difficult to find get rid of <ref name="0:"> too. There's not much difference. Keeping that aside I believe it can be made easier to find. Further, I would like to again remind the need for consolidating references into Wikidata for which various editors and tech people are working on already. The way ahead is improving Cite Q not getting rid of it. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:37, 15 September 2017 (UTC)[reply]
    • The existence of the template is one thing; the advocacy to use this systematically is another one altogether. Anybody seeking that kind of systematic, radical change in Wikipedia must get consensus for that in Wikipedia first. Being BOLD is fine but has its limits, and this kind of thing is one of them. Jytdog (talk) 21:42, 15 September 2017 (UTC)[reply]
  • Keep As the nominator notes, this template "creates a properly formed citation". The DOI template discussion has no bearing on this one, which does not rely on DOIs and does not work in the manner of the previously deleted template. More sensible discussions of this template than the one given may be found at, for example, Help talk:Citation Style 1/Archive 33#Drawing citation metadata from Wikidata. If the nominator is "baffled", there are numerous venues, such as the template's talk page, where they can seek assistance, and where it appears that the nominator has never posted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:39, 15 September 2017 (UTC)[reply]
    • @Jytdog: as Andy correctly says, you wrote above "creates a properly formed citation". I think this premise set the discussion off on a wrong foot. In many cases {{Cite Q}} does not, in some cases it even cannot, produce a properly formatted citation based on the Wikidata Q number of an otherwise reliable source. Maybe amend your initial "It creates a properly formed citation" to something in this vein: "It can creates a properly formed citation in some cases, while it currently obviously does not in many cases (see some of the examples below)" or "Ideally it creates a properly formed citation, a goal that can not under all circumstances be relied on" or simply "It creates a properly formed citation(preceding assertion removed while too contentious). --Francis Schonken (talk) 10:33, 28 September 2017 (UTC)[reply]
      • The original statement is quite correct. Just like all our other citation templates ({{Cite web}}, {{Cite journal}}, {{Citation}} et al), Cite  cannot produce a valid citation from invalid input data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:15, 29 September 2017 (UTC)[reply]
        • Incorrect, Johann Sebastian Bach: His Work and Influence on the Music of Germany (Q24969482) and Johann Sebastian Bach: His Life, Art, and Work (Q21998573) (and other examples below) all contain exclusively "valid" input data, yet the Cite Q template can not extract "properly formed citation"s from these valid input data. --Francis Schonken (talk) 10:59, 29 September 2017 (UTC)[reply]
          • In Q24969482, the template is being fed two different years of publication. Putting two publication years into {{Cite book}} would also produce an error. (Also, in using that, you are citing a two volume work, rather than citing the specific volume which was referred to; nonetheless, this can be done, as, say, {{Cite Q Q24969482|date=1873}}: Philipp Spitta (1873), Spitta's Johann Sebastian Bach, translated by Clara Bell; John Alexander Fuller Maitland, Wikidata Q24969482 ). Q21998573, as already noted below, is now a redirect, but before redirection it lacked a value for title. Omitting |title= from {{Cite book}} would also produce an error. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:09, 29 September 2017 (UTC)[reply]
            causes no problems in the {{cite book}} template I used to generate it.
            your proposal ({{Cite Q Q24969482|date=1873}}) causes multiple problems: it doesn't refer to the "work", it only refers to half of the work; its title wasn't Johann Sebastian Bach: His Work and Influence on the Music of Germany in 1873, a decade before its first English translation.
            • Re. Q21998573: the point being that the Cite Q input data became corrupted after an operation that was "valid" in Wikidata: coupling a newer en.Wikipedia article to an older Wikidata item on the same topic according to the instructions shown by the Wikidata system. Nowhere in Wikidata was it said: "now redirect the old item", nor even explained how that is done. Thus, *even with only "valid" Wikidata operations*, the content of a citation implemented with Cite Q can go south, as I said way down below: "If someone has placed a citation for WP:V reasons, and the content of this citation goes south, one can't just remove it (and with Cite Q in its present MO it may be a painstaking effort to recover its intended content). Thus, for references, something more sturdy is needed, ... etc" (note that the painstaking effort of finding the correct content was alleviated by me pointing to the current Q number, i.e. Q19231225 – what should one do when such clue isn't given?). --Francis Schonken (talk) 12:01, 29 September 2017 (UTC)[reply]
              • Like I said, the example I gave, with |year=1873 is for when you have referred to a specific volume. Quite why the fact that it "refers to half of the work" in that circumstance is a problem is something you're going to have to explain to me. Similarly, if you wish to cite a specific edition, such as an English translation, you should use a Wikidata item about that edition, not the one about the original work. I am sure this has been explained to you previously. You have identified no failing of Cite Q. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 29 September 2017 (UTC)[reply]
    Back to basics:
    • The OP's "It creates a properly formed citation" is only partially true, and that set the discussion off on a wrong foot. Cite Q can't deliver "a properly formed citation" in all circumstances. Nothing in Andy's replies contradicts that.
    • Andy defends a system (i.e. Cite Q) that can import malformed content into Wikipedia. The defences against malformation risks are extremely low (e.g. the system where the malformed content originates does not give a warning that the content could be perceived as malformed when harvested by an external system). The imported content shows only up as malformed in Wikipedia, in the event it is thus malformed, and malformation may emerge long after the import is done, but then in a way that is not easily detected in Wikipedia. My conclusion remains: stop importing content with a relatively high risk of showing up as malformed in Wikipedia, especially as we're speaking about something very central for the content of Wikipedia (i.e. verifiability). As said, deletion of the Cite Q template seems the most logical step here, until if and when a consensus can be found that a different system is not too prone to import malformed content in Wikipedia. --Francis Schonken (talk) 16:48, 29 September 2017 (UTC)[reply]
  • Weak keep. I do not have a strong opinion about whether the template should be deleted, slighly leaning towards keep. The obvious problem is vamdalism on Wikidata, though items with citations are not really attractive to vandals and are not highly visible, and one still does not have a single example of such vandalism which would create damage on Wikipedia. Another argument is that sometimes data is not retrieved properly (in the example in the discussion, the name of the series changed, and the template retrieves the actual name rather than the name at the time of publication). It can be solved for example by having two separate items on Wikidata. A clear advantage is that the citations are centralized. I understand that most English Wikipedia participants do not care a fuck about other language editions (and this is the reason why info on some obscure subjects such as majors of minor Ukrainian cities remains vastly outdated, but this is unrelated to the current discussion). However, references are sometimes changed, and whereas there is some mechanism of propagation of these changes to Wikidata (bots), the changes do not propagate to Wikipedia. The changes specifically in the citations are rare though, and this is why I said I do not particularly care - we have minor advantages and minor disadvantages. I strongly oppose, however, the notion that all information should be in the code of the article. First, it should not be. This is exactly the idea why Wikidata was created. Information in the code is updated very slowly. Second, this is actually n0ot the case with our current articles. An example from my watchlist as of today: Kōtōdai-Kōen Station has a link to a dab in the infobox. I tried to correct it, but I can not figure out how it can be done, because it is hidden in some obscure template somewhere. And I am a rather advanced Wikipedia user with some experience. It is just not true, the info is not always in the Wikipedia article code, and often it is not at all trivial to retrieve or to correct it.--Ymblanter (talk) 08:42, 15 September 2017 (UTC)[reply]
    • Re "a clear advantage is that the citations are centralized", that is only true if Wikidata is used for all references. While it lives alongside references that exist as text in articles it fragments references. It would only centralise references if all references were moved to Wikidata. I think though this would be fiercely resisted by the majority of editors used to the current system, and will not be possible until it vastly easier to work with Wikidata. Until then this does not really centralise citations – quite the opposite.--JohnBlackburnewordsdeeds 10:38, 15 September 2017 (UTC)[reply]
    • Ymblanter, the plain text 'Izumi-Chūō' is easily found when you edit the page. It had a fairly pointless STN template around it, but so what? I'm sure you know how to make a basic piped link.[1] BTW, please check that diff link. I assumed the disambig target should be the Izumi-Chūō on the same rail line. Alsee (talk) 11:03, 15 September 2017 (UTC)[reply]
      Thank you, this solves a problem for this particular article now, but generally this is a completely wrong way of dealing with data. It might be that the line is extended, and than in all articles about the stations of the line the end station must be changes. This is workload which scales with the number of stations. Instead, someone designed a template which keeps track of it and which you only need to change once. At the expence of the usability. Of course one can reject all these templates and remove them from the articles like you just did, but I am sure if you open an RfC there will be a vast majority for keeping the templates.--Ymblanter (talk) 13:42, 15 September 2017 (UTC)[reply]
    • Note on this, citations are valuable targets for vandalism. WP:REFSPAM is one of the most insidious kinds of spamming there is - when someone changes the URL in a ref from a legit or dead one, to some spam site, or adds a URL to a spam site where there was no URL. I fix a couple of these a day. Jytdog (talk) 21:30, 15 September 2017 (UTC)[reply]
      I do it as well, but what relation does it have to the usability issue we are discussing?--Ymblanter (talk) 21:34, 15 September 2017 (UTC)[reply]
      I am reacting to the statement in your !vote, though items with citations are not really attractive to vandals and are not highly visible. This is not true in my experience - the citations themselves are targets for vandals. Or did I misunderstand? Jytdog (talk) 21:45, 15 September 2017 (UTC)[reply]
      I actually meant the Wikidata items which are user in the template. My apologies for being unclear.--Ymblanter (talk) 21:55, 15 September 2017 (UTC)[reply]
      Wikidata entries for citations include URLs that can be the subject of spammers. Like this Q29581753 has a field with the URL http://www.histmodbiomed.org/witsem/vol31.html. That could be easily changed to some spam link by vandalizing spammer. Jytdog (talk) 00:43, 16 September 2017 (UTC)[reply]
      It certainly can be vandalized, but I would like to see an actual evidence that any of these Wikidata items has been vandalized even once. Usually items on highly visible topics are vandalized, not on some obscure articles.--Ymblanter (talk) 08:28, 16 September 2017 (UTC)[reply]
  • Delete or at least remove all mainspace instances of it (directly or through templates). Not only for the reason described above, but also because often it creates incorrect references which are hard to correct. At Povl Riis, this created a reference where neearly everything had to be changed to make it correct. Like I said at WP:ANI[2] ":If I have to add parameters to change the editors' names, change the title, change the link to the pdf, change the journal name, add the volume number, add the page number, and change the publisher's name (assuming all of these are even possible with the current template), then what is the actual use of the cite Q template?"
For another example of problems with the template, see Regensburg. A long way down on that page, you have the infobox for a UNESCO World Heritage Site. "Area [7]". Reference 7 is "Bavarian State Office for Statistics and Data, ed. (1991), Amtliches Ortsverzeichnis für Bayern, Munich: Bavarian State Office for Statistics and Data, p. 242, Wikidata Q15707237". Great, we have a reference without anything it references. Furthermore, the source, if you succeed in eventually finding it, has no info on the area anyway[3]. Then again, how could a 1991 source have information of the area designed as world Heritage Site in 2006... Similarly, on Visby they use a 1961 reference for a 1995 world heritage site, resulting in "Location Gotland Municipality, Q10716061, Gotland[10][11], Sweden" (emphasis mine) in the text of the infobox.
And a third group of articles this is used on are telescopes. Cerro Tololo Inter-American Observatory has the location of the telescope, "Location Coquimbo Region, Chile[1]" with the source "GRID Release 2017-05-22, 22 May 2017, doi:10.6084/M9.FIGSHARE.5032286, Wikidata Q30141628". Neither the doi nor the Wikidata link bring you any closer to the actual source, [4].
Some loose articles also use this, e.g. Moksha (Jainism) has a source: "Paul Dundas (2002, 1992), The Jains, London, New York: Routledge, ISBN 0-415-26605-X Check date values in: |date= (help), Wikidata Q36518532" (emphasis mine). Oops! Often, these pages have a Wikidata link to a general website, not an actual reference to the object in question (e.g. Bengtskär lighthouse links to this, not to this; Crucifixion with the Virgin Mary, St John and St Mary Magdalene links to this, not to this which as already present in the article anyway.
Basically, whether you believe we should have this template or not (I don't, hence my "delete"), it clearly isn't ready to be used in the mainspace and is added to articles and templates in a reckless, often WP:POINTY manner. Fram (talk) 09:12, 15 September 2017 (UTC)[reply]
    • It took just seconds to fix the dual date issue for the Dundas book's item at Wikidata (something Fram could have done, but choose not to). The issue there was the conflation of two editions, just as they are conflated on Wikipedia's article about the author. No doubt User:RexxS (whose Lua skills exceed mine) will be happy to kindly update Cite Q to handle the edge case of dual dates in Wikidata, and our project can take yet another a small step forwards, instead of the large step backwards that deletion of this template would involve. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:29, 15 September 2017 (UTC)[reply]
      • Andy Mabbett, please be more cautious about selectively pinging allies into RFC or deletion discussions. It may be interpreted as canvassing. Alsee (talk) 15:17, 15 September 2017 (UTC)[reply]
        • Please be more careful about failing to assume good faith. I know for a fact that RexxS has the template on his watchlist, not least as he's a major contributor to it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:33, 15 September 2017 (UTC)[reply]
      • Actually, it took you ten minutes, not two seconds[5], and since when do we have to edit other websites to fix error messages in Wikipedia? I don't see how having to correct references and errors there is somehow a sign of progress. You haven't really explained why deletion of this template would be "a large step backwards" though. By the way, don't edit my comments again. Fram (talk) 10:41, 15 September 2017 (UTC)[reply]
        • No, it took seconds to apply a fix that remedied the display in the Wikipedia article. I then decided to go back and make further improvements, *after making my post here* [during which time, incidentally, my Internet connection went down and I had to reconnect]. I have not "edited your comment"; I have fixed the list markup for accessibility reasons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:17, 15 September 2017 (UTC)[reply]
          • Your initial "fix" kept the wrong year and removed the ISBN. It's easy to make a 2-second fix if it doesn't have to be in any way or shape correct of course. Fram (talk) 13:43, 15 September 2017 (UTC)[reply]
        • P.S. "since when do we have to edit other websites to fix error messages in Wikipedia?" Since we started transcluding media from Wikimedia Commons. When indeed was that, remind me? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:25, 15 September 2017 (UTC)[reply]
          • I can't really remember the last time that I saw an error message here generated by a Commons file though (apart from adding a commons file in a wrong location, which needs fixing in enwiki, not on Commons). But you are welcome to indicate some recent cases where this happened of course. Fram (talk) 13:43, 15 September 2017 (UTC)[reply]
            • Just as soon as you show me an error message "generated by Wikidata", and not (as in the case in hand) by a template on en.Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:35, 15 September 2017 (UTC)[reply]
      • Fram has now Removed Cite Q from the Moksha article. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 15 September 2017 (UTC)[reply]
    • The issue at Regensburg is with {{Infobox World Heritage Site}}, which appears not to handle a missing |area= parameter. That cannot be laid at Cite Q's door. Similarly, at Bengtskär lighthouse, and at Metrostav, the issue is what is being passed to Cite Q by the infobox, not what it is doing with it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:23, 15 September 2017 (UTC)[reply]
      • In the cases of Regensburg and Visby, the main problem here was that we had multiple infoboxes here on enwp, rather than using child templates to just show the WHS-specific information. The current code for area needs more work before it can be applied to complex cases such as cities (as opposed to World Heritage Site-specific articles), as it needs to cope with, e.g., changes in area over time. I'm not sure why we had multiple infoboxes on the same page, as we should never have more than one. I've now fixed this in these two cases, and I am slowly working through the other articles that use the WHS template to make sure this doesn't happen in other cases - but this is an enwp cleanup task that will take a while to complete (only another 532 articles to work through). Thanks. Mike Peel (talk) 00:51, 16 September 2017 (UTC)[reply]
  • Keep a) the referred problem has no bearing as the nominator himself states and b) The solution to - real or imagined - problems with using wikidata is to work on those, and not by deleting templates here. Agathoclea (talk) 09:13, 15 September 2017 (UTC)[reply]
    • If there are fundamental problems with the template, and the supposed benefits seem to be missing from most or all examples actually in use now, then why keep it? I don't understand what you mean with "the referred problem has no bearing". Every time I look at actual uses of this template, I notice new problems. Metrostav has the first "reference": "annual report, Wikidata Q699735". The first link is to our article on "annual report", not to an actual annual report for this company. The second link, to Wikidata, goes to this, the Wikidata page for ... "annual report". The Wikidata link adds absolutely nothing here, only frustrates people wanting to find an actual source. How come? Well, an editor added here the "Infobox company/Wikidata", which calls the cite Q template, with this result. Uesful! Fram (talk) 09:22, 15 September 2017 (UTC)[reply]
      • But that is a problem of {{Infobox company/wikidata}} and not of the template we are discussing. Agathoclea (talk) 10:07, 15 September 2017 (UTC)[reply]
        • No, citeQ generates the actual text of the reference (it is supposedly its unique selling proposition). That CiteQ is used is the choice of the people maintaining that infobox version, but the end result is a reference which is nearly impossible to edit, improve or remove from the article. if CiteQ were deleted, we wouldn't see that "reference" and we would lose the link to the Wikidata item for "annual report", which would be a good thing. In general, no matter through what means the citeQ template is introduced in the article, there seem to be very few uses where the reference actually guides you to the right source, page, ..., the kind of things you would expect in a real, working cite template. Often it is simply wrong, in other instances it is somewhat, vaguely right if you ignore lots of small issues and defects. Fram (talk) 10:26, 15 September 2017 (UTC)[reply]
    You're begging the question (Q219429). It's circular to say we should use it because→ wikidata should be improved because→ we should use it. Alsee (talk) 14:07, 15 September 2017 (UTC)[reply]
  • delete or mark as unusable. This is strongly reminiscent of the previous {{cite doi}} which although well meant was found to be detrimental to the project, because it broke one of the main tenet of WP, that it is the encyclopaedia that anyone can edit. References are part of the page content, and editors should be able to view, edit and copy them by viewing the page source. Putting them on other pages made them harder to find and edit, harder to monitor for vandalism, harder to re-use by copy and paste. {{cite doi}} was bad enough, but at least when an editor found the relevant page it was a recognisable citation, and could be examined, edited, copied as if it were in an article. Putting them on Wikidata is far worse, as it is a separate project and the way it works is completely unlike WP.
    Maybe one day we will be able to edit Wikidata content within WP pages, and watch it for changes with other page changes. At that point it might make sense to host content such as references on Wikidata. But right now it makes the editing experience significantly worse and so should not be used.--JohnBlackburnewordsdeeds 09:26, 15 September 2017 (UTC)[reply]
  • delete. It's just about impossible to figure out which source is which while editing an article. Also, the template is self-described as experimental but is nevertheless finding its way into articles, so describing it as experimental in the documentation is insufficient to prevent it from being used in articles. Deleting it would be sufficient. Jc3s5h (talk) 09:50, 15 September 2017 (UTC)[reply]
    • Nowhere in the template's documentation is it described as "experimental". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:19, 15 September 2017 (UTC)[reply]
      • That would appear to be a "letter of the law" response; the words "A prototype wrapper" appear in the very first sentence of the documentation. --Izno (talk) 11:44, 15 September 2017 (UTC)[reply]
        • No, it's a "don't describe things as 'self-described as experimental' when they are clearly not" response. Our own frequent use of the qualified phrase "experimental prototype", not to mention a third of a million Google hits, shows that "experimental" and "prototype" are not synonyms. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:02, 15 September 2017 (UTC)[reply]
  • Allow for use in small scale testing only. Requires a broad RfC before general use Was created against the consensus here. The WD property can be added to cite journal. We do not need another citation format to confuse editors. I have specifically said a few times that WP:CITE should not work like this. But I guess if this is just a step towards better things than okay. Doc James (talk · contribs · email) 12:18, 15 September 2017 (UTC)[reply]
    • As noted above: "The DOI template discussion has no bearing on this one, which does not rely on DOIs and does not work in the manner of the previously deleted template. ". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 15 September 2017 (UTC)[reply]
      • The problem with Cite Q and Cite DOI are the same. They shuffle off the meta data to some other place out of Wikitext / Wikipedia. Much of the core editing community has previously opposed this. Doc James (talk · contribs · email) 13:17, 15 September 2017 (UTC)[reply]
  • Delete per Fram and Doc James and JohnBlackburne. Not an improvement and not needed. Ealdgyth - Talk 12:32, 15 September 2017 (UTC)[reply]
  • Strong delete... OK, let me start by admitting that I do not have much tech experience... If I had come upon a citation that used this template before reading this thread, I would have had no idea what all the coding meant. It is simply gibberish too me. I would have figured out that it was a link to wikidata... but that is about it. Having read the thread, I have a bit more of a clue... so I followed the links and tried to figure out how I would edit citations that used this template. I very quickly gave it us as too confusing. That is a huge problem. Wikipedia is supposed to be something that just about anyone can edit... even those who don't have a lot of tech experience. Wikidata may be wonderful for those who understand how its database works, but it is confusing as hell for the rest of us. With this template, editors see a string of meaningless letters and numbers... and if we click on the links, we end up at a confusing and meaningless database, with no idea of how to edit it. If we try, we are very likely to make a mistake... and make the citation worse. Not acceptable. Blueboar (talk) 12:39, 15 September 2017 (UTC)[reply]
    You should talk to someone who tries to edit Wikipedia for the first times.. There is nothing easy about it. Most people don't even dare to start. The frictionless experience you describe doesn't exist, our pages our filled with gibberish and people make MANY mistakes and then get stuck. It takes people lots of time to learn how to edit a reference. If your argument is that you don't want to learn twice, then ok, but lets not pretend that one is superior to the other. It isn't, both are shite for the true 'rest of us'. —TheDJ (talk • contribs) 13:39, 15 September 2017 (UTC)[reply]
I certainly remember how difficult it was for me to learn how to format a citation... and you are correct in saying that it wasn't easy. For a long time, I simply cut and pasted a citation from another part of the article (or some other article), and then simply rewrote the citation text. And I still use the old <ref>...</ref> format that I learned back then (All these "parameters" and "fields" and what not, are beyond me). But, that just reinforces my point... For a non tech-oriented Luddite like me, the template makes it even harder and more confusing to edit. I would be all for it if it actually made things easier... but it doesn't. Blueboar (talk) 14:09, 15 September 2017 (UTC)[reply]
  • DELETE. We encourage BOLD editing, but this Wikidata Crusade is getting disruptive. Worse than cite doi, with many of the same issues that established that consensus. Rather than hiding the actual ref outside of the article, this manages to hide the ref outside of wikipedia. I was confused as hell when I clicked edit on an article, and exactly NONE of the ref-text I was searching for was findable. Wow! Unreadable refs! BRILLIANT! This adds stupid layers of complexity and confusion for new editors, nevermind experienced editors. Or maybe I'm wrong, and eventually we'll just turn articles into one long string of Q-numbers:
    Welcome (Q299010) To (Q223817) The (Q2430521) Future (Q229748) Alsee (talk) 13:52, 15 September 2017 (UTC)[reply]
  • Keep Centralised storage makes a lot of sense, rather than endless copy and paste (and propagated errors). If the citation already exists on Wikidata (bibliographic data is currently being bot-imported there by the shedload), what's the point in duplicating it ? If people want something they can tweak without leaving the wikitext screen, a good solution is local over-ride fields, that would over-ride whatever is on Wikidata for that citation field. These over-rides can then be examined by somebody confident about editing Wikidata, and the database there updated if appropriate. Jheald (talk) 13:57, 15 September 2017 (UTC)[reply]
    • "propagated errors"; yes, with this template you are at least reasonably certain that you get the same error in all copies. Where does this belief come from that what you will get from Wikidata is somehow magically better than what you get here? It certainly doesn't match the evidence collected here. Fram (talk) 14:08, 15 September 2017 (UTC)[reply]
@Fram: In part because when it comes to copying and pasting I know that machines can do a better job with a lower error rate that I do as a human being. But the second factor is that it's easier to compare data in Wikidata to the original source, and much easier if you want to make such comparisons at scale. En-wp is very good at catching bad edits. But if a bad edit gets through that initial screen, you're never going to find it again. Suppose you wanted to check all the citations on en-wiki to a particular journal, to see whether the article titles were correct. You would have to scrape an enormous amount a material, simply to find those cites. Whereas on wikidata you could write a query that would retrieve all those article titles in under a minute. There are a lot of things that wikitext is good for, in particular its ease and speed of editing. But systematic at-scale data retrieval and data checking is not one of them. Jheald (talk) 14:35, 15 September 2017 (UTC)[reply]
I have seen very little evidence so far that Wikidata at the moment does any such data checking (or does it well). I have also seen very little evidence, from the current 250 or so citations using citeQ, that Wikidata is in any way better to a) find the right source, b) display the right source, and c) correct when it is wrong. And of course, most sources don't get used in that many articles, most sources are used once or twice, making the benefit of this minimal. I just checked one of the articles using Cite Q, and noticed that the Wikidata source is a generic one, instead of a specific one. If I would change this source to point at the right item on Wikidata, I would break dozens of other articles which use the same generic source. On enwiki, I would change the reference for this article and I wouldn't break any other articles. Funny bit (well, not really, another very sad reminder of the true state of Wikidata: the article I checked was La Madeleine, Paris, a rather famous Paris landmark and World Heritage site. Since 28 February 2017 this item has the wrong English label at Wikidata (basically meaning that it has been page-moved vandalized and no one saw it or cared for more than 6 months), where it is called "La Madeleine ceosoner"[6]. And tragically matching another current Wikidata debate, the English description "Roman Catholic church occupying in the 8th arrondissement of Paris" could do with some copy-editing as well. That error has been there only since October 2013 though[7]. It's the first line our mobile- and app viewers (used to) see when visiting the article, not something buried deep in the body of it. And that's the kind of site we should trust to keep our references up-to-date and correct? Fram (talk) 14:52, 15 September 2017 (UTC)[reply]
Well thank you for that vote of deep appreciation, Fram. And now, if you don't mind, I'll go back to the 1:1 matching of Wikidata's items on civil parishes in England to the identifiers and authoritative data from the UK national stats office, to facilitate just that kind of cross-checking. 10325 matched so far, closing in on the last 125. The kind of ongoing data matching and iterative improvement that is typical right across Wikidata. Jheald (talk) 15:31, 15 September 2017 (UTC)[reply]
  • Delete per Fram, JohnBlackburne, Doc James, and Blueboar. Articles are meant to be such that "anyone can edit" them, remember? SarahSV (talk) 14:56, 15 September 2017 (UTC)[reply]
  • Delete per JohnBlackburne's summary. Only in death does duty end (talk) 15:02, 15 September 2017 (UTC)[reply]
  • Oh joy... I have just discovered that a vandal will be able to simply go to wikidata, vandalize a citation, and have his vandalism appear on hundreds of pages on Wikipedia (wherever the Q template is used). Meanwhile, (to to really make this fun for vandals) the since changes made on wikidata will not show up on your watchlist here on wikipedia... which means that the chance that the vandalism will be noticed and fixed actually decreases. Brilliant! Blueboar (talk) 15:16, 15 September 2017 (UTC)[reply]
  • Comment I don't understand why a few people on English Wikipedia hate Wikidata and tech people so much. Wikidata is a beautiful tool which make data readable to machines just as Wikipedia make it to humans. Also, you should not forget that Wikipedia itself is designed and maintained by a tech team. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:23, 15 September 2017 (UTC)[reply]
Humans and machines do not read data the same way, and never have done. If they did, browser development would have stopped at Lynx as "a solved problem" and we'd all still be programming in assembly language. Ritchie333 (talk) (cont) 15:43, 15 September 2017 (UTC)[reply]
Haphazardly sprinkling WD on everything does not make it "Great TM". I like the idea of WD actually. There however has been specific requests NOT to do this and yet here it is. Doc James (talk · contribs · email) 23:20, 15 September 2017 (UTC)[reply]
  • Delete per Fram - it's clear the template makes Wikipedia harder for the average editor to fix mistakes, which is a big no-no. Ritchie333 (talk) (cont) 15:38, 15 September 2017 (UTC)[reply]
  • Delete Fram, Doc James and Blueboar make valid points; I see no benefits from the use of this template. SagaciousPhil - Chat 15:46, 15 September 2017 (UTC)[reply]
  • Delete If the information was actually kept in en.wiki and synched to Wikidata as wikidata-enabled infoboxes work, that would be fine to catch for errors/vandals, but the way that it hides info from editing on en.wiki is extremely problematic and we should not have this template until fixed. --MASEM (t) 16:03, 15 September 2017 (UTC)[reply]
  • Delete or at least do not use in articles. I've already given some reasons in the recent ANI thread. I agree with Fram, Doc James and most others who have already commented in favour of deletion in this discussion. In addition, think of the newbies: they struggle with our plethora of extant cite formats without something that is as utter gibberish as this one. - Sitush (talk) 16:14, 15 September 2017 (UTC)[reply]
  • Delete, or at least userfy in some way so that this is not used in mainspace. I was initially enthusiastic about the idea of a cite template that pulled data from Wikidata, and suggested it myself over a year ago. I still like the benefits that we might get from this sort of integration, but there are too many problems.
    • Ease of modification. Currently it's much too hard to figure out how to modify the data that constitutes the citation. I don't mind a bit of a learning curve -- it was a while before I began using {{cite journal}} and its ilk -- but it took me a long time to figure out how to do the data entry for the citation data I built on Wikidata. Most users who run into {{Cite Q}} in mainspace are going to be stopped dead in their tracks; at least with {{cite journal}} one can see that "Jhonson" is spelt wrong, and just fix it in wikitext. This reason by itself is enough to keep Cite Q out of mainspace.
    • Visibility. I can't imagine any content editor wanting to add information to an article that they can't keep an eye on via their watchlist. It's true we don't do this with Commons, but the only changes on Commons that can affect our articles are uploads of revised versions of existing files that are already included in articles. This is not something that is likely to happen as drive-by vandalism; I don't think I've ever noticed it on any article I've ever worked on. Changes to data likely to show up in thousands of citations -- say, a journal title, or an author name -- require much better visibility from the wikipedia they're used in.
    • Vandalism. I don't think this is quite as big an issue as some other commenters above; I think if we had better visibility and easy reversion from WP screens this problem would largely go away. However, minor or major, it's a real issue, and a clear net negative at the moment.
    • BLP & V. Several people have commented here or elsewhere that there is no equivalent on Wikidata to WP:V and WP:BLP; I've not yet seen a link that proves them wrong, but perhaps there is one. Again I think this is a secondary issue -- if in practice their data complied with V and BLP then I would care much less about their policies. The real issue is whether the data quality is good; BLP and V would help, but wouldn't guarantee it.
--Mike Christie (talk - contribs - library) 17:24, 15 September 2017 (UTC)[reply]
  • Delete – I have serious misgivings about this template, due to the problems at Wikidata that other editors have already mentioned. However, my concern is broader than that. If the intention is to have a database of references that the various Wikipedias can pluck sources from, (it sounds like that is the goal), I'd expect to see a major RFC before such a plan is implemented. A new host site for references is a change that would have more impact on the site than anything I've seen in almost a decade of editing. Everything from article maintenance to additions by inexperienced users would be affected, and this isn't the sort of thing that should be just be added one day as if it were a simple bug fix. A consensus of the entire editing community would be needed here. Until there is one, I don't think this template should exist yet. Giants2008 (Talk) 17:39, 15 September 2017 (UTC)[reply]
    • @Giants2008: A database of references is already there on Wikidata, and growing by the day. For one thing Wikidata needs it for its own citations. But the intention isn't to do away with existing citation mechanisms here, just to make it possible to cite the citations on Wikidata as well. Jheald (talk) 17:51, 15 September 2017 (UTC)[reply]
      • You just said that you supported centrally storing references, that keeping two sets of refs was unnecessary duplication, and that if Wikipedia editors don't like something they can locally override it. That sounds like a desire for a central reference database to me, and this would greatly alter our existing citation practices; taken to its logical conclusion, we'd be pushed to input new refs on Wikidata before using them on a given Wikipedia. My point about the need for an RFC for such big changes stands. Giants2008 (Talk) 17:59, 15 September 2017 (UTC)[reply]
        • Centrally stored references have benefits for the citations that use them. Citations that don't use them don't get the benefits; but I wouldn't be pushing for conversion, or mandatory use of wikidata for referencing. I mean, I still typically reference here using freetext without even a citation template. But if the bibliographic data already exists on Wikidata (and eg was already supporting the fact in question there), then I'd be very happy just to be able to put in a {{cite_Q}} template -- especially knowing that it would automatically pick up any improvements to the reference, eg links to repositories or appropriate indexing services. Jheald (talk) 19:27, 15 September 2017 (UTC)[reply]
          • I agree there would be plenty of benefits if we had a reliable citation database such as you describe. The "delete" !votes above don't generally point to a disbelief in these benefits; they point to other issues, which outweigh the possible benefits. Mike Christie (talk - contribs - library) 19:32, 15 September 2017 (UTC)[reply]
        • I can see that there might be benefits to a centralized database of sources... but this one definitely isn't the database we want. We want one that is internal to WP:en... subject our policies and guidelines... one where the text of the citation is readable when in edit mode (without going to some other project or page) ... and that alerts our watchlists if the citation is amended or changed. The citeQ templates are external .. not under our policies... without the text being visible in edit mode... and do not alert our waychlists if something gets changed. Blueboar (talk) 18:52, 15 September 2017 (UTC)[reply]
  • Delete per comments by many others above. --Andreas JN466 19:30, 15 September 2017 (UTC)[reply]
  • Strong delete (and deprecate) for the multiple solid objections raised above, and also because this template seems to rely on "named-refs", which is a definite defect. Additional comment re "centrally stored references": not only do they distance the citation from the material cited (as mentioned above), they also force a "one style for all" in matters such as whether authors' first names should be full or initialized. ~ J. Johnson (JJ) (talk) 20:02, 15 September 2017 (UTC)[reply]
    • @J. Johnson: Not at all. Given the data stored in a structured way, it's easy to have a local 'style' parameter that controls which formatting template to send it to. That can include whether to use full first names or initials. Jheald (talk) 20:17, 15 September 2017 (UTC)[reply]
      • It's easy to have a local style parameter? Then why (at least for this template) isn't there such a parameter? Not only is the implementation lacking, so is the conception of how this might be done. Unless, and until, that is addressed it's one-style-for-all, but without any consideration of what that style should be. Isn't that rather like kindling waiting for a match? ~ J. Johnson (JJ) (talk) 21:39, 15 September 2017 (UTC)[reply]
    • "this template seems to rely on 'named-refs'" It doesn't. Why are you calling for a template to be deleted, when you apparently don't know (and are clearly uncertain) how it works? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:37, 15 September 2017 (UTC)[reply]
Yes, I did read the template's documentation beforehand. Have you reviewed WP:civility any time recently? ~ J. Johnson (JJ) (talk) 21:01, 16 September 2017 (UTC)[reply]
  • Comment Someone uninvolved should please place a neutral notification of this discussion, on Help talk:CS1. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 15 September 2017 (UTC)[reply]
    • Just to note that @Nikkimaria: added a notification to that help page. I've tweaked it slightly so it mentions the template name. Thanks. Mike Peel (talk) 01:05, 16 September 2017 (UTC)[reply]
  • Conditional Keep and Prohibit use in mainspace until there's a clear consensus to do so. We're not ready to export citations to Wikidata, per the many reasons outlined above. I'm fully in agreement with that. But given the increasingly meaningful roles Wikidata will play in Wikimedia projects, it's worth considering that with a range of technical fixes to Wikipedia and/or bots and/or templates, it's entirely plausible citations will one day be handled on Wikidata. Maybe it won't, but templates like this are the sort that are useful for experimentation for uses like this, and it doesn't seem like there's any benefit to outright deleting it. Why not allow it to be used in sandboxes, drafts, talk pages, etc.? — Rhododendrites talk \\ 22:11, 15 September 2017 (UTC)[reply]
User:Rhododendrites I don't know what the future holds, but having this available for experimentation makes sense to me. An outcome that is "prohibit use in mainspace" is an entirely reasonable to me, with a big fat notice placed on the template doc, warning people not to use it in mainspace. I worry that Wikidata advocates won't abide by that but we would have this AfD to point back to at ANI or elsewhere, I reckon. Jytdog (talk) 01:00, 16 September 2017 (UTC)[reply]
That would be sufficient for me. Doc James (talk · contribs · email) 01:08, 16 September 2017 (UTC)[reply]
Re: use in drafts: What happens when those drafts are moved into Mainspace? All the Cite Q refs get altered? What are the chances that everyone's going to remember that? I think the chances are pretty low, and we're going to end up with it in Mainspace by the backdoor. Beyond My Ken (talk) 07:22, 16 September 2017 (UTC)[reply]
I am happy to see it tested. I guess the question is should we have a bot that converts for this to a normal citation when it occurs in mainspace? Such a bot would than keep it from getting into mainspace. Doc James (talk · contribs · email) 18:14, 16 September 2017 (UTC)[reply]
  • Strong keep. This is an integral part of the Wikidata infobox ecosystem - it is one of the two templates that are being used to include references in the infoboxes when the info is drawn from Wikidata (along with Module:wd), and it is the only one that can currently handle the "stated in" references. If we want to include references in the infoboxes (which seems to be the case from past conversations I've had about this), then this is vital to keep.
The template works, mostly quite well, and is quite well documented (although the documentation doesn't already get read ;-) ). There are issues with the template, but it is under active development, and issues either get quickly fixed by tweaks to the template (just point them out on the template talk page) or to the information on Wikidata (which is also still under development/expansion!).
A lot of the arguments I hear about incomplete information could easily be said about Wikipedia in the past (and even currently)! And a lot of the arguments about 'it's difficult to edit the information on Wikidata' can equally be said about the standard citation templates here (we just have stockholm syndrome...)
As for 'you can't follow changes here', please go to Special:Preferences, go to the 'Watchlist' tab, and tick the check-box next to 'Show Wikidata edits in your watchlist'. Maybe this should be enabled by default... Thanks. Mike Peel (talk) 23:29, 15 September 2017 (UTC)[reply]
This is how it goes. The community allows infoboxes to be drawn from Wikidata, which leads to citation templates drawing data from wikidata, which irresponsible editors start using more widely outside of infoboxes. This is the problem with working in an unstructured community like this. People are going to do irresponsible things, running well ahead of consensus.
Many many reasons have been given for deleting this citation template. If that makes things difficult with wikidata-driven infoboxes, then those will have to be redone, but that is an entirely different conversation. Not relevant here. It is not the en-WP community's problem, that Wikidata advocates are making problems for themselves. Jytdog (talk) 23:47, 15 September 2017 (UTC)[reply]
@Jytdog: Consensus without practical examples tends to lead to conservatism - "this can't be done", "this will break everything", "this will never happen". Everything I've been doing with Wikidata infoboxes so far has to prove that the concept works, within the bounds of existing consensus as I understand it, and to work through the technical and (mostly) social issues as best as I can. I have not yet seen a valid reason for deleting this template - restricting its usage to certain circumstances, maybe, but not deleting it. We can have Wikidata infoboxes that don't show references, but I worry that this will then be seen as a reason to delete the infoboxes ("they don't support references"/"you can't display references from Wikidata correctly"). Most of the problems I've seen so far with this work have been due to the en-WP community's ad-hoc approach to things... Thanks. Mike Peel (talk) 00:22, 16 September 2017 (UTC)[reply]
I get it that you see nothing wrong with this; you wrote that the first time. Jytdog (talk) 00:48, 16 September 2017 (UTC)[reply]
Thank you for listening. Mike Peel (talk) 01:04, 16 September 2017 (UTC
"This is how it goes. The community allows infoboxes to be drawn from Wikidata, which leads to citation templates drawing data from wikidata, which irresponsible editors start using more widely outside of infoboxes." In this case you are demonstrating a remarkable ignorance of the facts. That is most certainly not how it has gone, as just a few seconds reading of the links already posting this discussion would have shown you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:02, 16 September 2017 (UTC)[reply]
Just to reply to this: "As for 'you can't follow changes here', please go to Special:Preferences, go to the 'Watchlist' tab, and tick the check-box next to 'Show Wikidata edits in your watchlist'.". I tried it for a couple of days and it does not work. Or at least it is badly broken in a number of ways. First with no edit summaries only automated ones you are often forced to guess what the edit is, certainly what its intent is. Second there is no 'diff' link, you have to go to the page, then view history, then view the last change. Third Navigation Popups don’t work. But fourth and worst it pulls in every change, not just ones to the items that correspond to the pages on your watchlist but every item used on them, filling the list with irrelevant changes, but which are not obviously irrelevant until you dive in and see what the change is. E.g. I saw reports of vandalism of the description at Argentina on Wikidata, not because I have that page watched but because there was something on my watchlist which is in Argentina, which has an infobox which gets the country name from the country’s Wikidata page. And this is only likely to get worse as infoboxes and templates pull data from multiple Wikidata pages.--JohnBlackburnewordsdeeds 22:40, 17 September 2017 (UTC)[reply]
@JohnBlackburne: It's not broken, although it's not as feature-complete as you (and I) would like. First, the automated edit summaries are because manual edit summaries aren't used when editing Wikidata as each edit is quite small (the sort of edits you'd make with summaries of 'tweak', 'ce', '+', '-' here) - although the display of these could be a lot better (property name, value changes), and for larger edit sets a summary would be useful. Second, the diff link works for me as usual (except it points to the wikidata edit diff rather than the wikipedia one), if it doesn't work for you then that's a bug that needs to be fixed. Third, yes, pop-ups don't work (which is a shame). Fourth, this is both a pro and a con - it's a pro because you need to see when things change in other entries that affect the page you're watching (which is particularly relevant for the template being discussed here!), but a con is it would be better if duplicate edits didn't show up (although maybe this shows up the important changes to check. ;-) ). Thanks. Mike Peel (talk) 00:20, 19 September 2017 (UTC)[reply]
  • Strong keep. No valid reason for deletion has been specified, and the goal of centralizing citation metadata in a single database entry per source rather than copying it as text in each article that uses it (in each different language of Wikipedia) is a very good one. That way, there is one place to correct any errors or add new detail to the citation, rather than having to track down each different copy of the citation and correct it separately in each one. —David Eppstein (talk) 01:31, 16 September 2017 (UTC)[reply]
  • Delete. One thing that I have learned in fixing a half million disambiguation links over the past ten years is that it is a very bad idea to separate the presentation of data from the location for editing that data, unless there is a crystal clear road map for finding the place where the edit needs to be done to fix an error. bd2412 T 02:38, 16 September 2017 (UTC)
  • Delete per Doc James. Citations are a mystery to many editors, and this appears to make them even more mysterious and less functional. Beyond My Ken (talk) 02:56, 16 September 2017 (UTC)[reply]
  • Keep The template is useful for discussions and as a sandbox, but remove from mainspace. Headbomb {t · c · p · b} 03:30, 16 September 2017 (UTC)[reply]
  • Not ready for use on Wikipedia. I read through the documentation, and could not work out how to use it or fix it if something is wrong. I don't necessarily need to be able to use it from scratch, but if it breaks something on my watchlist I want to be able to fix it without a huge learning curve. This looks like the Visual Editor fiasco revisited, maybe a little less in your face. Most content creators are unlikely to look kindly on tech changes which confuse them or take them away from what they want to be doing to try to iron out someone else's bugs. Get it working, get it user friendly. This may be just a matter of good documentation, but from the comments above I think the problem is deeper. It may be potentially wonderful, but at present it is not. · · · Peter (Southwood) (talk): 07:06, 16 September 2017 (UTC)[reply]
  • Keep for experimentation, with warning not to use in reference sections on articles. I feel partially responsible for this fiasco as I encouraged Andy Mabbett to create this as a proof of concept template, supplanting an earlier experimental template. I agree that it is not ready to be used in articles. For some historical context, we first started discussing this approach to storing citation data at 2014. After that discussion Wikidata WikiProject Source MetaData was started. And although I did not attend, I do know that this idea has been discussed at two conferences since, WikiCite 2016 and WikiCite 2017; the overarching project is at [8] Mvolz (talk) 07:42, 16 September 2017 (UTC)[reply]
  • Delete, per Blueboar, Doc James, Pbsouthwood, and JohnBlackburne. I understand the point of wikidata and tesnhis template, but the practice is close to hopeless. Happy days, LindsayHello 12:03, 16 September 2017 (UTC)[reply]
  • Keep and restrict out of mainspace, but not out of Wikidata-generated infoboxes—The objections cited are compelling. I would add another one—which cuts against the grains of Wikipedia community skepticism of VisualEditor: We should be moving the project in the direction of interactive Web operations, not obscure codes. This implementation of database-driven citation creation, which uses WorldCat to automatically generate editable citation templates, should be our model. (Even then, there are errors in WorldCat which need to fixed on the page.) But when Wikidata provides rich structured information, like in Infobox gene, (1) it's better if that material is referenced, and (2) we shouldn't begrudge Wikidata for using a Wikidata item to hold the reference. These processes generated the four infoboxes in Dihydrofolate reductase, and the first two references in the article. Using Cite Q within Infobox gene strikes me as unproblematic. What's more, it means that one reference is being actualized in multiple languages across Wikipedias, which is a kind of amazing feature. In the long term, I think both these applications (linked citations and cited multilingual infoboxes) require greater conversations across Wikipedias and Wikidata, but limiting the former while letting the latter go forward seems optimal until then.--Carwil (talk) 15:12, 16 September 2017 (UTC)[reply]
    • But that still leaves the problem that, when using a citeQ template, the text of the citation Is not visible when in edit mode. Centralized storage of data is all well and good, but citations are more than bits of data... they also need to be thought of as text ... and text requires ease of editing at an article level. Users should not have to go to external pages to edit an article's text. Even in infoboxes, the text should be editable by simply clicking on "edit" and typing. Blueboar (talk) 15:41, 16 September 2017 (UTC)[reply]
      • I want that too… but we have some tools to build for that to be true. For example on Dihydrofolate reductase, someone added its position on Chromosone 5 on Wikidata and cited it. That citation now appears inside the infobox, but aren't editable. We should fix that (so that the citation is visible in Wikitext, editable in Wikitext and VisualEditor, and so that changes to the citation propagate to infoboxes in the other eight languages with Infobox gene), but it sounds like it will take some time. My point is that until we do fix such things, the least astonishing path for rich templates generated from Wikidata is to keep having the cites generated by Wikidata. And by "rich templates," I mean things like Infobox gene that reveal complex data, but not like Infobox company which gets a plain text field—the company's official URL—from Wikidata. Under the circumstances, I'd rather keep rich citations in such templates, not suspend them. (And not having access to the source of Infobox gene etc., I'm not sure if they depend on Cite Q at all.)--Carwil (talk) 18:51, 16 September 2017 (UTC)[reply]
That would definitely be a step in the right direction. Ok... I can see allowing it on a user page for testing... but don't roll it out to mainspace until fully vetted and approved by the WP:en community. Blueboar (talk) 19:33, 16 September 2017 (UTC)[reply]
template:infobox gene is used in Dihydrofolate reductase; it is one of the very few infoboxes that is drawn completely from Wikidata. It does not rely on the template we are discussing and is not relevant to this discussion. (i had an extended discussion about excluding health information from that infobox at Module talk:Infobox gene). Jytdog (talk) 19:48, 16 September 2017 (UTC)[reply]
@Jytdog:, you're technically right in this case. I figured out how to look under the hood (at the Lua code that underlies Infobox gene) and it uses cite web for all footnotes it generates, not Cite Q. But, (1) those references are also invisible in wikitext (which just shows {{Infobox gene}}, and (2) it would be better if it did provide more fully elaborate references, such as journal articles.--Carwil (talk) 15:28, 18 September 2017 (UTC)[reply]
  • Keep. One of the few instances we have where we can experiment with using Wikidata for storage of non-interwiki data. Also per Mike Peel and Agathoclea. —Kusma (t·c) 18:27, 16 September 2017 (UTC)[reply]
  • This sort of experimentation should not be happening in live articles. Keep it for testing in sandboxes etc, fine, but no more. - Sitush (talk) 18:44, 16 September 2017 (UTC)[reply]
  • We regularly test things on live articles (bot runs etc.) and then monitor what happens and revert when things go wrong. Being afraid of change or innovation is not how we became what we are now. —Kusma (t·c) 19:42, 16 September 2017 (UTC)[reply]
  • If I was afraid of change or innovation, I wouldn't be doing the job that I do. However, being sensible is rarely a bad thing: this thing is nowhere near ready for articles, for a bundle of reasons already noted in this discussion. Sandboxes are for testing. - Sitush (talk) 19:49, 16 September 2017 (UTC)[reply]
  • Strong keep. I've been experimenting with using {{cite Q}} after adding references to Wikidata to provide sources for data items there. The template itself is experimental, with a cryptic name. Among other projects Wikidata is being used as a database for thousands of scholarly articles (the goal is 4 million to start). This is changing the way Wikidata editors are viewing sources, which is all to the good. We have several hundred templates that use Wikidata in mainspace and most started out there. I am confused by the level of animosity towards this one. There have been objections to the use of some of the other templates, including by me, but they are still here. Even {{Wikidata list}}, which overwrites article entries periodically, hasn't been deleted. This one should be kept and improved. It should be usable in mainspace. If you are unhappy with its use in a particular article object there, but don't stop experimentation in this reference area.
Main issues with using Wikidata in order that they bother me, others' concerns will vary:
  • not properly referenced by en.wiki standards - however these ARE references
  • hard to see what the reference is (the cite doi problem) - this can be improved, I've tried using named references and comments, but there can be other ways
  • hard to see vandalism - with thousands and thousands of references in Wikidata it is less likely that those we use here would be randomly hit
  • hard to edit references in Wikidata - painfully true, but only a few editors are using cite Q at the moment, just ask us to fix it
StarryGrandma (talk) 01:58, 17 September 2017 (UTC)[reply]
  • Strong keep. The module Cite Q is a possibility to use the same bibliographic data in various articles of en-wiki but also in various wikipedias of different languages. This is certainly an improvement compared to the state before when you had to copy and paste the same information in some wikitext-format in several articles or just enter it again. Moreover, we can share the bibliographic data with others as for example refernce management systems. This is IMO the same idea as we have WikiCommons for images and more. Further progress or improvements cannot come by just deleting such modules at an early stage. Zuphilip (talk) 20:04, 17 September 2017 (UTC)[reply]
I endorse the importance of this feature without changing my !vote above. As someone who occasionally translates Wikipedia articles and frequently draws on material written in other languages, it's incredibly valuable to have a simple way for a reference to appear in a different Wikipedia without having to learn a new set of citation formats.--Carwil (talk) 15:28, 18 September 2017 (UTC)[reply]
That is an excellent reason to keep this template (and to make sure it is rolled out everywhere). Translations should be able to share the same citation database. —Kusma (t·c) 09:24, 19 September 2017 (UTC)[reply]
The content translation tool takes care of references during translation and we have "cite journal" and "cite book" installed in nearly all languages. As someone who manages a large translation project yes it would be nice to have centralized references, but this should not come at the loss of metadata within wikitext. Doc James (talk · contribs · email) 16:52, 19 September 2017 (UTC)[reply]
  • Delete per Fram, JohnBlackburne, Doc James, Blueboar and SlimVirgin. I don't think anything from wikidata belongs on en-WP because it is crud.Smeat75 (talk) 20:54, 17 September 2017 (UTC)[reply]
  • Delete. It is frustrating to see waste of good will among Wikipedia editors which seems to come with strident advocacy for wikidata and various template-related arguments. Honestly a huge part of this is the personalities and/or attitudes and/or the ways of speaking of some of the advocates. Whatever they want to accomplish is not worth it; shutting down any initiative like this is the best policy by far. --doncram 03:42, 18 September 2017 (UTC)[reply]
  • Keep but keep it out of BLPs. (Seems something we can easily do with a bot?). —TheDJ (talk • contribs) 11:41, 18 September 2017 (UTC)[reply]
Arbitray break 1 edit
  • Comment/Proactive suggestion: Clearly, there's been a lot of intelligent discussion around the WikiCite theme about using Wikidata as a repository for citation material. {{cite Q}} is one small piece of implementation of that vision. Right now, it only a prototype (as the Template page says). If further development is to go forward…
    1. Restricted use is the appropriate way to test a prototype.
    2. One thing putting forward a prototype does is create useful feedback, including much of what's on this page.
    3. WikiCite is in bad need of central, accessible discussion space to process concerns, receive bug reports, reformulate proposals, and question core assumptions. Right now, that seems to only happen through crisis-driven shouting matches, which are poor spaces to learn. If you want to tinker on Wikipedia in a way that changes things, start a WikiProject already and be open to conversation.
    4. The largest element of feedback on this page is this: citations must continue to be readable in Wikitext and editable on Wikipedia. So, find a way to use Wikipedia:Substitution to generate a non-live citation from Wikidata. Second, include a Wikidata link in those citations. Third, create a bot that scans such citations for changes and alerts Wikidata editors.
    5. Curb your ambitions about replacing the entire citation system for now. (The Cite Q template's documentation reads: "Once robust the functionality should be merged into {{Citation}}.") Wikipedia's citation system isn't perfect, but it has been greatly perfected by many incremental improvements (including ability to auto-generate citations from many sources and to edit citation fields in the Visual Editor, both of which run circles around the Wikidata process). Whatever the virtues of a new system, it will get rightly shouted down until it becomes as usable and functional as the current system. Expect to spend a long time in development before thinking about widespread implementation.
    6. Start broad, cross-project conversations with Wikipedians about the benefits, risks, possibilities, and challenges of making citations smart. Be open to the risks and challenges, which you may not be thinking through clearly yet.
    7. Also, be open to the notion that Wikidata may not be the space to implement a universal citation system, or that citations should not auto-update. Consult with people for whom citations are their lifeblood (e.g., research scientists, social scientists in book disciplines, historians) about what dose and doesn't work. Conceptual questions about "a card catalog that anyone can edit, but whose data appears instantly in thousands of articles, e-books, and websites" are real. Perhaps greater protections for source data (each of which becomes a high-use template in Wikipedia terms) and greater skills training for catalog data entry (which is done in the rest of the world by librarians knowledgeable of complex data structures) will be needed.
    8. But, a Wikimedia-wide citation system that facilitates cross-language knowledge sharing would be a precious thing of great value to the Wikipedia mission. Don't be daunted by the difficulties, but don't assume that technology will instantly answer them. And diplomacy and sensitivity to people who do the hard work of maintaining the existing Wikipedias is going to be essential.--Carwil (talk) 15:28, 18 September 2017 (UTC)[reply]
    • You seem to conflate the template documentation text that you quote in your fifth point "Once robust the functionality should be merged into {{Citation}}.") with "replacing the entire citation system". The former in no way means the latter. As for your seventh point, "Consult with people for whom citations are their lifeblood..." that is already being done, extensively and openly. The assumptions you allude to in your final point are not being made by anyone that I have encountered, here, on Wikidata, or in the WikCite part of our community. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:08, 18 September 2017 (UTC)[reply]
  • Comment I like the idea of using Wikidata as a "BibTeX for Wikipedia". I haven't looked at the specific implementation to have an opinion on whether the current attempt is worth keeping or needs to be scrapped and redone, but I do see that most of the !votes above seem to be complaining "Wikidata is horrible and too hard to edit" rather than complaining about the template itself. Anomie⚔ 19:03, 18 September 2017 (UTC)[reply]
  • Keep - Zuphilip expresses my feelings well: The English Wikipedia is the flagship project of a family of projects, and when we create something that has the potential to benefit many other language Wikipedias, it makes sense to face problems as they arise here and solve them. We need to have functionality that scales across multiple projects, and the ability to quickly and simply re-use citations from English Wikipedia into another language is a goal worth striving for. Does this template do the job perfectly? Of course not: it is in its infancy and needs work to adress some of the issues raised here. But nobody ever made progress by giving up as soon as they encountered difficulties. --RexxS (talk) 13:01, 19 September 2017 (UTC)[reply]
    • User:RexxS The Content Translation tool already handles the current major citation styles. Why not simply add this id to the existing cite journal template? Doc James (talk · contribs · email) 16:27, 19 September 2017 (UTC)[reply]
      • @James: The Content Translation tool would be able to do a better job if the citations were a central resource that automatically applied localisation - just as Wikidata's own interface does. You might understand the reason why adding this id to the existing cite journal template is anything but simple if you tried it. All of the CS1/2 templates are candidates for fetching their information from a central resource, but that's a big job and fraught with complications that really need to be explored and solved before such a major undertaking is attempted. This template represents the first steps in confronting problems like how to deal with multiple editions of a book, etc. and we need to find solutions before attempting changes to major templates like cite journal which has over 175,000 transclusions. Let's get something working on a small scale and iron out the wrinkles on this template first. --RexxS (talk) 16:44, 19 September 2017 (UTC)[reply]
        • As long as the template is not used in main space I am okay with its existence for testing purposes. Not happy with losing metadata from within wikitext. We already had a couple of templates that did this and we had a bot convert these templates to hosting the meta data within wikitext. Doc James (talk · contribs · email) 16:49, 19 September 2017 (UTC)[reply]
          • I agree that having all data within wikitext is easier in the short term, and for a single article. However, if links break or additional URLs for a reference become available, having the metadata in each article's wikitext is suddenly worse than storing them centrally (then you have to update many articles on many wikipedias). I think looking at this from the perspective of a single article isn't the right way forward. We might be able to get rid of a lot of bot editing if we can get our metadata storage right. —Kusma (t·c) 16:55, 19 September 2017 (UTC)[reply]
          • I have created at least half of the template's current transclusions - I don't think that, in doing so, I've removed citation metadata from Wikipedia more than once, as a test, if that; they are all new citations, mostly on new articles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 19 September 2017 (UTC)[reply]
  • Comment – I gave it a try to see whether the {{Cite Q}} template could be used in mainspace with a subst:. The result was a bit disappointing (see Wikipedia talk:Wikidata/2017 State of affairs#Mainspace use: subst?), so: Question: could the code of the template be rewritten thus that it would result in a clean user-friendly output in mainspace when used with a subst:? --Francis Schonken (talk) 13:14, 19 September 2017 (UTC)[reply]
    Yes, although it would probably require edits to some of the templates it calls as well. Pppery 02:36, 22 September 2017 (UTC)[reply]
I'm still divided between "delete" and "keep for experimentation, with implementation restricted to a limited set of sandboxes and/or talk pages until if and when a beta-version (probably with "subst:") can be approved, or until all experimentation is ultimately deemed unsuccessful resulting in a delete of the template". Another suggestion for a way forward is inspired by German-language ADB pages at Wikisource: such pages, e.g. wikisource:de:ADB:Gesenius, Wilhelm, contain at the bottom of the page a "Suggested citation format" (German: "Empfohlene Zitierweise"). Other reliable websites suggest similar pre-formatted citations (see e.g. "Cite This Item" at the bottom of this LOC page). So, Question (#2): can pre-formatted citations be stored (or "generated on the fly" by request) in Wikidata items, easier to "call" (with a "subst:" template or whatever), or, possibly in a first step, transferable with old-fashioned copy-paste? --Francis Schonken (talk) 11:23, 20 September 2017 (UTC)[reply]
Isn't that exactly what the current template, if it were made to subst cleanly, would do? Pppery 02:36, 22 September 2017 (UTC)[reply]
No, the proposal is to generate/store the formatted citation at Wikidata (so that it could be visualised there, i.e. as a proposed reference format, without visiting Wikipedia); The Cite Q template only visualises the formatted citation at en.Wikipedia, thus needing similar templates, each of them calling and arranging Wikidata properties in a similar procedure, i.e. doing the same work, when other WikiMedia projects want to use formatted citations: this question is about whether the code that performs the formatting can be run centrally, at Wikidata, instead of on each WikiMedia project separately: seems like an economy of resources for doing essentially the same job (and less endless discussion about the template at en.Wikipedia). --Francis Schonken (talk) 05:53, 24 September 2017 (UTC)[reply]
So, instead of writing one template that can be copied once to each language Wikipedia that wants it, you propose asking editors on every language Wikipedia to go to another site (Wikidata) each time they want a citation, track down the citation they want, and then manually copy-and-paste it back into their own Wikipedia. Yeah, I can really see that gaining traction. --RexxS (talk) 14:31, 24 September 2017 (UTC)[reply]
No this "question" is not about what I "want" (what I want is already expressed in my !vote below). The question is about exploring a route. That route seems to have some advantages:
  1. would be available immediately, to all WikiMedia projects, whether or not they have any sort of citation templates implemented;
  2. would be available before the cite Q template is translated/reprogrammed to the local format(s) of citation templates, for the WikiMedia projects that have any (the local variants of the cite Q template may take some time to develop, plus the preliminary period of developing one that would be ready to be exported to other languages might still take a lot of time too);
  3. and other advantages already intimated above (the cite Q template may become considerably simpler to develop etc), and a new one per your comment: rather invites to go visit the Wikidata item before using it as a source. It is a questionable habit to use something as a source which you have never seen. For instance, this morning I updated Johann Sebastian Bach: His Life, Art, and Work (Q19231225), and as a consequence it generates an error when used in a Cite Q template – which apparently can't handle books published in more than one edition: it seems easier to implement a "select an edition" feature before generating the formatted citation at Wikidata than via an immensely complex Cite Q template.
Reason enough to explore the route imho, even if, I'm sure, it may not all be advantages. --Francis Schonken (talk) 15:29, 24 September 2017 (UTC)[reply]
I've fixed Q19231225. The problem was, you added metadata about editions to the item about the work; as though they were about the work. What you should have done - if you wanted to store metadata about editions - is to create items for the editions, add the metadata to those, and then add statements linking to the editions to the item about the work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 24 September 2017 (UTC)[reply]
Alas, no, I've reverted these Wikidata edits. They're about the same work (which has only one article in Wikipedia, that is in English Wikipedia, one source text, that is in German wikisource, and one commons category). The Wikidata item should present the international links available for this topic, it should not be written to please a template that only exists on en.Wikipedia (and in that case without linking to an English-language edition). --Francis Schonken (talk) 18:13, 24 September 2017 (UTC)[reply]
The problem repeats of course for Johann Sebastian Bach: His Work and Influence on the Music of Germany (Q24969482):
Note that this book, when used as a reference in en.Wikipedia, usually doesn't relate to the original two-volume German version, but to the English three-volume translation (and usually not even the 1884–1885 first edition of that translation), e.g. from the Bach article:
As I said below: there are still too many issues to address to let this template into mainspace. --Francis Schonken (talk) 07:38, 25 September 2017 (UTC)[reply]
  • Keep for limited use, as Carwil and Zuphilip put well. WD as a sort of BibTeX for all wikis would be great; allowing painless reuse across wikis is an extraordinary benefit; polishing this will take time. We should encourage small, focused experiments with this template, both in and out of main space; and should make it work with subst. I agree for instance that there are mainspace contexts that already require going to WD to edit data, where something like Cite Q makes sense now. – SJ + 19:21, 19 September 2017 (UTC)[reply]
    A specific idea for converting Cite Q (changing when WD changes, uneditable data) to a static Cite would be a bot that extracts the cite data as of [date], and includes the WD link and the date in a traditional cite. Someone could copy that to a new wiki again using Cite Q if that were available on the second wiki; where it could be again substed to a static, traditional cite [or whatever the equivalents are on the second wiki]. – SJ +
  • Keep but clarify to ensure that the prototype does not creep into general mainspace use until ready. Some sort of error message could go far to reducing this anxiety. We might do better to have, for each cited work item Q, a FirstCitedAt property P so that each such bibliographic item can readily be traced back to the lang-wp mainspace article in wikitext from whence the information is derived. LeadSongDog come howl! 20:46, 19 September 2017 (UTC)[reply]
  • Keep per Carwil, Zuphilip, and others, but with a limited scope. This template is very useful for prototyping the ability of connecting reference metadata – which belong to the body of a Wikipedia article – to source metadata – which many people, including myself, have argued would be much better served by a centralized bibliographic repository as structured, reusable data. I fully understand the concerns brought up in this thread, from editors supporting the deletion decision, and they boil down to something fairly straightforward: replacing an already complex template with an obscure reference to a Q-item is likely to make it much harder for contributors (particularly newbies) to add, modify, or correct a reference to a source. It's hard to overstate the technical barriers that markup creates for new contributors, and I'd personally oppose any broad adoption of a template pulling data from Wikidata without strong community consensus. This concern is absolutely legitimate and should be respected. This being said, the existence of this template is critical for the experiments I mentioned above that cross-link references and source metadata. The goal of the WikiCite initiative is to create a rich, well-curated, structured repository of metadata on every source cited across Wikimedia projects. Many of the people involved believe the existence of such a centralized database of sources will create value, regardless of how it is reused (and whether it is reused at all) by other Wikimedia projects. The problem of reuse of content or structured data across projects, in a way that is graceful, transparent and respectful of different norms, policies and expectations in these projects, is a much bigger one, and it applies to bibliographic data as well as any type of data or resource reused across projects. For this reason, I'd support keeping this template but limiting its scope to a small set of articles allowing testing without giving the impression that this is meant to replace and deprecate any existing template. (full disclosure: I have been on the WikiCite organizing committee for the past 2 years) --DarTar (talk) 22:02, 19 September 2017 (UTC)[reply]
    • Since it is probably lost in the noise above, I'll say it again: sandboxes are the place for testing. - Sitush (talk) 09:55, 20 September 2017 (UTC)[reply]
      • That's certainly true, and the template was tested in a sandbox before being used in articles, and each new change is also tested in its sandbox. However, once such testing has been undertaken, and for something as complex as citations, with an uncountable and unpredictable number of edge cases, there also has to be some trial use in article space, which is where we are now: just 225 transclusions in 5.5 million articles and goodness knows how many magnitudes more citations, which have already highlighted, and resulted in fixes to, some minor issues. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:42, 20 September 2017 (UTC)[reply]
        • So copy to a sandbox whatever article it may be that you want to use as a testbed? - Sitush (talk) 12:06, 20 September 2017 (UTC)[reply]
          • I said "trial", not "test". In the cases to which I referred, the issues have been uncovered by other people. Sandbox testing would not have found (indeed, did not find) them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:03, 20 September 2017 (UTC)[reply]
            • Andy, your somewhat brusque manner throughout this discussion or in the recent ANI thread is probably not helping matters. A trial is a test, unless you are more specific as you now have been. As I see it, no amount of trials/tests are going to resolve the key issue of obscurity that affects this template in its current form, ie: a letter followed by a series of numbers. I'm indulging those that fancy pursuing what appears to be a fatally flawed design concept by suggesting that they can continue to experiment outside of article space but I'm not prepared to see it used in that space until that seemingly fatal flaw is addressed. And don't point me to ISBN numbers as an analogy, please: I add those things to citations but rarely use them, nor need to do so. - Sitush (talk) 13:17, 20 September 2017 (UTC)[reply]
              • I'm amused to be lectured on my "manner" by someone who recently referred to the work of our fellow WMF volunteers as "some distant project that has bugger-all control over what happens there". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 20 September 2017 (UTC)[reply]
                • You may be amused, Andy. It alters nothing: I've have never denied being sometimes brusque in manner, and it is no secret that I have a very ambivalent attitude towards people who have been paid in any form by the WMF. However, all I said was that a brusque approach may not be particularly helpful in this discussion. Mike Peel's approach seems to be much more likely to evoke reasonableness in this context. I note that your last response completely ignores the relevant point I made about the template itself, ie: it was merely sniping. - Sitush (talk) 23:42, 20 September 2017 (UTC)[reply]
                  • The problem with attempting to do all the testing in a sandbox is that calls to fetch information from Wikidata are different when you are working with the Wikidata item linked to the article where the call is being made. It's been possible to fetch from the linked item for almost five years now, but getting information from other Wikidata items was only made possible two years ago. So at some point, we really need to do trialling in actual articles. The point at which that happens, and the size and scope of any trials are judgement calls, but I'd tend to rely on the developer's judgement in such cases. I accept that not everyone will share my view on that. --RexxS (talk) 01:05, 21 September 2017 (UTC)[reply]
                    • This is a fair point, and I'd have no object to a handful of instances in article space for testing purposes. A handful would need to be less than ten, I think. Mike Christie (talk - contribs - library) 01:17, 21 September 2017 (UTC)[reply]
                      • At the time of writing, we have 5,481,060 articles; and 225 transclusions of this template (on fewer than 225 articles, but let's call it that, for convenience). Your suggested ten articles (a figure for which you offer no rationale) is 0.000182%. 225 articles is 0.004105%. Are you really suggesting that the difference - amounting to well under a half of one thousandth of one percent of our articles - causes significant problems? On what evidence? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:08, 21 September 2017 (UTC)[reply]
                        • @Pigsonthewing: "At the time of writing, we have 5,481,060 articles; and 225 transclusions of this template". At the time of writing, User:DPL bot (currently poorly sick) reports 28,478 bad links to DAB pages. Estimating from my own experience, it has missed (and could never find) at least another 10,000 bad links where the WP:PRIMARYTOPIC linked to was just plain wrong. (That's from eyeballing.) One bad link is bad enough. In an encyclopaedia, 225 bad links is unacceptable. Narky Blert (talk) 00:41, 27 September 2017 (UTC)[reply]
                          • As explained to you at length below, those errors are not caused by Cite Q. I'm not sure why you continue to flog this particular expired equine, and you certainly have no evidence whatsoever that Cite Q is causing even one of your "estimated" 10,000 errors, let alone "225 bad links". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:38, 27 September 2017 (UTC)[reply]
                    • For this template, this shouldn't be true: it is not dependent on the article you are using it on, only on the source call you put through (the Q number). The idea is that you could use the same template in multiple articles. If it doesn't work in your sandbox or in draft space, then it again is an argument against using this. Fram (talk) 06:59, 21 September 2017 (UTC)[reply]
                      • Andy, my preference would be to keep it out of mainspace completely until the problems I listed above are fixed. RexxS's point is that some testing needs to be done in mainspace; I picked ten articles since I could imagine there might be multiple scenarios to test, which might require different types of article (lists, BLPs, ...) to test. The specific number is arbitrary but I see no reason for it to be more than a handful. Mike Christie (talk - contribs - library) 23:26, 21 September 2017 (UTC)[reply]
  • Comment on use of this forum. This forum is suitable for what amounts to code review? I think not. I suggest that the community needs to step back here. We have a sprawling if passionate discussion. I think crafting a sensible outcome is difficult in a forum where "keep" and "delete" are the typical outcomes. There are usability, correctness and data integrity issues being raised and mingled. If I read things correctly, the correctness issues are manageable. That is typical of discussions around use of Wikidata; which I believe should be piecemeal, incremental and addressed in a problem-solving spirit. So ... I suggest the community bites the bullet and admits that the introduction of Lua has raised the stakes in talking about templates, which are not the simple macros they once could be considered. Wikidata is not going away, and we do need discussion that generates more light than heat. How best should that be done? Charles Matthews (talk) 09:37, 20 September 2017 (UTC)[reply]
  • Delete, unless recoded to require substitution in mainspace. If the data is no longer being pulled from off-site, in our live encyclopedia content, then the editability and confusion problems go away.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  10:35, 20 September 2017 (UTC)[reply]
    • The entire point of this template is to connect to citations from an external database. Subst'ing it is about as useful as subst'ing {{Latest stable software release/Linux}}. —Kusma (t·c) 08:52, 21 September 2017 (UTC)[reply]
      That's overstating the case and a false analogy, since the title, author, publication date, journal name, etc., of a citation does not change incrementally over time, but is a fixed set of data that's either correct or not. A subst use case is obviously practical, a decision that the data pulled from WD is correct, a substitution to make the data locally editable, then either leaving it as-is, or reconfiguring it to fit the WP:CITEVAR of the article. That said, I've gone through another week's worth of commentary on this, and posted a different !vote at the end, in favor of keeping the template if it's constrained to testing outside of mainspace for now.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:26, 27 September 2017 (UTC)[reply]
  • keep (with caveats) – A new-ish idea seldom survives first contact with implementation (or with real-life). {{cite Q}} fetches data from wikidata and assigns those data to standard cs1|2 parameters if the template call does not already assign local override values. It then calls {{citation}} to render the final citation. Some problems that I see with this template's implementation are:
    • reliance on poorly curated data which, I think, is due in part, to a lack of standards that define the minimal requirements for what constitutes a proper bibliographic entry in wikidata – that is a wikidata problem and not necessarily a problem of this template but I can see that people will blame this template for the failings of wikidata
    • as it is implemented now, for some parameters, |title= in particular (a required parameter), {{cite Q}} will fetch an alternate 'title' from some place other than a 'title' property in the wikidata record (the wikidata page label); the alternate may or may not accurately reflect the source's actual title – this was a 'fix' made to the template when the better fix would have been to the wikidata
    • it needs improved author/editor name handling (human names being what they are, this seems to me to be difficult issue to 'fix')
    • it needs to be able to use the whole suite of cs1|2 templates for rendering and not just {{citation}}
    So, the caveats for my keep !vote are, at minimum:
    • revise the template so that it shall only pull information for a specific parameter from the specific wikidata properties that match the cs1|2 parameter: for example, |title= shall only be filled from {{#property:P1476}} or from a local |title= override. When there is no local override and when there is no property defined in the wikidata, then for required parameters, the template shall show an error message, perhaps akin to the error messages shown by the cs1|2 templates and shall add the article to an appropriate error category; again much like cs1|2 so that editors can make appropriate fixes. Showing error messages is not enough; the error message must link to a help document that explains the meaning of the error message and how to fix it; perhaps something akin to Help:CS1 errors.
    • add a hidden maintenance category to articles when {{cite Q}} uses local override parameters. Here again, editors can use this information to apply fixes to the wikidata, if appropriate. Just adding a maintenance category to such pages is not enough. At the top of the override-parameter-category there shall be explanatory text that describes why the pages are listed there and what to do about them. Taking a queue from cs1|2, perhaps the template should render a message similar to the cs1|2 maintenance category messages with display controlled in the same way (see Category:CS1 maintenance).
    small things matter:
    • error and maintenance messages might include something that looks like the template call as a finding aid (it can't be exact because templates cannot see how they were called)
      {{Cite Q|Q12345}}: missing or empty title property P1476 (Help)  
    • to be consistent with other uses of wikidata, replace the wikidata link at the end of a {{cite Q}} rendering:
      [[Wikidata]] [[:d:Q21707170|Q21707170]]
      Wikidata Q21707170
      with the standard pencil icon:
      {{EditAtWikidata|qid=Q21707170 }}
       
    The intent of these caveats is to use {{cite Q}}:
    • to drive quality into the wikidata upon which it relies. We cannot 'hope' that one day the quality of wikidata will improve. The data will never self-correct. Editors here must take an active part in making the data correct. If we want quality data, we must use the tools that we have to coerce the data into being correct.
    • as a learning experience and test-bed for developers and editors alike. Here is an opportunity for us to learn to control and use the data and tools available from wikidata by implementing a single, highly correct, template.
    Some here have suggested that we should keep this template but prohibit its use in main space. I don't think that we should do that. Occasional use in talk, sandbox, and other non-main namespaces won't expose the template, its developers, its users, to the diverse variety of real-life data that are a consequence of use in main space. Such restrictions will stifle its ongoing development because there are no 'rewards' for doing that development – why should any developer put any effort into anything when the resulting work would never be used? Would you have authored that FA if you knew it would never get out of Draft?
    Others have suggested that it isn't time for this template. If not now, when? Why wait? Here we have a single template with relatively few, human inserted, transclusions. From this we can learn what to do to make best use of the wikidata resource and we can learn what not to do. We are in the early days of wikidata; it is not going to go away, the idea of using wikidata to store citation metadata is not going to go away. It seems to me that railing against the future is a fruitless endeavor so we should use our influence to direct that future rather than reject it because: the data are not perfect; because the template is not perfect; because the wikidata user interface is not perfect; ...
    Yeah, to a newby, {{cite Q}} in wikisource will be inscrutable. But, to a newby, a lot of wikisource is inscrutable. Learning how to edit at wikipedia is not easy and it took all of you a bit of time, a bit of success, a bit of failure, to become the competent editors that you have become.
    —Trappist the monk (talk) 10:28, 21 September 2017 (UTC)[reply]
  • DeleteUserfy and let the editing community decide when, and under which conditions, an improved version of the template may be ready for mainspace trials. I don't think it inappropriate to give suggestions regarding the template in this TfD thread, but there are too many to have a short-time effect on sustainability of the current template. WP:VPT seems appropriate to notify the community on future development (e.g. whether a decent "subst:" output can be generated by the template or whether another, more promising, route is followed, etc.), and that also seems a suitable place to propose, and find consensus for, possible future mainspace trials. --Francis Schonken (talk) 11:06, 21 September 2017 (UTC)Thinking it over once again, I see no future for this template. If anything similar would be attempted, which imho should be fundamentally different, it should not be allowed in mainspace before a proper RfC. --Francis Schonken (talk) 20:17, 28 September 2017 (UTC)[reply]
  • For an example why moving citation data to Wikidata might be a good idea, see for example this edit. Archiving the references and storing them is in principle a good idea, but adding 90k to the article source isn't worth it. There are limits to the cherished model of storing all information in one wikitext page. —Kusma (t·c) 13:43, 21 September 2017 (UTC)[reply]
    • What would be gained and what would be lost by using "Cite Q" in this example a) for the reader and b) for the enwiki editor? Fram (talk) 14:03, 21 September 2017 (UTC)[reply]
      • a) no change b) crazy citation metadata would be moved out of the wikitext and replaced by a references to strange Q numbers. A mixed blessing: the wikitext becomes quite a lot shorter and a bit easier to read, as it isn't interrupted by very long template calls, but the direct connection to the citation data is lost, especially for the first instance a citation is used, and further clicks are necessary (unless UI improvements are made; for example, the references imported from Wikidata could be listed under the edit window together with their Q numbers). Probably more programmer creativity is necessary here before one could recommend a large scale conversion of citation data to Wikidata items. —Kusma (t·c) 20:00, 21 September 2017 (UTC)[reply]
        • "unless UI improvements are made" That is, of course, planned. But we need to show that the template is workable, first. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:58, 21 September 2017 (UTC)[reply]

Given some of the alarmist comments above, one wonders how on Earth editors cope with the myriad current citation templates that work with a single ID parameter:

  • {{cite AHD|16274}}
  • {{cite amis|id=03777}}
  • {{cite DANAS |volume=2}}
  • {{Cite EWD|1000}}
  • {{Images of England|200575}}
  • {{cite rcn |id=9909}}

or indeed those with no ID parameter, such as:

  • {{Cite brooklyn}}
  • {{Cite citygrid}}
  • {{cite dps}}
  • {{Cite enc-nyc}}

and the very many others listed under Category:Specific-source templates, some of which have been in regular use for years, it seems that claims that such templates are a "fatally flawed design concept", or that there is consensus that "Citation data should be in the article where the citation is used, not somewhere else" are, in fact, bogus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:47, 22 September 2017 (UTC)[reply]

Classic Tu quoque fallacious argument. We are discussing this template. Jytdog (talk) 15:08, 22 September 2017 (UTC)[reply]
Nice try at dismissing my argument, but as can be seen above, we are discussing editing behaviour, claims of consensus, precedence, and more. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:25, 22 September 2017 (UTC)[reply]
Andy Mabbett, if you look on the Category:Specific-source templates page it states They are intended to be substituted. That seriously nukes your argument. As for the cite(thing)|id=#, citing a named collection by an actual id number is vastly more reasonable than a completely unreadable citeQ template filled with an utterly random number. Alsee (talk) 10:27, 23 September 2017 (UTC)[reply]
Not necessarily. I created {{cite DANAS}} – one of the templates that Editor Pigsonthewing mentioned – in February 2014. The subst: text was added to the category with this edit in March 2016; apparently without discussion but also apparently because of frustration with the TfD system. I never intended {{cite DANAS}} to be substed because periodically (probably because some new squeaker ensign needs to show his boss that work is being done) the source website gets rearranged and breaks all of the links to DANAS.
—Trappist the monk (talk) 11:17, 23 September 2017 (UTC)[reply]
"Nukes my argument"? It doesn't even tickle it with a feather. Some of these templates have four-figure transclusion counts (I haven't checked them all; some may be far higher still), and nothing in their documentation to say they should be Subst'd. Incidentally, a Wikidata QID very much is an "actual id number" - and they are used as such by many external bodies.. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:51, 23 September 2017 (UTC)[reply]
  • Strong keep: I hate having to duplicate citations when used on more than one page. While I understand the argument "all references information should be on the page", I hate the current approach to references in Wikipedia, I hate the slow visual editor (and its UI for editing templates), and I have been wishing for a Wikidata-driven approach like this all the time. I liked "Cite doi" while it existed, although it was flaky quite often (only working for journals, not conference proceedings, wtf?). In my opinion, we should migrate at least all citations to scientific publications to Wikidata eventually - of course the exact details may need some polishing. And yes, we also should eventually fix all the horribly bad things about how the Mediawiki language is parsed and evaluated. Yes, Wikimarkup made Wikipedia, but in fact a much simpler version of the markup. Current markup with its mixture of latex-like math, xml-style tags, real html-tags, wiki-markup, is just a PITA and keeps on screwing us over and over again. The more structured data we can migrate from Wiki-infobox/template-hacks into structured data like Wikidata, the better. Chire (talk) 14:08, 25 September 2017 (UTC)[reply]
  • So, with Cite Q, you have to either go to Wikidata, find the exact right version of the source you want to include (not easy in many cases), add the Q number to the template, and then add extras like the page number anyway, or you have to go to another article which uses the same reference (but how are you going to find one? You can't search enwiki for the name of the source any longer, as it is stored as "Cite Q number", not as "Jones and Smith, "the History of Whatchamacallit"), copy the reference (and change the page number and so on); without Cite Q, you need to find another article with the same source (like I said, much easier in that case), copy the reference, and change the page number and so on. I don't see where in your scenario the supposed benefit is coming from. (Mind you, I hate Visual Editor as well, but that has no impact on this whole discussion). Fram (talk) 14:20, 25 September 2017 (UTC)[reply]

"You can't search enwiki for the name of the source any longer, as it is stored as 'Cite Q number', not as 'Jones and Smith, the History of Whatchamacallit'" No, Fram, that's not true. Searching Wikipedia for the tile of a work cited using "Cite Q" will find the page on which that work is cited, even when Cite Q is the only way that text is included in the article. Wikipedia's search function searches the rendered text, not the source code. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 26 September 2017 (UTC)[reply]

You're right, that does work. I still don't see the benefit for duplication (copying one or the other is needed), but this aspect is less dramatic than I thought at least. Fram (talk) 04:46, 27 September 2017 (UTC)[reply]
It's not a if we couldn't easily solve these. For example, the visual editor (if you like that) *can* be made to automatically search for e.g. the DOI, or even title, on Wikidata. Page numbers often exist in Wikidata; all that is probably needed is to extend the Cite Q template to also include them. With Cite Q and Wikidata, missing page numbers can even be more easily added, because they are only in one, structured, data storage rather than duplicated many times. Because page numbers may even change: when a paper is published "online first", it may not yet have a page number; once it gets printed, it will get actual pages, issue; and even the year may change. Again, having the data in a *single*, *structured* data store means we can easily fix this; rather than having to update several pages. Chire (talk) 10:23, 28 September 2017 (UTC)[reply]
I utterly dislike VE... "Page numbers may change", yes, but then the ISBN, link, year of edition, ... normally change as well. There is no need to change a reference because something gets printed, reprinted, ... and the new reference would be a different Q-number anyway, so no way to automatically update that here (assuming that every instance of the old may be changed to the new would be rather dangerous). What you present is a) not a fix, and b) not the way Wikidata + CiteQ works. (And "page numbers often exist in Wikidata" seems a very optimistic statement. I have looked at many items before on Wikidata, and have now used the "random item" 50 times: I didn't find a single book, nor did I find a single encyclopedia article that used a book as a reference. There are books (which are used as references) created as items, but I doubt that any individual book pages are created as items, and that is what you would need to get the page number via Cite Q. Adding items per page of a book would significantly increase the number of items on Wikidata, but I think it would be a bridge too far even for them. Fram (talk) 11:39, 28 September 2017 (UTC)[reply]
There are not only books, you know. Of course the Wikidata doesn't know which specific page you are going to cite. That is what {{Cite Q|...|page=123}} is for, cite a page of a book. But journal articles (and no, a "reprint" is not the same there as for books either!) are considered to be published when paginated and printed. See e.g. [9] for correctly citing early-view articles. But of course, once the article is in a printed version, we should update year, issue, number, and pages information, as the printed version is the preferred source/version of the article (usually, the DOI will remain unchanged, and redirect to the printed version; but that makes the online-first version often inaccessible. In fact, often the links on Wikipedia to such an article will the point to the printed version, with different page numbers etc. than given in Wikipedia, so we get a mismatch between the data here and the link). But it is considered to be the same article as before (and the contents are not supposed to change).
I've added support to Cite Q for "pages" (as I'm not a template expert, and Mediawiki templates are horrible, I didn't do it entirely correct, but that was quickly fixed). Example (note the page numbers are 1-15; this is supposed to be present for journal citations): P. Ashwood; S. Wills; J. Van de Water (9 May 2006). "The immune response in autism: a new frontier for autism research". Journal of Leukocyte Biology. 80 (1): 1–15. CiteSeerX 10.1.1.329.777. doi:10.1189/JLB.1205707. ISSN 0741-5400. PMID 16698940. Wikidata Q22241718. {{Cite Q|Q22241718}}. So Cite Q does currently support both: explicit page-within-a-book use (by adding the page= attribute; but being able to reuse all the book metadata), as well as the pages as used with journal publications that are the same on every use and shouldn't be copied into every article source code.
But it's not just that. There are many more things where the wikidata approach is beneficial. For example, an author may get a Wikipedia article at some point. With Wikidata, these link to the authors Wikipedia article will appear automatically on all Cite Q citations. With the manual templates, you have to edit the authorlink= fields whenever you create an author article. Wikidata is also working hard to link various databases, so you get PubMed IDs, DOIs, CiteseerX, etc. that you would all have to manually look up every time. Chire (talk) 16:11, 28 September 2017 (UTC)[reply]
Queries edit

I have three simple queries relevant to the discussion above:

  1. Is there a list which shows the most popular citations? I mean by number of pages on which it is being used. If not, can such a list be prepared? How?
  2. Can someone please refer me to the list of explicitly non-RS like I was told that Gyan publications are non-RS for history articles. If such a list is not there, how can we get such a list? Also how to get a list of pages on which such refs are cited??
  3. How does wikipedia (in current regime) rank / rate references? How can a new editor know about the reliability of a random source for a particular article?

These questions, if answered, might help in bringing clarity to the above discussion. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 06:25, 22 September 2017 (UTC)[reply]

To 1: There was some work at the hackathon with Crossref Event data, and they analyze the DOIs most referenced in Wikipedia (this does neglect publications without a (Crossref) DOI etc.). The most referenced DOI found https://doi.org/10.5194/hess-11-1633-2007 is used more than 500.000 times across Wikipedia, mainly as a source for some climate data. Other DOIs are also used often (thousands or hundreds times) in Wikipedia. Etherpad with some notes is here: https://etherpad.wikimedia.org/p/WikiCite17Day3EventData --Zuphilip (talk) 18:54, 22 September 2017 (UTC)[reply]
  • Comment – a book worth citing in Wikipedia will more often than not have been published in several editions, and may have been translated from or in other languages. If that is the case, Wikipedians may choose a recent edition, which may or may not have the same page numbering as the original edition and/or contain other revisions or be a translation, etc, when using the book as a reference. The original edition may or may not be available or accessible (e.g. language-wise) to the editor using the book as a reference. Nor {{Cite Q}}, nor the WikiData item about the book (the work) seem to have a knack on how to handle these issues satisfactorily (see examples above). A Wikipedia article on a book would usually discuss significant revised editions, first publication of an English translation, etc (i.e. without creating a separate article on each printed or otherwise published version), thus its Wikidata counterpart should probably better not be about a single edition of the book, but about the work as a whole, whatever outward form it may have taken throughout time – otherwise the Wikidata item linked from a Wikipedia page is disconnected from the latter (i.e., speaking about a different topic: the work in Wikipedia, one single edition in the Wikidata item). This includes that other-language Wikipedias would most likely use a language-version in their own language when using the book as a reference, so there is no reason to keep that version out of the Wikidata item, lest one would lose the connection between the Wikipedia articles on the same book in Wikipedias of different languages (thus forfeiting one of the primary goals of Wikidata). All of this seems to indicate that there is still a lot of work & decision-making ahead before a Cite Q-like template could be of broad practical use. Until if and when all of that has happened this is also a clear indication that the Cite Q template should, for the time being, be kept out of mainspace to avoid future mess (heavy reforms seem more likely than not ahead, and that may mess up citations using the current Cite Q format). Let the experimentation with the template take place out of mainspace, please. --Francis Schonken (talk) 09:02, 25 September 2017 (UTC)[reply]
    Different editions (including editions in different languages) should have (and often have) different Wikidata items, which solves all the problems you mention.--Ymblanter (talk) 09:45, 25 September 2017 (UTC)[reply]
Alas no, doesn't solve (quoting from above):

A Wikipedia article on a book would usually discuss significant revised editions, first publication of an English translation, etc (i.e. without creating a separate article on each printed or otherwise published version), thus its Wikidata counterpart should probably better not be about a single edition of the book, but about the work as a whole, whatever outward form it may have taken throughout time – otherwise the Wikidata item linked from a Wikipedia page is disconnected from the latter (i.e., speaking about a different topic: the work in Wikipedia, one single edition in the Wikidata item). This includes that other-language Wikipedias would most likely use a language-version in their own language when using the book as a reference, so there is no reason to keep that version out of the Wikidata item, lest one would lose the connection between the Wikipedia articles on the same book in Wikipedias of different languages (thus forfeiting one of the primary goals of Wikidata).

Mark the forfeiting one of the primary goals of Wikidata part. --Francis Schonken (talk) 09:54, 25 September 2017 (UTC)[reply]
Which only applies if the other language has its own edition to quote from. But more often than not, one version is used as reference on many language editions. Agathoclea (talk) 10:26, 25 September 2017 (UTC)[reply]
Example: the Falsifiability#References section currently contains:
The Wikidata item for this book is The Logic of Scientific Discovery (Q1868040) – calling the book as a reference with the Cite Q template results in:
The ISBN is of course wrong for the 1934 first edition (long before ISBN numbers were assigned to books): the ISBN refers to a 21st-century print, quite likely with page numbers different from the first edition. The OCLC also refers to the 21st-century print. Anyhow, all of the elements in the Q-based citation (apart from the author link) refer to different (20th- and 21st-century) German-language editions of the book.
One of the basic assets of the Wikidata item is that it connects en.Wikipedia's The Logic of Scientific Discovery to articles on the same book in other-language Wikipedias, e.g. de:Logik der Forschung in German Wikipedia.
I don't see, with the current underlying technology/programming, how that basic function of the Wikidata item can be preserved, and still extract a meaningful Cite Q citation from it, that is: meaningful for en.Wikipedia which of course usually would use an English-language version of the book in citations (as illustrated above for the Falsifiability article).
See also the policy-level recommendations in WP:RSUE: "...English-language sources are preferred over non-English ones when available and of equal quality and relevance...", which would make the mainspace use of the current version of the Cite Q template for this book at least a little bit against policy (unless when the English translation of Popper's book would be of poor quality, which I don't suppose to be the case here). --Francis Schonken (talk) 11:50, 25 September 2017 (UTC)[reply]
  • Delete. I've had (I think) three run-ins with this template, two on World Heritage sites and now one on a telescope - Leviathan of Parsonstown. In each case, the template had generated a link to a DAB page which was then picked up as an error by User:DPL bot. In the Leviathan case, there is no relevant entry on DAB page Arthur Berry. There seems no way to stop the template doing it. Links like that are completely useless and are confusing to readers (not to mention WikiGnomes – I wasted 20 or 30 minutes on the first example I found, trying and failing to solve the problem). Narky Blert (talk) 17:39, 26 September 2017 (UTC)[reply]
@Narky Blert, Pigsonthewing, and Mike Peel: This isn't the template causing the problem. The so-called "error" is produced by {{Wikidata}} which supplies references to {{infobox telescope}}. Check:
  • {{wikidata|references|normal+|{{{qid|Q459970}}}|P31}} →

References

Module:Wd (lines 639–706) has to check whether an author's name returned from Wikidata can be linked to an article on English Wikipedia. So it examines the object representing Arthur Berry, which it discovers is a dab page, so doesn't link it. However, the act of checking creates a link - see MW:Extension:Scribunto/Lua reference manual#mw.title.new: "The title referenced will be counted as linked from the current page." That's part of the way that the MediaWiki software works, so the solutions are to either file a phabricator report and ask for that behaviour to be changed, or to modify DPL bot to ignore these false positives. Hope that helps. --RexxS (talk) 22:38, 26 September 2017 (UTC)[reply]

@RexxS: In cases like this where the reference is in a different Wikidata entry, {{Wikidata}} passes the references through {{Cite Q}}. I've resolved this specific issue by editing Cite Q's module code. I think the code you point to in Module:Wd doesn't include the check to see if a page with the same name as the text exists. Thanks. Mike Peel (talk) 22:42, 26 September 2017 (UTC)[reply]
I've given you the lines in Module:Wd where the code gets a label. The call to mw.title on line 690 can create a link from the page where the code runs to the page being checked, as can that on line 2454. I've said before that getting references is fraught with problems, many of which will not be obvious. --RexxS (talk) 23:02, 26 September 2017 (UTC)[reply]
"The so-called "error" is produced by..."
I have no interest in what produces the error. It isn't a "so-called error" – it's an error. It needs to be fixed. Narky Blert (talk::::) 01:58, 27 September 2017 (UTC)[reply]
It was of sufficent interest to you for you to give it as your sole reason for calling for the template's deletion; based on what is now shown to be an incorrect understanding of the cause of the error: "In each case, the template had generated a link to a DAB page which was then picked up as an error". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:32, 27 September 2017 (UTC)[reply]
It was an error (an incorrect inclusion in whatlinkshere), and it was caused by the use of the template (and hopefully solved by changing Module:CiteQ[10]). There are e.g. more than 50 pages currently linking to Lois Reynolds[11] or Daphne Christie[12], even though in reality no pages link there. This is caused by her inclusion in many cites generated by the CiteQ template. Fram (talk) 09:55, 27 September 2017 (UTC)[reply]
I referred to it as "a so-called error" because it's not an error. It works exactly as expected. If a name like Arthur Berry is a dab page (which it is), then we need to check for that and not include the link. Checking produces the "What links here" that DPLbot picks up. The error, if any, is either in DPLbot's inability to distinguish between a check and a genuine link, or in MediaWiki software's implementation of the mw.title library that creates the effect. There most certainly is not an error in the code that uses that library correctly. None of this is any reason to get the torches and pitchforks out over any template/module that implements the MediaWiki software accurately. --RexxS (talk) 14:37, 27 September 2017 (UTC)[reply]
Can you give other examples of pages not actually linked but still included in a "linked" list? As far as I am concerned, when I encounter a page listed as "linked" which isn't actually linked, this is an error, no matter if you expect this to work in this illogical way or not. Fram (talk) 14:52, 27 September 2017 (UTC)[reply]
They are not common, and I have no way of searching for them, but I can manufacture a contrived one. If I wanted to find the name of the doctoral advisor (P184) of Johannes Theodor Schmalhausen (Q1765161), I could use {{#invoke:WikidataIB |getValue |qid=Q1765161 |P184 |fetchwikidata=ALL |onlysourced=no}} in Johannes Theodor Schmalhausen, perhaps indirectly in an infobox. That would give Andrey Beketov   which isn't linked because English Wikipedia has no article on Andreï Beketov. The only way to determine whether an article exists is to use either the MediaWiki mw.title library or the expensive parser call {{#ifexists:}} (which does the same thing). If someone now made a dab page titled "Andreï Beketov" (just an example - I said this was contrived), a link would be made by the MediaWiki software and show up at "What links here" for Andreï Beketov the dab page, even though that dab page is never actually linked from Johannes Theodor Schmalhausen. Now, I expect this to happen, so I don't see it as an error, i.e. something went wrong. I accept that you may wish to consider even expected behaviour to be an "error", if the expected behaviour is ... well, unexpected. Cheers --RexxS (talk) 16:01, 27 September 2017 (UTC)[reply]
I don't care too much about the semiotics: as far as I'm concerned "difference in expectations", "output perceived as erroneous" and "flawless software and template coding (meaning: those managing the code won't change a thing)" may all be correct or incorrect (I don't care), but one thing should be crystal clear by now... not ready for Wikipedia's mainspace. Maybe those having the coding under their wings could take in the average content editors' expectations; maybe the content editors could speak about "something which I subjectively experience as an error" instead of flatout calling it an error etc.; but I propose to keep that mutual finetuning of the description of the issue out of Wikipedia mainspace: the next step, after the issue is understood exactly the same at all sides, could be some improvement in the coding, or change in the content of Wikidata items (what do I know what would work best), also kept out of mainspace, after which some experimentation and trials could take place, also out of mainspace, until everyone agrees "expectations" are met. --Francis Schonken (talk) 16:31, 27 September 2017 (UTC)[reply]
Just to note that I've tracked down the ifexist issue to a bug report filed in 2007(!) - see phab:T14019. This is a very long-running issue that is not directly related to this template (particularly with the trimmed code). Thanks. Mike Peel (talk) 00:35, 29 September 2017 (UTC)[reply]
@RexxS: Your example is not contrived. Andrei Beketov is a {{hndis}} page in Russian Wiki. Johannes Theodor Schmalhausen's doctoral advisor was Andrei Beketov [ru]. This sort of thing is as easy as pie to sort out if there's a proper redlink rather than a half-arsed link to Wikidata. Narky Blert (talk) 02:22, 30 September 2017 (UTC)[reply]
  • Conditional keep: Prohibit use in mainspace until there's a clear consensus to do so, which is unlikely to come until a few years of further development, policy synching, and dialogue. Agreed with the concerns of the nom, Fram, Doc James, Blueboar, et al. Also agreed with the underlying intent and the "I see the future" enthusiasm of Andy Mabbett, et al. But we're just not there yet. This template will be a useful tool for testing and experimentation, if constrained to testing. The data in WikiData isn't yet clean or protected enough, or easily editiable enough by trusted users, for mainspace use. See also related but more general thread at Wikipedia talk:Wikidata/2017 State of affairs#Wikidata and the English Wikipedia's stylistic integrity (and pretty much everything else at that page, and at previous discussions at WP:VPPOL, WP:VPTECH, WP:VPPRO, and WT:WIKIDATA, and etc., etc.). It's clear that WikiData is coming and will do some stuff for us. It's also clear that those working on it are far more enthusiastic about what it's capable of right now and are not getting how uneasy many of us are, how frequently it's breaking, and how much back-end work still needs to be done for a mainspace front end to be practical on this and other sites. Frankly, en.wp is not a place to experiment with in this way in mainspace. And it's isn't going to be until, when I see a mistake in a WD-provided citation (or other bit of content), I can edit the article, see that it's a WD thing with the error in it, click right on that, and go fix it, without any specialist knowledge of how WD works. Seamless pass-through. For security reasons, it's going to require logged-in, non-noob accounts to do that, though, in all probability; otherwise any vandal can change "1932" to "1923" at will and screw up a tremendous number of articles on multiple projects. It's like a remote detonator for a whole array of bombs. Just because something can technically be done doesn't mean we're going to agree that it should be, especially after people demonstrate why its causing problems.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:20, 27 September 2017 (UTC)[reply]
    • You're parrotting the anti-Wikidata rhetoric without any sense of what is true and what is propaganda.
    • The data in WikiData isn't yet clean - true; or protected enough - it's protected in the same way as here (by volunteers) and there's been a zero evidence adduced of problems that are produced here by vandals at Wikidata, so that's just repetition of the fact-free bluster typified by the "2017 State of affairs" - nobody is going to take that seriously. Your time would be better spent lobbying WMF for the technology to allow Wikidata editing from within Wikipedia, rather than moaning about its absence.
    • ... when I see a mistake in a WD-provided citation (or other bit of content), I can edit the article, see that it's a WD thing with the error in it, click right on that, and go fix it - One of the features built-in to many implementations of Wikidata imports is the "edit pen" or "Edit at Wikidata". Those provide exactly what you ask for - a direct link to the Wikidata article and the relevant section, where anyone who has edited Wikidata before will know exactly how to make the edit they want. Complaining about that is equivalent to complaining that an editor on Wikipedia has to learn how to type wikicode into an edit-box that they have to learn to find. Sure, there's a learning curve with any system, but I've seen no evidence that editing Wikidata is any more difficult than editing Wikipedia.
    • I'm one of the folks working on the ways that we can make use of Wikidata's resources in all the language Wikipedias, and I can assure you I'm more than intimately acquainted with not only "how uneasy many of us are", but also the downright Luddite hostility from some who are bitterly opposed to any technological advance. You think I don't see the problems with Wikidata at least as clearly as you do? Think again: I struggle on a daily basis with finding ways to make what is good on Wikidata available, while insulating us from the worse aspects.
    • any vandal can change "1932" to "1923" at will Why wouldn't a vandal just change 1932 to 1923 in their local Wikipedia? There are more vandalism edits made here than anywhere else, because we have more readers, and if the vandals move to Wikidata (why?) there's no immediate gratification of seeing their vandalism where they make it.
    • In May 2013, we had a very well attended RfC about using Wikidata in Wikipedia and consensus was reached that it was appropriate to make use of Wikidata in infoboxes with some caveats. I've spent a lot of my wiki-time in the following four years creating and refining ways of accomplishing that in order to ensure that the concerns expressed in Wikipedia:Requests for comment/Wikidata Phase 2 would be met, as well as fixing the issues raised at Wikipedia:Village pump (policy)/Archive 128 #RfC: Wikidata in infoboxes, opt-in or opt-out?. Whenever I've been asked to solve a problem in this area, I've done my best to meet the concerns of those raising them, but I have to ask whether it's been worth the effort. If you want to change the consensus from those RfCs, you know how to go about trying. --RexxS (talk) 21:02, 27 September 2017 (UTC)[reply]
      • RexxS, I'd like to comment on one of your points: I've seen no evidence that editing Wikidata is any more difficult than editing Wikipedia. I've no firm evidence to offer, but anecdotally I can tell you that despite decades of IT experience, and a good deal of knowledge of data design, I personally found learning to edit Wikidata much harder than learning to edit Wikipedia. Izno was kind enough to spent some time explaining Wikidata to me, and I eventually figured out how it works, I think. At that point I was enthusiastic about the idea of something like Cite_Q. It wasn't until I thought more about the implications of the steeper learning curve that I came down on the side of restricting Cite_Q to testing. If you could prove to me that most editors find Wikidata no harder to edit than Wikipedia, that would remove one of my main objections to Cite_Q. I suspect, however, that I'm the sort of editor who is likely to find Wikidata easier to use than most, so if I'm an outlier, it's probably in the wrong direction. Mike Christie (talk - contribs - library) 22:16, 27 September 2017 (UTC)[reply]
        • That's interesting, Mike. Of course, I can't point to rigourous research testing the point, but I can relate my experiences of introducing new editors to editing Wikidata, and seeing other trainers like Andy teaching established Wikipedia editors to edit Wikidata. I do remember finding dificulty the very first time I edited Wikidata, and I wonder if established Wikipedia editors find learning that particular skill by themselves more difficult than those who are guided initially? In answer to your request, I can't prove anything one way or another, but I would suggest that folks like yourself who are accustomed to Wikipedia and have technical skills might have artificially lowered expectations of the ease with which they expect to pick up new skills – I know I do – making the Wikidata learning experience seem harder than it in fact is. I'll see if I can find some resources that might modify the initial learning curve, but meanwhile have you seen Magnus' "Drag'n'drop Wikipedia references to Wikidata" video at https://www.youtube.com/watch?v=jP-qJIkjPf0 - those 22 seconds show off how easy some tasks can be in Wikidata once you're past the initial stage. Cheers --RexxS (talk) 22:54, 27 September 2017 (UTC)[reply]
          • RexxS: I hadn't seen that, and it's impressive. I don't know if this is the right forum to have this conversation, but my feeling is that the video doesn't really address the core difficulty that new editors will have. Here is my first ever edit to Wikipedia. Once I decided that word needed to be changed, I clicked "Edit" somewhere near it, and typed over the word. I didn't need to understand anything about links, or wikitext; what I could see in the article was text, and if I wanted to change text I clicked "Edit" and typed new text on top of it. All the other details came later, and there was no harm in that.
            Here, for contrast, is my first edit to Wikidata -- the prior edits were the result of the interface that was set up to encourage people to help do data input, so this edit is the first one done by going to Wikidata, finding the item I wanted to edit, and editing it. Looking at it now, it is taking me a while to figure out what I did: I added an ISBN to reference the claim that George Orwell was the author of Animal Farm. That ISBN is for the book I was citing. Clearly I didn't really see how to add a reference. Let's say I want to do something simpler -- I see, for example, that the publisher is listed as Harvill Secker, whereas I know the first edition imprint was actually Secker & Warburg. So I click the pen next to it -- that's straightforward. I start typing "Secker" over "Harvill Secker" and the completion list tells me that Harvill Secker is the same thing as Secker & Warburg, so I think maybe I should just add it as another publisher. After maybe five seconds I figure out I should probably click "add value", and I do that and type "Secker & Warburg". I see "add qualifier" and think "maybe I can say this was the first edition", but when I click it and type "first edition" it says "no match was found". So I give up.
            Not to belabour the point, but the difference is that to edit the Wikipedia article I didn't need to know what I was doing, and I could tell that I didn't need to know. When I tried editing the Wikidata article it was clear I *did* need to know. I would never have graduated to using {{cite journal}} if I'd had to understand what a template was on my first edit, and I wouldn't be a Wikipedia editor now. Sue Gardner used to say that fixing typos was the gateway drug to becoming a regular editor; there doesn't seem to be a gateway drug to Wikidata. Mike Christie (talk - contribs - library) 00:49, 28 September 2017 (UTC)[reply]
            • I'm with Mike Christie on this one. I've been experimenting with {{cite Q}} only to discover that creation of proper Wikidata reference objects requires creating a Q-item for the article, for the author, and potentially for the author's not-yet-included given name and surname. Or deciphering which, say, "Kenichi" the author's name actually is. (At the moment, all this name entry is no help in getting Cite Q to produce citations using surnames, anyway, but that should be fixed eventually.) Likewise, referencing a book not yet in Wikidata should entail creating two Q-items, for the work and the edition, and then finding Q-items for the author, place of publication, and publisher (most of the latter are single entities that have produced books under multiple names, so there must be an appropriate qualifier) etc. etc. In short, entering reference information on Wikidata is harder than properly creating a reference. And all of this is time-consuming and non-automatated (yes, I tried the Zotero-to-Wikidata QuickStatements script, also a non-novice move), and prone to errors, which I don't foresee an automated way to fix. Like Mike, I'm an experienced Wikipedia. Academic citations are part of my day job. I read the Chicago Manual of Style and refine EndNote and Zotero templates sometimes. I'm not the average user, and I'm on the verge of judging the whole Wikicite system as not worth my time until it's thoroughly automated (at least with VisualEditor style entry systems and real Zotero integration).--Carwil (talk) 17:49, 28 September 2017 (UTC)[reply]
              • "creation of proper Wikidata reference objects requires creating a Q-item for the article, for the author, and potentially for the author's not-yet-included given name and surname" No, it does not. "referencing a book not yet in Wikidata should entail creating two Q-items, for the work and the edition" Again, not so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:04, 28 September 2017 (UTC)[reply]
      • Regarding the infoboxes comparison (RexxS's last point): the situation is entirely different: infoboxes are optional (decided on a case-by-case basis whether one is included in an article or not), while, on the other hand, citations are the bread-and-butter of any article (per the WP:V policy). Infoboxes can be thrown out of any article where they don't work right, citations touch on the foundations of the Wikipedia system: their resilience has to comply to a higher standard, out of necessity. The RfCs on infobox/Wikidata combinations say nothing about citation/Wikidata combinations. Citation/Wikidata combinations should not be allowed in mainspace before an appropriate RfC is held that results in a consensus to allow them. {{Cite Q}} is not ready to go through such a RfC yet: too much work still needs to be done imho. It would probably be pure self-torture if embarking on an RfC about this too early. --Francis Schonken (talk) 07:16, 28 September 2017 (UTC)[reply]
        • False comparison: infoboxes are optional, and so is the use of Cite Q; no one is suggesting that the latter be mandated. Also, clearly, this TfD is being used as a pseudo-RfC by those seeking to prohibit the use of values from Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:24, 28 September 2017 (UTC)[reply]
          • Well, there is a difference: if the content of an infobox goes south one can remove it. No harm done (the presence or absence of an infobox is not an indication of an article's quality). If someone has placed a citation for WP:V reasons, and the content of this citation goes south, one can't just remove it (and with Cite Q in its present MO it may be a painstaking effort to recover its intended content). Thus, for references, something more sturdy is needed, fool-proof to a degree that its content changes show up as a content change for the article where the citation is used in recent changes lists, that obvious questionable changes to its content can be countered by anti-vandalism bots, that its expired external links can be detected and remedied by an archive bot (with a notification on the article talk page, that is of the article where the EL appears), etc.
          • Here's a thought: can the usage of {{Cite Q}} be limited to citations that are not used as references? I mean, "Further reading" lists or Bibliographies with entries that don't serve as a reference? Seems difficult to realise: above citation templates are mentioned that normally should be used "subst:"-only, and it seems impossible to manage that such provision is followed. Nonetheless this route may be considered for mainspace experimentation with the Cite Q template (if that is what the community thinks that should be done). --Francis Schonken (talk) 15:10, 28 September 2017 (UTC)[reply]
  • Comment — I've had it for now, changed my !vote above to *delete*, for the reasons indicated there. --Francis Schonken (talk) 20:17, 28 September 2017 (UTC)[reply]
  • Delete per Fram, JohnBlackburne, Doc James Blueboar and SlimVirgin. Wikidata is a deeply flawed project, and the connections between it and here are likely to end with a sub-standard product here. - SchroCat (talk) 11:25, 29 September 2017 (UTC)[reply]
  • Another example. Bagnoud Observatory uses the infobox observatory, which gets populated through Wikidata, and where the location uses the value from the Wikidata location fields (Saint-Luc, Canton of Valais, Switzerland), but the reference from the GRID, "GRID Release 2017-05-22, 22 May 2017, doi:10.6084/M9.FIGSHARE.5032286, Wikidata Q30141628". Well, actually, it doesn't use the actual identifier from the GRID, which is in this case this, but it uses the reference for the identifier, which is an URL found in another Wikidata item. That URL doesn't go to the GRID site, but to a share[13] where the GRID database is available for download. This is an extremely un-userfriendly and roundabout way to present a reference to an editor, and we can't simply change the reference either at the article or in Wikidata.
  • To make matters worse, the actual reference used (assuming you eventually found it) states that the Observatory is in Geneva, Geneva, Switzerland, not in Saint-Luc, Valois, Switzerland[14]. To be clear, the correct location is Saint-Luc, Valois[15]. Confusing, no? Fram (talk) 13:41, 29 September 2017 (UTC)[reply]
    • Couldn't find how that relates to the {{Cite Q}} template: I'd propose to limit the discussion here to that template (which is already complicated enough), and the only germane topic to this thread. --Francis Schonken (talk) 13:49, 29 September 2017 (UTC)[reply]
    • Anyway, I removed the infobox as it apparently caused problems, and contained information not covered in the body of the article. --Francis Schonken (talk) 14:06, 29 September 2017 (UTC)[reply]
      • CiteQ was built into the Infobox, and used to get the "reference", making it harder to know where and how to correct this (apart from, indeed , removing the infobox). You can see the exact same issue at Mount Stromlo Observatory or Mount Wilson Observatory, where the first reference has the telling "See Tfd" notice caused by template Cite Q. (The second example also starts with a redlinked file, caused by the fact that there are two images at Wikidata and the template can only deal with one. Another victory for Wikidata-based templates! Fram (talk) 14:21, 29 September 2017 (UTC)[reply]
  • Keep - Save ppl who want to experiment with it time. If deleted, sooner or later someone else will waste time building something similar. If there are problems, keeping it and fixing it will save others from reinventing the wheel with the same problems. If the concern is its use in the main space, put a note in the documentation that it's for experimenting and not to use in the main space instead of deleting it. Many very nice infoboxes now pulling from Wikidata, and there was probably plenty of opposition to those at first as well. Gtsulab (talk) 21:21, 29 September 2017 (UTC)[reply]
  • Not ready for mainspace and never for printed material. I can see the utility of a centralised citation database for things like web citations, particularly for archived references. User:Kusma makes a good point above, in reference to this diff which adds a bunch of weight to the article in the form of archived web links (this process is super common). A central storage for web cites would also make references to web pages significantly easier to update when the linked site's structure changes. However, I believe that references to printed material should only be substed and never transcluded. When I cite a book, I'm using a particular printing of that book with particular pagination, not necessarily the most recent version, most popular version, first edition, etc. That reference will never change no matter how many more printings the book goes through. If, as Kusma says, the "entire point of this template" is transclusion rather than substitution, it should not now nor in the future ever be used for printed material, even if it is technically possible to create Wikidata items for every edition, every volume of every edition, every page and chapter of every volume of every edition, etc. Snuge purveyor (talk) 17:01, 30 September 2017 (UTC)[reply]
  • Keep - there is nothing wrong or against policy with storing references in Wikidata and transcluding them into the articles, we have been doing exactly the same locally through data retrieval templates for ages.--eh bien mon prince (talk) 10:20, 1 October 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:Maratha Rulers Infobox 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 by Fastily (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) AnomieBOT⚡ 02:03, 23 September 2017 (UTC)[reply]

Unused template Zackmann08 (Talk to me/What I been doing) 02:49, 15 September 2017 (UTC)[reply]

  • Delete. Unused because the content is redundant to {{MarathaEmpire}}. Alsee (talk) 16:02, 15 September 2017 (UTC)[reply]
  • Delete per Alsee. Please note that a lot of Indian history articles dealing with the pre-Raj era tend to attract multiple sidebar templates, which actually makes the page pretty ugly. Where possible, as here with {{MarathaEmpire}}, a horizontal navbox at the bottom of the article is much, much the clearer, cleaner option. - Sitush (talk) 16:34, 15 September 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 LLWSQualifiers-Pre2001 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 September 23. Primefac (talk) 17:57, 23 September 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 carom billiards player 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 September 23. Primefac (talk) 17:56, 23 September 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 bbl season 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. Plastikspork ―Œ(talk) 13:24, 22 September 2017 (UTC)[reply]

Unused template Zackmann08 (Talk to me/What I been doing) 02:44, 15 September 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:NLP sidebar 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. Plastikspork ―Œ(talk) 13:23, 22 September 2017 (UTC)[reply]

unused template Zackmann08 (Talk to me/What I been doing) 02:38, 15 September 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_September_15&oldid=1142562383"