Help talk:Citation Style 1/Archive 41

Archive 35

←

Archive 39

Archive 40

Archive 41

Archive 42

Archive 43

→

Archive 45

TemplateData

Tracked in Phabricator
Task T101075

Continuing a conversation started at Wikipedia:VisualEditor/Feedback#Archiveurl, archivedate, deadurl fields have gone missing in the Cite web pop-up as it initially appeared to be change in the Visual Editor. @Risker, Salix alba, Jdforrester (WMF), and Xover:

The fields archiveurl, archivedate and deadurl are no longer appearing in the Cite web popup in the Visual Editor. As someone who uses the Visual Editor and pre-emptively archives URLs as I write citations, the loss of these fields is a major annoyance as it takes quite a number of clicks to add those fields back in using the Visual Editor. I have been told that the problem has been created by changes to the Template Data here for the the Cite Web Template. Could we please restore these parameters?

We have a tsunanmi of problems with dead link URLs and pre-emptive archiving is the easiest defence against it. And, while I am experimenting with IAB, I find that it often will not archive links that I can successfully archive myself with Internet Archive. Also IAB does rescuing (a service I don't need for what am doing) and there can be errors in this too, which I don't want to incur.

I write a lot of articles and I use a lot of citations. I use the VE because it more productive for content editing (less so for template work) so I will usually be in VE when I create citations. So significantly adding to the creation of a citation by requiring these three fields to individually added is a signficant time delay. Please change the Template Data back to include these fields by default. Thanks Kerry (talk) 04:57, 26 February 2018 (UTC)

As I wrote at WP:VE/Feedback, this is really an issue with the Visual Editor. It decides which parameters to display by default based on whether that parameter is marked as required or suggested in a template's TemplataData block; but then always inserts the parameters in the generated wikimarkup regardless of whether those parameters were used or not. To fix this, VE either needs to stop inserting suggested parameters in generated markup when they are empty, or it needs a new class of parameters that are "easy to access" but not included by default, or probably both. Or, of course, it could remember each user's favorite params and provide easy access to those, but I don't think VE's current architecture makes that feasible.

Note that right now it's editors who both use VE for new citations, use mainly web citations with {{cite web}}, and like to preemptively archive them (so |dead-url=, |archive-url=, and |archive-date= would get inserted, usually empty, into every single citation). But the problem is the same for any subset of editors with a preference for various fields. For instance, I most often use {{cite book}} and {{cite journal}}, and very often want |doi=, |hdl=, |via=, |ref=, |editor-last=, |editor-first=, |editor-link=, |author-link=, |chapter=, etc. Given the status quo, in order for me to get easy access to these, they would have to be set as suggested and would get inserted into the generated markup of every single citation both created with and edited with VE (VE adds them even when modifying an existing citation, not just when creating a new one). --Xover (talk) 06:35, 26 February 2018 (UTC)

User:Xover, you chose to be bold and make this change to the Template Data without discussion. When you were reverted (not by me), you ignored WP:BRD and reverted back to your version (i.e. edit warring). Please revert to the state before your bold change, then discuss please. The issue I raised is to do with cite web (you should raise your issue about cite book etc separately instead of using it as a distraction here). Citation URLs go dead very frequently, which impacts on key principles like WP:Verifiability which forms part of the five pillars. We are here to build an encyclopedia. You say your objection to their inclusion relates to Visual Editor including empty template fields when values are not supplied for these fields. If so, why aren't you having the conversation at Visual Editor Feedback instead of modifying the template data for one specific set of fields in this particular Template Data? Your objection to these empty fields appears to be that you don't like seeing them (despite there is no actual harm done by them) and they are not visible to the readers whom we serve. I cannot see how your dislike for them justifies working against the interests of people who want to make their web-based citations more persistent through the use of archive URLs. Kerry (talk) 07:21, 26 February 2018 (UTC)

@Kerry Raymond: I would appreciate it if you stop avoid personalising the discussion and casting aspersions. The mere fact of disagreeing with you does not ipso facto constitute edit warring, introducing vicarious arguments to distract from the main issue, not being here to build an encyclopedia, working against our readers, or refusing to get the point; all of which you accuse me of above. Please strike those parts of your message.

And just for the record, I changed the TemplateData back because the revert was made with an invalid rationale: a weak local consensus (made without all relevant information being available) elsewhere does not bear on if or how to change things here. This is fundamentally a problem with the Visual Editor, and should be addressed by changes to VE, but if a consensus forms here to make the parameters in question suggested in {{cite web}} I certainly won't object, and would be happy to make the necessary changes to the TemplateData.

Which, incidentally, means I would very much like the regulars on this page to chime in with their view (even the ones philosophically opposed to VE and TemplateData as currently implemented: broader discussion will contribute to a clearer and stronger consensus and avoid needless disagreements over similar issues in the future). --Xover (talk) 08:07, 26 February 2018 (UTC) [edited to correct clumsy phrasing. --Xover (talk) 10:24, 26 February 2018 (UTC)]

I think that this squabble is a good demonstration that template data, which simultaneously attempts to be "template documentation" (hah!) and a ve control mechanism, does neither well.

If I understand the issue here, Editor Xover's complaint is that "suggested": true in the template data causes ve to insert the associated parameter into the wiki source even when the editor does not provide a value for that parameter so that what source editors see after a ve edit is:

{{cite web |url=//example.com |title=Example |archive-url= |archive-date= |dead-url=}}

If this is the complaint, then I'm fully sympathetic because, to me, adding empty parameters that serve no function (because empty cs1|2 parameters convey no meaning) is just clutter in the wiki source that makes it harder to read.

However, if this is the complaint, this forum is not necessarily the best forum because editors here can do nothing to resolve the underlying problem. All that we can do is serve as a forum to decide if |archive-url=, |archive-date=, and |dead-url= should be marked "suggested": true in the template data. My !vote is no, they should not. Editor Kerry Raymond may diligently and laudably archive web sources but I expect that most others do not.

—Trappist the monk (talk) 11:59, 26 February 2018 (UTC)

• Hmm. Leaving a blank parameter is not a big deal; templates have been doing this for eternity, and in fact in many cases the removal of "suggested" parameters is considered poor form. I would not have an objection to removing the "dead-url" parameter, though, as it would be only very infrequently used when the references are being created. The entire point of "suggesting" the "archive-url;" and "archive-date" parameters is to encourage editors to consider immediate archiving of URLs, which is a good thing. Bots are nowhere as efficient as humans who do the archiving when they have the URL open, and can make the exact match. As I said, I'm okay with dropping the dead-url parameter from the suggested ones, but there is good reason to leave the other two.
  
  I am very disappointed to see an experienced editor completely ignoring BRD in order to press the advantage in this discussion, though. Risker (talk) 22:23, 26 February 2018 (UTC)

I've created a Phabricator task for this asking that the Visual Editor does not include template parameters which have no value specified.

I can see the two sides, its nice to have clean wikitext, its also nice that the UI encourages good behaviour. Of the two it seems like there is greater net benefit to the encylopedia if use of archive-url is encouraged. --Salix alba (talk): 22:45, 26 February 2018 (UTC)

I highly support removal of blank |archiveurl= and associated parameters for a couple reasons. 1. We have automated systems to deal with WP:link rot, namely IABot (accessible from the history tab "Fix dead links"), a sophisticated system currently in production with support from WMF and Interet Archive. 2. The scale is off the charts, 10s of millions of links on enwiki alone. In the first 15 years of Wikipedia only about 600k archives were added manually and by other bots. In the past 24 months of IABot running, this has increased to over 3 million with 2500-5000 new adds every day. User input is appreciated, but it makes little difference in the end. I would guess manual additions are 1/10th or less of what IABot is doing. And those manual adds are error prone. My bot WaybackMedic has removed or fixed 100s of thousands of bad archive links added by users and old bots. Manual input is appreciated, but we don't need to burden users with doing something that is automated. -- GreenC 00:40, 27 February 2018 (UTC)

@GreenC: Note that the issue of removing blank/empty params is strictly speaking a VE issue (i.e. belongs in the Phab Salix alba linked above and not here). The core issue here is: while VE behaves that way, should cite web's TemplateData mark these parameters as "suggested" leading to empty params being inserted in articles as a side effect; or should the parameters not be marked "suggested", causing inconvenience to those editors who frequently need them in VE's citation template editor. If VE is changed to no longer insert spurious empty parameters even if they are marked "suggested", then the issue here becomes moot. If you have an opinion on the cite web-related issue (including "Don't care", if that is the case), it would be helpful if you could indicate it to aid in determining consensus. --Xover (talk) 18:12, 27 February 2018 (UTC)

"suggested" should be no, to prevent blank entries for archiveurl/archivedate/deadurl. In terms of VE behavior, that's up to VE but it seems reasonable that the configuration is determined via the "suggested" mechanism so the community can decide easily and openly on-site. -- GreenC 18:55, 27 February 2018 (UTC)

Attempted summary (semi-arbitrary break)

Ok, since there appears to be no further editors chiming in, nor any ongoing discussion, I'm going to attempt to summarise. If you were pinged below, please verify and indicate whether I have accurately and fairly reflected your arguments. I've tried to be as neutral (and brief) as possible, but I can't preclude the possibility that I've messed it up (if so, I apologise and will correct as best I'm able). Note also that Risker has not edited since their initial post here and may thus currently be unable to participate (i.e. busy IRL), so please do not rely on my summary of their position until they have had a chance to verify it.

• Kerry Raymond is in favor of marking |dead-url=, |archive-url=, and |archive-date= as suggested in the TemplateData. They point to the inconvenience for editors of having to manually add the parameters under discussion to the Visual Editor's template editing dialog when using the Visual Editor to edit citations. They also point out the significant problem of dead links in citations and the consequent value of preemptive archiving, and that this makes WP:V an applicable policy. They do not consider empty parameters inserted in articles' wikicode to be a problem.
• Xover (me) is against marking them suggested because it causes VE to insert spurious and useless parameters into articles' wikicode, also for editors who do not routinely practice preemptive archiving. They (I) believe this is an issue that should be addressed in VE rather than in TemplateData. They (yes, I) also argue that leaving the parameters optional only negatively affects a relatively small number of editors, while setting them to be suggested would negatively affect both a relatively larger number of editors as well as all articles edited with VE in this manner.
• Trappist the monk is against marking them suggested, and argues that the current disagreement reflects the general problems with TemplateData as a system. They point to useless parameters being inserted into articles and the resultant clutter in articles' wikicode. They further argue that the underlying problem must be addressed in VE, and that leaving the parameters optional affects a relatively small number of editors.
• Risker is in favor of marking them suggested, considering the addition of empty parameters to be "no big deal". They also point out that including them by default has an educational effect by encouraging editors to include archives, and that manual addition by a human editor is more efficient and provides a better match between cited URL and archive than an equivalent bot addition. They also add that |dead-url= does not need to be marked suggested as it is relatively less frequently used.
• Salix alba sees both perspectives on the issue, pointing to clutter in the wikicode on one hand and user interface that encourages good behaviour on the other, but concludes that there will be "greater net benefit to the encylopedia if use of archive-url is encouraged".
• GreenC is against marking them suggested, pointing to clutter in wikimarkup. They further argue that manual addition of archives is both error prone and of relatively little utility given the scope of the link rot problem. They argue that the solution based on IABot and WaybackMedic (etc.) is both more efficient, with a lower error rate, and with less needless burden placed on human editors.

By my assessment this leaves us with no clear policy guidance for either option, and no numerical !vote advantage in either direction. I also see no ongoing discussions that might lead to a consensus, nor any sign that anyone is open to being persuaded by others' arguments. That is, I believe, the very definition of "no consensus".

In light of this, and of a request by one of the participants to that effect elsewhere, I am therefore going to self-revert the removal of the suggested properties for |dead-url=, |archive-url=, and |archive-date= until such time as we make some kind of progress toward a consensus, or until a possible future VE change makes the issue moot. --Xover (talk) 09:50, 3 March 2018 (UTC)

PS. Since several editors expressed various disappointments above, allow me to express one of my own: A willingness to discuss (not just !vote) and to be persuaded is pretty fundamental for a consensus-oriented project. If one merely focusses on one's own immediate goals and how to achieve them, then actual consensus will forever stay elusive. Or put another way, absent a willingness to both discuss and be persuaded, the process devolves to wikilawyering and exploiting (gaming) first-mover advantage and lack of consensus as a "de facto consensus". While actual consensus may always have been impossible to achieve in this specific case (there is genuine and valid disagreement on the issue), I had very much hoped the efforts to achieve it had been more vigorous and constructive. Oh well. --Xover (talk) 10:07, 3 March 2018 (UTC)

I think it is difficult to achieve consensus when we discuss the problem and the solution as a single issue. The root problem was the presence of unused parameters visible to source editor users, which is an issue of how VE renders source text and affects many templates. The proposed solution was to change just one template in a way that adversely affected VE users who were not leaving those particular fields empty. My objection was to the proposed solution. I have no objection to a solution that directly address the problem in the VE's rendering and I think your proposal of a new "type" of field might be such a solution. I suspect that the VE may be constrained to behave as it currently does because [1] appears to say that a template can interpret the absence of a field differently to the presence of that field without a value. If so, the VE should not suppress fields without values. I can't think of an example of a template that actually does behave differently in those circumstances, but templates would appear to be allowed to do so. If that possibility was to be ruled out (that is, a template should not behave differently in those circumstances), the VE could safely omit the fields without values. But I think the question has to be put to the VE developers. Kerry (talk) 06:38, 5 March 2018 (UTC)

@Kerry Raymond: Thanks for responding, and for your cogent analysis of the situation. Provided I've understood you correctly, we appear to be in agreement on both the underlying problem and the proper long term fix for it. And thus the only place we disagree is in the relative weighting of the downsides of the two possible status quos until a permanent fix is implemented. But in any case, since there is an absense of a consensus either way, the previous status quo (i.e. the one that coincides with your preference AIUI) stands until a consensus emerges. In the mean time, the Phabricator link at the top of the section is to a task tracking the request to the VE developers to address this. --Xover (talk) 08:48, 6 March 2018 (UTC)

Cite chapter number

There seems to be no convenient way within the Cite book template to cite a chapter that is only numbered. chapter=4 yields "4", which doesn't look like a chapter number, instead of Chapter 4. I'm adding the {{rp}} template, which is fine but less tidy. Clean Copy^talk 00:43, 6 March 2018 (UTC)

If {{rp|Chapter4}} works for you, why wouldn't this:

{{cite book |last1=Keneally |first1=Thomas |chapter=Chapter 4 |title=Abraham Lincoln: A Life |date=2002 |publisher=Penguin |isbn=978-0670031757}}

Keneally, Thomas (2002). "Chapter 4". Abraham Lincoln: A Life. Penguin. ISBN 978-0670031757.

—Trappist the monk (talk) 00:51, 6 March 2018 (UTC)

I am probably overly fussy, but the quotation marks annoy me. No citation style would use them for a chapter number. Clean Copy^talk 11:28, 6 March 2018 (UTC)

No citation style would use them for a chapter number. Can you show examples of chapter number handling from published style guides? I don't know that this particular topic has been raised before so if there are published style guides that show numerical chapter headings in a form distinct from alpha chapter headings then we might want to adopt a similar styling.

—Trappist the monk (talk) 19:09, 6 March 2018 (UTC)

The 6th edition of the Publication Manual of the American Psychological Association offers "(Shimamura, 1989, Chapter 3)" as an example of citing a specific chapter (p. 179). I don't have other style manuals at hand, but a citation generator (Zotero) gives "Aspray and Kitcher, History and Philosophy of Modern Mathematics, chap. 4." in Chicago style and "(Aspray and Kitcher, 1988, chap. 4) in Harvard style. I hope these are helpful. Clean Copy^talk 22:55, 7 March 2018 (UTC)

The book by Keneally is the work being cited, and the chapter is a specific location in that book, so |at= seems appropriate:

{{cite book |last1=Keneally |first1=Thomas |title=Abraham Lincoln: A Life |date=2002 |publisher=Penguin |isbn=978-0-670-03175-7 |at=Chapter 4}}

Keneally, Thomas (2002). Abraham Lincoln: A Life. Penguin. Chapter 4. ISBN 978-0-670-03175-7.

Kanguole 12:42, 6 March 2018 (UTC)

I agree; |at= is underused in my experience of citation templates. |contribution=, an alias of |chapter=, works best for titled contributions, including in edited publications.

The only problem with |at= is that although you can use an external link as the value, you can't then include an access date, because this is only accepted without an error when |url= or |contribution-url= are present. @Trappist the monk: I think |at-url= would be useful, which would then allow |access-date=. Peter coxhead (talk) 13:43, 6 March 2018 (UTC)

FWIW, |access-date= is not needed for a book. From the documentation: "Not required for linked documents that do not change. ... Access dates are not required for links to published research papers, published books, ...." – Jonesey95 (talk) 14:02, 6 March 2018 (UTC)

@Jonesey95: the documentation isn't quite complete, in my view. It's not only a question of whether the linked document will change, but whether the link will change. Research papers, chapters in published books, etc. that are available at the author's own web pages, or the web pages of the institutions at which they work, have a habit of disappearing. It's useful to know when the link worked when trying to recover an archived copy. It's different for a paper with a doi, for example. Peter coxhead (talk) 17:49, 6 March 2018 (UTC)

I'm not convinced that use of |at= is appropriate for a chapter title. In this example, the chapter 'title' is just a number (see 'chapter' 2) so we should render this chapter title just like we render chapter titles that are composed of words. The use of |chapter=Chapter 4 in my previous example is an editorial liberty taken for the benefit of those who are reading the rendered citation though I suppose that it could be omitted:

{{cite book |last1=Keneally |first1=Thomas |chapter=2 |title=Abraham Lincoln: A Life |chapter-url=https://books.google.com/books?id=E28G6JSPqz8C&pg=PT12 |date=2002 |publisher=Penguin |isbn=978-0670031757}}

Keneally, Thomas (2002). "2". Abraham Lincoln: A Life. Penguin. ISBN 978-0670031757.

And then there are the metadata issues:

|chapter=Chapter 4 → &rft.atitle=Chapter+4 + &rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DE28G6JSPqz8C%26pg%3DPT12

|at=Chapter 4 → &rft.pages=Chapter+4 (url is not available in the metadata)

—Trappist the monk (talk) 15:39, 6 March 2018 (UTC)

I would not consider "4" to be the title of the chapter; chapters may be numbered and titled, titled only, or numbered only. Here they are numbered but untitled. Clean Copy^talk 18:03, 6 March 2018 (UTC)

We use |chapter= when the work we are referencing is a separately-authored part of a book, but in this case the work is the whole book.

The same thing is seen with the metadata: the OpenURL genre for this source (to assist in finding it in libraries) should be book, not bookitem, so it should have rft.btitle, but not rft.atitle. Kanguole 17:11, 6 March 2018 (UTC)

It's not the only reason |contribution= is used; it's often desirable to link directly to part of an old scanned book with no OCR, for example, using |contribution= and |contribution-url=. Peter coxhead (talk) 17:49, 6 March 2018 (UTC)

I'm not clear on the point you are making here. |contribution= is an alias of |chapter= as long as |contributor= (aliases and enumerations) is not set.

—Trappist the monk (talk) 19:09, 6 March 2018 (UTC)

@Trappist the monk: I was making exactly the point you have below, namely that we don't only use |contribution= or its aliases when it is separately authored, but also when it's useful to specify |contribution-url= or its aliases. Peter coxhead (talk) 18:48, 7 March 2018 (UTC)

Not true. cs1|2 does not constrain the use of |chapter= to referencing ... separately-authored [parts] of a book.

—Trappist the monk (talk) 19:09, 6 March 2018 (UTC)

Short of a new parameter "Chapternumber", there seems no perfect solution. For my purposes, however the "at" parameter appears well-suited. Thank you all! Clean Copy^talk 18:03, 6 March 2018 (UTC)

For the purposes of the reader, "chapter" is an in-source location (the source being the book). Any info to identify this location uniquely and unambiguously would do. How much of such info you use is up to you I guess. A chapter with a unique title and number may be cited with either or both. A chapter without a title could be cited as "ch. [number]" (cf. "p. [number]" when citing a different type of in-source location). A chapter with a title but no number could use just the title. A chapter with neither could be cited as just "Chapter" as long as the pages containing it are also cited with |page=. Or it could be assigned a number depending on its order of appearance or proximity to a significant element in the source, as long as this is expressly stated (eg "chs. 3-5 [not numbered]", or "Chapter [follows map on p. 12]"). 108.182.15.90 (talk) 16:32, 7 March 2018 (UTC)

Inconsistency in linking title translations

In {{cite book}} (and anything else using the same underlying implementation), when an external link is added to the title of a book, the translation of the title remains unlinked. But when an external link is added to the title of a chapter, the link is also added to the translation of the chapter title. I'm not sure which of these two behaviors is preferable, but shouldn't this be made more consistent?

• {{cite book | title=Book title | trans-title=Translated book title | url=https://book.url | chapter=Chapter title | trans-chapter=Translated chapter title | chapter-url=https://chapter.url}}
• "Chapter title" [Translated chapter title]. Book title [Translated book title].

—David Eppstein (talk) 23:21, 10 March 2018 (UTC)

This conversation did not discuss |trans-chapter= so it did not get changed. Sandbox:

{{cite book/new |title=Title |trans-title=Trans title |url=http://example.com |chapter=Chapter |trans-chapter=Trans chapter |chapter-url=http://example.com}}

"Chapter" [Trans chapter]. Title [Trans title].

—Trappist the monk (talk) 00:14, 11 March 2018 (UTC)

format parameter in Cite AV Media

What does the |format= parameter in {{Cite AV media}} do? The documentation doesn't say (I could check talk page archives, but I didn't particularly feel like digging currently.) E to the Pi times i (talk | contribs) 22:11, 11 March 2018 (UTC)

Never mind, I just need to read more carefully. E to the Pi times i (talk | contribs) 22:15, 11 March 2018 (UTC)

Really?

—Trappist the monk (talk) 22:25, 11 March 2018 (UTC)

You know, one of these days edit conflicts will be correctly detected and reported.

—Trappist the monk (talk) 22:28, 11 March 2018 (UTC)

Manually inserted error categories

While working on Category:CS1 errors: ISBN, I came across the pages below that had no errors but had had the categories (ISBN and one other) manually added to the page. I don't know why that had been done but... once I deleted the manual insertions, the pages dropped out of Category:CS1 errors: ISBN. It strikes that if it happened on those three, it could have happened elsewhere. Are such manual insertions searchable and removable by a bot?

• The pages
  • Defence Act of 2000 (Sweden)
  • Defence Act of 1936 (Sweden)
  • Defence Act of 1925 (Sweden)

--Georgia Army Vet Contribs Talk 23:21, 11 March 2018 (UTC)

It might be reasonable to have a WP:DBR for all pages in a category tagged with {{Maintenance category}}. --Izno (talk) 23:35, 11 March 2018 (UTC)

I suspect that there aren't enough to worry about a bot fix. insource: searches should be adequate. For example this search.

—Trappist the monk (talk) 23:46, 11 March 2018 (UTC)