Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite podcast)
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.


Documentation / Lua[edit]

We currently have three templates not using the Lua module: {{cite episode}}, {{cite serial}} and {{cite map}} (which is in progress). Currently we have a documentation switch |lua=yes in {{Citation Style documentation}} to display documentation sections for the Lua templates. I think it is time to remove that and show the Lua documentation on all with notes on the non-Lua templates. --  Gadget850 talk 18:16, 28 February 2015 (UTC)

Trappist the monk (talk) 19:55, 28 February 2015 (UTC)
Support, especially if we proceed with migration of {{cite episode}} and {{cite serial}}. I will help in any way that I can. It will be exciting to be done with this multi-year migration project. – Jonesey95 (talk) 23:29, 1 March 2015 (UTC)

What is needed to proceed with this change? Do we change to |lua=no for the non-Lua templates? Do we just put a big note at the top of the documentation for each of them saying that they don't work quite as described? Do we gather the non-Lua content from the subtemplates into a single subtemplate to display on the non-Lua pages?

As an aside, I noticed that {{Cite arXiv}} is listed in some of the official lists of CS1 templates (e.g. at {{Citation Style documentation/cs1}}) but not in others (e.g. Help:CS1 errors and Help:Citation Style 1#General use). It does not yet use Lua. – Jonesey95 (talk) 20:30, 21 March 2015 (UTC)

Yes check.svg Done. Now that all of the templates have been converted to Lua, this project was straightforward. I believe that I have stripped all of the "lua=yes" and "if lua" statements from our CS1 documentation. If I missed or broke anything, let me know (or be bold and fix it). – Jonesey95 (talk) 15:38, 19 April 2015 (UTC)

"Missing or empty |title=" error message[edit]

Various uses of citation without a |title= now throw the error message "Missing or empty |title=". Per a discussion last January I had thought that use of "|title=none" was going to suppress this message, but that is not happening. Can we get this message suppressed? ~ J. Johnson (JJ) (talk) 19:53, 12 March 2015 (UTC)

The referenced discussion referred specifically to {{cite journal}} though the applied 'fix' also applies to {{citation}} when one of the |periodical= parameters (except |encyclopedia=) is set. Which see:
{{cite journal |title=none |periodical=Periodical}}
{{citation |title=none |periodical=Periodical}}
{{citation |title=none |encyclopedia=Encyclopedia}}
"none", Encyclopedia 
Trappist the monk (talk) 22:49, 12 March 2015 (UTC)


{{citation |author= Hegerl, ''et al.'' |chapter= Chapter 9 |title=none }} in {{Harvnb|IPCC AR4 WG1|2007}}.
> Hegerl et al., "Chapter 9", none  in IPCC AR4 WG1 2007.
[My apologies. I condensed the example the example so much that it looks like a short cite, but it is intended to be a full citation. See the uncondensed example below. ~ J. Johnson (JJ) (talk) 21:10, 14 March 2015 (UTC)]
Better example below at #Example of "source in work" ~ J. Johnson (JJ) (talk) 00:50, 21 March 2015 (UTC)
where the source is a chapter in the larger work linked to. Strictly speaking the 'work' is a book, but use of {cite book} gives the same result. Use {cite journal} causes |chapter= to be ignored. ~ J. Johnson (JJ) (talk) 22:18, 13 March 2015 (UTC)
This would allow replacement of the little used {{source in source}}. --  Gadget850 talk 22:58, 13 March 2015 (UTC)
I have never warmed to {source in source} (too grotesque), and would favor its replacement. ~ J. Johnson (JJ) (talk) 21:04, 14 March 2015 (UTC)

{Harvc} as alternative[edit]

Even though you are on the record in opposition, this is the kind of thing for which {{harvc}} was invented. Somewhere in the text you have: {{sfn|Hegerl, et al.|2007}} which for illustration I'll put here.[1]

In the bibliography section write a citation for the book. This template is one I found at Global warming; it has not been modified:

{{Cite book | year = 2007 | author = IPCC AR4 WG1 | title = Climate Change 2007: The Physical Science Basis | series = Contribution of Working Group I to the [[IPCC Fourth Assessment Report|Fourth Assessment Report]] of the Intergovernmental Panel on Climate Change | editor = Solomon, S.; Qin, D.; Manning, M.; Chen, Z.; Marquis, M.; Averyt, K.B.; Tignor, M.; and Miller, H.L. | publisher = Cambridge University Press | url = | isbn = 978-0-521-88009-1 | ref = harv }}

Then write {{harvc}} templates for each of the individual chapters that are part the 'book' but are cited separately:

{{harvc |last=Hegerl, et al. |year=2007 |c=Chapter 9: Understanding and Attributing Climate Change |url= |loc=[ Section 9.5.2: Sea Level]|in=IPCC AR4 WG1}}

So, from your {{sfn|Hegerl, et al.|2007}} there is now a link into §References where there is a link to the appropriate chapter in §Bibliography which links to the book. Here is the link in article text again.[2] The {{harvc}} template can also be enclosed in <ref>...</ref> tags.[3]




Trappist the monk (talk) 23:58, 13 March 2015 (UTC)

My apologies for causing some confusion here. In the interest of brevity I condensed the example above so much it may appear to be a short cite, such as where harv templates are used to connect to a full citation with full bibliographic details. (This confusion is further compounded by the way citations are misused at Global warming#Citations.) The preferred solution here is to have very short links (implemented with some form of {harv}), such as "Hegerl, et al. 2007", used where ever material needs to be attributed, all of which link to a single full citation such as the following:
This should be considered as a full citation, which would appear only once in an article (presumably in the "Bibliography" or such), and refers to the whole source ("Chapter 9"), not to any specific material within. (I have stricken the specification that was mistakenly included.) It does not look like a "full" citation because it does not repeat the bibliographic details of the encompassing work, nor a proper list of authors, and contains only the details that distinguish this chapter from other chapters in the same work. ~ J. Johnson (JJ) (talk) 20:41, 15 March 2015 (UTC)
{{harvc}} does that: can appear only once and refers/links to the single whole source, does not look like a full citation (because it isn't one) and contains only the details that distinguish this chapter from others in the same work. And, it doesn't produce corrupted metadata and so there isn't a missing title error message (though it will emit error messages when required stuff is omitted).
Trappist the monk (talk) 00:26, 16 March 2015 (UTC)
The important point is that the "in source" attribution follows only the full citation, not every instance of the short cite. (The latter being what {{harvc}} does, which is one reason why I opposed it, the other being that I don't believe a whole additional template is necessary for this.) And in fact the current set does all this just fine, except for the little detail of an entirely unnecessary and unuseful red error message.
So back to my initial request: can this little red splash be suppressed? ~ J. Johnson (JJ) (talk) 21:10, 14 March 2015 (UTC)
The example full citation template is incomplete. It identifies a chapter of 'something', but doesn't identify what that 'something' is. Because that template is a CS2 citation, it produces metadata that are also incomplete. This is the reason that there is, and should remain, an error message. The full template is coupled (by proximity only) to a {{harvnb}} template that links to a full citation that is complete in and of itself – title, editors, publisher, isbn, etc that the pseudo-full citation lacks.
This same is all true of {{harvc}} in that it also lists only a chapter of 'something' without identifying what that 'something' is; it also links to a full citation with all of the aforementioned stuff (without an additional {{harvnb}} template). But, because it isn't a CS1/CS2 template, it does not produce metadata and is simply a bridge between simple {{sfn}} templates and the full citation template. I've tweaked my examples above to include the chapter's name, url, and location data.
Trappist the monk (talk) 23:00, 14 March 2015 (UTC)
The "something" - the larger work which includes this source - is identified. Just not within the template. The citation is indeed complete as displayed (that is, the work is identified/linked). But I gather your concern is providing context for the metadata collected from the template. Well, that is a deep issue. And it seems to me that harvc is, in the end, just a kludge for getting around the CS1 error checking. I think it would be simpler to just suppress the error message. However, I want to take a deeper look at al this, and see if I can better formulate what is needed. For the duration: even if "missing title" is kept as a maintenance category, could we at least have the error message suppressed? ~ J. Johnson (JJ) (talk) 20:43, 15 March 2015 (UTC)
Yes. There is no facility for us to split a citation and then, somehow, later, gather up all of the incomplete metadata from the disparate parts and meld them into a single complete unit. It is not possible; templates can't communicate with each other. Maybe someday but not at present. So, {{harvc}} is no more a kludge than writing a CS1/CS2 citation that intentionally leaves out information critical to the proper compilation of the citation's metadata. Better, I think, to have metadata that is complete and correct than to have metadata that is incomplete.
Trappist the monk (talk) 00:26, 16 March 2015 (UTC)
I have had an idea (yikes). In {{harvc}} you have an |in= parameter. Could we have a similar parameter in {{citation}}, which would signal that the citation metadata is incomplete and should not be collected for COinS? And incidentally overlook the lack of a title? ~ J. Johnson (JJ) (talk) 23:04, 18 March 2015 (UTC)
Could. But:
  1. {{harvc}} is already written, debugged, working, and documented
  2. new documentation would be required
  3. adding |in= to Module:Citation/CS1 adds yet another level of complexity to an already complex code set
So, unless overwhelming support for this compels me, I'd rather not.
Trappist the monk (talk) 15:25, 19 March 2015 (UTC)
Harvc does not provide the functionality needed (such as expansion of the author list), misorders the elements (but fixable?), and adds complexity to the use of citations. I would be satisfied if {{citation}} simply accepted the lack of a title; my idea for an |in= parameter would address your conern about incomplete metadata. It also permits retention of title checking for the general run of cases where lack of a title probably is an error. If coding that is too much trouble, then let's fall back to the previous idea of using |title=none to suppress the error message. I believe any changes to the documentation are minimal, and I can take care of that, so that should not be any objection. ~ J. Johnson (JJ) (talk) 19:24, 19 March 2015 (UTC)
{{harvc}} was modeled on the other short-form templates that accept a maximum of four author names. That could be changed, I suppose, though we would probably also need to include a form of |display-authors= so that the template could switch from its default, where it acts just like the other {{harv}} templates, to displaying all or part of the author list. How are the elements misordered? How is using {{harvc}} any more complex than the exemplar that uses both a broken CS2 template and a {{harvnb}} template?
Trappist the monk (talk) 14:26, 20 March 2015 (UTC)
I'm putting together an example which should clarify the situation. ~ J. Johnson (JJ) (talk) 23:27, 20 March 2015 (UTC)
I've added a better example below at #Example of "source in work". In brief, one or more short cites (implemented with harv templates) link to the citation for the chapter (contribution), which links to the citation for the work. The middle layer uses {{citation}} because there is no simple form of {{harv}} that will produce the full author list (which could include author-links), and because any use of harv of at the middle layer confuses the use of short cites. All of this works just fine, aside the from the red message. ~ J. Johnson (JJ) (talk) 01:06, 21 March 2015 (UTC)
Trappist the monk: back to my initial request, can the Missing or empty title message be suppressed, either entirely, or in the specific case of |title=none? ~ J. Johnson (JJ) (talk) 23:03, 24 March 2015 (UTC)
Have I not already answered this? No. The error message is there for a purpose and so should not be suppressed. If we do anything, it should be to {{harvc}} where we expand on its ability to better handle and display all or part of the author list.
Trappist the monk (talk) 11:02, 25 March 2015 (UTC)
You said you would "rather not" implement my idea of an |in= parameter, and I can accept that you think it is not important enough. However, suppressing this red message is a different matter. It is an "error" only because you (and ??) decided that it should be; I think it can be argued that it is not. Indeed, in regards of COinS I would argue that given a full citation for a containing work, citations for the chapters contained within should not generate COinS metadata. However, the usual way of handling such cases - incorporating all the bibliographic details of the containing working within each chapter's citation (see example below) - can lead to voluminous redundant data for the IPCC reports. The method I have developed for handling these cases is reasonable, and works. Except for the splot of red, which is a recent innovation.
Harvc is not suitable. Should we break out a subsection to discuss that? ~ J. Johnson (JJ) (talk) 21:46, 25 March 2015 (UTC)
You are mistaken. I do think it is important. That is why {{harvc}} exists. I also think that it is important to let the CS1/2 templates do what they do best and not try to make them do else-wise by creating special cases where the module does something different; there is too much of that already complicating the code in service of the unique characteristics of the various templates. So far I see no reason to abandon my 'rather not' position.
I have suggested that {{harvc}} functionality could be expanded but even with that you stand fast on Harvc is not suitable. This begins to look rather like a stalemate which to me is wearisome.
Trappist the monk (talk) 00:05, 26 March 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I regret that this is becoming wearisome, but it is rather important for me, so I would deem it a great favor if you might bear with me a little longer. The IPCC citations present some unusual and difficult challenges, and though these are not so notable across the entirety of Wikipedia (but what sources are?), they are very significant within the Global Warming articles. The approach I developed has worked very well, up until the recently introduced "error" messages. I take your view to be that this approach involves "broken" {{citation}} templates, that this approach misuses the templates in making them do something they were not designed for, and would complicate the underlying code.

Regarding the last, I do not see how testing the template data for "missing or empty title" is any less complicated than not testing for that. Even the special case of skipping the test for "title=none" should be only a single line, nothing complicated. But if it is, then I would argue: eliminate the title test entirely.

Which gets to what I suspect is the core issue: is citation of chapters always incomplete, and therefore an error, if it is missing details of the containing work, such as title? I do agree that a "citation" is incomplete without such details. But I say the issue is more finely whether the template (whether {{citation}} or {{cite xxx}}) must contain all the details, and more particularly whether a link to those details is acceptable. I find that this must be made acceptable, as the alternative is that every chapter cited in every IPCC Assessment Report becomes bloated with these extensive details. I believe your argument at this point would be something about the incompleteness of COinS data. I will address that tomorrow. For now I ask if you concur with what I have described so far. ~ J. Johnson (JJ) (talk) 04:34, 27 March 2015 (UTC)

Here are a couple of {{harvc}} templates of the sandbox variety. They will accept as many authors as you want. Right now it's somewhat clunky: |display-authors=99 |display-authors=all is used to display all of the authors in the contributor's list. If the value assigned to |display-authors= is all or the same as or greater than the number of authors in the contributors list, then all last and first names are displayed. If |display-authors= is empty or omitted, then the template displays up to the first four (if present) last names in the same way that other 'harv' templates do. If |display-authors= is assigned a value less than the number of authors in the contributors list, the template displays both last and first names of that number of contributors followed by et al.
Here the {{harvc/sandbox}} {{harvc}} template output is compared to your unmodified {{citation}} output. The differences are date display and brackets around year in the link to the enclosing work.


Trappist the monk (talk) 00:58, 29 March 2015 (UTC)
Thank you. I will study this tonight. ~ J. Johnson (JJ) (talk) 21:25, 29 March 2015 (UTC)
I am somewhat amazed that you went to the trouble of making harvc produce a proper display, where addition of (I believe) one or two lines in the CS1 code could have saved us all this trouble. Particularly as harvc extends the harv templates well past what they were designed for. Which sounds like what you complained about on the 26th, that "it is important to let the CS1/2 templates do what they do best and not try to make them do else-wise by creating special cases where the module does something different...". The only special case I am asking for is the one value of "none" for title, and all it does is suppress an error message. Your fix introduces three new parameters (|c=, |url=, and the |in= parameter you rejected for CS1 on the 19th), and radically alters the normal Harv output. Not to mention that new documentation will be required (your objection #2 on the 19th).
But while the harvc display now looks reasonable, there is still a fundamental problem: the harv templates are designed for use in-line as short cites, whereas the CS1 and CS2 templates are designed for full citations. As such the latter are often collected together as lists, where inclusion of a short cite form (harv) as an item is anomalous, and typically an error. Using a full citation form (such as {citation}) for the IPCC chapters is reasonable and conformable with all other full citations, using the same general format. Use of harvc increases complexity, creates anomalies that invite "correction", and increases the difficulty of explaining to other editors why there must be this anomalous usage.
Trappist, I really appreciate that you would put significant time and effort into tweaking harvc. However, it also concerns me that you should expend so much time and effort on something fundamentally unsatisfactory when there is a better solution. I believe your principal concern is the integrity of the COinS data. If that is satisfactorily addressed, could we not have the minimalist modification of "title=none"? ~ J. Johnson (JJ) (talk) 22:39, 30 March 2015 (UTC)
|c= (and its aliases |chapter= and |contribution=), |url=, and |inn= have been part of {{harvc}} since its first release. The changes in {{harvc/sandbox}} are: unlimited |lastn=, addition of |firstn=, |author-linkn=, |author-maskn=, and |display-authors=; conversion of |separator= to |mode= for CS1/2 compliance. Yeah, if I make this new version the live version then I'll need to update the documentation.
I chose {{harvc}} as a name because it was developed from the code that handles the {{harv}} and {{sfn}} templates. {{harvc}} is just a name. Pick another name; one that makes you happy; then make a redirect from that name. Or {{harvc}} can be moved to that name.
Trappist the monk (talk) 11:35, 31 March 2015 (UTC)
{{citation-in}}? Face-smile.svg Well, a name change would help, but the problem is that it is only "skin deep": the parameters and their usage are still different. This template by any name is inherently different, which increases complexity. ~ J. Johnson (JJ) (talk) 00:20, 1 April 2015 (UTC)

"Error" message still a problem, and Harvc still unsuitable[edit]

Trappist the monk: the "missing or empty title" message is still a problem, and (upon re-reviwing the matter) I find Harvc is still unsuitable for the use needed (as previously explained). Therefore I re-iterate my original request to suppress this message. Or, alternately, to allow some keyword that would suppress the message. You previously stated (25 Mar) that "[t]he error message is there for a purpose", which I take to be ensuring that data extracted for COinS is complete. However, it seems to me that skipping the metadata extraction these cases is simple (and even quite reasonable, as chapters are not really suitable for COinS anyway), and so should not be an issue if a special keyword is implemented.

If you still object to having a special keyword I would much appreciate reviewing your reasons. ~ J. Johnson (JJ) (talk) 23:09, 20 April 2015 (UTC)

I'm pretty sure that my position hasn't changed since my last post on this topic three weeks ago. Unless there is something new to discuss ...
Trappist the monk (talk) 11:49, 21 April 2015 (UTC)
Trappist the monk: You have previously expressed concern for the COinS metadata, but in your statement of three weeks ago (00:05, 26 Mar) your opposition was to "creating special cases" and "complicating the code". Allow me to suggest that checking for "empty or missing" title is a special case that complicates the code, and that eliminating that recently added functionality would simplify the code. Your position is also inconsistent with your advocacy of harvc, which (besides being quite unsuitable) is a definite cock-up relative to the rather simple change need to add a title exception. I can only surmise that your adamant opposition arises from some other basis, which we cannot examine until you state what it is. Despite your previous statement, it appears that you do not think this is important enough to even address. ~ J. Johnson (JJ) (talk) 20:57, 22 April 2015 (UTC)
Yep, because omitting |title= corrupts the metadata; yep, because to do what you want introduces yet another 'special case'; yep, because special cases complicate code, they always have and they always will. Checking for missing titles is not new but, rather, has been refined. In the past, anything that vaguely resembled a title counted as a title but that loose definition permitted editors to create citations that produced incomplete metadata.
I have no hidden reasons for my opposition and I have addressed the issue: see the {{harvc/sandbox}} examples in the adjoining discussions.
Trappist the monk (talk) 12:12, 23 April 2015 (UTC)
Thank you for clarifying this. So your opposition is based entirely on two points: 1) leaving out "title" corrupts the COinS data, and 2) special cases complicate the code.
Regarding your first objection, I point out that metadata is not corrupted if it is not generated. If a "title" (referring to a containing book or "work") is not present, then it is appropriate to not generate any metadata, and there is no corruption. This is reasonable, as COinS is used to find library items (e.g., books), not chapters within books. (Underlying this is a deeper issue of whether every use of a citation template must include a title, but as this is not a point of objection we need not examine it.) If in the special case I am asking for COinS data is simply not generated, there is then no corruption of the metadata. Your point is refuted.
Regarding your second objection: if you insist on simplicity for its own sake, then you should remove all COinS processing, which is a vast complication on the original and primary purpose of the CS templates. On a smaller scale you could simply remove the code that checks for "missing or empty" titles. Of course, that would conflict with the preference for complete metadata, but that is my point: it's all a matter of trade-offs. You decided that reducing data corruption warranted further "refinement", but when you broke an established and valid usage you decided that it was not important enough for any further refinements. This is particularly odd as the CS code appears to be a mass of special cases, so why do you think this special case will break everything?
I do not find your objections valid (which is why I wonder if there is some other basis for your adamancy), and do not know how else to address them. Would you be persuaded otherwise if I can find (say) three other editors (after all, this is an obscure technical point) who support what I have requested? ~ J. Johnson (JJ) (talk) 22:01, 23 April 2015 (UTC)
Of course, metadata are not corrupted if not generated, but CS1 and CS2 do generate metadata. The decision to do so was taken quite long ago. I don't know how the metadata are consumed but I would guess that complete and accurate metadata are important to those who do consume it. The COinS documentation identifies a keyword rft.atitle to hold chapter titles. COinS support exists, the metadata are used, so that facility likely isn't going away even though it would simplify the code. (And yes, I think every CS1 and CS2 template should have a title.)
Yep, Module:Citation/CS1 is awash in special cases because it directly supports some two dozen CS1 and CS2 templates. One of my long-term goals is to minimize that to the extent possible.
Trappist the monk (talk) 11:09, 24 April 2015 (UTC)
So you agree that, in the cases at issue, if a COinS record is not generated, there is no corruption of the data. The question is then whether, in such cases, not generating a record is a loss of data. I say no, as a record is generated for the item (book) containing the chapter. I believe the issue comes down to having either a) multiple records containing chapter data that is that is useless for finding the book and book data that is repeated across all these records, or b) a single record for the book that does not contain information not useful for finding the book (i.e., the chapter details). In most cases of "source in work" there is only a single instance, so it is convenient to package all the bibliographic detail into one citation. (That COinS has a field for chapter title is, I believe, for the rare but extant cases where a chapter is published separately, where it is useful to know that the material might be found as an individual item, or included in a larger work.) In the cases I am working with there are multiple instances, and even multiple levels of containment (section in chapter in report in review), each with substantial bibliographic detail. Such masses of detail can overwhelm both readers and editors, and causes other problems, wherefore I find it necessary to use the second approach. ~ J. Johnson (JJ) (talk) 21:27, 24 April 2015 (UTC)
I find it necessary to use the second approach for which purpose {{harvc}} was designed and since enhanced. {{harvc}} does not produce COinS metadata, can be linked from multiple places in an article, does link to the containing work's CS1/2 citation, and does hold and display the substantial bibliographic details of the sub-unit. All of this so that [s]uch masses of detail [don't] overwhelm both readers and editors, and [cause] other problems.
Trappist the monk (talk) 12:08, 25 April 2015 (UTC)
Have I not already explained this? Harvc is fundamentally unsuitable. (See my previous comment of 22:39, 30 March.) Although you can make the resulting display essentially equivalent, Harvc is quite at odds with the use and purpose of the Harv family of templates. It is very much a special case (such as you keep inveighing against) that will only confuse the editors attempting to use. E.g., the Harv templates generate short cites which do not contain bibliographic details, and (typically) use only the last name (of one or more authors) or a shortened title to link to the full citation. Now editors will wonder (it becomes necessary to explain) why bibliographically complete full names and full titles are required for Harvc, but are not accepatble for the rest of the Harv templates. Also: editors can readily understand having the short cites (implemented with Harv) in the text (or notes therein) and the full citations (implemented with CS1/CS2 templates) in a seperate "References" section. But having Harvc templates mixed in with the CS templates is anomalous, confusing an otherwise distinct usage. Harvc not only makes the already challenging task of IPCC citation more complex, it is likely to confuse and perplex editors in the use of the Harv templates generally. This is entirely unacceptable.
CS1/CS2 already does everything you claim for the unsuitable and even dubious Harvc, and the simple enhancement I am requesting could easily skip producing COinS data. Your advocacy of Harvc in the face of a simpler and more suitable option brings us back to my previous question: why? Your objections are inconsistent and disproportionate, and I believe I have adequately addressed them. So why do you persist?
BTW: In quoting me are you concurring in preferring the second approach? ~ J. Johnson (JJ) (talk) 23:46, 25 April 2015 (UTC)
I can take a file to one of the claws of a framing hammer so that it fits a slotted-head wood screw and use the modified hammer to drive the screw or I could just hammer the screw into place. I would be better to use a screwdriver, the proper tool for the job. {{harvc}} is not a special case but rather, the proper tool to render intermediate cites between long-form citation templates and short-form citation templates.
{{harvc}} has never required bibliographically complete full names; its default is to display the contributor list in the same manner as {{sfn}} and {{harv}}. Because of its intermediate nature, it does require a title and the enclosing work's author/editor list or name.
I don't believe that our editors are bucket-headed dolts who are incapable of understanding how all of these bits, pieces, and parts fit together. I took your point about {{harvc}}'s name. Do you have a better name? You did suggest {{citation-in}}. Because {{harvc}} defaults to CS1 styling perhaps that name should be {{cite-in}}. But, I don't think that {{harvc}} should be renamed to either of those because it isn't one of the CS1 (cite) or CS2 (citation) family of templates. Perhaps the name should describe the function: {{harvc}} is intermediate between short-form and long-form citation templates: {{intermediate harv cite}} perhaps with a redirect from {{ihc}}.
I would not have gone to the trouble of coding {{harvc}} if I didn't believe that there are times when an intermediate template between short- and long-form citation templates is appropriate.
Trappist the monk (talk) 15:10, 26 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── As a quasi-humorous interlude: years ago I was surprised to find a tool like an awl with screw thread on the end. The intended use is to hammer it into a stud, then screw it out, leaving a pre-threaded pilot hole for a proper screw. This was considered better practice than hammering screws in most of the way, taking a couple of turns at the end. Which is perhaps to say that kludginess is relative.

