Help talk:Citation Style 1/Archive 29

If we cite books, the formatting makes a distinction between books with an editor and those with an author:

• Editor, Ann, ed. (2000). Edited book. {{cite book}}: |editor-last= has generic name (help)
• Author, Ann (2000). Monograph. {{cite book}}: |last= has generic name (help)

If no year is supplied, the formatting is

• Editor, Ann (ed.). Edited book. {{cite book}}: |editor-last= has generic name (help)
• Author, Ann. Monograph. {{cite book}}: |last= has generic name (help)

If we cite contributions within these books, using |chapter= for edited books and |contribution= for authored ones, the two are still formatted differently, but in a different (and less transparent) way than above:

• Contributor, A. (2000). "Chapter". In Editor, Ann (ed.). Edited book. pp. 1–23. {{cite book}}: |last= has generic name (help)
• Contributor, A. (2000). "Contribution". Monograph. By Author, Ann. pp. 1–23. {{cite book}}: |last= has generic name (help)

I propose that it would be more consistent, and clearer, to flag the difference by formatting the book part of the citation in the same way we do for the year-less book citations above:

• Contributor, A. (2000). "Chapter". In Editor, Ann (ed.). Edited book. {{cite book}}: |editor-last= has generic name (help) pp. 1–23.
• Contributor, A. (2000). "Contribution". In Author, Ann. Monograph. {{cite book}}: |last= has generic name (help) pp. 1–23.

(This is for {{cite book}}, but similar applies to {{citation}}.) Kanguole 18:09, 9 November 2016 (UTC)

The |contributor=–|contribution= pair is intended to work together to cite forewords, afterwords, introductions, etc that are included with another author's work. For example, citing something that Pynchon wrote in the foreword to Orwell's Nineteen eighty-four:

{{cite book |last=Pynchon |first=T. |contribution=Foreword |editor-first=G. |editor-last=Orwell |title=Nineteen eighty-four |pages=vii–xxvi |location=New York, NY |publisher=Penguin |year=2003 |isbn=978-0-452-28423-4}}

Pynchon, T. (2003). "Foreword". In Orwell, G. (ed.). Nineteen eighty-four. New York, NY: Penguin. pp. vii–xxvi. ISBN 978-0-452-28423-4.

The pair are not intended for use when citing a contribution to an edited collection of independent writings. I think that most of the discussions that created the |contributor=–|contribution= pair are in Help talk:Citation Style 1/Archive 9 and Help talk:Citation Style 1/Archive 10 (you were a participant in a couple of those: Foreword and citing contributed forewords, prefaces etc).

—Trappist the monk (talk) 18:56, 9 November 2016 (UTC)

I said above that I was referring to |contribution= in connection with authored works, not edited ones. It is used for forewords and the like, but also for guest chapters in authored books, e.g.

{{cite book |contribution=Appendix A: A Concise Introduction to Old Chinese Phonology |pages=543–576 |contributor-first=Zev J. |contributor-last=Handel |title=Handbook of Proto-Tibeto-Burman: System and Philosophy of Sino-Tibetan Reconstruction |first=James |last=Matisoff |location=Berkeley |publisher=University of California Press |year=2003 |isbn=978-0-520-09843-5 }}

• Handel, Zev J. (2003). "Appendix A: A Concise Introduction to Old Chinese Phonology". Handbook of Proto-Tibeto-Burman: System and Philosophy of Sino-Tibetan Reconstruction. By Matisoff, James. Berkeley: University of California Press. pp. 543–576. ISBN 978-0-520-09843-5.

If we cited Matisoff's book, it would be

{{cite book |title=Handbook of Proto-Tibeto-Burman: System and Philosophy of Sino-Tibetan Reconstruction |first=James |last=Matisoff |location=Berkeley |publisher=University of California Press |year=2003 |isbn=978-0-520-09843-5 }}

• Matisoff, James (2003). Handbook of Proto-Tibeto-Burman: System and Philosophy of Sino-Tibetan Reconstruction. Berkeley: University of California Press. ISBN 978-0-520-09843-5.

Sorry if using "Contributor, A." in the examples was confusing, but in both cases the item being cited is someone else's contribution to a larger work. Kanguole 20:48, 9 November 2016 (UTC)

The editor role added in edited books helps because the parameter displays in the same position as the author parameter. In the wording you are proposing, wouldn't the author role also need to be specified? A name there could mean anything. 72.43.99.138 (talk) 19:01, 9 November 2016 (UTC)

Btw the dependence of parentheses (around "ed.") on |date= is a long-standing inconsistency. 72.43.99.138 (talk) 19:10, 9 November 2016 (UTC)

The author role would be specified (with |first= and |last=). The issue here is how it's visually distinguished from an editor (specified |editor-first= and |editor-last=). I'm suggesting it be done by tagging editors with "ed.", rather than by presenting the elements of authored books in a different order. Kanguole 20:48, 9 November 2016 (UTC)

Isn't "in" vs. "by" a self-eplanatory distinction? 65.88.88.76 (talk) 23:56, 9 November 2016 (UTC)

Deleting "in", adding "by", and swapping the order of the title and names isn't a particularly intuitive indication. Kanguole 17:56, 10 November 2016 (UTC)

And here I was thinking that chapter and contribution were synonyms. Pray tell, for those of us creating citation templates automatically from bibtex files elsewhere on the net, how our software is supposed to dstinguish between these two different types of piece-of-a-book when that distinction is not present in the bibtex? Or, to put it another way: the more fine-grained you make the distinctions among these parameters, the more impossible-to-use-correctly this becomes. It was already impossible to use by hand (I am still getting the distinction between url and contribution-url wrong when I try it, some two years after the natural behavior that url= defaults to the finest-level titled subdivison of a citation was deliberately broken), and now not even machines can get it right. This distinction should be eliminated, and the (ed.) removed in all cases so that both types of piece-of-a-book are formatted reasonably. —David Eppstein (talk) 19:26, 9 November 2016 (UTC)

To clarify, I'm proposing that:

1. editors be marked with "ed." when we're citing an article in the book, as they would be if we were citing the book, i.e. that

   {{cite book |last=Bloggs |first=Fred |chapter=History of the Bloggs Family |editor-last=Doe |editor-first=John |title=Book |publisher=Book Publishers |date=2001 |pages=100–110 }}

   • Bloggs, Fred (2001). "History of the Bloggs Family". In Doe, John (ed.). Book. Book Publishers. pp. 100–110.

   should instead be rendered as

   • Bloggs, Fred (2000). "History of the Bloggs Family". In Doe, John (ed.). Book. Book Publishers. pp. 100–110.

2. the author and title of a book of which we're citing someone else's contribution be written in the same order as for any other authored book, i.e. that

   {{cite book |contributor-last=Bloggs |contributor-first=Fred |contribution=Testimonial |last=Doe |first=John |title=Book |publisher=Book Publishers |date=2003 |pages=1–10 }}

   • Bloggs, Fred (2003). "Testimonial". Book. By Doe, John. Book Publishers. pp. 1–10.

   should instead be rendered as

   • Bloggs, Fred (2003). "Testimonial". In Doe, John. Book. Book Publishers. pp. 1–10.

Kanguole 18:30, 10 November 2016 (UTC)

Better. Not averse to the proposal. 65.88.88.127 (talk) 22:21, 10 November 2016 (UTC)

Regarding proposal 1 above, I've come across several cases where people have manually added "(ed.)" or "(eds.)" to the last |editorn= field to get this in the displayed text. Kanguole 14:37, 21 November 2016 (UTC)

Other editors and I have converted |city= to |location= in a few hundred (or maybe a few thousand?) citations since the last update deprecated this parameter. I have done repeated insource searches and turned up nothing left, although insource searches are not always reliable. I propose to change this |city= parameter to unsupported in the next module update, which would move any stragglers from Category:Pages containing cite templates with deprecated parameters (where it could be hiding amidst 4,300 articles) to Category:Pages with citations using unsupported parameters (normally empty). I will be happy to perform any remaining cleanup once the change is made. – Jonesey95 (talk) 19:07, 21 November 2016 (UTC)

We should do the rest of the parameters that were part of the cite interview cleanup as well as clean the module's use of these parameters. --Izno (talk) 19:40, 21 November 2016 (UTC)

So, I've done this.

--Izno (talk) 01:22, 22 November 2016 (UTC)

When we have an incomplete {{cite arxiv}}, we display something like

A bot will complete this citation soon. Click here to jump the queue arXiv:1011.1234.

We should do the same when we have an incomplete {{cite journal}}

