Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite web)
Jump to: navigation, search
the 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.
 

Template:NewMusicBox[edit]

Resolved

Would anyone care to make {{NewMusicBox}} a wrapper for a suitable CS1 template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:56, 26 July 2016 (UTC)

Doesn't this question first belong on that template's talk page? Or, in lieu of that, a notice to the template's author about the conversation here?
Trappist the monk (talk) 09:59, 28 July 2016 (UTC)
No. It needs someone with an understanding (better than mine, or I would do it) of CS1. This is the place where such people congregate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 31 July 2016 (UTC)
@Pigsonthewing: I've made {{NewMusicBox/sandbox}}, which is a wrapper for {{Cite interview}}. Note that if this sandbox version is used, someone should go through the articles using this template and change the parameter |composer=[[Composer article|Composer]] (or |composer=[[Composer]]) to |composer=Composer|composer-link=Composer article - Evad37 [talk] 06:07, 1 August 2016 (UTC)
@Evad37: Thank you. I've asked for an AWB operator to assist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:43, 30 August 2016 (UTC)
All done, now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 20 September 2016 (UTC)

Wadewitz memorial proposal[edit]

Recently a discussion at Talk:Jane Austen has revolved around the linchpin issue of template formatting. The original version of the article from 10 years had initially been started in MLA Handbook format (without templates, see below) by the late Wadewitz, and it was clearly her strong desire (as evidenced by her comment in the references section) that that MLA format be retained. However, a regrettable situation arose: since Wadewitz passed away, 5-6 editors have edited the article in different cite formats (or even "freestyle format", perhaps). Manual editing resulted in a massively inconsistent references section that I described as a "steaming mess of wrongness".

I strongly support the use of reference templates to create consistency in formatting within any given article, and to provide the many benefits of COinS.

However, neither of these advantages is available to any editors who wish to edit in MLA (or APA, or Chicago/Turabian, or Bluebook) as expressly supported under WP:CITEVAR.

WP:CITEVAR does not by extension mean that such template options must be created, but I suggest that the proper way to show courtesy and respect to all editors working within those extremely common (outside of Wikipedia) formats would be to create them. The reason these formats are rare in Wikipedia is precisely because template options for them are completely unavailable. If these template options had existed before, the "steaming mess of wrongness" at Jane Austen would never have come to be.

If possible, I propose (perhaps using |mode=) the creation of |style-guide=mla, |style-guide=apa, |style-guide=chicago and |style-guide=bluebook as alternate parameters that reformat displayed template text.   Lingzhi ♦ (talk) 09:33, 23 August 2016 (UTC)

The reason why MLA style is not suited to use in Wikipedia has been explained at length, by user:RexxS, in the discussion at Talk:Jane Austen; not least - in great detail - in Talk:Jane_Austen#MLA. Attempting to bypass that discussion here, and framing it in such a way as to imply that anyone opposing your proposal is both disrespecting other editors and disrespecting the memory of a much missed former colleague, is facile, and in the latter case is an abuse of her memory. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:44, 23 August 2016 (UTC)
@Lingzhi: Rather than wade through that lengthy talk page, I'd rather refer anyone to the essay presently at User:RexxS/NoCiteBar, where I've tried to collect my thoughts and explore the issues related to MLA-type and similar referencing schemes. That does rather damn MLA-type short cites as inadequate for our needs. If it's any consolation, I have been in the process of working through Module:Citation/CS1, with a view to creating a version that allowed a parameter to act as a switch for the displayed output. That, of course, would only affect the long citations, and would do nothing to fix the fundamental problems with MLA-type short citations. When I can get an uninterrupted stretch of time to do some programming (hint, hint), I'd hope to have something sandboxed that might go some way to meeting your request. Any pointers to definitive on-line references for the different styles, MLA, APA, Chicago, etc. would be appreciated. --RexxS (talk) 12:05, 23 August 2016 (UTC)
I think that having an MLA style option for the CS1 {{cite xxx}} templates is a good idea. It would allow editors to make use of the error checking that is available in CS1 templates but still format full citations in their discipline's preferred format. (As Andy says above, MLA style, e.g. "Smith, 101", is unsuitable for Wikipedia, where anyone can edit an article and easily introduce ambiguity. We would have to adopt a modified MLA style for short footnotes, e.g. "Smith 2005a, 101", linked to the full citation.) – Jonesey95 (talk) 13:23, 23 August 2016 (UTC)
I think a |mod=MLA wouldn't be a bad idea for full citations, but the existing {{harvnb}} templates should be be used for any short even though MLA itself doesn't call for the inclusion of the year there. Other mode options could be added in the future for other styles. Imzadi 1979  20:02, 23 August 2016 (UTC)
  • We need short form MLA templates (and APA, and Chicago, and...) similar to sfn etc. Why oh why oh why do I have to come here and beg? Why do I have to kiss the ring of a small group of editors? Give me permission to edit templates, show me how you've implemented things in the years since I last edited a template, and I'll do it. This is nothing but flat WP:OWNership, and that's a fact.  Lingzhi ♦ (talk) 04:19, 24 August 2016 (UTC)
    A good way to get me to abandon this mla project is for you to continue to make unsupported accusations of WP:OWNership and the like:
    • Cite Book is a wikipedia-only standard that is in practice shoved down everyone's throats because the template maintainers flatly refuse to make MLA and APA templates. (you wrote that here)
    • I DO think that the template maintainers of cite book are massively remiss for flatly refusing to produce MLA, APA and Chicago flavors of cite book; they have an untouchable cast-iron WP:OWN on the issue, in flagrant violation of policy at WP:OWN. (you wrote that here)
    Show me where template maintainers or the maintainers of {{cite book}} have refused to make MLA and APA templates.
    Trappist the monk (talk) 12:18, 24 August 2016 (UTC)
    @Trappist the monk: I admit to having become consistently embittered against those who maintain templates... I've been around Wikipedia off and on (with a nearly three year "off" period) for ten years. I have come to various template-related forums asking for various things, and have always been shown the door... even when I asked nicely (I ceased being so nice after a while). I don't recall when I asked last (either as User:Ling.Nut or User:Ling.Nut3) for these particular APA/MLA/Chicago template alterations, or what specific template-related forum I asked on, but I do recall asking for them, and I do recall being treated like an intruding idiot, to put it nicely. So my attitude is embittered, but it is a response to past arrogance. I do not recall the usernames of all of those who were rude in the past, but I am quite certain that you were not one of them. I do recall one user (still quite active) who treated me rudely in the dim past, but I will not repeat that username in this particular moment. So. Is this a non-apology apology? I'm not sure. But it is perhaps true that nicer people are around now than I have dealt with in the past, and if I have unfairly tossed you and others here into the bucket with the relatively unreasonable ones, then I do apologize for that. But having said that, I still feel bitter. So it's a bit of a dilemma. :/  Lingzhi ♦ (talk) 14:51, 24 August 2016 (UTC)
    Perhaps you are mis-remembering. I can find no discussions on template-related talk pages (the Template:, Module:, and Help: namespaces) where any of User:Lingzhi, User:Ling.Nut, or User:Ling.Nut3 asked for templates to write references in a style other than cs1|2. I did not look at user talk pages because those are not generally public venues and did not look into article or other namespace talk pages because those are clearly not template-related fora so perhaps you asked in one of those places. I am interested in knowing the reasons that were given when requests for alternate styles were denied.
    Trappist the monk (talk) 16:14, 24 August 2016 (UTC)