Your "bucket-headed dolts" is not really relevant here. I think there are such editors, but the editors I am trying to serve are quite experienced (and competently so), and I believe are fully capable of understanding citation complexity. But many of them are uncomfortable going beyond the simplest use of CS1/CS2. Which I find somewhat reasonable: WP has a lot of complex stuff, and I am loathe to add any unnecessary complexity. I would like to bring them up to using Harv, but there is great sensitivity to any perceived complexity, and especially so for any increase of complexity. This includes radically differing uses (such as use of full or only last name, as I described in my previous comment) of ostensibly similar "Harvx" templates. Using a different name would defuse some of the anticipation of similiarity, but would add another layer of complexity where I am convinced the existing tools (with a slight enhancement) are quite adequate.

Keep in mind that this intermediate link I am trying to implement has two components. First is the description (full biblilographic details) of the chapter (contribution); second is the link (minimal necessary details) to the enclosing work. Note the key differences: the chapter has the full names of all authors, AND the full title, while the enclosing work has either the last names only of the first three editors, OR a short title. The CS1/CS2 templates are designed to do the former, while the Harv templates are designed for the latter. Except for Harvc, which you are repurposing to do both by adding a raft of additional parameters. Your hammer is now trying to emulate a ratchet screwdriver that handles slotted, Phillips, or Allen head screws.

If you really insist on a separate template let's do this: copy {{citation}} to {{citation-nc}} ("no coins"), then remove both the title test and all of the code for generating COinS data. No red message, no corrupted data, and we're both happy. Right? ~ J. Johnson (JJ) (talk) 20:33, 27 April 2015 (UTC)

I understand what you are trying to implement. {{harvc}} does all that:
vs your implementation:
{{harv}}{{citation}} + in + {{harv}}{{citation}}
Copying {{citation}} to {{citation-nc}} (really copying Module:Citation/CS1 to some other name) is not going to happen. That makes two mostly similar code sets to maintain in parallel. No thank you. Module:Harvc, not being a one-off copy of Module:Citation/CS1 does not have to be maintained in parallel. Yes, there will on occasion be times when a change to Module:Citation/CS1 will require a change to Module:Harvc but every change to Module:Citation/CS1 need not be reflected in Module:Harvc.
Trappist the monk (talk) 14:29, 28 April 2015 (UTC)
I was rather cherishing my virginal innocence of Lua, but in a momentary rashness I clicked on your link. And now I am undone, undone!! I blush to think of my ignorance all in shreds, with visions of algorithms dancing in my head. :-(
~ J. Johnson (JJ) (talk) 21:02, 29 April 2015 (UTC)
I share your aversion to maintaining multiple nearly identical sets of code. But aside from that, consider that from a conceptual point of view, two templates whose use is identical and differ only in that one flags "missing or empty" titles as errors (which is what you want), and the other neither flags such cases (satisfying me) nor generates "corrupted" COinS data (satisfying you) would seem a satisfactory solution.
Of course, where the differences between two such templates is so slight, it would be absurd to maintain separate blocks of code. That also goes to creating and maintaining a whole new template (Harvc) which, in the end, implements what is a trivial enhancement of what can be (and has been) done with CS1. In brief, [{{citation}} "in" {{harv}}] worked fine; there was no need for Harvc until you broke {citation}. ~ J. Johnson (JJ) (talk) 23:58, 28 April 2015 (UTC)
I think that the current situation works just fine. {{Harvc}} is designed to shorten a citation down to the name(s) of the contributor(s) of a component in a larger work and link to the full citation of the encompassing work in another section. It works just fine to handle multiple chapters in a report that each have individual authorship apart from the encompassing report on Michigan State Trunkline Highway System, and for the life of me, I can't see what the great issue is with that system that's caused all of this discussion and debate. The status quo with the templates, with a few possible amendments seems more than adequate. Imzadi 1979  05:05, 28 April 2015 (UTC)
Imzadi: I think you are not paying close enough attention. All that you said is quite true except one little detail: a couple of months ago the status quo changed, resulting in numerous "error" messages that beg "fixing". I am trying to get Tappist to make a "possible amendment", but won't do it. He wants me to use Harvc, which I find quite unsuitable. Not because of the displayed result, but for all the objections he makes to my requested little change, plus the confusion it will add the use of citations, particularly the Harv templates. We are not arguing about the resulting display, but the process, and similar underlying issues. ~ J. Johnson (JJ) (talk) 05:50, 28 April 2015 (UTC)
@J. Johnson: I was also unhappy about the appearance of error messages when citation templates were used without titles, since I made regular use of references of the form "chapter_citation in Harvard_link" with the "Harvard_link" leading to an entry elsewhere, often in the Bibliography. But as far as I can see, {{harvc}} can now be used to achieve the correct effect. So what is your real objection? If it's to the name of the template, I agree that for general use, it's a confusing name, since its purpose is "condensed citations" not Harvard style cross-references. However, as Trappist the monk says, there can be any number of aliases, so this is easily fixed. The precise behaviour of the parameters is an issue, I think; it betrays the origin of the template via the Harvard templates rather than via the cite/citation templates. For example, I do find it odd to have to use |display-authors= to get first names displayed. I believe this should be the default as it is for a normal citation, with |display-authors= required to suppress output not produce it. Peter coxhead (talk) 09:26, 28 April 2015 (UTC)
It wouldn't be much of an issue to make the default contributor list display be like that of CS1|2 templates and then use the CS1|2 presentation parameter |name-list-format=harv to switch to the {{harv}} family style. This would, I think require a new name. Got any ideas for that? {{intermediate cite}}, {{intercite}}, {{icite}}; {{contribution cite}} with redirects from {{section cite}}, {{chapter cite}}, {{report cite}} (may be too close to {{cite report}}), {{review cite}} come to mind.
Trappist the monk (talk) 14:29, 28 April 2015 (UTC)
Back into the sandbox, here's Hegerl:
{{harvc/sandbox |mode=cs2 |ps=. |first1= G. C. |last1= Hegerl |first2= F. W. |last2= Zwiers |first3= P. |last3= Braconnot |first4= N. P. |last4= Gillett |first5= Y. |last5= Luo |first6= J. A. |last6= Marengo Orsini |first7= N. |last7= Nicholls |first8= J. E. |last8= Penner |first9= P. A. |last9= Stott |year=2007 |c=Chapter 9: Understanding and Attributing Climate Change |url= |in=IPCC AR4 WG1}}
Hegerl, G. C.; Zwiers, F. W.; Braconnot, P.; Gillett, N. P.; Luo, Y.; Marengo Orsini, J. A.; Nicholls, N.; Penner, J. E.; Stott, P. A., "Chapter 9: Understanding and Attributing Climate Change", in IPCC AR4 WG1 (2007).
and if you set |name-list-format=harv you get this:
Hegerl et al., "Chapter 9: Understanding and Attributing Climate Change", in IPCC AR4 WG1 (2007).
I have set all previous uses of {{harvc/sandbox}} in these conversations to use the live version.
Trappist the monk (talk) 10:58, 29 April 2015 (UTC)
@Trappist the monk: the functionality of the sandbox version is closer to my current preference; please see the comment I've added at #Example of "source in work". Peter coxhead (talk) 19:22, 29 April 2015 (UTC)
Peter: I agree that Harvc can produce what is essentially identical display output. But as I was just saying, there is what I deem a very serious problem in how to use this template. Just for the sake of the Harv templates generally (and trying to get editors to use them) I strongly object to how Harvc goes way beyond that family of templates with these new parameters, uses, and output. For the case at hand I object to having to use yet another template, with its own peculiar characteristics, where, with a single enhancement, the existing CS1/CS2 templates would work just fine, with no additional training or explanations required. Alternately, I object to this disenhancement that broke prior usage.
Trappist: "Harvc" as a name absolutely has to go. (That removes the confusion of anticipated similarity with the rest of the Harv family.) But the deeper problem is having yet another template, with its own peculiar characteristics, which adds more complexity in creating citations. And (again), why go to so much trouble making Harvc more like CS1/CS2 instead of just fixing the latter? ~ J. Johnson (JJ) (talk) 00:02, 29 April 2015 (UTC)
@J. Johnson: please see the comment I've added at #Example of "source in work". Peter coxhead (talk) 19:22, 29 April 2015 (UTC)


I need a context to understand this. Have I got this right? J. Johnson wants three levels of citation, a short inline citation, an intermediate level that describes a chapter in a larger work (in this case, an online work), and a top level citation that gives full information on the work? I don't think that's traditional in paper citation styles. If I'm right that it is untraditional, it's going to confuse readers, who won't be expecting a three-level citation hierarchy. And it's going to be even more confusing for editors. So if the work has the same authors for all chapters, I'd cite the entire work and have short cites to that. If the work has different authors for different chapters, and especially if the identity of the chapter authors is significant, I'd put every chapter that was used in the bibliography and make the short cites point to the appropriate chapter. Jc3s5h (talk) 21:04, 15 March 2015 (UTC)

Pretty nearly "yes" on all counts. (Though what I want is subect to modification. I'm still working this out.) And what you suggest - giving each chapter (these all have different authorship) a full citation that includes the details of the containing work - is inded the standard format. However, in the various global warming articles the chapters from the IPCC reports are cited so often, and the citations of the containing works have so much detail, that the citations become very bloated, in both the wiki-text and the displayed text, with redundant information. This obscures the essential information, and makes careful editing extremely tedious. That having three levels of citation (instead of the more common two levels) is not "treaditional" is not, I think, a problem, as any readers interested in the sources (most of them are not) are used to clicking on a link to get to the next level of information. ~ J. Johnson (JJ) (talk) 23:56, 17 March 2015 (UTC)

Example of "source in work"[edit]

The goal is to enable having within an article one or more short cites like this Hegerl et al. (2007)[1] (in either the text or a note, and optionally specifying a location within the source[2][3]) that link to a single citation for a chapter (contribution) with the full details of that source, which in turn links to a single citation for the containing work, without repeating at any level the details of the chapter or of the containing work. And without the red message complaining of a missing or empty title.


  1. ^ [Generated with {{harv}} templates like this: {{Harvtxt|Hegerl et al.|2007}}]
  2. ^ Hegerl et al. 2007, Section 9.5.2: Sea Level, p. 999. [Short cite, with specification appended.]
  3. ^ Le Treut et al. 2007, Section 1.3.2: Global Surface Temperature.

In the "References" or "Bibliography" section, using {{citation}} templates:

  • Hegerl, G. C.; Zwiers, F. W.; Braconnot, P.; Gillett, N. P.; Luo, Y.; Marengo Orsini, J. A.; Nicholls, N.; Penner, J. E.; Stott, P. A. (2007), "Chapter 9: Understanding and Attributing Climate Change",   Missing or empty |title= (help) in IPCC AR4 WG1 2007. ["Full" citation of Hegerl et al., except that details included in the citation of the containing work (below) are not repeated here. This citation appears only once in the article.]

Contra-example: The goal is to avoid having to cite each chapter with a bloated "fullest" citation such as the following:

All this currently works just fine, aside from the recent introduction of the "missing or empty title" message. ~ J. Johnson (JJ) (talk) 00:43, 21 March 2015 (UTC)

I have added a contra-example of the bloated "fullest" citation that ordinary usage requires for every chapter cited. ~ J. Johnson (JJ) (talk) 21:34, 25 March 2015 (UTC)

@J. Johnson: the disadvantage of your approach above is that it involves a "two template" citation of this form:
{{Citation |...chapter details... }} in {{Harvnb| to book...}}
Like you I used to use this approach regularly, and was initially annoyed that it produced an error message. Now, with the benefit of hindsight, I see that the "two template" approach was not optimal. All the relevant information is not contained within the Citation template, which is logically wrong and makes automated processing and extraction of citation details difficult. With the benefit of the work done by User:Trappist the monk, and some more hindsight, what is needed instead is the ability to use a "one template" citation of the form:
{{Citation |...chapter details... | to book.. }}
so that the link to the book is within the Citation template. (The sandbox version of harvc almost achieves this, but not quite, because some functionality of the Citation template is missing – e.g. |lastauthoramp=.) Given a little bit of tweaking and a better name for the template, I can't see that the "one template" approach is any more difficult for editors to use than the "two template" approach: it requires precisely the same information to be provided. It has some limited, but real, advantages.
The only slight difficulty I see is that the "two template" approach allows some extra choice; thus I prefer the style of {{Citation}} plus {{Harvtxt}}, the latter with no terminal full stop to be compatible with CS2, whereas you appear to prefer CS2 + {{Harvnb}} and to have a terminal full stop not usually considered compatible with CS2. Peter coxhead (talk) 19:15, 29 April 2015 (UTC)
Unlike CS1|2 which is promiscuous, for |last-author-amp=, {{harvc/sandbox}} requires yes or true (case insensitive):
{{harvc/sandbox |last-author-amp=yes |mode=cs2 |last1=Last1 |first1=First1 |last2=Last2 |first2=First2 |last3=Last3 |first3=First3 |chapter=Chapter |in=Enclosing Source |year=2009}}
Last1, First1; Last2, First2 & Last3, First3, "Chapter", in Enclosing Source (2009)
Trappist the monk (talk) 00:31, 30 April 2015 (UTC)
@Trappist the monk: ah, I see now that the problem is with my use of the alternative/alias |lastauthoramp=. Try using this with the sandbox version, i.e. use |lastauthoramp=yes and see what happens. Peter coxhead (talk) 13:02, 30 April 2015 (UTC)
I've fixed the Lua error. The CS1|2 alias |lastauthoramp= is not supported by {{harvc}} because of the move to hyphenated parameter names in CS1|2. I'm wondering about making yes the only accepted value for |last-author-amp=.
Trappist the monk (talk) 13:21, 30 April 2015 (UTC)
It's fair enough not to 'advertise' the unhyphenated aliases, in the interests of simplifying the documentation and thus helping new users, but spare a thought for us oldies (both in age and Wikipedia editing time) who find it hard to shake off old habits! Peter coxhead (talk) 15:09, 30 April 2015 (UTC)
Peter: the key difference between these two approaches is whether "all the relevant information" of the containing work (such as the editors, publisher, isbn, etc.) should be 1) contained within the template that describes the chapter (for every chapter), or 2) contained in single citation for the work, to which each chapter links. The first case results in multiple instances of "fullest" (i.e., bloated) citations with lots of redundant data, such as the "contra-example" shown above.
In the second case there are two ways of linking: 2a) externally, by explicitly suffixing a Harv link (as I have done), or 2b) internally, using an |in= parameter and code to create the link automatically. This is what Trappist did in Harvc, and (if I understand you correctly) what you seem to be suggesting for {{citation}}. However, note that I already suggested that (23:04, 18 Mar), which Trappist rejected (15:25, 19 Mar) as "adds yet another level of complexity to an already complex code set".
As to ease of use: your "one template" approach is more accurately (if I understand you correctly) a hybrid template approach. And the arithmetic is more precisely the use of two templates (citation and harv) versus three templates (citation, harv, and the hybrid Harvc). (The hybrid form does not eliminate use of the other Harv templates because they are still needed to link to the chapter template.) Use of |in= in any template increases the complexity of that template; using {{citation}} "in" {{harv}} does not, as that is a straightforward application of what the editor already knows. ~ J. Johnson (JJ) (talk) 20:50, 29 April 2015 (UTC)
Trappist hasn't rejected the use of the "one template" approach, but rather trying to shoe-horn it into the existing template. I'm happy to leave it to an experienced template/module editor to decide on the appropriate modularity for the implementation; a single template would indeed be easier to use, but may simply be too difficult to maintain well. You and I agree, I think, that "harvc" is a bad name for the "one template", but given that the most editors prefer CS1 (for reasons which escape me), and hence have to choose between "cite book", "cite web", "cite encyclopedia", "cite journal", etc., having one more citation template (with a more sensible name like "cite in") can't be a serious burden. Anyway, it seems that we aren't going to agree. Peter coxhead (talk) 13:11, 30 April 2015 (UTC)
Peter, I think we can agree. It's just a "simple matter" (ha) of finding the right basis for resolving our different views. It's not easy, but have patience. One partial resolution is renaming Harvc. (More on that later.)
My prior comment seems to have been a bit ambiguous. What Trappist rejected was not your "one template" approach, but my suggestion for an |in= parameter.
As to appropriate modularity: although I have not dabbled in Lua (and am reluctant to even look at the template coding), I am an experienced programmer, with a deep appreciation of "appropriate modularity". I am also quite familiar with human factors, such as why people use (or not) the tools made available. And it is in this regard that, quite aside from all issues of coding (which should be transparent to the users), adding a hybrid third template (like Harvc) is more complicated (for the users) than using a pair of existing templates. ~ J. Johnson (JJ) (talk) 21:38, 30 April 2015 (UTC)

Vancouver style error[edit]

The recent module update that included the changes discussed in name-list-format is now generating a enormous number of "Vancouver style errors" which I think are unintended. RomanASCII. ASCII is a subset of Roman characters. Roman characters include characters with diacritical marks. I am no expert on character sets, but allowed Roman characters would seem to include Unicode characters in the range of 0000 to 036F (Latin character set) and exclude Unicode 0370 and higher (Greek, Cyrillic, Arabic, etc.). PubMed which uses Vancouver style authors and is the source of the citation data that is used in many Wiki articles, clearly allows for extended Roman characters in author names (see for example, PMID: 15196329). Boghog (talk) 13:11, 21 March 2015 (UTC)

I'm not sure that characters with diacritical marks are included in the Roman characters. I've been watching for the introduction of a new law about vital records in my state, and the last time they tried, they wanted to restrict names on birth certificates to Roman letters, which was interpreted to exclude diacritical marks. Since our so-called Vancouver style is only quasi-Vancouver, I would think we would want to allow diacritical marks, regardless of whether the official Vancouver style guide (if such a thing exists) allows them or not. Jc3s5h (talk) 13:24, 21 March 2015 (UTC)
The Romanization requirement is in what appears to be the Vancouver style guide.
Trappist the monk (talk) 13:34, 21 March 2015 (UTC)
OK, I now see that the The NLM Style Guide for Authors, Editors, and Publishers states Ignore diacritics, accents, and special characters in names. (e.g., Å treated as A). However PubMed does not follow this recommendation and NLM/PubMed is the de facto Vancouver System standard (see Vancouver_system#History) and is also the source of much of Wikipedia's citation data. I think we should follow PubMed practice and allow extended Roman characters. The alternative is to replace these characters but this would cause an enormous amount of work with no real benefit to our readers. Boghog (talk) 13:41, 21 March 2015 (UTC)
I agree with Jc3s5h, we should allow diacritical marks regardless. Boghog (talk) 13:41, 21 March 2015 (UTC)
If PubMed uses diacritical marks, we should consider hiding this red error message until we come to a consensus on whether to permit or eliminate (and how to eliminate, if we so choose) the marks from existing articles that use the Vancouver style. (I am amending this comment to say that there are currently 16 articles in Category:CS1 errors: Vancouver style, a number that will surely grow, but which I would not classify as "enormous".) – Jonesey95 (talk) 15:05, 21 March 2015 (UTC)
  • The module was just updated. Existing articles must be edited for purged before the error message occurs. Also there is a lag between when an error displayed in an article and when it shows up in the CS1 error category. I guarantee you that within a few days, this number will be huge. Boghog (talk) 15:20, 21 March 2015 (UTC)
  • The use of extended Latin characters in citation authors in Wikipedia is wide spread and has been so for a very long time. Tools and bots that generate citations that support extended Latin characters include WP:REFTOOLS, User:Diberri/Template filler, and User:Citation bot. Clearly the current consensus is that extended Latin characters are allowed. A new consensus would need to be established to classify extended Latin characters as citation errors, even if these errors are only generated when |name-list-author=vanc is invoked. Even PubMed doesn't follow this particular author style recommendation. Why should we? Boghog (talk) 15:54, 21 March 2015 (UTC)
Use of foreign letters in an English context still presents problems of classification and sortng, but it's not like the "old" days when many publications could not even produce diacritical and other foreign letters. But modern typography is more capable, and even on the English Wikipedia there is a trend to a more global orthography. {{Citation}} already accomodates diacrticals, Vancouver style should not be an exception. ~ J. Johnson (JJ) (talk) 20:34, 21 March 2015 (UTC)
Agreed. The NLM Style Guide states, "Ignore diacritics, accents, and special characters in names ... to simplify rules for English-language publications." However displaying diacritical marks is no longer a technical problem using modern publication methods. Hence this particular NLM guideline is antiquated and is no longer followed even by PubMed. While non-Latin characters must be romanized in Wikipedia (see MOS:ROMANIZATION), Latin diacritical marks are allowed (MOS:DIACRITICS). In addition, by using metadata, someone might want to transfer Vancouver style references to another article that uses the default CS1 style that allows diacritical marks. Stripping out the diacritical marks from the Vancouver style references represents an unnecessary loss of information that will adversely impact the transferability of these citations into different citation formats. Boghog (talk) 14:11, 22 March 2015 (UTC)
Yes. If there is any real need to dediacriticise (!) perhaps that could be done with a template, thus preserving the fuller form. ~ J. Johnson (JJ) (talk) 20:15, 22 March 2015 (UTC)
Unicode 0x0000–0x036F consists of seven defined groups:
  1. 0000–007F C0 Controls and Basic Latin (C0 Controls: 0000–0020)
  2. 0080–00FF C1 Controls and Latin-1 Supplement (C1 Controls: 0080–00A0 & 00AD)
  3. 0100–017F Latin Extended-A
  4. 0180–024F Latin Extended-B
  5. 0250–02AF IPA Extensions
  6. 02B0–02FF Spacing Modifier Letters
  7. 0300–036F Combining Diacritical Marks
It would seem that if we choose to disregard the NLM Style Guide then the range of characters that we allow should be 0021–007F, 00A1–00AC, 00AE–024F.
Trappist the monk (talk) 12:29, 23 March 2015 (UTC)
Yes, those ranges make sense. Per MOS:ROMANIZATION, shouldn't this restriction not only apply to |author-name-list=vanc but also to the default author format? Although before expanding the scope of the check, I think we would need wider consensus. Just for curiosities sake, implementing this type of check in standard Lua appears non-trivial. Can this be done with something like utf8.find? Boghog (talk) 14:37, 23 March 2015 (UTC)
This whole test was added because it was pointed out that the NLM Style Guide (Vancouver) requires Romanization. It would seem, if we are to apply MOS:ROMANIZATION to non-Vancouver-style author/editor names, then MOS:ROMANIZATION should also apply to everything else in a CS1/2 citation. If that is the case then there can be no titles in Cyrillic, Japanese, Hebrew, Thai, etc and there are a lot of those.
Though kind of ugly, this might work:
for codepoint in mw.ustring.gcodepoint( s ) do
	if 33 > codepoint					-- C0 controls
		or 128 >= codepoint and 160 <= codepoint	-- most C1 controls
		or 173 == codepoint				-- odd-man-out C1 control
		or 591 < codepoint then				-- codepoints beyond Latin Extended-B
			-- error message stuff
We might simplify and just accept everything below codepoint 592 (0x0250) on the theory that C0 and C1 controls would be an unlikely part of a name.
Trappist the monk (talk) 15:26, 23 March 2015 (UTC)
Ah, thanks. With the mw.ustring library, it is still somewhat messy, but not as difficult as I first thought. Boghog (talk) 17:07, 23 March 2015 (UTC)
Some editors are starting to Romanize author names to eliminate these errors and there appears to be a developing consensus that this is unnecessary. Is there any way the current error message can be suppressed until a solution that has consensus has been implemented? The only argument that has been advanced in favor of the error message is the NLM Romanization guideline and there appears consensus above that we should ignore this particular guideline. Furthermore no one has raised any objections to following PubMed practice of using extended Latin characters. Boghog (talk) 17:06, 24 March 2015 (UTC)
I concur. There is no urgency regarding this "error", and prompting editors to make changes where matters are yet unsettled leads to instability and confusion. ~ J. Johnson (JJ) (talk) 22:47, 24 March 2015 (UTC)

@Trappist the monk: Please suppress this error message. In the mean time, I have boldly warned editors to ignore this message. Boghog (talk) 20:21, 26 March 2015 (UTC)

With your bold warning, is it really necessary to dump a couple of million pages onto the job queue for simply changing hidden = false to hidden = true?
OK, thanks for your reply. I thought there might be a way of suppressing the message that didn't require modifying the template code. I will be patient. Boghog (talk) 19:01, 27 March 2015 (UTC)
It occurred to me this afternoon while I was doing something completely unrelated that we can still use the lua patterns to solve this problem. The above code snippet is really pretty ugly and in fact would have gotten uglier. This pattern that I concocted in the debug window is, I think, better:
=mw.ustring.find("a Ëb-c ɏÝ'a", "^[A-Za-zÀ-ÖØ-öø-ƿDŽ-ɏ%-%s%']*$")
The pattern includes, I think, all the letters in the Latin range of 0000–024F, jumping over things like × (00D7) and ÷ (00F7) etc.
Trappist the monk (talk) 00:53, 27 March 2015 (UTC)
I am ignorant on the specifics of Lua, but I believe that in many programming languages the mappinng/ordering of characters is dependent on a locale setting. Is that a factor here? ~ J. Johnson (JJ) (talk) 04:23, 27 March 2015 (UTC)
I don't think so.
I have managed to try the pattern I identified above, not without some struggle. It seems that the code editor gets confused regarding character and cursor position – I could put the cursor at a place, and the next character I typed ended up in some other position. Writing the line here and then copy/pasting it there worked.
Cite book compare
{{ cite book | name-list-format=vanc | last=Waśniowska | first=J. Paul | last2=Gómez-Coronado | last3=Kühme | title=Title | last4=DŽǻlĕç | first2=Suárez | first4=d | first3=T }}
Live Waśniowska JP, Gómez-Coronado S, Kühme T, DŽǻlĕç d. Title. 
Sandbox Waśniowska JP, Gómez-Coronado S, Kühme T, DŽǻlĕç d. Title. 
This appears to work. The first three names are taken from article space, the last one is concocted from various letters in the four Latin code sets.
Trappist the monk (talk) 13:46, 27 March 2015 (UTC)
Your solution looks brilliant! Thanks :-) Boghog (talk) 19:04, 27 March 2015 (UTC)

I have discovered and fixed an error in reduce_to_initials() that produced � for author initials when the first character of the name was not in the set [A-Za-z]:

{{cite news/new|title=title|name-list-format=vanc|last1=González|first1=Ángel}}
González Á. "title". 

Trappist the monk (talk) 16:22, 4 April 2015 (UTC)