. doi:10.1234/0123456. {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help)

Ideally, both {{cite arxiv}}/{{cite journal}} and all other templates missing information should display something like

• arXiv:1011.1234. Missing or empty |title= (help, fix with Citation bot)
• doi:10.1234/0123456. Missing or empty |title= (help, fix with Citation bot)

Headbomb {talk / contribs / physics / books} 16:44, 7 November 2016 (UTC)

This seems like a good idea to me. – Jonesey95 (talk) 22:38, 7 November 2016 (UTC)

Ping @Trappist the monk: ?Headbomb {talk / contribs / physics / books} 15:59, 25 November 2016 (UTC)

I don't think that I have much of an opinion. Wouldn't this change involve more than |doi=? What to do when there are more than one of these identifier parameters? Mightn't this be a case for resurrecting {{cite doi}} in a different incarnation? If a bot can add parameter data then surely it can change the name of the template to {{cite journal}} at the same time. I don't think that adding the {{cite arxiv}} facility to all of the cs1|2 templates as you seem to have suggested is a good idea.

Do the bot operators/maintainers have an opinion? After all, they will need to support this suggestion.

—Trappist the monk (talk) 16:50, 25 November 2016 (UTC)

It's not a case to resurrect {{cite doi}}, it's a case to have users invoke the bot to help dealing with CS 1|2 templates which are throwing 'error' messages. The examples above are minimalist, but could equally apply to

• Smith, J. (2006). Journal of Stuff. 3 (4): 234. doi:10.1234/0123456. {{cite journal}}: Missing or empty |title= (help) (or any in Category:Pages with citations lacking titles)

or

• "Article of things". Journal of Stuff. 3 (4): 234. 2006. doi:10.1234/0123456. {{cite journal}}: |first1= missing |last1= (help) (or any in Category:CS1 errors: missing author or editor)

or

• Smith, J. (2006). "Article of things". Journal of Stuff. 3 (4): 234. {{cite journal}}: |doi-access= requires |doi= (help) (or any in Category:CS1 errors: param-access)

The bot won't fix everything, of course, but having that link will help to make a big dent in the ~40,000 article backlog where these are issues. No sure where the bot maintainers' opinion come into play, since the functionality is already provided for {{cite arxiv}} and that you can activate this bot on any article already, but I'll leave a notice on Citation bot's talk page. Headbomb {talk / contribs / physics / books} 17:12, 25 November 2016 (UTC)

Upon inspection, the bot should likely be only present in citations that the bot can actually work with. This means 1) {{cite book}} 2) {{cite journal}} 3) {{cite arxiv}} 4) {{cite conference}} 5) {{citation}} with isbns/identifiers. Headbomb {talk / contribs / physics / books} 17:27, 25 November 2016 (UTC)

I am trying to help out with the new implementation of ProveIt. This gadget has recently been rewritten and a new version was put in place a few days ago. This new version is driven by the TemplateData of the cite being used. Due to a current bug in Proveit (Phabricator Maniphest T148236), if an editor edits a page using ProveIt, and the cite that the editor is working on contains a parameter not listed in the Template data, then Proveit ignores the parameter and its data, and when saved the parameter AND ITS DATA ARE LOST!

To avoid this, I have been going through this monthly parameter usage report regarding TemplateData and parameters used in cite book. All of the parameters that seem valid that are not in TemplateData need to be added to TemplateData to avoid this data loss, at least until the ProveIt bug is fixed.

Having said all that, I want to make some points:

• cite book and the "issue" parameter: If I am reading the citation code correctly, there is a setting "templates_using_issue" that enumerates the templates that use "issue". cite book is not on the list. Therefore, it seems that for cite book, the parameter "issue" should be listed as deprecated. Regrettably, the parameter usage report says there are over 3200 pages that do use it.
• cite book and the "authors" parameter: I listed this as an alias of "last". I now see that that was my mistake. I was thrown by the fact that using both leads to an error. I will list "authors" separately as deprecated with notes and warnings that "lastn" to "firstn" are preferable and that the "authors" and "last" cannot be used together.
• cite book and *many* "lastn": The usage report shows that there are some usages of cite book with up to 48 authors! While this seems absurd, it also seems valid. To sync TemplateData with this situation, I see little alternative but to add all these parameters to the TemplateData. I do not like this since it will add about 120 seldom used parameters to TemplateData (40 entries (ten through forty nine) with three each (last, first and link)). If anyone has a better idea, I am all for it.

Thanks all for now. Thanks, John --Arg342 (talk) 13:24, 13 November 2016 (UTC)

The better idea is to get whomever it is at wmf to fix TemplateDate so that it understands enumerated parameters. I'm not holding my breath for that to ever happen. But, when you move on to {{cite journal}}, stand by, I have heard that there are citations out there with hundreds of authors (why we should ever list all of those authors escapes me). And then there are twenty-one more cs1 templates and {{citation}} so another obvious fix to TemplateData would be the ability to share and/or merge various instances of TemplateData. Not holding my breath for that either.

To address your other points:

Correct, |issue= is not supported by {{cite book}}. See the table at Help:Citation Style 1#Pages.

|authors= (plural) is not deprecated; do not list it as such – it should be, but that is a topic for another time.

—Trappist the monk (talk) 15:17, 13 November 2016 (UTC)

Hundreds of authors? Try 1000s doi:10.1103/PhysRevLett.105.252303, where the last 13 pages of an 18 page paper is author list and affiliations. Headbomb {talk / contribs / physics / books} 11:52, 16 November 2016 (UTC)

The last bullet is documented twice-over in Phabricator at phab:T139489 and phab:T54582--the latter seems to be a particular solution and the former is simply the problem definition. --Izno (talk) 15:38, 13 November 2016 (UTC)

|issue= is not deprecated for {{cite book}}; it is unsupported by that template. It should not be listed as deprecated. I've gotten yelled at too many times for editing the TemplateData programming code that is improperly stored in the template's documentation, and I don't use Visual Editor to be able to check it, so I'll let you make the edits.

That ProveIt behavior sounds like a nasty bug. I hope it gets fixed soon. – Jonesey95 (talk) 16:27, 13 November 2016 (UTC)

For both issues and authors, I have left them marked as deprecated. I turned on VisualEditor and looked at its behavior. For deprecated, it lists the parameter with a little exclamation icon and when you edit the property, you can see the property information. VisualEditor prefixes the deprecated instructions with "Field is deprecated." So to these two properties, I added "While not technically deprecated, " followed by suggestions. IMHO, this is a good compromise. It alerts editors to better alternatives, but does not block the usage.

As far as the authorn, editorn and translatorn with enumerated parameters, for now I will add the authorn parameters as I described as a short term fix, clumsy and nasty as it is.

I may chime in with ideas at VisualEditor as to better long term handling, but it is a fairly big issue. The JSON definition has to be changed, the JSON editor and documentation needs to be changed, then all the tools reading the JSON (VisualEditor and Proveit that I know of) need to be changed. Not trivial.Arg342 (talk) 10:13, 16 November 2016 (UTC)

I guess I disagree. I do not think that declaring a parameter deprecated by using the deprecated keyword and then 'overriding' that declaration with some text saying that the parameter is not deprecated is a good thing. Too many editors-with-little-experience use the ve tool, and will believe what the tool tells them as gospel truth. By saying that these parameters are both deprecated and not deprecated just causes confusion. Do not confuse the editors. The proper description for |issue= is 'not supported in cite book' and for |authors= is 'use of this parameter is discouraged, use ... instead.' I think that you should merge the deprecated keyword descriptions into their respective description keywords.

|authors= is a free-form parameter. There is no requirement that its content be 'comma separated'. If there were such a requirement, it should follow the standard cs1|2 name-list separator convention of semicolon-separation. ve should not suggest a requirement when there is none.

—Trappist the monk (talk) 11:42, 16 November 2016 (UTC)

Arg342, it appears that you are working around a bug in ProveIt by adding inaccurate statements to template documentation, compounding a problem instead of ameliorating it. |authors= is not deprecated; please remove that "deprecated" property from its documentation. |issue= is not supported in {{cite book}}; please do not describe it as deprecated. – Jonesey95 (talk) 16:10, 16 November 2016 (UTC)

As requested, I have removed deprecated from both.

|authors= now reads: List of authors, comma separated. Use of this parameter is discouraged, "lastn" to "firstn" are preferable. Warning: do not use if last or any of its aliases are used.

|issue= now reads: Issue number. This parameter is not supported by and should generally not be used with cite book. Consider that a different cite template may be more appropriate, such as cite magazine or cite journal. See Help:Citation_Style_1#Pages.