(undent) I also spent 10 or 15 minutes looking for that incident and have not found it yet either. I will continue looking. Meanwhile, I am in the present case obviously in the wrong, though (in my opinion) somewhat humanly so. But still in the wrong.  Lingzhi ♦ (talk) 02:35, 25 August 2016 (UTC)

  • You don't need any special permission to create a new template or to edit a template's sandbox code. Go for it! And all template code is available via the Edit or View Source links at the top of the page. You might start at Module:Footnotes. – Jonesey95 (talk) 05:17, 24 August 2016 (UTC)
    @Lingzhi: Let's assume that you have a ref like <ref>Smith, 101</ref> and you want that linking to a long-form cite template. There are two things to do here, and neither of them is restricted by the edit protection on the templates.
    The first thing to do is to make a link inside that ref, this could be as simple as <ref>[[#Smith|Smith]], 101</ref> but as there may be a section in the article titled "Smith" it's a good idea to add something distinguishing, such as the letters "ref" - so you might use <ref>[[#refSmith|Smith]], 101</ref>.
    The second thing to do is to create an anchor on the long-form citation template, this might be {{citation}}, {{cite book}} or one of the others. Use the |ref= parameter for that, i.e. |ref=refSmith.
    You can see it in action at Wikipedia:Sandbox. You could make a template for the [[#refSmith|Smith]] part, but it's not essential. --Redrose64 (talk) 10:12, 24 August 2016 (UTC)
    @Lingzhi: Further to the above: I've found that you can in fact do it using existing templates, see Wikipedia:Sandbox. Here, we have <ref>{{harvnb|Smith|loc=101}}</ref> in the text, and |ref={{harvid|Smith}} in the cite template. The two templates used here are {{harvnb}} and {{harvid}}; notice that I didn't use the year parameter on either one, and with {{harvnb}} I used |loc= instead of |p= in order to suppress the "p." that would otherwise have been included. --Redrose64 (talk) 11:29, 24 August 2016 (UTC)
    @Redrose64: I think the short MLA can be finessed using existing |loc= in sfn, plus text for the year (since sfn treats everything as a string), plus and ref={{harvid}} except for the hard-coded comma in Module:Footnotes (in the args.location). See the very first cite in my sandbox for a fake example.  Lingzhi ♦ (talk) 12:15, 24 August 2016 (UTC)

For a long time I have wanted to restructure the code that assembles the miscellaneous constituent parts into a recognizable whole. Perhaps this is the burr under the saddle.

To help me understand what kind of changes are needed, I have hacked the sandbox so that |mode=mla controls a couple of the most obvious differences between cs1 and mla, date and editor placement and style, for {{cite book}}:

Author; Author2; Author3 (2016). "Chapter". In Editor; Editor2. Title. Location: Publisher. pp. 12–34. 
Author, Author2, and Author3. "Chapter". Title. Eds. Editor, and Editor2. Location: Publisher, 2016. pp. 12–34. 

Trappist the monk (talk) 11:15, 24 August 2016 (UTC)

And last author / editor separator. —Trappist the monk (talk) 13:27, 24 August 2016 (UTC)

I don't think this is currently feasible in practice, but if you're looking at switches to control citation style, please consider the possibility of the displayed citation format being controlled by a user preference. At least half the clamour for, e.g., MLA is due to dissonance when reading a cite in an unfamiliar format; as opposed to that caused when having to enter a cite in an unfamiliar format (for which, those with MLA bred in their bones will dislike any template-based solution). Letting them choose to see all cites in MLA format would help a lot (and the right gizmo in VisualEditor might eventually help with the other issue). --Xover (talk) 14:46, 24 August 2016 (UTC)
Aye, that would be the thing. But, I think that for such a thing, we would need to compel all editors to write citations with templates. I think that it is a bit much to expect some bit of code at MediaWiki to read free-form contents of <ref>...</ref> tags and then correctly render that reference according to a user's Special:Preferences. It would also require the server to render the citations at the time they are served or to cache multiple versions of the rendered page.
Trappist the monk (talk) 15:35, 24 August 2016 (UTC)
We might not be able to "compel all editors to write citations with templates". It would be progress to stop editors from blocking the conversion of (for want of a better description) "plain-text" references to use citation templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 24 August 2016 (UTC)
@Lingzhi: The changes that Trappist the monk has made to Module:Citation/CS1/sandbox are producing something very close to what you want for long citations:
  • {{cite book/new |last=Southam |first=Brian C |chapter=Grandison |editor-last=Grey |editor-first=J David |title=The Jane Austen companion |year=1986 |publisher=Macmillan |location=New York |isbn=0025455400 |mode=mla}}
produces:
  • Southam, Brian C. "Grandison". The Jane Austen companion. Ed. Grey, J David. New York: Macmillan, 1986. ISBN 0025455400. 
and
  • {{cite book/new |last=Tomalin |first=Claire |author-link=Claire Tomalin |title= Jane Austen: A Life |location=New York |publisher= Alfred A. Knopf |date=1997 |isbn=0-679-44628-1 |mode=mla}}
produces:
Surely that is appreciable progress. Thank you very much, Trappist.
Before anybody starts thinking about "faking" MLA-style short citations, I'd like to hear your refutation of my arguments in User:RexxS/NoCiteBar against using <<Author Page>> or sometimes <<Author "made-up Short title">> short citations in Wikipedia articles. It is clear that authors regularly produce multiple works on the same topic, which require disambiguating via a user-constructed "short title" in MLA-style (e.g. about 70 times out of 146 short references in Jane Austen 18 February 2016), whereas it is equally clear that authors rarely produce multiple works on the same topic in the same year (none in Jane Austen today). For Wikipedia use, MLA-style short citations are a non-starter: different editors make different short titles, and adding another work by the same author requires all the previous <<Author page>> cites to be found and disambiguated. No, no, no, no (sounds familiar?). Harvard-style short cites (as already implemented in sfn) have the same format throughout, so any editor new to the page can copy the same style without effort by using the template {{sfn}}, and Ucucha's script can catch any errors that creep in. There's really no case for using anything else. --RexxS (talk) 21:21, 24 August 2016 (UTC)

First/last name order:

Last1, First1; Last2, First2; Last3, First3 (2016). "Chapter". In EditorLast1, EditorFirst1; EditorLast2, EditorFirst2. Title. Location: Publisher. pp. 12–34. 
Last1, First1, First2 Last2, and First3 Last3. "Chapter". Title. Eds. EditorLast1, EditorFirst1, and EditorFirst2 EditorLast2. Location: Publisher, 2016. pp. 12–34. 

Trappist the monk (talk) 00:36, 25 August 2016 (UTC)

I have a few quick thoughts about MLA, and maybe these are items yet to come as this effort proceeds. If so, I apologize for jumping the gun.
  • At least the more recent versions, the style specifically omits URLs and assumes that anyone can search for the source online. Of course we can link to a source within our citations because our formatting explicitly includes hyperlinks while MLA is designed for print. I assume we'd want to continue the practice of actually linking items, and probably continue to insert the file type as we do now.
  • Also, MLA would append a medium designation, something like "Print" or "Web" to the end of the citation. For online sources, the "Web" would be followed by the access date. If it were a source reprinted online, that would be "Web. <republisher>. <access date>." Perhaps a little coding to assume that this would be "Print" unless a link is supplied when it would be "Web", but we'd need to either use |type= or another new parameter to allow editors to override this for DVDs and other media.
Imzadi 1979  01:42, 25 August 2016 (UTC)
I would have thought that the addition of a hyperlink when a source is available online is such a convenience for the reader that there's no case for failing to do that in our citations. MLA is indeed designed for printed work (including instructions on margins, double line spacing and the name of the Works Cited section), so we have to adapt to some extent. The whole point of offering an MLA-style long citation is so that readers accustomed to that style don't find it jarring when they see the citations in CS1 default style, not to precisely mimic a print format within an online encyclopedia. I can therefore see little point in appending "Web" or "Print" - that tells readers of the printed article that it's worth searching for online or not. In a Wikipedia article, it is surely obvious that if there's a hyperlink, it's available online, and if there's not, it isn't. --RexxS (talk) 02:11, 25 August 2016 (UTC)
It seems to me that it would be a bit disingenuous to add the capability to code a citation with |mode=mla and not actually output what MLA says is their citation format. That said, I've seen something that makes it seem as though they've dropped the medium indicator from the 8th edition published this year, so that might be something unique to the 7th edition that's now superseded. Imzadi 1979  15:22, 26 August 2016 (UTC)

Original year and edition:

Author; Author2; Author3 (2016) [1920]. "Chapter". In Editor; Editor2. Title (2nd ed.). Location: Publisher. pp. 12–34. 
Author, Author2, and Author3. "Chapter". Title. 1920. Eds. Editor, and Editor2. 2nd ed. Location: Publisher, 2016. pp. 12–34. 

Trappist the monk (talk) 09:48, 25 August 2016 (UTC)

Translators:

Author; Author2; Author3 (2016) [1920]. "Chapter". In Editor; Editor2. Title. Translated by Translator; Translator2 (2nd ed.). Location: Publisher. pp. 12–34. 
Author, Author2, and Author3. "Chapter". Title. 1920. Trans. Translator, and Translator2. Eds. Editor, and Editor2. 2nd ed. Location: Publisher, 2016. pp. 12–34. 

Trappist the monk (talk) 13:49, 25 August 2016 (UTC)

Contributors:

Contributor (2016) [1920]. Introduction. Title. By Author; Author2; Author3. Editor; Editor2, eds. Translated by Translator; Translator2 (2nd ed.). Location: Publisher. pp. 12–34. 
Contributor. Introduction. Title. 1920. By Author, Author2, and Author3. Trans. Translator, and Translator2. Eds. Editor, and Editor2. 2nd ed. Location: Publisher, 2016. pp. 12–34. 
Contributor. Introduction. Title. 1920. By Author, Author2, and Author3. Eds. Editor, and Editor2. 2nd ed. Location: Publisher, 2016. pp. 12–34. 
Contributor. Introduction. Title. 1920. By Author, Author2, and Author3. Trans. Translator, and Translator2. 2nd ed. Location: Publisher, 2016. pp. 12–34. 
Contributor. Introduction. Title. 1920. By Author, Author2, and Author3. 2nd ed. Location: Publisher, 2016. pp. 12–34. 
Contributor. Introduction. Title. By Author, Author2, and Author3. 2nd ed. Location: Publisher, 2016. pp. 12–34. 
Contributor. Introduction. Title. By Author, Author2, and Author3. Location: Publisher, 2016. pp. 12–34. 

Trappist the monk (talk) 11:07, 1 September 2016 (UTC)

Break[edit]

@Trappist the monk, RexxS, and Lingzhi: I know nothing about templates and haven't read the above, so perhaps this isn't feasible, but I would love to see those templates converted so that we could simply place the punctuation where we needed it. At the moment, I write manually:

  • John Rawls, A Theory of Justice, Cambridge: Harvard University Press, 1971, 1.
  • and thereafter: Rawls 1971, 2.
  • Chantal Zabus, "The Excised Body in African Texts and Contexts," in Merete Falck Borch (ed.), Bodies and Voices: The Force-field of Representation and Discourse in Colonial and Postcolonial Studies, New York: Rodopi, 2008, 1.
  • and thereafter: Zabus 2008, 2.
  • Nicky Woolf, "Stingray documents offer rare insight into police and FBI surveillance", The Guardian, 26 August 2016.

When I'm editing with people who use templates, I can copy their style manually, even though it leads to internal inconsistency with newspapers (date after name if there's a byline, and date at the end if not; it's frustrating to add an inconsistency deliberately just to copy the template style). But if people edit an article where I've added manual cites in the style above, they can't copy my style (or any other) using templates; they have to do it manually because the templates are so limiting.

Is it not possible to create a set of templates where the punctuation is more flexible? SarahSV (talk) 00:07, 27 August 2016 (UTC)

Is it really punctuation that you're talking about or is it element placement or a combination of both? Your apparently preferred style looks to be a combination of cs2 (comma separated elements) and mla (publication date moves to the end):
  • John Rawls, A Theory of Justice, Cambridge: Harvard University Press, 1971, 1. – your original
  • John Rawls (1971), A Theory of Justice, Cambridge: Harvard University Press, 1. {{cite book}} with |mode=cs2
  • John Rawls. A Theory of Justice. Cambridge: Harvard University Press, 1971. 1. {{cite book}} (sandbox) with |mode=mla
A primary purpose of the templates is to take on the burden of punctuation so that editors don't have to worry about it – punctuation just happens and it is the same, citation-to-citation, editor-to-editor. One could, I suppose, create punctuation-specific parameters:
|title= – normal or standard title parameter follows the cs1|2 rules according to the rules of the enclosing template
|title,= – override the normal cs1 element separator, full stop, with a comma
|qtitle= – force a normally italic title to be quoted
|ititle= – force a normally quoted title to be italic
|ptitle= – force a normally italic or quote title to be plain text
One could extend this idea and enumerate the parameters so that they would render in order specified in the template:
{{cite book |1author,=John Rawls |2title,=A Theory of Justice |3location=Cambridge |4publisher,=Harvard University Press |5date,=1971 |6page.=1 |nopp=yes}}
I don't think that either of these ideas should be pursued. Better, I think is to support a handful of commonly used and well documented styles – mla, apa, cms.
The above discussion that you didn't read is mostly about implementing mla in the cs1|2 templates. I have adapted {{cite book}} so that it can render basic mla style. I intend to similarly adapt {{cite journal}}, {{cite news}}, and {{cite web}} and then when real life gets out of the way, take what I've learned from this experiment and rewrite a large chunk of Module:Citation/CS1 so that other similarly documented styles can be supported.
Trappist the monk (talk) 10:38, 27 August 2016 (UTC)
Trappist the monk, thank you for the detailed response. The style I use is close to Chicago, but I've pared it down to all commas, no brackets, to keep it simple. I usually use the long cite on first reference in the text and the short thereafter, and usually no separate bibliography section.
Can cite news at least be changed so that the dates don't move? We had an RfC that supported the change, but it was never implemented. SarahSV (talk) 16:16, 27 August 2016 (UTC)
Above I mentioned a rewrite of a large chunk of Module:Citation/CS1. The difficulty that Editor Dragons flight mentioned in the RfC still exists. I would expect that at the end of the rewrite, it will be easier to position the publication date as the second element in the rendered citation.
Trappist the monk (talk) 09:50, 28 August 2016 (UTC)
@Trappist the monk: I strongly disagree with both creating punctuation-specific and enumerating parameters as this would make total mess over months/years and references would be not unified/uniform but – mess. I'm even surprised that you proposed this as goal of CS1 was to standardize – not to allow "citeshakes"?
Moreover, I thought you would simply ignore SarahSV's comment as this user is not using CS1 and says ... they can't copy my style (or any other) using templates; they have to do it manually because the templates are so limiting. – I can't even comment on this one.
@SlimVirgin: Templates and CS1 are not "so limiting" but a perfect solution not to disable people from "copying each other styles" but to introduce one style for all references that can be altered in future if there is need to, because citation style and Wikipedia style generally should be uniform and consistent with guidelines; if every editor would cite in a different way – "chaos mode" would be turned on in references section.--Obsuser (talk) 23:07, 27 August 2016 (UTC)
You must have missed this line in that post: I don't think that either of these ideas should be pursued. It is the prerogative and the responsibility of the cs1|2 templates to handle formatting details. I do not think that we should be changing that. What I wrote was merely a thought experiment.
When an editor specifically asks a question of me, as was done here, common courtesy requires me to respond. No one benefits if questions that can be answered are left unanswered.
Trappist the monk (talk) 09:50, 28 August 2016 (UTC)
Just for the record, I also "strongly disagree with both creating punctuation-specific and enumerating parameters" for similar reasons. We already have a frequent problem with people abusing the |publisher= parameter to "get their way or else" in their WP:GREATWRONGS campaign against ever italicizing the name of a cited website, for example. This nonsense battlegrounding has to stop, not be given a whole new navy of battleships with which to engage in style-micromanagement editwarring. I also agree with the points above about the benefits of a consistent citation style. I don't think we should be doing any work at all to integrate MLA, ALA, AMA, etc. citation styles into CS1 or any template system; it's a non-productive waste of editorial time to do it, and an much worse waste of many editors' combined editorial time to deal with the mess it creates, and, worst of all, all the "don't you dare touch my precious citation formatting" drama festivals it generates. If we just ignore these off-WP citation styles, at some point the sheer pressure of more and more articles being done in default CS1 style, and more and more articles converted to it without objection, will result (finally) in consensus that WP should have a consistent citation style, not permit every imaginable, inconsistent one. That may take 5 years, or 10. Even if it never happened, what has to go – no doubt – is the nonsense WP:LOCALCONSENSUS over at WP:CITE that any made-up on the spot out of your own imagination citation "style", not found in any source anywhere, can be ruthlessly enforced at an article as long as you made it the consistent "style" at the article at some point, no matter how irrational and confusing the "style" is. WP:CITEVAR was intended to permit people professionally steeped in a particular, real-world citation style, like AMA or MHRA or Vancouver, to use it here without hissy-fits erupting about it (and this has proven to be a mistake). Whether or not that was a good idea, it's since then been totally hijacked to permit idiosyncratic WP:OWN chaos that has to go. This will probably require a WP:VPPOL RfC, since prior attempts to deal with it at WT:CITE itself have met with tagteam stonewalling.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:10, 28 August 2016 (UTC)

mla in cite journal[edit]

Adapting {{cite journal}} to use mla:

Author; Author2; Author3 (2016). "Title". Journal. Volume (Issue): 12–34. 
Author, Author2, and Author3. "Title". Journal. vol. Volume no. Issue, (2016). pp. 12–34. 

Trappist the monk (talk) 12:12, 27 August 2016 (UTC)

If I make a tangential comment, but seeing how this is formatted above MLA style, reminds me of a minor request related to {{cite magazine}}. That template is capitalizing "Vol." when I think it really should be lowercasing it as your MLA example does. Maybe a minor change for a future module update? Imzadi 1979  14:01, 29 August 2016 (UTC)
Compare these; one is {{cite magazine}} (cs1) and the other is {{citation}} (cs2):
"Title". Magazine. Vol. 23 no. 4. Archived from the original on 2016-08-29. Retrieved 2016-08-29. 
"Title", Magazine, vol. 23 no. 4, archived from the original on 2016-08-29, retrieved 2016-08-29 
The 'style' defined for cs1 is to use full stops between citation elements compared to commas for cs2. Because each citation element in cs1 is essentially a new sentence, the element's static text is capitalized. Because cs2 is a single sentence, the static text is not capitalized.
Trappist the monk (talk) 15:04, 29 August 2016 (UTC)
Except that "p." and "pp." aren't capitalized when used, so I don't buy the "separate" sentence argument. Why isn't the volume ended by a period when issue and page number are?
"Title". Magazine. Vol. 23 no. 4. p. 6. Archived from the original on 2016-08-29. Retrieved 2016-08-29. 
I think it would be better to be a bit more consistent here, and oddly MLA shows a bit of a better way forward. Imzadi 1979  15:36, 29 August 2016 (UTC)
Are p. and pp. ever capitalized outside of Wikipedia? I don't think that those two have ever been capitalized in cs1|2. 'Vol.' has only recently been made available. The thing that I notice about your example is the separator character following the issue number. If there isn't a separator character between volume and issue, should there be a separator character between issue and page?
Trappist the monk (talk) 10:03, 30 August 2016 (UTC)

mla in cite news[edit]

Adapting {{cite news}} to use mla:

Author; Author2; Author3 (3 September 2016). "Title". Newspaper. Volume (Issue). pp. D12+.  – cs1 live
Author; Author2; Author3 (3 September 2016). "Title". Newspaper. Volume (Issue). pp. D12+.  – cs1 sandbox
Author, Author2, and Author3. "Title". Newspaper, 3 September 2016. pp. D12+. 

Trappist the monk (talk) 10:33, 3 September 2016 (UTC)

I didn't get it quite right. When the mla version of {{cite news}} (and {{cite journal}} and {{cite web}}) did not have |author=, the title would not display. That has been remedied.

without author; with editor
Editor; Editor2; Editor3, eds. (3 September 2016). "Title". Newspaper. Volume (Issue). pp. D12+.  – cs1 live
Editor; Editor2; Editor3, eds. (3 September 2016). "Title". Newspaper. Volume (Issue). pp. D12+.  – cs1 sandbox
Editor, Editor2, and Editor3, eds."Title". Newspaper. pp. D12+, 3 September 2016. 
without author or editor
"Title". Newspaper. Volume (Issue). 3 September 2016. pp. D12+.  – cs1 live
"Title". Newspaper. Volume (Issue). 3 September 2016. pp. D12+.  – cs1 sandbox
"Title". Newspaper. pp. D12+, 3 September 2016. 

Trappist the monk (talk) 11:02, 8 September 2016 (UTC)

Cite interview title and italics[edit]

I searched in the CS1 archives regarding {{cite interview}} and couldn't find a reason for why cite interview italicizes its title.

I couldn't find anything in our Manual regarding the title of an interview. MLA and Chicago recommend (not official links!) to place the title of a published interview in quotation marks, while APA doesn't seem to have a recommendation (presumably because they consider published interviews to take the format of the publication type in question--official blog from 2009--APA then seemed to have the practice of italicizing their titles regardless, so maybe it's not worth considering).

Would there be support for changing how interview titles are cited to use quotation marks instead of italics? (I did note Help talk:Citation Style 1/Archive 5#The "title" parameter in the Cite interview, which seems to work around a local issue and which happens to use the italics as a feature, not a bug, but as cite interview is only used about 3k times, I doubt that we couldn't fix them locally as necessary.) --Izno (talk) 22:46, 27 August 2016 (UTC)

Yeah, should be quotation marks. The major work in which the interview is published gets the italics.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:14, 28 August 2016 (UTC)
{{cite interview}} is one of those templates that needs a rewrite. To make it work with {{citation/core}}, |program=, |callsign=, and |city= are all concatenated into the meta-parameter ID. For some reason, |type=, which is media descriptor, is used to modify |interviewer(s)= (an alias of |others=). When I converted the template to use Module:Citation/CS1, I retained these peculiarities because the task at the time was to faithfully reproduce {{citation/core}}.
Trappist the monk (talk) 11:09, 2 September 2016 (UTC)
I'm happy to have a discussion actually about remapping/rewriting for cite interview, but I suspect the change needed for |title= would be simple.
Regarding the other stuff in your comment, the template talk page's history may be an interesting view into template's history and may explain some of the peculiarities.
  • Type looks to be explained: it looks like the name just overlaps and so cleanup is needed for it. We might want to do a survey (add a category) of the pages using type in cite interview.
  • Program should probably alias |work=; usage seems to indicate that the field might need some cleanup.
City should probably map to |location= or |publication-place=. |callsign= mapping to ID doesn't seem like a bad choice, but it shouldn't override ID in case another is identified. In our current example at Template:Cite interview, the call sign seems to be an alias for the |publisher= or possibly the republisher, as in the second example (which would go in |via=). NPR for some reason is the program, which doesn't make sense to me. Maybe call-sign should wait for another day. :D
Another personal peculiarity: I find the mapping of interviewee to author peculiar, but not interviewer to author--ostensibly, they should share credit, because the interviewer thought of and published the questions asked. Of course, now we have |contributor=, if we don't think the interviewer should share credit... just some thoughts.
To get around the issue in the H:CS1 archive, I might suggest the following order regarding the URL: title, work/program, and if neither are available (unlikely--the interview may as well be unpublished at that point!) the text "interview with interviewer" should probably get the url. Of course, |work= can usually take a wikilink, so I'm not sure about that suggestion... So many cut out linking work, and simply: if title is missing, then link the text "interview with" or possibly "interview". --Izno (talk) 11:41, 2 September 2016 (UTC)
This search suggests that there aren't too many {{cite interview}} templates that use |type=.
In looking through that list, I notice stuff like this ('video' and the 'Interview' static text in separate parentheses – because there is no |interviewer=):
{{cite interview |subject= Sia|subjectlink= Sia Furler|type= video|title= Sia—Interview|url= http://www.bbc.co.uk/later/artists/sia/|program= ''[[Later... with Jools Holland]]''|callsign= BBC Two|city= London|date= October 2008 |accessdate=14 November 2008 }}
Sia (October 2008). Sia—Interview (video). (Interview). Later... with Jools Holland. BBC Two. London. Retrieved 14 November 2008. 
So that needs fixing.
Remapping |program=|work= seems obvious as does |city=|location=. |callsign=|publisher=?
I wonder if we shouldn't treat interviewers the same way we treat translators: create enumerated |interviewern=, etc; have dedicated static text so instead of Translated by $1 we use Interviewed by $1; |type= if set overrides the predefined meta-parameter TitleType value (just like all of the other cs1 templates that use predefined TitleType).
Titles are required for all cs1|2 templates. I'm not sure we should break that rule here.
Trappist the monk (talk) 13:36, 2 September 2016 (UTC)

The template currently supports |interviewer= and |interviewers=. I don't see a problem with adding the enumerated case, and perhaps interviewer-first/last; would the intent be to add that to the metadata as I suggested? Otherwise, doesn't seem worth it.

I'm wondering if we can't just remove the non-standard parameters; namely, |call-?sign= (179 articles), |city= (465 articles), and |program= (563 articles).

Should we choose not to remove them:

  • For callsign, it looks like it's subject to the standard work/publisher confusion, but indicating perhaps a higher-level work. I don't think capturing the higher-level work is necessary or desirable, so setting it to publisher would be okay in the majority of cases.
  • I think we're agreed re city and program.
Regarding titles, don't we have a keyword lying around when the title is unknown or is not present for the lesser work in question? It's not documented in the generic documentation, if so. --Izno (talk) 16:08, 2 September 2016 (UTC)
For the sake of consistency, interviewer names would have the same parameter variants ans other namelists.
The only names in the metadata are author names. Translators, editors, interviewers, others, coauthors; none of these get into the metadata. When the metadata standard changes or we adopt another standard, then those names can be included.
We should deprecate before we remove, but I am in favor of removing those three parameters.
Only {{cite journal}} allows |title=none because there is an abbreviated 'style' used in some scientific disciplines that omits article titles in journal citations.
Trappist the monk (talk) 11:04, 3 September 2016 (UTC)
The only point in response, because I'm fine with the rest: the handful of links above for the other styles each noted the case of the untitled interview. I'm personally fine with an interview being untitled and having an error, but it seems to me like the other information present would be sufficient (namely, the combination of interviewer, interviewee, and work). Maybe it should be questionable from our point of view whether the interview is legitimately published if it contains no title. *shrug* I think the other changes clearly have my agreement. :D --Izno (talk) 23:12, 3 September 2016 (UTC)
I've marked the parameters callsign, program, and city as deprecated in the sandbox and provided replacement documentation in the errors page. The below should provide at least one error:
Cite interview compare
{{ cite interview | program=Program | title=Title }}
Live Title. (Interview). Program. 
Sandbox "Title". Program (Interview).  Cite uses deprecated parameter |program= (help)
Cite interview compare
{{ cite interview | callsign=Callsign | title=Title }}
Live Title. (Interview). Callsign. 
Sandbox "Title" (Interview). Callsign.  Cite uses deprecated parameter |callsign= (help)
Cite interview compare
{{ cite interview | call-sign=Call-sign | title=Title }}
Live Title. (Interview). Call-sign. 
Sandbox "Title" (Interview). Call-sign.  Cite uses deprecated parameter |call-sign= (help)
Cite interview compare
{{ cite interview | city=City | title=Title }}
Live Title. (Interview). City. 
Sandbox "Title" (Interview). City.  Cite uses deprecated parameter |city= (help)
Cite interview compare
{{ cite interview | program=Program | callsign=Callsign | city=City | title=Title }}
Live Title. (Interview). Program. Callsign. City. 
Sandbox "Title". Program (Interview). City: Callsign.  Cite uses deprecated parameter |city= (help)
I'm boggled on where to go in the module to correct the use of italics versus quotation. I'd like a pointer and then to see if I can implement it myself. --Izno (talk) 04:37, 17 September 2016 (UTC)
Okay, I've figured out the title change. I made a decision to 'prefer' some values; I'm not hung up on a change in that regard. I will look at the type next. --Izno (talk) 05:38, 17 September 2016 (UTC)
I tweaked the remapping of parameters a bit. When a variable is set, no need to re-set it. Carry on.
Trappist the monk (talk) 10:01, 17 September 2016 (UTC)
I went to implement a "fix", but maybe we should discuss how we want the citation to appear instead in the following cases:
  1. |type= is set and |interviewer= (or variant) is set.
  2. |type= is set and |interviewer= is not set.
  3. |type= is not set and |interviewer= is set.
  4. |type= is not set and |interviewer= is not set.
--Izno (talk) 16:19, 17 September 2016 (UTC)
I think that I would like to see |type= default to |type=Interview regardless of the presence or absence of |interviewer=. That way is consistent with other cs1 templates that have default |type= values. If an editor chooses, |type= may be set to something other than the default value.
Along with that, perhaps |interviewer= is treated the same way we treat |translator=; fixed text as prefix: 'Interviewed by <interviewer-name-list>' (or some such).
Trappist the monk (talk) 11:11, 18 September 2016 (UTC)
Should interviewers come before or after translators? --Izno (talk) 15:07, 18 September 2016 (UTC)
I've started implementing interviewers and it looks like i broke something with title type = interview; I will be back later. --Izno (talk) 15:10, 18 September 2016 (UTC)
I took care of some stray punctuation. In doing so, I made two assumptions: interviewers should be available to every citationClass/mode, and they should come before translators. These can be changed if someone wants. --Izno (talk) 20:49, 18 September 2016 (UTC)

Type and language[edit]

When |type= and |language= are both specified where a title appears (and perhaps without a title?) (as with any of the citation templates that default a type), we get output that looks like

Subject. "Title" (Interview) (in French). Publisher. 

We should also clean this up after. --Izno (talk) 15:46, 18 September 2016 (UTC)

This also occurs with |type= and |format=:
Subject. "Title" (Format) (in French). Publisher. 
And all three:
Subject. "Title" (Format) (Interview) (in French). Publisher. 
With work included, these become:
  • Subject. "Title". Work (Interview) (in French). Publisher. 
  • Subject. "Title" (Format). Work (in French). Publisher. 
  • Subject. "Title" (Format). Work (Interview) (in French). Publisher. 
--Izno (talk) 20:49, 18 September 2016 (UTC)
When we updated {{cite map}} last year to put it on the Lua module, we gave it a little bit of "intelligence" that I think should be put into play in other situations. For example:
  • "Map" (Format) (Map). Atlas. Scale (in French). Publisher. 
In this case, the map title is followed by the type indication instead of listing it after the title of the encompassing work, which itself isn't a map. In the future, I'd do something like:
  • "Map" (Map, Format). Atlas (in French). Scale. Publisher.
which would merge the adjacent parenthetical statements together and shift the language away from the scale so as not to imply that the scale itself was in another language. Imzadi 1979  00:13, 19 September 2016 (UTC)
local tcommon
to
else	-- all other CS1 templates
	tcommon = safe_join( {Title, TitleNote, Conference, Periodical, Format, TitleType, Series, Language, 
		Volume, Others, Edition, Publisher, Agency}, sepc );
end
we have a whole bunch of "stuff these together" while for e.g. Language regarding styling we have:
if is_set (Language) then
	Language = language_parameter (Language);	-- format, categories, name from ISO639-1, etc
else
	Language="";					-- language not specified so make sure this is an empty string;
end
Language is getting stuff done to it that doesn't care about the other things that might be parenthetically placed in that location. TitleType is similar. For these two, which are referenced only rarely elsewhere in the module, fixing this issue may be trivial, I think. Format on the other hand seems to be referenced in multiple different locations and will likely require a bit more hacking. Mostly this is research on my part. :D --Izno (talk) 04:09, 22 September 2016 (UTC)

Type expectations[edit]

To return to a previously (as in years ago) requested modification/clarification, what exactly is |type= supposed to be? Is it:

  1. Type of medium ("video" "print" "audio" "digital" "plaque" "photograph" etc.)
  2. Type of source ("interview" "media notes" "thesis" "press release" etc.)
  3. Type of binding/packaging ("paperback" "CD" "VHS" or in digital bindings, "file-format"/"platform and file-format" etc.)
  4. Whatever

Please do not repeat here what type: states in the various template docs, it's painful. Assuming that no. 4 above does not apply, can a less confusing |type= be had? 65.88.88.127 (talk) 19:47, 19 September 2016 (UTC)

Citation/"source" type is what the phrase is used for those citation classes which use the type by default, and this is echoed by the documentation in Help:CS1. It seems to me that the medium/source/packaging question is something of a false trichotomy--all of those may be source types; while I might prefer to see something like "video interview" when someone uses |type=, I wouldn't be bothered by just seeing |type=[Vv]ideo. --Izno (talk) 13:56, 21 September 2016 (UTC)
By the same logic, all {{cite xxx}} templates are unneeded specializations of {{citation}}. For citation purposes, i.e. to expeditiously direct people to proof of claims in an article, "medium" is not a "source", and neither of the two is "binding". 72.43.99.146 (talk) 15:00, 21 September 2016 (UTC)

Unwanted semicolon[edit]

When a book or article has more than one article or editor, with Template:Cite book a semicolon is placed between the first and second author, or between the first and second editor. For example "Dominic Baker-Smith; Cedric Charles Barfoot". I think this should be a comma. In the ISBD, a semicolon is used when contributors to a publication have different roles, which are mentioned in the description, for examples an editor, author, illustrator or translator. A comma or the word 'and' are usually used however between contributors with the same role (like two authors). In most referencing styles I see elsewhere, like APA style, the same applies. Bever (talk) 21:20, 1 September 2016 (UTC)

CS1 follows the "Last, First" convention for most names. Comma separators between contributors would not work well with the current scheme. There is also some facility for indicating roles in CS1 already. Is there any specific reason for CS1 to comply with ISBD? 65.88.88.127 (talk) 21:33, 1 September 2016 (UTC)
@Bever: you can include |last-author-amp=yes which inserts an ampersand between the last two authors (or editors) in a list. In your example, you'd get "Dominic Baker-Smith & Cedric Charles Barfoot". If you used |first=Dominic |last=Baker-Smith |first2=Cedric Charles |last2=Barfoot, you'd get "Baker-Smith, Dominic; Barefoot, Cedric Charles", which makes clear why we use the semicolon without the optional parameter to use an ampersand between the last two entries in an author list. Imzadi 1979  01:55, 2 September 2016 (UTC)
I can the point you both make about confusing commas. In scientific publications, often only initials are used for first names, so they are easily recognizable, making the extra commas less problematic. Sometimes the comma between last name and initials is even omitted. Personally I think the reversed name order is only useful when you want to sort the publications alphabetically (on last name), which is typically not the case when using footnotes... Bever (talk) 16:47, 18 September 2016 (UTC) PS Thank you for the ampersand advice.
Alterations in separators based on whether the first name is an initial or not seem like a non-starter to me. As for the sorting comment, list of full citations are (correctly) sorted by Last where WP:SFN and WP:GENREF is employed. 65.88.88.127 (talk) 18:51, 18 September 2016 (UTC)

cs3 for a new separator.[edit]

A recent technical change to Template:nlab to use cite-web broke the display style there. It dropped the word "in", and I can't figure out how to reinstate it. Viz. it now reads, for example, Pointed object in nLab whereas it used to read, last week, Pointed object in nLab. (without the quotes, with the word "in"). The new format is awkward and visually ugly, and (most importantly) confusing to look at (to non-afficionados who may not know what ncatlab is). So... I'd like to get the old display style back, while keeping whatever the technical reasons are for converting the the cite-web template. It would seem that proposing a mode=cs3 that drops the quotes, and adds the word "in" is the only way to do this. Is there another way? How can we get the technical advantages(?) of using cite-web, and still get the prettier formatting of the older template? 67.198.37.16 (talk) 19:03, 2 September 2016 (UTC)

That would be a heck of a change to accommodate one external link template that is used just a few times. The more straightforward way to get what you want would be to discuss the change on the template's talk page or at the relevant WikiProject and decide whether the template should use the cite web template at all. Since it is used to link to a wiki, using the cite web template may be misleading to editors and may lead them to use it in references instead of just in external links. – Jonesey95 (talk) 20:52, 2 September 2016 (UTC)
that would result in us loosing all the other advantages of wrapping {{Cite web}}, such as validation, and COinS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:02, 2 September 2016 (UTC)
OK, never mind, I'm just being stupid, there is an obvious alternative. 67.198.37.16 (talk) 17:09, 3 September 2016 (UTC)
Yes; you've canvassed another editor to revert my changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 7 September 2016 (UTC)

Cite Polish law[edit]

I've made {{Cite Polish law}} a wrapper for {{Cite web}}, but it has |volume= and |number= parameters, which I've temporarily shoe-horned into the |website= parameter. Is there a better solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:58, 7 September 2016 (UTC)

I've solved that by making it wrap {{Citation}}, instead. Please let me know if my edits can be improved further. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 7 September 2016 (UTC)
A technicality, but AFAIK, {{citation}} is Citation Style 2, not CS1, so your wrapper template is not quite accurate. Keep up the bold work. – Jonesey95 (talk) 13:59, 7 September 2016 (UTC)
Why not use cite journal instead of cite web? Headbomb {talk / contribs / physics / books} 15:01, 7 September 2016 (UTC)
Someone has reverted your changes but left the documentation inconsistent. Before I realised that I created a sandbox and testcases to experiment with using the mode parameter, but so far that has not worked as I expected. I've not touched the live template. --Mirokado (talk) 22:00, 7 September 2016 (UTC)

Thank you, all. I've made it wrap {{Cite journal}}, instead. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 8 September 2016 (UTC)

I've been reverted, again, apparently because the template did not match "the legal Polish format". I wasn't aware that we were subject to Polish law. It would be interesting to review the internal consistency of citations in articles using the template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:03, 13 September 2016 (UTC)


Language template[edit]

A side issue: I understand now why this revert of part of my edit was made, but how else can we show the language of a non-English title? (As opposed to the |language= of the target page.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 8 September 2016 (UTC)

We've discussed a |title-lang=es/|title-es= in the past, derived from discussion at the feature request for it. Aside: I doubt there would be support for displaying the language of the title, as that's really just fluff for a citation. --Izno (talk) 12:32, 8 September 2016 (UTC)
It's not about displaying the language of the title (my use of "show" was imprecise, sorry), but marking it up correctly. For instance, {{lang|pl|Twoje zdrowie!}} displays as Twoje zdrowie! and emits the HTML: <span xml:lang="pl" lang="pl">Twoje zdrowie!</span> . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 8 September 2016 (UTC)
Then you may want to review the archive discussion; contributors do desire this function, but were a) split on the parameter set and b) per the Html 5 specification, specifying only the lang and not the xml:lang e.g. <span lang="pl">Twoje zdrowie!</span>. --Izno (talk) 19:50, 8 September 2016 (UTC)

BioRxiv support[edit]

bioRxiv, similarly to arxiv, is a preprint repository for biology. They don't quite have a dedicated identifier, but they do make use of a DOI system, which is not the same as the published version's DOI. I propose we add support for Biorxiv as an identifier

Option 1

e.g. Luallen, Robert J.; et al. (30 June 2016). "Discovery of a Natural Microsporidian Pathogen with a Broad Tissue Tropism in Caenorhabditis elegans". PLOS Pathogens. 12 (6): e1005724. bioRxiv 047720 Free-to-read lock 75.svg. doi:10.1371/journal.ppat.1005724.

Option 2

e.g. Luallen, Robert J.; et al. (30 June 2016). "Discovery of a Natural Microsporidian Pathogen with a Broad Tissue Tropism in Caenorhabditis elegans". PLOS Pathogens. 12 (6): e1005724. bioRxiv 10.1101/047720 Free-to-read lock 75.svg. doi:10.1371/journal.ppat.1005724.

Option 1 has the merit of being in line with how bioRxiv presents their pseudoidentifier (click citation tools on the right of that website), but option 2 makes the doi nature of the link clearer, and would be more useful in print. Personally I lean towards option 1, but I'd rather let people more experienced with bioRxiv than me decide. I'll advertise the discussion at relevant wikiprojects. Headbomb {talk / contribs / physics / books} 21:49, September 7, 2016 (UTC)

  • I'm fine with Option 1. I don't think it's important to draw attention to the DOI resemblance. --Tryptofish (talk) 21:59, 7 September 2016 (UTC)
These citations are confusing (to me). You are citing a pre-print and the published, peer-reviewed version in the same citation. Those are two different articles. Just as DOI is not allowed in {{cite arxiv}}, we should not allow a DOI and biorxiv value in the same citation. Help us understand what you are trying to achieve here. – Jonesey95 (talk) 23:24, 7 September 2016 (UTC)
The journal is cited, the bioRxiv copy is linked as convenience, just like we do with arXiv (e.g. W.-M. Yao; et al. (Particle Data Group) (2006). "Review of Particle Physics: Pentaquark Update" (PDF). Journal of Physics G. 33 (1): 1–1232. arXiv:astro-ph/0601168free to read. Bibcode:2006JPhG...33....1Y. doi:10.1088/0954-3899/33/1/001. ). Headbomb {talk / contribs / physics / books} 23:41, 7 September 2016 (UTC)
I agree these could be two different articles, depending on the peer-review process. What might be useful is the linked biorxiv copy where the final version is non-OA. In my experience of mostly compbio papers, this isn't usually the case, but it could be different for other biology subfields? Amkilpatrick (talk) 00:16, 8 September 2016 (UTC)
(edit conflict)The identifier 10.1101/047720 is a doi simply because of its structure. Put that number in |doi= and it works:
{{cite journal |title=Discovery ... |doi=10.1101/047720}}
"Discovery ...". doi:10.1101/047720. 
This is just a proposal for a biorxiv identifier, right? We aren't contemplating a {{cite biorxiv}} here are we? If just an identifier, is the identifier anything but digits? Because it is and can (does) use the doi mechanism, anything after the first virgule can be any printable character.
Trappist the monk (talk) 00:07, 8 September 2016 (UTC)
Here it's for adding the identifier support. We might develop a {{cite biorxiv}} template in parallel to this, but that's not what this proposal is about specifically. Headbomb {talk / contribs / physics / books} 12:06, 8 September 2016 (UTC)
  • option 1 seems preferable--Ozzie10aaaa (talk) 00:03, 8 September 2016 (UTC)
  • Thanks for the heads up at WP:COMPBIO. It would definitely be good to have bioRxiv supported similarly to arXiv. I think Option 1 is fine here, in line with their own style. Amkilpatrick (talk) 00:13, 8 September 2016 (UTC)
  • Option 1 seems good to me. It is more useful than using the |doi= field because this field might be used for the published version (and adding a custom |biorxiv= parameter enables us to add the free-to-read lock silently). I am happy to implement that in the sandbox if it helps. − Pintoch (talk) 07:46, 8 September 2016 (UTC)

Here is the exemplar citation rendered by the sandbox. This rendering uses |biorxiv=047720 which is the simplest form and should work for all as long as the prefix is and remains 10.1101/. If ever that changes, then this scheme will stop working.

Luallen, Robert J.; et al. (30 June 2016). "Discovery of a Natural Microsporidian Pathogen with a Broad Tissue Tropism in Caenorhabditis elegans". PLOS Pathogens. 12 (6): e1005724. bioRxiv 047720free to read. doi:10.1371/journal.ppat.1005724. 

Trappist the monk (talk) 12:20, 8 September 2016 (UTC)

Should/does it support both 047720 and 10.1101/047720 as inputs? Headbomb {talk / contribs / physics / books} 12:27, 8 September 2016 (UTC)
As I wrote in my post, the sandbox does not support the doi form. Should it? I think not. If editors want to use the doi form there is |doi=.
Trappist the monk (talk) 14:57, 8 September 2016 (UTC)
Just throwing it out there as an idea. The output would be the same (truncated) in all cases though. Headbomb {talk / contribs / physics / books} 15:50, 8 September 2016 (UTC)

Non-standard citation templates[edit]

This search finds templates whose names begin "Template:Cite...", that do not wrap one of the standard CS1 citation templates (currently finding 144 results). I've already upgraded all those that were straightforward, to do so. This give all the usual advantages, such as error trapping and embedded COinS.

I invite anyone interested and capable to look at upgrading the rest (or to consider whether they should be deleted, or merged - I nominated several such templates at TfD in recent days). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 8 September 2016 (UTC)

You may be overreaching here. CS1 is a citation style. It is not a "standard". Just because a template attempts to cite something, does not mean it has to follow CS1, an unfinished spec to be sure. A more pertinent approach would be to fix meta- and specific-source templates that purport to be based on CS1 but either are not, or do so out of spec. 71.247.146.98 (talk) 11:56, 8 September 2016 (UTC)
Same thoughts here. If there are non-standard citation templates, it's probably for a reason. For example, some templates may reflect country-specific legal requirements for citing legal documents. At the very least, such changes should be first discussed on talk pages of the templates in question. — Kpalion(talk) 12:29, 8 September 2016 (UTC)

[reply to both] Well, I didn't ask anyone to immediately "upgrade", I said "look at upgrading". And CS1 templates are more configurable in their presentation, thanks to |mode=, than anything hard-coded to a single presentation. After that, WP:BOLD applies; prior discussion is not mandated. if you have a list of "templates that purport to be based on CS1 but either are not, or do so out of spec", please feel free to link to it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:42, 8 September 2016 (UTC)

Editing is not the issue. Editing just to comply with a specific style is. Especially when the style is wrongly claimed a "standard". Write similar templates that apply your preferred style. Then let editors choose which iteration to use. There has been previous discussion here about CS1-based templates that need attention or de-categorizing. The relevant categories include several examples. 64.134.65.76 (talk) 17:36, 8 September 2016 (UTC)
Thanks for the advice; I don't find it compelling; not least because you wrongly refer to "editing just to comply with a specific style"; and misquote me. And if you/ the other editor (or are you the same?) want me to work on something else, I expect you to provide the link, not to send me to search for it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 8 September 2016 (UTC)
Well your heading is "Non-standard citation templates". And this is a talk page for some citation templates (CS1), that you obviously exclude from the ones referred to in the heading, unless I'm mistaken. I don't think I misquoted. You mention "mode" but this is a CS1 parameter, and therefore not style-neutral. Also, I was not asking/telling you to work on anything, but laying out how things should be properly handled, imo. There are several subcategories in Category:Citation Style 1 templates. There are templates in them that don't belong. To me that is a better approach, but I wasn't trying to convince anyone to do anything about it. 65.88.88.127 (talk) 21:24, 8 September 2016 (UTC)

The Times[edit]

It looks as though {{Cite newspaper The Times}} could be made a wrapper for {{Cite news}}. The former's |column= appears to be unused, while the rather unnecessary |day_of_week= is used only once. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:20, 8 September 2016 (UTC)

There seems to have been some lag in applying the tracking categories'; but those parameters still appear to be used on fewer than ten articles each. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:25, 8 September 2016 (UTC)
Looking at the documentation for {{Cite news}} it appears that |department= could be used for the name of a column; it could also be used for other areas within a newspaper, such as editorials. Jc3s5h (talk) 20:37, 8 September 2016 (UTC)
Now updated to max. 59 pages using |column=; max. 85 pages using |day_of_week=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:15, 9 September 2016 (UTC)
Currently 118 page and 154 pages respectively. Andy, I think a lot more pages are using this template with those parameters than you think. Category population can be very slow when the job queue has high lag (you know that). Can you please wait until you are sure the categories are fully populated before doing anything. Previous discussion here (at the template talk page) is relevant. Also, you really should be pointing people to this discussion when they ask you what is going on. When Mjroots asked you here what was happening, your reply failed to point to this discussion, that is verging on misdirection. Your reply should have been along the lines of "I created the categories to help generate some statistics for the discussion I started where I am proposing to make this template a wrapper for cite news" (with a link to the discussion). @Iridescent: who I know has strong views on how this template should be used. Carcharoth (talk) 21:33, 9 September 2016 (UTC)
Now 136 pages and 194 pages respectively. It is clear that populating these tracking categories is going to take a long time. The transclusion count is 3017. Those that know how this template works and why it has 'column' and 'day of the week' parameters (The Times was published in a chapbook format for most of its history, hence this different citation style) know that most of the transclusions of this template will include use of these parameters, hence what Andy said above about the parameters being unused (or almost unused) makes no sense at all. I am going to ask at the technical village pump for advice here. Reversing the edits will just re-add to the job queue. Currently the issue is readers being served up with nonsensical category names as red-links (e.g. at Beckton Gas Works). I checked logged out, and readers are seeing those category names. I think we will need to create the categories and mark them as hidden, unless there is a way to 'hide' red-linked categories. Carcharoth (talk) 03:01, 10 September 2016 (UTC)
Short answer: no there isn't. Redlinked cats can never be hidden. --Redrose64 (talk) 07:47, 10 September 2016 (UTC)

Update: I have asked for advice here at the technical village pump. I wouldn't normally do this, but I think the issue needs some wider attention and I'll not be around for the next day or so. I'll add a similar note over at the template talk page. Carcharoth (talk) 03:24, 10 September 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

@Carcharoth: No. When asked:

what is the purpose of these uncreated categories? The are appearing on all articles and lists that use this template.

My reply, was:

As the name indicates, they are TEMPORARY. One tracks TEMPORARY Cite newspaper The Times using the 'column' parameter; the other tracks TEMPORARY Cite newspaper The Times using the 'day of week' parameter.

There was no "misdirection" - borderline or otherwise - whatsoever. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:15, 10 September 2016 (UTC)

I fully understood what they did, but I asked what the purpose of the categories was. If there is to be a proposal to do away with {{cite newspaper The Times}}, I for one will be opposing it. Mjroots (talk) 14:25, 10 September 2016 (UTC)
Andy, your reply to Mjroots lacked information. You gave a literal reply (explaining what 'temporary' means) rather than pointing to this discussion. I think that omission of a link to this discussion is far from ideal. I apologise for saying it verged on misdirection. I think we should now focus on trying to work out when the 'temporary' categories will be fully populated. Currently the numbers are 260 and 356 respectively. I think we need the numbers to be stable for at least a full day before being confident that the categories have fully populated. On the wider question of the use of the parameters, I think they are only really useful before a certain date. After that date, The Times became a 'normal' newspaper. Not sure when that was though. Hopefully someone else will be able to provide that information. Carcharoth (talk) 09:16, 11 September 2016 (UTC)
File:Times May 10 1830.jpeg
Page 2 of The Times as it was formatted in 1830
Regarding the comments above from Carcharoth, it might make it easier to explain why citing early issues of The Times differs from other newspapers to see what it looked like in chapbook days. Each issue consisted of a single large sheet of paper, which was folded in half to create four nominal "pages". The front was filled with adverts, and the rear was filled with official notices (law reports, auction notices, births, marriages & deaths, stock prices etc), leaving only the two inner "pages" for actual news. These two pages (one shown to the right for illustrative purposes) were filled with very, very small type so as to cram everything in, and most headings in the same small type as a space-saving measure. Thus someone checking a reference who wants to find it in the original will effectively have to read 50% of the newspaper to find it since it will always be on page 2 or 3 so the page number isn't particularly useful, and there aren't 'headlines' in the modern sense for the eye to skim over. As a consequence, it's conventional when citing early issues of the Times to provide a column reference as well as the page, which as things stand the existing {{cite news}} template can't handle. Regarding when they stopped using this format, it was a gradual process; in the early 1830s they went from one sheet of paper to two (e.g. 8 pages per issue), circa 1850 they went to three sheets (12 pages), and circa 1860 they went to four sheets (16 pages) and started to abandon their formatting eccentricities (although not entirely; they stubbornly stuck to some conventions like "no news on the front page" until the late 1960s). ‑ Iridescent 13:49, 12 September 2016 (UTC)
My quick thoughts: keep the column indication as is, but drop the day of the week. I can't find it in the MOS now, but I recall reading that we don't include the day of the week in giving dates unless it's significant to the mention of the date in prose. As for including it in citations, I don't know of any style guide that includes it either. Imzadi 1979  17:37, 12 September 2016 (UTC)
Imzadi1979's proposal is acceptable to me. It'd be a bit less work for editors using the template, and a bot run could do the removal of the parameter from existing uses of the template. Mjroots (talk) 19:11, 12 September 2016 (UTC)
I'd agree with that. I suspect that "day of the week" field stems from the fact that the Sunday Times and Times have always had different editors and different editorial lines (and in some periods, different proprietors) yet are usually archived as a single entity. The other idiosyncratic field I'd be reluctant to lose from this template is "section", because the Times is both a general newspaper and an official gazette, it's sometimes important to make it clear if we're citing general editorial content or the formal paper-of-record stuff like the Law Reports or the Court Circular. ‑ Iridescent 20:12, 12 September 2016 (UTC)
The |section= could probably be mapped to the |department= of {{cite news}}. As for the day of the week, I have a random thought based on Iridescent said above: should the uses with dates that are Sundays give |work=The Sunday Times instead of |work=The Times? If so, that would retain the distinction while dropping the day of the week from date. Imzadi 1979  22:19, 12 September 2016 (UTC)
In late 2014, I made {{Cite newspaper The Times/sandbox}} that pretty much adheres to Editor Imzadi1979's suggestion:
"The Queen Mary Back In Port" The Times (London). Monday, 3 January 1949. (51269), col E, p. 4. – live
"The Queen Mary Back In Port". The Times (51269). London. 3 January 1949. col E, p. 4.  – sandbox
There are differences: period after the article title; |day_of_week= is ignored; |location= (not a parameter in {{Cite newspaper The Times}}) is in a different location as is |issue=.
Trappist the monk (talk) 00:08, 13 September 2016 (UTC)
This all sounds good. Can anyone identify the uses of this template that are not using the day of the week parameter? Those will have to be checked to see if they are Sundays or not. Might also be worth looking around for other 'Sunday Times' citations elsewhere in Wikipedia and seeing if they are made distinct from 'The Times'. I am sure 'cite newspaper' has had this problem in the past with other newspapers with weekend editions. PS. I think the numbers are stable now - 1,274 for the column parameter and 2,935 for the day of the week parameter. Another check in a day or so should confirm that. Carcharoth (talk) 06:11, 13 September 2016 (UTC)
Re the Sunday Times, wouldn't it be simpler to create a separate template for that newspaper? Mjroots (talk) 07:55, 13 September 2016 (UTC)
Not necessarily. We can do something like this addition to the sandbox:
|newspaper={{#ifeq:{{{day_of_week|}}}|Sunday|Sunday Times|Times}}
which would do this:
"Steamer lost off The Lizard" The Times (London). Sunday, 6 December 1914. (40718), col E, p. 4. – live
"Steamer lost off The Lizard". The Times (40718). London. 6 December 1914. col E, p. 4.  – sandbox
If this is not a good way to distinguish the Sunday edition, then yeah, a separate template will answer.
Trappist the monk (talk) 11:24, 13 September 2016 (UTC)
Undone per this discussion.
Trappist the monk (talk) 10:24, 17 September 2016 (UTC)
The discussion above is leaning towards the abolition of the day parameter, so a separate template would seem to be the way to go. Mjroots (talk) 09:43, 14 September 2016 (UTC)
No need for a separate template. It's what |newspaper= is for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:11, 14 September 2016 (UTC)

Moving forward[edit]

Do we have consensus to make {{Cite newspaper The Times}} a wrapper for {{Cite news}}? We could need to add |column= to the latter, and deprecate |day of the week=, unless it is set to "Sunday", in which case it would change the value of |newspaper=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 16 September 2016 (UTC)

Yes, but if and only if {{cite news}} can handle the existing "section" parameter; because parts of the Times have official status, it can be important to note whether something appeared in the Law Reports (in which case will be treated as a legal precedent under the English common law), the Court Circular (the official record of the lives of the posh) or if it was just editorial opinion. ‑ Iridescent 18:57, 16 September 2016 (UTC)
See the suggestion to use |department=, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 16 September 2016 (UTC)
I'd prefer the creation of a separate template for the Sunday Times, as there were occasions when The Times was published under that title on a Sunday. Agree that we can do away with the day of the week, but the column must stay. Mjroots (talk) 08:40, 17 September 2016 (UTC)
I have undone the change to the sandbox that used |day_of_week=Sunday to modify the paper's name. We can attend to a separate template when and if this template change is put to bed.
Trappist the monk (talk) 10:21, 17 September 2016 (UTC)
A separate template would still leave us with more, not less, to maintain. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 17 September 2016 (UTC)
The sandbox vs live with |section=Section Name:
"Article Title" (Section Name). The Times (London). Monday, 3 January 1949. (12345), col N, p. 2. – live
"Article Title". Section Name. The Times (12345). London. 3 January 1949. col N, p. 2.  – sandbox
Trappist the monk (talk) 10:21, 17 September 2016 (UTC)

Improving HTML citation element semantics[edit]

Cite[edit]

Given the following wiki markup as example:

{{Cite web |url=https://support.apple.com/en-us/HT202944 |title=TCP and UDP ports used by Apple software products |date=2014-11-08 |website=Apple Support |publication-date=2016-02-05 |archive-url=https://web.archive.org/web/20160913023842/https://support.apple.com/en-us/HT202944 |archive-date=2016-09-13 |dead-url=no |access-date=2016-09-13}}

produces output similar to this:

<cite class="citation web"><a rel="nofollow" class="external text" href="https://support.apple.com/en-us/HT202944">"TCP and UDP ports used by Apple software products"</a>. <i>Apple Support</i> (published 2016-02-05). 2014-11-08. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160913023842/https://support.apple.com/en-us/HT202944">Archived</a> from the original on 2016-09-13<span class="reference-accessdate">. Retrieved <span class="nowrap">2016-09-13</span></span>.</cite>

My concern is that the HTML citation element (<cite>) is wrapped around the whole template. The WHATWG HTML Standard says in section 4.5.6 that A person's name is not the title of a work and and the element must therefore not be used to mark up people's names. Further examples are given in that section for correct usage according to that specification. HTML5 specification published by W3C (which was developed by WHATWG, but later diverged by W3C) allows using a name as a citation, but I believe the examples given mostly point at the direction of giving a very specific citation based on work name (in our case, |title=).

The correct output should look something like this (untested, I mind you):

<p class="citation web"><a rel="nofollow" class="external text" href="https://support.apple.com/en-us/HT202944">"<cite>TCP and UDP ports used by Apple software products</cite>"</a>. <i>Apple Support</i> (published 2016-02-05). 2014-11-08. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160913023842/https://support.apple.com/en-us/HT202944">Archived</a> from the original on 2016-09-13<span class="reference-accessdate">. Retrieved <span class="nowrap">2016-09-13</span></p>.

Time[edit]

It may be a good idea to change the <span> for dates to <time> element as well, for further improving the semantics. I also question if the quotation marks " need to be around the <cite> element, as if they are only for visual appearance then they should be added in CSS.

My view is biased towards WHATWG as the current status of HTML as the right thing to do, because updating to the WHATWG specification would satisfy requirements of both W3C's HTML5 and WHATWG's HTML standard. The current template does not allow satisfying HTML standard requirements.

References[edit]

Not quite so relevant citations

80.221.159.67 (talk) 11:50, 13 September 2016 (UTC)

Discussion[edit]

We changed cite deliberately to use cite per Help_talk:Citation_Style_1/Archive_8#HTML5 bait-and-switch: The cite element again. Please review that discussion. --Izno (talk) 12:40, 13 September 2016 (UTC)

And the discussion linked therein at MediaWiki_talk:Common.css/Archive_17#The_cite_element_needs_to_not_auto-italicize_any_longer. --Izno (talk) 12:43, 13 September 2016 (UTC)
And finally, the actual implementation discussion at Help_talk:Citation_Style_1/Archive_9#<cite> has been fixed, so we can now use it for entire citation. --Izno (talk) 12:46, 13 September 2016 (UTC)

Regarding the styling (issue with quotation marks), we have already defaulted the use of cite to not-italicize based on the issue that sometimes the citation provides only work vice work and sub-section title. Long works use italics while sub-work-level usually use quotation marks. So I believe there would not be consensus (even if it made sense to change our use of cite, which it doesn't) to change those points of styling in CSS. No comment regarding the use of the time element. --Izno (talk) 12:57, 13 September 2016 (UTC)

Time discussion[edit]

The point about <time> seems well made. Can we do that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:44, 16 September 2016 (UTC)

Reading up on the spec for the time element, we would need to be careful with this, such that the datetime= attribute is both supplied and valid (it expects all-numeric dates), for example <time datetime=2016-09-16>16 September 2016</time>. If we don't validate that attribute, it would need to be omitted, and the enclosed date would then need to be all-numeric, i.e. <time>2016-09-16</time> would be valid, but <time>16 September 2016</time> would not. --Redrose64 (talk) 20:19, 16 September 2016 (UTC)
I would be concerned about adding a such tag for a non-Gregorian date given that the input is ISO8601-like and thus does not provide for calendar model. But any date after 1923 should certainly get it. The dates aren't technically all-numeric, for sub-date information, but that's mostly a non-issue.
I would apply this to all dates in the citation templates. --Izno (talk) 20:29, 16 September 2016 (UTC)
According to https://www.w3.org/TR/html5/infrastructure.html#dates-and-times "To unambiguously identify a moment in time prior to the introduction of the Gregorian calendar (insofar as moments in time before the formation of UTC can be unambiguously identified), the date has to be first converted to the Gregorian calendar from the calendar in use at the time (e.g. from the Julian calendar). The date of Nero's birth is the 15th of December 37, in the Julian Calendar, which is the 13th of December 37 in the proleptic Gregorian calendar." Wikipedia uses the date that appears on the publication itself, which may very well be non-Gregorian. So either we forget about this <time> thing altogether, or we have to examine the date to see if it is a plausible Gregorian date (rather than, say, an Islamic calendar) and then make sure it is no earlier than 1923. Jc3s5h (talk) 20:37, 16 September 2016 (UTC)
I think we can start with a limited rollout for all dates after 1923 since this will be the vast majority of dates anyway, unless there's some calendar in use presently which had years greater than 1923 in the Gregorian year 1923. --Izno (talk) 20:49, 16 September 2016 (UTC)
I would think the first test is to see if the entire date string can be successfully parsed as a machine readable date. I imagine "Summer 2015" would fail this, even though it is a valid Wikipedia publication date. This should also screen out dates that have some notation of a non-Gregorian calendar, something like "Japanese year 2015". Then check if the year is greater than 1923 and not ridiculously far in the future. If you try too hard to extract a date from a bunch of junk, you are likely to find out that what you treated as junk was actually a warning that the date doesn't mean what you think it means. Jc3s5h (talk) 21:27, 16 September 2016 (UTC)
phab:T34545 is still open, but its parent task phab:T25932 says the tag is implemented. Looks like Danny B noticed that on the child task and asked the question awhile ago without answer. My browser seems to think that the tags emitted above are supported in the wikitext, so I'll probably go close the child. --Izno (talk) 20:49, 16 September 2016 (UTC)

Any updates on adding open access links to references?[edit]

For simplicity's sake, I suggest we implement the coloured version of the locks, with |access= (paired for whatever link is in |url=) and |id-access= to append locks after the identifiers (replace 'id' with 'bibcode'/'doi'/etc.). We can then refine the behaviour later after we see what issues come up. Headbomb {talk / contribs / physics / books} 14:27, 14 September 2016 (UTC)

I totally agree! I think that's what is currently implemented in the sandbox (but only for id=doi, not for the others). We are ready to submit OAbot to WP:BAG and we can discuss there which icons we want the bot to add (if the current implementation is pushed to live, otherwise there is no discussion to have about that as the bot would not have any option to display the status of the links it adds). − Pintoch (talk) 21:27, 14 September 2016 (UTC)
I also agree that the colored versions are more intuitive and also more consistent with usage outside of Wikimedia. OAbot can do some pretty nifty work, so I think the current implementation is definitely "good enough" to get started with, and as noted above doesn't prevent us from tweaking icons in the future as we progress, get feedback, and learn. Cheers, Jake Ocaasi (WMF) (talk) 22:27, 14 September 2016 (UTC)
Colored versions of the lock are only more intuitive if you as a reader have color sight. For those who don't, the color is more-or-less meaningless; perhaps slightly differing shades of gray. As before, I remain opposed to implementing colored versions of the various locks.
As before, I remain opposed to highlighting the norm. Because named identifiers typically require registration or payment, we should not be adding closed-lock icons to those links. Throughout all of Wikipedia, links in |url= typically link to a readable source; we should not be highlighting those by adding open-lock icons.
I am not opposed to including lock icons in rendered citations where their use is appropriate, distinguishable in color and gray-scale against white or black background, and constrained in their application.
Trappist the monk (talk) 11:27, 15 September 2016 (UTC)
They are more intuitive, and those with color blindness can still tell them apart by different shapes. Let's implement them, and if we can find a better way of showing this, then we'll refine. We're not saying ignore the 1% here, but to deny the 99% easier access because the information is conveyed in one extra way that the 1% doesn't have access to is silly.Headbomb {talk / contribs / physics / books} 17:36, 15 September 2016 (UTC)
OK. I will not write again here my arguments against your decision to forbid certain locks at certain places as they have not changed either. Are there any chances the change could still be implemented if you acknowledge that there is a consensus for it, or is your own position a definitive veto against it? All I want is to know when to submit the bot for approval: in the first case, we'll try to reach that consensus, in the latter, I'll submit the bot without waiting for CS1 to change. (I am only concerned about which parameters are allowed - the pictures do not have any influence on how the bot should work.) − Pintoch (talk) 17:18, 15 September 2016 (UTC)
Do not put words into my mouth that I have not spoken. I have not ever said that I forbid certain locks, nor have I said that I will veto changes that I do not support. You know that I do not have that power here.
Trappist the monk (talk) 09:51, 16 September 2016 (UTC)
I can see my comment sounded rude. Please accept my apologies, I am still not familiar with the power structures here (as an admin you do control what gets into the live module, right?). − Pintoch (talk) 10:53, 16 September 2016 (UTC)
No. I do not have that power. Any admin can can be the boatman who conveys changes across the cascading protection (our River Styx). Neither they, nor I control what gets into the live module.
Trappist the monk (talk) 11:47, 16 September 2016 (UTC)
Trappist's concerns are legitimate and I will comment that he is not the only one who holds them. "A consensus" does not seem to exist with such firmness as you think, and I suspect that an RFC would likely resolve in Trappist's favor on those points. --Izno (talk) 17:28, 15 September 2016 (UTC)
Fine! I thought most editors agreed on the mockup that I followed for my implementation in the sandbox (hence the "consensus"). Trappist was the only one to voice his concerns about this issue after my implementation. Good to see others finally chiming in! I just need the discussion to actually take place, because this detail is holding us back on another front, and I'm happy to see any decision taken about this. I hope this is clearer. − Pintoch (talk) 19:55, 15 September 2016 (UTC)
Let's implement the technicalities, and we'll work out the best practices. I'm not super thrilled about plastering |access=free myself, mostly because the url SHOULD be free by default. If it's not free, then the link adds nothing over |doi=, and should be removed. So the only time you really need to flag anything is if it's not free, and no id/doi are present. Likewise, DOIs should be closed by default, and we flag the free ones (with automated links when that is the case).
So that could mean only allowing |access=subscription/registration/ignoring |access=free and allowing |doi-access=free/ignoring |doi-access=subscription/registration. 17:45, 15 September 2016 (UTC)
They appear to have been refuted; and accessibility guidelines (our own, and the W3C's) suggest not relying on colour alone to distinguish items; they do not deprecate its use at all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:20, 15 September 2016 (UTC)
I join others above in expressing doubts that there is sufficient consensus for the proposals as they stand. Both the icons to be used and the circumstances of their use have been debated and changed back and forth several times. There should be a clear proposal, or a clear small set of alternative proposals, and then a much wider RfC. Nothing less will be satisfactory for a change with such a significant visual impact all over Wikipedia. Peter coxhead (talk) 19:43, 15 September 2016 (UTC)
Let me join in the chorus of people here who are skeptical about this proposal. It cluttters up the citations, is not always easy to define (is a site that limits you to a certain number of downloads per month open access? is a link that works when you follow it from a specific other link, but not when you copy and paste the same url into Wikipedia, open access?), is about a specific link rather than the whole citation but is proposed to be parameterized and displayed in a way that does not indicate which links are open and which are not (the same paper can be open access through one access method and not open access through another), and is of dubious value to most readers. We can continue to discuss it and mock things up, of course, but I remain unpersuaded. Just because we can do something doesn't mean we should. —David Eppstein (talk) 20:03, 15 September 2016 (UTC)
The locks would apply to the links provided. doi:10.1234/whatever may sometimes resolve to different places, but never one that's open access and another that isn't. The lock on that doi would reflect the state of that link. We might need some more discussion, but right now what I'm proposing, and that I think is likely to be agreed on, is that |url= link shows when they ARENT free, while identifier links shows when they ARE free. But let's at least have a working sandbox version so we can debate and tweak behaviour as needed. And then we can RfC for deployment or something.Headbomb {talk / contribs / physics / books} 20:22, 15 September 2016 (UTC)
Re the different potential expansions of a doi never having different open-access statuses: [citation needed]. And what do you propose to do with links like the ones generated by {{MR}} that already give you useful information when accessed openly but give enhanced information to subscribers? —David Eppstein (talk) 22:15, 15 September 2016 (UTC)
Re doi: You can't prove a negative, and you know that. But I do citation cleanup like few people do, and I have never once ran into a doi that resolves to both an open and a closed access provider. That's because articles are either openly licensed, in which case they will be openly licensed to both providers, or they aren't, in which case neither providers will provide it.
Re MR: MR is closed/subscription based, and non-subscribers do not have access to the review. The options available are, mark it locked (which I think is unecessary/overkill, but others might differ), or do like we do now (which I think is the best behaviour, but again others might differ) and leave the MR link plain.
Re clutter: The locks are certainly better than Smith, J. (2016). "Article of things". Journal of Things. 1 (2): 3. doi:10.1234/whatever. (subscription required (help)).  as far as reducing clutter go (and have the added benefit of applying to the link, rather than to the citation).Headbomb {talk / contribs / physics / books} 22:48, 15 September 2016 (UTC)
I have to go along with Headbomb, that we need a fully functional sandbox version so that we can compare the output with the existing templates to see what works best. Keith D (talk) 23:04, 15 September 2016 (UTC)

I have changed the sandbox to forbid |access=free and |doi-access=subscription. Intermediate access levels are currently allowed on both |access= and |doi-access= (but it's straightforward to change). |id-access= is not implemented for other ids. I can add them if you think that it would ease the discussion (but as far as I can tell they would work just like |doi-access=, right?). So I believe the sandbox is functional now. − Pintoch (talk) 06:15, 16 September 2016 (UTC)

The identifiers that need to be flagged would behave like that, yes. However, some are always free (arxiv, biorxiv [see above discussion], rfc, pmc, and possibly others) while others are always closed (mr, possibly others) and for others it's just irrelevant (asin, lccn, issn, isbn, oclc, ol) so we don't need to have an |arxiv-access=/|mr-access=/|asin-access= parameters. Only those that vary would need to have an access-parameter. Of the identifiers we support, I'm not sure of jstor, jfm, osti, ssrn, zbl as well as the proposed citeseerx support. I know bibcode/doi vary, I think citeseerx/jstor vary as well, but that jfm/zbl are always non-free and osti/ssrn are always free. But that's something that needs to be verified. Headbomb {talk / contribs / physics / books} 12:05, 16 September 2016 (UTC)
Perhaps this has been asked and answered: why do we need |access= when there is already |subscription= and |registration=? Are these not possibly conflicting?
Trappist the monk (talk) 09:51, 16 September 2016 (UTC)
Those should be deprecated/cleaned up by bots when the new system is rolled out. Headbomb {talk / contribs / physics / books} 12:05, 16 September 2016 (UTC)
In my opinion, the main problem with |subscription= and |registration= is that it is unclear which link they apply to (given how they are currently rendered). Here is an instance where the |url= is closed, but |subscription= adds a note just after the CiteSeerX id, which is open:
Simpson, Alex (2012). "Measure, Randomness and Sublocales". Annals of Pure and Applied Logic. 163 (11): 1642–1659. CiteSeerX: 10.1.1.220.7880. (subscription required (help)). 
It has also been pointed out that |subscription= is quite verbose. However, I agree that allowing both |access= and |subscription= is annoying. I think we should deprecate these old parameters in favor of the new system we are discussing here. It might be possible to migrate existing |subscription= and |registration= to the new system with a bot, but that could only be done in unambiguous cases. − Pintoch (talk) 10:24, 16 September 2016 (UTC)
The conflict I was thinking about was |access=subscription and |registration=yes (and vice versa). I have always taken |subscription= and |registration= to apply to |url= but I can see that the template documentation is not clear on that. If this |access= proposal is adopted, then I agree that |subscription= and |registration= should be deprecated. For the case of a single external link, either by |url= or a named identifier, a bot could replace or remove |subscription= and |registration=.
Trappist the monk (talk) 11:47, 16 September 2016 (UTC)
Concerning this conflict, should we simply raise an error in the cases you mention? About the ambiguity of |subscription= and |registration=, let me stress that a good documentation would not solve the problem: the rendered output is still ambiguous to readers, because most readers will not read the CS1 documentation. − Pintoch (talk) 13:25, 16 September 2016 (UTC)
Yes. I have done so:
"Title"A (paid) subscription is required to access this source. journal.  More than one of |url-access= and |subscription= specified (help)
"Title"A (paid) subscription is required to access this source. journal.  More than one of |url-access= and |registration= specified (help)
Trappist the monk (talk) 10:44, 17 September 2016 (UTC)

Adding different access icons and related links[edit]

Is there any reason for adding a non-free source link to a citation when there is a free one? You present a false dilemma. 72.43.99.146 (talk) 12:33, 16 September 2016 (UTC)
This will not usually be done intentionally, but right now (see #automatic url generation below), since free links are not flag/automatically linked, many people add urls even when free sources are available just so there is a link to click. But there's also the case of someone initialy adding |url=http://www.example.com |subscription=yes for something non-free, and then someone / a bot later (like a CiteSeerX bot) adding |citeseerx=123456 |citeseerx-access=free, which would create the above situation. Headbomb {talk / contribs / physics / books} 12:46, 16 September 2016 (UTC)
I would think it should be the bot writer's job to have the bot check whether a source is already verifiable online through the current citation before adding yet another link? I still don't see the logic behind having both free and non-free links. 72.43.99.146 (talk) 13:02, 16 September 2016 (UTC)
What you're proposing that is that bots remove existing urls when they add free links, and that is something very, very risky. While it'll certainly be possible to do so in some case, for most links it will be nearly impossible to confirm whether or not an existing url is freely accessible or not. Headbomb {talk / contribs / physics / books} 13:18, 16 September 2016 (UTC)
In this particular example, the free version is only a preprint that significantly differs from the published version (the URL points to that version). The url is still useful to the happy few who can jump the paywall. In general, there are many reasons why non-free URLs or identifiers are useful even when there is a free one: for instance to generate richer COinS data, or to help readers find the article in their library's database (because they like reading a paper copy, say). − Pintoch (talk) 13:25, 16 September 2016 (UTC)
What is the citation verifying? Is it a claim that is sourced at the preprint or at the peer-reviewed version? Or both? If it is on both, only the free link is required for purposes of verification. If it is in either version, the links would be mutually exclusive. 72.43.99.146 (talk) 13:47, 16 September 2016 (UTC)
The statement is always backed by the official/published version. The preprint is a link of convenience. Headbomb {talk / contribs / physics / books} 14:56, 16 September 2016 (UTC)
Whether a version is official or not is irrelevant. Does it verify the related claim in the text? Then that is the only link (and icon) necessary. It is fine to provide additional information but be mindful of the overhead. 100.33.37.109 (talk) 01:17, 17 September 2016 (UTC)
It matters very much, because if the claim didn't survive peer review, then the source doesn't support the statement it is meant to support the article needs to be revised accordingly. Headbomb {talk / contribs / physics / books} 09:08, 17 September 2016 (UTC)
A single citation cannot point to two different versions/editions/reprints.
If an article, for whatever reason, states something from a particular version, and correctly cites that version, that is all that is needed. The editor can add |edition=preprint or |edition=peer-reviewed.
If it cites something as included in one version but not another, two different citations are needed. The editor can add |edition=preprint and |edition=peer-reviewed.
If the versions are identical, either can be used. Because the point is to verify the text, by whatever means, and there is no issue of reliability here. It is the contributor's choice to include the info about the versions being identical, in article text or non-reference footnote.
If the version cited is the non-free peer-reviewed one, and the particular statement is included in both, and the preprint is free, a |url= free link comparable to the one in {{cite book}} can be used. Such links do not need to be shown as free. Their existence as |url= without an access note in the citation, suffices. Again It is the contributor's choice to include the info about the versions, in article text or non-reference footnote.
The proposed proliferation of icons and parameters unnecessarily complicates this. Imo, per the current policies and citation guidelines, there is no need for the module(s) to accomodate different icons and related links per citation, taking into account the required overhead. 72.43.99.138 (talk) 13:40, 17 September 2016 (UTC)
Simply put, you're wrong because you're conflating several different and unrelated issues. We are not citing two versions, we are citing one version, and providing a convenience link to a preprint which is most of the time accurate as far as the information goes, but lacks the polish and format of a professionally edited final version. This link is useful because preprints are free, while published versions often aren't, and if the publisher's website is down, you can still access the preprint version. If the preprint version is what is cited, then we would use {{cite arxiv}} or similar. Headbomb {talk / contribs / physics / books} 14:17, 17 September 2016 (UTC)
I did not propose that preprint-version links should not be included. The last example in my previous comment states that such links, when they are used in a citation of a non-free, peer-reviewed article, should be treated the same way similar links are treated in {{cite book}}: using the pre-existing |url= without any additional access note, which by default signifies a free link. I completely support adding free links that directly verify the citation; I just don't believe an extra icon and/or access note is required. That is also the case with free doi ids etc.: either format them as |url= instead, or eschew the url link and (if so decided) add a free-access icon to |doi=. 72.43.99.138 (talk) 14:48, 17 September 2016 (UTC)
If your objection is simply the existence and use of icons, then consensus seems to be against you. Headbomb {talk / contribs / physics / books} 20:48, 17 September 2016 (UTC)
It is not just aesthetics. It is also the added complexity and overhead in the code. The added complexity is not static. It may return with a bite any time the code has to be modified, one more thing to take into account. I don't think the payoff is worth it. 72.43.99.138 (talk) 14:28, 18 September 2016 (UTC)
Hum, are we talking here about the complexity of the code required to implement |access=, |doi-access= and the others? If so, have you had a look at the relevant changes in the sandbox? The footprint is actually very small. After a (long) deprecation period for |subscription= and |registration=, we should eventually be able to remove these parameters, which would even simplify the code a bit. I agree we have to be careful to implement it in a responsible way, but I think the current approach is quite modular and fits well with the rest of the code. If you have any specific concern about the way it is currently implemented, let's discuss it. − Pintoch (talk) 15:27, 18 September 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Code footprint is not the issue. Complexity is not a result of mass, but of relationships. The effect of which, especially when they cascade (as they will invariably do), can be difficult to gauge beforehand. I am looking at what is being gained by implementing this. To me, the gain seems borderline trivial. This is not a reflection on OAbot per se. I'm not lingering on this because I want to micromanage, delay, or be obstructive. But once something wrong is applied, it takes forever (or never) to make right. The only chance to avoid this usual Wikipedia grind (due to the slowness and fragility of consensus building) is to make sure things are right the first time. Because something obviously true in the real world may not be obvious, nor true, where "Wikipedians" are concerned. 65.88.88.127 (talk) 18:34, 18 September 2016 (UTC)

Can you pinpoint some concrete case where this proposal could interfere with other aspects of CS1? Your point seems to be applicable against any new feature. (Moreover, this is not a new feature: this is a refinement of an existing one.) I don't think the gain is marginal. If we add a |citeseerx= or |hdl= while there is already a |url=, the change will go mostly unnoticed. People don't know if these ids give access to the full text, they will just click on |url=. And again, as in the example above, changing |url= is not an option. Peer reviewing really matters. − Pintoch (talk) 19:51, 18 September 2016 (UTC)
As I mentioned, I cannot know where the new dependencies may bite in the future. I can only do the cost-benefit analysis according to the perceived benefit. Furthermore, my opinion is as non-binding as anyone's. 65.88.88.126 (talk) 15:03, 19 September 2016 (UTC)

CiteSeerX id structure[edit]

Copied from an email I got from the CiteSeerX people

Resources ingested by CiteSeerX require a unique ID, or Digital Object Identifier (DOI) that will stay the same for lifespan of the resource. DOIServer provides the means to obtain unique DOIs safely, such that once a particular DOI is issued, that DOI will never be issued again at a particular site or at other sites that use DOIServer. DOIs are of the following form:

<SITE_ID>.<DEPLOYMENT_ID>.<TYPE>.<BIN>.<RECORD>

All variables are integers and have the following semantics:

• SITE_ID: a label that uniquely identifies the site where CiteSeerX is hosted.

• DEPLOYMENT_ID: a label that uniquely identifies the particular DOIServer deployment within the site (allows safe replication of DOIServer application).

• TYPE: a label identifying the type of resource that a DOI was issued for.

• BIN: an ID space for a particular resource type, meant to bound the size of the DOI string.

• RECORD: an ID for a particular resource, with values ranging from 1–9999.

When a new DOI is issued for a particular site, deployment, and resource type, if incrementing the RECORD field would result in a value greater than 9999, the BIN value is incremented instead and the RECORD value is dropped to 1.

This should be useful for error checking. Headbomb {talk / contribs / physics / books} 21:59, 20 September 2016 (UTC)

Can your contact identify what the legitimate value-ranges for these elements are? Besides the record element, which has a defined range of 1–9999, are there similar limits to the range-size of the other elements? Are there illegal values for some or all of these elements? (0 is apparently illegal for the record element).
Trappist the monk (talk) 10:08, 21 September 2016 (UTC)
I'll ask. Headbomb {talk / contribs / physics / books} 11:45, 21 September 2016 (UTC)

Their answer

"In principle, all fields could range between 1 and 9999. If, let's say, a mirror of CiteSeerX is deployed on another site in the future, the SITE_ID may be different. Currently, the first three numbers are fixed, literally <SITE_ID>=10, DEPLOYMENT_ID=1, TYPE=1. The <BIN> could go from 1 to 9999. Currently this field only has three digits but it is increasing. Let me know if this answers your question."

So it seems that, for now, it's 10.1.1.(1-999).(1-9999). Depending on how stringent we want to be, this could be our error check, and then we'll adapt in the future when we run into issues and update to 10.1.1.(1-9999).(1-9999) or similar. Or we could anticipate the expansion, and implement 10.1.1.(1-9999).(1-9999) right off the bat to not worry about the rollover. Or we could allow the most general case of potentially valid ids with (1-9999).(1-9999).(1-9999).(1-9999).(1-9999) from the outset and never again worry about things, but I feel this would be much less useful. Headbomb {talk / contribs / physics / books} 20:42, 21 September 2016 (UTC)

Current state of the sandbox[edit]

Cite journal compare
{{ cite journal | last=Cockell | date=2007-09-29 | first=Charles S. | journal=Origins of Life and Evolution of Biospheres | issue=1 | title=The Interplanetary Exchange of Photosynthesis | volume=38 | url=http://link.springer.com/article/10.1007/s11084-007-9112-3 | pages=87–104 | url-access=subscription }}
Live Cockell, Charles S. (2007-09-29). "The Interplanetary Exchange of Photosynthesis". Origins of Life and Evolution of Biospheres. 38 (1): 87–104.  Unknown parameter |url-access= ignored (help)
Sandbox Cockell, Charles S. (2007-09-29). "The Interplanetary Exchange of Photosynthesis"A (paid) subscription is required to access this source. Origins of Life and Evolution of Biospheres. 38 (1): 87–104. 
Cite journal compare
{{ cite journal | arxiv=1412.8548 | journal=Electronic Proceedings in Theoretical Computer Science | date=2014-12-28 | doi=10.4204/EPTCS.172.23 | last1=Bar | title=A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem | first2=Jamie | first1=Krzysztof | volume=172 | last2=Vicary | pages=316–332 | doi-access=free }}
Live Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548free to read. doi:10.4204/EPTCS.172.23.  Unknown parameter |doi-access= ignored (help)
Sandbox Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548free to read. doi:10.4204/EPTCS.172.23free to read. 
Cite journal compare
{{ cite journal | date=1992-10-01 | doi=10.1139/f92-220 | last2=Bocking | first1=K. K. | doi-access=subscription | pages=1982–1989 | last1=English | first2=R. C. | url=https://www.researchgate.net/profile/James_Irvine5/publication/233865122_A_Robust_Procedure_for_Estimating_Salmon_Escapement_based_on_the_Area-Under-the-Curve_Method/links/09e4150c65bae92991000000.pdf | journal=Canadian Journal of Fisheries and Aquatic Sciences | title=A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method | first3=J. R. | last3=Irvine | volume=49 | issue=10 | url-access=free }}
Live English, K. K.; Bocking, R. C.; Irvine, J. R. (1992-10-01). "A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method" (PDF). Canadian Journal of Fisheries and Aquatic Sciences. 49 (10): 1982–1989. doi:10.1139/f92-220.  Unknown parameter |url-access= ignored (help); Unknown parameter |doi-access= ignored (help)
Sandbox English, K. K.; Bocking, R. C.; Irvine, J. R. (1992-10-01). "A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method" (PDF). Canadian Journal of Fisheries and Aquatic Sciences. 49 (10): 1982–1989. doi:10.1139/f92-220.  Invalid |url-access=free (help); Invalid |doi-access=subscription (help)

Pintoch (talk) 06:15, 16 September 2016 (UTC)

Personally, if |access/doi-access= are set to any 'valid' access options (free/registration/subscription), I wouldn't output error messages for the options we disallow. Those would act as a sort of edit-window comment of "yeah, I've actually checked this link, and it is freely accessible" / "yeah I've checked this doi, and it isn't freely accessible". Error messages should, IMO, only be displayed if |access/doi-access= is set to something like "24$" or "Smith 2005 et al.". Headbomb {talk / contribs / physics / books} 07:56, 16 September 2016 (UTC)
However, maybe we'll want to give the option of having the locks displayed, and make it a guideline (but not a hard rule) that those are best omitted in the instances where the url is free, and that the doi is not. Headbomb {talk / contribs / physics / books} 08:03, 16 September 2016 (UTC)
I agree with both comments. − Pintoch (talk) 08:12, 16 September 2016 (UTC)
Oppose the latter as highlighting the norm, and the former because excessive use becomes just so much clutter in the wikitext. If there is a need for a note in a reference, such notes can and should be enclosed in <!-- hidden comments -->.
Trappist the monk (talk) 09:51, 16 September 2016 (UTC)
I fail to see how |url=http://www.example.com<!-- Open access link --> reduces clutter when compared to say, |url=http://www.example.com |access=free. However, I'm not sure exactly to what you are referring to with 'former' and 'later'. Headbomb {talk / contribs / physics / books} 10:38, 16 September 2016 (UTC)
|url=http://www.example.com<!-- Open access link --> and |access=free are just two forms of highlighting-the-norm. My statement was qualified: If there is a need .... The need to highlight the norm should be rare and because of rarity, html comments suffice.
You made two posts: the former and the latter.
Trappist the monk (talk) 11:23, 16 September 2016 (UTC)

Automatic url generation[edit]

In the case of the free doi (and other free ids of official versions), |url= should be automatically populated with "https://dx.doi.org/{{{doi}}}" to match the behaviour of |pmc= which automatically populates |url= with "https://www.ncbi.nlm.nih.gov/pmc/articles/PMC{{{PMC}}}". Then we can see a priority of |url= (manual) > |doi= (automatic link) > |pmc= (automatic link) to prioritize which automatically-generated url gets used (assuming |url= is empty), and also support |url=doi/pmc so we can override the priority of url-generation if needed. Might be best to wait till later to get into this however. Headbomb {talk / contribs / physics / books} 08:23, 16 September 2016 (UTC)

Assuming that |url= is automatically populated, then the id should be unlinked. Having 2 links to the same content in a single citation would be superfluous. 72.43.99.146 (talk) 12:57, 16 September 2016 (UTC)
Doing that would be extremely confusing and contrary to established practice. Headbomb {talk / contribs / physics / books} 13:45, 16 September 2016 (UTC)
Simplicity is confusing? If established practice is wrong, it should go on because it is established, I suppose. 72.43.99.146 (talk) 13:53, 16 September 2016 (UTC)
Having something like
Would be very confusing, yes. Headbomb {talk / contribs / physics / books} 14:13, 16 September 2016 (UTC)
I agree that the example above would be confusing. I would counter-propose then that |url= should be not be populated when a content id like |pmc= etc. exists. Obviously this would not apply to non-content ids like |issn= etc. 72.43.99.146 (talk) 14:31, 16 September 2016 (UTC)
Well that's against long-established practice. You're free to try and gain consensus for a different behaviour, but not 'main linking' to a free source is a pretty unlikely to pass proposal. Headbomb {talk / contribs / physics / books} 14:53, 16 September 2016 (UTC)
Re: "long-established practice": Time rights wrongs? 72.43.99.138 (talk) 13:45, 17 September 2016 (UTC)

That would be very nice indeed! But we should make sure the logic remains simple. − Pintoch (talk) 13:53, 16 September 2016 (UTC)

The logic should be fairly simple, at least as far as template users are concerned. If there's a free link (|pmc=something or |doi-access=free is specified, the template automatically makes a link. The details of what is linked when multiple free links are available would be taken care of by the template, and in most situations no one needs to do anything else except to flag the 'freeness' of the doi with |doi-access=free. But the option to override the template's preference for a certain identifier for the main link would be there if it makes sense for that article (e.g. on medical articles, it may be that a link through pmc is preferable to a link through doi, in which case, you could just add |url=pmc or something to that nature). Headbomb {talk / contribs / physics / books} 14:20, 16 September 2016 (UTC)
Astonishing. For once, the IP editor and I are in agreement. I caught hell from editors at WP:MED when I removed the automatic title linking when |pmc= is set. I thought then that such linking was redundant and now that the PMC link is marked with a free-to-read icon, think that such auto-linking is doubly redundant.
I don't think that we should overload parameters. If an editor wants to override the current PMC auto-linking of |title=, they provide a url in |url=. Doing it that way relieves the template of the need to prioritize one free-to-read named identifier over another. I don't think that the templates should be in the prioritizing business.
Trappist the monk (talk) 11:28, 18 September 2016 (UTC)
Except this creates issues in print, because you'd have something like Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". (https://dx.doi.org/10.4204%2FEPTCS.172.23) Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548 Free-to-read lock 75.svg. doi:10.4204/EPTCS.172.23 Free-to-read lock 75.svg. showing up. Autolinking solves that and reduces edit window clutter from unnecessary urls and accessdates. Headbomb {talk / contribs / physics / books} 12:18, 18 September 2016 (UTC)

Which identifiers?[edit]

Identifier Full text access? Template Examples Decision
|arxiv= Always {{arxiv}} arXiv:1412.8548 Always append free to read
|biorxiv= (?) Always {{biorxiv}} bioRxiv 047720 Always append free to read
|citeseerx= (?) Always {{citeseerx}} CiteSeerX: 10.1.1.220.7880 Always append free to read
|pmc= Always {{PMC}} PMC 50050 Always append free to read
|rfc= Always {{IETF-RFC}} RFC 125 Always append free to read
|ssrn= Always {{SSRN}} SSRN 871210 Always append free to read
|bibcode= Sometimes {{bibcode}} Bibcode1974AJ.....79..819H is free to read,
Bibcode1998ApJ...508L..81K is not
Use |bibcode-access=free
|doi= Sometimes {{doi }} doi:10.4204/EPTCS.172.23 is free to read,
doi:10.1139/f92-220 is not
Use |doi-access=free
|hdl= Sometimes {{hdl}} hdl:1808/3638 is free to read,
hdl:1893/23021 is not
Use |hdl-access=free
|jstor= Sometimes {{JSTOR}} JSTOR 10.1086/673276 is free to read,
JSTOR 123456 is not
Use |jstor-access=free
|ol= Sometimes {{OL}} OL 25894862M is free to read,
OL 5665961M is not
Use |ol-access=free
|osti= Sometimes {{OSTI}} Template:Osti[1] is free to read,
Template:Osti[2] is not
Use |osti-access=free
|asin= No {{ASIN}} ASIN B00086U61Y No icon
|isbn= No {{ISBN}} ISBN 0-7475-3269-9 No icon
|ismn= No {{ISMN}} ISMN 979-0-2600-0043-8 No icon
|issn= No {{ISSN}} ISSN 0028-0836 No icon
|jfm= No {{JFM}} JFM 54.0271.04 No icon
|lccn= No {{LCCN}} LCCN 89-456 No icon
|mr= No {{MR}} MR 0123456 No icon
|oclc= No {{OCLC}} OCLC 632791477 No icon
|pmid= No* {{PMID}} PMID 123456 No icon
|zbl= No {{zbl}} Zbl 06626752 No icon
* If it's free, it will have both a PMID and PMC. PMID technically provides a link to a freely-accessible version, but it's the PMC version. So for purpose of displaying the free icon, it should be on the PMC, and not on the PMID, since the PMID link would point to the PMC version anyway.


I propose we build a table summarizing the status of all identifiers currently supported by CS1 with regard to these free to read icons. Feel free to edit it directly. − Pintoch (talk) 14:22, 20 September 2016 (UTC)

@Headbomb:, I am not familiar with bibcode: does this service store any full text? It seems to me that they redirect to the publisher's version or arXiv (which should be already covered by |doi= and |arxiv=), at least in the example you give. It looks similar to |pmid= in this respect, so I am not sure an icon is useful there? − Pintoch (talk) 17:59, 20 September 2016 (UTC)
The ADSABS database (which is what the bibcode links to) does offer free full versions of many articles, although not articles with a bibcode will have a free full article. I'm not home (I'm at work, where I have access to some sources via our academic subscription), but I will be there soon. I'll find an example where there is a free version available to the public in the next hour or so, and I'll update the box accordingly. Headbomb {talk / contribs / physics / books} 18:31, 20 September 2016 (UTC)
Thanks for the examples (and other improvements to the table), it does make sense to add an icon indeed. − Pintoch (talk) 07:49, 21 September 2016 (UTC)
Somewhat relatedly, the doai project seems to be a somewhat official way of finding open-access versions of papers from their closed-access doi. For instance the doai version of the non-free doi example above links to a free pdf on the same paper, apparently in this case made available through ResearchGate. —David Eppstein (talk) 23:27, 20 September 2016 (UTC)
Yes, this is one of the sources OAbot will be pulling from. − Pintoch (talk) 07:49, 21 September 2016 (UTC)

PMC error checking adjustment[edit]

QuackGuru has edited the Help:CS1 errors page to note that |pmc= values higher than 5000000 are being issued by PubMed. See, for example:

S. Klotz; et al. (26 Aug 2016). "Ice VII from aqueous salt solutions: From a glass to a crystal with broken H-bonds". Sci Rep. 6: 32040. doi:10.1038/srep32040. PMC 5000010free to read Check |pmc= value (help). 

The above message generates an error message at this writing, because our error check for |pmc= looks for PMC IDs between 1 and 5000000 (five million). I have adjusted the sandbox code to allow for values up to 6000000 (six million):

S. Klotz; et al. (26 Aug 2016). "Ice VII from aqueous salt solutions: From a glass to a crystal with broken H-bonds". Sci Rep. 6: 32040. doi:10.1038/srep32040. PMC 5000010free to read. 

Questions or comments are welcome. – Jonesey95 (talk) 00:01, 16 September 2016 (UTC)

This doesn't need debate, just fix it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 16 September 2016 (UTC)
Unless I made a coding error, it is fixed and will be put into production at the next module update. The last module update was on 30 July 2016. We have done about eight updates per year for the last two years. – Jonesey95 (talk) 13:51, 16 September 2016 (UTC)
This is a bug fix, not a feature improvement, and therefore should be expedited. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:39, 16 September 2016 (UTC)
If you can convince a template editor/admin to make the change (hint: you shouldn't be able to based solely on Jonesey's comment, and I wouldn't implement it either), then sure, it should be expedited. But any template editor worth his salt is going to check for consensus first for this module and that you will not find. Wait, just like everyone else ever has. --Izno (talk) 15:18, 16 September 2016 (UTC)
You think there's no consensus to fix an obvious and demonstrated error? I'd have done it myself already, were the module not fully protected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:03, 16 September 2016 (UTC)
No, I think there's no consensus to fix an obvious and demonstrated error in this module. It's a subtle but distinct point. --Izno (talk) 16:07, 16 September 2016 (UTC)

Is this upper bound on the PMC identifier really worth all this trouble? Four editors have been involved in fixing it already! If such a constant needs to be updated manually that often (and generate meta discussions at the same time), it should not be treated as a constant. I would either remove the check or put a really high value like 10-15 million. I believe such a tight check brings more hassle to template maintainers than it helps editors spot wrong PMC IDs. − Pintoch (talk) 17:37, 16 September 2016 (UTC)

The check was implemented in this change from March 2014 based on Module talk:Citation/CS1/Archive 9#PMC error check needed. About 2.5 years ago, the need was for 4 million (and only 5 million due to need for space). A maintenance-free implementation might increment the return value at 1 million/2.5 years ~= an increase of 1100 per day. Otherwise, we should just leave ourselves a note to check every 2 years or so to further increment the value. --Izno (talk) 18:19, 16 September 2016 (UTC)
I think it may be valuable to keep in mind that there are currently zero articles in Category:CS1 errors: PMC. This means that there are no articles citing PMC IDs over 5000000 at this time. We do not typically expedite bug fixes to this widely used template unless they are causing havoc in article space. – Jonesey95 (talk) 04:13, 17 September 2016 (UTC)

Un-deprecate |version=[edit]

Back in 2015, the decision was made to deprecate |version= for {{cite arxiv}}. This should not have been done. The main reason against deprecation is that the majority of arxiv links with v1/v2 etc. are more or less mindlessly copy-pasted, and the person giving the link didn't mean to link to a specific version. |version= gave us the means to distinguish between the intentional linking to a specific version of a preprint, vs the accidental linking which really should just be the most up to date version of the preprint. So please restore |version= in {{cite arxiv}}. Additionally, the v1/v2 of the arxiv identifier should be hidden when people write {{cite xxx|arxiv=1001.1002v2}}. Headbomb (talk) 00:40, 18 September 2016 (UTC)

Why does that distinguishing need to happen? The deliberate user will still use the version of interest, while the ignorant user will use the version which provided him the information (which will presumably be the latest version, as you note). WP:SAYWHEREYOUGOTIT protects us regardless. --Izno (talk) 02:54, 18 September 2016 (UTC)
WP:SAYWHEREYOUGOTIT says that you should cite the version where you found the information in question, so mindless copying and pasting of the version that the editor has actually read is exactly what we want. If an editor cites version 2 and then version 3 (the latest version) changes radically to stop supporting the statement in question, omitting the version number is the wrong thing to do. |version= is redundant to |arxiv= (or its alias, |eprint=), since "v2" or whatever can easily be included in the identifier. – Jonesey95 (talk) 04:07, 18 September 2016 (UTC)
Yes, but a statement should always be backed by the latest version, and if it isn't then we should tag it with {{fails verification}} / remove the statement. That's why an explicit |version=2 means you really DID mean the second version, because the 3rd version (or later) no longer supports that fact. Likewise, the v2 of the arxiv identifier of a {{cite journal}} should be stripped because in that case the arxiv link is a convenience link, and should always link to the most up to date version. Headbomb {talk / contribs / physics / books} 10:44, 18 September 2016 (UTC)

Simplify (these guidelines)[edit]

I want to reference a YouTube video (yes I've checked notability copyright etc). This is surely a common if not one of the primary online references today? Anyway, to do this I have to take an UG course in wiki editing. The HowTo text here is a technical manual and the examples are really fragmented. Is there not a simple way to demonstrate the FULL basic use of the template and then go into detail rather than the taxonomic tree hierarchy approach that seems to be being adopted. Demonstrating the elementary use of the template is not so helpful as it only serves to encourage the poor use of the template. It's a balance. IMO this time it's way out of kilter. I'd rewrite it myself but .... maybe when I have your expertise? ;) LookingGlass (talk) 11:07, 19 September 2016 (UTC)

{frustrated} well I was shocked .. answer is that I was helpfully redirected from Template talk:Cite AV media. More chaos and dumb machineness from the redirect and merge junkies. Grrr! Help pages? The clue's in the name! LookingGlass (talk) 11:11, 19 September 2016 (UTC)
No, the clue is in the big banner at the top of this page, which says "To help centralise discussions and keep related topics together, the talk pages for all Citation Style 1 templates and modules redirect here.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 19 September 2016 (UTC)
@LookingGlass: I concur; it is quite helpful to discuss things that impact the various templates in a single place, and it gives us one page to watch to help instead of following a few dozen talk pages.

Now, to try to help answer your question, if you want to cite a video uploaded to YouTube, use the {{cite AV media}} template. Ignore for a moment that the video is on that website. Cite the author(s)/creator(s) of the video, the publication date, the title of the video, the original publisher, etc. Add |type=Video so that readers know it is a video. Include the URL to the video, and then at the very end, I would add |access-date=September 19, 2016 and |via=YouTube. This lets people where and when you accessed the video file without crediting YouTube as the original publisher, just as we wouldn't credit Google Books as the original publisher of a scanned copy of a book they merely host online. Imzadi 1979  13:17, 19 September 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Imzadi1979: Thanks for your reply, though my experience is that that a central page is not very helpful. See Staggeringly unhelpful, below. I solved the issue of the citation. As with all wikipedia editing it is very easy - once you find the code needed - doing that though takes a great deal of time. The question then arises "why am I doing this?" - why spend all this time on editing when the cognoscenti don't try to make things simple?

Bottom line: there is a line of text in the template documentation that sets out the parameters of the "template" (this label ie unhelpful I find - what we are addressing is actually a line of code) but this template description is incomplete (e.g the Via parameter is omited). The primary problem though is that descriptions of the parameters are sometimes provided in curly quotes sometimes not sometimes with sub-parameters sometimes not sometimes describing sub-parameters but not as such sometimes with curly quotes etc etc you get the point I hope. The curly quotes are a red herring. They do not form part of the "template". I would have edited the template/doumentation to clarify but .... And I would have had this discussion on that template there is the chance had been afforded. As it is anyone befuddle by similar issues is sent here and the conversation grows exponentially.

The mistake being made with the template documentation is one in my experience typically found in text written by technical experts to serve as documentation for their own subject. There is a natural tendency to assume those not familiar with our own area of expertise are simple minded. Perhaps consequently we fail to recognize fundamental semantic errors in our text, let alone more complex ones. Simply put this issue, pandemic in wiki, is driven by succumbing to the sweet temnptation of hubris - a flaw I have in abundance! Thanks again.

LookingGlass (talk) 13:35, 21 September 2016 (UTC)

Your comments regarding poor documentation would not be the first. WP:BOLD applies. :D --Izno (talk) 13:53, 21 September 2016 (UTC)

Long article titles[edit]

Do we truncate long old-timey headlines (called titles in the template) down to the first sentence? "title= Vernon Castle Dies In Airplane Fall. Killed at Fort Worth Avoiding Collision That Threatened Lives of Three. Won Captaincy At Front. Numerous Deaths In Training Call Attention to the Need of Skilled Inspectors. Castle's Spectacular Feats. Skilled Inspectors Needed. Vernon Castle's Career. Starred on the Stage" --Richard Arthur Norton (1958- ) (talk) 23:06, 19 September 2016 (UTC)

That kinda seems like a inline TOC. Do you have the original copy of that article somewhere so we can review it? Headbomb {talk / contribs / physics / books} 23:13, 19 September 2016 (UTC)
After searching, it really does look like that's the full title. I'd quote it in full personally, but if someone only kept it to 'Vernon Castle Dies In Airplane Fall' I wouldn't revert either. Headbomb {talk / contribs / physics / books} 23:20, 19 September 2016 (UTC)
We've run into something similar citing specific older laws in California that made changes to the state's highway system. In those cases, we used only the first X words/Y characters and truncated the titles. Another example comes from citing social media postings. Since they lack a separate headline, most style guides use the text of the posting or tweet as the title, and they advise truncating overly long items, usually to a 40-word incipit. Imzadi 1979  23:29, 19 September 2016 (UTC)
Chicago Manual of Style (14th ed., p. 15.115) agrees with shortening titles of old works with excessively long titles. Jc3s5h (talk) 00:06, 20 September 2016 (UTC)
Sounds like the titles of Papal Bulls - typically truncated to the first two or three words. --Redrose64 (talk) 12:30, 20 September 2016 (UTC)
For English literature from about the 16th century (e.g. Shakespeare) up until somewhere in the 18th century (e.g. Johnson) the style was to use big ponderous titles that double as a sales pitch. This looks really awkward to modern readers who are used the sales pitch being rendered devoit of actual meaning and condensed down into three to five words (in big ponderous fonts and high-contrast colours, usually accompanied by an overproduced cover design). However, these are actually the titles of the works, and any shortening edges into WP:OR territory (mostly won't matter at all, but it demands care). I think the guidance in the context of citation templates should be to use the full title (however awkward it may look to modern readers), and that any abbreviation needs careful consideration. If the resulting issues (which, again, mainly boil down to dissonance for readers unused to the long titles) are considered severe enough, the place to try to address it would be at the MoS, where additional guidance (such as: abbreviations should be supported by reliable sources, and explained in text; or whatever) can be included that would be somewhat out of scope for the CS1 context. And personally, I would advocate weak guidance to use full titles but to leave room for individual editors' judgement and local consensus for an article (and, where applicable, WikiProject).
But to give a counter-example: Shakespeare's plays have short to medium length titles (e.g. A most pleasant and excellent conceited comedy, of Sir John Falstaffe, and the merry wiues of Windsor.) which have effectively universally agreed shortened titles that our reliable sources use (and often also discuss directly); to wit: The Merry Wives of Windsor. For these there is very little sense in using the ponderous title in the citations (in the text it needs to be discussed, but for different reasons). Shakespeare also provides the counter-counter-example: since the modern short names are later abbreviations, there is some times actual scholarly discussion over which part of the long title should form the short title (to construct an example on the fly: should it be Merry Wives or Sir John Falstaff? There are actual examples of this that I can't be arsed to dig up right now, incidentally.) Picking a particular short title can (and I stress, can, not will) end up privileging the position of The Oxford Shakespeare over the Arden Shakespeare in violation of WP:NPOV (WP:DUE). --Xover (talk) 09:48, 21 September 2016 (UTC)
  • You can almost write a whole biography from just the article title. I suppose you can use the first sentence in the title and the rest add to the quote= section. That way you do not end up with a sea of blue. --Richard Arthur Norton (1958- ) (talk) 01:24, 20 September 2016 (UTC)

End time parameter[edit]

There exists a "time" parameter for this template, but it is used only to denote the start time. Is there nothing to denote the end time? Kailash29792 (talk) 12:14, 20 September 2016 (UTC)

Not specifically. The time parameters are |minutes=, |time= and |time-caption=. The output rendering for |minutes= is fixed:
Title. 4:30 minutes in. 
as is the plain |time=:
Title. Event occurs at 4:30. 
but the |time= rendering can be overridden with |time-caption=:
{{cite av media |title=Title |time=4:30 and 4:45 |time-caption=Between}}
Title. Between 4:30 and 4:45. 
or:
{{cite av media |title=Title |time=4:45 |time-caption=Ends at}}
Title. Ends at 4:45. 
Trappist the monk (talk) 09:31, 21 September 2016 (UTC)
For segments of a longer video; would not |start-time= combined with either |duration= xor |end-time= make sense? It appears intuitively so to me, but I hadn't really thought about it. --Xover (talk) 09:53, 21 September 2016 (UTC)

Staggeringly unhelpfull[edit]

With an arrogance all too customary of wikipedia, User:Huntster reverted my edit without troubling even to notify me. (thanks robot?) The Edit summary given (I should be thankful for small mercies) said simply:

keep discussion on the centralised page. Explanation has been given there.  

Truly sublime! Currently that/this page runs to over 26,000 words. There are 23 pages shown of its archive.

This is the comment that s/he reverted on the redirect's Talk page:

== WHY?!?!?! ==
I want to raise an issue with this page.  So wt* is the purpose of a redirect to a general Talk page that covers ...... ALL the citation1 pages ?!?!?!?!!!  Words fail. Sincerely. If you need more explanation I can't imagine any could ever suffice. LookingGlass (talk) 11:15, 19 September 2016 (UTC)

Irony^2 ??

Needless (?) to say (see above) I am not watching this page, but, if relevant .. address me? Thanks. I haven't troubled Hunster with this, again, for reasons that should be self-explanatory (to anyone who stumbles across this message in a bottle).

LookingGlass (talk) 13:06, 21 September 2016 (UTC)

As the above notice indicates, and to which you have been pointed prior by Pigsonthewing: To help centralise discussions and keep related topics together, the talk pages for all Citation Style 1 templates and modules redirect here. A list of those talk pages and their historical archives can be found at Help talk:Citation Style 1/Centralized discussions. It seems quite self-explanatory why you were reverted as a result. If you would like to change the practice of centralizing these talk pages, you should start a discussion, since you have been reverted. Be forewarned that I doubt anyone else will support your position in a change request discussion. --Izno (talk) 13:43, 21 September 2016 (UTC)
LookingGlass, adding text to a redirect page will always be reverted if it is noticed. – Jonesey95 (talk) 14:30, 21 September 2016 (UTC)
Thanks Jonesey95 (and Izno), the sublime pointlessness of attempting to engage with wiki's Kafkaesque controllers doesn't escape me, yet nonetheless sometimes I succumb. Dialogues of the deaf. Messages in bottles. Peace out LookingGlass (talk) 18:49, 27 September 2016 (UTC)

Date format flexibility or error message suppression in Cite templates[edit]

More flexibility in the date parameter of {{cite}} templates is needed. See David Biespiel as of 18:22, 22 September 2016, which includes a reference to a two-week issue of The New Yorker, entered as:

  • {{cite magazine |title=Want to understand the jihadis? Read their poetry. |author=Robyn Creswell |author2=Bernard Haykel |magazine=The New Yorker |date=June 8 & 15, 2015 |url=http://www.newyorker.com/magazine/2015/06/08/battle-lines-jihad-creswell-and-haykel}}

which displays with a spurious date error message:

The New Yorker web page says that the article appeared in the "June 8 & 15, 2015 Issue", so the date is correct. There should be a way of suppressing the error message. — Anomalocaris (talk) 23:27, 22 September 2016 (UTC)

The New Yorker just has to be different, don't they? You could put that information in |issue= as a workaround, with |date=2015 as a placeholder for the date. Or you could just call it June 8, 2015, which is what they do in their own URL: the URL for the article contains the string "/2015/06/08/", not "/2015/06/08&15/" – this is a tip-off that they know they are just being precious. – Jonesey95 (talk) 03:44, 23 September 2016 (UTC)
Closed ranges are allowed in |date=, so you could use "June 8–15, 2015":
Not quite right, I know, but possibly acceptable. Peter coxhead (talk) 09:51, 23 September 2016 (UTC)
Jonesey's suggestion renders like so, for comparison:
Robyn Creswell; Bernard Haykel (2015). "Want to understand the jihadis? Read their poetry.". The New Yorker. No. June 8 & 15, 2015. 
Not much better. Edition might also work:
Robyn Creswell; Bernard Haykel (2015). "Want to understand the jihadis? Read their poetry.". The New Yorker (June 8 & 15, 2015 ed.). 
--Izno (talk) 12:44, 23 September 2016 (UTC)

Maybe a new parameter could tell the module to output a different character separate a date range, e.g. |date=June 8–15, 2015|range-symbol=& – so an ampersand could be displayed for the above above, or a / could be used when the source uses it (as in "June/July") - Evad37 [talk] 14:41, 23 September 2016 (UTC)

I don't think that is needed. The double issue can be uniquely identified by the date of publication, which is June 8, 2016. This is when it became generally available, and that is sufficient for purposes of discovery. To remove any doubts or to be completist, |issue= can also be used; however that is not imo strictly needed for verification. I usually do this:
Robyn Creswell; Bernard Haykel (June 8, 2016). "Want to understand the jihadis? Read their poetry.". The New Yorker. No. [n1–n2] (double issue). 
72.43.99.138 (talk) 16:19, 23 September 2016 (UTC)
To add, if the issue numbers are not available, the mysterious everyman-parameter |type= can be used:
Robyn Creswell; Bernard Haykel (June 8–15, 2016). "Want to understand the jihadis? Read their poetry.". The New Yorker (double issue). 
72.43.99.138 (talk) 16:25, 23 September 2016 (UTC)
To reply to Evad37 above, but "June/July" would not be in keeping with our MOS, and it should be switched to an en dash. That's the sort of minimal change traditionally allowed. We don't have to faithfully copy every exact detail from a source into a citation. Imzadi 1979  20:59, 23 September 2016 (UTC)

Various workarounds have been suggested, but none of them recognize the fundamental issue. Sometimes articles are published in parts, with each part in a separate issue. It's possible, but less common, for the parts to not be in consecutive issues. So just it is possible to list pages as 18–9, 25, 36–9, it should be possible to list several publication dates. Jc3s5h (talk) 19:56, 23 September 2016 (UTC)

In the case of articles that are part of multi-part series published periodically, I would cite each part of the series as a separate article instead of trying to collapse them into a single citation. The overall title of the series can be noted in |department=. Imzadi 1979  20:56, 23 September 2016 (UTC)
@Jc3s5h: That would be way too cumbersome, as a single citation would have to denote: several dates, several issue numbers, and several page numbers. This is hampering discovery of the source and verification of the cited claims. One citation per issue, please. If the parameter |series= is available then it could be set as |series=part x [of y] or similar. Then all the related citations can occupy a sublist within the "References" listing. 184.75.21.30 (talk) 23:45, 23 September 2016 (UTC)

CiteSeerX support[edit]

It's been discussed all over the place, but I can't find any effort to actually implement it. We should have add the |citeseerx= parameter giving

Headbomb {talk / contribs / physics / books} 14:34, 23 September 2016 (UTC)

This edit was made; while I am agreeable to the lower-cased version, I could find nothing to indicate that CiteSeerX is every uppercased in its entirety. I would possibly support |CiteSeerX=. --Izno (talk) 19:05, 23 September 2016 (UTC)
Parameters are traditionally all lowercase, but they display 'normally', hence why |arxiv=1001.1234 yields arXiv:1001.1234. I suppose we could do |citeseerx=10.1.1.220.7880CiteSeerX: 10.1.1.220.7880free to read, but I've got no strong feelings here. Headbomb {talk / contribs / physics / books} 19:13, 23 September 2016 (UTC)
Oh, you're referring to the parameter name itself? There's been some movement to support ALLCAPS version of those for a while. It's annoying, but I guess this is just consistency with the other parameters. Headbomb {talk / contribs / physics / books} 19:17, 23 September 2016 (UTC)
It should work now.
Let me add support for |CiteSeerX=. − Pintoch (talk) 19:46, 23 September 2016 (UTC)

All caps for not-all-caps identifiers[edit]

Hum, actually |arXiv= is not supported, and it seems to me that identifiers tend to be lowercase or ALLCAPS only, so maybe it would be better to keep only |citeseerx= and |CITESEERX= for uniformity. − Pintoch (talk) 19:49, 23 September 2016 (UTC)
The parameters with all caps variants are only all caps because they are abbreviations. CiteSeerX is not. I suppose CSX is, but does that occur in the wild? --Izno (talk) 21:48, 23 September 2016 (UTC)
I have removed CITESEERX (leaving citeseerx) from the Whitelist sandbox page because the name is not an initialism or acronym. DOI, ISBN, and others are allowed in all caps because they are initialisms or acronyms. – Jonesey95 (talk) 05:33, 24 September 2016 (UTC)
The caps are there for pretty much all identifiers though, even those that aren't initialisms or acronyms (e.g. |ARXIV=, |BIBCODE=), etc... I've restored it for consistency with the current behaviour. We should, however, add |arXiv=/|bioRxiv=/|CiteSeerX=. Headbomb {talk / contribs / physics / books} 06:40, 24 September 2016 (UTC)
When adding or removing parameters, don't forget to update both the configuration and whitelist. − Pintoch (talk) 07:28, 24 September 2016 (UTC)
So, consistency is not necessarily desirable here. Even if it were, let's talk about having all-caps versions of identifiers which are never used as acronyms. You point out that there are presently identifiers which shouldn't be all caps, because they aren't so outside Wikipedia I presume. As it happens, BIBCODE isn't used in the wiki-wild. I haven't checked the others, but we should deprecate that. --Izno (talk) 15:04, 24 September 2016 (UTC)
ARXIV is used some 1k times, but almost all of those are empty. Let's deprecate that also. It looks to me like ARXIV is being trans-wikied from somewhere, probably German Wikipedia. --Izno (talk) 15:06, 24 September 2016 (UTC)
I'm fine with deprecating those, but right now the sandbox is inconsistent in its logic, and that is not acceptable. Either update the sandbox version to deprecate those parameter names, or allow |CITESEERX=, but a bastardized version shouldn't be there. The caps versions should be likely replaced by |arXiv=/|bioRxiv=/|CiteSeerX=.
That being said, if the germans use all caps versions like ARXIV and CITESEERX, we should keep ours too for compatibility.Headbomb {talk / contribs / physics / books} 15:12, 24 September 2016 (UTC)
Most of the ones I saw from German were using {{citation/core}}, which was odd; it's probable that if we updated our module, we'd be fine on any transwiki points. Even if we weren't, we can add a property suggestion for those all-caps variants. Do we want to replace those all-caps versions with the properly-capitalized versions? You seem to want that. --Izno (talk) 15:27, 24 September 2016 (UTC)
All caps should be reserved for parameters that are pure initialisms, like |DOI= and |ISBN=. I recommend removing support for |BIBCODE=. I am fine with supporting mixed caps for parameters whose canonical versions use mixed caps, like |arXiv=/|bioRxiv=/|CiteSeerX=. All parameters should also support pure lower case. – Jonesey95 (talk) 18:04, 24 September 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Izno: I don't get why you keep removing |CITESEERX= from the whitelist. Either we decide to remove capitalized versions of identifiers which are not acronyms, or we decide to keep them. In the former case, there are many other changes to do, for instance |BIORXIV= should also be removed as this parameter will be introduced in the next update of the live module (so, no deprecation needed). In any case, let's try to keep the sandbox in a consistent state, which should ideally reflect a consensus here. And let's not make a mountain out of a molehill, this is about a capitalized version of a parameter in a Wikipedia template… − Pintoch (talk) 12:23, 27 September 2016 (UTC)

I haven't edited in that region since the above date (24 September). No one since has voiced disagreement that we should perhaps deprecate (or remove before release) the all-caps versions of the parameters which are not acronyms, so I was planning to implement that apparent consensus at some point in the near future (today?). Feel free to implement that consensus yourself if you would like. --Izno (talk) 12:26, 27 September 2016 (UTC)
Yeah, I just saw your edits today, so I did not respond earlier. Please go ahead with the rest of the parameters, it would be great to have a consistent sandbox. − Pintoch (talk) 12:43, 27 September 2016 (UTC)

@Headbomb, Pintoch, and Jonesey95: please review configuration edit and whitelist edit. --Izno (talk) 12:58, 27 September 2016 (UTC)

Happy with this, but should we replace the (rare) occurences of |ARXIV= in the wild by |arxiv= before the change is effective? (Could someone with AWB rights do it?) − Pintoch (talk) 13:09, 27 September 2016 (UTC)
Since the parameter is now marked as false, pages including templates with the deprecated parameter will be added to the deprecated parameters category. We should indeed remove the parameter from usage prior to removing the parameter from the whitelist completely, but we do not need to remove the parameter from use prior to release of the changeset. --Izno (talk) 13:16, 27 September 2016 (UTC)
I've seen TTM regularly work on deprecation of attributes in the wild using AWB, so yes, that is possible. --Izno (talk) 13:18, 27 September 2016 (UTC)
At least part of the edit to Module:Citation/CS1/Configuration/sandbox should be reverted. Deprecated parameters should still display as if they weren't deprecated. For example, |coauthor= is deprecated (still) but the module displays its assigned value:
{{cite book/new |author=Author |coauthor=Coauthor |ARXIV=1001.1234 |title=Title}}
Author; Coauthor. Title. arXiv:1001.1234free to read.  Cite uses deprecated parameter |ARXIV= (help)
While not a hill on which I'd care to die, I think that we should avoid mixed case parameter names even to replicate the identifier's canonical name. This is the camel's nose to supporting capitalized parameter names. We deprecated and removed |Author= and a few other similarly capitalized parameters. Let us not return to that.
Trappist the monk (talk) 13:36, 27 September 2016 (UTC)
I have made the requested edit. I personally would prefer not to have mixed case as well. Aside: Why doesn't coauthor= display an error? --Izno (talk) 13:57, 27 September 2016 (UTC)
If there is more than one deprecated parameter in a template, the module displays an error for the first one it encounters. If I remove |ARCHIVE=, then there is an error for |coauthor=:
Author; Coauthor. Title.  Cite uses deprecated parameter |coauthor= (help)
Trappist the monk (talk) 14:02, 27 September 2016 (UTC)
Yeah, let's not introduce mixed case. − Pintoch (talk) 14:11, 27 September 2016 (UTC)
@Jonesey95 and Headbomb: What do you think about leaving out the mixed-case versions? --Izno (talk) 23:01, 27 September 2016 (UTC)
OK with me. – Jonesey95 (talk) 02:43, 28 September 2016 (UTC)
Well, I don't personally care, and would personally get rid of all caps versions as well. But if the logic is that DOI/ISBN need to stay because some people will use caps for these acronyms instead of doi/isbn, the same argument can be made for mixed cases since some people will use 'correct' casing when writing arXiv/bioRxiv/CiteSeerX/Zbl. So while my personal DGAF levels are fairly high, we do need to think of newbies/user-friendliness... Headbomb {talk / contribs / physics / books} 07:42, 28 September 2016 (UTC)

Casing for compound parameters[edit]

Now appears |URL-access= purportedly for consistency. I'm not so sure about that. |URL-access=, if retained, will be the only compound parameter name that has different case on either side of the hyphen. The other 'acronym' compound parameter names, |ignore-isbn-error=, |doi-broken-date=, |dead-url=, etc, are all lower case. I think that compound parameter names should be lower case – which means that we should deprecate |ASIN-TLD= and revert the |URL-access= change.

Trappist the monk (talk) 12:36, 27 September 2016 (UTC)

Yet more intrigue. The edit was bold on my part, so I'm not attached to it here. :D --Izno (talk) 12:43, 27 September 2016 (UTC)
I agree with Trappist, I also prefer the fully lowercase version. Otherwise, if we support |URL-access=, we should also support |DOI-access=, |HDL-access= and so on… Let's keep things simple. − Pintoch (talk) 12:50, 27 September 2016 (UTC)

SSRN free access lock[edit]

Per #Which identifiers?, we should add the green free access lock to |ssrn= so we can have free to read appended to the SSRN in citations like

  • Twomey, A. (2008). "Responsible Government and the Divisibility of the Crown". Public Law (93): 742–767. SSRN 1301166. 

Headbomb {talk / contribs / physics / books} 15:07, 23 September 2016 (UTC)

Done.
  • Twomey, A. (2008). "Responsible Government and the Divisibility of the Crown". Public Law (93): 742–767. SSRN 1301166free to read. 
Pintoch (talk) 18:49, 23 September 2016 (UTC)

id-access support[edit]

Per #Which identifiers, we should support

  • |bibcode-access=yes
  • |doi-access=yes
  • |hdl-access=yes
  • |jstor-access=yes
  • |ol-access=yes
  • |osti-access=yes

To make them display green open access locks at the end of their identifier. We should also update

to also support the same |foobar-access=yes and have the green open access locks.

And then we should update

to always display the green free access locks. Headbomb {talk / contribs / physics / books} 14:50, 23 September 2016 (UTC)

After a lot of fiddling, the prototype in the sandbox should be mostly functional.
always free
id-access


And so on. Note that currently |id-access=registration and |id-access=limited are allowed, although that makes little sense given the identifiers that currently use the system. Should we only allow |id-access=free? − Pintoch (talk) 13:02, 24 September 2016 (UTC)
It might make sense to support |id-acccess=registration/limited, but if we do that, only for doi and (possibly) jstor. However, I don't see anyone, even bots actually bothering to flag those, so I'd personally be in favour of only supporting 'free' per the WP:KISS principle, but it's not a strongly-held opinion. Headbomb {talk / contribs / physics / books} 13:24, 24 September 2016 (UTC)

Free locks vs url locks[edit]

Currently, the free green locks uses Trappist's version of the lock + hover message, while the newer url-access locks use my versions of the locks + hover messages. Those should be made consistent. Headbomb {talk / contribs / physics / books} 10:03, 27 September 2016 (UTC)

More importantly, we should settle the color vs. shape vs. accessibility issue. Having attended to that, we can create a uniformly consistent set of lock images to suit.
Trappist the monk (talk) 12:42, 27 September 2016 (UTC)
We should, yes, but we should also have consistency in the initial rollout. Headbomb {talk / contribs / physics / books} 13:23, 27 September 2016 (UTC)

ISMN support[edit]

We should add |ismn= to support ISMN

  • |ismn=979-0-2600-0043-8ISMN 979-0-2600-0043-8

Headbomb {talk / contribs / physics / books} 15:06, 23 September 2016 (UTC)

Already supported:
{{cite book |title=Title |ismn=979-0-2600-0043-8}}
Title. ISMN 9790260000438. 
I notice that the rendering has stripped the hyphens. I'll fix that.
Trappist the monk (talk) 15:22, 23 September 2016 (UTC)
We should update the doc then, because ISMN isn't mentioned. Also, is there a way to auto-hyphen the ISBN/ISMN? That would be really, really nice. Headbomb {talk / contribs / physics / books} 15:49, 23 September 2016 (UTC)
Template:Cite_book#Identifiers, and every other cs1|2 template that uses {{csdoc}}, defines ISMN; has done since this edit. If you are thinking of that abomination TemplateData, perhaps it doesn't. If you want to fix that, go ahead; I will not touch it.
Trappist the monk (talk) 22:02, 23 September 2016 (UTC)
I was thinking of Help:Citation_Style_1#Identifiers. Never even was aware that Template:Citation Style documentation/id2 even existed, or that Help:Citation_Style_1 didn't make use of it. Headbomb {talk / contribs / physics / books} 22:40, 23 September 2016 (UTC)

The sfn template has a fault when the date is "n.d."[edit]

Please see the bug report at Template talk:Sfn#Fault when date is "n.d." Jc3s5h (talk) 15:48, 23 September 2016 (UTC)

For the readers here, the problem has been identified as a feature request to modify Module:Footnotes. The CS1 citations appear to be blameless (this time!). – Jonesey95 (talk) 05:35, 24 September 2016 (UTC)

Template:Cite within nominated for deletion[edit]

This TfD discussion could do with input from the citation experts crowd. The question seems to revolve around whether there is a need for a template that formats multiple locations/quotes from within a single source. Uanfala (talk) 14:02, 24 September 2016 (UTC)

url-access support[edit]

Per the above discussion, we should now implement

  • |url-access== free (A free version of this source can be accessed here)/registration (A (free) registration is required to access this source)/limited (A (free) registration is required to access this source)/trial(A (free) registration is required to access this source)/subscription (A (paid) subscription is required to access this source)

And deprecate |registration=/|subscription=

We could also

  • leave |url-access=free out
  • make |access= an alias of |url-access=

The hover text and file versions for the locks should match (mine are a bit different). Headbomb {talk / contribs / physics / books} 17:02, 24 September 2016 (UTC)

I thought that the parameter for the url was to be |access=. It is implemented to some extent but is pretty severely broken:
{{cite book/new |title=Title |url=//example.com |url-access=subscription}}
TitleA (paid) subscription is required to access this source. 
Pintoch, did you break it?
Trappist the monk (talk) 17:22, 24 September 2016 (UTC)
Oops, sorry about that. Let me investigate. − Pintoch (talk) 18:32, 24 September 2016 (UTC)
Well, it could be |access=, but then I saw the current error message so I was like... well maybe it's better to have it as |url-access=? I don't have strong feelings here, although I think it would be good to have both |access= and |url-access= as alias of each other. Headbomb {talk / contribs / physics / books} 19:07, 24 September 2016 (UTC)
@Trappist the monk: The bug was introduced when I added support for |access=, because now that the title can be wrapped inside a <span>, the following check for an empty citation triggers when there is only a title:
if string.len(text:gsub("<span[^>/]*>.-</span>", ""):gsub("%b<>","")) <= 2 then
I believe this check was introduced with the idea that all things enclosed by <span> tags were peripheral, non-essential pieces of metadata: this is not true anymore as adding |access=subscription encloses the title with a <span>. So, this check should be replaced by something simpler (should I write "cleaner"). Any idea how? What about string.len(text:gsub("%b","")) == 0? There is probably a reason why the original check was so complicated, but the test suite does not help much to understand. Concerning |url-access= vs |access=, I am happy with both, but maybe |url-access= is indeed more coherent with the |id-access= scheme. − Pintoch (talk) 19:17, 24 September 2016 (UTC)
I suspect that you're right about the <span>...</span> tags. I changed that line to use <cite>...</cite> and it seems to work. I'm not inclined to change it further until I have the time to actually think about what it is that its doing. It's from before my time, and like so much of that, undocumented.
But, since we're talking about code, can we not use camelCase? For the most part, the camelCase form is used only in calls to the Scribunto library and is the legacy form used for meta-parameter names. As long as I've been working on this code, I have tried to adopt a uniform naming convention.
Trappist the monk (talk) 19:42, 24 September 2016 (UTC)
Got it, I just changed customAccess to custom_access. − Pintoch (talk) 20:43, 24 September 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Clearly, the change I made to the code snippet above (<span>...</span> to <cite>...</cite>) was wrong. It makes no sense to look for <cite>...</cite> tags before they are added to the output. This part of the snippet:

text:gsub("<span[^>/]*>.-</span>", "")

looks for and replaces span tags with an empty string. Once that's done, this bit:

:gsub("%b<>","")

looks for and replaces other html-like markup with an empty string (anything enclosed in <...>; cs1|2 adds <q>...</q> and <b>...</b>)

I am a bit perplexed by the pattern in the first replacement:

"<span[^>/]*>.-</span>"

The pattern matches everything between the opening and closing tags and replaces the lot with nothing. So, in this case, where text has the value:

<span class="plainlinks">[//example.com ''Title'']</span><span style="margin-left:.1em">[[File:Lock-red.svg|9px|link=|A (paid) subscription is required to access this source]]</span>.

everything except the final dot is replaced by nothing. Why?

I wonder if the pattern and replacement should have been:

text:gsub("<span[^>/]*>(.-)</span>", "%1")

This captures the content and uses that as the replacement value so only the <span>...</span> tags are removed leaving the content behind:

[//example.com ''Title'']

which gives string.len() something to count besides the dot.

Except that, once upon a time, there was code that added hidden comments to the module output for debug information. Those comments were enclosed in <span>...</span> tags so apparently, the first replacement pattern was added to deal with them. It makes sense that for those hidden comment <span>...</span> tags, removal of the whole is appropriate. That form of debugging has since been removed and we are now occasionally enclosing elements of the citation in <span>...</span> tags so we should not be discarding the content of those tags in the process of doing this test.

I have reverted my edit and modified the test as described above.

Trappist the monk (talk) 11:54, 25 September 2016 (UTC)

Awesome, thanks a lot! Your new version looks much more sensible indeed. − Pintoch (talk) 13:36, 25 September 2016 (UTC)

I have changed |access= to |url-access=, given the arguments above (and also from the previous discussion):

  • The current error message (suggesting to use |access-date= instead of |access=) indicates that some editors might write |access= when they think |access-date=, so they could be confused by the new meaning of |access=
  • Using |url-access= is more consistent with the |id-access= schema
  • 'access' alone is too generic, not informative enough
  • This change underlines that the access level is tied to the |url= unlike |subscription= and |registration=.

Currently |access= is rejected (it is not an alias of |url-access=), essentially because of the first argument. − Pintoch (talk) 08:58, 27 September 2016 (UTC)

Category names. Perhaps not these: Category:Pages using citations with url-access and no URL and Category:Pages using citations with id-access and no id? For quite some time now, new error categories have been named: 'Category:CS1 errors: <something>' where <something> is a brief descriptor of the category's purpose. I might suggest: Category:CS1 errors: url-access without URL and Category:CS1 errors: id-access without id.

Trappist the monk (talk) 09:40, 27 September 2016 (UTC)

That's much better indeed, I have changed that. Actually, is it useful to keep these two categories separate? It is quite simple to merge them (we can remove the error message for |url-access= and use the one for |id-access= with id=url). It seems harder to split the one for |id-access= into specialized ones for |doi-access=, |hdl-access= and the others without adding some complexity to the Lua code. − Pintoch (talk) 13:01, 27 September 2016 (UTC)

PMC minor formatting difference when embargoed[edit]

I noticed that when a PMC is embargoed, we render a colon after "PMC", but when it is available, there is no colon. I poked through the module code and was unable to find where that happened. Here are examples of {{cite journal}} with no embargo date, an expired embargo date, and a future embargo date.

Author (2006). "Title". Journal. PMC 12345free to read. PMID 123456. 

Author (2006). "Title". Journal. PMC 12345free to read. PMID 123456. 

Author (2006). "Title". Journal. PMC: 12345. PMID 123456. 

Can someone please find that code and remove the colon from the "future date" example? I'm assuming this will be uncontroversial. Thanks. – Jonesey95 (talk) 22:26, 27 September 2016 (UTC)

it was in Module:Citation/CS1/Identifiers/sandbox:
Author (2006). "Title". Journal. PMC 12345. PMID 123456. 
Trappist the monk (talk) 22:41, 27 September 2016 (UTC)
(edit conflict) I think I found it, but I'm about to open a can of worms. It appears to be in Module:Citation/CS1/Configuration/sandbox at "local id_handlers". The can of worms has two parts:
  1. Some identifier names (e.g. arXiv and doi) are followed by a colon, and some are not (e.g. PMC and PMID).
  2. Identifier capitalization is inconsistent (e.g. ASIN and DOI).
At the risk of having to eat a bunch of worms, I propose removing all colons following identifier names (using nbsp for consistency) and changing "doi" and "hdl" to all caps, per the web sites that "own" these identifiers. – Jonesey95 (talk) 22:46, 27 September 2016 (UTC)
Perhaps not just yet. doi, with the colon preceding the identifier I think is to be lower case. It was originally intended to be like a url scheme if memory serves.
Trappist the monk (talk) 23:04, 27 September 2016 (UTC)
Yes, I think you are correct. So much for consistency. Thanks for fixing the PMC colon. – Jonesey95 (talk) 02:43, 28 September 2016 (UTC)
This old discussion is related to that. I'm still annoyed that ISBN formatting is different than all others. Headbomb {talk / contribs / physics / books} 07:34, 28 September 2016 (UTC)