Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite serial)
Jump to: navigation, search
          This page is of interest to the following WikiProjects:
Wikipedia Help Project (Rated B-class, High-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article B  This page does not require a rating on the project's quality scale.
 High  This page has been rated as High-importance on the project's importance scale.
WikiProject Academic Journals (Rated NA-class)
WikiProject icon This page is within the scope of WikiProject Academic Journals, a collaborative effort to improve the coverage of Academic Journals on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 NA  This page does not require a rating on the project's quality scale.
See WikiProject Academic Journals' writing guide for tips on how to improve this article.

Give a citation bot link when mandatory parameters are missing[edit]

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.  Missing or empty |title= (help)

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

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
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)

Formatting for contributed chapters[edit]

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. 
  • Author, Ann (2000). Monograph. 

If no year is supplied, the formatting is

  • Editor, Ann (ed.). Edited book. 
  • Author, Ann. Monograph. 

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. Edited book. pp. 1–23. 
  • Contributor, A. (2000). "Contribution". Monograph. By Author, Ann. pp. 1–23. 

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.  pp. 1–23.
  • Contributor, A. (2000). "Contribution". In Author, Ann. Monograph.  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. 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. (talk) 19:01, 9 November 2016 (UTC)
Btw the dependence of parentheses (around "ed.") on |date= is a long-standing inconsistency. (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? (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. 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. (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)

Spaces in usage samples to make source more readable[edit]

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)

|location=Cambridge [u.a.][edit]

I suppose that I should know the answer to this question but I do not. In |location=Cambridge [u.a.] what is the meaning and purpose of [u.a.]?

Trappist the monk (talk) 12:28, 13 November 2016 (UTC)

See previous discussion. Nikkimaria (talk) 15:49, 13 November 2016 (UTC)
Worldcat does this a lot, so some automated tool is probably copying the Worldcat location directly. See this entry, which says that it is an abbreviation for the German unter anderem (in English: "among other things"), and this StackExchange discussion, which says that "u.a." and "et al." have the same meaning. We should probably remove it, since it does not help the reader find the source. – Jonesey95 (talk) 16:36, 13 November 2016 (UTC)
Short answer: Yes. Long answer: The abbreviation "u.a." has two similar, but nevertheless distinguishable meanings in German, "unter anderem" ("among other things") and "und andere" ("and others"). The first meaning is very commonly used, whereas the second meaning has somewhat fallen into disuse over time and is much less frequently used today. Germans typically use the Latin phrase "et al." / "et alii" only for people, not for things, so it would be okay to replace "u.a." by "et al." in a list of authors, but for a list of locations, Germans would probably use either "usw." ("and so on") or "etc." ("et cetera") instead today.
--Matthiaspaul (talk)

New additions to cite book TemplateData[edit]

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)

Russian (Cyrillic) characters in url[edit]

The article Troitsky Administrative Okrug contains cites with links to http://троицкий-округ.рф/ - which is causing {{cite web}} to complain Check |url= value. Short of encoding the url in punycode (which produces the human-unfriendly http://xn----ftbnafed0afniox8a.xn--p1ai/) is there anything that can be done to suppress or fix the warning in this case? It seems the .рф TLD has been issuing Cyrillic domains since 2010, so we must have come across this issue before. -- Finlay McWalter··–·Talk 11:57, 15 November 2016 (UTC)