Sorry for all the noise on this. --Arg342 (talk) 23:59, 16 November 2016 (UTC)

Looks great. Thanks for engaging in good faith. – Jonesey95 (talk) 02:10, 17 November 2016 (UTC)

Last night, I overlooked the point about authors being free form, not comma separated. Sorry about that. I just fixed it.--Arg342 (talk) 11:34, 17 November 2016 (UTC)

I am pretty well done with cite book! By using the monthly usage report, combined with examining the code in the cs1 module code, I think the TemplateData is usable. Since the bug on ProveIt was fixed, I DID NOT add in all the author 10 to 49 entries; I think this can wait until TemplateData is redefined to accept the enumerated parameters.

There are two points I want to bring up. First, I did not exhaustively go through the code in the module to be sure I got everything; Instead I think I fixed everything in the wild as of the last report. Secondly, I am not sure I like the order of the parameters. If anyone wants to take that on, feel free. Thanks to all for your help and ideas! John --Arg342 (talk) 11:56, 26 November 2016 (UTC)

The {{cite interview}} template does not at present support |interviewer-first= and |interviewer-last= (including the usual bunch of first/last variants), only |interviewer=. Also, there can be more than one interviewer, so numbered parameters are needed as well. I think, both should be added for consistency. --Matthiaspaul (talk) 23:02, 24 November 2016 (UTC)

I think that I agree. I'll see what I can do to make this happen.

—Trappist the monk (talk) 16:17, 25 November 2016 (UTC)

When I hacked on cite interview prior to the last update, Trappist made this suggestion. I didn't feel strongly about implementing it because it's data that isn't added to the metadata and so it inevitably clutters up the edit window. *shrug* --Izno (talk) 15:31, 26 November 2016 (UTC)

|editor= and |translator= aren't supported by COinS but those parameters are enumerated and have accompanying -first, -last, -link, and -mask parameters. I see no reason to handle |interviewer= any differently and this may also allow us to get rid of |interviewers=.

—Trappist the monk (talk) 16:13, 26 November 2016 (UTC)

Added:

{{cite interview/new |title=Title |interviewer1=Interviewer One |interviewer2=Interviewer Two |interviewer-mask1=2 |interviewer-link2=Abraham Lincoln |interviewer-first3=First |interviewer3-last=Last}}

"Title" (Interview). Interviewed by ——; Interviewer Two; Last, First. {{cite interview}}: |interviewer1= has generic name (help)

{{cite interview/new |title=Title |interviewers=Interviewer One; Interviewer Two}}

"Title" (Interview). {{cite interview}}: Unknown parameter |interviewers= ignored (help)

—Trappist the monk (talk) 17:31, 26 November 2016 (UTC)

An edit to the {{cite book}} template data added |air-date= as an alias of |date=. That edit caused me to go look at the code. The current Module does in fact list |air-date= and |airdate= as aliases of |date= though I can think of no reason why this should be the case. The aliasing takes place in Module:Citation/CS1/Configuration but, in Module:Citation/CS1 these parameters aren't used except when the template is {{cite episode}} or {{cite serial}}. Probably an oversight on my part sometime in the past. I have removed the aliasing from Module:Citation/CS1/Configuration/sandbox:

—Trappist the monk (talk) 16:40, 25 November 2016 (UTC)

Good change. --Izno (talk) 15:32, 26 November 2016 (UTC)

Shouldn't that throw an error? Headbomb {talk / contribs / physics / books} 11:09, 27 November 2016 (UTC)

Probably not. We silently ignore |volume=, |issue=, |page=, among others in several of the cs1|2 templates. I don't see this as any different. We test for and announce ignored |chapter= aliases and crudely test {{cite arxiv}} for inappropriate parameters. In all other cases, I think, unused parameters are silently ignored.

The related question posed by Editor Jonesey95 has received relatively little comment which would seem to indicate that editors are comfortable with existing practice.

—Trappist the monk (talk) 12:54, 27 November 2016 (UTC)

What templates should be used when the source type does not match one of the templates provided? Examples:

• Laws, regulations, government notices.
• Organizational policy documents
• Standards

These are often, but by no means always, available as downloads in pdf or doc format, and sometimes only on paper. Sometimes they are published as part of a larger document, other times not. None of the available options seems to be universally applicable to any of the examples above. Any useful advice welcomed. Cheers, • • • Peter (Southwood) ^(talk): 15:20, 26 November 2016 (UTC)

There is nothing in cs1|2 requiring a cited source to be on-line.

cs1|2 doesn't directly support law citations. There are some template specifically designed for that. See Category:Law citation templates.

For policy docs and standards, there is {{cite report}} or perhaps {{cite techreport}}. More generally, {{citation}} can often serve quite well.

—Trappist the monk (talk) 16:04, 26 November 2016 (UTC)

I accept that cs1/2 do not require a cited source to be on line. I was mentioning the point that the source types may or may not be on line as an indication that cite web is inappropriate.

I was not aware of the existence of law citation templates. I will look them up as they may be suitable, assuming that using them is MOS and FA compatible with using cs1 elsewhere in the article.

I will also look into the other three templates you mention. If they provide the right output formatting they should work acceptably. Thanks, • • • Peter (Southwood) ^(talk): 03:24, 27 November 2016 (UTC)

Templates are not necessary, so asking what templates should be used is limiting. I assume that you want to use this style (CS1). If you can understand the help page (not a guaranteed endeavor) you will be able to apply the related style without a template. If you want to use a template, imo you have to use common sense and a bit of imagination. All these types of sources can be fairly accurately presented with existing templates and parameters. On the other hand, this is a general-purpose encyclopedia. If the source is as obtuse as the parent help page (and most policy documents, standards docs, and regulations are, or they assume expertise) the average Wikipedia reader will be at a loss to verify whatever it is the text is claiming. 65.88.88.126 (talk) 21:27, 26 November 2016 (UTC)

I made the not entirely unreasonable assumption that since this is the Help talk page for Citation style 1, that it would be assumed that I want to use Citation style 1 templates, so yes, your assumption is not misplaced. I am also aware that templates are not necessary. However, they are provided, and since they are provided I chose to use them on the premise that they would automatically format the citations consistently as is required for FA, thus (and here is where I made the rather optimistic assumption) saving time and effort - after all, why else would they exist? As to common sense and imagination, I miss your point. I would have thought one of the reasons for providing a set of specifically formatted templates would be to minimise the amount of common sense and imagination required, to help people use a system they are not familiar with to provide a uniform and consistent output. However, as this is Wikipedia, perhaps this was a bit optimistic. Furthermore, I would have thought my question implied that I expected there to be a way to present the specified sources using existing templates since I explicitly asked which ones to use. Your further comment is not only not obviously helpful, but incomprehensible in the context of my question. I wish to specify the sources correctly, sufficiently and consistently. Whether the average reader is able to use them effectively is an entirely different problem, and one which I did not bring up, as it has, to the best of my understanding, nothing whatsoever to do with the use of cs1 templates. Cheers, • • • Peter (Southwood) ^(talk): 03:24, 27 November 2016 (UTC)

Is there really any law, regulation, government notice, organizational policy document, or standard that may be encyclopedically pertinent in Wikipedia, that is not presented/discussed in another reliable, but more accessible source than the original? (free of the specialized jargon and expert knowledge) I assume, since you are in Wikipedia, that you contribute information so that the average person (meaning one without the requisite expert knowledge) will be able to understand. I think it can be safely stated that any expert source document that may have an impact on the average reader is probably already discussed in other, reliable, lay sources. So maybe is up to the contributor to search for such sources, that not coincidentally, do not need specialized citation templates. Because it would be a rare case if the subject the sources support is both notable per Wikipedia policy, and esoteric enough to have not attracted non-expert testimony. But let's say this is indeed such a case: does this rarity justify adding/changing the code? or it is easier to fit the existing, extensive, parameters/templates into an adequate, understandable, presentation? Or even easier, to just enter the citing info as best as you can present it? In other words, if the reader understand what is cited and why, and has an avenue to verify the claims in the article, who cares how you formatted the citation? Related to that, style is important, not just for consistency but for presentation (ease of understanding). But this talk page is mislabeled: instead of discussing the style, it discusses a non-obligatory application of it (the templates). Imo it shows clearly a waste of time and effort in frivolous and minor detail. I'm sorry, but this is yet another section about more of the same. 72.43.99.138 (talk) 15:48, 27 November 2016 (UTC)