Add a 'volume-b=' parameter that skips the four-chr test for bolding?[edit]

I just learned from a discussion above that bolding of |volume= is conditioned on having four or fewer characters. I don't know why that limit was picked; presumably it serves some useful purpose. But it does lead to some inconsistent results. Would it be possible to have something like |volume-b= that would be identical to Volume= in all respects except that it skips the the four-chr test, and thus always does bolding? ~ J. Johnson (JJ) (talk) 21:53, 22 March 2015 (UTC)

Some history. The suggestion to wrap the volume value in wikimarkup (|volume='''MCMLXXXIV''') corrupts the COinS metadata so that shouldn't be considered as a way to get around this 'constraint'.
Trappist the monk (talk) 00:03, 23 March 2015 (UTC)
For sure a parameter value should never include wikimarkup. But that is irrelevant to what I am asking. The current code already generates bolded output, and apparently without corrupting COinS. What I am asking should make no difference in how such bolding is done, only in when the existing test is applied. ~ J. Johnson (JJ) (talk) 00:15, 24 March 2015 (UTC)
Trappist the monk: while this is not an urgent matter, I hope that will not entirely overlooked. It should be simple to implement (just a test condition), and its availability should reduce the "need" and tendency of editors to add wikimarkup to force bolding. ~ J. Johnson (JJ) (talk) 21:23, 4 April 2015 (UTC)
I've changed my position with regard to wikimarkup in |volume=. We allow constructs like this in |title=:
{{cite journal | ref=harv | last=Cody | first=William J. | title=''Adiantum pedatum'' ssp. ''calderi'', a new subspecies in northeastern North America | journal=[[Rhodora (journal)|Rhodora]] | volume=85 | issue=841 |date=January 1983 | pages=93–96 | url=}}
Cody, William J. (January 1983). "Adiantum pedatum ssp. calderi, a new subspecies in northeastern North America". Rhodora 85 (841): 93–96. 
and there is code in the module that strips the apostrophe markup from the title value before it becomes COinS:
so, why not use that same code to render the value in |volume= COinS-safe as well?
Trappist the monk (talk) 23:58, 4 April 2015 (UTC)
Why don't we just drop the bold completely, regardless of character count? Imzadi 1979  01:24, 5 April 2015 (UTC)
Volume numbers, which are especially significant for serials and journals, are often overlooked on account of being so short, wherefore they are commonly bolded so they are more readily seen in long citations.
There often is a need to specifically apply italicization, perhaps even bolding, within a title, just as there is often a need for special characters and raised or lowered text. But I am against encouraging use of wikimarkup in the templates generally, as it confuses the display and data functions. (It is a really bad practice in respect of database systems.) I could possibly accept 'volume' as another exception, but it rankles me. ~ J. Johnson (JJ) (talk) 21:18, 5 April 2015 (UTC)
Editors will use wikimarkup. I don't think that we're going to get them to not use wikimarkup except in places where it is obviously detrimental to the function of the citation. Since we must accept wikimarkup in titles, doing so for |volume= isn't too difficult because editors will sometimes use |volume= as an extension of a title:
{{cite book|last=Tolkien|first=J. R. R.|title=The Lord of the Rings (50th Anniversary Edition)|year=2004|publisher=Houghton Mifflin Company|volume=''The Return of the King''|pages=747–748}}
Tolkien, J. R. R. (2004). The Lord of the Rings (50th Anniversary Edition). The Return of the King. Houghton Mifflin Company. pp. 747–748. 
Here it isn't bold, it's italics (of course using |volume= for the title of a book in a series is problematic because COinS doesn't support volume for books; it does for journals). That makes me think that sometime down the road someone is going to want |volume-i=.
Properly written, and COinS compatible, the citation above could be:
{{cite book|last=Tolkien|first=J. R. R.|series=The Lord of the Rings |edition=50th Anniversary |year=2004 |publisher=Houghton Mifflin Company|title=The Return of the King |pages=747–748}}
Tolkien, J. R. R. (2004). The Return of the King. The Lord of the Rings (50th Anniversary ed.). Houghton Mifflin Company. pp. 747–748. 
I know that there has been some debate about styling of series' titles. I don't know what the result of that debate was but I could easily imagine that there are clear cases for styles and unstyled. If that's the case then we should also strip wikimarkup from |series=.
Trappist the monk (talk) 00:11, 6 April 2015 (UTC)
Perhaps not the best example. When "works" (books) are split into volumes those are usually numbered, with one title for the entire work. When a work consists of volumes separately titled, the work is a series. It is confusing that the generic workhorse |title= can be used for chapter, article, volume, book, work, and series, all with differing nuances of display. Perhaps it would help to have more specific title parameters. But (as I was just saying) there is a need to apply special formatting in some titles, so we are stuck with having to allow wikimarkup (or html?) in some cases. So much as I deplore this: perhaps it would be simpler (in terms of use) to generally allow some markup across all parameters. However, there will be greater problems trying to maintain consistency if editors can individually customize their references. ~ J. Johnson (JJ) (talk) 20:15, 6 April 2015 (UTC)
Wikimarkup is simple to deal with and even titles like this aren't so bad:
|title=Tracing H<sub>2</sub> Via Infrared Dust Extinction
Alves, J.; Lada, C.; Lada, E. (2001). Tracing H2 Via Infrared Dust Extinction. Cambridge University Press. p. 217. ISBN 0-521-78224-4. 
but then we get titles like this:
|title=A Parallactic Distance of <math>389^{+24}_{-21}</math> Parsecs to the Orion Nebula Cluster from Very Long Baseline Array Observations
Sandstrom, Karin M.; Peek, J. E. G.; Bower, Geoffrey C.; Bolatto, Alberto D.; Plambeck, Richard L. (2007). "A Parallactic Distance of 389^{+24}_{-21} Parsecs to the Orion Nebula Cluster from Very Long Baseline Array Observations". The Astrophysical Journal 667 (2): 1161. arXiv:0706.2361. Bibcode:2007ApJ...667.1161S. doi:10.1086/520922. 
Fortunately there aren't that many instances of this second type:
insource:/\| *title *=[^\|\}]*\<math/
Still, these lurk in the back of my mind as something that needs to be addressed.
Trappist the monk (talk) 22:05, 6 April 2015 (UTC)
Yes, that's the kind of stuff I was thinking about. The variations in how Sandstrom et al. is cited suggests that COinS might be ineffective is such cases, so perhaps it doesn't matter much how this markup gets flattened. ~ J. Johnson (JJ) (talk) 22:40, 6 April 2015 (UTC)

Trappist the monk, Imzadi1979: If use of wikimarkup (specifically, apostrophes) in parameters is acceptable (yuck), then there is no need for 'volume-b'. But to make that determination, should we have an RfC? ~ J. Johnson (JJ) (talk) 22:17, 8 April 2015 (UTC)

For the moment I guess I have no opinion with regard to an RfC.
Trappist the monk (talk) 11:21, 9 April 2015 (UTC)
Are the three of us sufficient to decide whether the use of apostrophes in |volume= should be acceptable? Do we have sufficiently broad scope of view to not miss some important consideration, or should we request comments from others? I lean some what in that direction, so will consider what question should be formulated. ~ J. Johnson (JJ) (talk) 20:34, 10 April 2015 (UTC)
I still have no opinion on the matter. If you want an RfC, do so. I have done nothing with the code that handles |volume= and likely won't before I freeze the current changes in advance of the next update.
Trappist the monk (talk) 23:26, 10 April 2015 (UTC)
Nah, let's just fake it. So in regard of getting the value of |volume= bolded when it has more than four characters: we have a consensus (of sorts) that using apostrophes (wikimarkup) is an acceptable work-around. In view of that, and the backlog of other work, we can close this discussion. ~ 21:06, 11 April 2015 (UTC)

cite arxiv[edit]

In considering how best to migrate {{cite arxiv}}, I have answered this feature request. |class= is used in {{cite arxiv}} to append the assigned value to the arxiv identifier. If |arxiv= is empty or omitted, |class= is ignored. There is no error checking of the value assigned to |class=.

Indelicato, Paul (2004). "Exotic Atoms". Physica Scripta T112 (1): 20–26. arXiv:physics/0409058 [physics.atom-ph]. Bibcode:2004PhST..112...20I. doi:10.1238/Physica.Topical.112a00020. 

{{cite arxiv}} is an odd duck. In its current guise it is {{cite journal}} without a proper journal title though it uses the {{citation/core}} meta-parameter |Periodical= to hold the external link to the arXiv page.

{{cite arxiv}} has some parameters that are new to Module:Citation/CS1:

  1. |class= – mentioned above
  2. |eprint= – apparently an alias of |arxiv=
  3. |version= – not actually new to the module but used in a different way. In the module, |version= is an alias of |serial= and is used in other CS1/2 templates to identify different versions of things in the rendered citation. In relation to arxiv identifiers, |version= is a suffix on the arxiv identifier that specifies which version of the paper the identifier identifies. I propose to deprecate this parameter in {{cite arxiv}} so that it is included in |arxiv= (arxiv error checking already supports this).
  4. |use ampersand before last author= – really, it's there; same as |last-author-amp= so I propose to deprecate it.

Apparently, {{cite arxiv}} can be filled by bot if |title= and all of the |author= parameters are empty and if the citation contains |arxiv= or |eprint=. The bot that does this work isn't identified so if anyone knows which bot that is, and if it is still alive, please tell us so that we can add its name to the documentation.

When editors rely on the bot to fill the template, the template code invokes {{citation/core}} to render a link to the arxiv page with a message saying that a bot will soon fill the template. That won't work so nicely with the module which will emit a missing title error message. This code needs to be rewritten so that the appropriate message is rendered but the module isn't invoked.

I don't quite know yet what to do about the COinS metadata. Currently, this template:

Mashnik, Stepan G. (2000). "On Solar System and Cosmic Rays Nucleosynthesis and Spallation Processes". arXiv:astro-ph/0008382 [astro-ph]. 

produces this jibberish for rft.jtitle:


This may be a case where we just name the 'journal' arXiv and produce this:


For the |arxiv= identifier, the module produces this metatdata:


which it would also do for {{cite arxiv}} once it has migrated.


Trappist the monk (talk) 15:50, 30 March 2015 (UTC)

The bot that does this work isn't identified – perhaps not well identified, but in the first line under the Usage heading, "a bot" is a piped link to User:Citation bot - Evad37 [talk] 16:04, 30 March 2015 (UTC)
So it does, I've tweaked it.
Trappist the monk (talk) 16:27, 30 March 2015 (UTC)

I've created {{cite arxiv/new}} which mimics the way the current {{cite arxiv}} works. The new version doesn't invoke Module:Citation/CS1/sandbox unless both |title= and |last= (or one of its aliases) are set. In contrast, {{cite arxiv}} always invokes {{citation/core}}. To mimic the old version, the new adds an external link to the output using the value provided in |arxiv= or |eprint=. The output for {{cite arxiv/new |arxiv = physics/0409058}} looks like this:

A bot will complete this citation soon. <small>[ Click here to jump the queue]</small>[[Category:Articles with missing Cite arXiv inputs |Citation Style 1]] [[arXiv]]:[// physics/0409058].

which renders as (category commented out):

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

Trappist the monk (talk) 18:41, 30 March 2015 (UTC)

(e/c) I agree with points 1 through 4 above. I have seen Citation Bot fill in one of these templates recently, so that piece of the system does work. {{Cite doi}} emits a similar message about the bot when you create a new template that contains only a DOI value, although the template is structured differently, with only a single unnamed parameter.
Emitting "arXiv" as the journal may not be appropriate, but I can't tell. Some arXiv articles contain a "journal reference", presumably to indicate that the article, or a version of it, was published in a peer-reviewed journal. Maybe we emit "arXiv" unless |journal= is filled in?
Trappist, thanks for taking on these migrations. I know you get a lot of static for it since you are the main programmer, but I think that the changes that have been made to the CS1 templates over the last two years have dramatically increased the consistency and accuracy of CS1 citations in hundreds of thousands, if not millions, of articles. – Jonesey95 (talk) 18:50, 30 March 2015 (UTC)
If the arXiv article has a journal reference, we should be using {{cite journal}} (with |arxiv= filled in) not {{cite arxiv}} (which should only be for preprints that do not also have a more definitive published form). So I think using "arXiv" as the journal should be ok. —David Eppstein (talk) 19:52, 30 March 2015 (UTC)
I was just coming to that. {{cite arxiv}} has associated categories
Category:Articles with missing Cite arXiv inputs – I suspect that Citation bot uses the content of this category
Category:Articles with a journal parameter in their Cite arxiv templates – can go away and be replace with an error message? add to Category:CS1 errors: arXiv?
Category:Articles with a publisher parameter in their Cite arxiv templates – also goes away?
I think that if either of |journal= or |publisher= is set (or their alias), the module should set them to empty strings, and then emit an appropriate error message. There wouldn't be any periodical in the rendered citation, but the COinS would get &rft.jtitle=arXiv (this parameter usually holds the periodical name).
Trappist the monk (talk) 20:19, 30 March 2015 (UTC)
Perhaps like this, and, perhaps, |url= should be added to the list of parameters not supported by the new {{cite arxiv}}:
Cite arXiv compare
{{ cite arXiv | last=Conte | date=2002 | class=quant-ph | journal=Proceedings Fundamental problems of Sciences, 271-304, S. Petersburg 2002 | arxiv=0711.2260 | title=A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics | url= | first=Elio | pages=271-304 | accessdate=3 March 2014 }}
Live Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". arXiv:0711.2260 [quant-ph].  Unsupported parameter(s) in cite arXiv (help)
Sandbox Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". arXiv:0711.2260 [quant-ph].  Unsupported parameter(s) in cite arXiv (help)
Trappist the monk (talk) 21:57, 30 March 2015 (UTC)
In comparison to all of the other CS1/2 templates, {{cite arxiv}} is quite limited in what it supports. Along with the aforementioned |journal=, |publisher=, and |url=, there are |access-date=, |page=, |pages=, and |at=. It does support |format= but shouldn't; it supports all of the usual identifiers but probably shouldn't. I have to think about this some more.
Trappist the monk (talk) 00:00, 31 March 2015 (UTC)
Ok, rather than have the error message list the unsupported parameter(s), I've opted to create a simpler error message. The list of unsupported parameters and an explanation will be available at the Help:CS1 errors. The test for unsupported parameters includes all of the special identifiers (ISBN, doi, etc) but doesn't set them to empty strings.
I've also added an error message for the case where |arxiv= is missing or empty:
Cite arXiv compare
{{ cite arXiv | last=Conte | title=A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics | date=Nov 2007 | first=Elio }}
Live Conte, Elio (Nov 2007). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics".  |arxiv= required (help)
Sandbox Conte, Elio (Nov 2007). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics".  |arxiv= required (help)
With that then, I think that this migration is done. See Template:Cite arxiv/testcases and add more if you see something that should be tested.
Trappist the monk (talk) 13:46, 31 March 2015 (UTC)
I have notified Wikiproject Astronomy, Wikiproject Mathematics, and Wikiproject Physics about this discussion. Feedback from the actual users of this template will be helpful. – Jonesey95 (talk) 15:05, 31 March 2015 (UTC)
- I'm not sure if this will just automatically work once {{cite arXiv}} gets migrated, so, just in case: |display-authors= isn't recognized currently, and the citation auto-truncates to 8 authors. Also, I support points 1-4.
- Concerning |journal= or |publisher= in {{cite arXiv}}, I agree with David Eppstein and Trappist - I think it would be better to produce an error message, or at least a maintenance category/message to convert a {{cite arXiv}} to {{cite journal}} (I've seen variants of |publisher=arXiv though..., which could be made to emit an error as well?). If {{cite arXiv}} were to accept |journal=, then it would make sense to duplicate most of the other {{cite journal}} parameters, but I don't think that's the right way to go. I think it'd make more sense to make {{cite journal}} a wrapper around {{cite arXiv}} (if I'm using the term properly), than the other way around. {{cite arXiv}} should be reserved for papers not yet published in a {{cite journal}}. A potential problem is that arXiv eprints are not always word-for-word copies of their published peer-reviewed counterparts, but the differences are generally minor.   ~ Tom.Reding (talkcontribsdgaf)  16:28, 31 March 2015 (UTC)
Setting |displayauthors=4 seems to work in the new version; as an example I've added |publisher=Publisher (should show an error):
Cite arXiv compare
{{ cite arXiv | author8=Bertaux, J.-L. | author6=Pepe, F. | author9=Bouchy, F. | class=astro-ph.EP | author5=Ségransan, D. | author7=Benz, W. | author4=Udry, S. | eprint=1109.2497 | displayauthors=4 | author=Mayor, M. | date=2011 | author14=Santos, N. C. | author13=Queloz, D. | publisher=Publisher | title=The HARPS Search for Southern Extra-solar Planets XXXIV. Occurrence, Mass Distribution and Orbital Properties of Super-Earths and Neptune-mass Planets | author12=Mordasini, C. | author11=Lo Curto, G. | author2=Marmier, M. | author10=Dumusque, X. | author3=Lovis, C. }}
Live Mayor, M.; Marmier, M.; Lovis, C.; Udry, S. et al. (2011). "The HARPS Search for Southern Extra-solar Planets XXXIV. Occurrence, Mass Distribution and Orbital Properties of Super-Earths and Neptune-mass Planets". arXiv:1109.2497 [astro-ph.EP].  Unsupported parameter(s) in cite arXiv (help)
Sandbox Mayor, M.; Marmier, M.; Lovis, C.; Udry, S. et al. (2011). "The HARPS Search for Southern Extra-solar Planets XXXIV. Occurrence, Mass Distribution and Orbital Properties of Super-Earths and Neptune-mass Planets". arXiv:1109.2497 [astro-ph.EP].  Unsupported parameter(s) in cite arXiv (help)
To convert {{cite arxiv}} to {{cite journal}} (once the paper has been published) is a simple matter of changing the template name and adding or deleting the relevant details – as you say, the preprint may not accurately reflect the final published paper.
Trappist the monk (talk) 16:50, 31 March 2015 (UTC)

In the COinS, the module version will report the title's genre as &rft.genre=preprint. The change to support this may allow us to refine COinS data for the other CS1 templates.

Trappist the monk (talk) 11:17, 6 April 2015 (UTC)

Forgive me if I'm being stupid, but isn't it always better to use {{cite journal|arxiv=xxx}} than {{cite arxiv|eprint=xxx}} anyway? In the former case Citation bot automatically fills out the journal details if and when the preprint is published, and it ensures full compliance with all the normal formatting used by {{cite journal}} and support for all the existing parameters. Is there any reason to maintain a separate template for this? It seems rather pointless to duplicate everything. Could {{cite arxiv}} not be deprecated entirely, or converted into a simple wrapper for {{cite journal}}? Modest Genius talk 22:11, 9 April 2015 (UTC)

Are you sure about that? {{cite journal}} doesn't have the auto-filling-by-bot code that {{cite arxiv}} has. Infact, creating a {{cite journal}} with just |arxiv= creates missing or empty title errors.
If an editor is citing a paper that hasn't been published, or if the editor is citing a version of the paper that is a preprint (because that's the WP:SAYWHEREYOUGOTIT paper) and not citing the published version, then the editor is correct to use {{cite arxiv}}. According to the arXiv article, some papers never make it out of preprint so, for those papers ever languishing in the arXiv limbo, {{arxiv}} is the correct template.
Trappist the monk (talk) 22:54, 9 April 2015 (UTC)
Whenever I use a {{cite journal}} I enter a single ID and then hit 'expand citations'. The bot is supposed to do it after some time if I forget to hit the button, but I haven't tested whether that's working in practice. If it's a preprint that hasn't been published yet the template still works fine so long as e.g. the title gets filled out by the bot.
I'm unconvinced by the need to specifically cite the preprint rather than the final publication, because a) many editors read the arxiv version simply because that is the green open access copy of the final publication (rather than a preliminary version) and thus citing the real thing is preferably (as there are many other ways of accessing it) and b) If some claim was present in a pre-reviewing arxiv posting but not in the final publication then must have been found to be deficient during the peer review process, so we really shouldn't be citing it.
Of course I still might be missing something here. Modest Genius talk 23:22, 12 April 2015 (UTC)
Update: I just did a quick sandbox test, and it was in fact the bibcode that behaves the way I was thinking, not the arxiv ID (which I had to add manually). Note however that the formatting of the final result was superior in the {{cite journal}} case, whilst the {{cite arxiv}} ended up with the wrong year of publication(!) but had a nicer clickable link. It's unclear to me whether it would be easier to get Citation bot to look up arxiv IDs in {{cite journal}}, or make changes to {{cite arxiv}} to mirror all the other desired functionality. I suspect the former but am no expert on bots. Modest Genius talk 23:34, 12 April 2015 (UTC)
There is no facility in {{cite journal}} to notify Citation bot that a journal citation needs to be completed. That facility does exist for {{cite arxiv}}; the template leaves you a message in the article telling you: "A bot will complete this citation soon." The template also gives you a link to click if you want it done now. {{cite journal}} does not do this.
Whatever problems you are having with auto-filling are problems with the tool you are using, not with {{cite arxiv}} or {{cite journal}}. My guess for the different dates is that it's simply a matter of where the tool goes to get the data. Following the Bibcode link at your sandbox example takes you to a page that lists publication date as 02/2013; similarly, following the arXiv link takes you to a page that identifies the v1 version date as 30 October 2012. It would appear that the tool acted correctly.
Your sandbox example makes no use of {{cite arxiv}} so it is not clear to me how you can make any claims that it is better or worse than {{cite journal}}.
If an editor uses material found at arXiv in support of assertions made in a Wikipedia article, that is the source that should be cited. If the editor uses material found in a journal in support of assertions made in a Wikipedia article, that is the source that should be cited. The two may be identical; they may not. If the editor has read one but not the other, it is inappropriate to identify the unread material as the source supporting the Wikipedia article. Is this not what WP:SAYWHEREYOUGOTIT is all about?
Trappist the monk (talk) 00:35, 13 April 2015 (UTC)
The 'tool' I'm using is just citation bot. Yes cite arxiv does give you a handy link to it, whilst cite journal does not (I mentioned this above), but the bot fills both out eventually anyway. The year is incorrect because it gave volume and page numbers that didn't exist until 2013 - in this case 2012 would refer to the preprint only and not the final journal publication. Oh and yes I did use cite arxiv, it's just that when the bot fills it out it changes it to cite journal. It seems that cite journal is better for some things, and cite arxiv better for others. Surely combining the best bits into a single template is easier to maintain than two separate but very similar templates? Modest Genius talk 17:43, 13 April 2015 (UTC)
So you did; I missed the (4 intermediate revisions by 2 users not shown) text.
The bot clearly fetches some information from the arXiv page which you can see if you compare the completed template page parameter with the page information at the arXiv page. But, this talk page isn't about Citation bot; if it is fetching incorrect information, regardless of the CS1 template being used, that topic should be raised at the bot's discussion page because it won't be solved or addressed here.
I don't have a problem with the notion of combining the best bits into a single template when it makes sense to do so. But, here we have one template designed to cite published work and another designed to cite unpublished work. These two templates are to my mind, serving sufficiently different purposes to remain separate.
Trappist the monk (talk) 13:41, 14 April 2015 (UTC)

How to use "et al"?[edit]

Looking over the template dox, I see examples of the use of "et al" in long lists of names. It appears this is automated though, is there some way to do this manually? I have a conference paper with about 40 names in it, I only want the first one to appear, along with et al. Maury Markowitz (talk) 20:32, 1 April 2015 (UTC)

{{cite conference |title=Title |last=Last1 |first=First1 |last2=Last2 |first2=First2 |last3=Last3 |first3=First3 <!-- and as many more author names as you'd like to include --> |display-authors=1}}
Last1, First1 et al. Title. 
Trappist the monk (talk) 20:54, 1 April 2015 (UTC)
Ah ha! Ok, so if I put in only one author, and say |display-authors=1, do I get the et al? I'd test this myself, but the article is being edited offline in my text editor... Maury Markowitz (talk) 20:59, 1 April 2015 (UTC)
You could test it here, click show preview, and see. But, since I'm here I'll show you that no, that doesn't work, pretty much as you'd expect.
{{cite conference |title=Title |last=Last1 |first=First1 |display-authors=1}}
Last1, First1. Title. 
Trappist the monk (talk) 21:22, 1 April 2015 (UTC)
Bummer. Suggestions on what such a beast would look like? |display=0 seems more confusing than useful. Maury Markowitz (talk) 21:35, 1 April 2015 (UTC)
You can still add two authors and set display authors to 1. --Izno (talk) 21:51, 1 April 2015 (UTC)
That's fooling the system, precisely what I would like to avoid. This should be a feature, not a workaround. Maury Markowitz (talk) 02:50, 2 April 2015 (UTC)
[ec] The "et al." doesn't come up unless have at least one more author than display-authors. E.g., adding last2 and first2 to the above code gives us:
Last1, First1 et al. Title. 
But note that your full citation really should list at least three authors. (Some style conventions (including APA?) will add "and 37 others" instead of "et al.") The "Last, et al." would be in an in-line short cite, such as created by harv. ~ J. Johnson (JJ) (talk) 22:07, 1 April 2015 (UTC)

Sure, but I'm simply not going to type in all 37 to get the "and 37 others" tag. Since the cite will only list one author, and the citeref refers only to that author, I shouldn't have to list all the rest just to get the template to display the way it's going to in the end anyway. Maury Markowitz (talk) 02:48, 2 April 2015 (UTC)

Maury Markowitz: I just showed you how to get the 'et al.' with just two authors. Look at the wikisource. (Though, as I said, you really should have at least three/four. See below.) ~ J. Johnson (JJ) (talk) 21:00, 2 April 2015 (UTC)
@Maury Markowitz: you can put the 1st author in |author1=, set |display-authors=1 (as suggested above), and copy & paste the remaining authors into |author2= as long as they're either comma or semicolon delimited. Then I, or someone with a similar script, can enumerate them into the appropriate # of authors. From all my citation cleanup, this seems to be the way it is being (hastily?) done. Whether or not there's a better way is a different story.   ~ Tom.Reding (talkcontribsdgaf)  14:14, 2 April 2015 (UTC)
The original problem that led me here was a PDF document that doesn't allow cut and paste of the text. :-) Maury Markowitz (talk) 14:19, 2 April 2015 (UTC)
I have that same frustration with paper books and newspapers. I can cut and paste, but then I can't see my whole computer monitor. – Jonesey95 (talk) 14:35, 2 April 2015 (UTC)

Because we now detect and categorize citations that include et al. in author and editor parameters, and because of this conversation, it occurs to me that we might create a couple of parameters, perhaps |more-authors= and |more-editors= that would append et al. to the author list if the parameter is set to yes or true. In this way, Editor Maury Markowitz could list only one of the bazillion authors, need only one author in {{sfn}} or {{harv}} templates, not corrupt the COinS metadata, nor fool the system.

Alternatively, perhaps we modify |display-authors= and |display-editors= by adding a keyword more that would append et al. to the appropriate name-list.

It would seem that either of these solutions would also provide a way of positively dealing with the 18,000+ pages in Category:CS1 maint: Explicit use of et al.

Trappist the monk (talk) 16:21, 2 April 2015 (UTC)

I strongly agree that we should have a non-hacky way for WP editors to ask the citation to show "et al." without breaking the harv referencing or the metadata.
It would be nice to come up with a way to implement this that allowed us to sweep through those 18,000 articles and convert them elegantly to the new way. – Jonesey95 (talk) 16:52, 2 April 2015 (UTC)
Sort of like this:
|display-authors=Last1, First1. Title. 
|display-authors=1Last1, First1. Title. 
|display-authors=moreLast1, First1. Title.  Invalid |display-authors=more (help)
I have not implemented this for the editor name-list. Shall I proceed or revert?
Trappist the monk (talk) 16:58, 2 April 2015 (UTC)
I agree with both |display-authors=more and |more-authors=, and prefer the |display-authors=more solution since it uses an existing parameter in a non-conflicting way, is intuitive to use, and it's easy to remember.   ~ Tom.Reding (talkcontribsdgaf)  19:28, 2 April 2015 (UTC)
I agree with |display-authors=more for the reasons given by Tom.Reding. It would probably be useful to have a bit of error checking for |display-authors= to locate values that are not numbers or "more". I don't know what is done with |display-authors=blahblahblah now, but it should throw an error.
Testing |display-authors=blahblahblah : Smith, John. Title.  Invalid |display-authors=blahblahblah (help)
Nice work, Trappist. – Jonesey95 (talk) 02:02, 3 April 2015 (UTC)
Using a keyword of "etal" or similar might be more (heh) intuitive in the parameter than the word "more". I read "display-authors = more" in the sense of "display more of them!"... which obviously isn't the intent. --Izno (talk) 03:21, 3 April 2015 (UTC)
Currently supports keywords more and etal regardless of case. We should choose one. |display-editors= does not yet have this functionality.
|display-authors=moreLast1, First1. Title.  Invalid |display-authors=more (help)
|display-authors=etalLast1, First1 et al. Title. 
|display-authors=1Last1, First et al. Title. 
|display-authors=Last1, First; Last2, First2 et al. Title. 
|display-authors=blahblahblahLast1, First1. Title.  Invalid |display-authors=blahblahblah (help)
Trappist the monk (talk) 11:09, 3 April 2015 (UTC)
I've made a separate function so that both |display-authors= and |display-editors= use the same code. So, the keywords are now supported by |display-editors=:
|display-editors=moreLast1, First1 (ed.). Title.  Invalid |display-editors=more (help)
|display-editors=etalLast1, First1 et al. (eds.). Title. 
|display-editors=1Last1, First1 et al. (eds.). Title. 
|display-editors=Last1, First1; Last2, First2; Last3, First3 et al. (eds.). Title. 
|display-editors=Last1, First1 et al. (eds.). Title. 
|display-editors=Last1, First1; Last2, First2 et al. (eds.). Title. 
|display-editors=blahblahblahLast1, First1 (ed.). Title.  Invalid |display-editors=blahblahblah (help)
We need to remember to revisit this code when Category:Pages using citations with old-style implicit et al. in editors has been cleared.
The code now uses the plural editor annotation whenever et al. is part of the rendered list.
Trappist the monk (talk) 12:56, 3 April 2015 (UTC)

This neatly solves the other issue I've had with the sfn's, which is the need to use CITEREF if there's a lot of authors to make the ref something typeable. I really like this mod. One suggestion though, perhaps the item after the = could be one of a number of different indicators? etal is the one I would use, but as you pointed out, others prefer a number. Maury Markowitz (talk) 12:50, 3 April 2015 (UTC)

I don't understand what you mean by one of a number of different indicators. In the sandbox code the value assigned to |display-authors= can be a number, which truncates the author name list and appends et al. or it can be a keyword that simply adds et al. to the end of the name list without truncation.
Trappist the monk (talk) 12:56, 3 April 2015 (UTC)

We have two options on the table for a keyword to add 'et al.' to an author/editor list. I'm inclined to agree with Editor Izno that |display-authors=etal should be preferred over |display-authors=more. While more is really simple in that it has only one spelling, it turns out that it isn't much more work to allow for a variety of etal spellings. Here are some variations on the etal theme:

|display-authors=etalLast1, First1 et al. Title. 
|display-authors=et alLast1, First1 et al. Title. 
|display-authors=etal.Last1, First1 et al. Title. 
|display-authors=et al.Last1, First1 et al. Title. 
|display-authors=''etal''Last1, First1 et al. Title. 
|display-authors=''et al''Last1, First1 et al. Title. 
|display-authors=''etal.''Last1, First1 et al. Title. 
|display-authors=''et al.''Last1, First1 et al. Title. 

So, more or etal?

Trappist the monk (talk) 17:16, 4 April 2015 (UTC)

I think etal is clearer, and I love the idea of allowing multiple forms of it in the parameter value. Editors will reasonably expect to be able to type et al or et al., especially since the latter is the recommended form in MOS. – Jonesey95 (talk) 23:04, 4 April 2015 (UTC)
I think that using |display-authors=etal (and silently allowing the variations) is the easiest solution. Imzadi 1979  01:28, 5 April 2015 (UTC)
Ok, |display-authors=more no more.
Trappist the monk (talk) 16:57, 5 April 2015 (UTC)

Adding retweet parameter to cite tweet and twitter status[edit]

Is there a way the templates for cite tweet and twitter status can be modified to note that the status was retweeted by a reliable source.

For instance:

{{Twitter status
  | user = DisneyChannelPR <!-- -->
  | statusid = 558343980690059264
  | title = Confirms Jimmy Weldon as voice of the Whoopty-Doopty-Schmoodily-Duck
  | name = Disney Channel PR
  | date = January 22, 2015
  | accessdate = April 3, 2015
}} Retweeted by Shea Fontana.

would become:

{{Twitter status
  | user = DisneyChannelPR <!-- -->
  | statusid = 558343980690059264
  | title = Confirms Jimmy Weldon as voice of the Whoopty-Doopty-Schmoodily-Duck
  | name = Disney Channel PR
  | date = January 22, 2015
  | accessdate = April 3, 2015
  | retweet = Shea Fontana

This would apply for the cases where the original tweeter's handle is not anyone particularly notable, but the reliable source person takes it and retweets it rather than tweeting a reply to it. -AngusWOOF (talk) 23:55, 2 April 2015 (UTC)

{{Twitter status}} is not a Citation Style 1 template. I suspect that the best place to discuss this is at the template's talk page.
Trappist the monk (talk) 00:21, 3 April 2015 (UTC)
No prob. I added the request to twitter status's talk page. Cite tweet's talk page redirected here so it'd be nice to know if someone can work on that template. -AngusWOOF (talk) 14:06, 3 April 2015 (UTC)
In {{cite tweet}}'s sandbox I've passed a new |retweet= parameter through to the |others= parameter in cite web, preceded by "Retweeted by":
  • Example code: {{Cite tweet/sandbox |user=Pigsonthewing |number=564068436633214977 |date = 7 February 2015 |quote=This is an example tweet. |retweet=Someone else }}
  • Example output: Pigsonthewing (7 February 2015). (Tweet). Retweeted by Someone else  Missing or empty |title= (help)
Is this the sort of thing you're after, AngusWOOF? - Evad37 [talk] 03:49, 4 April 2015 (UTC)
Yep, that would work! -AngusWOOF (talk) 04:21, 4 April 2015 (UTC)
The biggest criticism I have of {{cite tweet}} is that it links through the tweet number and relegates the content of the tweet to the optional quote parameter. Most citation guides say to include the full content of a tweet as the title of the tweet and not to display the tweet's number. At least one guide also advises using the real name of the author in addition to the Twitter account name, which should be preceded by the @. Imzadi 1979  07:01, 4 April 2015 (UTC)
If there's a way to make Twitter status compatible with CS1 I'd be all for that. Twitter status (as shown in my above example) allows for the title to summarize the tweet rather than force the exact quote which would introduce hashtags, links, and replies to non-notable users. -AngusWOOF (talk) 14:14, 4 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I've adjusted the sandbox version again, see the new testcases page. In addition to |retweet= as mentioned above, changes include:

  1. The default author value is @{{{user}}}. Setting |author= overrides this, so it can be set to the real name, or the real name together with the account name if desired
  2. |author-link= added, so the author can be linked to their Wikipedia page
  3. |title= added, for specifying a title for the tweet. Defaults to 'Tweet Number ...' if not specified.
  4. Access date now only set by |access-date= or |accessdate=, not by |date=
  5. |link= added, so that Twitter is unlinked when |link=no is set (as per {{Google maps}}) – when used multiple times in an article, only the first instance needs to be linked
  6. Error messages adjusted to say which parameters are missing, and moved to the end. Tracking category is only added in mainspace.

Any other comments or suggestions? - Evad37 [talk] 04:43, 6 April 2015 (UTC)

Just a minor comment: the title shouldn't be in quotes, otherwise it implies it is what is being tweeted. Also, does this mean the title and quote are both usable? -AngusWOOF (talk) 06:20, 6 April 2015 (UTC)
We need not reinvent the wheel here folks. CS1 was heavily based on APA style, and the APA Style Blog has already created guidelines on how to cite social media that we can easily adapt to handle citing tweets. Looking at them, I would suggest:
  • When the real name is known, it should be listed first with the user handle in square brackets: "Mabbett, Andy [Pigsonthewing]". (The APA says to drop the "@", but we could leave that in place.)
  • When the real name of the author is not known, only the user handle would appear without any bracketing: "Pigsonthewing".
  • The full tweet should be used as the title, which should appear in quotes as the title of the source.
  • Tweet numbers are meaningless, and any citation that lacks a full title should flag an error for correction. Citing just the ISBN for a book without the book title is just as meaningless to a reader. Yes, we could click the links to determine the title of the book, but it's just not a proper citation.
  • To solve the issue of multiple instances of "Twitter" being linked, I'd just drop the publisher completely and default to |type=Tweet. It may be a semantical distinction, but Twitter doesn't actually cause any tweets to be published; the user tweeting does. They merely host the content, just as Google Books hosts copies of scanned books, and we'd never say Google actually published the books. (It's possible that Google published content that they host on Google Books, but it's also possible that Twitter itself tweets.)
  • The quote parameter is superfluous as the full tweet should be given.
For additional ideas, we can consult guidelines from the MLA and the suggestion from the Chicago Manual of Style, although CMOS quotes the full tweet in the prose and omits it from the footnote, relying on a reader's ability to locate it from the Twitter feed. Imzadi 1979  07:12, 6 April 2015 (UTC)
These changes implement your suggestions. Another point for discussion: At the moment, if |user= or |number= is ommitted, a junk url such as{{{user}}}/status/{{{number}}} is passed through to {{cite web}}, and error messages regarding |user= and |number= are displayed. Another option would be to check the parameters, so that no url rather than a junk url is passed through – but not having a url results in the "Missing or empty |url=" error message, which is a bit deceptive as cite tweet doesn't have a |url= parameter. Any ideas on which is preferable, or if there is another option? - Evad37 [talk] 08:18, 6 April 2015 (UTC)
Actually, I've just noticed that the missing url error message is hidden by default, so now the code checks that the parameters have been set - Evad37 [talk] 09:55, 6 April 2015 (UTC)
Probably best that you don't rely on the missing url error remaining forever hidden. You might change the {{cite tweet}} code to something like this:
|url={{#ifeq: {{{number|}}}{{{user|}}} | {{{number}}}{{{user}}} |{{{user}}}/status/{{{number}}} | }}
Trappist the monk (talk) 10:46, 6 April 2015 (UTC)
Done - Evad37 [talk] 14:57, 6 April 2015 (UTC)
One other idea, but MLA uses a time in addition to the date, and it advises that the time zone should be that of the author of the paper, not the author of the tweet. Since Wikipedia is an international publication, if we did have a way to insert the time, I would suggest that we mandated UTC. (We don't use times in any other form of citations though, and I think the Lua module would see any attempt to add a time to a date as an error.) Imzadi 1979  07:17, 6 April 2015 (UTC)
Regarding whether titles and quotes be the same, I disagree. While the quote can contain the full tweet (without the hashtags as appropriate) the title should be without the quotes as it may be needed to explain the context, such as when a user says "Happy Birthday", and the tweeter replies "Thanks!" -AngusWOOF (talk) 16:59, 6 April 2015 (UTC)
@AngusWOOF: since the title of a tweet is the full tweet, hashtags and all, any quotation in the middle of that is superfluous to the full tweet, period.
In your proffered example, the context would require the citation of two separate tweets. You'd end up with something like <ref>{{cite tweet <details on first tweet...>}}<br/>{{cite tweet <details on reply tweet..>}}</ref>. To attempt to quote the reply while only citing the original one fails to attribute both authors, even if the link to the original tweet displays the reply. If the reply comes days after original, you'd have issues related to which date to use. By using separate citations, even if combined into the same footnote, you'd properly attribute each other and note the proper date(s) for what are separate tweets. Imzadi 1979  18:53, 6 April 2015 (UTC)
Yes, that would be needed if the tweets are not threaded, but in the case where it is threaded only the second tweet is necessary, as in this example: [1] But a double tweet in the ref would be fine. -AngusWOOF (talk) 18:59, 6 April 2015 (UTC)
There's still the same issue of attribution. Even in that case, you need the work of two separate authors to set up the context, and the template only supports one author because, by design, tweets only have a single author/account. I still think that even with the threading, you'd want to separately cite [2] followed by the reply to keep attribution and dates correct. There's a 6-hour gap between the original and the reply, putting them on separate days according to how Twitter displays them for me. Maybe in other time zones they'd appear to have the same date. Adding date support would require additional modifications to the Lua module that handles CS1 templates though. Imzadi 1979  19:45, 6 April 2015 (UTC)
If the quote and the title are to be the same, then it would be fine to exclude hashtags and @'s (and http:// links, similarly use ellipses) where it doesn't add to the content of the article. Would that make it CS1 compatible? As for the date, it should be mainly dependent on where the RS person in question is situated. This would work if the OP asks their question the day before (or after if they are in the Far East and the RS is in the United States) and is also consistent with news article time stamps coming from whoever posted the article. -AngusWOOF (talk) 01:59, 7 April 2015 (UTC)
Why would you drop the hashtags, at signs or the links? They're part of the content of the tweet, period. There's no compatibility issues to be worried about with the links, as Twitter drops the "http://" part of a URL in the displayed text. We wouldn't have any issue with the template/MediaWiki software recognizing a link in the middle of the title:
using that example from the APA Style Blog, and putting it in {{cite web}}, there isn't a need to drop any of the content. If we're going to do this, we should do it properly and reproduce the full tweet.
As of right now, we can't include publication times in CS1 citations. The Lua module checks the formatting and validity of the dates supplied, and there is no standardized way to handle a time of publication. Adding a time stamp to a citation, at the present, creates an error. For most sources, anything more precise than a day is not needed; for other sources like books, anything more specific than the year of publication is overkill.
Twitter, like other social media, is different from news articles. The date and time stamp on an article published on won't vary based on the time zone of the reader. CNN's time stamps are fixed based on their location in Atlanta, Georgia, United States. However, Twitter reports the date and time stamp on a tweet based on the time zone of the reader. Where I am located at the moment is UTC-5, so a freshly posted tweet would carry a date of April 6, 2015, and a time of 9:48 p.m. If I were located in London, that same tweet would appear with April 7, 2015 at 3:48 a.m. We can't assume or guess the original local time for the person writing a tweet, unless it's geotagged. Printed publications get around this because they'll default to the time zone of the author citing the tweet, which will be fixed because it is in print. If we ever added the capacity to include the time of a tweet, to minimize issues we should then specify that the time be given in UTC. Imzadi 1979  02:48, 7 April 2015 (UTC)
Well that a tweet has that character limit means quoting the entire thing shouldn't be an issue then. -AngusWOOF (talk) 04:25, 7 April 2015 (UTC)

I have updated the template, and fixed the resulting errors in the error tracking category - Evad37 [talk] 04:43, 10 April 2015 (UTC)

Time variable for Template:Cite tweet[edit]

Could we design a time= variable for this template? Tweets always include time-of-day tags and this could help put things in order if multiple tweets from the same day are cited within an article. Ranze (talk) 13:08, 4 April 2015 (UTC)

Cs1 template categories[edit]

In Category:Citation Style 1 templates there are a handful of templates that aren't part of the core suite. These are:

  1. {{Cita news}} – uses {{cite news}}
  2. {{Citar web}} – uses {{cite web}}
  3. {{Cite Merck Index}} – uses {{cite web}}
  4. {{Cite tweet}} – uses {{cite web}}
  5. {{Cite video game}} – uses {{cite journal}}
  6. {{Cytuj stronę}} – uses {{cite web}}
  7. {{Vcite2 journal}} – uses {{cite journal}}
Except for {{Cite Merck Index}}, these meta-templates aren't specific-source templates so don't belong in Category:Citation Style 1 specific-source templates‎. It would seem that for all of these but {{Cite Merck Index}}, we should create a new category Category:Citation Style 1 meta-templates‎.
identifier-based citations
  1. {{Cite doi}} – transcludes bot-created {{cite journal}} templates
  2. {{Cite hdl}} – transcludes other prefilled templates that may or may not be CS1 templates
  3. {{Cite isbn}} – transcludes other prefilled templates that may or may not be CS1 templates
  4. {{Cite jstor}} – transcludes bot-created {{cite journal}} templates
  5. {{Cite pmid}} – transcludes bot-created {{cite journal}} templates
These are all deprecated. I think that they should be placed in their own category outside of Category:Citation Style 1 templates; perhaps Category:Identifier-based citations as a member of Category:Citation templates.
  1. {{CitePMIDs}} – bundles {{cite pmid}} in {{#tag:ref}}; sort of an {{sfnmp}} for PMIDs
Because {{cite pmid}}, shouldn't this template also be deprecated? Because it is unconditionally linked to {{cite pmid}}, this template probably belongs in the identifier-based citations category.


Trappist the monk (talk) 14:35, 4 April 2015 (UTC)

Another option, which could be in addition to or instead of any of the options above, is to establish a "CS1 core templates" category that would include cite web, cite journal, and the other templates we list in the "official" CS1 table of templates. – Jonesey95 (talk) 14:45, 4 April 2015 (UTC)
Perhaps another, vaguely related issue is that meta-templates should not redirect their talk pages here because they are not CS1 templates. Yeah, I'm thinking about this because of the {{cite tweet}} conversations currently underway.
Trappist the monk (talk) 15:36, 4 April 2015 (UTC)

Category changes done. Instead of Category:Identifier-based citations I used Category:Identifier-based citation templates.

Trappist the monk (talk) 13:41, 7 April 2015 (UTC)

Today I noticed that all, most, a lot, of the CS1 error categories are also listed in Category:Articles with incorrect citation syntax. Is there any real reason for them to be listed there? The documentation on the category page doesn't apply to Module:Citation/CS1-based errors but to templates that use {{citation error}}. Because the category page has a 'see also' link to Category:CS1 errors, I see no reason for the CS1 error pages to be listed in both places.

Trappist the monk (talk) 17:28, 12 April 2015 (UTC)

separator suppression[edit]

At Module_talk:Citation/CS1/Feature_requests#Separator suppression is this example:

{{cite AV media |title=[[Whaam!]] |last=Lichtenstein |first=Roy}}

which renders as:

Lichtenstein, Roy. Whaam!.  – a period follows the exclamation point

Without all of the wrapping spans the raw output looks like this:

Lichtenstein, Roy. ''[[Whaam!]]''.

It occurs to me that terminal punctuation inside a wikilink or external link followed by another terminator (a period for CS1 or a comma for CS2) can be detected and the punctuation added by the Module can be easily removed. So I've hacked an experiment to test that notion:

{{cite AV media/new |title=[[Whaam!]] |last=Lichtenstein |first=Roy}}

which renders as:

Lichtenstein, Roy. Whaam!.  – no period
Lichtenstein, Roy, Whaam!, Publisher |mode=cs2; |publisher= so the module places a comma before removing it; compare live version of same:
Lichtenstein, Roy, Whaam!, Publisher  – has comma
Lichtenstein, Roy. Whaam!.  – no period, no wikilink
Lichtenstein, Roy. Whaam!.  – no period, using |title-link=Whaam!

Change to {{cite book}} and add |chapter=Baam?:

Lichtenstein, Roy. "Baam?". Whaam!.  – no periods

Because the module renders external links slightly differently from Wikilinks:

[// ''Whaam!''].

a different test is required. I don't know of any reason why we couldn't render them both in the same way (with italic markup outside the brackets):

[// ''Whaam!''].Whaam!.
''[// Whaam!]''.Whaam!.

Is there a reason for them to be different?

So, for the time being, the hack in the sandbox does not fix duplicate punctuation for the external link variety of this issue. I recently addressed a similar issue related to editor names. That happened in one place in the code. There is another place that has a long if-then-else test (safe_join()) that handles it for other portions of the rendered citation.

After the next update, I propose to disable those portions of the code, make the module render Wikilinks and external links with markup outside the brackets, and see if this simpler method of removing duplicate punctuation carries any water.

Trappist the monk (talk) 19:27, 4 April 2015 (UTC)

And another variation: |trans-title=:

''Whaam!'' &#91;''Wham!''&#93;.

|trans-title= with |title-link=:

''[[Whaam!|Whaam!]]'' &#91;''Wham!''&#93;.

|trans-title= with |url=:

[// ''Whaam!'' &#91;''Wham!''&#93;].

And this same for |chapter= and |trans-chapter=:

"Baam?" &#91;Bam?&#93;.

when |chapter= is wikilinked:

"[[Baam?]]" &#91;Bam?&#93;.


[// "Baam?" &#91;Bam?&#93;].


Trappist the monk (talk) 13:13, 5 April 2015 (UTC)

Add code tweaks to test external link detection and add |chapter=Baam?:

Lichtenstein, Roy. Whaam!. 
Lichtenstein, Roy. "Baam?". Whaam!. 

And test these conditions:

!''&#93;. – unlinked trans-title
Lichtenstein, Roy. Whaam! [Wham!]. 
?&#93;. – unlinked trans-chapter
Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!. 

and these:

!''&#93;]. – ext linked trans-title
Lichtenstein, Roy. Whaam! [Wham!]. 
?&#93;]. – ext linked trans-chapter
Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!. 

and these, probably unusual conditions:

!]]''&#93;. – wikilinked trans-title
Lichtenstein, Roy. Whaam! [Wham!]. 
?]]&#93;. – wikilinked trans-chapter
Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!. 

I have placed all of this in a function experiment_strip_dup_punct () that does these tests. Before the next update to the live module, I will leave the code enabled but not use the 'fixed' rendering. The code will still categorize citations like this so that I can see how the code is working.

Trappist the monk (talk) 16:42, 5 April 2015 (UTC)

I've discovered a couple of problems with this idea. The first is that Bibcodes often look like this: 2004PhST..112...20I which the code dutifully turns into: 2004PhST.112..20I and the second occurs when the template mode is CS2, uses |editor-firstn= where the assigned value is an initial followed by a period. I think that I'm going to discontinue this experiment.

Trappist the monk (talk) 13:49, 10 April 2015 (UTC)

|authors= not an alias of |last=[edit]

|authors= is not an complete alias of |last= and hasn't been for a long time.

Cite book compare
{{ cite book | authors=Authors | last2=Last2 | title=Title }}
Old Authors; Last2. Title. 
Live Last2. Title.  Missing |last1= in Authors list (help); More than one of |authors= and |last= specified (help)
Sandbox Last2. Title.  More than one of author-name-list parameters specified (help); Missing |last1= in Authors list (help)

In Module:Citation/CS1/Configuration, where aliases are defined, is this line:

['Authors'] = {'authors', 'people', 'host', 'credits'}

which defines the parameters that alias to the meta-parameter |Authors=. Further along in that same module is:

['AuthorList-Last'] = {"author#-last", "author-last#", "last#", "surname#", "Author#", "author#", "authors#", "subject#"}

In that code |last#= is an alias of |authors#=. Here, the '#' represents 0 or more digits. This list is used by the module to determine if there are redundant parameters used for author names:

Last. Title.  More than one of |authors= and |last= specified (help)

But, when it comes time to assemble the author name-list, a test is made to see if the meta-parameter |Authors= is set. If it is, the module assumes that |Authors= contains the complete list of names and does not execute the code that assembles the author name-list from the parameters that alias to |AuthorList-Last=. This makes some sense because with a complete list of authors in |authors= there is no need to go through the motions of examining |display-authors=, |last-author-amp=, |name-list-format=, etc.

I guess the question is: What to do about this? In the documentation, we clearly state that |authors= is an alias of |last=. Semantically, I think that they ought not be aliases and that |authors#= should be stricken from |AuthorList-Last= and from the documentation. There have been discussions elsewhere regarding the use of |authors= which topic is not part of this discussion. Just to enforce that last statement, the question at hand is:

Shall |last= and |authors= be aliases of each other?

Trappist the monk (talk) 19:05, 5 April 2015 (UTC)

The redundant parameter category is essentially empty (new pages pop in there at a rate of a few per day), so we know that there are essentially no instances of |last= and |authors= in the same citation. That said, I would not be surprised if |lastn= and |authors= exist together in many citations, and it looks like the |lastn= parameters are ignored in that case. That is not desirable.
What do you propose to do about this situation? Would you list the contents of |lastn=/|firstn= along with |authors=? Mark the presence of |lastn= and |authors= as an error condition? Or something else? If the second option is chosen, that could be a problem, since our documentation has said that |last= and |authors= are aliases for a while. – Jonesey95 (talk) 20:37, 5 April 2015 (UTC)
To gauge opinion and to figure out what to do was the purpose of my post. But, since you've asked, if it is left to me, I propose to:
  1. strike |authors#= from |AuthorList-Last=
  2. create a new temporary meta-parameter, perhaps |LastFirstAuthors=
  3. allow the module to create a list of author names from |lastn=, |firstn=, |authorn=, |author-maskn=, |author-linkn=
  4. if both |Authors= and |LastFirstAuthors= are set, choose one (probably |LastFirstAuthors=) and emit some sort of redundant parameter error message
  5. strike |authors= from the |last= documentation
  6. create new |authors= documentation noting the difference between it and |authorn=
Trappist the monk (talk) 23:30, 5 April 2015 (UTC)
I agree with all of the above except step 4, which may require a bit more thought. Right now, if |authors= and |last2= are present, only the value of |authors= is displayed. Following the procedure (marked "probably") in step 4 would silently change that to prefer |last2=, and presumably emit a "missing author" error. If the "missing author" error category were already empty, it would be a simple matter of finding these new instances and fixing them to display all of the intended authors, but it currently contains 9,700 articles. The newly changed articles would get lost in the shuffle.
In short, I would change step 4 to read "(probably |Authors=)". I think. – Jonesey95 (talk) 00:24, 6 April 2015 (UTC)
True, but step 4 also says that it will emit some sort of redundant parameter error message which will place the page in Category:Pages with citations having redundant parameters which is not so large.
Trappist the monk (talk) 10:52, 6 April 2015 (UTC)

I have implemented items 1–4 from the list above:

{{cite book/new |authors=Authors |last2=Last2 |title=Title}}
Last2. Title.  More than one of author-name-list parameters specified (help); Missing |last1= in Authors list (help)
{{cite book/new |author=Author |last2=Last2 |title=Title}}
Author; Last2. Title. 
{{cite book/new |author1=Author1 |last2=Last2 |title=Title}}
Author1; Last2. Title. 
{{cite book/new |authors=Authors |last1=Last1 |title=Title}}
Last1. Title.  More than one of author-name-list parameters specified (help)

Trappist the monk (talk) 15:10, 7 April 2015 (UTC)

|display-author=etal bug[edit]

I've discovered a bug. When a citation has |authors= and |display-author=etal the author list is simply et al. This happens because the module inappropriately adds 'et al.' to the empty |last_first_list= meta parameter. I've fixed it in the sandbox.

Cite book compare
{{ cite book | display-authors=etal | title=Title | authors=Authors }}
Live et al. Title.  More than one of |authors= and |last= specified (help)
Sandbox Authors et al. Title. 

The issue doesn't arise with |display-editors= in the live version because the code to distinguish |editors= from |editor= is not present. But, if it were, it would be fixed in the sandbax as well

Cite book compare
{{ cite book | display-editors=etal | editors=Editors | title=Title }}
Live Editors (ed.). Title. 
Sandbox Editors et al. (eds.). Title. 

I've also tweaked the code so that |editors= is always treated as multiple names so the content of |editors= in the rendered citation is annotated with (eds.) (where appropriate).

Trappist the monk (talk) 16:19, 23 April 2015 (UTC)

|editors= not an alias of |editor-last=[edit]

I should have made the change described in the above section for |editors= (plural) because it also is not a complete alias of of |editor-last=. I have now done so:

{{cite book/new |editors=Editors |editor-last2=Editor Last2 |title=Title}}
Editor Last2 (ed.). Title.  More than one of editor-name-list parameters specified (help); Missing |last1= in Editors list (help)
{{cite book/new |editor=Editor |editor-last2=Editor Last2 |title=Title}}
Editor; Editor Last2 (eds.). Title. 
{{cite book/new |editor1=Editor1 |editor-last2=Editor Last2 |title=Title}}
Editor1; Editor Last2 (eds.). Title. 
{{cite book/new |editors=Editors |editor-last1=Editor Last1 |title=Title}}
Editor Last1 (ed.). Title.  More than one of editor-name-list parameters specified (help)

Trappist the monk (talk) 10:23, 23 April 2015 (UTC)

|Editor= (capital "E") not flagged in {{Cite book}}?[edit]

This capitalized |Editor= appears to work just fine. I believe that it should be flagged as unsupported.

Cite book compare
{{ cite book | Editor=James Wilson | publisher=On the Line Inc. | year=2006 | place=Seattle | title=Book about super trains | chapter=All the great shows }}
Old "All the great shows". Book about super trains. Seattle: On the Line Inc.. 2006. 
Live James Wilson, ed. (2006). "All the great shows". Book about super trains. Seattle: On the Line Inc. 

I haven't looked at the code yet to see why this capitalized parameter is accepted, but I will do so if I have time.Jonesey95 (talk) 22:01, 5 April 2015 (UTC)

It's on the Whitelist. That's odd. – Jonesey95 (talk) 22:03, 5 April 2015 (UTC)
It's also been in the main module for years; I've just never noticed. It looks like we also allow |Author= and |Ref= and |DoiBroken=, with all other parameters, except for initialisms, in lower case only. I think we should deprecate the capitalized form of all of these parameters. Are they in our documentation anywhere? – Jonesey95 (talk) 22:09, 5 April 2015 (UTC)
The supported alternative capitalizations were each part of one or more of the pre-Lua templates and hence were pulled in to maintain backward compatibility. Dragons flight (talk) 22:24, 5 April 2015 (UTC)
That makes sense. It's been two years since then, however, and I think it's time to bid them farewell. Maybe a maintenance category to ease into this transition? I have a nice AutoEd script that I use to clean up unsupported parameters (usually capitalization and misspelling errors), and it would work just fine on such a category. – Jonesey95 (talk) 22:34, 5 April 2015 (UTC)
insource:/\| *Author *=/ 25 instances
insource:/\| *Editor *=/ 332 instances; |Editor= is used by {{Infobox television episode}}
insource:/\| *Ref *=/ 47 instances; |Ref= is accepted by the {{harv}} family of templates
insource:/\| *DoiBroken *=/ none found
insource:/\| *EditorGiven *=/ none found
insource:/\| *EditorSurname *=/ 2 instances
insource:/\| *Embargo *=/ none found; we might want to think about removing |embargo= in the cases where the embargo has expired
insource:/\| *PPrefix *=/ none found
insource:/\| *PPPrefix *=/ none found
Presumably there are numbered versions: |Authorn=, |Editorn= and perhaps |EditorGivenn= and |EditorSurnamen=.
Given these low numbers, I don't have a problem deprecating the author and editor parameters and killing the others.
Trappist the monk (talk) 23:16, 5 April 2015 (UTC)
I believe that I have fixed all of the instances of the above parameters that needed to be fixed, i.e. they were in citation templates and were populated with a value. It has been my experience that the insource search doesn't always find everything, so there may be a few more that crop up in the deprecated parameter category. – Jonesey95 (talk) 19:55, 11 April 2015 (UTC)

These are now deprecated:


and these are invalidated:


For PMCs with |embargo= that have expired, a new maintenance category:

Cite journal compare
{{ cite journal | title=Title | embargo=25 May 2015 | pmc=12345 | journal=Journal }}
Live "Title". Journal. PMC 12345. 
Sandbox "Title". Journal. PMC 12345. 
embargo expired today
Cite journal compare
{{ cite journal | title=Title | embargo=26 May 2015 | pmc=12345 | journal=Journal }}
Live "Title". Journal. PMC: 12345. 
Sandbox "Title". Journal. PMC: 12345. 
embargo expired today

Trappist the monk (talk) 16:13, 7 April 2015 (UTC)

It appears that |Ref= is still a valid parameter name. Is there a reason to keep it? I can think of none. It's probably still valid merely because of mistake on my part.

Trappist the monk (talk) 11:52, 13 May 2015 (UTC)

This capitalized parameter should be changed to deprecated or unsupported, per the discussion above. It looks like we all missed removing it in the last round, even though it was discussed above.
Would you be willing to create a Monkbot task (or would GoingBatty be willing to create a BattyBot task) to scan the deprecated parameters category for these capitalized parameters and change them to lower-case? The category is so overwhelmed with |coauthors= that it is hard for a human editor to find |month= and Ref and other rare deprecated parameters in there. – Jonesey95 (talk) 14:19, 13 May 2015 (UTC)
I have an AWB script that works on these plus others listed in the table at Help:CS1_errors#Cite_uses_deprecated_parameters. I have just added |Ref= to it.
Trappist the monk (talk) 15:00, 13 May 2015 (UTC)

Questions regarding citation of a government report[edit]

I would like to cite this section of this report for use in October Surprise conspiracy theory and related articles. I am wondering if the following is sufficient:

<ref name="October Surprise Task Force">{{cite book |title=Joint report of the Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 ("October Surprise Task Force") |url=;view=1up;seq=1 |date=January 3, 1993 |publisher=United States Government Printing Office |location=Washington, D.C. |page=147|chapter=VII. Alleged Attempts to Delay the Release of the Hostages |chapterurl=;view=1up;seq=161;size=150 |ref={{harvid|"October Surprise Task Force"|1993}}}}</ref>

Which gives...

"VII. Alleged Attempts to Delay the Release of the Hostages". Joint report of the Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 ("October Surprise Task Force"). Washington, D.C.: United States Government Printing Office. January 3, 1993. p. 147. 

You may notice that I used {{Cite book}} and that I did not fill in |author=; I wasn't sure if the author should be United States House of Representatives or just House October Surprise Task Force. Should I also place "H. Rept. No. 102-1102" somewhere? Thanks again! - Location (talk) 15:45, 7 April 2015 (UTC)

I think that it's VIII
I'd use |url=, the book's permalink, and |chapter-url=, the chapter's permalink.
I have no strong opinion about |author= except that I think the nickname 'October Surprise Task Force' is too informal.
Trappist the monk (talk) 16:24, 7 April 2015 (UTC)
I agree on the comment about informality of the name. Personally, I'd use the official name of the task force as the author. As for the report number, |id= H. Rept. No. 102-1102 should work to include it. Adding |oclc= 27492534 (OCLC 27492534) to link to the library catalog entry is another beneficial extension of the citation for readers. Imzadi 1979  16:47, 7 April 2015 (UTC)
Thanks for the feedback. Although it makes the citation quite lengthy, I used the formal name in |author= but House October Surprise Task Force for its link:
Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 (January 3, 1993). "VIII. Alleged Attempts to Delay the Release of the Hostages". Joint report of the Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 ("October Surprise Task Force"). Washington, D.C.: United States Government Printing Office. p. 147. OCLC 27492534. H. Rept. No. 102-1102. 
By the way, where did you find the OCLC number? - Location (talk) 18:22, 7 April 2015 (UTC)
The webpage displaying the report has a link on its left side to "Find in a library". Clicking that takes you to the entry: . Imzadi 1979  18:36, 7 April 2015 (UTC)
Thanks again! - Location (talk) 19:53, 7 April 2015 (UTC)

Exclude some templates from citation errors?[edit]

Is it possible to exclude some template pages from citation errors, such as Template:AASHTO minutes and Template:Accu-Stats? Note that I'm just asking about the template pages themselves, not incorrect uses of the templates in articlespace. Thanks! GoingBatty (talk) 01:23, 8 April 2015 (UTC)

There is some way to do this with <noinclude> statements, but some people got hot and bothered when it was done to a batch of template pages a while ago, so I'm not inclined to mess with it. I'm open to clever suggestions, because they bug me when I run a report of templates with errors using catscan. – Jonesey95 (talk) 02:30, 8 April 2015 (UTC)
Actually, I think you probably want WP:INCLUDEONLY (<includeonly>...</includeonly>) so that the code is processed in transclusions, but not for the template itself - Evad37 [talk] 02:40, 8 April 2015 (UTC)
This would fix his immediate issue but restricts viewing the templates and isn't really a long-term change. --Izno (talk) 16:36, 8 April 2015 (UTC)
Probably what core should do is avoid categorizing any errors outside mainspace/draftspace. --Izno (talk) 03:52, 8 April 2015 (UTC)

Given the variety of answers to the original question, it would seem that the original question is a bit imprecise.

But, it did bring to mind something that has been fermenting at the back of my brain for a while. I have noticed that Module:Citation/CS1 categorizes pages that perhaps ought not be categorized. For example, we categorize archived pages, log pages, sandbox pages, testcases pages, and, undoubtedly, others as well. I don't think that it would be too difficult to prevent categorization of these pages if we can come up with a complete list of them.

I've added a snippet of code to Module:Citation/CS1/sandbox that sets the don't-categorize flag when an article title matches any of these simple Lua patterns:


Others that might be added are:

/%d%d%d%d – subpage starts with a year
/%a+ %d%d%d%d – subpage starts with month (or some other text) followed by year


Trappist the monk (talk) 14:25, 8 April 2015 (UTC)

I'm amenable (obviously) to starting to de-categorize certain classes of pages. My query would be: why not (additionally?) by namespace? Do we see any particular uses for such categories outside the main/draftspace? --Izno (talk) 16:38, 8 April 2015 (UTC)
To Trappist: I strongly support removing /sandbox and /testcases from categorization. I do not support summarily decategorizing /Archive and /Log. I just fix those pages instead, and I have had zero complaints (that I can remember, at least).
To Izno: We already exclude some namespaces. Here's a previous discussion. Please read that discussion and then let us know what namespaces you would recommend that we completely exclude from categorization. I am definitely open to suggestions.
Excluding the Template namespace is not a good idea, as there are plenty of times when templates have errors that should be fixed, and sometimes those templates are transcluded in hundreds or thousands of pages. If you look through some of my edits, you can see examples of fixes I have made to citation errors in templates.
To GoingBatty: Clarifying your question, it sounds like you are asking how to exclude Template pages when the transcluded version of the template does not produce errors, but the example version of the template given on the Template's own page has an error. I think that <includeonly>...</includeonly> is the way to do that, but I don't remember how to do it. There might be some chatter about it in my Talk page archives. – Jonesey95 (talk) 20:00, 8 April 2015 (UTC)
Ok, archive and log removed. Are there others that should be added to sandbox and testcases?
Trappist the monk (talk) 11:29, 9 April 2015 (UTC)

Still hidden error messages[edit]

These five categories of errors still hide their error messages. Can/should any of these be unhidden?

Trappist the monk (talk) 14:46, 9 April 2015 (UTC)

Unhidden as in publicly flogged with red splotches? Yikes. I have a bunch of citations with explicit et als. to revise, but I am waiting for a better resolution of the "missing title" message (a related issue) before proceeding. I would rather keep both of those categories hidden for a while longer. ~ J. Johnson (JJ) (talk) 19:34, 9 April 2015 (UTC)
The RFC that governs the hiding of these messages says that they should be turned off "until an appropriate bot fixes resolvable instances of the error." We can turn on the error messages in the category when it is not feasible for a bot to fix any of the existing/remaining errors in a given category. Here's my understanding of where each of these categories stands:
Please discuss the individual categories below. If my summaries above are incorrect, please post corrections below, and I will add strikethrough markup to, and adjust, the summaries. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)

Pages using citations with accessdate and no URL[edit]

Someone should troll through the archives for previous discussions before rehashing them here. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)

A list of links to many of these previous discussions is included in my recent census of data for this error. The last link in the list was not updated by a bot before the post was moved to the archives - it is found at [3]. Stamptrader (talk) 22:02, 13 April 2015 (UTC)

Pages using web citations with no URL[edit]

Pages containing cite templates with deprecated parameters[edit]

I am willing to work to help Monkbot clear up bot-fixable entries in this category. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)

I have a script that will clear a lot of the |name-list-format= related parameter errors but I stopped running it because of this RfC which remains open.
A rather significant amount of what remains is |coauthors= that Monkbot, without a rewrite, can't do much about. So I'm going to say that this category should remain hidden for now.
Trappist the monk (talk) 00:19, 10 April 2015 (UTC)

Pages using citations with format and no URL[edit]

Pages using citations with old-style implicit et al. in editors[edit]

There are only about 750 articles in this category, so we could just fix them and then eliminate the category as we did with the "et al. in authors" category. I think that this would be the easiest path. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)

Like I said above, I have a handful of articles where a suitable fix (for which Citation Bot is not competent) is tied into other stuff which is not yet ready. ~ J. Johnson (JJ) (talk) 20:09, 10 April 2015 (UTC)
To Jonesey95, J. Johnson: I've just noticed today that, in addition to CS1 errors in red, there are now notices of CS1 maintenance in green, which link to various maintenance categories. The reason I'm asking about this here is that the first one I came across was the CS1 maint: Explicit use of et al. category. I haven't been able to find much information on these categories, so I am compelled to ask, "Is this how the 'et al. in authors' category you mention was 'eliminated'? just by redefining it from an 'error' to a 'maintenance' item?" – Paine EllsworthCLIMAX! 02:42, 13 April 2015 (UTC)
Implicit et al. is an error message (red) and caused by citations that have exactly four editors. In the old {{citation/core}} version, templates with four or more editors would display three editors followed by et al. In the Module:Citation/CS1 version, you can display as many as you'd like. The implicit (red) message was there because the Module mimics {{citation/core}}. Once Category:Pages using citations with old-style implicit et al. in editors is cleared, that error message will go away.
Explicit et al. refers to the intentional addition of the text string et al. (in a variety of flavors) to any of the author or editor parameters. This is a maintenance category with attendant green messages because at the time the code was developed there wasn't a viable 'solution' to the problem (the et al. text corrupts the COinS meta data). At the next update of the Module, editors will be able to set |display-authors=etal and |display-editors=etal so that the template displays the et al. text regardless of how many authors/editors are included in the template.
See Help:CS1_errors#.7Cdisplayeditors.3D_suggested, Help_talk:Citation_Style_1#How_to_use_.22et_al.22.3F, Help_talk:Citation_Style_1/Archive_7#Maintenance_category_messaging
Trappist the monk (talk) 03:03, 13 April 2015 (UTC)
Paine Ellsworth, the maintenance category and the original authors category are unrelated. See this discussion for an explanation of how the display-authors et al. category was eliminated through hard work, not through any sort of sleight of hand. – Jonesey95 (talk) 13:49, 13 April 2015 (UTC)
Thank you both for helping me to fill in the gaps of my understanding. I really did not mean to imply any "sleight of hand", Jonesey95, only perhaps a lowering of priorities so that more important issues may be more easily seen and addressed. I see now that I was mixing apples and oranges. Thank you again, and we wish the best of everything to you and yours! – Paine EllsworthCLIMAX! 08:59, 14 April 2015 (UTC)
To Jonesey95, Trappist the monk, J. Johnson: Thank you so much for this! I fixed one in the Java Man article and several more at Mitochondrion, and it works great! Thank you! and Best of everything to you and yours! – Paine  00:15, 19 April 2015 (UTC)

Update to the live CS1 module weekend of 18–19 April 2015[edit]

On the weekend of 18–19 April I propose to update the live CS1 module files from the sandbox counterparts:

Changes to Module:Citation/CS1 are:

  1. migrate {{cite episode}}; discussion
  2. migrate {{cite serial}}; discussion
  3. fix |type= anomaly in cite map; discussion
  4. fix duplicate separator character bug; discussion
  5. add |sheet=, |sheets=, and |trans-map= for cite map; discussion
  6. migrate {{cite arxiv}}; discussion
  7. add support for multiple comma-separated languages in |language=; discussion
  8. add support for |archive-format=, |conference-format=, |contribution-format=, |event-format=, |lay-format=, |section-format=, |transcript-format=; add automatic pdf detection and annotation; discussion; discussion
  9. expand accepted character sets for Vancouver style; discussion
  10. |display-authors=etal support; discussion
  11. |authors= not (and hasn't ever really been) an alias of |lastn=; discussion
  12. categorize expired PMC embargoes; discussion
  13. do not categorize /sandbox and /testcases subpages; discussion
  14. move static text (properties and maintenance category names, default title types) to Module:Citation/CS1/Configuration/sandbox;

Changes to Module:Citation/CS1/Configuration are:

  1. add |credits=, |began=, |ended=, for {{cite episode}} and {{cite serial}};
  2. add |sheet=, |sheets=, and |trans-map= for {{cite map}};
  3. add |class=, |eprint= for {{cite arxiv}};
  4. add |archive-format=, |conference-format=, |contribution-format=, |event-format=, |lay-format=, |section-format=, |transcript-format=; discussion; discussion
  5. remove Authors# from AuthorList-Last - |authors= not an alias of |last=; discussion
  6. remove invalidated |DoiBroken=, |Embargo=, |PPPrefix= (standardizing on the lower case versions of these parameter names); discussion
  7. add citation_config.maint_cats table;
  8. made all tables local; add uncategorized_subpages, prop_cats, title_types tables;

Changes to Module:Citation/CS1/Whitelist are:

  1. add |credits=, |began=, |ended=, for {{cite episode}} and {{cite serial}};
  2. add |episode= for cite serial;
  3. add |sheet=, |sheets=, and |trans-map= for {{cite map}};
  4. add |class=, |eprint= for {{cite arxiv}};
  5. add |archive-format=, |conference-format=, |contribution-format=, |event-format=, |lay-format=, |section-format=, |transcript-format=; discussion; discussion
  6. invalidated |authorsn= and |editorsn=; discussion
  7. deprecated |Authorn=, |Editorn=, |EditorGivenn=, |EditorSurnamen= (standardizing on the lower case versions of these parameter names); discussion
  8. invalidated |DoiBroken=, |Embargo=, |PPPrefix= (standardizing on the lower case versions of these parameter names); discussion
  9. make all tables local;

Changes to Module:Citation/CS1/Date validation are:

  1. add "Christmas" as a valid month/season; discussion
  2. refined |access-date= checking; discussion

Trappist the monk (talk) 11:00, 11 April 2015 (UTC)

Thoughts on incorporating |orig-date=, perhaps by aliasing |orig-year= to it? (discussion)   ~ Tom.Reding (talkcontribsdgaf)  16:58, 11 April 2015 (UTC)
Trappist the monk, please post here when you have made the above edits so that we can update the documentation. Am I correct in thinking that we will be able to remove all of the non-Lua text from the template documentation files? – Jonesey95 (talk) 23:04, 11 April 2015 (UTC)
Yes, I think so.
Trappist the monk (talk) 11:40, 12 April 2015 (UTC)
I checked all of the transclusions of Template:Citation Style documentation/author, one of our documentation subtemplates (from which non-Lua documentation will be removed), and it was being used by only two templates that were not "CS1 core" templates: {{Cite wikisource}} and {{Cite IETF}}. Both use {{citation/core}} to render citations. I substed the non-Lua documentation into those templates' documentation pages, and I left a note on the talk page for each to explain that watchers there should check the documentation for accuracy.
I also checked transclusions of the CS1 title documentation, figuring that author and title would be transcluded most frequently. It looks like we are OK to proceed with removing non-Lua wording from all of these doc templates after the module update. – Jonesey95 (talk) 14:16, 12 April 2015 (UTC)
Hold up! Let's not be over hasty in deprecating the |author= (|authorN=) parameter. Doing so was a comment on the indicated discussion, it was not actually discussed. Some authorship is attributed to groups or organizations, the names of which do not map into first/last (personal/surname), so we do need a general "author's name" parameter (note possessive form). I believe the deprecation we discussed was of plural "authors". Similarly for "editors". ~ J. Johnson (JJ) (talk) 18:30, 16 April 2015 (UTC)
|authors= (plural) is not deprecated:
{{cite book/new |title=Title |authors=First Author; Second Author; Third Author}}
First Author; Second Author; Third Author. Title. 
nor is |author= (singular)
{{cite book/new |title=Title |author=First Author; Second Author; Third Author}}
First Author; Second Author; Third Author. Title. 
nor is |authorn= (also singular)
{{cite book/new |title=Title |author1=First Author; Second Author; Third Author}}
First Author; Second Author; Third Author. Title. 
Trappist the monk (talk) 18:42, 16 April 2015 (UTC)
Under "Changes to Module:Citation/CS1/Whitelist" you have:
"7. deprecated |Authorn=, |Editorn= ...."
Is there something here I don't understand? ~ J. Johnson (JJ) (talk) 19:31, 16 April 2015 (UTC)
I think that's just the capitalized version he's removing support for. --Izno (talk) 19:34, 16 April 2015 (UTC)
Yes, non-standard capitalization per this discussion.
Trappist the monk (talk) 19:42, 16 April 2015 (UTC)
We are standardizing on all lower case for parameter names, except for initialisms like DOI, ISBN, and similar identifiers. So |authors= is fine, but |Authors= is being deprecated. Note the non-standard capital "A" in the second parameter name. If you look at the Whitelist now, you will see only a few parameters that start with capital letters. They are essentially never used, so it should not be a burden to deprecate them. Sorry for any confusion. – Jonesey95 (talk) 21:15, 16 April 2015 (UTC)
Ah, yes. I was thinking we were being casual about case. I'll talk with my barista about adjusting my caffeination. ~ J. Johnson (JJ) (talk) 21:15, 16 April 2015 (UTC)

Update complete[edit]

This update is complete. Most documentation has been updated. If you notice any errors or omissions, please post your findings here. – Jonesey95 (talk) 04:40, 19 April 2015 (UTC)

I noticed that the deprecated parameters |began= and |ended= are still shown in the {{Cite episode}} documentation. There may well be others, this is simply one that I noticed while cleaning up CS1 errors earlier tonight. Stamptrader (talk) 04:55, 19 April 2015 (UTC)
Good catch. Fixed.
I have noticed that some of the "if lua" statements have not been removed from documentation subpages, but it's late at night where I am, and I do not trust my brain to do complex editing at this time of night. – Jonesey95 (talk) 05:33, 19 April 2015 (UTC)
Another small point regarding the update (but not the documentation) - there seems to have been code added to the module to capitalize the contents of the |format= parameter. A large number of citations (about 6800 according to an insource: search) populate the |format= parameter with [[Portable Document Format|PDF]], creating a wikilink to the PDF article. However, the module code turns the parameter contents into [[PORTABLE DOCUMENT FORMAT|PDF]], which created a red patch of text because there wasn't a Wikipedia article with that capitalization. There is now, I created a redirect page to get rid of the red ink, but there may be other examples cropping up. Stamptrader (talk) 07:30, 19 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Fixed in the sandbox.

Cite web compare
{{ cite web | title=Title | format=[[Portable Document Format|pdf]] | url=//example.pdf }}
Live "Title" (PDF). 
Sandbox "Title" (pdf). 

Trappist the monk (talk) 10:57, 19 April 2015 (UTC)

But, just to be a counterpoint:

Cite map compare
{{ cite map | format=[[MrSID]] | year=1930 | url= | title=Map of Ohio showing State Routes | author=Ohio Department of Highways }}
Live Ohio Department of Highways (1930). Map of Ohio showing State Routes (MRSID) (Map). 
Sandbox Ohio Department of Highways (1930). Map of Ohio showing State Routes (MrSID) (Map). 

The "r" in MrSID shouldn't be capitalized. Imzadi 1979  11:25, 19 April 2015 (UTC)

Ok, no case shifting.
Trappist the monk (talk) 12:08, 19 April 2015 (UTC)

With the format added automatically, anything that was using (or rather, misusing) |type=PDF now shows (PDF) twice, eg:

Cite map compare
{{ cite map | type=PDF | title=Title | url= }}
Old Title (PDF). 
Live Title (PDF) (PDF). 

Could this or should this be tracked, and/or would this be fixable with an AWB run? (The real examples I noticed are at this revision of North West Coastal Highway, but I intend to fix them shortly.) - Evad37 [talk] 13:02, 19 April 2015 (UTC)

An insource: search for /\| *type *= *pdf/ finds about 400 instances of |type=pdf. I'm just now working on an AWB script that will remove the now redundant |format=pdf when |url= points to one of the MediWiki recognized pdf file extensions so making a tweak to that code to handle |type=pdf fits nicely.
Trappist the monk (talk) 13:15, 19 April 2015 (UTC)
I don't agree that |format=pdf is redundant. It might well be in the English Wikipedia at the moment, but (1) urls can change and often remove the Mediawiki recognised pdf file extensions; (2) our articles are translated and reused in other wikis where there is no guarantee of support for automatic addition of the PDF indicator. We should not be needlessly throwing away data just because of our own assumptions about redundancy. --RexxS (talk) 18:58, 19 April 2015 (UTC)

chapter and section[edit]

Nothing in {{tl:cite book}} suggests that chapter and section are mutually exclusive. Ideally they should be allowed concurrently, but at a minimum the documentation should reflect that it is not permitted. The particular case I wanted was

{{cite book|last1=Bowen |first1=Ray M. |authorlink1= |last2=Wang |first2=C.-C. |last3=Ratiu |first3=T. |title=INTRODUCTION TO VECTORS AND TENSORS, Linear and Multilinear Algebra, Volume 1 |url= |format=PDF |year=2010 |language=English |isbn=0-306-37508-7 |page=214 |chapter=Chapter 7 TENSOR ALGEBRA |section=Section 32. The Second Dual Space, Canonical Isomorphisms |quote=Since the isomorphism J is defined without using any structure in addition to the vector space structure on V. , its notation can often be suppressed without any ambiguity. We shall adopt such a convention here and identify any v \in V as a linear function on <Math>V^*. |separator= , |lastauthoramp=}}, where Section 32 is within Chapter 7. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:46, 12 April 2015 (UTC)

In such cases I would usually just use a contribution (or chapter) parameter referring to the section, but with the chapter number attached: |contribution=7.32 The Second Dual Space, Canonical Isomorphisms. If you really need the chapter title you can also include it as part of the same parameter. By the way, please do not use all-caps in the book and chapter titles, per MOS:CAPS. —David Eppstein (talk) 20:07, 12 April 2015 (UTC)
There is also the other case where a book is in volumes, subdivided into sections (or parts) for some editions and then chapters within those sections (or parts). Take for example versions of Magna Britannia;: Being a Concise Topographical Account of ..., Volume 2, Part 2. Of course one can hack in the different combinations, but it would be better if books could have volume, section, part and chapter, to be combined as needed to follow usage in the book. -- PBS (talk) 12:35, 13 April 2015 (UTC)
It bothers me to use a parameter explicitly named "chapter" for something not a chapter. But in the case here it seems to me that you have to decide whether the source is the book, or a chapter in the book. The latter is typically where the chapters have separate authorship. But this is rarely so at the level of sections (though I have seen exceptions). Citing a section is typically an in-source location of specific material, of which there may be multiple instances in given source. Such in-source specfification is best done at the level of the short cite. E.g.: "Smith et al. (2009), §26". ~ J. Johnson (JJ) (talk) 19:52, 13 April 2015 (UTC)
In the example given above, the source is the whole book (by Bowen and Wang), and the chapter, section and page number are all in-source location information. The usual citation style would just give the page number. There's sometimes a tendency to think that if a template has fields, they should be filled in. Kanguole 21:29, 13 April 2015 (UTC)
Indeed. There is also confusion between use of "pages" in a full citation to indicate the location of the source within the work, and the in-source specification of a particular location. Then there is the classical footnote usage of including the full citation in the first reference, along with the specific page number. In a certain respect all of this is simple, but it is also a little bit complicated, and I despair that we will ever (in my lifetime?) have a simple, understandable explanation of all this. ~ J. Johnson (JJ) (talk) 22:15, 13 April 2015 (UTC)
Re the page number ambiguity: yes. This is especially problematic when the citation is to a journal article (where by convention we always list the page number range for the whole article) but where we want to refer to a specific point within the article. The way I generally handle this is something like what you recommend above with a short cite: give the full journal citation (with the full page range), but then either at the same place or in a footnote referring to the article give the more specific location where a quote or result can be found. —David Eppstein (talk) 23:19, 13 April 2015 (UTC)

cite arxiv tweaks[edit]

Something I missed: |version= should have been deprecated because it can and should be concatenated onto |arxiv= or |eprint=. I have fixed that in the sandbox:

{{Cite arXiv/new |eprint=1004.5110 |class=physics.atom-ph |title= Extreme ultraviolet frequency comb metrology |version=v2 |date=10 May 2010 |first1=Dominik Z. |last1=Kandula |first2=Christoph |last2=Gohle |first3=Tjeerd J. |last3=Pinkert |first4=Wim |last4=Ubachs |first5=Kjeld S.E. |last5=Eikema}}
Kandula, Dominik Z.; Gohle, Christoph; Pinkert, Tjeerd J.; Ubachs, Wim; Eikema, Kjeld S.E. (10 May 2010). "Extreme ultraviolet frequency comb metrology". arXiv:1004.5110v2 [physics.atom-ph]. 

Trappist the monk (talk) 18:25, 18 April 2015 (UTC)

AWB volunteer to clean up Category:CS1 maint: Unrecognized language?[edit]

Now that multiple languages are recognized in |language=, do we have an AWB-savvy volunteer who can fix up articles in Category:CS1 maint: Unrecognized language?

There are many articles that have multiple valid languages that just need some cleanup, converting usages like "English & German" and "English / German" to comma-delimited format. – Jonesey95 (talk) 23:36, 19 April 2015 (UTC)

I think the code in the module already handles the examples you give above - many of the articles in that maintenance category don't show the green text maintenance tag, and a WP:NULLEDIT clears the article from populating the category. And in the case of usages with English as one of multiple languages, I've found that using a comma-delimited list actually puts it back into another maintenance category.
Consider the following edits of 3D pose estimation (reference #1 in each case) - an article originally with |language=English / German [4] doesn't show a green text tag. If you try to use comma, |language=English, German [5] causes the reference to then receive a green maintenance tag and it goes into Category:CS1 maint: English language specified. Changing to |language=English & German [6] clears the maintenance tag again. Stamptrader (talk) 00:17, 20 April 2015 (UTC)
Interesting. I got the impression from the discussion above that only comma-separated values would be accepted. Two languages (or non-languages) separated by an ampersand or a slash seems to render without emitting an error message, however:
Cite book compare
{{ cite book | language=foo & bar | title=Book title }}
Live Book title (in foo & bar). 
Sandbox Book title (in foo & bar). 

Cite book compare
{{ cite book | language=foo / bar | title=Book title }}
Live Book title (in foo / bar). 
Sandbox Book title (in foo / bar). 

Something is not quite right here.
And an article in "Latvian and English" should not be placed in Category:CS1 maint: English language specified, in my opinion. A bilingual or mixed-language article should be able to be described as such, even if one of the languages is English. I don't feel strongly about it, though. – Jonesey95 (talk) 03:58, 20 April 2015 (UTC)
The failure to categorize the two above examples is caused by a bug that I introduced when I moved static text out of Module:Citation/CS1 into Module:Citation/CS1/Configuration. Fixed in the sandbox.
Without some opinion either way I left the English language detector code alone. I think it's relatively simple to limit English language categorization to the single language case.
Trappist the monk (talk) 11:12, 20 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Over the past few days I ran an AWB script that changed |language= parameters with multiple languages to the comma delimited form on about 1750 pages. I have come to believe that multiple language sources that include English as one of the languages should not add the category Category:CS1 maint: English language specified. I have tweaked the sandbox accordingly.

|language= used to categorize into the same categories as those used by {{icon xx}} templates (Category:Articles with xx-language external links). The {{icon xx}} templates only categorize from article space. As I think about it, this constraint ought not apply to CS1/2. We have a defined set of name spaces that we don't categorize, I see no real reason to treat |language= in a special manner. That being the case, I have adjusted the code so that the |language= uses the same categorization rules as every other parameter.

Cite book compare
{{ cite book | language=en,fr | title=Title }}
Live Title (in English and French). 
Sandbox Title (in English and French). 
Cite book compare
{{ cite book | language=en | title=Title }}
Live Title (in English). 
Sandbox Title. 

Trappist the monk (talk) 11:57, 24 April 2015 (UTC)

I'm going through this list and I'm not seeing the CS1 maintenance message on some of the pages. For example, Anton incident (last edited 2014) contains |language=English ([ Finnish]) and is currently on the 1st page of Category:CS1 maint: Unrecognized language, yet I fail to see an unknown language error anywhere on the page. My common.css has the appropriate line of code to see maintenance messages, and I've null-edited the page. Is this a bug, a feature, or my fault?   ~ Tom.Reding (talkcontribsdgaf)  21:17, 21 April 2015 (UTC)

The bug that I introduced fails to categorize unrecognized languages. That whole long string is considered to be one language name because there isn't a comma separator.
{{Cite web/new | title = Stubb Defends Father and Consulate in Custody Battle | url = | publisher = [[YLE]] | date = 15 May 2008 | accessdate = 2009-05-16 | language = English ([ Finnish])}}
"Stubb Defends Father and Consulate in Custody Battle" (in English (Finnish)). YLE. 15 May 2008. Retrieved 2009-05-16. 
The bug is fixed in the sandbox.
Trappist the monk (talk) 21:29, 21 April 2015 (UTC)

A discussion at Module_talk:Citation/CS1#Language_parameter has me wondering if we should adopt something similar to what is done at fr:WP. There, when |language=français or |language=fr, they simply don't display the language annotation. We could do the same thing here when |language=English or |language=en.

Should we?

Trappist the monk (talk) 15:07, 1 May 2015 (UTC)

If we do this, it has been proposed at Module_talk:Citation/CS1#Language_parameter that the practice of deleting |language=en and |language=English be stopped. If we are to hide English language annotation and leave |language= in the templates then use of Category:CS1 maint: English language specified should be discontinued and instead, we should create a new subcategory of Category:CS1 properties that is not a subcategory of Category:CS1 foreign language sources. Perhaps Category:CS1 English language sources. I don't know to what purpose we could put such a category because use of |language=English will not be universal and it would be inappropriate for the module to assume that a source is English unless specified otherwise.

Without someone speaks up and tells me unequivocally not to, I think that I shall proceed.

Trappist the monk (talk) 17:21, 6 May 2015 (UTC)

Why is a category necessary? It should be a simple matter to test for either |language=en or |language=English, and do nothing - no output, no category. --Redrose64 (talk) 22:33, 6 May 2015 (UTC)
Because it's there if someone thinks of a use for such incomplete information? Of course if that happens, it is easy enough to add the category later.
Trappist the monk (talk) 23:08, 6 May 2015 (UTC)

Ok, English is not displayed when used alone but is displayed when listed with other languages. The middle example to show that I didn't break single language rendering. No categories.

Cite book compare
{{ cite book | language=fr, en | title=Title }}
Live Title (in French and English). 
Sandbox Title (in French and English). 
Cite book compare
{{ cite book | language=fr | title=Title }}
Live Title (in French). 
Sandbox Title (in French). 
Cite book compare
{{ cite book | language=en | title=Title }}
Live Title (in English). 
Sandbox Title. 

Trappist the monk (talk) 00:10, 7 May 2015 (UTC)

Suggestion for maintenance category: redundant "edition" or "ed" used in |edition[edit]

Would it make sense to set up a maintenance category for citations using a redundant "ed." or "edition" in the |edition= parameter? Like this:

Cite book compare
{{ cite book | title=Book title | edition=2nd edition | author=Book author }}
Live Book author. Book title (2nd edition ed.). 
Sandbox Book author. Book title (2nd edition ed.). 

I have seen "edition", "Edition", "ed", "ed.", and possibly other variants in the wild. A bot or AWB script should be able to tidy these without much fuss, and without the need for a red error message. – Jonesey95 (talk) 05:10, 20 April 2015 (UTC)

Added detection of 'edition', 'ed', 'ed.' (insensitive to first letter case) where they occur at the end of |edition=:
Book author. Book title (2nd Edition ed.). 
Book author. Book title (2nd ed ed.). 
Book author. Book title (2nd Ed. ed.). 
Book author. Book title (Edition Grande Plus ed.). 
Are there other versions of this that should be detected?
Are there other parameters that should be handled the same way?
Trappist the monk (talk) 11:59, 20 April 2015 (UTC)
I can't think of anything that I have actually seen, but it stands to reason that there are instances of "pp." within the |pages= parameter. I would prefer to find some in the wild before adding code to the module, since coding for hypothetical problems is the first step to madness. – Jonesey95 (talk) 13:30, 20 April 2015 (UTC)
Yep, these insource: search strings:
insource:/\| *page *= *p/ found 442 instances
insource:/\| *pages *= *p/ found 4334 instances
insource:/\| *nopp *= *[YyTt]/ found 1726 instances
Given this, it seems that we might also add categorize citations into Category:CS1 maint: Extra text when |page(s)=p n, |page(s)=p. n, |page(s)=pp n, |page(s)=pp. n, |page(s)=page n, |page(s)=pages n, where n can be any letter nor number, but not when |nopp= is set. So I'll work on that.
Trappist the monk (talk) 12:49, 21 April 2015 (UTC)
Sandbox tweaked. These of various forms of p. and pp.:
|page=123Title. p. 123. 
|page=p123Title. p. p123. 
|page=pp123Title. p. pp123. 
|page=p 123Title. p. p 123. 
|page=pp 123Title. p. pp 123. 
|page=p.123Title. p. p.123. 
|page=p. 123Title. p. p. 123. 
|page=pp.123Title. p. pp.123. 
|page=pp. 123Title. p. pp. 123. 
|pages=123Title. p. 123. 
|pages=p123Title. pp. p123. 
|pages=pp123Title. pp. pp123. 
|pages=p 123Title. pp. p 123. 
|pages=pp 123Title. pp. pp 123. 
|pages=p.123Title. pp. p.123. 
|pages=p. 123Title. pp. p. 123. 
|pages=pp.123Title. pp. pp.123. 
|pages=pp. 123Title. pp. pp. 123. 
and for page and pages:
|page=page123Title. p. page123. 
|page=page 123Title. p. page 123. 
|pages=pages123Title. pp. pages123. 
|pages=pages 123Title. pp. pages 123. 
|page=pagerangeTitle. p. pagerange. 
|pages=pagerangeTitle. pp. pagerange. 
Shouldn't categorize:
|pages=preface, 123Title. pp. preface, 123. 
|page=PrefaceTitle. p. Preface. 
|pages=p 123 |nopp=yTitle. p 123. 
|page=page 123 |nopp=yTitle. page 123. 
Doesn't categorize because at least some of these could be legitimate:
|pages=pA1Title. pp. pA1. 
|page=p.A1Title. p. p.A1. 
|pages=ppA1Title. pp. ppA1. 
|pages=pp.A1Title. pp. pp.A1. 
I have also limited the set of allowable parameter values for |nopp= to yes, y, true (case insensitive) because |nopp=no turns off the page prefixes but shouldn't. An insource: search for insource:/\| *nopp *= *[Nn]/ found one instance which I shall fix.
Trappist the monk (talk) 14:02, 21 April 2015 (UTC)
You probably should make sure that any error checks for p or pp in page/pages is not carried out in cite journal, as they are likely to be intentionalNigel Ish (talk) 17:14, 21 April 2015 (UTC)
Can I have an example of where it makes sense to include p. or pp. in the page specification of a journal article?
Trappist the monk (talk) 17:26, 21 April 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────The Astronomical Almanac names each chapter with a capital letter, and restarts the page numbering with each chapter. There are other books that do this too. In 2011 they were up to chapter N; maybe by the end of the decade they will be up to chapter P. A citation would look something like

{{cite book/new |title=Astronomical Almanac for the Year 2020 |page=P7 |nopp=}}

which would render as

Astronomical Almanac for the Year 2020. p. P7. 

Jc3s5h (talk) 17:38, 21 April 2015 (UTC)Q

I have tweaked the code to answer this particular case.
Trappist the monk (talk) 15:46, 24 April 2015 (UTC)
As cite journal is the only citation style 1 template that omits p. and pp. from the displayed output, it is necessary to add them to make cites look consistent between cite journal and cite news/book etc, and to make the sourcing clear to the reader.Nigel Ish (talk) 18:36, 21 April 2015 (UTC)
May be we should change {{cite journal}} to put in the p. or pp. to be consistent with the other templates and then the presence of the p. or pp. can be detected and removed. Should not be removing from instances of this template without the template change being made. Keith D (talk) 19:10, 21 April 2015 (UTC)
Some editors are probably adding the explicit page indication when they use {{cite journal}} or {{cite magazine}} because the citation looks too confusing with the clump of numbers at the end. If {{cite news}} is used, an explicit page indicator is added by the module code, but that is left out of {{cite journal}} to conform with norms in scientific citations. Consider this citation from the Leicester and Swannington Railway article - it looks doubly clumsy without the inclusion of an author, as then the date gets tacked on to the mix of numbers and things get real confusing even with the addition of an indicator in the |page= parameter. First, {{cite journal}} as originally written, then {{cite journal}} as it would look if the page indicator had been left out, then {{cite journal}} as it would look if there had been an author included in the citation, then {{cite news}} as it would look if that had been used while retaining the editor's page indicator text.
"Stephenson tunnel saved". The Railway Magazine 154 (1,292): p 10. December 2008. 
"Stephenson tunnel saved". The Railway Magazine 154 (1,292): 10. December 2008. 
Author (December 2008). "Stephenson tunnel saved". The Railway Magazine 154 (1,292): p 10. 
"Stephenson tunnel saved". The Railway Magazine 154 (1,292). December 2008. p. p 10. 
I think an editor coming at referencing from a "non-academic normal guy" standpoint can be easily confused by the text generated for citations when using {{cite journal}}, and some of these uses of an explicit page indicator within the |page= parameter will be attempts at making things easier to read. Stamptrader (talk) 20:36, 21 April 2015 (UTC)
Maybe we could consider changing the formatting of journal references to something like "Journal, vol. 3, no. 2, pp. 54–128" instead of "Journal 3 (2): 54–128"? It's a little less concise (so what) and less like typical academic citation formats (also so what) but clear enough and much less intimidating, I think. Not to be done without a lot of discussion first, though, since this is a big change. —David Eppstein (talk) 21:11, 21 April 2015 (UTC)
I'm looking at CMOS 16, and for citing a specific volume of multivolume books, it uses "4:243" to put the volume and page number together if the volume lacks a separate name. For journals, they use "76, no. 1 (2006): 19–35;" after the name of the journal. On that basis, David Eppstein's idea of explicitly adding the "vol", "no." and "p."/"pp." prefixes isn't far fetched. What I've wanted to do for {{cite journal}} is that "76(1):19–35" would be fine, but if the volume or issue number are dropped, the "p." or "pp." would appear with the page number, but the less concise format may be better for Stamptrader's "non-academic normal guy". As it is, I wish many of our editors would heed the advice to stop using the overly abbreviated journal names in deference to our non-academic readers. Imzadi 1979  22:36, 21 April 2015 (UTC)

date for bimonthly issue[edit]

Scouting Magazine had a January-February 2005 issue ( how should that properly be cited, date=January-February 2005 , still gives a CS1 error.Naraht (talk) 17:33, 20 April 2015 (UTC)

Use an en dash: |date=January–February 2005. – Jonesey95 (talk) 18:01, 20 April 2015 (UTC)
thank you.Naraht (talk) 18:25, 20 April 2015 (UTC)
How do you format date ranges which span years, please? |date=21 December 1963–1 February 1964 still produces an error. (talk) 22:45, 21 April 2015 (UTC)
The dash needs to have a space on either side of it:
"Title". Journal. 21 December 1963 – 1 February 1964. 
"Title". Journal. 21 December 1963–1 February 1964.  Check date values in: |date= (help)
This is how the MOS says we are supposed to format dates in prose, which the templates are designed to enforce. Imzadi 1979  22:54, 21 April 2015 (UTC)

Thank you; alles klar. (talk) 22:39, 22 April 2015 (UTC)

accessdate and indirectly-specified URLs[edit]

When a reference specifies a URL indirectly, e.g., using a parameter like jstor=, it ignores accessdate= and generates the category Pages using citations with accessdate and no URL. For example, in [7], the invocation:

{{cite journal| last=Nichols|first=Thomas M. |title=Soldiers and War: A Top Ten List |journal=International Journal |date=Spring 2001 |volume=56 |issue=2 |pages=312, 316–317 |jstor=40203558 |accessdate=30 June 2011 |publisher=Canadian International Council}}


Nichols, Thomas M. (Spring 2001). "Soldiers and War: A Top Ten List". International Journal (Canadian International Council) 56 (2): 312, 316–317. JSTOR 40203558.  [[Category:Pages using citations with accessdate and no URL]]

Note the missing "Retrieved 30 June 2011." and the category generation.

A work-around (maybe) is to specify the URL both directly via the url= parameter and indirectly via the jstor= parameter, see, here, but that's clumsy, and I think there may be a bot that "fixes" the article by converting links to to the jstor= parameter.

I assume this would also occur with other implicit URL indicators (e.g., doi=, pmid=, etc., maybe isbn= and issn=) but have not confirmed. TJRC (talk) 15:47, 25 April 2015 (UTC)

|access-date= has always indicated the date that the URL provided in |url= was last accessed and found to support the content of the Wikipedia article. |access-date= has never applied to material at archival-like sites such as JSTOR, doi, PMC, ZBL, etc. |isbn= is different in that it links to Special:BookSources.
The error message and the category supporting it are correct for your example citation because |url= is not specified. If you choose, you may duplicate the JSTOR or other identifier URL in |url= but that seems to me to be needlessly redundant.
Trappist the monk (talk) 16:18, 25 April 2015 (UTC)
But a URL is specified: in the jstor= parameter. The jstor= parameter generates a link to, which is the accessed source, to which the accessdate= refers. It's not an error for an editor to indicate the date on which the cited source at was accessed, and should not be flagged by the template.
To make this clear: I'm not saying that the template is incorrectly saying the url= parameter is not present. I'm saying the template is incorrectly flagging a template with accessdate= when the URL is specified with a supported parameter other than with the url= parameter. It does not make sense to choose between losing the documentary evidence supplied by accessdate= and the needlessly redundantly putting in the URL twice, once via jstor= and once via url=.
It may be "working as designed" to flag this as a CS1 error; but that just means the bug is in the design, not in the code. IN short, if there is a URL present in the citation to which accessdate= refers, it should not be flagged as an error. TJRC (talk) 16:53, 25 April 2015 (UTC)
I understand what you are saying. It has been said before by others. It is perfectly legitimate to have multiple identifiers, |pmc=, |pmid=, |jstor=, |doi= all in the same citation. To which of these would |access-date= 'attach'? Should we have an access date parameter for each of them? What if we accept the premise that |access-date= applies to identifier-based parameters and also to |url=. Suppose we have a citation that, legitimately, uses both |url= and some identifier, both pointing to different resources, to which of these does |access-date= apply?
The philosophy regarding |access-date= is that it applies when the resource (identified by |url=) is ephemeral in nature. Identifier-based URLs are considered permanent so are presumed to always be available in the same state they were when the Wikipedia editor added the citation. Resources at ephemeral URLs may be here today and gone tomorrow, may change for no apparent reason, may move to a different location; in essence, link rot. Because these kinds of resources are not permanent, we have |access-date= to identify the date when the resource was valid, and |archive-url= and |archive-date= to help us recover the once-valid resource. This functionality is not required for the permanent identifier-based external links.
Trappist the monk (talk) 17:29, 25 April 2015 (UTC)
I agree entirely that |access-date= should not be used with identifier-based URLs. I'd just like to point out, though, that access dates are needed for two slightly different reasons: (1) for those URLs that may be transient, as Trappist the monk notes above, and (2) for URLs whose target is updated more-or-less continuously without distinct "versions". In case (1), it's often appropriate to archive the target webpage. In case (2), archiving is usually inappropriate, and the access date is the only way of telling whether the content might have changed. Peter coxhead (talk) 08:55, 26 April 2015 (UTC)

orig-year parameter in Template:Cite web[edit]

Is this parameter deprecated? It's listed in the template documentation under "Date", though not in the full parameter set under "Usage". As far as I can tell it doesn't do anything. PC78 (talk) 23:50, 25 April 2015 (UTC)

Not deprecated but ignored if |date= is not set.
{{cite web |title=Title |url=// |date=25 April 2015 |orig-year=1995}}
"Title". 25 April 2015 [1995]. 
Trappist the monk (talk) 00:10, 26 April 2015 (UTC)
Ah-ha, thanks for clearing that up. PC78 (talk) 02:33, 26 April 2015 (UTC)

trans-title / script-title mismatch in Cite episode?[edit]

I can't make heads or tails of this one, from Greek Expeditionary Force (Korea):

Cite episode compare
{{ cite episode | last=Βασιλόπουλος (Vasilopoulos) | network=[[Alpha TV]] | first=Χρίστος (Christos) | trans_title=Greeks in Korean War | script-title=el:Οι Έλληνες στον πόλεμο της Κορέας | year=2007 | series=Μηχανή Του Χρόνου (The Time Machine) | location=Greece | url= | language=Greek (English subtitles) }}
Live Βασιλόπουλος (Vasilopoulos), Χρίστος (Christos) (2007). [Greeks in Korean War] |trans-chapter= requires |chapter= (help). Μηχανή Του Χρόνου (The Time Machine) Οι Έλληνες στον πόλεμο της Κορέας (in Greek (English subtitles)). Greece. Alpha TV. 
Sandbox Βασιλόπουλος (Vasilopoulos), Χρίστος (Christos) (2007). [Greeks in Korean War] |trans-chapter= requires |chapter= (help). Μηχανή Του Χρόνου (The Time Machine) Οι Έλληνες στον πόλεμο της Κορέας (in Greek (English subtitles)). Greece. Alpha TV. 

There's a |script-title= and a |trans_title=, which seem to match, but the error message reads "|trans-chapter= requires |chapter=". – Jonesey95 (talk) 21:38, 27 April 2015 (UTC)

I guess it wants a |title= field (which would contain the romanized title) to put into the |chapter= field of the underlying call. Kanguole 22:30, 27 April 2015 (UTC)

I think that this is a case very much like {{cite encyclopedia}}. |title=, and |trans-title= are promoted to |chapter= and |trans-chapter= internally to get the proper formatting. In this case, there is not |script-chapter= to receive |script-title= so the module thinks that |trans-chapter= is missing |chapter=. I'm not sure why the title text is being rendered after the series text. Further research is required.

Monkbot task 6l made the edit that created this so I've stopped the bot and will disable the script-title functionality for {{cite episode}}. If you find others of this kind, and the edit was made by Monkbot task 6l, reverting the bot is the correct response.

Trappist the monk (talk) 22:52, 27 April 2015 (UTC)

Allow slash and numbers in Vancouver style?[edit]

Category:CS1 errors: Vancouver style has been emptied, mostly through null edits, except for three articles, BRCA1, BRCA2, and Tuberous sclerosis. The first two contain the slash "/" in the author name (copied straight from PubMed), and the third contains numbers in the author name (also copied straight from PubMed). Paging Boghog and other interested parties for comment. – Jonesey95 (talk) 16:52, 29 April 2015 (UTC)

It seems to me that those templates shouldn't be {{vcite2 journal}} but {{cite journal}}. Those corporate author names can't be reduced to Vancouver name format so I think that the error message is correct.
Trappist the monk (talk) 17:02, 29 April 2015 (UTC)
Non-conforming Vancouver authors in PubMed are very rare (on the order of one in ten thousand citations), hence substituting {{vcite2 journal}} with {{cite journal}} or by resetting |author-list-format= to null should be OK. Category:CS1 errors: Vancouver style is now completely emptied. Boghog (talk) 05:55, 30 April 2015 (UTC)
There are those who believe that empty parameters such as |author-list-format= constitute citation clutter and so will complain about and / or remove them. Can I suggest that {{vcite2 journal}} and Module:ParseVauthors use some form of positive indication that the parameter is there for a purpose? Perhaps one of these: |author-list-format=none or |author-list-format=default or |author-list-format=cs1; all of which would serve the purpose of not passing |author-list-format=vanc to {{cite journal}}.
I don't think that it is necessary to have this same functionality in Module:Citation/CS1 because an empty |author-list-format= doesn't disable anything.
Trappist the monk (talk) 14:49, 1 May 2015 (UTC)

New behavior of |authors= needs to be adjusted or documented[edit]

Now that |authors= is officially not an alias of |last=, it appears that some behavior of the |authors= parameter needs to be either adjusted or documented.

First, using "et al." in |authors= does not put it in the "explicit et al." maintenance category:

Cite journal compare
{{ cite journal | authors=Steve Warren, Daniel Mortlock, ''et al.'' | bibcode=2011sptz.prop80114W | title=Photometry of the z=7.08 quasar ULAS J1120+0641 | volume=80114 | date=May 2011 | journal=Spitzer Proposals }}
Live Steve Warren, Daniel Mortlock, et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W. 
Sandbox Steve Warren, Daniel Mortlock et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W. 

Second, using |authors= with |display-authors=etal does not display author names and shows a redundant parameter error (although this appears to be fixed in the sandbox):

Cite journal compare
{{ cite journal | display-authors=etal | date=May 2011 | journal=Spitzer Proposals | title=Photometry of the z=7.08 quasar ULAS J1120+0641 | volume=80114 | bibcode=2011sptz.prop80114W | authors=Steve Warren, Daniel Mortlock }}
Live et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W.  More than one of |authors= and |last= specified (help)
Sandbox Steve Warren, Daniel Mortlock et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W. 

Changing |authors= to |last= works fine, by the way:

Cite journal compare
{{ cite journal | display-authors=etal | last=Steve Warren, Daniel Mortlock | date=May 2011 | journal=Spitzer Proposals | title=Photometry of the z=7.08 quasar ULAS J1120+0641 | volume=80114 | bibcode=2011sptz.prop80114W }}
Live Steve Warren, Daniel Mortlock et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W. 
Sandbox Steve Warren, Daniel Mortlock et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W. 

And just to be perverse, here's one with |authors=, |last2=, and |display-authors=etal:

Cite journal compare
{{ cite journal | display-authors=etal | date=May 2011 | last2=Daniel Mortlock | title=Photometry of the z=7.08 quasar ULAS J1120+0641 | volume=80114 | bibcode=2011sptz.prop80114W | authors=Steve Warren | journal=Spitzer Proposals }}
Live Daniel Mortlock et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W.  Missing |last1= in Authors list (help); More than one of |authors= and |last= specified (help)
Sandbox Daniel Mortlock et al. (May 2011). "Photometry of the z=7.08 quasar ULAS J1120+0641". Spitzer Proposals. 80114. Bibcode:2011sptz.prop80114W.  More than one of author-name-list parameters specified (help); Missing |last1= in Authors list (help)

Is this working as designed? If so, we need to document it. If not, how should it be adjusted? – Jonesey95 (talk) 03:40, 30 April 2015 (UTC)

First case fixed today, I think; second case was fixed 23 April 2015 (see here); third case, yep; fourth case is working as intended. When you mix |authors= with |last2= you have two author parameters that are not aliases of each other so we emit the 'more than one of ...' redundant parameter error message. Because |authors= with |last2= are not aliases of each other, the code is looking for |last1= to complete that author name list. Not finding it, the module emits the 'missing |last1= ...' error message.
Trappist the monk (talk) 21:47, 30 April 2015 (UTC)
Nice work. The sandbox examples all look right to me now. – Jonesey95 (talk) 00:53, 1 May 2015 (UTC)

Problems with "cite episode" template?[edit]

I've been editing on Wikipedia for a while, but I'm new to attempting to clean-up CS1 errors that appear. Lately, dozens of "cite episode" templates appear to be generating a CS1 error because the editor included a "writers" parameter. Is this a parameter that used to appear in the template? Has it been eliminated? And can someone suggest an alternate method for including the information (which is critical in television and radio episodes), especially when other parameters are being used for the episode's director(s).JimVC3 (talk) 20:11, 30 April 2015 (UTC)

I had this same question, so I looked in the history of the documentation for {{cite episode}}.
It looks like the |writers= parameter was added to the template on 7 March 2006 and then marked as deprecated on 12 June 2006. It was officially deprecated but displayed in the template from that point until 25 May 2009, when it began to be silently ignored (and not displayed) with this major change to the template code. I found no discussion in the {{cite episode}} talk page archives about this |writers= parameter.
On 18 April 2015, with the change of the template to use the CS1 Lua module, the parameter's presence started to generate an error message, as do all unsupported (and deprecated) parameters.
The previous documentation recommended using |credits= for all credited people associated with the episode, so I would write something like |credits=Joe Smith (producer); Ellen Brown (director); Jane Doe (writer). – Jonesey95 (talk) 20:44, 30 April 2015 (UTC)
I suspected this is what happened. Thanks so much for your research and verifying the situation. Eliminating the parameter probably deserved more discussion. Anyway, your work-around looks like a very good alternative. Thanks again. JimVC3 (talk) 17:32, 1 May 2015 (UTC)
Far better to have separate parameters for each role, for improved data granularity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 4 May 2015 (UTC)


Hi all, just flagging this conversation at Module talk:Citation/CS1. Best, --Elitre (WMF) (talk) 08:29, 1 May 2015 (UTC)

Cite episode - bogus error[edit]

The instance of {{Cite episode}} in Lisa Lynch is giving a "missing title" error, even though the title parameter has content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 4 May 2015 (UTC)

Not bogus, but yeah, confusing. As {{cite journal}} uses |title= to name an article, so {{cite episode}} uses |title= to name an episode. What is missing from that citation is |series=.
"The C Word". <series name goes here>. 3 May 2015. BBC. Retrieved 3 May 2015. 
Trappist the monk (talk) 12:27, 4 May 2015 (UTC)
Confusing indeed. I modified the help documentation a couple of weeks ago after figuring out this quirk. – Jonesey95 (talk) 14:32, 4 May 2015 (UTC)
Should have used {{Cite serial}} AManWithNoPlan (talk) 14:35, 4 May 2015 (UTC)
Why, given that, it's not a serial? And why have you removed the date of first transmission from that reference? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:54, 4 May 2015 (UTC)
Saying there is no title, when there is a title, is bogus. The error should presumably say "Missing series name". However, there is no series name, as the programme was a one-off. I note that its documentation says "This Citation Style 1 template is used to create citations for television or radio programs and episodes." Why is the parameter required? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:05, 4 May 2015 (UTC)

@Trappist the monk and AManWithNoPlan:. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:31, 10 May 2015 (UTC)

Citing newspaper insert[edit]

I think I've asked this one previously, but I cannot find the old discussion. I would like to cite a weekly insert (i.e. Time Out) that appears in a newspaper (i.e. The Ledger). Which parameter should I use for the insert? Unlike Parade, the insert is published by and only for the main newspaper it appears in. Thanks! - Location (talk) 16:37, 4 May 2015 (UTC)

I think you want |department=. Documentation here. – Jonesey95 (talk) 20:04, 4 May 2015 (UTC)

Link to ISBN[edit]

I noticed an inconsistency in display when ISBN is given via |isbn= and when given in plain text. For example:

  • A Whited, Lana (2004). The Ivory Tower and Harry Potter. University of Missouri Press. ISBN 978-0-8262-1549-9. 
  • A Whited, Lana (2004). The Ivory Tower and Harry Potter. University of Missouri Press. ISBN 978-0-8262-1549-9

The first one (use of |isbn=) contains an extra link to ISBN. The second one is given in plain text. I think this link is unnecessary. Moreover, it's overlinking. -- Magioladitis (talk) 06:50, 6 May 2015 (UTC)

All of the identifier parameters, PMC, doi, zbl, issn are linked to their Wikipedia articles. Why should ISBN render differently?
Trappist the monk (talk) 10:29, 6 May 2015 (UTC)
ISBN 978-0-8262-1549-9 in plaintext is just autoformatted by the wiki (one of those legacys; RFC 1918 is another that is similar) to provide the link in question, whereas we override that functionality by deliberately inserting a link in the template, per Trappist. --Izno (talk) 15:58, 6 May 2015 (UTC)

Trappist the monk I mean we could just unlink all of PMC, doi, zbl, issn as common links and instead of having a wikilink followed by an (almost) external link just inherit the behaviour of ISBN 978-0-8262-1549-9 (plaintext, autoformatted by mediawki). I am just saying my opinion and underlying an inconsistency for viewers. -- Magioladitis (talk) 11:01, 21 May 2015 (UTC)


The topic of |vauthors= support periodically pops up. It has done so again at Module talk:Citation/CS1#Author parsing and at Wikipedia talk:WikiProject Medicine#Medical FA maintenance. |vauthors= is a parameter that is used in {{vcite2 journal}} to hold a strictly formatted Vancouver system-style author name list. {{vcite2 journal}} invokes Module:ParseVauthors which extracts the author names from |vauthors= into a series of |firstn= / |lastn= parameters that it then passes with |name-list-format=vanc and |display-authors=6 along with all of the other parameters to {{cite journal}}.

I have added support for this parameter to Module:Citation/CS1/sandbox. These examples are {{cite book/new}} but the parameter works for the other cs1|2 templates:

A simple case:

First FM, Second FM (2015). Title. 

Supports |author-maskn= and |authorlinkn= as well as CITEREF:

——, Lincoln A (2015). Title. 

allows |vauthors= to contain et al. without adding the page to Category:CS1 maint: Explicit use of et al. because the PMID cite tool, heavily used by WP:MED, did, in the past, and reportedly will again in the future, create citations that include the text:

First FM, Second FM et al. (2015). Title. 

default display of 6 authors even though seven are listed: :First FM, Second FM, Third FM, Fourth FM, Fifth FM, Sixth FM, Seventh FM (2015). Title. 

to display all seven, set |display-authors=7. Category:CS1 maint: display-authors suppressed because in this case there is legitimate need to set |display-authors= to a number equal to or greater than the number of authors: :First FM, Second FM, Third FM, Fourth FM, Fifth FM, Sixth FM, Seventh FM (2015). Title. 

{{citation}}, name list contains an illegal character

First FM; Second FM (2015), Title  Vancouver style error (help)

{{cite journal/new}}, first name's intials not properly capitalized:

First fm; Second FM (2015). "Title". Journal.  Vancouver style error (help)

As currently configured, |vauthors= has priority over |lastn= / |firstn= which has priority over |authors=. Is this the correct hierarchy? Still to do is error reporting when a template includes |vauthors= with any of |lastn= / |firstn= / |authors=.

Trappist the monk (talk) 13:01, 7 May 2015 (UTC)

It occurs to me that if we keep this, we should extend it to support editors with |veditors=.

Trappist the monk (talk) 13:28, 7 May 2015 (UTC)

It makes sense to support this given that vauthors has a format which can be parsed in an expected way (and which can be error checked). I am concerned about not including all authors (to some extent). --Izno (talk) 14:12, 7 May 2015 (UTC)
Nothing about this parameter will prevent you from including a gross of authors if that is your desire. To be compatible with {{vcite2 journal}} which itself complies with this recommendation (at 1), {{cite journal}} should display a maximum of six authors unless otherwise directed by |display-authors=.
Lifting that restriction for the other cs1|2 templates may be 'correct' but may also confuse editors. I think that if we define a standard 'vauthors rule' (up to six authors are displayed unless overridden by |display-authors=), we won't have so many confused editors. If there is sufficient need for a different or no default for other templates, we can address that need as it arises.
Trappist the monk (talk) 14:46, 7 May 2015 (UTC)
I was commenting more about the linked WT:MED discussion regarding that second sentence. --Izno (talk) 18:07, 7 May 2015 (UTC)

A slight revision of the code that handles |display-authors=:

First FM, Second FM, Third FM, Fourth FM, Fifth FM, Sixth FM, Seventh FM (2015). Title. 
First FM, Second FM, Third FM, Fourth FM, Fifth FM, Sixth FM, Seventh FM (2015). Title. 
First FM, Second FM, Third FM et al. (2015). Title. 
|display-authors=etal (four authors listed)
First FM, Second FM, Third FM, Fourth FM et al. (2015). Title. 

And to make sure I didn't break the |display-authors= handling for the |authorn= type of author name list:

First FM; Second FM; Third FM; Fourth FM; Fifth FM; Sixth FM; Seventh FM (2015). Title. 
First FM; Second FM; Third FM; Fourth FM; Fifth FM; Sixth FM; Seventh FM (2015). Title. 
First FM; Second FM; Third FM et al. (2015). Title. 
|display-authors=etal (four authors listed)
First FM; Second FM; Third FM; Fourth FM et al. (2015). Title. 

Trappist the monk (talk) 23:56, 7 May 2015 (UTC)

This is fantastic! Vancouver style authors have been and continue to be widely used in medical and scientific articles. Adding |vauthors= support to CS1 will make it much easier to maintain a consistent citation style in these articles while at the same time producing clean metadata. Thank you Trappist! Boghog (talk) 05:10, 8 May 2015 (UTC)

  • So why can we implment this but not the citation styles that use small caps for authors names...·maunus · snunɐɯ· 05:13, 8 May 2015 (UTC)
    Because that doesn't have consensus per WP:SMALLCAPS? --Izno (talk) 05:18, 8 May 2015 (UTC)
It was REMOVED without consensus! And it has consensus aslong a WP:CITEVAR is in effect.·maunus · snunɐɯ· 23:56, 8 May 2015 (UTC)

It occurs to me that setting the artificial limit to the number of authors to be displayed (6) is inconsistent with the other author-holding parameters. I think that imposing such a limit on editors will just be confusing. If editors wish to constrain the display, they should do it with |vauthors= in the same way that they would for |authorn= and for |lastn= / |firstn=: use |display-authors=. So, I've removed the 6-author display constraint from the sandbox.

Trappist the monk (talk) 11:36, 10 May 2015 (UTC)

The default should be set to what most editors prefer. Editors that use |vauthors= presumably prefer compact Vancouver style output. Since the original ICMJE recommendation is to display only the first six authors, I suspect that many of these same editors would support following this recommendation. The whole idea |vauthors= is to reduce the number of required citation parameters. If most editors end up adding |display-authors=6, it partially defeats the purpose of using |vauthors=. Boghog (talk) 12:37, 10 May 2015 (UTC)
You wrote: The tool will return to its default (list all authors if there are five or less, and truncate to three plus et al if there are six or more). Since the tool will be artificially limiting the number of authors, and because the tool is apparently commonly used, shouldn't that be sufficient? The template should not impose an artificial limit on one author-name-holding parameter that it doesn't also impose on |authorn= and |lastn= / |firstn= parameters. When editors desire to include more authors in the template than are to be displayed, they should use the same mechanism (insofar as is possible – it won't work on |authors=) that is used with other author-name-holding parameters. If compactness is desired, there is nothing to prevent editors from simply reducing the number of authors listed in |vauthors=.
Trappist the monk (talk) 15:39, 10 May 2015 (UTC)
There is developing consensus over at WT:MED (and also supported by Izno above) that all authors should be included in the author list. As I subsequently wrote, the tool's default has been changed to include all authors and will only truncate the author list if the "Use et al. for author list" option is selected. The "et al." option is retained for FA MED articles and for citations with "hyperauthorship". Boghog (talk) 16:17, 10 May 2015 (UTC)
Apparently, there is some support at WT:MED (here and here) for listing all and truncating the list with |display-authors=. If a consensus develops outside of WP:MED to artificially limit the displayed length of a Vancouver-style author-name list, then we should consider doing that but I think that it isn't quite right to allow WP:MED to define this parameter's functionality based on WP:MED's unique preferences when such preferences may not match those of other projects or other editors.
Trappist the monk (talk) 17:06, 10 May 2015 (UTC)
By far, the widest use of the citation filling tool and {{vcite2 journal}} has been within the WP:MED and WP:MCB projects and the participants within these two projects largely overlap. Hence the consensus at WP:MED is significant and carries at least as much weight as this talk page. Finally {{vcite2 journal}} has been transcluded into ~2600 pages and has included |display-authors=6 from the beginning. Not one editor has objected to this setting. Boghog (talk) 17:46, 10 May 2015 (UTC)
I do not doubt that. But, {{vcite2 journal}} is not {{cite journal}}, {{cite book}}, {{cite web}} nor any of the other 20-some cs1|2 templates. For editors who use those templates, there are no artificial limits such as those that WP:MED have imposed upon themselves. I suspect that a requirement to add |display-authors=n to show more than 6 authors is going to be confusing because editors don't need to do that with |author= or |authors=.
Trappist the monk (talk) 23:10, 10 May 2015 (UTC)

Corporate authors and |vauthors=[edit]

What to do about corporate authors? This cite throws two errors because '16' is not in the set of letters allowed by the Vancouver name test and because the 'first name', 'Consortium' is not one or two uppercase letters. A quick search of the Vancouver system documentation for the terms 'corporate' and 'institutional' was unproductive. The corporate author in this citation renders correctly:

European Chromosome 16 Tuberous Sclerosis Consortium (1993). "Identification and characterization of the tuberous sclerosis gene on chromosome 16". Cell 75 (7): 1305–15. doi:10.1016/0092-8674(93)90618-Z. PMID 8269512.  Vancouver style error (help)

but, the metadata are flawed:


This is because there isn't a mechanism in place to identify this author as a corporate author.

There are citations in article space that list both individual and corporate authors using the existing author-holding parameters. If a corporate or institutional author is listed separately in |authorn= or |lastn=, the citation renders correctly and the metadata are not corrupted. |authors= almost always produces corrupt metadata. It should be expected that editors will create citations that will include both individual and corporate authors in |vauthors=.

One possible solution might be to require that corporate authors be 'wrapped' in some sort of simple markup:

|vauthors=[European Chromosome 16 Tuberous Sclerosis Consortium], First FM, Second FM

The wrapping bypasses the usual Vancouver name test so any character is allowed within the brackets. This should not be used to defeat the test for individual author-names.

Using this scheme, this citation:

[European Chromosome 16 Tuberous Sclerosis Consortium], First FM, Second FM (1993). "Identification and characterization of the tuberous sclerosis gene on chromosome 16". Cell 75 (7): 1305–15. doi:10.1016/0092-8674(93)90618-Z. PMID 8269512.  Vancouver style error (help)

produces this correct metadata:


I have added code to trap the expected case when editors write [[ and ]].

European Chromosome 16 Tuberous Sclerosis Consortium, First FM, Second FM (1993). "Identification and characterization of the tuberous sclerosis gene on chromosome 16". Cell 75 (7): 1305–15. doi:10.1016/0092-8674(93)90618-Z. PMID 8269512.  Vancouver style error (help)

An opening [[ without a closing ]] does not produce an error because WikiMedia never finds the ending ]] so the template's }} is never found.

While this example uses square brackets, perhaps a better markup would be doubled parentheses in this fashion:

|vauthors=((European Chromosome 16 Tuberous Sclerosis Consortium)), First FM, Second FM

Doubling the parentheses is closely akin to other doubled markup used in Wikitext but it is not used anywhere else that I know of. Parentheses are not allowed by the Vancouver name test so their presence won't be confused as a proper part of a name.

Opinions? Is there a better way to detect or define corporate or institutional authors?

Trappist the monk (talk) 13:32, 10 May 2015 (UTC)

I don't have a strong feeling about this. The ICMJE recommendations suggest that individual and organization authors be separated by a semicolon. This recommendation is followed by PubMed (see for example PMID: 12771764). However I don't think we should follow this particular recommendation as it would make error checking less robust (one of the most common vauthors errors is likely to be the use of standard CS1 rendered author format).
Another possibility is to use |vauthors= for the individual authors and |authorn= for the organization author. For example:
  • {{vcite2 journal | vauthors = Vallancien G, Emberton M, Harving N, van Moorselaar RJ | author5 = Alf-One Study Group | title = Sexual dysfunction in 1,274 European men suffering from lower urinary tract symptoms | journal = J. Urol. | volume = 169 | issue = 6 | pages = 2257–61 | year = 2003 | pmid = 12771764 | doi = 10.1097/01.ju.0000067940.76090.73 }} renders as:
  • Vallancien G, Emberton M, Harving N, van Moorselaar RJ, Alf-One Study Group (2003). "Sexual dysfunction in 1,274 European men suffering from lower urinary tract symptoms". J. Urol. 169 (6): 2257–61. doi:10.1097/01.ju.0000067940.76090.73. PMID 12771764. 
This does not currently work with {{cite journal/new}} however. Please note that citations with organization authors are not very common. Furthermore I don't object to using extra parameters to cover special cases that occur infrequently. Boghog (talk) 16:57, 10 May 2015 (UTC)
Also if there is a single author and that author is an organization, it would be much more practical to use |author1= instead of |vauthors=. Boghog (talk) 17:04, 10 May 2015 (UTC)
I agree that for a single corporate author, |author= should be preferred. I suspect that editors will use |vauthors= for single author names whether they are human or corporate.
The mix of |vauthors= and |authorn= intentionally doesn't work in Module:Citation/CS1/sandbox. The Module currently disallows the combination of |authors= with |authorn= (and its alias |lastn= with |firstn=) because the former is not formatted by the template and the latter is and because |authors= is not an alias of |authorn=. Similarly, |authorn= is not an alias of |vauthors= so mixed use would blur the line between those two styles. This is why I suggested that corporate authors should be included in |vauthors= with appropriate markup to render the visual presentation and the metadata properly.
I agree that corporate authors and individual authors should not be separated by semicolons.
Trappist the monk (talk) 17:33, 10 May 2015 (UTC)
I have changed the corporate or institutional mark up from single square brackets to doubled parentheses because single square brackets have meaning as external link markup:
{{cite journal/new | vauthors = Vallancien G, Emberton M, Harving N, van Moorselaar RJ, ((Alf-One Study Group)) | title = Sexual dysfunction in 1,274 European men suffering from lower urinary tract symptoms | journal = J. Urol. | volume = 169 | issue = 6 | pages = 2257–61 | year = 2003 | pmid = 12771764 | doi = 10.1097/01.ju.0000067940.76090.73 }} renders as:
Vallancien G, Emberton M, Harving N, van Moorselaar RJ, Alf-One Study Group (2003). "Sexual dysfunction in 1,274 European men suffering from lower urinary tract symptoms". J. Urol. 169 (6): 2257–61. doi:10.1097/01.ju.0000067940.76090.73. PMID 12771764. 
Trappist the monk (talk) 12:49, 13 May 2015 (UTC)

|vauthors= and |authorn= and |authors=[edit]

Because there are now three possible sources for authors, I think that we should choose one of the three and emit an error message when more than one of these sources is present in the template. The hierarchy in the sandbox is: |authorn= (includes |lastn=, an alias and |firstn=|vauthors=|authors=. The current live version of the module emits an error message when |authors= and |authorn= are both detected.


First LF, Second LF, Third LF (2015). Title. 


First VF, Second VF, Third VF (2015). Title. 


First AF, Second AF, Third AF (2015). Title. 

|vauthors= and |author1=:

  • Fourth LF; Fifth LF; Sixth LF; Seventh LF (2015). Title.  More than one of author-name-list parameters specified (help)

|vauthors= and |authors=:

  • First VF, Second VF, Third VF (2015). Title.  More than one of author-name-list parameters specified (help)

|author1= and |authors=:

  • First LF, Second LF, Third LF (2015). Title.  More than one of author-name-list parameters specified (help)

|vauthors=, |author1=, and |authors=:

  • First LF, Second LF, Third LF (2015). Title.  More than one of author-name-list parameters specified (help)

There is a limit to this. When |vauthors= or |authors= are used with |authorn=, n must be 1 or 2 to be detected. This is because n could conceivably be any number greater than 0 and there are 6 aliases of |authorn=. The test is similar to the test that is used to detect missing |lastn= which uses a 'hole' size of 2 to decide that the test is done.

Trappist the monk (talk) 23:10, 10 May 2015 (UTC)


A first hack at |veditors=. I cloned the code that does the author selection to do editor selection from |editorn= (and its aliases), |editors=, and |veditors=. Except for names, the code is identical to that used for authors so I need to figure out how to combine the two into a single function. The code that interprets |vauthors= and |veditors= and then creates the name list that is later rendered as an author list or an editor list is the same. These example show that the sandbox code is capable of properly rendering a |veditors= name list.


First LF, Second LF, Third LF, ed. (2015). Title. 


First VF, Second VF, Third VF, eds. (2015). Title. 


First AF, Second AF, Third AF, eds. (2015). Title. 

|veditors= and |editor1=:

  • Fourth LF; Fifth LF; Sixth LF et al., eds. (2015). Title.  More than one of editor-name-list parameters specified (help);

|veditors= and |editors=:

  • First VF, Second VF, Third VF, eds. (2015). Title.  More than one of editor-name-list parameters specified (help)

|editor1= and |editors=:

  • First LF, Second LF, Third LF, ed. (2015). Title.  More than one of editor-name-list parameters specified (help)

|veditors=, |editor1=, and |editors=:

  • First LF, Second LF, Third LF, ed. (2015). Title.  More than one of editor-name-list parameters specified (help)

Trappist the monk (talk) 19:18, 11 May 2015 (UTC)

Citing youtube and online video sites[edit]

Apologies if this question has been asked a gazillion times already. What is the preferred cite AV media parameters for citing a youtube or other online video: 1) from the direct site itself, and 2) from a wrapper site / news article that embeds the video? Should I use work=YouTube, medium=YouTube, or via=YouTube? AngusWOOF (barksniff) 18:57, 7 May 2015 (UTC)

It probably hasn't, but I'll throw a suggested answer out:
  1. If you are citing content in the video itself, I would recommend clicking through to the origin website ( in your example) and using that URL. This is cite AV media.
  2. If you are citing content outside the video, the URL you are on at that time. In this case I don't see a need to mention YouTube or a video or media at all in the context of the citation so I would use cite web/cite news.
  3. If for some reason you need both (I can't think of one), then provide two citations.
work = YouTube is fine. medium as a parameter does not exist in the documentation (using ctrl + F). via would be appropriate in the 3rd case. --Izno (talk) 19:25, 7 May 2015 (UTC)

titlelink oddity in cite encyclopedia[edit]

According to the cite encyclopedia documentation, |title-link= is "Title of existing Wikipedia article about the source named in title" – yet it actually links the text in |encyclopedia=, not |title=:

Cite encyclopedia compare
{{ cite encyclopedia | via=[[Wikisource]] | title=Gopher | year=1879 | encyclopedia=The American Cyclopædia (1879) | titlelink=s:The American Cyclopædia (1879)/Gopher }}
Live "Gopher". The American Cyclopædia (1879). 1879 – via Wikisource. 
Sandbox "Gopher". The American Cyclopædia (1879). 1879 – via Wikisource. 

|url= works as expected, but full urls shouldn't be necessary when wikilinks are available

Cite encyclopedia compare
{{ cite encyclopedia | via=[[Wikisource]] | title=Gopher | year=1879 | encyclopedia=The American Cyclopædia (1879) | url= }}
Live "Gopher". The American Cyclopædia (1879). 1879 – via Wikisource. 
Sandbox "Gopher". The American Cyclopædia (1879). 1879 – via Wikisource. 

Can this be fixed? Thanks - Evad37 [talk] 00:21, 8 May 2015 (UTC)

It is perhaps fixed in the sandbox. I have no more time to think about it for a couple of days.
Trappist the monk (talk) 00:38, 8 May 2015 (UTC)

access-date usage definition[edit]

I notice that on many cite template related pages that the given usage for |access-date= varies. I believe that "full date when the contents pointed to by url was last verified to support the text in the article" (as given in the cite book documentation) best captures what is intended for |access-date=. Yet many places (like on Help:Citation Style 1 itself or places like Category:Pages using citations with accessdate and no URL give differing definitions, mostly because the authors who wrote them probably weren't trying to be as precise as they should have been. I intend to start tweaking the usage definition for accessdate whenever I see it saying something too unlike that of Template:Cite book. If you can think of CS1 examples where |access-date= really should not use "full date when the contents pointed to by url was last verified to support the text in the article", let me know. Jason Quinn (talk) 11:30, 11 May 2015 (UTC)

I have copy-edited the |access-date= documentation just now. I fixed some grammar and changed the word "required", since "required" has a specific meaning for template parameters, and |access-date= does not meet that definition.
All of the CS1 core templates that display the |access-date= help text in their documentation should be using the exact same text to describe the parameter, since they (should) transclude Template:Citation_Style_documentation/url.
I support your changing of Help:Citation Style 1. The category page linked above I'm not as sure about. It has a pretty good explanation that has been developed over time to be helpful. Feel free to be bold and change it, but don't be offended if one of us swoops in after you with changes to your changes. Thanks. – Jonesey95 (talk) 13:53, 11 May 2015 (UTC)

enumerated parameters[edit]

I started doing the searches identified in the following tables so that I might have some idea of how to better order the search for enumerated author and editor names. But, the search also shows general editor preferences for certain parameter styles and for certain parameter names.

|first= aliases
parameter search string count
|author-firstn= insource:/\| *author\-first[0-9]* *=/ 227
|authorn-first= insource:/\| *author[0-9]+\-first *=/ 96
|firstn= insource:/\| *first[0-9]* *=/ 51,274
|givenn= insource:/\| *given[0-9]* *=/ 473
|last= aliases
parameter search string count
|author-lastn= insource:/\| *author\-last[0-9]* *=/ 236
|authorn-last= insource:/\| *author[0-9]+\-last *=/ 94
|lastn= insource:/\| *last[0-9]* *=/ 43,262
|surnamen= insource:/\| *surname[0-9]* *=/ 800
|authorn= insource:/\| *author[0-9]* *=/ 42,398
|subjectn= insource:/\| *subject[0-9]* *=/ 14,880dagger

dagger used by {{cite interview}} but also used by {{infobox book}}, {{In-universe}}, {{databank}} so this number is essentially meaningless

|author-link= aliases
parameter search string count
|author-linkn= insource:/\| *author\-link[0-9]* *=/ 19,139
|authorn-link= insource:/\| *author[0-9]+\-link *=/ 10,044
|authorlinkn= insource:/\| *authorlink[0-9]* *=/ 53,345
|authornlink= insource:/\| *author[0-9]+link *=/ 50
|subject-linkn= insource:/\| *subject\-link[0-9]* *=/ 47
|subjectn-link= insource:/\| *subject[0-9]+\-link *=/ 1
|subjectlinkn= insource:/\| *subjectlink[0-9]* *=/ 679
|subjectnlink= insource:/\| *subject[0-9]+link *=/ 0
|author-mask= aliases
parameter search string count
|author-maskn= insource:/\| *author\-mask[0-9]* *=/ 710
|authorn-mask= insource:/\| *author[0-9]+\-mask *=/ 7
|authormaskn= insource:/\| *authormask[0-9]* *=/ 511
|authornmask= insource:/\| *author[0-9]+mask *=/ 22
|editor-first= aliases
parameter search string count
|editor-firstn= insource:/\| *editor\-first[0-9]* *=/ 32,889
|editorn-first= insource:/\| *editor[0-9]+\-first *=/ 23,224
|editor-givenn= insource:/\| *editor\-given[0-9]* *=/ 0
|editorn-given= insource:/\| *editor[0-9]+\-given *=/ 0
|editor-last= aliases
parameter search string count
|editorn= insource:/\| *editor[0-9]* *=/ 33,883
|editor-lastn= insource:/\| *editor\-last[0-9]* *=/ 33,442
|editorn-last= insource:/\| *editor[0-9]+\-last *=/ 21,130
|editor-surnamen= insource:/\| *editor\-surname[0-9]* *=/ 0
|editorn-surname = insource:/\| *editor[0-9]+\-surname *=/ 0
|editor-link= aliases
parameter search string count
|editor-linkn= insource:/\| *editor\-link[0-9]* *=/ 7,988
|editorn-link= insource:/\| *editor[0-9]+\-link *=/ 5,183
|editorlinkn= insource:/\| *editorlink[0-9]* *=/ 297
|editornlink= insource:/\| *editor[0-9]+link *=/ 41
|editor-mask= aliases
parameter search string count
|editor-maskn= insource:/\| *editor\-mask[0-9]* *=/ 19
|editorn-mask= insource:/\| *editor[0-9]+\-mask *=/ 6
|editormaskn= insource:/\| *editormask[0-9]* *=/ 16
|editornmask= insource:/\| *editor[0-9]+mask *=/ 1

I have never really liked parameters where the enumerator is in the middle of the parameter name: |authorn-first= and |editornlink= for example, regardless of hyphenation. For many of the same reasons that we settled on hyphenated parameter names and have deprecated capitalized and camel-case parameter names, I think that we should settle on one standard form of enumerated parameter name. From the tables above, common usage would seem to suggest that editors generally prefer parameter names with the enumerator at the end of the name. Except when it comes to enumerated editor parameters. While enumerator-at-the-end is still preferred, enumerator-in-the-middle runs a close second.

These tables also show that some of the available enumerated parameter are rarely if ever used. Perhaps we should consider deprecating:



Trappist the monk (talk) 12:33, 12 May 2015 (UTC)

As frequent readers here know, I am often in favor of change, but I think this change is not necessary. It's cleaner, for sure, but it's actually less consistent across the parameters. If we do it, I expect that someone will come along at some point and say "We have parameter X, but we don't have the obvious parallel parameter Y." And then it's a big discussion. I don't know.... – Jonesey95 (talk) 13:12, 12 May 2015 (UTC)
There are really two items for consideration here: standardized enumeration and deprecating some rarely/never used parameters. Which of these are you saying will be less consistent across the parameters?
Trappist the monk (talk) 13:21, 12 May 2015 (UTC)
Having |editorn-link= but not |subjectn-link= makes the parameters less standard. I would rather have both or remove both than just have one of them. – Jonesey95 (talk) 14:44, 12 May 2015 (UTC)
I think that you are only focusing on the proposal to deprecate the short list of parameters and ignoring the proposal to standardize enumerated parameters. Were we to not standardize, then perhaps you are right.
If I had my way, the standard for enumerated parameters would be enumerator-at-the-end so both |editorn-link= and |subjectn-link= would be deprecated (even were we to not deprecate the latter because of disuse). We would still have as active and supported parameters: |editor-linkn= and |subject-linkn=. Parameters in the form |xxxxnyyyy= or |xxxxn-yyyy= would be deprecated and ultimately replaced with the extant |xxxx-yyyyn= form. I don't see much point in keeping both forms which I think is supported by the data in the tables above.
Trappist the monk (talk) 15:44, 12 May 2015 (UTC)
Now I see what you're saying, I think. I support standardizing on |parameter-namen= as the canonical form of two-word-plus-number parameters in our documentation (I haven't checked to see what the docs currently say). I don't see the point of deprecating the |parametern-name= form on what appear to be aesthetic grounds. I won't die on that hill, though; if others feel strongly, go for it, but please do show up on this page to respond when people complain that we are constantly changing things for no good reason. – Jonesey95 (talk) 23:52, 12 May 2015 (UTC)
How is deprecating enumerator-in-the-middle parameters different from deprecating capitalized parameters?
Trappist the monk (talk) 11:47, 13 May 2015 (UTC)
I would argue for keeping |givenn= and |surnamen= (and their editor versions), and adding them to the documentation. Having recently edited a lot of citations with East Asian authors, I find it confusing to have to put an author's first name into |last= and their last name into |first=, and I have seen editors erroneously "correcting" them. Kanguole 16:19, 12 May 2015 (UTC)
I have said nothing about deprecating |givenn= and |surnamen=. Certainly, if I had my way we would deprecate |editorn-given= and |editorn-surname= because of enumerator-in-the-middle syndrome and because of disuse. Because of disuse, I'm inclined to deprecation of |editor-givenn= and |editor-surnamen= but could be persuaded to keep them, at least for a time.
Trappist the monk (talk) 16:40, 12 May 2015 (UTC)
I would argue to keep |editor-givenn= and |editor-surnamen= for the same reasons as above: they provide an alternative that is less confusing and error-prone. Kanguole 12:10, 13 May 2015 (UTC)

Get first1 and last1 parameters to work in Wikiversity too[edit]

The corresponding template in Wikiversity (Wikiversity:Template:Cite journal) does not support the parameters first1, last1, first2 etc. How can this functionality be copied from this template to that one? Mikael Häggström (talk) 18:05, 12 May 2015 (UTC)

Since Wikiversity already has Wikiversity:Template:Citation/core, it might be simplest to copy {{cite journal/old}} from en:WP to Wikiversity:Template:Cite journal/sandbox to prove that it works (because the Wikiversity version of {{citation/core}} is somewhat older) and then, assuming that it does work, update the live {{cite journal}} from the sandbox. That will give you up to 9 author names.
Wikiversity also has very old version Wikiversity:Module:Citation/CS1 so using that instead of {{citation/core}} is another alternative. A rather bigger job would be to upgrade the module to use the current version of Module:Citation/CS1 from en:WP.
Trappist the monk (talk) 18:41, 12 May 2015 (UTC)
It does work now, after copying {{cite journal/old}} from en:WP to {{cite journal}}, thanks! It would be even better, however, if the author presentation had Wikipedia's style (First L instead of First, L;). Would that be achieved by performing any of the latter methods you described? Mikael Häggström (talk) 05:06, 14 May 2015 (UTC)
Standard Wikipedia style is to put a comma between an author's last and first names and to separate consecutive authors with a semicolon. cs1|2 does not render author names in italics (nor does it render first name followed by last initial):
{{cite book/old |title=Title |last=Last |first=F |last2=Last2 |first2=F}}
Last, F; Last2, F. Title. 
If you are looking to mimic Vancouver system style you can do this:
{{cite book |author-separator=, |author-name-separator=&#32; |title=Title |last=Last |first=F |last2=Last2 |first2=F}}
Last F, Last2 F. Title. 
Trappist the monk (talk) 11:06, 14 May 2015 (UTC)
Thanks again! Face-smile.svg Mikael Häggström (talk) 04:44, 15 May 2015 (UTC)

Can parameters be passed to a nested cite web?[edit]

I'm trying to modify the Airreg template so that it produces in-line citations instead of external links, but when I try to nest a {{cite web}} into it, the parameters taken by Airreg and passed to {{cite web}} don't seem to get processed by it, and the output is just {{{1}}}, {{{2}}} etc..

Instead, the same parameters passed, for example, to a nested {{conversion}} are processed normally, as expected. Is there something peculiar about {{cite web}} that, when nested, prevents it from accepting parameters?

See an example from my sandbox template, which takes one parameter, e.g. 'N4739N', outputs it as it is and then passes it to cite web, which seems to ignore it. This:


produces this:

Aircraft registration: N4739N[1]

--Deeday-UK (talk) 00:46, 14 May 2015 (UTC)


There are a several templates that feed various parameters to {{cite web}} or other cs1|2 templates (see Category:Citation Style 1 meta-templates or Category:Citation Style 1 specific-source templates) so that shouldn't be a problem. Have you tried your test without the <ref>...</ref> tags?
Trappist the monk (talk) 01:00, 14 May 2015 (UTC)
Good hint TtM, yes, without the <ref>...</ref> tags the parameters are processed as expected. Only trouble is that without the ref tags, it doesn't produce a superscript reference to a footnote, and instead it outputs the footnote text directly into the article body, right where the {{cite web}} template is. Is there any way around it? --Deeday-UK (talk) 01:23, 14 May 2015 (UTC)
Try wrapping {{cite web}} in {{#tag:ref|{{cite web |...}}}}.
Trappist the monk (talk) 01:52, 14 May 2015 (UTC)
Major thanks, Trappist tm; that worked. --Deeday-UK (talk) 17:22, 14 May 2015 (UTC)

Proposal to put a comma before "et al."[edit]

There is a proposal to put a comma before "et al." in author and editor lists. See this discussion. – Jonesey95 (talk) 03:22, 14 May 2015 (UTC)

Journal article titles[edit]

I've always assumed that the titles of both journal articles and book chapters should be in 'sentence case' (rather than in 'title case') but I cannot find any guidance on the wiki MOS pages. Have I missed it? If there is a recommended style, perhaps it would be useful to include guidelines in the cite journal documentation. Aa77zz (talk) 12:06, 18 May 2015 (UTC)

Title case, I think. See: Wikipedia:Manual of Style#Titles of works.
Trappist the monk (talk) 12:12, 18 May 2015 (UTC)
I disagree with the concept that CS1 follows the MOS. Only certain specific guidance has been adopted; the only guidance I know of adopted from MOS was date format, and that was a problem, because MOSNUM date guidance was being changed faster than the templates could be edited to keep up. As far as I know, there is no guidance whether to use sentence case or title case for journal article titles in citations. Jc3s5h (talk) 12:50, 18 May 2015 (UTC)
Absent any declaration of specific style to the contrary, it is appropriate to fall back on MOS: for style guidance. Style for titles is not defined for cs1|2 templates because there is no provision to detect deviation from a defined style and so enforce adherence to that style. As an aside, I have been wondering of late, about detecting and categorizing templates that have titles and other information in all capital letters.
Trappist the monk (talk) 14:09, 18 May 2015 (UTC)
I disagree with the whole concept that only style matters that can be checked by programming language in a template are defined for CS1. If CS1 is a citation style in its own right, then style matters can be prescribed in the documentation even though they are not enforceable with software. Likewise, style prescriptions can be made in the documentation that, for the time being, are incorrectly implemented in the software (February 29, 1700, Julian calendar). In such cases it is the software that is faulty, not the editor who filled out the template. Jc3s5h (talk) 19:08, 19 May 2015 (UTC)
Of course, but cs1|2, if it is a style, does not have documentation that defines that style. You will recall that I have previously asked both you and the community if we aught not create a style guide for cs1|2. Those suggestions have been met with ambivalence. So that leaves the cs1|2 'style definition' in the code or, as in the case for dates, a mention that dates for the most part comply with WP:DATESNO. Template documentation describes what the tempate parameters mean and how the contents are rendered, but that is not a style guide.
At present, cs1|2 has no defined title style except that, de facto, it accords with MOS:TITLE: chapter titles and article titles are quoted; book, journal, encyclopedia titles are italicized. cs1|2 does, to an extent, check certain components of style: dates, of course, but also Vancouver system author and editor names (when |name-list-format=vanc and in future with |vauthors=).
The documentation for cs1|2 dates says "Module:Citation/CS1 cannot know if a date is Julian or Gregorian; assumes Gregorian" which is both correct and incorrect. In fact, dates before 1582 are Julian and dates from 1582 are Gregorian and the module knows this:
{{cite book |title=Title |date=29 February 1500}}
Title. 29 February 1500. 
I'll tweak that documentation.
I did a quick search for Julian leap day dates in years 1700, 1800, and 1900 using these insource: search strings:
insource:/February *29 *, *1[7-9]00/ – 3 results, none of which were dates in references (all about Microsoft Excel)
insource:/29 *February *1[7-9]00/ – 3 results, one is a free-form reference where the date 29 February 1900 is mentioned
insource:/1[7-9]00-02-29/ – this search produced nothing
It would seem then that there is not much call for cs1|2 to support Julian leap days in the overlap period of 1582 – c. 1923. To do so would require some sort of mechanism to specifically identify those three dates as Julian dates; which can be done if there is ever a need.
Trappist the monk (talk) 22:22, 19 May 2015 (UTC)
I usually tend to sentence case for journal entry/article titles since these seem to have uncommon capitalization (Or Use Capital Letters For Obvious Emphasis, something which is on the Do Not Do list at Wikipedia:Manual of Style/Capital letters#Do not use for emphasis; WP:BADEMPHASIS is also relevant).

Regardless, I would recommend asking this question at WT:MOS with a note to that discussion from WT:Citing sources or similar (or vice versa as desired), since I don't think this is a question particularly specific to CS1. --Izno (talk) 14:58, 18 May 2015 (UTC)

Many thanks for your help. I've taken Izno's advice and asked the question at WT:MOS. Aa77zz (talk) 17:13, 18 May 2015 (UTC)
I think everyone is missing the point here. MOS applies to text, not citations. MOS is irrelevant to this discussion. Journal article titles and journal names typically use title case, not sentence case. We should follow the case that is used in the original sources, not the MOS. Boghog (talk) 19:19, 19 May 2015 (UTC)
In my experience, citations to journal article titles generally use sentence case, regardless of how the journal formatted the title. This is also how the titles are represented in some databases, for example MathSciNet. —David Eppstein (talk) 19:53, 19 May 2015 (UTC)
I agee that MOS applies to text, not citations. WP:CITE applies; it allows the style to be determined on an article-by-article basis, but "citations within any given article should follow a consistent style." This consistency requirement agrees with every printed style guide and every university instructor I have ever encountered. So it would be wrong to change from sentence case to title case from one entry to the next, depending on how the title was printed in the source. Jc3s5h (talk) 19:56, 19 May 2015 (UTC)
APA says use sentence case.I think that is stupid, but that is what they say. AManWithNoPlan (talk) 20:03, 19 May 2015 (UTC)

Link to an author page, without breaking "first1, last1 separate" convention?[edit]

Is there a way to have an author name linked to a page about that person, yet still retain the use of the separated "first1" and "last1" parameters (useful for bots searching wikipedia I suppose)? On the page Unknot, there's a reference to a paper by Godfried Toussaint. I had wanted to put this (with separate names):

{{cite journal |author = [[Godfried Toussaint]] |last1 = Toussaint |first1 = Godfried Toussaint |title = A new class of stuck unknots in Pol-6 | [...] }}

but had to settle for the slightly less-informative:

{{cite journal |author = [[Godfried Toussaint]] |title = A new class [...] }}

to avoid getting a "double author" error. Is there some other way to do this? Perhaps an additional "author-link" parameter? (But then you could have problems with multiple authors, so you'd need "author-link", "author-link1") Jimw338 (talk) 16:20, 19 May 2015 (UTC)

|first=Godfried|last=Toussaint|author-link=Godfried Toussaint Kanguole 16:28, 19 May 2015 (UTC)
Yes, as the documentation already states and Kanguole cryptically implies, the authorlink, author1-link, etc parameters you are asking for are already in place. —David Eppstein (talk) 16:51, 19 May 2015 (UTC)
The documentation should help you. If not, here's an example with two linked authors:
{{cite journal |author-link1 = Godfried Toussaint |last1 = Toussaint |first1 = Godfried |last2=Newton|first2=Isaac|author-link2=Isaac Newton |title = A new class of stuck unknots in Pol-6 }}
Toussaint, Godfried; Newton, Isaac. "A new class of stuck unknots in Pol-6". 
Is that what you were looking for? – Jonesey95 (talk) 20:21, 19 May 2015 (UTC)

Foreign author name[edit]

If the author's name uses a non-Latin script, should it be romanized? Where should the original form and romanization go? --Djadjko (talk) 01:33, 22 May 2015 (UTC)

It would be preferable to use the Latin-alphabet spellings plus the other language in parentheses brackets, perhaps as in "author=Plato (Greek: Πλάτων Plátōn)" but ideally, we wanted translation parameters to hold the translated author name, similar to trans_title for the title parameter.
      • Example: {cite book |title=Demos |trans_title=People |author=Plato (Greek: Πλάτων Plátōn) |year=370 BCE}}
      • Result: Plato (Greek: Πλάτων Plátōn) (370 BCE). Demos [People].  Check date values in: |date= (help)
The idea is to focus on the English-speaking readership. -Wikid77 (talk) 15:52, 23 May 2015 (UTC)
I've manage to do it the following way for Russian:
И. И. Иванов [I. I. Ivanov] (2010). Книжка [Book] (in Russian). Moscow: Издательство. ISBN 000 Check |isbn= value (help). 
({{Cite book|ref={{sfnref|Ivanov|2010}}|title=Книжка|trans-title=Book|language=ru|authors=И. И. Иванов [I. I. Ivanov]|date=2010|publisher=Издательство|place=Moscow|isbn=000}}). --Djadjko (talk) 01:35, 25 May 2015 (UTC)
Citation Style 1 is based on APA style with a dose of The Chicago Manual of Style thrown in along with our own innovations. So looking at the APA style for advice, they say to transliterate the names in the source to produce the final citation. CMOS says that for sources with titles in non-Latin alphabets to use the transliterated names/titles first and optionally follow them with the non-Latin versions second.
Wikid77's example, using our existing template parameters would be:
  • Plato (370 BCE). Demos [People].  Check date values in: |date= (help)
Note, there's really no reason to give the Greek translation of an author so well known in English.
For Djadjko's example:
  • Ivanov, I. I. (2010). Kniga Книжка [Book] (in Russian). Moscow: Izdatelystvo. ISBN 000 Check |isbn= value (help). 
|script-title=ru:Книжка will add the non-transliterated title, and where necessary, it handles right-to-left coding (Hebrew, Arabic, etc). Imzadi 1979  03:10, 25 May 2015 (UTC)