However, the punycode url is not seen by readers. And one could argue that all machine encodings (including FQDNs - pun intended) are human-unfriendly. (talk) 12:52, 15 November 2016 (UTC)
No, but they are seen by editors (Wikipedia is one of the few places where the format of URLs really impacts anyone but a handful of content creators - because we have so many content creators). And the less readable a URL is, the easier it is for someone to abuse it (by changing it to point to someone other than what the original author had intended). That's one of the reasons we don't allow URL shorteners. -- Finlay McWalter··–·Talk 13:05, 15 November 2016 (UTC)
The content creators in Wikipedia are a very small minority. There are far more editors than contributors. These in turn are dwarfed by the number of readers. I wonder if the required changes would pass a cost/benefit analysis. I can't even begin to think the kind of complexity that Scribunto for example, would have, if it was to be made as friendly to the small minority of programmers as your point is suggesting. Also, changes here are journaled: not only are they logged, but they are also reversible. Yet way too many things imo are restricted in order to make clerical functions (administration) easier. (talk) 15:27, 15 November 2016 (UTC)
I think that the only conversation that has been had about internationalized domain names is here. I suppose that at some future date, if there is sufficient need for it, Module:Citation/CS1 might be changed to support multi-byte Unicode domain names but I can imagine that that is not a simple task. For example, the code must make sure that domain names are composed of a single alphabet so that vandals can't insert urls that look to be 'lеgіtіmаtе' (lU+0435gU+0456tU+0456mU+0430tU+0435) but link to unsuitable hosts.
Trappist the monk (talk) 13:07, 15 November 2016 (UTC)
Yes, I can see that a solution is not a trivial task at all. Should we perhaps add to the documentation for the url parameter (perhaps at {{Cite web#URL}}) to say something like "urls with internationalized domain names will produce a Check |url= value warning; see here for a discussion" ? -- Finlay McWalter··–·Talk 13:23, 15 November 2016 (UTC)
Improved documentation is never bad. I think that referring to the archived discussion wouldn't be all that helpful. The documentation of this limitation should not be limited to {{cite web}} so the change should be made to Template:Citation Style documentation/url; should provide links to external puny encoders. The text might read:
URLs using non-Latin characters are not supported. These URLs must be converted to punycode. Online tools are available to internationalize URLs that are written in non-Latin scripts:
"IDN Conversion Tool". Verisign. 
"IDNA Conversion tool". 
Trappist the monk (talk) 13:44, 15 November 2016 (UTC)

Secondary and Tertiary archiveurl[edit]

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 are to Wayback. Followed by WebCite maybe 5%, then 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. (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? (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. (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)
If there is a decision taken to support multiple archives, it will be necessary to enumerate:
|dead-urln= – needs a new name; all other |<thing>-url= parameters take a url as an argument
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. = "Wayback Machine", = "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= |date=January 1, 2016 |url2= |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.  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. = "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)

Cite episode bug; missing parameters[edit]

{{Cite episode}}, which, according to its documentation "is used to create citations for television or radio programs and episodes", gives a red "Missing or empty |series=" warning when no |series= is provided.

For one-off programmes, the parameter is clearly not required.

I raised this last January, but nothing seems to have changed.

I've also previously requested the addition of |producer= and |writer= - could we have those, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 16 November 2016 (UTC)

It was Help talk:Citation Style 1/Archive 10#Cite episode - series.
Trappist the monk (talk) 16:32, 16 November 2016 (UTC)
Yes; that's what I meant to link to in my third paragraph (now fixed). When might this be fixed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:24, 20 November 2016 (UTC)

Flag issue= in Cite book as unsupported? And the more general question.[edit]

The discussion above reminds me of a long-standing question: should we flag |issue= as unsupported, placing it in the unsupported parameter category, when it is used in {{cite book}}? I guess the first question is: is it possible to do that in the module without a major rewrite?

The more general question: Should parameters that are valid in some CS1 templates (i.e. on the Whitelist) but not supported by specific CS1 templates:

1. be silently ignored (the status quo),
2. display a red error message and error category,
3. populate a maintenance category while displaying an optional error message in green,
4. populate an error category but show the error message only in Edit Preview mode, as is done with articles in Category:Pages using infobox mountain with unknown parameters and similar categories, or
5. something else?

To put my cards on the table: while it will be a pain to clean up, I think that silently discarding unsupported parameters is ultimately unhelpful to editors who are trying their best to use these complex templates. – Jonesey95 (talk) 16:17, 16 November 2016 (UTC)

I think my choice would be number 2 display a red error message and error category. This would show a reader of the encylopedia that the reference contains more possibly useful information. Some editor added the extra information; it may be of some use to a serious researcher, even if not displayed correctly due to a technical blunder on the part of the original editor. My second choice would be number 4 populate an error category but show the error message only in Edit Preview mode. This would let any editor know that there is an error that will require correction.--Arg342 (talk) 11:13, 17 November 2016 (UTC)
Please show error message to readers only when the errors impact verification. Otherwise, citations in general are cryptic enough for the average person. Secondly, "serious researchers" should know better: This is Wikipedia after all, where there is no formal mechanism for checking citations for completeness or accuracy. I doubt that incomplete or erroneous citations would escape the notice of such researchers for long. If they do, then some level of seriousness is lacking. (talk) 17:15, 18 November 2016 (UTC)

PDFlink template notice[edit]

There may be some CS1 script errors popping up over the next day or two related to {{PDFlink}}. The template is a wrapper for {{cite web}} and will be substituted/replaced shortly. These script errors should be temporary, as there are a few instances where the unsubst version has errors not found in the substituted template. Once the substitutions are complete, there should be few if any script errors, but please let me know (either here or on my talk page) so that I can finish cleaning this up. Cheers, Primefac (talk) 17:07, 16 November 2016 (UTC)

Some of the problems are showing up in Category:CS1 errors: URL–wikilink conflict. I just fixed about eight of them. They are typically templates inside of templates. Move the offending template outside of the {{PDF}} or {{PDFlink}} template, and a bot will do the rest. – Jonesey95 (talk) 22:29, 16 November 2016 (UTC)

Tool for identifying what articles are cited under the work field[edit]

Is there a way to do that? I'm interested in setting up categories to keep track of articles about sources used by Wikipedia. Is there a way to generate a pinging list for any articles linked in the work= or website= fields by the use of this template on articles? Ranze (talk) 08:06, 18 November 2016 (UTC)

No tool that I'm aware of. There is this which is a collection dependent on |journal= which is one of the |work= aliases.
Trappist the monk (talk) 13:20, 18 November 2016 (UTC)
Like Trappist said, there is WP:JCW for |journal=. It should be fairly straightforward to adapt User:JL-Bot to work on other parameters, but you'd have to contact the bot's owner for that. Headbomb {talk / contribs / physics / books} 13:23, 18 November 2016 (UTC)

author-linkn doesn't seem to work if n>10[edit]

See Platyceps najadum which has (Interwiki) links for authors 11 and 15 in the first ref. I determined through experimentation that the same links worked fine if I put them on an author #10 or below, but at their current, correct location, no links display. I also determined that the same symptom shows up for normal (not interwiki) links. --Floatjon (talk) 12:53, 18 November 2016 (UTC)

{{IUCN2014.2}} is not strictly a cs1 template but is a wrapper template for {{IUCN}} which is a wrapper template for {{cite web}}. This problem is not a failing of {{cite web}} but is a limitation of {{IUCN2014.2}} and {{IUCN}} which both only support |author-linkn= where 1 <= n <= 10. Rewriting the citation strictly as a {{cite web}} shows that |author-linkn= where n > 10 does work:
{{cite web |url= |vauthors=Lymberakis P, Ajtic R, Tok V, Ugurtas IH, Sevinç M, ((Crochet P-A)), Mousa Disi AM, Hraoui-Bloquet S, Sadek R, Haxhiu I, Böhme W, Agasyan A, Tuniyev B, Ananjeva N, Orlov N |author-link11=:de:Wolfgang Böhme (Zoologe)| author-link15=:fr:Nikolaï Orlov |date=2009 |title="Platyceps najadum" |work=IUCN Red List of Threatened Species |version=2014.2 |publisher=International Union for Conservation of Nature |access-date=2014-10-14}}
Lymberakis P, Ajtic R, Tok V, Ugurtas IH, Sevinç M, Crochet P-A, Mousa Disi AM, Hraoui-Bloquet S, Sadek R, Haxhiu I, Böhme W, Agasyan A, Tuniyev B, Ananjeva N, Orlov N (2009). ""Platyceps najadum"". IUCN Red List of Threatened Species. 2014.2. International Union for Conservation of Nature. Retrieved 2014-10-14. 
Trappist the monk (talk) 13:12, 18 November 2016 (UTC)
I think, were all of our CS1/2 derivatives to call the module directly (with any parameters as necessary) rather than the CS1/2 templates, these limitations wouldn't exist. I haven't looked at how modules play with template syntax though. I might go try over at {{cite video game}} since that's a pretty basic template. --Izno (talk) 14:23, 18 November 2016 (UTC)
That should work as long as the template uses parameter names supported by cs1|2. The IUCN templates use |assessor= in places of |author= so that reassignment still needs to be done by the IUCN template.
which still works, but has the same limitations that Editor Floatjon is complaining about. For {{cite video game}} something like this should work:
| title = {{{title|}}}
| author = {{{developer|}}}
| publisher = {{{publisher|}}}
| date = {{{date|}}}
| volume = {{{platform|}}}
| issue = {{#if:{{{version|}}}|v{{{version|}}}}}
| at = {{#if:{{{scene|}}}|Scene: {{{scene|}}}|}}{{#if:{{{level|}}}|{{#if:{{{scene|}}}|. }}Level/area: {{{level|}}}}}
| language = {{{language|}}}
| quote = {{{quote|}}}
Trappist the monk (talk) 14:56, 18 November 2016 (UTC)
Oh... I suppose they could write a small module that does what CS1/2 does with its enumerated parameters and then translate those into the equivalent assessors? --Izno (talk) 15:12, 18 November 2016 (UTC)

Change "author=Staff writer(s); no by-line." to "Not stated"[edit]

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. (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".  vice Author (no date). "Title".  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. (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)

Proposal: make city= unsupported in next module update[edit]

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.
Cite interview compare
{{ cite interview | city=City | title=Title }}
Live "Title" (Interview). City.  Cite uses deprecated parameter |city= (help)
Sandbox "Title" (Interview).  Unknown parameter |city= ignored (help)
Cite interview compare
{{ cite interview | callsign=Callsign | title=Title }}
Live "Title" (Interview). Callsign.  Cite uses deprecated parameter |callsign= (help)
Sandbox "Title" (Interview).  Unknown parameter |callsign= ignored (help)
Cite interview compare
{{ cite interview | program=Program | title=Title }}
Live "Title". Program (Interview).  Cite uses deprecated parameter |program= (help)
Sandbox "Title" (Interview).  Unknown parameter |program= ignored (help)
--Izno (talk) 01:22, 22 November 2016 (UTC)

Proposal: Support first/last parameters for interviewer in template cite interview[edit]

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)
{{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). Interview with ——; Interviewer Two; Last, First. 
{{cite interview/new |title=Title |interviewers=Interviewer One; Interviewer Two}}
"Title" (Interview). 
Trappist the monk (talk) 17:31, 26 November 2016 (UTC)

Cite journal causes error for journals with given issue and number numbers[edit]

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)

Stripmarker pre throws error also for quote parameter[edit]

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.  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:

Kildall, Gary (June 1975), CP/M 1.1 BDOS.PLM for Lawrence Livermore Laboratories,

/* 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 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:
Markup Renders as
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.



A statement about CP/M BDOS.[note 1] A subsequent statement.


  1. ^ Excerpt from CP/M 1.1 BDOS.PLM:[1]
    /* 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                          */


  1. ^ Kildall, Gary (June 1975), CP/M 1.1 BDOS.PLM for Lawrence Livermore Laboratories 
RP88 (talk) 23:37, 27 November 2016 (UTC)

|air-date= as alias of |date=[edit]

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:

Cite book compare
{{ cite book | airdate=2016 | title=Title }}
Live Title. 2016. 
Sandbox Title. 

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)

Source types not specified. Which templates should be used for other sources?[edit]

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. (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. (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. (talk) 21:20, 27 November 2016 (UTC)

Citing mirrors of websites[edit]

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? — (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. — (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 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 mirror of Wikipedia. Because of WP:SAYWHEREYOUGOTIT, I cite 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? — (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= |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  — via mirror at "Mirror Article Title". Mirror Name. Mirror Organization. Retrieved 2016-11-27. 
RP88 (talk) 21:54, 27 November 2016 (UTC)

Leaky italics[edit]

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

Cite news compare
{{ cite news | author=Mitchell Peters | publisher=''[[Billboard (magazine)|Billboard]] | title=Pentatonix Cover Leonard Cohen's 'Hallelujah' in Moving Video | access-date=November 29, 2016 | date=October 22, 2016 | url= }}
Live Mitchell Peters (October 22, 2016). "Pentatonix Cover Leonard Cohen's 'Hallelujah' in Moving Video". Billboard. Retrieved November 29, 2016. 
Sandbox Mitchell Peters (October 22, 2016). "Pentatonix Cover Leonard Cohen's 'Hallelujah' in Moving Video". Billboard. Retrieved November 29, 2016. 

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)

Are italics ever valid?[edit]

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 website is published by Billboard). Use {{cite magazine}}:
Mitchell Peters (October 22, 2016). "Pentatonix Cover Leonard Cohen's 'Hallelujah' in Moving Video". Billboard. Retrieved November 29, 2016. (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. (talk) 17:26, 30 November 2016 (UTC)

Back to the original question[edit]

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):

Cite news compare
{{ cite news | first=Dan | last=Bellerose | title=Group Claims Illegal Dive Made to ''Edmund Fitzgerald Site | newspaper=[[Sault Star]] | date=March 15, 2005 | pages=A1–A2 }}
Live Bellerose, Dan (March 15, 2005). "Group Claims Illegal Dive Made to Edmund Fitzgerald Site". Sault Star. pp. A1–A2. 
Sandbox Bellerose, Dan (March 15, 2005). "Group Claims Illegal Dive Made to Edmund Fitzgerald Site". Sault Star. pp. A1–A2. 

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)