Yes, several. More than 50 so far at a guess - from my personal experience. Yours may differ. Even if the relevant information is discussed adequately in some other reliable lay source (which in my experience is not often the case), that source may not be accessible, or I may not be aware of it. Why should I not use the original? It is available, reliable and authoritative. The encyclopaedia is supposed to be accessible to the average reader, that is not a requirement of the sources. The encyclopeadia should be as easy to edit as reasonably possible. that implies that logical and consistent tools should be available We the editors, are encouraged to cite references in consistent style. This would be easier with consistent tools. I accept that these are not always available, they are also a work in progress, but it is a goal to aim for. As regards the name of the page, it is the talk page for the template that presents the problem, so it is the place to discuss it. If you think you are wasting your time, feel free to stop doing so with my blessing. I do not foresee any profit from this discussion in any case. • • • Peter (Southwood) ^(talk): 20:17, 27 November 2016 (UTC)

I did not say you can't the use of the original, or even only the original expert source. You are as free as anyone to make verification of the article claims as forbidding, cryptic or inaccessible as you want to. But imo this encyclopedia needs to have everything accessible, including sources, because contributors and editors are not vetted, and have nothing to lose by doing the wrong thing. "Peter (Southwood)" can easily add misleading, inaccurate, or opinionated info while otherwise playing by the rules. Consistently. So can I. Did I, by chance get cought? Why, I can come right back as "Paul (Northwood)". Let others waste their time dealing with my subterfuge, but in the meantime, the articles I worked on have possibly misled. Also, the consistency of citations in general benefits readers mostly; editors must be consistent only per article, and they have several options. And if you look in the past iterations of this style, and into now, you will notice many, many inconsistencies in application. One reason (not the only one) is because too much attention is being given to downstream applications of the style (the different templates) and not to the style itself. Style by definition implies a willingness for consistency; but it does not necessarily imply comprehension or accessibility. 65.88.88.127 (talk) 21:20, 27 November 2016 (UTC)

How do we handle citing website mirrors, if we had occasion to do so? I expect we would use |website=original website’s name|publisher=mirrorer's name. Is this right? —67.14.236.50 (talk) 18:38, 27 November 2016 (UTC)

WP:SAYWHEREYOUGOTIT. I don't think that mirrors make any difference. Cite the source you consulted.

—Trappist the monk (talk) 18:45, 27 November 2016 (UTC)

@Trappist the monk: Well, the source would be the mirror, yes? I’m not sure what you mean. —67.14.236.50 (talk) 19:06, 27 November 2016 (UTC)

I mean the place that you found the fact that you are citing is the source that you cite. For example, we have an article Ahoskie (YTB-804). That article is mirrored at http://wikivisually.com/wiki/USS_Ahoskie_(YTB-804). Assume for the sake of the argument that these two articles meet the requirements of WP:RS. Now, suppose I learn that Ahoskie was stricken from the NVR on 10 October 1995 via the wikivisually.com mirror of Wikipedia. Because of WP:SAYWHEREYOUGOTIT, I cite wikivisually.com without mention of Wikipedia.

—Trappist the monk (talk) 19:48, 27 November 2016 (UTC)

That makes sense. But what if the mirror calls itself by the same name as the original and is otherwise indistinguishable except for the URL? —67.14.236.50 (talk) 20:29, 27 November 2016 (UTC)

I've handled that case in the past as if the mirror was a little-known web archive. That is, I put the original site in the main parameters like url and publisher, the URL for the mirror in archive-url, the date the mirror was captured in archive-date, and set |dead-url=yes. However, I did this because I actually relied on the original for my information, and only subsequently needed to use the mirror because the original was offline. If you actually got your information from this hypothetical mirror, I think you should cite the mirror. I would put the organization operating the mirror in publisher and the title of the mirror (which, in your hypothetical example, is the same as the title of the original website) in website. If for some reason it was important that the name of the organization that was the original publisher also be in the citation I would put the original publishing organization in publisher and the organization operating the mirror in the via parameter.

If you have a very complex situation you could do something like the following:

{{cite web |title=Original Article Title |date=2010-01-01 |website=Original Site Name |publisher=Original Organization |postscript=none}} — via mirror at {{cite web |url=http://example.com |title=Mirror Article Title |website=Mirror Name |publisher=Mirror Organization |access-date=2016-11-27}}

which produces:

"Original Article Title". Original Site Name. Original Organization. 2010-01-01 {{cite web}}: Missing or empty |url= (help) — via mirror at "Mirror Article Title". Mirror Name. Mirror Organization. Retrieved 2016-11-27.

—RP88 ^(talk) 21:54, 27 November 2016 (UTC)

In some of the vertical usage samples, like Cite web and Cite news, there are spaces around horizontal signs '|' and equal signs '=', which I think make the source more readable. In the latter case the equal signs are even neatly aligned, to make it even more readable. I suppose there is no difference in the actual rendering of the output, but I think it's good to write/use the source this way.

Is there a reason why the horizontal usage samples don't use the same style, with spaces? Otherwise I would like to see the samples change to that standard, which means the doc pages here, where one can copy it from. /PatrikN (talk) 16:13, 10 November 2016 (UTC)

I presume that you mean vertical sign ('|', the pipe symbol). No reason, and no requirement that parameters should be spaced in any particular way. | parameter =, |parameter =, | parameter=, |parameter= are all equally valid. The software that interprets the pipe, parameter-name, and assignment operator does so without regard to whitespace. Personal preference for Wikisource 'style' is merely personal preference. Of course the general rule for personal preferences is: do not change established style to fit your personal preference.

—Trappist the monk (talk) 17:05, 10 November 2016 (UTC)

Since the pipe character does not normally occur in text, a pipe immediately followed by a parameter name and/or an equal sign immediately following a parameter makes good search patterns, that's why I personally prefer the  |parameter=xyz style (in "own" articles). Regarding parameters with or without hyphens, I prefer the first ones because they are easier readable and wrap around more nicely even in narrow edit forms.

--Matthiaspaul (talk) 23:17, 27 November 2016 (UTC)

Since some while the cite templates throw an error message when the <pre>..</pre> stripmarkers occur in parameters. While this is necessary and fine for most other parameters, I think it is an error for the |quote= parameter, which's contents doesn't become part of the generated metadata AFAIK, where it is sometimes actually needed to format a quote in a reasonable way, and where freely flowing text is unacceptable (for example if |quote= contains a source code excerpt). --Matthiaspaul (talk) 00:39, 25 November 2016 (UTC)

Not inclined to do anything about this. If the quote is sufficiently complex as to require special formatting, then such quotes are best created outside the cs1|2 template and then cited appropriately. Additionally, such markup confuses MediaWiki's rendering of the <q>...</q> tags. The module uses those tags so that other-language wikis can set quote punctuation in their own common css. Note the extra quote marks which would be here regardless of the stripmarker detection and error message:

{{cite book |title=Title |quote=A quote with <pre>pre-formatted text</pre> renders with extraneous quote marks.}}

Title. A quote with

pre-formatted text

renders with extraneous quote marks. {{cite book}}: pre stripmarker in |quote= at position 14 (help)

—Trappist the monk (talk) 16:28, 25 November 2016 (UTC)

For illustration the citation in question was:

{{citation |title=CP/M 1.1 BDOS.PLM for Lawrence Livermore Laboratories |date=June 1975 |author-first=Gary |author-last=Kildall |quote=<pre> /* C P / M B A S I C I / O S Y S T E M (B I O S) COPYRIGHT (C) GARY A. KILDALL JUNE, 1975 */ [...] /* B A S I C D I S K O P E R A T I N G S Y S T E M (B D O S) COPYRIGHT (C) GARY A. KILDALL JUNE, 1975 */ </pre>}}

which renders as:

/* C P / M   B A S I C   I / O    S Y S T E M    (B I O S)
                    COPYRIGHT (C) GARY A. KILDALL
                             JUNE, 1975                   */
[...]
/*  B A S I C   D I S K    O P E R A T I N G   S Y S T E M  (B D O S)
                    COPYRIGHT (C) GARY A. KILDALL
                            JUNE, 1975                          */

{{citation}}: pre stripmarker in |quote= at position 1 (help)

Would a |pre-quote= parameter help the <q> issue? --Matthiaspaul (talk) 22:08, 27 November 2016 (UTC)

If I wanted to do this, I would use a note with a nested citation. Here is an example using your citation:

A statement about CP/M BDOS.{{refn|group=note|Excerpt from CP/M 1.1 BDOS.PLM:<ref>{{citation |title=CP/M 1.1 BDOS.PLM for Lawrence Livermore Laboratories |date=June 1975 |author-first=Gary |author-last=Kildall}}</ref><pre>
/* C P / M   B A S I C   I / O    S Y S T E M    (B I O S)
                    COPYRIGHT (C) GARY A. KILDALL
                             JUNE, 1975                   */
[...]
/*  B A S I C   D I S K    O P E R A T I N G   S Y S T E M  (B D O S)
                    COPYRIGHT (C) GARY A. KILDALL
                            JUNE, 1975                          */</pre>}} A subsequent statement.

====Notes====
{{reflist|group=note}}

====References====
{{reflist}}

—RP88 ^(talk) 23:37, 27 November 2016 (UTC)

Some journals specify both issue (relative number within volume) and number (apparently an absolute number). Our {{cite journal}} currently gives an error if both |issue= and |number= are specified at the same time. I suggest to remove the error message and display both if both are specified. Not sure if there is a standardized way to display this, but if not, something like "5 (1)/41" (for volume=5, issue=1, number=41) might do. --Matthiaspaul (talk) 23:29, 24 November 2016 (UTC)

I have never seen this in the wild. Real life examples?

—Trappist the monk (talk) 16:18, 25 November 2016 (UTC)

The one I ran into recently was:

{{cite journal |title=The history of CP/M - The evolution of an industry: One person's viewpoint |author-first=Gary |author-last=Kildall |journal=[[Dr. Dobb's Journal of Computer Calisthenics & Orthodontia]] |volume=5 |issue=1 |number=41 |date=January 1980 |pages=6-7}}

I have also seen this with older issues of a (German) photo magazine named "Minolta-Spiegel" - it happened over the course of several years in the 1980s, when they were transitioning from an absolute numbering scheme to a periodical with four issues per year.

--Matthiaspaul (talk) 14:06, 27 November 2016 (UTC)

Aeroplane Monthly (now known simply as Aeroplane) does it - as an example, the current (December 2016) edition is listed as Vol. 44, No 12, Issue no 524. I'm pretty certain Flight International used to do it as well, although it transitioned to volume and absolute number.Nigel Ish (talk) 16:09, 27 November 2016 (UTC)

A refined sanity check could be:

If |issue= and |number= are both given, at least one out of |volume=, |date= or |year= would have to be given as well (as companion for the relative issue). Since |issue= and |number= seem be used interchangeably, the one with the smaller value should become the relative issue number for the volume.

--Matthiaspaul (talk) 00:54, 28 November 2016 (UTC)

I wonder if anything can (or should) be done to isolate the unclosed italics in citations like this one:

Note that the |publisher= parameter has unclosed italics, making the access date italicized. I found this in the wild, in Hallelujah (Leonard Cohen song), and I've seen its ilk elsewhere. – Jonesey95 (talk) 06:23, 30 November 2016 (UTC)

Maybe we should just detect italics in any field that goes into the metadata and output a maintenance category? '' should never appear in those fields. I don't see a reason to "clean" these in the module. --Izno (talk) 12:57, 30 November 2016 (UTC)

Except that there are a few valid use cases where manual italics are appropriate. For example, if I were citing a newspaper article that contained the name of a TV program or a ship, something that would be rendered in italics, I'd need to add the appropriate coding. For example:

• Bellerose, Dan (March 15, 2005). "Group Claims Illegal Dive Made to Edmund Fitzgerald Site". Sault Star. pp. A1–A2.

In this case, the ship name is customarily rendered in italics under style guides like CMOS16, even in a title. Imzadi 1979 → 13:18, 30 November 2016 (UTC)

Right, and that's why I suggested a maintenance category rather than an error category. But I can think of a large number of cases where at least |publisher= is misused (for some reason) to add italic items. --Izno (talk) 14:10, 30 November 2016 (UTC)

The module does strip bold and italic wiki-markup from |title= and |chapter= values before those values are added to the metadata. It does not do the same for other parameters. In the exemplar case, |publisher= is not part of the metadata for periodicals so no harm is done except for the improper rendering. Is there any case where italic font is appropriate in |publisher= values? How about the negation of the automatic italic font in |work= values?

—Trappist the monk (talk) 13:57, 30 November 2016 (UTC)

Per the comment by Imzadi, it's plausible that there might be some work titled "A ship called USS Bird". Would I personally perform such a thing? Probably not. But some style guides (and probably ours if we poke a little) would allow for it. However, I can see very little reason to allow for italics in Publisher. --Izno (talk) 16:05, 30 November 2016 (UTC)

Should we agonize over every user error? The citation is not formatted correctly. Billboard is the source, not the publisher. The online version is apparently a separate entity, with several subdivisions. The current overall publisher is Prometheus Global Media (the billboard.com website is published by Billboard). Use {{cite magazine}}:

Mitchell Peters (October 22, 2016). "Pentatonix Cover Leonard Cohen's 'Hallelujah' in Moving Video". Billboard.com. Billboard. Retrieved November 29, 2016.

72.43.99.138 (talk) 15:27, 30 November 2016 (UTC)

No one above seems to have an opinion different from yours on the point. Did you actually read the full 'report' by Jonesey95? --Izno (talk) 16:02, 30 November 2016 (UTC)

Where? Instead of treating this as an avoidable use error with strictly cosmetic effects as far as readers are concerned, a discussion about machines and code takes place. Likely somebody saw a similar citation where something was auto-italicized and thought this was a user action, or misunderstood the positioning/meaning of "publisher" and "news" in the template, and manually added italics, or etc. There are a million ways CS1 can be misused. There is one page (the help page) that may proactively deal with the bulk and/or frequency of these errors, if done right. But anyway. If you have the time and inclination to add to the code, go for it. 72.43.99.138 (talk) 17:26, 30 November 2016 (UTC)

This discussion forked quickly. I have added headers to separate the discussion. If you want to discuss whether italics are valid in specific fields, I encourage you to start a new thread. My original question is about detecting and reducing the negative effects of unbalanced markup in parameter values. The same problem applies if someone forgets to close the clearly valid italics in |title= (italics "leak" from the title through to the end of the citation, including unitalicizing the |work= value):

Comments on the original question are still welcome. Thanks. – Jonesey95 (talk) 17:53, 30 November 2016 (UTC)

My original comment still stands (though perhaps more clearly): cleaning up after users (of incorrect wikitext) should not be the module's duty--but it should take care to let someone know that such users didn't get it quite right. --Izno (talk) 19:09, 30 November 2016 (UTC)

If we are going to take the trouble to identify and notify unbalanced markup in |title=, |chapter=, |publisher=, |work=, and perhaps others, then we might as well identify and notify when balanced or unbalanced markup is used where it should not be used. How we do the notification may be different depending on the parameter where the markup is detected. Balanced italic markup in |title= is acceptable so only notify for unbalanced; but in |publisher=, perhaps markup is not acceptable so notify whether balanced or not.

—Trappist the monk (talk) 00:46, 1 December 2016 (UTC)

Clarification added later: all my (pol098) suggestions are about added hidden comments, not actual reader-visible bot-affecting values for the author= and date= fields. The text being discussed is

End of clarification aded later.

This is rather a pedantic comment, but entering "author=<!--Staff writer(s); no by-line.-->" as recommended in the documentation for some templates with an "author" field actually is a statement of presumed fact which may be incorrect. It seems more appropriate to say "Not stated" or words to that effect, which is all we actually know. Not very important as it's only a hidden comment, and not particularly misleading at that, but if there's a place to be pedantic it's an encyclopaedia! [Entering a comment in this field is recommended to save future editors from needlessly looking for the author's name.] Best wishes, Pol098 (talk) 16:58, 21 November 2016 (UTC)

It's a recommendation, not an obligation. Likely carried over from news agency days. For this, I would just use the wording appropriate to the particular situation. But you do have a point, Imo. 64.134.101.234 (talk) 00:27, 22 November 2016 (UTC)

Of course, as I said it's a recommendation, and in a hidden comment too. But over the years I have found a fair number of "Staff writer(s); no by-line.", and never any other wording, so it seems to be taken as gospel. Unless I get any objections here, I'll consider editing the documentation. "Not stated" seems the best wording to me (again, only as a recommendation), unless anyone has a better suggestion. The same could be added to the "date=" field.

Going a bit further, the documentation uses the unambiguous wording If the cited source does not credit an author... use author=<!--Staff writer(s); no by-line.-->", and adds "this HTML comment alerts fact-checking and citation-fixing ... bots that the ... author credit wasn't accidentally omitted". This wording suggests that the wording I criticise is possibly required rather than recommended, and is built into bots, and shouldn't be changed? Or do bots simply check for anything or any comment in the author field, ignoring the precise wording? In any event, unless there's opinion to the contrary, I'll eventually make the change; it doesn't have big consequences and is easy to revert if necessary. Best wishes Pol098 (talk) 11:35, 22 November 2016 (UTC)

What is confusing about the comment to me is whether to add an author when "Staff" is the provided author. I've tended toward "yes, I'll add this, even though I know it doesn't really add much". I don't think those bots are still functioning, or if they are, it's unlikely they ever made note of the exacts of the comment. We should tend toward "whatever the source gives us", so in the case of no-listed-author, do indeed provide a comment to the effect of "no known author". I don't think it's a good idea to add "not stated" visibly, since that is, in fact, not the author. As for dates, you can add |date=n.d. and the module will accept it: Author (n.d.). "Title". {{cite news}}: |author= has generic name (help) vice Author (no date). "Title". {{cite news}}: |author= has generic name (help); Check date values in: |date= (help). I don't know what happens to the metadata there though. --Izno (talk) 12:48, 22 November 2016 (UTC)

"What is confusing about the comment to me is whether to add an author when "Staff" is the provided author." My suggestion is purely about a hidden comment to tell future editors not to bother to look for an author, none is identified in the source. If the author is known to be a staff writer, then that would be entered into the author field proper, visible to readers. I think the comment is better as "Not stated" than "no known author", again being pedantic - we might actually know the author, but it is not stated in the source. Have I made things clearer or added to the confusion? Best wishes Pol098 (talk) 18:47, 22 November 2016 (UTC)

Invalid dates get dumped into the COinS &rft.chron key/value pair so |date=no date ends up there. That may or may not be the correct thing to do. Likely, it's incorrect so perhaps there is a bit of code tweaking to do.

—Trappist the monk (talk) 14:01, 22 November 2016 (UTC)

I've always been discussing hidden comments, to save future editors from having to check; this wasn't entirely clear in the words I used. What I mean is to use |date=<!--Not stated-->. Would this upset the bots that seek invalid dates? Best wishes, Pol098 (talk) 18:47, 22 November 2016 (UTC)

To be honest, I always have difficulties remembering the exact phrase suggested to be put into this HTML comment when adding references without authors. In my opionion, the best solution would be if there would be special and easy to remember token value which could be given instead of a normal value. Bots searching for the comment could be easily updated to look for that token as well (and switch the citation to use that token when they run into it), but using a token instead of an invisible comment has the advantage that the citation template can react on it programmatically whereas a HTML comment is seen just as an empty parameter. So, the template could decide to display some special text (f.e. "Staff" for author parameters, or "no date" for dates), suppress the parameter, or add/remove the citation from some maintenance categories. As before, it could throw an error for mandantory parameters. Since the template is centrally maintained, we could always reconsider the necessary/wanted behaviour later on, so it is future-proof as well. Ideally, the chosen token for parameters without values should be the same for all parameters, it is just important to choose something which can be ruled out as normal value like "NOTGIVEN".

--Matthiaspaul (talk) 01:02, 25 November 2016 (UTC)

Help page edited: "staff writer"==>"Not stated", and wording trimmed.

Pol098 (talk) 14:53, 25 November 2016 (UTC)

The wording If the cited source does not credit an author, ... use: should be changed to If the cited source does not credit an author, ... you may use:. Hasn't it been stated already that this is only a recommendation? Wording that may be appear to be, or may be construed as, a guideline, should be avoided as far as this is concerned. 65.88.88.127 (talk) 21:46, 25 November 2016 (UTC)

Personally I support a recommended form of wording (a recommendation is a guideline, surely?). This would allow a bot to be developed if required (I understand there isn't one at present; I don't actually think one is needed, and I'm not sure that hidden text can be searched efficiently anyway), and a standard form of words just seems tidier. Pol098 (talk) 13:28, 28 November 2016 (UTC)

A guideline is not a command. Instead of surreptitiously putting a straightjacket on human editors (who may assume that they must, not may, do as you suggest), write a better robot. One that can understand a field populated only by comments. Please change the wording. 65.88.88.200 (talk) 15:20, 5 December 2016 (UTC)

I created this template some years ago as a quick citing template for a book. Since then there have been four supplements (so far) of additions and amendments published and I'm wondering how to amend the template to include simple supplement parameter so that {{Quick-Stations |page=FOO |supp=1}} would produce
Quick, Michael (2009) [2001]. Railway passenger stations in Great Britain: a chronology. Vol. 1st supplement (January 2011) (4th ed.). Oxford: Railway and Canal Historical Society. p. FOO. ISBN 978-0-901461-57-5. OCLC 612226077. {{cite book}}: Invalid |ref=harv (help)
The four supplements are Supp 1; January 2011, Supp 2; February 2012, Supp 3; February 2013, Supp 4; May 2014. if there are better ways of displaying all three dates within the output then even better. Thanks. Nthep (talk) 14:28, 8 December 2016 (UTC)

The four supplements are available at pdf documents so I would think that they should be cited separately from the book. Trying to combine them into the {{Quick-Stations}} template's base {{cite book}} seems a misuse of both templates. You might make {{Quick-Stations}} smart enough to do a {{cite web}} if |supp= is set.

—Trappist the monk (talk) 15:32, 8 December 2016 (UTC)

Notwithstanding Trappist's good advice, I did an experiment in the sandbox using the |volume= parameter of Cite book.

Quick, Michael (2009) [2001]. Railway passenger stations in Great Britain: a chronology. Vol. Supplement 1, January 2011 (4th ed.). Oxford: Railway and Canal Historical Society. pp. 7–14. ISBN 978-0-901461-57-5. OCLC 612226077.

Quick, Michael (2009) [2001]. Railway passenger stations in Great Britain: a chronology. Vol. Supplement 3, February 2013 (4th ed.). Oxford: Railway and Canal Historical Society. pp. 7–14. ISBN 978-0-901461-57-5. OCLC 612226077.

Quick, Michael (2009) [2001]. Railway passenger stations in Great Britain: a chronology (4th ed.). Oxford: Railway and Canal Historical Society. pp. 7–14. ISBN 978-0-901461-57-5. OCLC 612226077.

It seems to give the desired output, but after looking at it, I have to agree with Trappist that having three dates in the citation is unwise. You should cite the actual title, edition, and date of the publication you are looking at. – Jonesey95 (talk) 15:40, 8 December 2016 (UTC)

Page numbering in that solution may confuse readers – do the page numbers apply to the book or to the supplement?

—Trappist the monk (talk) 16:16, 8 December 2016 (UTC)

Page numbering is applicable to both the book and the supplements. Regarding the dates it's no problem to me to just show the supplement date and orig year but they are supplements to the 4th edition and not standalone publications hence trying to incorporate them into one template.

I guess I disagree. The supplements are stand-alone documents with their own dates and pagination. If I understand what you wrote, you are suggesting that the supplements' pagination mirrors the pagination of the book – that page 2, for example, in the supplement is a revision of page 2 in the book, etc. It is not clear to me that this is the case.

cs1|2 templates render one and only one in-source location so there is nothing to clearly indicate to the reader which of the two sources (book or supplement) the page number belongs. As the {{Quick-Stations}} template is now, |date= and |orig-year= are both consumed by the book citation. Squeezing in yet another date for the supplement is just confusing. The cs1|2 templates are designed to cite a single source; packing multiple sources into the templates is a misuse and should not be done.

—Trappist the monk (talk) 16:58, 8 December 2016 (UTC)

The pagination is for the supplement only and not a mirror of the same page in the book but they are only a list of amendments to the book and are not designed to be read as a separate book a the supplements lack the surrounding and supporting material. That said I appreciate the point about a single source so I'll rephrase the original question of how to use the short template{{Quick-Stations}} to select one of five sources by using a parameter in the template? Nthep (talk) 17:10, 8 December 2016 (UTC)

I'm confused. What is the short template?

—Trappist the monk (talk) 18:08, 8 December 2016 (UTC)

Nthep, have you looked at {{Quick-Stations/sandbox}}? It shows how to use a switch statement to choose which supplement information to display based on the value of |supp=.

I think you might need a template that displays one of five mostly different citations, based on whether you are citing the 4th edition itself or one of the supplements. I can help you with the code if you can design five different desired outputs in plain text. I suggest that we take this over to Template talk:Quick-Stations.

One other note: you are using |ref=harv for this template, but right now, the book or any supplement will be cited with the short reference "Quick 2009". This will be a problem. If you want to cite multiple supplements in the same article, this will be a problem to be worked around in the code. – Jonesey95 (talk) 18:16, 8 December 2016 (UTC)

Ok, let's continue at the talk page. Nthep (talk) 18:43, 8 December 2016 (UTC)

I've never asked for a new CS1|2 feature but hope we would consider adding |archiveurl2= and possibly |archiveurl3=, as secondary and tertiary archives (with |archivedate2= and 3). User:Cyberpower678 and myself have been doing work with Link rot bots, verifying links, adding links, deleting links etc... We work with the Director of the WaybackMachine at Internet Archive on technical issues, as well as the Community Tech team. There are some issues that have come up that could be solved with this feature in CS1|2.

As background, 90% of the archive links on en.wiki are to Wayback. Followed by WebCite maybe 5%, then Archive.is at perhaps 2% and various others the rest. There are dozens of other link archive sites List of Web archiving initiatives that could be used. Every web archive service has its own peculiar rules about keeping archives, dealing with take down requests etc.. none are permanent, in the sense that just because an archive link exists today, it might not tomorrow. And just because a link goes dead, doesn't mean it won't back alive in the future. It's similar to the problem with DNS where servers come and go so we have primary, secondary and tertiary servers.

For example Wayback will take down a page due to changes with robots.txt - however the page may come back alive later if the robots.txt changes. I've monitored thousands of these pages over time and discovered they sometimes flap on a daily basis, or weekly, or monthly etc.. or temporarily 1 time, or "permanently" down etc.. it runs the gambit. I originally was removing any link that was blocked by robots.txt but in retrospect this was a mistake as over time most of those links will probably become available again it it's useful to keep the link in place.

Adding a secondary/tertiary archiveurl opens new possibilities to solving the problem of flapping links. It also solves the problem if an archive site ever goes out of business. It also allows for using more obscure archive sites without fear of them going out of business. It gives editors the freedom to choose multiple archive sites if they want double or triple protection from link rot.

We have a new template {{webarchive}} which supports |url= .. |url10=. So we now have the ability to do multi-archive sites. This template has an option |format=addlarchives which will make a CS1|2 template look like it supports multiple archives, however this is something of a hack and not ideal, the best solution would be if CS1|2 natively supported it. If the feature is implemented in CS1|2 we can remove |format=addlarchives from {{webarchive}}.

I understand the downside of littering the template with lots of links, which is why the tertiary might be too much, but I don't have an opinion on tertiary either way. We can always add a tertiary later if there seems to be a need for it.

-- GreenC 15:11, 15 November 2016 (UTC)

Your work with {{webarchive}} is commendable, but imo a bigger priority in the templated application of CS1 as far as archives are concerned is not redundancy, but depth: the ability to drill-down to archive sections, add different pages in the same archive etc. Unless I have misunderstood your request, and what you are proposing would cover either, or both. 72.43.99.146 (talk) 15:41, 15 November 2016 (UTC)

|archiveurl2= is needed to fight WP:Link rot which is a priority for the community and Mediawiki Foundation per broad consensus. -- GreenC 17:07, 16 November 2016 (UTC)

Not disputing that at all. The point was that being able to plumb an archive for depth and breadth, and insert the result in the template, is probably imo more pertinent to citing sources. I don't disagree with your proposal, but there is also the visual aspect. An option to hide the secondary (or even also the primary) archive(s) from the reader until the original url dies? Something to work with/replace/enhance |dead-url= perhaps? 65.88.88.127 (talk) 19:26, 16 November 2016 (UTC)

One can't drill-down to archive sections because Wayback strips the part after the # from the URL. If you mean linking to the archive index it is already supported with Wayback using "*" in place of date. Multiple pages in an archive are currently supported in {{cite archive}} and the feature has been used by the community perhaps 20-30 times, there is little demand. The sole purpose of |archiveurl=/|archivedate= is to combat link rot, and the sole purpose of |archiveurl2= is to resolve problems with the current system. The problem of link rot has broad community consensus, and this feature request has broad application with (I believe) minimal disruption and complication to CS1|2. -- GreenC 20:19, 16 November 2016 (UTC)

The concern is about the visual clutter, that is why it was mentioned above if there might not be a way to hide the redundant archive info until such time as needed. One of the reason added pages/sections from the same archive are useful is because they may help in consolidating citations. Redundant archiving is a useful preventive measure, but link rot is not the issue. It is important for citation purposes only because it makes verification harder; but I am not sure that link rot is major concern of the wider community. {{cite web}} has 11 million transclusions, yet less than 7% of these (as of November 1st) included an archive. Despite the fact that preemptive archiving is relatively painless, and largely devoid of copyvio issues. Also despite the fact that the major step, ie making the effort to provide a citation in order to support a claim, had already been decided upon. 65.88.88.126 (talk) 22:30, 16 November 2016 (UTC)

I am not sure that link rot is major concern of the wider community Link rot was identified by the community as the number one concern during a recent survey 2015 Community Wishlist Survey, it received over 110 support votes which is more than any other in the survey. It received financial support by the Wikimedia Foundation in the form of programming support by Community Tech (paid staff). We already display multiple archives using {{webarchive}} using the |format= option, limiting it to 1 or 2 extra archives is not clutter. There is a bot IABot adding archives at the rate of 2000-3000 a day for the next 4 months or so as it traverses every article; but many are not dead (yet) so no archive or none available. Look, if this feature comes down to an RfC I feel confident the community will step up and support it. You are probably in the minority in not believing link rot is a priority. -- GreenC 14:48, 21 November 2016 (UTC)

And yet the numbers don't lie. In the most pertinent situation (cited web links) less than 10% of contributions bothered with archives. I don't think that this is the doing of a smaller "community". IAbot, like most Wikipedia bots in my experience, is buggy. Among other things, it "fixes" things that don't need fixing. Pre-emptive archiving is helpful, and is also advertised in several guide pages. And that's it. It is still not something urgent for most editors. If it was, you wouldn't be here discussing it. It's ok to have an option for additional archives. But the point of citations is to provide access to verification, not necessarily to deal with link rot. Will the added info bloat the citation? That is why it was suggested the archive be hidden. We will discuss the much more important aspect of archive reliabilty, stability, and security when the time comes. 64.134.100.212 (talk) 19:48, 10 December 2016 (UTC)

If there is a decision taken to support multiple archives, it will be necessary to enumerate:

|archive-urln=

|archive-daten=

|dead-urln= – needs a new name; all other |<thing>-url= parameters take a url as an argument

|archive-formatn=

Additionally, some determination regarding presentation should be made so that citations employing multiple archives don't blow-up to essay-length.

—Trappist the monk (talk) 15:42, 21 November 2016 (UTC)

We might also need an |archivern= parameter to allow us to display something like:

Archived from the original at WayBack Machine, Webcite

when we have multiple archive links being displayed. Imzadi 1979 → 16:30, 21 November 2016 (UTC)

Could do so, but the archive service can be retrieved the same way {{webarchive}}, by examining the domain name and keeping a map in the code ie. archive.org = "Wayback Machine", webcitation.org = "WebCite" etc.. -- GreenC 15:47, 26 November 2016 (UTC)

Trappist the monk, I found in writing {{webarchive}} that the simplest solution was the first archiveurl is un-numbered since that will be the case most of the time only one. It aliases to archiveurl1 to avoid confusion. There are corresponding archivedate's. Do we need multiple deadurl's since that is for the primary url, not the archiveurl(s)? Agreed need archive-formatn. Here is how {{webarchive}} renders with multiple archives:

{{webarchive |url=https://web.archive.org/web/20160101000000/http://example.com |date=January 1, 2016 |url2=http://www.webcitation.org/5eWaHRbn4?url=http://www.example.com |date2=February 12, 2009 |format=addlarchives }}

Additional archives: January 1, 2016, February 12, 2009.

When added to the end of a cite web:

""Example website"". March 1, 2000. Archived from the original on April 1, 2008. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help) Additional archives: January 1, 2016, February 12, 2009.

So the idea is remove {{webarchive}} in this case but produce the same output using CS1|2 alone. If there is a missing |archivedaten=, it displays the archive service name based on the domain name ie. archive.org = "Wayback Machine" etc.. -- GreenC 15:47, 26 November 2016 (UTC)

Yeah, you're right about |dead-url= (still needs to be renamed though).

I think that the rules for |archive-urln= and |archive-daten= must be the same as currently in use for the non-enumerated parameters. To have different rules for the enumerated version only serves to confuse editors; so no using archive domain name in place of a missing date.

cs1|2 allows only certain date formats. If we do not limit the number of additional archives (as we do not limit the number of authors or editors) then that may make date checking more of a pain. Also need to check for 'holes' in the list (we have 1 and 3 but are missing 2).

—Trappist the monk (talk) 13:24, 27 November 2016 (UTC)

Well I was thinking a secondary and possibly tertiary, otherwise it becomes clutter, the template shouldn't become a database of all possible web archives, rather a select few to prevent link rot. So a total of up to three? {{webarchive}} supports up to 10 currently because it also allows for archiving individual pages of a site but that requires different rendered text and is probably better served as a function of {{webarchive}} since it's rarely used. That's OK about not using the domain mapping for the missing date, the date should be required anyway. Regarding holes (1..3), I wrote a function for that in {{webarchive}} (parseExtraArgs()) it wasn't difficult though not sure how that method integrates with CS1|2. -- GreenC 16:03, 27 November 2016 (UTC)

What is the correct category for a subscription to a newspaper accessed through a local library?

Currently there are four categories under the "Subscription or registration required." There is not any wording to tell you how to designate a library subscription in a reference.

In many cities/towns/villages access to a local library and its resources is available over the Internet and in the library. These subscriptions are paid for with local tax dollars from their residents or by grants. You may be paying for the resource if you access the library through the Internet via your library card, but you might not be paying anything if you walk into the library (since most public libraries allow anyone to enter the building). Does this type of access fall under the "limited" or "subscription" category?

Whichever category this type of access is considered, to be consistent across all articles, should verbiage be placed on the Template:Cite news page stating which category library access falls into?

Possible wording:

• limited: there are other constraints (such as a cap on daily views) to freely access this source; this category includes access to library resources accessed via the web or in person
• subscription: the source is only accessible via a library or paid subscription

— Preceding unsigned comment added by Zcarstvnz (talk • contribs) 10:28, 15 December 2016 (UTC)

I would say that this goes in the subscription category, because a library subscription is a paid subscription (you don't pay, but your librarian did). − Pintoch (talk) 12:17, 15 December 2016 (UTC)

It depends on how the citation contributor accessed the source. If you just walk in a public library and handle the physical copy, there is no need to mention any access requirement. It is a different story if in order to access the source you must be a member of the library (many non-private libraries require membership for access to some resources, including physical or digital archives). That requirement is an obstacle to discovery, and should be noted. If it pertains to a library-owned archive/database/collection/rarity/whatever, the library and access requirement should be indicated (use |via= and the access-requirement param). If the resource in question is not library owned, indicate that resource, not the library, so that verifying users can skip a step on their way to the source. It is assumed that most readers know that they can get access to all kinds of materials through libraries. 72.43.99.146 (talk) 15:06, 15 December 2016 (UTC)

When I copy and paste a reference like

{{citation|title=On the Erdős–Szekeres convex polygon problem|first=Andrew|last=Suk|year=2016|arxiv=1604.08657}}

Suk, Andrew (2016), On the Erdős–Szekeres convex polygon problem, arXiv:1604.08657

(This is CS2 but I assume the same is true for CS1), selecting the whole line of text by triple-clicking it, and then I paste the result into a text editor, I get

Suk, Andrew (2016), On the Erdős–Szekeres convex polygon problem, arXiv:1604.08657Freely accessible

I don't want the "Freely accessible" to be part of the text, and it's formatted badly enough to likely lead to later errors in removing too many characters when deleting it and damaging the arXiv id. Can this garbage text that's not part of the actual reference be removed from what I copy, please? (I'm also not happy that when I do this to a footnote I get an added line "Jump up" at the end of the copied text but I doubt there's much to be done about that part here.) —David Eppstein (talk) 07:16, 18 December 2016 (UTC)

Fixing this particular issue may not be possible except we abandon lock icons as they are currently implemented. The 'Freely accessible' text that you are seeing is the image's alt text. For those who use screen readers, the image requires that we include |alt=<text> in the icon's File: link.

Here, I've tweaked the span that makes the link and icon so that alt text and title text are clearly identified:

<span class="plainlinks">12345<span style="margin-left:0.1em">[[File:Lock-green.svg|9px|link=|alt=alt text: Freely accessible|title text: Freely accessible]]</span></span>

12345 

triple-click copy and paste gives:

12345alt text: Freely accessible

I don't know what you mean by Jump up unless you mean the newline character (ASCII 0x0A). If that, then there is no solution in cs1|2 because that is not a function of the module. For me, on a windows browser, Ctrl+← once omits the newline; twice omits the newline and the 'Freely accessible' alt text.

—Trappist the monk (talk) 13:59, 18 December 2016 (UTC)

Don't you mean locks as conditionally implemented? Last I checked, the related RFCs were still open, and there was considerable opposition to implementing any locks whatsoever. 72.43.99.138 (talk) 15:08, 18 December 2016 (UTC)

No. Almost always I'm successful when I set out to write what I mean.

—Trappist the monk (talk) 15:55, 18 December 2016 (UTC)

??? Do you mean that if/when the RFC closes against locks, the locks are not going to be removed? What was the RFC for then. 72.43.99.138 (talk) 16:13, 18 December 2016 (UTC)

I have not written anything here about the RfC outcomes; that is not the topic of this discussion.

—Trappist the monk (talk) 16:51, 18 December 2016 (UTC)

If locks are overruled by the RFC consensus this discussion is moot, especially since the particular issue seems to lack consensus. This makes the present discussion tentative, at best. 64.134.242.89 (talk) 22:24, 18 December 2016 (UTC).

Maybe so. So what? I don't know what will happen because I suck at predicting the future. I answered the original question because when a question is asked, it deserves the courtesy of an answer. Can we be done?

—Trappist the monk (talk) 00:12, 19 December 2016 (UTC)

Agree. An initial response of "Sorry, I can't comment on that until the RfC closes" would not have been useful. Let's be done. ―Mandruss ☎ 00:19, 19 December 2016 (UTC)

Thanks Trappist for this distinction between title and alt. Wouldn't it be enough to change the lua code to render links with an empty alt and use title for the description instead? This seems to work:

<span class="plainlinks">12345<span style="margin-left:0.1em">[[File:Lock-green.svg|9px|link=|alt=|title text: Freely accessible]]</span></span>

12345 

Unless this violates accessibility, I think this would solve David Eppstein's issue. − Pintoch (talk) 17:12, 18 December 2016 (UTC)

Accessibility requires that the plain text version of our references be readable and usable. Concatenating this text onto the id without even a space violates that. If we have alt text at all, it should be how we want the reference formatted if we were to replace all of those locks by actual text. So replacing by |alt=" (freely accessible)" might be an improvement. (As for "Jump up", it's text added by ref/reflist somehow, so yes, not under our control. Sorry for not making that part more clear.) —David Eppstein (talk) 17:47, 18 December 2016 (UTC)

I totally agree - I did not mean that the current version was correct with regard to accessibility. We clearly overlooked your scenario in the original discussion. Thanks for bringing it up! − Pintoch (talk) 18:53, 18 December 2016 (UTC)

I think that the accessibility requirements (WP:ACCIM), while not policy, take precedence.

The sandbox version of the module uses Unicode character 'narrow no-break space' (U+202F /  )to separate the icon from the adjacent text:

'"`UNIQ--templatestyles-0000007F-QINU`"'<cite id="CITEREFSuk2016" class="citation cs2">Suk, Andrew (2016), ''On the Erdős–Szekeres convex polygon problem'', [[arXiv (identifier)|arXiv]]:<span class="id-lock-free" title="Freely accessible">[https://arxiv.org/abs/1604.08657 1604.08657]</span></cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=On+the+Erd%C5%91s%E2%80%93Szekeres+convex+polygon+problem&rft.date=2016&rft_id=info%3Aarxiv%2F1604.08657&rft.aulast=Suk&rft.aufirst=Andrew&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+29" class="Z3988"></span>

Suk, Andrew (2016), On the Erdős–Szekeres convex polygon problem, arXiv:1604.08657

Suk, Andrew (2016), On the Erdős–Szekeres convex polygon problem, arXiv:1604.08657 Freely accessible

The downside of using that character in lieu of the css 'nowrap' class (the live version of the module) is that of unknown browser support. Additionally, our use of the narrow no-break space is purely for presentation so is likely semantically incorrect. There always seem to be trade-offs. The discussion relating to the narrow no-break space character is here.

—Trappist the monk (talk) 19:13, 18 December 2016 (UTC)