Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
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.


Feature request: |note= parameter[edit]

It'd be nice to have a |note= parameter, so that things like "Source is a blog, but published by a project of the city government; primary but not self-published.", kept with (inside) the citation instead of external to it in an HTML comment. It's pretty common to to use a pseudo-parameter like |note=, or (in other contexts, like cleanup/dispute templates) |reason=, for this purpose, but CS1's auto-detection and red-flagging of unrecognized parameters makes this impossible at present.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:06, 15 July 2015 (UTC)

It would be nicer still to have a |null= to work around the red-flagging because there are time when as SMcCandlish unrecognized parameters are convenient. -- PBS (talk) 22:56, 15 July 2015 (UTC)
I think the problem with the example above is that all of the other parameters in CS1 are for bibliographic data that theoretically at least is understandable to readers and meaningful outside Wikipedia. Whereas that comment would be understandable to maybe 1 or 2 out of every 1,000 Wikipedia readers – the ones who are familiar with what WP editors usually mean when they call a source "primary". For that sort of thing, an HTML comment embedded in the wikitext seems like exactly the right way to handle it. Let's keep meta comments and WP-specific issues separate from the data. – Margin1522 (talk) 11:21, 16 July 2015 (UTC)
SMcCandlish is not proposing a display variable, but one to be used in place of <!-- a hidden comment --> as the parameter |reason= is used in the template {{Clarify}}. -- PBS (talk) 19:35, 16 July 2015 (UTC)
I can see the advantage of a |note= parameter. I find the |others= parameter very useful - today I've used it to flag "(published anonymously)". Library catalogs sometimes use square brackets for this. Aa77zz (talk) 20:19, 16 July 2015 (UTC)
Like this from Finch?:
{{ cite book | last=Leach | first=William Elford | author-link=William Elford Leach | year=1820 | chapter=Eleventh Room | title= Synopsis of the Contents of the British Museum | place=London | publisher=British Museum | edition=17th| pages=65-70 | others=(published anonymously) }}
Specifically these bits:
| publisher=British Museum and | others=(published anonymously)
One contradicts the other. And, from the template documentation at Authors:
  • others: To record other contributors to the work, including illustrators and translators. For the parameter value, write Illustrated by John Smith or Translated by John Smith.
I think that your use of |others= as you have done is an improper use of the parameter.
Trappist the monk (talk) 22:23, 16 July 2015 (UTC)
I was well aware that my use was "improper" but I had wanted to say that the author wasn't specified rather than the publisher wasn't specified. I've now deleted the parameter.Aa77zz (talk) 07:05, 17 July 2015 (UTC)
At Finch it now says: "The name of the author is not specified in the document." If that is so, then who is | last=Leach | first=William Elford?
Trappist the monk (talk) 09:31, 17 July 2015 (UTC)
I was trying to simplify as this isn't an important reference. In the Finch article I've actually cited two sources - the other is Bock 1994. It is Bock who gives the information about the publication: "All the parts of this public guide to the British Museum are unsigned, however, this part was clearly written by Leach as indicated by the fact that he was Keeper of Zoology at the time and by the numerous references to Leach's list of family-group names by his contemporaries." I'm reluctant to add a notelist with this info. It is not uncommon to have "unsigned" articles. I've met them in 19th century book reviews. Sometimes there is a RS giving the authors name. I've seen square brackets used in references when the information isn't present on the title page - such as the author or the year of publication. Aa77zz (talk) 10:17, 17 July 2015 (UTC)
If Synopsis ... doesn't identify the authors then | last=Leach | first=William Elford | author-link=William Elford Leach should be removed from that citation. You might then change the note to read: "Attributed to Leach in Both 1994." I'm not at all sure that this is even important. Will knowing that Both thinks that Leach wrote "Eleventh Room" help readers find a copy of Synopsis ...?
Trappist the monk (talk) 12:13, 17 July 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────The conversation has moved a long way from User:SMcCandlish's request for a |note= parameter to allow a hidden editor to editors message, similar to |reason= in the cleanup templates. -- PBS (talk) 21:23, 30 July 2015 (UTC)

And it would actually serve the purpose Aa77zz has in mind, anyway. So, I renew the request. All fields I'm aware of, including physical sciences, social sciences, humanities, law, etc., that regularly cite sources do in fact have definitions of "primary source" and so on (even if they sometimes differ in their particulars), so the objection to my example isn't even valid. And it was just an example. There are any number of reasons to use such a parameter, e.g.:
  • |note=Titled "Blood of the Isles" in the UK printing.
  • |note=Paywall can be bypassed by request at URL here.
  • |note=Page 17 is missing from this Project Gutenberg scan, but is not part of the cited material.
  • |note=There is a newer edition, but the cited section has not changed, according to URL to changes list.
  • |note=This is a master's thesis, but was reviewed by Notable Researcher Here, and has been cited in 12 journal papers as of July 2015.
etc. There's no reason to put these in messy HTML comments that some editors are apt to delete on sight because they don't like HTML comments. And, really, no one's head will asplode if someone happens to include a more WP-jargon-specific note. They'll just shrug and move on. No one will see them but wikitext-editing users anyway.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:15, 30 July 2015 (UTC)
Are you hoping that the note will appear when a user mouses over the tag as with {{clarify-inline}} ? AngusWOOF (barksniff) 08:12, 22 August 2015 (UTC)
That might be useful, sure, but was not central to the nature of the request, which is about keeping these notes with (i.e., inside) the citations, so that nothing is put between them, etc.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:50, 12 September 2015 (UTC)

Italicization of websites in citations[edit]

If I may revive an old discussion (pardon me if there are other threads), I don't understand why we are italicizing websites (thru the |website= parameter) in citation templates. The argument seems to be that the alias of |website= is |work= (meaning you can use one or the other but not both) and obviously |work=, |journal=, etc. should be italicized. But the plain fact is that, per the MOS, while we italicize the names of publications, we (generally) do not do so for websites. So these parameters should not be interchangeable. For example: TMZ, Gawker, and other sites and urls should not be italicized. And while for content found in both a print publication and on its website I may cite The Advocate or Entertainment Weekly, if the actual url is being cited ( or it should not be italicized. This seems like a no-brainer.— TAnthonyTalk 21:16, 31 July 2015 (UTC)

"Generally" is the key word here, though. The vast majority of the time when a WP article is referring to a website, it's referring to it a business entity (or other kind of entity, e.g. a nonprofit, a free software coding group, a government project, whatever), or in a functional way, e.g. as a service or product. But when we cite it as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:53, 1 August 2015 (UTC)
As a journalist and editor, I need to disagree with the premise that when we cite, or the British Board of Film Classification or that these entities transmogrify into "a major published work, like a book, journal, magazine, film, etc."
No mainstream source italicizes, British Board of Film Classification,, or, for that matter, Rotten Tomatoes or Box Office Mojo, and none of these entities themselves italicize their names.
Italicizing dotcom names is not done anywhere else, and I'm afraid I can't find a valid reason that Wikipedia should create a non-traditional form of punctuation. Indeed, not even Wikipedia italicizes these entities in their respective articles. So I'd like to ask for what compelling reason we do so here. --Tenebrae (talk) 19:43, 29 August 2015 (UTC)
I agree. Entirely. ~ J. Johnson (JJ) (talk) 22:25, 30 August 2015 (UTC)
With what, though? Half of that wasn't cogent. British Board of Film Classification is a publisher, not a work of any kind, and what source italicizes itself (except as an incidental stylistic matter)? Looking at an entire bookshelf, only a tiny handful of covers have italic titles, and if you look at the actual title on the frontispiece, and at the top or bottom of each (or every other) page in the book, it is not italicized. This tells us nothing at all about whether WP would italicize the book title in a citation to it. No one made any such argument of "transmogrification". What I actually said was 'when we cite [a website] as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.' This argument has not actually been responded to at all. Instead, Tenebrae told us what some other publishers are doing, and made some unrelated observations. But WP's citation system is not that of any other site or publication, and no case has been made for why WP should treat the titles of all major works consistently (italicizing them by template) except when they're online publications.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:21, 30 August 2015 (UTC)
The problem is with how the website parameter is used. Since it's a synonym for work, it should only be used when a work is given as the value. "" is not a work. Peter coxhead (talk) 00:59, 31 August 2015 (UTC)
Exactly. Titles can be italicized, so we could have, but only because it is a title, not because it refers to a url. As to usage outside of WP: while some aspects of other styles are questionable, and often contradictory, it is still a good idea to consider them: 1) They often reflect a lot of hard-earned experience, and it would be shameful waste to insist on having to re-experience more than is useful. 2) Making WP more different than standard uses makes it harder to edit, and can even lead to subtle problems of reading. ~ J. Johnson (JJ) (talk) 18:06, 2 September 2015 (UTC)
As Peter coxhead rightly notes, "" is not a work or a title. "Rotten Tomatoes" or "Rotten" are not titles. "" is not a title. Though I certainly agree with J. Johnson (JJ) that no other reference source, nor newspapers or magazines, italicize dotcom names. There is no reason for Wikipedia to have a nonsensical deviation from every grammatical standard in this regard. --Tenebrae (talk) 21:40, 2 September 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I think you all are missing a couple key things here:

  1. the name of the website very rarely includes the domain space (.com, .org, etc) it's "Wikipedia" not ""
  2. citation styles are, generally, an exception to the MoS...the citation styles are intended to reflect common citation styles. Of the common citation styles, condsider how the following handle the names of websites:
  1. MLA uses italics (scroll down to the section "A page on a website")
  2. Chicago uses italics
  3. APA generally doesn't include the name of a website that's not scholarly website (eg. an online journal), but instead uses "Retrieved from [url]".
  4. ASA and Oxford style also does not include the name of the website, but rather the url
  5. Vancouver style (see page 5) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Wikipedia [internet].

While there are many exceptions, websites are generally a work/publication. Of the citation styles that include the name of the website, the two general style guides (MLA and Chicago) both italicize the name of the website, while the Vancouver style guide is generally reserved for the physical sciences. AHeneen (talk) 01:58, 3 September 2015 (UTC)

I don't think we need to research varied style guidelines. It's already established that websites/urls are generally not italicized at Wikipedia, and I'm not aware that we have separate formatting conventions for citations in this regard. The fact that cite templates equate "website" with "work" is the problem, because while one or the other should be required, they do not have the same established formatting style. Period. If I'm citing, I actually cite |work=Entertainment Weekly because the website is an obvious platform of that publication. But when you cite a website not affiliated with a conventional publication, yes it may be considered a "major published work" in the sense that it is a reliable source, but I don't see why it should be italicized when it does not meet the criteria for that formatting, and would not be italicized in other contexts at WP. I get SMcCandlish's basic argument, but it is not as if there a requirement somewhere that something has to be italicized in each citation, or that the source has to be italicized no matter what it is.— TAnthonyTalk 19:24, 3 September 2015 (UTC)
Okay, we need some clarification here, as it seems that "website" is being used in several different ways. Note that websites usually have a proper name, such as "Google", "The New York Times", "Entertainment Weekly", and "Rotten Tomatoes". Websites also have hostnames, such as (resp.) "", "", "", and "", which often (but not always) incorporate some form of the website's (or parent entity's) name. Hostnames are usually part of URLs (but see below), and as such have specific form and usage in the context of the Internet. As hostnames (URLs) they are not italicised, nor capitalized. What are italicized are titles, such as the names of books, periodicals, and (generally) works. A book title in the form of a hostname, such as, would be italicized, but only because it is a title.
It seems to me the real issue here is what constitutes a title; particularly, the name of a source. "The New York Times" and "Entertainment Week" are the names of both publications and their associated websites; "" and "" are not. (Entertainment Weekly could have named their website "", in which case it could be a title, but they did not.) Note that a further distinction can be made between a publisher and a publication (or work). E.g., "Amazon" (the website) might be the publisher of a reveiw found there, but is it a publication? ~ J. Johnson (JJ) (talk) 21:34, 3 September 2015 (UTC)
Amazon, or, indeed is not a publication. Neither is the publisher Simon & Schuster or Likewise, is not a publication, and citing, just for example, the number of stores that Sears owns would be to the website, and not
TAnthony is correct that if we're citing something created by the editorial department of Entertainment Weekly or The New York Times, we credit the publication rather than or, and these publications of course are italicized. In such cases, we use "work=" or "newspaper=" or "journal=". But neither Black & Decker nor is italicized. Same with The Home Depot or
The sensible solution, I believe, is to have the "website" field not italicize its contents. That way we're not putting in " " or " ". If we're citing an actual publication, we have three different fields we can use. --Tenebrae (talk) 22:48, 3 September 2015 (UTC)
Careful! You seem to be sliding back to confusing the name (as in a proper name) of a website with its hostname. E.g., "" is not the name of a website, so should not be put in anywhere. If you want to cite something from the Sears website (located at ""), then you cite that, not its hostname. If a website is a publication (e.g., "Rotten Tomatoes") then its name is properly italicized. ~ J. Johnson (JJ) (talk) 23:27, 3 September 2015 (UTC)
I don't think I am. And I think you are the only person on this thread making the argument that should be italicized. And, certainly, no one italicizes Rotten Tomatoes, not even Rotten Tomatoes, as it is not, by any definition, a publication.
What do the other editors think? Aside from one holdout, the consensus seems to be to have the "website" field be non-ital. Do we need to create a formal RfC, or have we reached consensus? --Tenebrae (talk)
If all sources are italicized, including sources that contain the cited work, then websites should be italicized for both stylistic consistency and semantic reasons (e.g. to distinguish a webpage or section from the hosting website). — Preceding unsigned comment added by (talk) 21:43, 5 September 2015 (UTC)
T: You don't seem to understand the distinction I am making, and have thereby misstated my view. Note: I believe we have no disagreement that (e.g.) titles can be (even should be) italicized. Also, that hostnames - such as found in URLs, and when used as hostnames - are NOT italicised. What you don't seem to understand is the use of a hostname in other contexts, such as in a title, or as the proper name of a website. Where I say that "" - note the capitalization, which is generally not done in urls - could be italicized it is very much dependent on it being used in the context of a title (like of a book) or proper name. That you think there is consensus to not italicize "website" is only because you have conflated "website" with "hostname". This is indicated by your earlier reference to "dotcom names". Strictly speaking, there no such things, except in the casual use of "" to refer to the website of some company XXXX. While such uses are in the fashion of a hostname, simply adding ".com" to some name does not make it a hostname, and does not exclude it from italicization. ~ J. Johnson (JJ) (talk) 22:05, 5 September 2015 (UTC)
I believe this is a valid point. The print product Grapes of Wrath, delivered by a printer, is not the book Grapes of Wrath delivered by a publisher. The digital product, delivered by a software developer, is different from the website delivered by an online publisher. In most cases what is cited as the source is the content, not the "delivery method/packaging", as it were. (talk) 14:43, 6 September 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I can only repeat my previous point. At present, |website= is simply a synonym of |work=, and so its value should be italicized, in line with the usual style for a work. It would be possible to give the two parameters a different meaning, but this would require a huge number of existing uses to be checked. Since "website" seems to be widely misunderstood, perhaps its use should be deprecated? Peter coxhead (talk) 19:28, 6 September 2015 (UTC)

I agree that "website" (as in "work") can be italicized; the problem seems to be where people mistakenly equate it with the url/hostname. Perhaps the documentation should be clearer about this. And perhaps a bot could flag all the instances where the value of |website= is a valid hostname. I am reluctant to deprecate |website= as I think it has a good use, but if the problem is too great then that is something to consider. ~ J. Johnson (JJ) (talk) 21:34, 6 September 2015 (UTC)
Editors were perplexed or confused with the term 'work'. In response to this feature request, |website= became an alias of |work=.
Trappist the monk (talk) 22:12, 6 September 2015 (UTC)
Suggesting that it is the concept of "website" as a "work" that is confusing. ~ J. Johnson (JJ) (talk) 22:36, 6 September 2015 (UTC)
So should not be italicized by should, is what you're saying? First, I'm not sure how often we would be citing a raw URL. Second, I don't see URLs italicized in any mainstream source. I'm not sure it's a positive thing for WIkipedia credibility to be adopting highly non-standard forms of citation. I'm not sure this is any different from citing authors by first name rather than last. That would be a highly non-standard way of citing, and would only make Wikipedia look eccentric. I'm thinking that italicizing URLs where virtually no one else does might do the same. --Tenebrae (talk) 17:03, 7 September 2015 (UTC)
No, I believe he's saying the reverse. is the name of a website, and as a major published work, it would be itaicized if included in a citation. On the oter hand, is the hostname and wouldn't be itaicized nor would we need to cite it. Imzadi 1979  17:59, 7 September 2015 (UTC)
Again, no one italicizes or,, etc., including those companies themselves. A URL / hostname / website does not suddenly change and become a book, magazine, newspaper or other "major published work." There's a reason we say things are "posted to the Web" and not "published to the Web". I think the fact no one in the mainstream italicizes these things should be a significant factor in this discussion. --Tenebrae (talk) 18:24, 8 September 2015 (UTC)
Exactly. Tenebrae, you started off with an incorrect understanding, so everything else that follows is invalid. If you start off the right way (and if you understand/accept that "website" ≠ hostname) I think you will find that we are largely in agreement. ~ J. Johnson (JJ) (talk) 20:40, 7 September 2015 (UTC)
I would like to think so, but a fundamental issue is that I believe the "website" parameter should not be italicized. Virtually no mainstream source italicizes either website names or URLs, which I take it is what you mean by "hostname". Italicizing websites/URLs is non-standard and does Wikipedia no good. --Tenebrae (talk) 21:52, 7 September 2015 (UTC)
You need to loosen your death-grasp on 'the "website" parameter should not be italicized'. Your implicit argument is that URLs (which includes hostnames) are not italicized. Look, we all get that part - everyone agrees that URLs should not be italicized. And that includes parts of a URL, such as hostnames. So it is a bit annoying that you keep asserting that. What you don't get is that this is irrelevant, because "website" does not equal URL/hostname. In particular, what you don't get is that a website - that is, a site on the World Wide Web with "web page" (HTML) content - can have a proper name. E.g.: the name of the website located at the WWW address "" is The New York Times - which is properly italicized. I repeat: "website" hostname. ~ J. Johnson (JJ) (talk) 21:58, 8 September 2015 (UTC)
With all respect, we're talking specifically about a field in "cite web" called "website". If we're citing The New York Times, we use "cite news or "cite newspaper" and enter the name of the paper in the field "work".
But I am confused, because it does sound as if we both agree that the name of a website is not italicized unless it's a newspaper, magazine, etc. ... in which case we wouldn't use "cite web." So ... am I wrong or do we agree that if we use "cite web" that the field "website" should not be italicized?--Tenebrae (talk) 22:29, 8 September 2015 (UTC)
Suppose one wanted to cite this web page. Becuase it isn't a newspaper, it isn't a journal, nor a book, nor anything but a web page, then I would cite it with {{cite web}} like this:
{{cite web |url= |title=Autism Spectrum Disorder (ASD) |website=[[Centers for Disease Control and Prevention]] |date=12 August 2015}}
"Autism Spectrum Disorder (ASD)". Centers for Disease Control and Prevention. 12 August 2015. 
Trappist the monk (talk) 23:04, 8 September 2015 (UTC)
Yet nowhere else is the Centers for Disease Control and Prevention italicized. Same with CNN or CBS News. They are not publications, and I'm not sure it makes sense for Wikipedia to transmogrify them and pretend that they are publications. CBS News is never italicized. CNN, Sears, BBC, Rotten Tomatoes — none of these are italicized. If virtually no one else in the mainstream is italicizing these entities, I'm not sure why Wikipedia would. It makes us look eccentric. Do you see my reasoning?--Tenebrae (talk) 23:54, 8 September 2015 (UTC)
Agreed, yet the name of the website at , if it were being cited, is "Michigan Highways" per the site's mastheads. If it were being cited, it should appear in italics as the name of a major work (as opposed to individual webpages within the site which would be minor works in quotation marks). There is no entity named "Michigan Highways" to be called a publisher. In some of those cases being mentioned above, what is being claimed as the name of a website is the publisher. Not all websites have names, but when they do, they should be in italics. If a website lacks a separate name, without resorting to creating "Official website of X", then |website= should be left blank. It's the same in comparing the news sites of WLUC-TV (Upper Michigan's Source) with that of WBUP-TV (no name). Imzadi 1979  00:48, 9 September 2015 (UTC)
cs1|2 take their styling cues from MLA, APA, CMOS, and, no doubt, stuff we've made up ourselves. There is this, which on pages 4 and 5, compares three style guides for citing online material:
"The Purdue OWL: Citation Chart" (PDF). Online Writing Lab. Purdue University. pp. 4–5. 
If one is to believe that, website names are rendered in italics in citations so my CDC citation above is correctly rendered.
Trappist the monk (talk) 00:51, 9 September 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Wikipedia is highly non-standard. Contributors are not vetted. Sources are not systematically checked. Citation styles are not enforced. Editors have widely varying expertise. Consumers cannot be assumed to be experts. The present problem should I think take this non-standard approach into account. If the source is a website (a collection of pages connected by hyperTEXT links and employing the digital equivalent of a markup language) then should be treated the same way CS1 treats other similar collections in other media. --— Preceding unsigned comment added by (talkcontribs) 19:43, 7 September 2015

Tenebrae, lets say I want to something from the New York State Department of Motor Vehicles website, something that only appears on the website, and is not in any book, pamphlet, etc. So I use cite web. And I use |website= = New York State DMV because that is the title of the web site. I know it is the title of the website because when I examine the html source for the home page of the web site I find <title>New York State DMV</title>. It should be italicised because that is the title of the work. Jc3s5h (talk) 23:06, 8 September 2015 (UTC)
Except no one other than we italicize it. New York State DMV is a proper-noun entity, but to suggest that all proper-noun entities be italicized — I dunno. I mean, what's the advantage of italicizing CBS News, Sears, New York State DMV, Yellowstone Park or United Airlines? Would readers not understand that " 'Traffic Laws in 2015'. New York State DMV." comes from the New York State DMV? I'm not sure what the advantage is of going with a deliberately eccentric format.--Tenebrae (talk) 23:58, 8 September 2015 (UTC)
At the NYS DMV website, the <title>New York State DMV</title> html officially declares to the world "the title of our website is New York State DMV. My Firefox browser responds to that declaration by putting that title in the tab associated with the web page. Style guides outside Wikipedia, mentioned in this discussion, explain that when a website has a title, that title is italicised, and we have decided to follow that guidance. It has nothing to do with whether "New York State DMV" is a proper noun phrase or not. Jc3s5h (talk) 14:15, 9 September 2015 (UTC)
And my Google Chrome does not italicize anything at Nor does the title of the page itself, in big blue letters. As for "we have decided," that's what this discussion is for, to discuss a change. Because having a style that virtually no one else uses just seems remarkably eccentric for no purpose. I don't believe any of us has ever seen, anywhere, "Author's Page". Simon & Schuster. No one would ever italicize the publisher Simon & Schuster. And to suggest that Rotten Tomatoes, which is not italicized in article text, be italicized in the footnote seems determinedly inconsistent. I think we're going to need wider input from all of Wikipedia.--Tenebrae (talk) 16:35, 9 September 2015 (UTC)
T: We are not saying that "that all proper-noun entities be italicized". In the context of citation publications ("works") are italicized, publishers are not. This is not "eccentric", this is a standard convention. So we italicize the titles of webpages (as Jc3s5h just explained), such as Sears or New York State DMV. We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. What kind of font is used on the website has nothing to do with it. (E.g., that the New York Times uses a serif title font has absolutely no bearing whatsoever on how a citation is formatted.)
Your persistent failure to understand this is starting to sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 01:13, 10 September 2015 (UTC)
No, it is the other way around, and I'll thank you stop casting aspersions. Pick up some books with footnotes and see whether web pages are italicized. See what AP Stylebook, the largest style guide in the English-speaking world, has to say. Nobody properly writes Rotten Tomatoes in regular font in article prose and then, inconsistently, puts it in italics in footnotes. Virtually no one in the world would italicize an organization like CBS News when citing something from the CBS News website. Organizations and institutions don't suddenly become titles because they have a web page.
Try and WP:HEAR this: The information we get from the New York State Department of Motor Vehicles comes, ultimately, under the auspices of the New York State Department of Motor Vehicles and not from the Web editor who inserted the information onto the web. Just as we cite The New York Times and Entertainment Weekly and not or, the information from those websites ultimately comes under the auspices of those organizations. And in the case of non-publications, those organizations' names are not italicized. Now stop making false accusations — I understand perfectly, as I've said. It's you who seem to have trouble grasping the concept. --Tenebrae (talk) 20:26, 10 September 2015 (UTC)
False accustations? Aspersions? Perhaps you should review the bit at WP:NPA that accusing someone of a personal attack can also be considered a personal attack.
My "accusation" is that you have repeatedly failed to understand what is being said here. E.g., you have just insisted that "no one in the world would italicize an organization like CBS News", and "those organizations' names are not italicized." But who has said we should? You have implied that I did (and again at the RfC (below). But that is false. I have no where said that names of organizations should be italicized. And you seem to have totally missed what I said in my last comment regarding organizations: We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. (Emphasis added for the hard of hearing.) You have mis-taken my position, and are arguing against something (italicization of organizational names) that nobody is arguing for. If you in fact do "understand perfectly" then why are you arguing a non-issue? I surmise that you have confused "website" with "publisher", just as you earlier confused it with "hostname". I submit that not understanding this despite repeated explanations does sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 22:38, 10 September 2015 (UTC)
Don't you dare accuse me of uncivil behavior, when you were the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning. And you compound your incivility by falsely claiming I was deliberately misunderstanding in order to obfuscate. How dare you. Look around this RfC — other people have no problem whatsoever understanding my point, so the fact that only you seem to have a problem understanding seems ironic, given your accusations. You say organizations should not be italicized, but you support leaving the "website" field italicized (01:19, 10 September 2015) because the very same words are not, in your view, that of organization anymore but of a page title. That seem contradictory. I've already explained that when we're using publications, we wouldn't be using "cite web" field but "cite news" etc., so why you keep bringing up publications is beyond me. --Tenebrae (talk) 23:23, 10 September 2015 (UTC)
Yes, I think I will dare to accuse you of uncivil behavior: of grotesquely misrepresenting my views, of attributing to me things I have clearly not said. Let's start with your statement that I was "the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning." Where? Give us a diff. That view is entirely your interpretation. As I said at the RfC, you it have backwards: I disagree with your position because your reasoning is faulty, not the other way around. As to your "deliberately misunderstanding in order to obfuscate: I asked why (if, as you stated, you "understand perfectly") you are arguing a non-issue. Again, the suggestion "in order to obfuscate" is entirely yours, not mine. But now that you have raised it, is that your answer to my question?
I think it is quite evident that your understanding of matters here (and reasoning) is faulty, but as all efforts (of others as well as mine) to explain this to you are unavailing it seems pointless to continue. If you can provide that diff, fine, but otherwise you should cease your flailing about. If anyone else thinks that I have misunderstood something, please bring it to my attention. ~ J. Johnson (JJ) (talk) 23:48, 11 September 2015 (UTC)

deprecate enumerator-in-the-middle parameters[edit]

See this archived discussion.

I propose to deprecate these parameters and standardize on the enumerator-at-the-end form. The numbers in the preference ratio column are caclulated from the values in the tables in the archived discussion: (terminal enumerator ÷ medial enumerator). Where the cells are blank the denominator is zero.

CS1 parameters to be deprecated
parameter extant replacement preference ratio
|authorn-last= |author-lastn= 2.51
|authorn-first= |author-firstn= 2.36
|authorn-link= |author-linkn=dagger 1.91
|authornlink= |authorlinkn= 1066.9
|authorn-mask= |author-maskn=dagger 101.43
|authornmask= |authormaskn= 23.23
|editorn-link= |editor-linkn=dagger 1.54
|editornlink= |editorlinkn= 7.24
|editorn-mask= |editor-maskn=dagger 3.17
|editornmask= |editormaskn= 16
|editorn-first= |editor-firstn= 1.42
|editorn-given= |editor-givenn=
|editorn-last= |editor-lastn= 1.58
|editorn-surname= |editor-surnamen=
|subjectn-link= |subject-linkn=dagger 47
|subjectnlink= |subjectlinkn=

dagger these parameters are the canonical form

Trappist the monk (talk) 13:26, 4 August 2015 (UTC)

Makes more conceptual sense the other way around. editor2-last implies the last name of editor #2, but editor-last2 implies the second surname of the editor.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:33, 5 August 2015 (UTC)
I agree with SMC on this point and think it would make more sense to keep the number in the middle than to have it out there hanging at the end. --Izno (talk) 17:47, 6 August 2015 (UTC)
The implication arises from the sense of the digit binding more tightly than the hyphen. (I.e., to "last" rather than "editor-last".) On the otherhand, when indexing a list of authors/editors I have found it most useful to have the index digit next to the equals sign, which gives the index better visibility, and provides a handy anchor for a regex. It's also easier to scan a list of authors/editors when the index is not buried inside the string. Which all might explain the medial location is not as widespread as the terminal form. I prefer the latter. ~ J. Johnson (JJ) (talk) 20:16, 7 August 2015 (UTC)
And yet others of us view the number as better in the middle. Comparing |editor2-last= and |editor-last2=, I parse the first as being the last name of the second editor and the second as the second last name of the (singular) editor. YMMV, and as far as I'm concerned, there's no harm in retaining both forms. Imzadi 1979  20:44, 7 August 2015 (UTC)
I am sympathetic to both points of view though my personal preference is terminal enumerator. I have added a column to the table that shows that overall, editors who have used these enumerated parameters generally prefer to use the terminal enumerator forms.
Trappist the monk (talk) 12:26, 8 August 2015 (UTC)
That's surely skewed by how they're documented, and likely also by some individuals, perhaps even with AWB scripts, manually changing them to your "preferred" version. I know I've occasionally seen diffs that include this change along with other "general cleanup".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:06, 9 August 2015 (UTC)
Of course it's possible that the documentation has influenced one style choice over the other and its possible that editors change extant parameters to suit their own preferences. I don't know that AWB, as part of its general fixes, makes this kind of change; I haven't noticed changes of that kind. If you are suggesting that I have written an AWB script that changes enumerator-in-the-middle to enumerator-at-the-end, then you would be wrong.
Trappist the monk (talk) 12:35, 9 August 2015 (UTC)
  • Strongly oppose deprecation. These are still listed as the primary parameter names for {{citation}} and we should not diverge the CS1 and CS2 templates so far from each other as to deprecate one template's parameters in the other. Additionally, these are used by software for creating citation templates (I know, because I have written such software myself). What purpose is served by this change? What does it make better? It seems to me to be purely a foolish consistency. Finally, I note that once again Trappist is proposing major changes that relate to {{citation}} without even bothering to mention the discussion on Template talk:Citation. Trappist, you have been told over and over again: don't do that. —David Eppstein (talk) 17:14, 8 August 2015 (UTC)
    I don't understand why you think this affects {{citation}}... when it doesn't. --Izno (talk) 21:09, 8 August 2015 (UTC)
This change affects {{citation}} because {{citation}}, despite being cs2, is rendered by Module:Citation/CS1.
Trappist the monk (talk) 21:52, 8 August 2015 (UTC)
Yes, and also because it is desirable to continue the current state of affairs in which we can change CS1 to CS2 or vice versa just by changing the template name. Not that changing the citation style of an article is frequent nor usually a good idea. But finding articles that mix the two styles is common enough, and changing them to use only one is usually a (minor) improvement. Thanks to recent improvements it's also possible to do this using a parameter but changing the actual template name seems less likely to encourage more inconsistency later. —David Eppstein (talk) 06:27, 9 August 2015 (UTC)
Standardizing on terminal enumerators will not prevent editors from changing CS1 to CS2 or vice versa just by changing the template name. Standardizing on lowercase parameter names did not change that nor did standardizing on the hyphen as a separator in parameter names change that.
Trappist the monk (talk) 12:35, 9 August 2015 (UTC)
Citation Style 2 is distinguished from Citation Style 1 by its element separator (comma vs period), by lowercase static text (retrieved..., archived from ..., written at ..., etc. vs Retrieved..., Archived from ..., Written at ..., etc.), by terminal punctuation (none vs period), and cs2 automatically sets |ref=harv, cs1 doesn't. cs2 is not distinguished from cs1 by some subset of the commonly shared parameters.
The primary documentation for both cs1 and cs2 is {{csdoc}}. I grant that {{csdoc}} has a cs1 bias, so does Help:CS1 errors though I did a bit of work on that recently that removed some of the bias.
Of the sixteen parameters in the above table, these seven are found in Template:Citation/doc outside of the {{csdoc}} content:
Are we to believe then that the other nine are not or should not be supported by {{citation}}?
Yep, it is just for consistency whether you think it foolish or not. This choice is no different from the choice we made to standardize on parameter names that use hyphens instead of underscores or spaces; and standardize on lowercase instead of capitalized or camel-case. Choosing one flavor or the other is merely for consistency.
Trappist the monk (talk) 21:52, 8 August 2015 (UTC)
Yes, I think it is foolish to suddenly kill off the primary documented parameter choices of the sister CS2 style, that our templates have been handling perfectly well, for the sake of no reason at all but neatness. The costs of this proposal involve breaking software or forcing the developers of the software to make parallel changes, breaking the mental model of who knows how many editors (as an example, I am still months after you made this change unable to remember to use contribution-url= in place of url= for the url of book chapters, and this is causing actual citations to be formatted wrong), forcing edits to who knows how many live citations after the red error messages start showing up, etc. The benefit of the proposal is appeasing the OCD of one single software developer who wants all the ducks to be perfectly lined up in a precise row. It's a bad idea. —David Eppstein (talk) 02:52, 9 August 2015 (UTC)
Agreed (other than the assumption of mental issues), and as I said earlier, the proposed "norms" don't make conceptual sense: |author2-last= implies the surname of the second author, while |author-last2= implies the second surname of the (singular) author. I.e., there are multiple, independent reasons not to deprecate this, and at least one to actually prefer the form Trappist wants to deprecate.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:00, 9 August 2015 (UTC)
Deprecation does not suddenly kill off anything.
Trappist the monk (talk) 12:35, 9 August 2015 (UTC)
Must be why I still have an ant problem. This bug spray says "Deprecates on Contact!"  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:41, 10 August 2015 (UTC)
:-} ~ J. Johnson (JJ) (talk) 23:38, 11 August 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────While all these are valid and could exist in the same article

|authorn-last= vs. |lastn=
|editorn-first= vs. |firstn=

they are also inconsistent. Just as parameter case was decided to be lower-case, this could also be decided in similar fashion. (talk) 19:34, 9 September 2015 (UTC)

ISBN error category[edit]

So that it is consistent with the naming convention of other identifier error categories, and while it is mostly empty, I've changed the ISBN error category name from Category:Pages with ISBN errors‎ to Category:CS1 errors: ISBN in Module:Citation/CS1/Configuration/sandbox.

After the next module update, I think that the old category Pages with ISBN errors ‎can go away.

Trappist the monk (talk) 16:34, 22 August 2015 (UTC)

Support. It helps distinguish it from Category:Articles with invalid ISBNs as well. – Jonesey95 (talk) 10:14, 23 August 2015 (UTC)

This will break some ISBN fixing tools such as WPCleaner. -- Magioladitis (talk) 12:39, 19 September 2015 (UTC)

If Category:Pages with ISBN errors‎ is hard coded into the tool, I have no sympathy. Wikipedia:WPCleaner/Configuration/Help#isbn_errors_categories suggests that ISBN categories are kept in a configuration file somewhere though that isn't at all clear from the documentation. If this latter is true, then I see no reason not to proceed.
Trappist the monk (talk) 13:39, 19 September 2015 (UTC)
Magioladitis, can you provide some details? If we are breaking something by standardizing this category name, we are willing to help fix it or test the tool after the change. It looks like we may need to change the second category name at User:NicoV/WikiCleanerConfiguration#ISBN; will that fix the problem? – Jonesey95 (talk) 13:46, 19 September 2015 (UTC)


For a very long time editors have been asking for |translator= in some form or other. For a very long time the answer has been |others=. While I have been hacking away at the |coauthors= problem in Category:Pages containing cite templates with deprecated parameters I have become somewhat sympathetic to that request. So, here it is, these new parameters:


And an example:

{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url= |page=745 |last=[[Hesiod]] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}}
Hesiod (1810). "Works and Days". English Translations: From Ancient and Modern Poems 2. Translated by Cooke, Thomas. N. Blandford. p. 745. 

Relatively little is new as the translator-name-list makes use of existing author- and editor-name-list code. Currently, there is no support for et al. and no support for Vancouver styling.

Right now, |others= is appended to |translator= and the two rendered in the same place as |others=. This may not be the correct placement. There have been suggestions that |translator= belongs with |author=. What say you? Also, keep? Discard? What about punctuation? Static text?

Trappist the monk (talk) 17:36, 25 August 2015 (UTC)

This is a good addition to the module. It will be welcomed by many editors. Here's how it looks with |others=:
{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url= |page=745 |last=[[Hesiod]] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}
Hesiod (1810). "Works and Days". English Translations: From Ancient and Modern Poems 2. Translated by Cooke, Thomas. Illustrated by Jane Doe. N. Blandford. p. 745. 
That looks right to me. As for the fixed text "Translated by", I like it. Our guidance in the documentation for CS1 templates has contained only this recommended form since October 2012, as far as I can tell. – Jonesey95 (talk) 18:17, 25 August 2015 (UTC)
The ball on naming of parameters with numbers hasn't been resolved yet, so I would expect to see the number-in-the-middle variants also. --Izno (talk) 21:40, 25 August 2015 (UTC)
I don't think consistency requires us to introduce number-in-the-middle variants of new parameters, just because some of our old and entrenched parameters already have them. I'd prefer to see only one version of the new parameters rather than trying to duplicate all the variants of the old parameters. —David Eppstein (talk) 17:29, 27 August 2015 (UTC)


  • Hesiod (1810). "Works and Days". In Smith, Edward. English Translations: From Ancient and Modern Poems 2. Translated by Cooke, Thomas. Illustrated by Jane Doe. N. Blandford. p. 745. 

I wondered how the above would work in with an editor. Are the translator and the illustrator meant to be volume wide and not related to the chapter?

Translator is one option but another is "Reviewed by" which is used by the ODNB, another is "Illustrated by". So rather than having a specific type why not have other parameters with a "other string" it could default to ("translated by") but be set to another word such as "Reviewed" or "Illustrated" etc. or set to "none" if other is a mixture of more than one type (translated by some, and illustrated by others), and instead of |translator-firstn= have |other-firstn= etc. -- PBS (talk) 16:52, 27 August 2015 (UTC)

Good, as long as these also work:
Discussions above (e.g. #deprecate enumerator-in-the-middle parameters) do not indicate a consensus in favor of this role-lastn order, with multiple editors objecting to it as counter-intuitive.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:16, 29 August 2015 (UTC)
As also noted in the relevant discussion, retaining both
is inconsistent and could also be counterintuitive. Per your suggestion then, |lastn=, |firstn= should be deprecated? (talk) 14:52, 12 September 2015 (UTC)

Double period bug (again)[edit]

I know this was reported before, but this bug is still alive and annoying.

Steps to replicate: give the publisher parameter a value that ends with a period.

Result: Two periods after the publisher. Which is wrong. Mature software such as BibTeX and Citation Style Language can deal with this.

Real-life example: Look for “Digitalcourage e.V.” on de:Digitale_Gesellschaft_(Schweiz). --Thüringer ☼ (talk) 08:08, 7 September 2015 (UTC)

Here is the citation from de:Digitale_Gesellschaft_(Schweiz):
{{Cite web |title=Überwachung in und aus der Schweiz: Das volle Programm |url= |author=Digitale Gesellschaft Schweiz |publisher=Digitalcourage e.V. |date=2015-08-18 |accessdate=2015-09-07 }}
Digitale Gesellschaft Schweiz (2015-08-18). "Überwachung in und aus der Schweiz: Das volle Programm". Digitalcourage e.V. Retrieved 2015-09-07. 
De:wp does not use the en:wp Module:Citation/CS1 to render citation templates. The de:wp, {{cite web}} is a template that is written using wiki markup.
Probably best to raise the issue at de:Vorlage Diskussion:Cite web.
Trappist the monk (talk) 11:09, 7 September 2015 (UTC)

RfC closure challenge: Template talk:Cite doi#RfC: Should Template:cite doi cease creating a separate subpage for each DOI?[edit]

Please take part in the discussion at Wikipedia:Administrators' noticeboard#RfC closure challenge: Template talk:Cite doi#RfC: Should Template:cite doi cease creating a separate subpage for each DOI? Curly Turkey 🍁 ¡gobble! 05:12, 8 September 2015 (UTC)

RFCs on citation templates[edit]

There are ongoing discussions (mostly parallel but since each one is argued as separate consensus, separate) regarding the use of (A) Template:Cite wdl (which creates subpages for a wrapper of cite web) here; (B) Template:Cite pmid (which is a wrapper for cite journal either in-article or via pages at Category:Cite pmid templates) here; and (C) another RFC at Template:Cite doi (a cite journal wrapper with almost 60k pages at Category:Cite doi templates) here. There are unique wrinkles to each one but basically all three discussions concern whether to deprecate these templates or not. Please comment there if everyone could. -- Ricky81682 (talk) 06:22, 8 September 2015 (UTC)

Request for Comments: Italics or Non-Italics in "website" field[edit]

In the template "cite web", which is used when "cite news", "cite newspaper" or "cite journal" is not, should the "website" field italicize the name of websites, in the manner of books or periodicals?

  • Oppose No mainstream source italicizes British Board of Film Classification, U.S. State Department, Sears, Rotten Tomatoes, New York State Department of Motor Vehicles or other entities. Indeed, none of these entities themselves italicize their names on their own websites. These aren't publications, and we have templates like "cite newspaper" that we use for publications. It seems eccentric to use a citation format virtually no one else uses, and it also seems inconsistent that a movie article, for example, would mention Rotten Tomatoes in text but call it Rotten Tomatoes in a footnote. --Tenebrae (talk) 16:50, 9 September 2015 (UTC)
"No mainstream source italicizes [examples]". Wrong. The most commonly-used style guides MLA ([1], scroll down to the section "A page on a website") and the Chicago Manual of Style ([2]) both use italics for all websites. ASA style (generally used in sociology field) and Oxford style only include the url, not the website name. APA, generally used in the field of psychology, doesn't include the name of a website unless it corresponds to a scholarly journal (otherwise, it uses "Retrieved from [url]"). Vancouver style (see page 5, generally used in the bio-sciences) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Wikipedia [internet]. Since the AP style guide is intended for new stories, it does not cover footnote/bibliographic citations, since new stories use in-text attribution. "AP doesn't use italics in news stories. That includes newspaper names and magazine references. No italics." ([3]). So BOTH of the major style guides (MLA & Chicago) that are used for general writing italicize the name of a website, while one (Oxford) does not include the name of a website. Of the style guides that are widely used only in a limited field, only one style guide for citations (Vancouver) does not italicize the names of websites and two generally do not include the names of the website (ASA, APA). AHeneen (talk) 22:19, 11 September 2015 (UTC)
  • The MLA is an inapplicable example. It says to include the additional information or otherwise modified information, like domain names [e.g. .com or .net]" (brackets in original source) and to even do so if it's a publication name. It's well-established that Wikipedia cites The New York Times and not, and even editors who who want to keep the "website" field italicized agree Wikipedia does not and should not cite "" or italicize names with ".com" in the formal name, like So MLA has no bearing on the disucssion here. --Tenebrae (talk) 22:35, 11 September 2015 (UTC)
  • Additionally, it is not, in fact, wrong to say "No mainstream source italicizes [examples]". I'm referring to the fact that, Sears, CBS News, etc. are not italicized terms in general prose use. Yes, you can find a style guide that italicizes website names in footnotes. And you can find style guides that do not, so that part's a wash. The fact is that unlike periodicals, entities such as, Sears, CBS News, etc. are not normally italicized in prose text, and there's no reason to have a non-periodical in regular font in prose and italicized i footnote. One can always find someone doing things eccentrically — I believe The New York Times, maddeningly, says 1950's rather than 1950s when it means the entire decade. But just because The New York Times or Chicago Manual of Style does something eccentrically that we have to be eccentric as well. We can use common sense. --Tenebrae (talk) 22:42, 11 September 2015 (UTC)
MLA does not say to use the domain name, except in limited circumstances where the publisher uses the domain name in the website name. The full quote, which you conveniently did not include, is: "Remember that some Print publications have Web publications with slightly different names. They may, for example, include the additional information or otherwise modified information, like domain names [e.g. .com or .net]." It's not common, but some publishers include the domain name, "[name] online", or do something similar with the name of their website. It is absolutely not eccentric to italicize all websites. It is eccentric to have a policy that is inconsistent and determines which sites to italicize based on users' opinions. For example, you give the example of CBS News, but it is a major news site that is little different than a newspaper or TV news program, which is considered a work by any sensible person, except that it is on the internet. Websites like the New York Times have content on their websites that are not published in print. Your comments drive home the reason why we need a simple, common-sense policy about italics...there should not be excessive dispute about which websites merit italics and which do not. Common sense is to italicize all websites, rather than have a policy that is open to differing opinions among users. AHeneen (talk) 03:24, 12 September 2015 (UTC)
Um, most of those examples are not |work= (i.e. |website=) values but |publisher=. Of the entire list only Rotten Tomatoes is a |work=, and, yes, various sources do, and various style guides would, recommend italicizing it (same goes for CBS News as a news source rather than as an intellectual property business entity. I'm not sure what relevance that external style guides are thought to have here, and that's all I'll say on that matter for now.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:22, 12 September 2015 (UTC)
  • Comment: MOS:TITLE#Italics says, "Website titles may or may not be italicized depending on the type of site and what kind of content it features. Online magazines, newspapers, and news sites with original content should generally be italicized ( or The Huffington Post). Online encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online). Other types of websites should be decided on a case-by-case basis." I think if the website title is italicized in its Wikipedia article, it should be italicized in the citation template as well (and probably should use the {{cite news}} template as well). We do have a challenge here when it comes to websites that are not identical to news sources. Rotten Tomatoes and Box Office Mojo are more like database sources, but they do have parts of the website where there are write-ups that are basically like news articles. (Rotten Tomatoes has a "Critics Consensus" news column, and Box Office Mojo summarizes box office forecasts and actual performances in such articles.) I suppose if websites like these are not primarily news-type outlets, we do not italicize them? Erik II (talk | contrib) (ping me) 17:03, 9 September 2015 (UTC)
  • Italicise value of website parameter. This is supported in Chicago Manual of Style 16th ed. p. 754 which I quote:

16. Ellis, Rhian, J. Robert Lennon, and Ed Skoog. Ward Six (blog).

Jc3s5h (talk) 17:12, 9 September 2015 (UTC)
And other style guides do not. Some do, some don't. Cherrypicking just one that supports your arguments isn't helpful. --Tenebrae (talk) 22:46, 11 September 2015 (UTC)
  • Italicize and on a case-by-case, editors can omit the name of a website that matches its publishing entity and give just the |publisher= instead. So to reply to Tenebrae, |publisher=British Board of Film Classification would be 100% appropriate and correct, and the rendered formatting for the publisher would not be in italics. Imzadi 1979  17:30, 9 September 2015 (UTC)
  • Italicise per Jc3s5h, we should take our lead from mainstream style guides. According to Jc3s5h, Chicago Manual of Style italicises them. Likewise the 19th edition of The Bluebook (legal citation) requires them to be in small caps, which is also how it treats books and magazines (italics being largely reserved for case names). By contrast however, AP style is to use standard type but title-style capitalization, so its not uniform. ~ ONUnicorn(Talk|Contribs)problem solving 17:31, 9 September 2015 (UTC)
  • Leave default alone but add named parameters to give editors control of how this is displayed, e.g. |title-format=, |publisher-format=, |website-format=, etc. with values that correspond to "quoted," "italic," and "plain". davidwr/(talk)/(contribs) 18:35, 9 September 2015 (UTC)
  • Leave un-italicized - There have been many discussions at the MOS about whether or not to italicize website names. Our current guidelines are a sensible compromise. By leaving them un-italicized by default, we allow the editor to choose (and thus to properly conform to the MOS). I would probably support making them italic by default if either the MOS is changed or a new parameter is added to allow overriding the default italicization. Kaldari (talk) 22:41, 9 September 2015 (UTC)
  • Yes, italicize, as it is standard practices to italicize the names of publications. Tenebrae's opposition is faulty because he has persistently misunderstood (see the extended discussion above) the intended scope of the |website= parameter, first conflating it with hostnames (URLs), now with publishers. ~ J. Johnson (JJ) (talk) 01:19, 10 September 2015 (UTC)
No. Just because you disagree with me does not make my position faulty. I am not misunderstanding anything. You are claiming that corporations and government agencies suddenly transmogrify by magic into publications. I've tried to be politic here, but if you're going to get personal and suggest that anyone who disagrees with you must have "faulty" reasoning is insulting and plain wrong. Virtually no mainstream source italicizes Sears, Home Depot, Simon & Schuster or the New York State Department of Motor Vehicles. We don't italicize Rotten Tomatoes in article prose, yet you want a field that italicizes it in footnotes. That's ridiculous. --Tenebrae (talk) 01:30, 10 September 2015 (UTC)
Again you have it backwards. Your position is faulty because of your imprecise thinking, quite independently of what ever I think about it (or you). You certainly misstate my position: I have not "claim[ed] that corporations and government agencies suddenly transmogrify by magic into publications", and I will thank you to stop such misrepresentation. If you are going to take disagreement as a form of insult perhaps you should refrain from requesting comments. ~ J. Johnson (JJ) (talk) 22:47, 10 September 2015 (UTC)
  • Comment It depends on usage. Sometimes, a web site is semantically almost the same as a publication. Other times it is semantically almost the same as a publisher (no italics). At other times, it is semantically more akin to a bookstore or library (again, no italics). We need a clean, somewhat consistent way for editors to cite the website by name and give it the proper italics or lack of italics depending on the semantics. Here's an example: If you cite a copy of a pre-1923-century National Geographic Magazine article hosted at Project Gutenberg, you probably don't want |website=Project Gutenberg to show up in Italics. On the other hand, if you cite the same article hosted at, you probably may very well want |website=National Geographic Magazine italicized. Note - for those counting noses I already made my main comment above - see "Leave default alone." davidwr/(talk)/(contribs) 02:08, 10 September 2015 (UTC)
I understand the comment about the bookstore/library, but it's is important to note that your example is bad. The "via" parameter in Citation Style 1 templates is intended for this purpose. Your example should use Template:Cite journal with |via=Project Gutenberg. AHeneen (talk) 22:19, 11 September 2015 (UTC)
  • Oppose forcing italicization for reasons explained by Davidwr above. Granting users the right to understand context, and italicize properly on their own should be what we do. As noted, there are many cases where the name of the website itself should not be italicized. And many cases where it should. Having a single "one size fits all" solution is not good, as having a template that forces a certain style which may not be universal would do. Yes, we should italicize appropriately. But is it really that hard for users to type four apostrophes when needed? --Jayron32 02:30, 10 September 2015 (UTC)
  • Thanks for the endorsement, but the "two apostrophes" solution may not be the best solution, in that computer programs that parse this template for meaning may be confused. See my suggestion above ("Leave default alone") for having a different parameter to govern the formatting. davidwr/(talk)/(contribs) 02:57, 10 September 2015 (UTC)
    • Actually, I think both of you are on the right track. Normally, editors add the two apostrophes before and after a word or phrase to italicize it. So while that can work in reverse — ading two apostrophes before and after a word or phrase in an italicized field to un-italicize it — that's counterintuitive. So wouldn't it make sense to have the website field non-ital, and that way editor who want to italicize something there can do so the normal way. --Tenebrae (talk) 23:28, 10 September 2015 (UTC)
    • Add to address davidwr's astute point, I think if we were citing National Geographic we would use "cite news" or "cite journal", so the question of having a publication in the "cite web" website field shouldn't really be an issue. --Tenebrae (talk) 23:31, 10 September 2015 (UTC)
The template's we're discussing are Citation Style 1 templates, so all usage of the templates should be the same style. If an article is using a different style (eg. MLA, Vancouver, APA), then these templates shouldn't be used. AHeneen (talk) 22:19, 11 September 2015 (UTC)
  • Leave default/italicized. As has been stated in the discussion above, the title of the website is used, not the domain name or the URL. The website is generally not the publisher; e.g., Deadline Hollywood, TheWrap, Indiewire, Vox (website), Rotten Tomatoes, and Metacritic are not publishers (editors have added them to the publisher= field). Moreover, other style guides, such as the Chicago Manual of Style, italicize the name of the online source. Some editors either confuse the name of the website as the publisher or just use the publisher parameter so the online source isn't italicized. Template:Cite_web#Publisher says, "Do not use the publisher parameter for the name of a work (e.g. a book, encyclopedia, newspaper, magazine, journal, website). ... Omit where the publisher's name is substantially the same as the name of the work (for example, The New York Times Co. publishes The New York Times newspaper, so there is no reason to name the publisher)". WP:ITALICS says, "The medium of publication or presentation is not a factor"; whether or not the online source/website is also a print publication is irrelevant; it's the name of a work - which has produced the content cited - therefore it should be italicized. I'd say one should use the work= parameter to cite print publication and online sources/websites that are also print publications; use website= parameter for strictly online sources. Lapadite (talk) 02:20, 11 September 2015 (UTC)
Indeed, the "publisher" field is being used for, say, Rotten Tomatoes since the "website" field italicizes it, and Rotten Tomatoes simply isn't italicized. Same with Metacritic and Box Office Mojo, these all being commonly used in WP:FILM articles.
Template:Cite_web#Publisher says, as you note, "Do not use the publisher parameter for the name of a work (e.g. a book, encyclopedia, newspaper, magazine, journal, website)." Yet having that last word in this list of examples, "website", does not mean websites are automatically italicized, because Wikipedia:Manual of Style/Titles#Major works states, "Website titles may or may not be italicized [emphasis mine] depending on the type of site and what kind of content it features." It goes on to gives examples of what should be italicized: "Online magazines, newspapers, and news sites with original content should generally be italicized ( or The Huffington Post). Online encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online)." And then it specifically notes, "Other types of websites should be decided on a case-by-case basis."
Case-by-case basis. So websites are not to be automatically italicized. It would seem to make sense, then, that the "website" field not automatically italicize, since things that need to be italicized can still be italicized in the regular manner if the field doesn't do it automatically. --Tenebrae (talk) 03:33, 11 September 2015 (UTC)
I'm repeating one of Tenebrae's comments above for emphasis: editors specifically use the "publisher" parameter for website titles because the "website" parameter italicizes by default, and every commonly used website title I've seen is not italicized by our own MOS guidelines. As I note below, the very examples Lapadite77 cites in his argument above to keep the italics are not italicized in their own articles. The number of website names established as "major works" that should be italicized is relatively small compared to those that are not. — TAnthonyTalk 19:54, 11 September 2015 (UTC)
  • Oppose default italics, as is currently in place. See #Italicization of websites in citations, above. Most website names and/or urls are not italicized per current MOS convention, so this should not be the default. A general discussion about outside style guides is irrelevant because the current Wikipedia style guides establish that website names are not italicized like "publications" are, as in the given examples of TheWrap, Indiewire and Rotten Tomatoes. If our articles about these websites establish and confirm this style, citations should not diverge from it. In the case of items like The Huffington Post, the publication should be cited as |work=The Huffington Post rather than | anyway, but even if the url is preferred to be shown, it should be and not — TAnthonyTalk 17:17, 11 September 2015 (UTC)
The "url" form is NOT preferred. Unless, of course, it has been adopted as the name of an organization, publication, or (horrors) website. ~ J. Johnson (JJ) (talk) 23:57, 11 September 2015 (UTC)
  • Italics by default As I mentioned in the previous discussion above ("Italicization of websites in citations") and in the response to the first comment by Tenebrae, the two most widely-used style guides (MLA and the Chicago Manual of Style) both use italics for the names of all websites. A citation style should be as uniform as possible, not filled with vague criteria. How will we determine which websites merit italics and which do not? This can especially be a point of disagreement in a featured article/list nomination. The problem is that there is an increasing amount of websites that function much like a publication such as a book or magazine, without a print equivalent, and in such cases the website is essentially a work similar to a book or magazine. There is too much opinion involved in distinguishing a website that should be italicized and one that shouldn't. Adding a parameter to not italicize something would not fix this problem. Furthermore, I think the implications of a change haven't been appreciated by the other commenters. The citation style 1 templates are used millions of times on Wikipedia (there are almost 5 million articles on en-wp, most use CS1 templates, and the articles with no CS1 citation templates are balanced by articles with 20..50...100...200+ CS1 templates). Changing the default behavior of these templates to not italicize websites and forcing users to manually add italics would be a monumental task to implement and not very easy to do with a bot. Using italics for all website names is simply the easiest way to format citations, eliminates disputes over which websites should and should not be italicized, and matches the two most widely-used style guidelines. AHeneen (talk) 22:19, 11 September 2015 (UTC)
Here's the thing, if these are the (external) style guidelines Wikipedia should be following, why are the majority of website titles which are the subject of articles currently not italicized? And where is the discussion that initiated the idea that the website parameter be italicized? The fact that the template is in use by a trillion articles means nothing if the format was not set with an adequate discussion, or for that matter, if it is now being challenged. — TAnthonyTalk 00:40, 12 September 2015 (UTC)
In 2009, there was a discussion about italicizing everything in the work parameter, including websites. At the time, neither the MOS/Titles nor MOS/Text formatting pages addressed whether italics should be applied to websites or not. The titles page simply said (emphasis mine) "Italic type (text like this) is generally used for the following categories of titles:" followed by a list of things. AHeneen (talk) 03:24, 12 September 2015 (UTC)
  • Support italics. When we cite, in |website= (which is {{Cite web}}'s |work= parameter), something like we're citing it as the title of a publication, not referring to it as an entity, so it is properly italicized as the title of major work, like a journal, book, or feature film. When I say "Jane works at", I'm referring to a business entity. When the site has a conventional title, without the .com or whatever, we use that: {{Cite web|website=[[Slate (magazine)|Slate]]|...}}, not {{Cite web|website=[[Slate (magazine)|]]|...}}. When the site has no such non-domain-name title, the domain name is the title, and this quite common for online publications, as in our example. In running prose, write: "According to a article ...", but " the new CEO of '". When the website/work and publisher are the same or essentially the same, omit the publisher, exactly as we do for newspapers: {{Cite web|news=[[The New York Times]]|...}}, not {{Cite web|news=[[The New York Times]]|publisher=[[The New York Times Company]]|...}}. This is quite common with online publications, where the business entity does not really exist separately from the website for our intents and purposes. This is usually apparent in the copyright notice; if the indicia for says "Copyright 2015" or "Copyright 2015 Snorkel Weasels LLC", you can usually safely omit the publisher parameter.

    This would necessarily invalidate much of the oppose reasoning above relating to stuff like "British Board of Film Classification, U.S. State Department, Sears ... New York State Department of Motor Vehicles or other entities"; those are all |publisher= (as "entities" indicates), and their corresponding |website= a.k.a. |work= parameters are, respectively:,,, and This is important, because most such entities have multiple publications, online and offline. "U.S. State Department" is absolutely not a work title. It's typical, not just common, for universities to have dozens of websites on a departmental level ( that are often separately written, maintained, and funded, with separate purposes and audiences, and with their own editorial processes. It's also common for major governmental departments/ministries to do likewise (e.g. is also a US State Dept. website). And it's fairly common for business entities to have multiple consumer-facing websites (usually divisional and/or world-regional), plus a separate type of site for non-consumer information about the company. And so on. Even Sears has multiple websites (I know, because it gives me a headache to remember which one to log into with what password to pay my bill); we might cite any of them (even the Sears bill-paying one, e.g. for what their privacy policy states vs. what some journalist wrote about it in a security scandal article or whatever). For any news publisher with multiple publications and different editorial boards, such that the paper and online editions may differ radically in content, it is safest to cite the online edition by its domain name (without "www." unless DNS resolving fails without it) as the work (or the online one's separate title if there is one, e.g. Wired News vs. Wired the magazine, which are from the same publisher) rather than the name of the paper publication. I tend to do this to be safe anyway, and cite, e.g. not The Guardian, because I don't know their online vs. paper editorial process.

    The easiest way to keep this straight in one's head is probably to stop using |website= and always use |work=, to remind oneself that the parameter is about a publication. And if ever in doubt, remind yourself that Apple Records is a publisher and The Magical Mystery Tour is a work. It never ceases to amaze me how frequently people confuse |publisher= with |work= and its aliases. There's no reason for it. We all understand the difference between Marvel Comics, the business entity, and Ultimate Fantastic Four, the comic book series, don't we? Apply the same reasoning to websites. Oxford University Press is a publisher, not a book.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:22, 12 September 2015 (UTC)

    Self-correction: Salon has gone back to using Salon instead of as the title, and the business name has changed, to Salon Media Group, so it's essentially the same as Wired News as an example; I've changed the Salon example to a hypothetical one.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:46, 14 September 2015 (UTC)

I, for one, appreciate anyone willing to do a detailed analysis, although a non-succinct wall of text such as this, as we've seen in countless previous discussions all over Wikipedia, can sometimes be used to overwhelm a discussion. I'm not saying that's the intent here, and in fact, I see things I agree with and things I disagree with in the text above, which suggests it's an attempt at a fair analysis (though the lack of paragraph breaks makes it all a little hard to follow). It also sounds as if while he says "Support Italics", he actually doesn't support them in the website field: "Oxford University Press is a publisher, not a book." Absolutely. So it sounds as if he would not italicize "Oxford University Press".
I absolutely agree with him, and I think we all do, that when dealing with something that's unquestionably a publication, like The New York Times, "The easiest way to keep this straight in one's head is probably to stop using |website= and always use |work=, to remind oneself that the parameter is about a publication."
But as we're dealing with the field "website" here, we still need to reach consensus on that. I think the simplest way to address this is to note that Wikipedia:Manual of Style/Titles#Major works states, "Website titles may or may not be italicized [emphasis mine] depending on the type of site and what kind of content it features." Since we have a a choice of whether to italicize or not, I'm not sure why we're forcing italics in the field rather than not italicizing and letting editor italicize when appropriate. --Tenebrae (talk) 20:26, 13 September 2015 (UTC)
Thank you, Mac. Tenebrae, you say you "absolutely agree with him", even though you also say there are things you with which disagree. I think what you agree with is that the title of works are italicized. What you object to is the italicization of certain cases, such hostnames (from a URL) and names of organizations (including publishers). But that is not a matter of disagreement, because no one here accepts such italicization. Your more particular objection – to "forcing italics" on the content of |website= when the content is such as we all agree should not italicized – overlooks a very essential point: if the content is not the name of the work then it should not be in "website" in the first place. The problem there is not the italicization, but misuse of the parameter.
You have cited the MOS that "Website titles may or may not be italicized ...". Please note that that section gives no examples of a website whose name ought not to be italicized. If you have any such examples it might be useful to mention them. ~ J. Johnson (JJ) (talk) 22:58, 13 September 2015 (UTC)
What I said was that I absolutely agreed with him on the specific point that we italicize something that is "unquestionably a publication, like The New York Times. You were deliberately misrepresenting my stance with your opening sentence above in a false attempt at making me appear contradictory. You additionally put words in my mouth. I can state my position; I don't need you to misstate it.
And, again, you refuse to listen to examples I've made previously: Rotten Tomatoes and Metacritic, to name just two websites, are websites. They are not italicized. No one italicizes them in prose, not even RT and MC themselves, and they don't suddenly become The New York Times in a footnote. And I shouldn't have to give examples when the MOS itself says there are website titles that may not be italicized.
And since the MOS says "Website titles may or may not be italicized ...", I'm not sure why we're forcing titles in the "website" field to italicize.--Tenebrae (talk) 15:10, 15 September 2015 (UTC)
Jeez, will you ever learn to pay attention? My "opening sentence above" in no way misrepresents what you said. I quite understand that your "absolute agreement" is not universal (i.e., applies to a specific point); I have not said otherwise. The only problem here is where you assumed that I was asserting your agreement as applying universally, and then further assumed I that was acting in bad-faith. If you thought I had misstated something you could have asked for clarification, but no, you just start assuming bad motives. This is a clear violation of WP:AGF. And you're so wrapped up in this that it seems you have totally missed why your "forced italics" is a false issue.
As to why we italicize titles in |website=: because by definition they are titles of works, which are italicized by standard citation convention.
I will address your other points below. ~ J. Johnson (JJ) (talk) 22:47, 15 September 2015 (UTC)
(edit conflict)Tenebrae, thanks ever so much for coming to the conclusion that maybe my faith was good after all, because you happen to agree with some of what I said (or think you do). Some of us value precision over convenience. I'm getting a bit tired of being berated for being in the former camp. I don't see the point in grousing about a few paragraphs of text on a site that consists of about 99.5% paragraphs of text. How can paragraph breaks make text hard to follow? The very purpose of them is that they make text easier to follow; that's why they were introduced so many centuries ago.

Anyway, of course we would not italicize Oxford University Press. "Oxford University Press" does not go in the website field, it goes in the publisher field, just like Apple Records or Universal Studios, or Marvel Comics, etc. It appears to me that you skimmed what I wrote, concluded what you wanted to, and are now putting words in my mouth that are the exact opposite of what I said, e.g. 'It also sounds as if while he says "Support Italics", he actually doesn't support them in the website field', which is bassackwards. No separate consensus needs to be reached on |website=; it's the same thing as |work=, just as |journal= is in {{Cite journal}}. I just use |work= in all of them, and it works fine.

The poorly-worded guideline quote is trying awkwardly to get at the "according to a article" vs. "according to's privacy policy" distinction drawn earlier, and to separate sites that intrinsically are publications (like Slate or xkcd) from those that are services/applications/shops (Gmail, Yandex, That's about use in running prose; in a citation, if we use |website= a.k.a. |work=, we're citing something as a published work, whatever it's other possible uses.

Contrived example where the publisher shares essentially the same name as the publication, and it's name is (not Billiards):

But all of this is really hair-splitting; I'm skeptical that enough editors could care that we need to get into this in any more detail. What's important is that citations be usable to find sources accurately, and secondarily that they be consistent enough to be usable in this way. We don't need micro-formatting exceptions that don't help in that regard.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:46, 14 September 2015 (UTC)
    • And I ask, for what reason? Because the MOS says "Website titles may or may not be italicized ...". Since that's the case, why are we forcing titles in the "website" field to italicize? On its face, that goes against the MOS. --Tenebrae (talk) 15:13, 15 September 2015 (UTC)
  • WP:MOS does not say "Website titles may or may not be italicized". — Preceding unsigned comment added by Jc3s5h (talkcontribs) 16:01, 15 September 2015‎
The MOS does say "may or may not be italicized." (Second paragraph from the bottom of the seciton.) However, what Tenebrae seems to have missed is that this is not permissive, at the whim of individual editors. It depends "on the type of site and what kind of content it features. But while the MOS provides several examples that should be italicized, it does not provide any contra-examples. It says only: "Other types of websites should be decided on a case-by-case basis." In a previous comment (above) I suggested to Tenebrae that if he had any useful examples it might be useful to mention them. He said (15:10, 15 Sep) that he "shouldn't have to give examples when the MOS itself says there are website titles that may not be italicized." Which is partly true — and partly false. What is false is the assertion that "the MOS itself says there are website titles that may not be italicized." The MOS makes no such assertion that such titles exist, and certainly not that "may not be italicized" (in the sense of not permitting). It only allows the possibility of such cases. And so far we have not seen any clear instances of "website titles" as titles of works - which is how |website= is defined - which should not be italicized. Lacking any such instances the argument for non-italics seems distinctly hypothetical. ~ J. Johnson (JJ) (talk) 22:55, 15 September 2015 (UTC)
      • I'm rather tired of J. Johnson (JJ) not listening to the examples I've constantly given. For the fourth or fifth time: Rotten Tomatoes, Box Office Mojo and Metacritic are website names that are not italicized.
      • This editor also apparently has never encountered the concept of "corollary": If MOS says, "Website titles may or may not be italicized", then the inherent corollary is that some website titles are not italicized. That's basic use of the English language. --Tenebrae (talk) 17:36, 17 September 2015 (UTC)
And I am rather tired of your constant misrepresentations, failure to understand, and AGF failure. But perhaps you are ready to listen this time?
As I have been trying to explain to you for some time: the problem with these hypothetical italicizations that you object to – that everyone agrees would be improper – is not with the handling of |website=, but with the improper use of |website=. This parameter is defined at Template:Cite_web#Publisher as an alias for |work=, which contains the name of certain kinds of publications. Note: places, hosts, organizations, and publishers are NOT works. The problems you object to arise solely from your vague, ill-defined, and over-inclusive concept of "website names". In regard of Rotten Tomatoes (and your other examples): is that a publication (work), such as regularly publishes articles? Or is it a place, where a whole lot of diverse and constantly changing content can be found? If it is a place it does not belong in |website=, and there is no issue with italicization. Your entire tendentious complaint here rests entirely on such incorrect usage.
BTW, your understanding of corollary is faulty. The implication that there might exist a "website title" that 1) is properly used in |website= as the title of a work, and 2) should not be italicized, in no way establishes whether such an instance actually does exist. The examples you have offered are worthless because of their work/non-work ambiguity. ~ J. Johnson (JJ) (talk) 22:20, 17 September 2015 (UTC)

Checking back in on this messy debate, and J. Johnson I'm trying to follow your logic. Are you saying that Rotten Tomatoes is a place/publisher and not a website? Then what is |website= used for? My original point in all this is that it makes no sense to me why |work= and |website= are interchangeable when in many (most?) instances they are not publications. This is the issue Tenebrae and I seem to be stuck on: The Rotten Tomatoes article asserts that it is a website, but "Rotten Tomatoes" is not italicized. Either:

1. This is improper application of the MOS, and similar website titles (Box Office Mojo, Metacritic, etc) should be italicized in their articles, or
2. The |website= should not italicize by default, or
3. (By your logic above) The Rotten Tomatoes article should call it an "online publisher" rather than a website.

I see the distinction you are making, that we should be putting sites like Rotten Tomatoes in |publisher=, but that is counterintuitive to most editors, and |website= is mostly used for urls and website titles.— TAnthonyTalk 22:40, 17 September 2015 (UTC) '

No. What I am saying is that if the Rotten Tomatoes website is deemed to be a place/publisher/etc. – and I leave that determination to whoever wants to take it on – then it is not a work, and therefore does not belong in |website=. The question is not whether whether RT is a website (that is, an Internet location containing "web" content), but whether that website is a kind of publication (i.e., a work), or something else. (And incidentally: RT is a website, and the publisher is probably Flixter, Inc.)
Whether the articles for all Category:Film review websites should be italicized in the same manner as done for newspapers is a MOS issue, and would depend on whether they are newspaper-like works. If they are not italicized, then presumably they are not "works". In that case they should not be used in |work=or its aliases.
It is a standard citation convention, and established here by default, that the titles of works are italicized. The whole problem here seems to come to some editors thinking |website= encompasses all websites, including those that are not "works". (It certainly should not be used for urls.) If this is too difficult for general understanding then perhaps this parameter should be removed. ~ J. Johnson (JJ) (talk) 00:18, 18 September 2015 (UTC)
On removing "website" altogether: You bring up a good point. As an editor, I just assumed that the website= parameter was for the web site itself, but that it should only be used if adding the web site was helpful. I did not, do not, and probably will not assume that "website=" should only be used when the website is a "work," unless/until the documentation is updated to reflect this. If the consensus here is that |website= should only be used when the web site is a "work" and that it should not be used when it is a "place" or other "non-work descriptor" then all related documentation should be updated to make this point crystal-clear. Ditto if that's not the current consensus but the consensus evolves to that in the future. davidwr/(talk)/(contribs) 04:19, 18 September 2015 (UTC)
I believe all related documentation should be updated to make it crystal clear that |website= is an alias of |work= and should be used for the title of the website. There are two situations where the website (or work) parameters should not be used. One is if the website does not have a title (the html title tag might have a value, but that value might actually be nonsense, or the name of a company, and there is no large text near the top of the page that serves as a title). The other situation is where |title= is also the title of the "home page" where the information is found. A large website with many subpages can be a work, whether it has been assigned a title or not, and whether it corresponds to a traditional paper or film work or not. If it hasn't been assigned a title, I would just set |title= and leave it at that. Jc3s5h (talk) 12:04, 18 September 2015 (UTC)
It seems funny to me to try and force/enforce a counterintuitive usage of a parameter, especially when novice editors may not read the documentation in depth or at all, or may use the wizard tools. J. Johnson has made a valid argument (that I agree with) to consider certain websites to be "publishers" if they are not considered "works", but I think that distinction will be lost on the common editor, documentation or not. Of course, I am saying this from my belief that most of the websites I have seen cited as such (those without associated magazines or newspapers etc.) seem to fall into the "publisher" category.— TAnthonyTalk 15:29, 18 September 2015 (UTC)
To do a little fine-tuning: not necessarily publisher, as many of these sites are aggregators, more in the nature of a big wall where individuals hang their posters. The key point is not a "work". The term "website" gives no clue that it is meant to be used in such a carefully distinguished manner. (Cf. "website-as-a-work".) Given this basic weakness, a similar weakness in understanding the nature of a "work", existing mis-usage, and a general disdain for RTFD (especially when a term and its intended use seems "obvious"), I rather doubt that documentation will have much effect.
At this point I am thinking that |website= could be deprecated, with better documentation of where to use |work=. (Those editors that understand it can use it, and the others won't be mislead.) But this is getting beyond the scope of this RfC. ~ J. Johnson (JJ) (talk) 22:12, 18 September 2015 (UTC)
I'm going to try to stay positive here and say that I agree with J. Johnson (JJ) that this particular template field, "website", be deprecated. It does seems to have such an inherent ambiguity that it creates confusion and definitional issues. Since it has to be replaced with something, would it be "work = | publisher = ", as we have for other templates? --Tenebrae (talk) 20:34, 20 September 2015 (UTC)
Thank you. I don't see that |website=, as an alias for |work=, requires any replacement. Where the content of a "website" (in the broader usage) can be taken as a "work" that parameter is still available. I think that not using |work= when it might be applicable is a lesser (and addressable) problem than the misuse of |website=. However, all this is getting into a follow-up discussion. For the purpose of this RfC I think there is consensus that the contents of the |website= parameter, in the scope of its proper and restricted usage, should be italicized. ~ J. Johnson (JJ) (talk) 20:55, 20 September 2015 (UTC)
Oh, for goodness' sakes: No. Italicizing it goes directly against the MOS, which says that website names can be either italicized or not — and so forcing italics, rather than leaving the field open to italicize or not, is contrary to MOS. --Tenebrae (talk) 21:29, 20 September 2015 (UTC)
Wrong. As previously explained (22:55, 15 Sep), and recapped below. ~ J. Johnson (JJ) (talk) 22:30, 21 September 2015 (UTC)
Jeeminy Christmas, no. The MOS absolutely says website names can be either italicized or not. And I even agree with you that it's not subject to individual editors whims. That why I say below that Rotten Tomatoes is not italicized as per WP:FILM consensus and even a citation template at WikiProject:Film. Forcing the field to italicize when the MOS itself says website names such as this example don't have to be italicized goes completely against the MOS. --Tenebrae (talk) 22:50, 21 September 2015 (UTC)
  • Italicize as |work= does. I didn't even know |website= existed until stumbling upon it yesterday, and I still can honestly say I (and perhaps others) do not know when to use |website= over |work=. Assume that they are used interchangeably, and have the format be consistent between them. No prejudice if they are both not italicized, as long as they are consistent.—Bagumba (talk) 22:44, 15 September 2015 (UTC)
  • Summary: I think most (sigh) everyone's understanding is now adequate for the following summary. As the contents of the |work= parameter are titles of "works", which by standard convention are properly italicized, the contents of |website=, being an alias of |work=, and intended for those cases where the contents of a website are deemed to be "works", are also properly italicized. The objections raised here about improper italicization arise from improper use of the parameter for the names of non-works, such as hostnames or names of publishers. This misuse appears to arise from non-recognition of the non-obvious restriction of "website" to a form of title of a work. ~ J. Johnson (JJ) (talk) 20:59, 20 September 2015 (UTC)
  • That Is a False Summary: I take exception to a participant in the discussion, as opposed to a disinterested third party, giving any summary at all, let alone one that favors his personal opinion. Italicizing the "website" field goes directly against the MOS, which says that website names can be either italicized or not — and so forcing italics, rather than leaving the field open to italicize or not, is contrary to MOS. If a field is called "website", then editors naturally assume that any website name goes there. Rotten Tomatoes is a website. But Rotten Tomatoes, as per WP:FILM consensus and even a citation template there, is not italicized. This is just one example of why "website" should not force italics. --Tenebrae (talk) 21:29, 20 September 2015 (UTC)
    The template at the top of all MOS pages begins (emphasis added): "This guideline is a part of the English Wikipedia's Manual of Style. Use common sense in applying it; it will have occasional exceptions." The subject of this discussion can be considered a reasonable exception. AHeneen (talk) 17:14, 21 September 2015 (UTC)
    A "regular" or "expected" exception is an oxymoron. --Izno (talk) 19:10, 21 September 2015 (UTC)
    No. A well-defined exception is a normal part of any process or system description. – Jonesey95 (talk) 19:13, 21 September 2015 (UTC)
    I'm a little confused. By saying an exceptions can be made, are we saying we want to italicize things that should not be italicized? That doesn't really make sense. Rotten Tomatoes and Metacritic, for example, are websites that aren't italicized. So I'm not sure what AHeneen is saying.--Tenebrae (talk) 21:32, 21 September 2015 (UTC)
I have qualified my prior comment with most, as one editor keeps going around and around and around like a broken record. Tenebrae: your objections are getting tiresome, even tendentious. To your objection to certain names being italicized when they get stuffed into the 'website' parameter, my simple suggestion is this (are you paying attention?): don't stuff those names into the 'website' parameter. At a slightly higher level you object that "[i]f a field is called "website", then editors naturally assume that any website name goes there." While that is an understandable assumption, it remains a fact that 'website=' is an alias of 'work=', and thus restricted to the latter's use for titles of works, and thus italicized.
Your assertion that all this "goes directly against the MOS" is flat-out wrong, because (as previously explained) you keep forgetting the bit about "depending on the type of site and what kind of content it features." Your Rotten Tomatoes example is rotten because you have not shown that it is the title of a work. Failing that, it does not belong in 'website', and thus is irrelevant. ~ J. Johnson (JJ) (talk) 22:49, 21 September 2015 (UTC)
No. And stop with the name-calling. The only thing tendentious is your suggesting that Rotten Tomatoes is not a website. That's just remarkable. As for " 'website=' is an alias of 'work=' ", that's what this entire RfC is about: whether it's proper for website= to be an alias of work=. And since the MOS says website names aren't required to be italicized, it's improper for it to be an alias of work= and force italicization in the field. If anything, it should be an alias of publisher=, so that if someone wants something italicized in that field, they can always add two quote marks to the beginning and end of the term. What the heavy burden or big deal is to do that, I have no idea. --Tenebrae (talk) 22:57, 21 September 2015 (UTC)
There you go again. Flat-out wrong. Not only have I not suggested (as you state) that " Rotten Tomatoes is not a website", it seems you completely missed where I said that it is a website. (Which statement is likely to confuse you even further, as you quite evidently do not understand the distinction between 1) name of an Internet location containing web content, and 2) name of a work.) As to "what this entire RfC is about", I will quote your very own words when you opened this disucssion: "... should the "website" field italicize the name of websites, in the manner of books or periodicals?". That |website= is an alias of |work= is a given. If you want to discuss whether this is proper open another discussion. ~ J. Johnson (JJ) (talk) 00:08, 22 September 2015 (UTC)
Your double-talk is such that I'm beginning to think you're pranking me and seeing how far you can go before I realize you're pulling my leg.. You said: "Your Rotten Tomatoes example is rotten because you have not shown that it is the title of a work." The field we are talking about is called "website". Whether RT is a "work" or not is irrelevant. The field is not called "work" — it's called "website." So, yes, if you're saying it doesn't belong in the "website" field, you're saying it's not a website. That's obviously ridiculous.
RE: "That |website= is an alias of |work= is a given." It is nothing of the sort. Nothing is a "given". This entire RfC is about whether or not the "website" field should be italicized, and your bringing in irrelevant, extraneous points to create a smokescreen because you like the field to be italicized is just remarkable.
You refuse to address a point I keep bringing up: The MOS says website names can be either italicized or not. So forcing the "website" field to italicize goes completely against the MOS. --Tenebrae (talk) 02:43, 22 September 2015 (UTC)
Wrong again. See below. ~ J. Johnson (JJ) (talk) 20:54, 23 September 2015 (UTC)
What are you, five? I've seen below. You continue to refuse to address the fact that the MOS says website names can be either italicized or not. So forcing the "website" field to italicize goes completely against the MOS. --Tenebrae (talk) 22:21, 23 September 2015 (UTC)
What are you, blind? The MOS does not say "website names can be either italicized or not." (Note the closing full-stop.) It says: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." (Emphasis added.) What part of the qualifying "depends on ..." do you not understand? Oh, sorry, I forgot: none of it. Never mind. ~ J. Johnson (JJ) (talk) 22:41, 23 September 2015 (UTC)
OK, I've tried my best to keep a civil tongue, but your baiting me with insults has just pushed me over the line. I've been a professional writer and editor for over 35 years, and the garbled, verbose, unclear nature of your writing as seen here would never be acceptable in any mainstream periodical. I'm tired of what I now believe is your deliberate dissembling and your ignoring my addressing of your points. I have twice now addressed "depending on the type of site and what kind of content it features" — on Sept. 11 and again today — so just stop your smoke-screening and your arguments that come down to WP:ILIKEIT. I will say it again since you appear slow: "Case-by-case basis" means editors reach consensus whether to italicize or not. So forcing italics is wrong because it's simpler and more intuitive to italicize something that needs italics than to de-italicize something that doesn't. Your ridiculous argument only results in things being italicized that should not be. --Tenebrae (talk) 23:20, 23 September 2015 (UTC)
You consider characterizations like "double-talk", "ridiculous", "what are you, five?", "smoke-screen", and "the garbled, verbose, unclear nature of your writing" (all from you) to be civil?? Not the slightest bit provocative? Attributing your failure to understand to "deliberate dissembling" on my part is not civil (and also violates WP:AGF), nor does it encourage any continuance of a civil discussion. Whether we continune this discussion is another matter. ~ J. Johnson (JJ) (talk) 22:01, 24 September 2015 (UTC)
This discussion seems to be getting a bit personal, which is not helpful. It's simply a fact that at present, |website= is an alias of |work=. Of course, this could be changed and they could be made two separate parameters with different behaviours. But, and it's a big "but", first thousands of uses would have to be checked to see which meaning was intended, since there's no guarantee that editors have used the parameters with different meanings. I can only say that since I know they are aliases, I've not been consistent in which I used. So to this extent, J. Johnson is right to say that the current aliasing is a given. If separate parameters were agreed, then one could indeed be italicized and one not, but this is a different issue. Peter coxhead (talk) 08:14, 22 September 2015 (UTC)
I appreciate your trying to cool the waters. I do have to say I've never heard of any RfC where someone contends we'd have to check "thousands of uses" before we make a change. This RfC is no different than any other, where a consensus is reached among the editors discussing it, and to throw in some clearly undoable obstacle in order to retain the status quo is a bit questionable. You also seem to be saying that "since the website field is italicized currently, then it's a given that it's italicized". That seems a circular argument at best: It's not inherently italicized, as if anointed by God. That's what we're here to decide. And I'm still getting no one to address a point I keep bringing up: If the MOS says website names can either be italicized or not, why should the field force website names to be italicized? The website Rotten Tomatoes, for example, is not italicized, per WP:FILM consensus. Why would we force it to be? --Tenebrae (talk) 13:04, 22 September 2015 (UTC)
Tenebrae, I have addressed the point you keep bringing up, multiple times even. (As well as several other points you keep bringing up.) In your obsession with that bit at MOS:TITLE#Major works you keep quoting only part of it. So here is the whole of it, with the part you keep leaving off emphasized: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." The "or may not be italicized" is not a general permission for individual discretion, it is contingent (depends) on a certain distinction of site and content. There is no "forcing" of italics as use of 'website=' is entirely voluntary. But as you are resistant to understanding any of this further explanation seems futile. Calling my efforts "double talk" only underscores your lack of understanding.
The bottom line here is that a majority of respondents favor italicization. As to keeping "Rotten Tomatoes" (or any other name) non-italic in a citation, there is a very simple solution for you: do not stuff it into |website=. That the established and documented use of this parameter does not conform to your notion of what the general term "website" should cover: that is not what you requested comments on. ~ J. Johnson (JJ) (talk) 21:01, 23 September 2015 (UTC)
  • Sigh*. Anyone who has spent enough time on Wikipedia knows very well that in RfC discussions we don't count "votes" but try to achieve consensus. One third of the respondents here oppose forcing italics in the "website" field. That's a a large enough opposition that we're far from consensus.
And you are I hope inadvertently and not purposefully inaccurate when you claim I haven't addressed "depending on the type of site and what kind of content it features". At 03:33, 11 September 2015, I used those very words: "Wikipedia:Manual of Style/Titles#Major works states, 'Website titles may or may not be italicized [emphasis mine] depending on the type of site and what kind of content it features.' ... it specifically notes, 'Other types of websites should be decided on a case-by-case basis.'" And you can read my analysis of this in that Sept. 11 post, so don't you dare make up false claims and accusations, and dissemble like that.
"Case-by-case basis" means that editors reach consensus whether to italicize or not. You refuse to understand that simple point.
Nor the point that it's simpler and more intuitive to italicize something that needs italics than to de-italicize something that doesn't. You refuse to address the fact MOS says website names can be either italicized or not and so forcing the "website" field to italicize goes against the MOS. Rather, you point to something else in the MOS that I addressed 12 full days ago and claim I didn't address it. Well, I address it once again here. --Tenebrae (talk) 22:36, 23 September 2015 (UTC)
And it is completely disingenuous to claim that most editors will not put a website into the "website" field. Why you want to encourage editors to wrongly italicize (and this is just one example of many) Rotten Tomatoes is incomprehensible to me. --Tenebrae (talk) 22:37, 23 September 2015 (UTC)
Your assertion that I "want to encourage editors to wrongly italicize" is completely false, and I will yet again request that you refrain from misrepresenting my positions. I say that what should not be italicized should not go into the 'website=' parameter. Your argument is that certain names should go into 'website=', and then you are unhappy because it got italicized.
You should note that lack of consensus is not grounds for changing established usage. Where you don't want something italicized, don't use 'website='. No one is forcing you to use it, so all your jabbering about "forcing" of italics is just a red herring. The rest of your comments I reject categorically. ~ J. Johnson (JJ) (talk) 22:11, 24 September 2015 (UTC)
I'm not misrepresenting anything. The field's name is "website". Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are websites. If you're suggesting that the average editor doesn't know what "website" means and won't naturally put websites in the "website" field ... wow!!
And how can anyone say that putting something in the current "website" field won't force italics? You've said yourself the field "website=" is an alias of "work=", which automatically italicizes whatever's in the field. "Automatically italicizing" means the same thing as "forcing". Good gracious.
Maybe a consensus solution is this: We change the name of the field from "website" to the extant "work." Boom. No more confusion, no more chance of someone putting a website into "website=" that shouldn't be italicized. --Tenebrae (talk) 22:35, 28 September 2015 (UTC)
In your comment just above (22:37, 23 Sep) you imputed that I "want to encourage editors to wrongly italicize". That is false, and absolutely contrary to everything I have said here; it constitutes a misrepresentation of my views. You have done this several times before. That you do not listen, or perhaps lack the intellectual competency to understand, does not excuse your bad manners, and interferes with any progress in this discussion. And I have had enough. I demand an apology for this and other misrepresentations — Preceding unsigned comment added by J. Johnson (talkcontribs) 02:47, 30 September 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Only someone who knows he has no valid argument is going to start insulting another person, since that's a form of misdirection, and you've been smokescreening for most of this discussion. You're clearly so angry that rather than read thoroughly and think straight, you evidently only skim what I've been writing here. I've repeated myself blue in the face, and you still act as if you don't understand. That's just remarkable behavior. And it's typical of someone such as this that that you won't consider or even acknowledge a compromise suggestion but instead insist on some scorched-ground approach. I'm appalled and sad.

Once again: The field's name is "website". Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are websites. The average editor who knows the definition of "website" will put websites in the "website" field. Are you following? Now, the "website" field forces italics. I know you understand that. Italicizing websites that should not be italicized goes against the MOS, which allows for italics or non-italics depending on the website. I don't know how to explain it any more simply.

The solutions are simple: 1) make the website field not italicize automatically, so that editors can add the double-quote italic code in order to italicize, or 2) change the name of the field to something other than "website". That way, websites like Rotten Tomatoes and Grand Comics Database can go in a non-italicized field. There is a middle ground unless you simply want to have things your way without reaching reasonable compromise like an adult. --Tenebrae (talk) 03:43, 30 September 2015 (UTC)

That is a very impressive piece of "smokescreening" you have just done, dancing all around and accusing me of the very things you are doing without addressing the fact that you have misrepresented me. Would someone else please step in and explain this to him?
For the record, I quite understand what you are saying. As before (22:11, 24 Sep): I say that what should not be italicized should not go into the 'website=' parameter. Your argument is that certain names should go into 'website=', and then you are unhappy because it got italicized. And as I have also previously said, no one is forcing you to use "website=", so you have no basis for complain when you voluntarily elect to mis-use it. The problem here is that you don't understand (hear) any of this (or the MOS), insisting on your own idiosyncratic interpretations. As long as that condition continues there is no basis for further discussion. ~ J. Johnson (JJ) (talk) 21:56, 30 September 2015 (UTC)
No, again it is you who appears to be purposefully misunderstanding. Once again — and no one else is saying they have trouble following this — the field's name is "website". Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are websites. The average editor who knows the definition of "website" will put websites in the "website" field.
I never said anyone "is forcing you to use 'website='", so that's simply a false, straw-man argument. You know very well that editors know the definition of "website", and would have no reason not to put websites into a field named "website". You continue to refuse to address this simple fact. You don't want to discuss it further, fine. The fact you refuse to address this elementary point speaks volumes. --Tenebrae (talk) 20:05, 6 October 2015 (UTC)
Except that I never said that you said anyone "is forcing you to use 'website='." That is what I said, except that you left off the bit about "no one is forcing you...", which constitutes a blatant misquotation of my statement in the immediately preceeding comment. Your denial of having said what no one attributes to you is the very strawman argument that you then attribute to me. As to your "editors know the definition of "website"": that assertion has been questioned, and that issue addressed. Did you forget? ~ J. Johnson (JJ) (talk) 00:12, 7 October 2015 (UTC)

Add citationstyle= parameter to CS1 templates[edit]

All the talk about having |website= in italics or not got me thinking:

What if the cs1 templates like {{cite web}} etc. had a |citationstyle= parameter, with values of LSA, Vancouver, etc.

When these values are used, the CS1 templates would become "wrapper" templates to the existing Vancouver, LSA, etc. templates.

This would be a lot of work, but assuming the work got done, do you think the parameter would get a lot of use? davidwr/(talk)/(contribs) 02:47, 11 September 2015 (UTC)

We have a start to this in |mode= and |name-list-format=, but you're right, it would take some work. – Jonesey95 (talk) 02:58, 11 September 2015 (UTC)
Your idea has been in the back of my mind since the introduction of |mode= or there abouts. At about the same time there was a kerfuffle regarding small caps and LSA if I recall correctly. I have thought that we can extend |mode= to support clearly defined styles. Step 1 after we decide that this is something that we should be doing is to set down just exactly what it is that defines a particular style and then and only then hack the code to make it a reality.
Trappist the monk (talk) 03:04, 11 September 2015 (UTC)
I strongly favour this idea. It would render the maintenance of citations easier if there are fewer citation template types. Also, fixing inconsistent citation styles or changing them when there is consensus to do so would be much easier.Jo-Jo Eumerus (talk, contributions) 08:54, 12 September 2015 (UTC)
Ideally, in my view, |mode= would be used with the {{citation}} template, which would make life much simpler for users – no need to choose which of the cite templates to use. However, I suspect this is difficult or impossible in all cases because there isn't always enough information to pick the right formatting. The |website= discussion above exemplifies one issue: having it as an alias of |work= loses information. Peter coxhead (talk) 10:00, 12 September 2015 (UTC)
I strongly oppose having multiple citation styles at all, much less supporting external ones (i.e. other than CS1 and CS2, and we should retire CS2). But if we're stuck with it, something like this is the way to do it, and we should get rid of external-citation-style-specific templates for Vancouver, etc., and just have it all done by the Lua module on the fly. So consider this "support until we come to our senses and have a single citation style like, well, every other publication in the world".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:31, 12 September 2015 (UTC)
If we are to retire one of CS1 or CS2, I would strongly prefer it to be CS1. All. Those. Periods. Make. It. Very. Difficult. To. Read. And. Really. What's. The. Point. Of. Them? —David Eppstein (talk) 20:28, 15 September 2015 (UTC)
Not sure how I feel about this being in {{cite xxx}} / {{citation}}, but I'd definitely support this feature if it could be shoved in {{reflist}}. Headbomb {talk / contribs / physics / books} 13:27, 12 September 2015 (UTC)
Reflist is only capable controlling styling of what's inside it, but that requires a strong classing dicsipline inside the templates (so same problem as above). It has absolutely no way of controling content of these templates. -- [[User:Edokter]] {{talk}} 09:06, 13 September 2015 (UTC)

<cite> has been fixed, so we can now use it for entire citation[edit]

Yay! <cite>...</cite> has now been fixed to stop forcing italicization, so we can now use it instead of <span>...</span> to wrap the entire citation. This, BTW, has been interesting in that WP as a "developer user" of HTML & CSS has actually gotten W3C to fix things. Their own advice with regard to this element was self-contradictory between documents, and I got them to normalize to the current HTML5 description of the element. Details at Mediawiki talk:Common.css#cite-updates (anchor to update reporting in middle of larger thread about this issue over the last month or two).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:54, 12 September 2015 (UTC)

Done in the sandbox; compare live:
<cite class="citation book">''Title''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
to sandbox:
<cite class="citation book">''Title''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
Trappist the monk (talk) 13:47, 12 September 2015 (UTC)
Two comments:
  1. @Pigsonthewing:, I think this may be the incorrect way to handle the microformat. Have a look, if indeed that first span is intended as a microformat.
  2. The intent was for the <cite> to wrap the entire citation, whereas the sandbox is only wrapping the title. --Izno (talk) 19:30, 12 September 2015 (UTC)
Re: #1: why do you think it's wrong?
Re: #2: I made a minimal example because that is easier to read. Here is one that is more complex:
<cite class="citation web">[ "Autism Spectrum Disorder (ASD)"]. ''[[Centers for Disease Control and Prevention]]''. 12 August 2015.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
Trappist the monk (talk) 19:41, 12 September 2015 (UTC)

The class=citation book looked like a microformat pair of classes to me, rather than what is their more likely use of just plain ol' CSS classes.

Didn't realize the COinS was dumped at the end of the citation. I haven't looked too closely at the HTML behind the template system before.... --Izno (talk) 00:08, 13 September 2015 (UTC)

Looks OK to me. Strictly, COinS isn't a microformat, and works differently to them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)
I would check and make sure that Mediawiki:* and other parts of the CSS cascade aren't anywhere doing anything that relies on span.citation vs just .citation, and same for the .book class selector. I.e., ensure that moving the classes from <span> to <cite> doesn't break something we don't notice immediately. Then again, if it does, I'm sure someone will tell us. I've not looked at COinS much; if the book, etc., classes are part of COinS, they do seem to need to be in <span>, so we might need both (presumably the <span> inside the <cite>, since the span by itself would have no semantic "reality" on its own); but if that's just one of WP's own classes, it can be in the <cite>.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:43, 12 September 2015 (UTC)
The extent of .citation in Common.css is the following:
/* Highlight clicked reference in blue to help navigation */
span.citation:target {
    background-color: #DEF;

/* Styling for citations (CSS3). Breaks long urls, etc., rather than overflowing box */
.citation {
    word-wrap: break-word;

/* For linked citation numbers and document IDs, where
   the number need not be shown on a screen or a handheld,
   but should be included in the printed version */
@media screen, handheld {
    .citation .printonly {
        display: none;
Indeed, @Edokter: I'm not sure about that first item there. Does the <ref>...</ref> include a span when it drops its content into the bottom of the page, or is that meant to specifically target our various and sundry reference templates? --Izno (talk) 00:13, 13 September 2015 (UTC)
That's the thing that makes the [2] or whatever of the ref citation turn light blue when you are in the refs section and click on the ^ link to get back to where you were in the text. So, yeah, that would need to change to refer to the <cite>, or to be a class by itself without the element being named (unless we really do need the span as well; I'm still not sure if that class has anything to do with COinS). Ultimately it probably does not matter if have a <cite><span>{{cite journal|...}}</span></cite> structure; costs nothing but a few bytes.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:21, 13 September 2015 (UTC)
The Cite extension already provides the styles to turn the automatically generated referneces blue with the selector ol.references li:target, sup.reference:target. [Removed my own irrelevant bits] The span.citation:target snippet is an old remnant of the old link targeting mechanism, before the extension took over. The current snippet is useless and can be safely removed, because 1) references generated by citation templates, by themselves (ususally appearing between {{refbegin}}/{{refend}}), have no id and therefor 2) are not (and cannot) be linked to. That makes :target pretty pointless. -- [[User:Edokter]] {{talk}} 10:01, 13 September 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── class="citation" is required so that a cs1|2 template in a bibliography gets the blue highlight when linked from a reference in a reference list.[1] I've hacked the sandbox code so that class="citation" is not part of the <class> as an illustration.[2]


  • Blue (2008). Title. 
  • Not blue (2008). Title. 

Trappist the monk (talk) 11:05, 13 September 2015 (UTC)

I see. In that case, The span should be removed or replaced by <cite>. Though it will work without the element in the selector, I'd prefer to keep the specificity consistent to prevent accidental linking to other elements with the .citation class. But that should not be a problem until the conversion is complete. -- [[User:Edokter]] {{talk}} 12:36, 13 September 2015 (UTC)
Sorry, I do not understand what you just wrote. In Module:Citation/CS1/sandbox, the cs1|2 template output (except for the COinS) was wrapped in <span>...</span>. It is now wrapped in <cite>...</cite>. My example shows, I think, that <cite class="citation"> is required to get the blue highlight when the target cs1|2 template is outside of a {{reflist}} as commonly occurs when an article uses {{sfn}} and {{harv}} et al.
Trappist the monk (talk) 13:19, 13 September 2015 (UTC)
I was talking about the selector in Common.css. It should match whatever the module outputs. It now targets neither span or cite tags; just the .citation class, which is too broad. So I will make it target only cite.citation once the modules have been converted. If you still don't understand, don't worry about it. -- [[User:Edokter]] {{talk}} 21:52, 13 September 2015 (UTC)
FWIW, I am seeing blue highlight for the [2] ref even for the "Not blue" sample above, when I click on it's "^" link-back. I'm supposing this is because the underlying sandbox code has changed in the interim, but thought I'd report it in case not, and the example is supposed to do something else, since it might be relevant for debugging, if so.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:21, 14 September 2015 (UTC)
The superscripts do have the blue highlight; that isn't the issue. The issue is with the long-form citations; these links: #CITEREFBlue2008 and #CITEREFNot_blue2008 (or their mates in the reference list). The 'Blue' citation was rendered with <cite class="citation book"> but the 'Not blue' citation was rendered with <cite class="book">.
Trappist the monk (talk) 16:33, 14 September 2015 (UTC)
Hack to Module:Citation/CS1/sandbox in support of the examples I made here is undone.
Trappist the monk (talk) 11:23, 19 September 2015 (UTC)
@SMcCandlish: Congratulations on getting this fixed; it's good to see us as a movement contributing in that way. I've previously had WP:NOT cited at me when I've tried to get us to lead by example in similar areas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)
Pfft! WP:NOT has no power whatsoever to tell me who I can and can't contact off-wiki to fix things like W3C contradicting their own standards. >;-) It's the kind of thing I'd do anyway; the WP issue just made me notice this particular case. This may actually have quite noteworthy longer-term effects; apparently the entire W3C Cheatsheet was not being synched with the actual, live W3C Recommendation (the real spec), but had only been synched by hand or something to some old version in 2009! And WHATWG does what the Cheatsheet says. And browser makers and many others do what WHATWG says, to some extent. As far as I know, WHATWG has not updated its own materials yet since this W3C fix, but they should soon enough. I suspect and hope that much of what we're seeing with browsers lagging so far behind what the W3C HTML5 Recommendation says to do may be directly and primarily due to this synchronization failure. It would certainly be hot if that's the case, and all of sudden they started consistently implementing stuff we've been waiting on since 2013.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:28, 12 September 2015 (UTC)
2013 is awfully optimistic. --Izno (talk) 00:06, 13 September 2015 (UTC)
Hee haw! Yeah, I mean just the new stuff; I wasn't talking about stuff we've been waiting to work properly since the '90s. LOL. There did seem to be a rush to implement (at least with prefixes) lots and lots of stuff from the old draft and early release versions of HTML5, and then it just kind of stopped. I think it's because the Cheatsheet wasn't updated, so WHATWG didn't update. Then the HTML5 spec was revamped in 2013, and kinda nothing happened.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:09, 13 September 2015 (UTC)

In my opinion the CS1 and CS2 templates should produce HTML that not only gives the desired appearance at this moment, but also uses the HTML tags correctly. This thread should have begun with a link to the current official definition of the <cite> element so we could evaluate whether the changes discussed in this thread obey the documentation. Jc3s5h (talk) 15:22, 13 September 2015 (UTC)

WP:PROCESS is only important when it's important. :-) That documentation was already provided and discussed in the previous edition of this thread just a couple of weeks ago, and is also provided prominently in the Mediawiki talk:Common.css discussion linked to in the first post in this thread, where I indicated the matter had been discussed at length. Here it is again, with all the relevant off-site links. The purpose of pointers to such discussions is to avoid rehashing the same discussions. The entire point of these threads is, yes, to use the HTML correctly; the limitation of <cite> to title only was a 2009–2013 experiment that the HTML-using community rejected. As in HTML 4, the HTML5 spec allows this to cover citation data generally (the only required part is that at least one of the following must be present to use <cite>: author, title, URL).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  13:53, 14 September 2015 (UTC)

Update: I've fixed the placement and styling of <cite>...</cite> in all the templates using it that are not Template:Cite something, Template:Cite/something, or Template:Citation/something, which I've deferred here to Help talk:CS1. (This was mostly fixing it in single-source citations and in quotation templates). All that remains is for it to be integrated into the more complex citation templates.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  13:53, 14 September 2015 (UTC)

Handling multiple italicized titles[edit]

Notwithstanding the above RfC, which appears to be firmly in favor of retaining the italics by default, we might actually want a |work-noitalic=yes, as something to be used on a case-by-case basis for a reason, and not just created so people can evade a style they don't like. A genuine use case for it would be books (discrete major works) that have been published inside other books (bound paper things) with separate titles. I'd like to be able to do: {{Cite book|chapter=Foreign Words and Phrases|work-noitalic=yes|work=''The Oxford Guide to Style'', in ''Oxford Style Manual''|...}}.

Another example would be: {{Cite book|chapter=Foreign Words and Phrases|work-noitalic=yes|work=''Blood of the Isles: Exploring the Genetic Roots of Our Tribal History'' [North American title: ''Saxons, Vikings and Celts: The Genetic Roots of Britain and Ireland'']|...}}.

Another approach to this, that might be less prone to "gimme my own style" abuse, would be to distinguishing the two use cases:

  • {{Cite book|chapter=Foreign Words and Phrases|title=The Oxford Guide to Style|anthology=Oxford Style Manual|...}}
  • {{Cite book|chapter=Foreign Words and Phrases|title=Blood of the Isles: Exploring the Genetic Roots of Our Tribal History|alt-title=Saxons, Vikings and Celts: The Genetic Roots of Britain and Ireland|alt-title-label=North American title|...}}

My approach to handling the former case has been {{Cite book|chapter=Foreign Words and Phrases|title=The Oxford Guide to Style|...}} (published as part of {{Cite book|title=Oxford Style Manual|...}}. For the latter I've been doing something similar, using two citation templates. It's an unnecessarily longwinded way to do it, and prone to breakage because it doesn't keep all the citation's details in one template "package".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:12, 14 September 2015 (UTC)

{{cite encyclopedia}} does something like this:
{{cite encyclopedia |chapter=Chapter |title=Title |encyclopedia=Anthology}}
"Chapter". Title. Anthology. 
and so does {{cite book}} (sort of):
{{cite book |chapter=Chapter |title=Title |encyclopedia=Anthology}}
"Chapter". Title. Anthology. 
There are constraints imposed by the metadata. A book title in the metadata is two parts: article (chapter) title and book title. {{cite encyclopedia}} emits the value from |chapter= and |encyclopedia=. {{cite book}} on the other hand, emits the values from |chapter= and |title=. Presumably, the {{cite encyclopedia}} model is the preferred model for an anthology because, one presumes, that parameters like ISBN, publisher, etc. apply to the anthology and not to the component book. There is no way that I know of to feed a three-part title to the metadata.
It would seem not to difficult a task to create {{cite anthology}} and |anthology= so that we don't 'misuse' {{cite encyclopedia}}.
Trappist the monk (talk) 17:15, 14 September 2015 (UTC)
The example of different titles depending on place of publication seems to go against the principle of editors citing the copy that they examined. In most cases one editor would add the cite, and would have had access to only one copy. If an American and UK edition were used, probably they were used by two different editors, and the two editors would not necessarily know if the pagination in the two versions was the same. Jc3s5h (talk) 17:55, 14 September 2015 (UTC)
Right. Titles are the primary identifier of books (and other items), and if a publisher changes the title there is no telling what else may have been changed. If two titles are actually identical than one might be considered a reprint of the other, but how would an editor know that? Best that distinct titles have distinct citations. If a book or article has been republished under a different title that can be mentioned following the citation. ~ J. Johnson (JJ) (talk) 22:40, 14 September 2015 (UTC)
This isn't quite what I'm getting at. These are works that I have on hand, and they have three relevant titles: "Chapter/Article", Logical Book, Physical Book, in the one case, and "Chapter/Article", Regional Book Title I [Regional Book Title II], in the other. In the first case, I'm citing the specifics of a single work that has a hierarchy of three, not two, titles. In the other, I'm providing information to help readers locate the same source under two names (it has a typical hierarchy of two titles, but the major title has two variants). They're different cases.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:23, 15 September 2015 (UTC)
Oh. What you are talking about is not alternative titles, but titles at hierarchial levels of organization (e.g., work/chapter/section) - right? I got into that with the IPCC citations, but I am disinclined to re-visit it. ~ J. Johnson (JJ) (talk) 23:04, 15 September 2015 (UTC)

Cite book needs work alias for title[edit]

The above reminds me: {{Cite book}} needs to support |work= as an alias of what it calls |title=; as far as I recall, it's the only template in the series that doesn't support |work=, and this is a hassle for multiple reasons (having to remember which template demands what, not being able to convert easily between {{cite web}} and {{cite book}} for e-books, etc.).

Strictly speaking, it might make the most sense to re-code the {{Cite book}}'s |title= as an alias of existing |work= code (the input that gets italicized as a major work) in Cite/core, and use the same code to generate all |work= titles across all the templates. What is presently handled as |title= in almost all the templates (i.e., the input that gets quotation marks as a minor work) could be turned into an object called |item= or something, with |title= usually being an alias to it, and {{Cite book}}'s |chapter= being one, but using the same function to generate it regardless what template calls it.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:12, 14 September 2015 (UTC)

For the purposes of cs1|2, {{citation/core}} is dead.
{{cite book}} only supports |work= visually (discussed here) for which reason I have suggested elsewhere in these pages that |work= and its aliases should be ignored by {{cite book}} as they were in the old days of {{citation/core}}.
Trappist the monk (talk) 17:54, 14 September 2015 (UTC)
That you have a preference in this regard doesn't address why lack of support for |work= is problematic. I'm not suggesting that {{Cite book}} handle |title= and |work= as separate entities, but rather alias one to the other, the same way |accessdate= can also be called |access-date=. I'm not sure what "only supports |work= visually" even means, but have to run for now; will re-read that stuff and see if I can suss your meaning, if you don't clarify in the interim.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:27, 15 September 2015 (UTC)
{{cite book}} only supports |work= visually... means that you can have |work= in {{cite book}} with |title= and you will see it in the rendered citation. But, a value in |work= without |chapter= causes an error in the metadata – the citation is treated as a journal article (a bug I think that bears some thinking on). When |chapter= is included with |title= and |work= in {{cite book}}, |work= is rendered but not made part of the metadata while the other two parameters are (correctly this time).
Trappist the monk (talk) 03:03, 15 September 2015 (UTC)
That sounds like it would be fixed by having |work= and |title= be the same thing (one an alias for the other). Why would we want {{Cite book|title=...|work=...}}? That would generally make the same not-sense as {{Cite journal|journal=...|work=...}}. That said, having a special case where the use of both would case |work= to render but be omitted from the metadata would actually resolve my above need for being able to cite The Oxford Guide to Style (a logical |work=, and previously published as a separate volume, and in both editions having its own chapters and authors and such), and the Oxford Style Guide (a published |title= of the book in the "bound thing of paper in my hands" sense). In pseudocode:
if $title
if $work
[optional code for handling work-editor, etc., if separate from editor, etc., of $title]
print italicized $work [without metadata]; print ', in '; print italicized $title [with metadata];
else print italicized $title [with metadata]
else if $work
print $work [with metadata as if $title]
else [i.e. both are missing] throw missing-title error
Seems pretty simple, though I forget what is using template code and what is using Lua in these things. This could even be used for bound journals, with the bound physical book being cited as the |work= and the journal issue being cited as |journal=. I ran into this problem before trying to cite my bound volumes of Jugend, The Studio, etc., in some Art Nouveau articles, and again ended up doing the two-citations-back-to-back thing: {{Cite journal}} followed by a {{Cite book}} for the bound volume that was largely a redundant citation, but necessary to both WP:SAYWHEREYOUGOTIT and preserve the details of the bound and original publications. This can be important because, e.g. The International Studio was bound by more than one operation, and differently; I have some bound volumes of it that overlap, with some being bound by calendar year, the others being bound by the journal's own volume/issue numbering order.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:49, 16 September 2015 (UTC)

The main use case I can see for having both |title= and |work= in a {{cite book}} would be for a long multivolume work where you want to separately represent the titles of the whole work and of the volume. But that's better handled with |title= and |volume= now that the volume parameter knows to not boldface long parameter values, as for instance in

{{cite book|first1=Elwyn R.|last1=Berlekamp|first2=John H.|last2=Conway|first3=Richard K.|last3=Guy|title=[[Winning Ways for your Mathematical Plays]]|volume=Volume 2: Games in Particular|year=1982|publisher=Academic Press}}
Berlekamp, Elwyn R.; Conway, John H.; Guy, Richard K. (1982). Winning Ways for your Mathematical Plays. Volume 2: Games in Particular. Academic Press. 

So I agree with the general sentiment that having title and work be aliases of each other seems harmless enough, as long as we can get an error flag when both are used together to let us find them and replace one of the two parameters by volume or series or whatever the replacement should be. However, this does bring up a different issue (not really solved very well by misuse of the work parameter): what do we do when we have a book series that contains a multivolume book and we want to refer to one volume of that book? The |volume= parameter currently has two quite different semantics: the number of a book within a series of books, and the number or title of a volume within a single multivolume book. Is there some way to add a |series-volume= parameter to be used in ambiguous cases, or something like that? —David Eppstein (talk) 00:37, 17 September 2015 (UTC)

Request move for Module talk:Citation/CS1[edit]

Could use some eyeballs at Module talk:Citation/CS1#Requested move 9 September 2015. Thanks! Kaldari (talk) 01:37, 15 September 2015 (UTC)

choosing the correct metadata when |chapter=, |title=, and |work= are all set[edit]

Here is a list of all of the cs1 templates in the form:

{{cite ___ |title=Title |chapter=Chapter |work=Work}}
  • arXiv: Author. "Title".  |arxiv= required (help); Unsupported parameter(s) in cite arXiv (help) – chapter and work not supported in this template; includes |author= to avoid the bot invocation message
  • AV media: "Chapter". Title. Work. 
  • AV media notes: "Chapter". Title. Work (Media notes). 
  • book: "Chapter". Title. Work. 
  • conference: "Chapter". Title. Work. 
  • DVD notes: "Chapter". Title. Work (Media notes). 
  • encyclopedia: "Chapter". Title. Work. 
  • episode: "Title".  Missing or empty |series= (help) – chapter not supported; title is promoted to chapter; series is promoted to title; work ignored
  • interview: "Chapter". Title. Work. (Interview). 
  • journal: "Title". Work.  |chapter= ignored (help) – chapter ignored
  • mailing list: "Chapter". "Title" (Mailing list).  – work not supported; chapter is but shouldn't be
  • map: "Title" (Map). Work.  – chapter not supported;
  • news: "Title". Work.  |chapter= ignored (help) – chapter ignored
  • newsgroup: "Title". Work.  |chapter= ignored (help) – chapter ignored
  • podcast: "Title". Work (Podcast).  |chapter= ignored (help) – chapter ignored
  • press release: "Title". Work (Press release).  |chapter= ignored (help) – chapter ignored
  • serial: Title. Work.  – chapter not supported
  • sign: "Chapter". Title. Work.  – should only support title
  • speech: "Chapter". Title (Speech). Work.  – should only support title
  • techreport: "Chapter". Title. Work (Technical report). 
  • thesis: "Chapter". Title. Work (Thesis). 
  • web: "Title". Work.  |chapter= ignored (help) – chapter ignored

and cs2:

  • citation: "Title", Work  |chapter= ignored (help) – chapter ignored

The purpose of this list is to examine how the various templates handle the three parameters when all are set. Another conversation led me to discover that Module:Citation/CS1 may not be emitting correct metadata when |work= is set.

In Module:Citation/CS1 (and in {{citation/core}} before it), |work= and its aliases (|journal=, |newspaper= etc.) map to the meta-parameter Periodical. Similarly, |chapter= (and its aliases |article=, |contribution=, etc.) map to the meta-parameter Chapter.

There are two types of metadata: book and journal. When creating the citation's metadata, the module looks first at Chapter. If Chapter is set then the metadata type is set to book. If Chapter is not set but Periodical is set then the metadata type is set to journal. For all other cases, the metadata type is set to book.

Because the module knows which of the cs1|2 templates it is processing, we can use that knowledge to fix this issue. I will change the module so that these templates produce journal type metadata:

  • arXiv
  • conference – only when |work= is set (conference paper published in a journal)
  • interview – only when |work= is set (interview published in a magazine, newspaper, television broadcast, etc.)
  • journal
  • news
  • press release – only when |work= is set (published in a newspaper, magazine, etc.)
  • citation – only when |work= is set

Then comes a more difficult question. The metadata can accommodate two title-holding parameters: rft.jtitle and rft.atitle for journals, or rft.btitle and rft.atitle for books. When cs1 templates use three title-holding parameters |chapter=, |title=, and |work=, which two of these should be made part of the metadata? Some templates are already constrained to one or two title-holding parameters; should others be similarly constrained?

Trappist the monk (talk) 13:35, 15 September 2015 (UTC)

Module:Citation/CS1/sandbox tweaked. These are {{cite conference}} examples:
  • |title=, |chapter=, |work= – uses jtitle, atitle, and sets genre to article
    • <cite class="citation conference">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • |title=, |chapter= – uses btitle, atitle, and sets genre to bookitem
    • <cite class="citation conference">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • |title= – uses btitle and sets genre to book
    • <cite class="citation conference">''Title''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
the same but this time with the one-way alias |book-title=; chapter is held in |title= (|chapter= is ignored when |book-title= is set):
  • |book-title=, |title=, |work= – uses jtitle, atitle, and sets genre to article
    • <cite class="citation conference">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • |book-title=, |title= – uses btitle, atitle, and sets genre to bookitem
    • <cite class="citation conference">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • |book-title= – uses btitle and sets genre to book
    • <cite class="citation conference">''Title''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
Trappist the monk (talk) 15:05, 15 September 2015 (UTC)

|section= not working in cite news?[edit]

I used |section= in a {{cite news}} in the My War article, and I got the error: "|chapter= ignored (help)". Curly Turkey 🍁 ¡gobble! 23:13, 15 September 2015 (UTC)

{{cite news |last = Hampton |first = Howard |title = Black Flag: Waving Goodbye to the World |newspaper = [[The Phoenix (newspaper)|The Phoenix]] |date = 1984-04-17 |page = 8 |section = 3 |url =,1781571&hl=en |ref = harv}}
Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. p. 8.  |section= ignored (help)
|section= is an alias of |chapter=, hence the error message. Consider |at=Section 3, p. 8
Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. Section 3, p. 8. 
Trappist the monk (talk) 23:24, 15 September 2015 (UTC)
Is |section= (or |chapter= or whatever) not supposed to work, then? Curly Turkey 🍁 ¡gobble! 00:29, 16 September 2015 (UTC)
The mention of |chapter= and |section= in Template:Cite news#COinS could lead someone to think it is OK to use those parameters in {{cite news}}. GoingBatty (talk) 02:31, 16 September 2015 (UTC)
I sthere some reason it shouldn't be? The newspaper I cited had sections with their own paginations. Curly Turkey 🍁 ¡gobble! 03:58, 16 September 2015 (UTC)
Isn't it true that most newspapers have separate sections and pagination? The documentation for |at= at {{cite news}} specifically includes Section. The decision to make |section= an alias of |chapter= was taken long ago in support of another template ({{cite manual}} I think). Chapters are not supported in periodicals because it is not possible to shoehorn three cs1|2 title-holding parameters (|newspaper=, |title=, and |section= in this case) into the two metadata title-holding parameters (rft.jtitle and rft.atitle). Because there is an in-source metadata parameter (rft.pages), setting |at=Section 3, p. 8 renders the complete citation visually as well as in the metadata.
Trappist the monk (talk) 10:46, 16 September 2015 (UTC)
Well, that went over my head, but okay ... But wouldn't it be better to have the template automatically format it at least, rather than spit out an error? Curly Turkey 🍁 ¡gobble! 12:18, 16 September 2015 (UTC)
The template spits out an error because it doesn't know what to do with a chapter alias in a periodical-style citation. How should it be automatically formatted? Quoted? Italics? Neither of those? Where in the rendered citation should it go? The answers to these questions must apply to a very large majority of the templates in which |section= is used.
Trappist the monk (talk) 15:02, 16 September 2015 (UTC)
Well, if it's what I have to do then it's what I have to do, but it (a) feels like a hack, and (b) is totally unintuitive. |at= "May be used instead of 'page' or 'pages' where a page number is inappropriate or insufficient"—in this case |page= sure doesn't seem insufficient (it's on page 8!), and |at= isn't the obvious answer (you have to dig to find it, and then interpret the documentation as "Aha! This situation!").
if |section= et. al don't work, then shouldn't they be removed from the "COinS metadata is created for these parameters" section? Curly Turkey 🍁 ¡gobble! 23:27, 16 September 2015 (UTC)
|section= should be supported in periodicals, independently of |chapter=, because there are important sources that do break articles by sections. Also by paragraphs. ~ J. Johnson (JJ) (talk) 22:40, 17 September 2015 (UTC)

error message tweak[edit]

I have tweaked Module:Citation/CS1/sandbox. The current live version of the module lumps all aliases of |chapter= into a single '|chapter= ignored' error message. This tweak causes the error message to identify the alias that is used in the cs1|2 template:

  • "Title". Journal.  |chapter= ignored (help)
  • "Title". Journal.  |contribution= ignored (help)
  • "Title". Journal.  |entry= ignored (help)
  • "Title". Journal.  |article= ignored (help)
  • "Title". Journal.  |section= ignored (help)

Trappist the monk (talk) 23:53, 15 September 2015 (UTC)

Wouldn't it be far more helpful to directly alias these to cite journal's version of |title=, given that that's what they mean? If they're used at the same time, then |chapter= could be treated as |at=, within |title=. And if |at= is also present, well, I dunno; have an |at2=.

This brings me back to my earlier proposal of normalizing all these parameter names across all the templates. It would be so much simpler if we had something like this:

{{Cite ______


where |cite= is the minor work being cited (article, episode, book chapter, song on album, etc.); |at= is a subset there of, where relevant (section of article, section of book chapter, whatever); |work= is the major work (journal/newspaper/magazine, website, book title, album, TV series, etc.). I get more and more tempted all the time to just go create a CS3 designed from the start to be mutually consistent across all media types, so someone could learn how to cite in one sitting and get it right no matter what they're citing.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:12, 16 September 2015 (UTC)

Hindsight being what it is, were we to do it again, crafting a citation system from the ground up by starting with a real style guide and then coding to that would be preferable. But that isn't how it happened. We started with one or two templates that evolved into some twenty, all written independently. {{citation/core}} reduced the differences amongst the templates and Module:Citation/CS1 continues that with varying amounts of success. That is the problem with the evolutionary nature of Wikipedia: start with something disruptive and then tweak it until it's just good enough.
Trappist the monk (talk) 09:59, 17 September 2015 (UTC)

COinS and smallcaps[edit]

Template:Smallcaps/doc needs an update (where the {{clarify}} tag is) on what people should do to get the desired Small Caps effect for certain things in particular citation styles, given that {{Smallcaps}} is not COinS-safe.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:02, 16 September 2015 (UTC)

Yes check.svg Done. Let me know if my edits are unclear in incomplete. – Jonesey95 (talk) 03:37, 17 September 2015 (UTC)

Proposal for lead with the main cite that Wikipedians come to this page for[edit]

I think right on the "first screen" that the reader sees, without having to scroll down, she should see what is probably the main cite format that people to come to this page for: cite web |url= |title= |last1= |first1= |last2= |first2= |date= |website= |publisher= |access-date= |quote=}}. I think this would be helpful : )OnBeyondZebraxTALK 17:03, 17 September 2015 (UTC)

To be consistent, we would need to change the documentation for dozens of cite templates. Are there other templates whose documentation is structured in this way? I clicked on a sample of templates that I watch, including {{Birth date}}, {{Birth date and age}}, {{Death date and age}}, {{GOCE award}}, {{Infobox body of water}}, and {{Template for discussion}}. Of those that have a lead section and a table of contents, none of them do what OnBeyondZebrax proposes. – Jonesey95 (talk) 01:02, 18 September 2015 (UTC)

I think this would be quite unhelpful, actually. We should be encouraging Wikipedia editors to cite newspapers, books, and academic journals rather than web pages. And when they do cite those things, we should not be encouraging them to use the wrong template to do so. —David Eppstein (talk) 01:12, 18 September 2015 (UTC)

Yes. Especially where a web "source" only echoes a printed source. A large proportion of WP editors are quite unacquainted with the broad range of possible sources, and we need to gently encourage them to see beyond the web. ~ J. Johnson (JJ) (talk) 21:20, 23 September 2015 (UTC)

Update to the live CS1 module weekend of 26–27 September 2015[edit]

On the weekend of 26–27 September I propose to update the live CS1 module files from the sandbox counterparts:

Changes to Module:Citation/CS1 are:

  1. bug fix in |edition test; discussion
  2. bug fix in parse_vauthors_veditors(); discussion
  3. add test for 'and others' text to name_has_etal (); discussion
  4. enhanced |url= scheme test; discussion
  5. fix cite episode missing |series= error message; discussion
  6. bug fix in select_author_editor_source () that skipped extract_name(); discussion
  7. remove support for deprecated parameters, including |month=; discussion
  8. expand defined-value error detection; discussion
  9. add Macedonian (mk) to languages supported by |script-title=;
  10. suppress original url when |dead-url=usurped; discussion
  11. add support for |script-chapter=; discussion
  12. hyphenate parameter names in error messages; discussion
  13. move url prefixes for identifiers |asin= and |ol= to /Configuration;
  14. add url in |title=, |chapter=, |work= parameters; discussion
  15. combine |trans-title= & |trans-chapter= error messages; discussion
  16. remove stray colon from ismn rendering;
  17. add translator support; discussion
  18. tweak COinS to prevent duplication of first author; discussion
  19. enhance |vauthors= error checking; discussion
  20. replace wrapping <span>...</span> with <cite>...</cite>; discussion
  21. COinS output by citationClass rather than by parameter; discussion
  22. tweak missing chapter error messages; discussion

Changes to Module:Citation/CS1/Configuration are:

  1. deactivated 24 deprecated parameters; discussion
  2. create table of keywords used by is_valid_parameter_value(); discussion
  3. hyphenate parameter names in error messages; discussion
  4. add translator support; discussion
  5. move url prefixes for identifiers |asin= and |ol= from Module:Citation/CS1
  6. add url in |title=, |chapter=, |work= parameters; discussion
  7. change isbn error category name; discussion
  8. change embedded wikilink error message and category; discussion
  9. combine |trans-title= & |trans-chapter= error messages; discussion

Changes to Module:Citation/CS1/Whitelist are:

  1. deactivated 24 deprecated parameters; discussion
  2. deprecate |Ref=; non-standard capitalization; discussion
  3. add translator support; discussion

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

  1. hyphenate parameter names in error messages; discussion

Trappist the monk (talk) 12:10, 19 September 2015 (UTC)

Looks good to me. Look at all of the good work we have accomplished in the last couple of months! – Jonesey95 (talk) 13:45, 19 September 2015 (UTC)
For the record, this update happened about 40 minutes before my time stamp. – Jonesey95 (talk) 16:54, 26 September 2015 (UTC)

Test for date in |author=?[edit]

I came across a date in |author= while working on something else. How hard would it be to test for dates, or at least well-formed dates, in |author= fields? As always, I worry about false positives, so it may be something to put in a maintenance category.

I suspect that some sort of automated reference-filling tool populated |author= with dates, or at least included dates along with the author name, due to bad metadata on the source web page or bad processing of the page's data. – Jonesey95 (talk) 13:58, 19 September 2015 (UTC)

If such a test is to be created, bear in mind we allow editors to enter corporate authors in this field. Some organizations have a date fragment in their name. So the test should only be triggered if a well-formed date containing a year, month, and day is present. Jc3s5h (talk) 14:11, 19 September 2015 (UTC)
@Jonesey95: Edits like the one you've mentioned are a result of editors not fixing the suggestions given by Reflinks before saving their edits. We tried to discuss this with Dispenser but did not get any answer. BattyBot tries to fix/remove some bad author values, but can't fix them all. Therefore, I support a maintenance category. GoingBatty (talk) 14:16, 19 September 2015 (UTC)
Reflinks was the tool: diff and diff. But, like any edit, the tool-user is equally culpable.
If this is a problem caused by a tool, then the tool should be fixed. I suspect that searching for date formats that both do and don't comply with WP:DATESNO is a challenge that we should only accept if there is significant evidence of widespread malformed |author= parameters in the field.
(I've renamed this section to remove {{para}} so that section links from watch lists work.)
Trappist the monk (talk) 14:31, 19 September 2015 (UTC)
@Trappist the monk: A quick search of the September 2015 database dump of found 2,304 results. I'm sure other formats will find additional instances. I'm adding some rules for BattyBot to remove the date from the author parameter when it matched the YYYY-MM-DD date in the date parameter. I'd also be happy if ReferenceBot would notify editors when they added references with incorrect parameters like this. GoingBatty (talk) 15:40, 19 September 2015 (UTC)
Is that number sufficiently large to make us add code to the module and create some sort of category to support it? Is this an automated tool issue or is it an error commonly made by editors filling out the template?
Trappist the monk (talk) 16:06, 19 September 2015 (UTC)
@Trappist the monk: To determine if it's sufficiently large enough, I guess you would first identify the most common incorrect formats, see how many added/tweaked rules could be added to BattyBot, and then see how many are left. My guess is this is commonly an issue of people not taking care when using automated tools (and people unwilling to fix their tools), but I have no statistics on that. GoingBatty (talk) 18:32, 19 September 2015 (UTC)
How can BattyBot fix these errors if they are not yet in a category? – Jonesey95 (talk) 20:31, 19 September 2015 (UTC)
@Jonesey95: I built the list of articles based on a database search for author\s*=\s*(January|February|March|April|May|June|July|August|September|October|November|December)\s+\d{1,2},\s+\d{4}. GoingBatty (talk) 20:40, 19 September 2015 (UTC)

Citeweb website parameter[edit]

Would it be possible to make this respond to typing "site=" as well as "website=" ? "Web" is implied by the use of the template and this would take up less space and I find myself using that by accident a lot. Ranze (talk) 14:52, 22 September 2015 (UTC)

Foreign language authors & publishers[edit]

I'm wondering whether we should establish a way that foreign language author and publisher names should be handled in citation templates. This has been addressed before here: Help_talk:Citation_Style_1/Archive_8#Foreign author name (perhaps elsewhere but I was unable to find it) but there wasn't consensus on what should be done with author names that are written in non-Latin scripts. I understand that English sources are preferred on the English Wikipedia, but if the only sources available are written in Korean or Chinese, how should the author's name be included? Including only a transliteration does nothing to help someone who is trying to locate an article if its URL is dead. Since using the script-title and trans-title parameters produces "Script title [trans title]", perhaps something similar should be prescribed for author and publisher names? For example: [1]


As someone who has done a lot of work trying to rescue dead references, I've found it very frustrating if all I have available is the URL and an author name that was romanized in a non-standardized manner. Thanks, and I'm looking forward to your input, Ry's the Guy (talk|contribs) 18:05, 22 September 2015 (UTC)

Non-standard romanisations could be addressed by including the author's ORCID iD, or other authority control (or even a Wikidata ID), where they have one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:11, 23 September 2015 (UTC)r
Thanks for your response. Most of the references I come across are Korean online newspapers and the authors are generally not notable enough to have any data on Wikidata and there is no ID identifying them. In the past I have used the romanization with the corresponding Hangul in parentheses for author names, and have had others remove the Hangul because they thought that I hadn't formatted the reference correctly. As the citation templates' documentation are written now, there's nothing specifying whether the original script name or romanization should be included. Ry's the Guy (talk|contribs) 06:54, 24 September 2015 (UTC)

Cite video game[edit]

I'm wondering if it's possible to get default support for Template:Cite video game in Module:Citation/CS1 or perhaps some help with integrating it better with CS1. Right now, it bizarrely relies on Template:Cite journal (for the metadata???), which is inhibiting the correct citation of a video game with italics. Current example of an outputted title would be: "Example", as opposed to the correct Example. Previous discussion at Template talk:Cite video game#Quotes versus italics petered out in 2013 regarding the change (incorrectly) from quotation marks to italics. --Izno (talk) 00:10, 24 September 2015 (UTC)

{{cite AV media}}?

{{cite AV media
 |title=[[Halo 3]]
 |author=[[Bungie]] <!-- developer -->
 |publisher=[[Microsoft Game Studios]]
 |series=[[Xbox 360]] v1.0 <!-- concatenation of |platform= and |version= -->
 |at=The Storm
 |quote='''Arbiter''': "More Brutes?" / '''Master Chief''': "Worse."

Bungie (2007-09-25). Halo 3. Xbox 360 v1.0. Microsoft Game Studios. The Storm. Arbiter: "More Brutes?" / Master Chief: "Worse." 

Trappist the monk (talk) 00:53, 24 September 2015 (UTC)

|series= probably isn't much worse than |volume= + |issue=, I guess. |via= might be better but for the fact of the pre-output "via". --Izno (talk) 01:20, 24 September 2015 (UTC)
I modified the sandbox of {{Cite video game}} to use {{cite book}} instead of {{cite journal}}. It looks like this:
{{cite video game/sandbox |title=[[Halo 3]] |developer=[[Bungie]] |publisher=[[Microsoft Game Studios]] |date=2007-09-25 |platform=[[Xbox 360]] |version=1.0 |level=The Storm |language= |quote='''Arbiter''': 'More Brutes?' / '''Master Chief''': 'Worse.' }}
Bungie (2007-09-25). Halo 3. Xbox 360 v1.0. Microsoft Game Studios. Level/area: The Storm. Arbiter: 'More Brutes?' / Master Chief: 'Worse.' 
Compare to the current template:
Bungie (2007-09-25). Halo 3. Xbox 360 (v1.0). Microsoft Game Studios. Level/area: The Storm. Arbiter: 'More Brutes?' / Master Chief: 'Worse.' 
It looks like the sandbox results in the current rendering, except with italics for the title, per WP:VG/STYLE. – Jonesey95 (talk) 03:31, 24 September 2015 (UTC)
I updated the module. If we see a regression, someone can come bug me. --Izno (talk) 17:03, 24 September 2015 (UTC)
You should probably post a note at the very active Wikipedia talk:WikiProject Video games, citing WP:VG/STYLE as the reason for the change. Citation-related talk pages are often watched by few people compared to the number who watch project pages. – Jonesey95 (talk) 17:14, 24 September 2015 (UTC)
I'm part of WP:VG, but I probably should anyway. ;) --Izno (talk) 17:44, 24 September 2015 (UTC)

I'm not sure that {{cite book}} is the right template. One of the things that will change with the next update to the module is that the metadata will be in slightly closer alignment to the template that creates it; see choosing the correct metadata when |chapter=, |title=, and |work= are all set.

Also see Module_talk:Citation/CS1/COinS. The Used keys table there shows which metadata keywords are supported for the two object types available to us. Right now, everything is a book unless it is {{cite arxiv}}, {{cite journal}} or {{cite news}} in which case it is a journal. {{citation}}, {{cite conference}}, {{cite interview}}, and {{cite press release}} are treated as journal when the the module's metaparameter Periodical is set; otherwise these are treated as book.

The metadata keyword rft.genre has several set values that it can hold depending on the object (book or journal). After this next update to the module, I intend to refine how rft.genre is used for the individual templates.

Getting back to the topic, because {{cite video game}} uses {{cite book}}, the metadata will describe the video game as a book. Just as {{cite journal}} was the wrong template because of visual styling, so too is {{cite book}} the wrong template because of the metadata that will/are being produced. Because those things typically cited with {{cite AV media}} are not books or journals and because the metadata only give us book or journal, we should choose book for the metadata and then set rft.genre to unknown. Because |volume= and |issue= are not supported in the metadata for book, |series= is an appropriate choice to receive both |platform= and |version=.

I have hacked the {{cite video game}} sandbox to use {{cite AV media}}:

Bungie (2007-09-25). Halo 3. Xbox 360 v1.0. Microsoft Game Studios. Level/area: The Storm. Arbiter: 'More Brutes?' / Master Chief: 'Worse.' 

Visually similar except for the parentheses around |version=.

Trappist the monk (talk) 23:41, 24 September 2015 (UTC)

techreport in a collection?[edit]

What is the proper markup to use for a tech report that's published as part of a collection of such papers? Specifically, what's the term to use to indicate the collection's title, as opposed to the article within it? Maury Markowitz (talk) 19:17, 24 September 2015 (UTC)

Would |series= work for your source? See the cite techreport documentation. – Jonesey95 (talk) 19:46, 24 September 2015 (UTC)
I believe a "series" is usually taken as, well, a series of separate publications over a period of time (i.e., "periodically"). For a collection of articles (or reports) published together "work" seems more appropriate. The documentation suggests that "works" are only newspapers, magazines, and journals – i.e., periodicals – but "work" as a collection seems well established. Perhaps at some point that should be documented. ~ J. Johnson (JJ) (talk) 20:04, 25 September 2015 (UTC)

So {{cite work? That seems appropriate. Maury Markowitz (talk) 13:33, 4 October 2015 (UTC)

How to fix this external link error?[edit]

There are articles showing up in the new Category:CS1 errors: external links because of the following citation format:

Citation compare
{{ citation | display-editors=0 | editor-last=Baynes | date=1878 | p=45 | publisher=Charles Scribner's Sons | title=''[[s:Encyclopædia Britannica, Ninth Edition|''Encyclopædia Britannica'', 9th ed.]], [[s:Encyclopædia Britannica, Ninth Edition/Volume II|Vol. II]]'' | ref=CITEREFEB1878 | editor-first=Thomas Spencer | location=New York | contribution=[[s:Encyclopædia Britannica, Ninth Edition/Angora|Angora]] }}
Live "Angora", Encyclopædia Britannica, 9th ed., Vol. II, New York: Charles Scribner's Sons, 1878, p. 45 
Sandbox "Angora", Encyclopædia Britannica, 9th ed., Vol. II, New York: Charles Scribner's Sons, 1878, p. 45 

I have seen a few in this format in a sample of articles from the category. We should probably have a recommended way of fixing these. Any proposals? – Jonesey95 (talk) 16:35, 26 September 2015 (UTC)

Follow-up: {{EB1911}} is also generating this error message. It is transcluded in 12,387 articles. It uses {{Cite EB1911}}, which is transcluded in 16,067 articles. It would be good for us to find a fix for this template before this red error message is displayed on that many pages. – Jonesey95 (talk) 16:49, 26 September 2015 (UTC)

The test was fooled by the [[s: the last three characters of which look like a legitimate uri scheme. I've added a check for internal wikilinks to a namespace. Here we see that the rest of the code still catches a legitimate uri scheme:

{{cite book/new |title=[ Example]}}
Example.  External link in |title= (help)

Live module updated.

Trappist the monk (talk) 17:19, 26 September 2015 (UTC)

That works for me. Thanks. This pattern may need some more tweaking. This citation is causing an error message:
Cite journal compare
{{ cite journal | issn=1318-797X | date=September 2012 | trans_title=2000 Years of Emona? What Will We Celebrate? | volume=XVII | language=sl | deadurl=no | first=Marjeta | journal=Ljubljana: glasilo Mestne občine Ljubljana [Ljubljana: The Bulletin of the City Municipality of Ljubljana] | archivedate=2013-07-05 | last=Šašel Kos | title=2000 let Emone? Kaj bomo praznovali? | archiveurl= | url= | pages=28–29 | issue=7 | accessdate=2013-07-01 }}
Live Šašel Kos, Marjeta (September 2012). "2000 let Emone? Kaj bomo praznovali?" [2000 Years of Emona? What Will We Celebrate?] (PDF). Ljubljana: glasilo Mestne občine Ljubljana [Ljubljana: The Bulletin of the City Municipality of Ljubljana] (in Slovenian) XVII (7): 28–29. ISSN 1318-797X. Archived from the original on 2013-07-05. Retrieved 2013-07-01.  External link in |work= (help)
Sandbox Šašel Kos, Marjeta (September 2012). "2000 let Emone? Kaj bomo praznovali?" [2000 Years of Emona? What Will We Celebrate?] (PDF). Ljubljana: glasilo Mestne občine Ljubljana [Ljubljana: The Bulletin of the City Municipality of Ljubljana] (in Slovenian) XVII (7): 28–29. ISSN 1318-797X. Archived from the original on 2013-07-05. Retrieved 2013-07-01. 
We'll get this thing debugged. We may need to settle for finding specific patterns, like "http://". – Jonesey95 (talk) 17:52, 26 September 2015 (UTC)
The fix for this is pretty easy. In correctly formed external wikilinks, the first character after the required colon should not be a space. The fix then is changing:
value:match ("%[%a[%a%d%+%.%-]*:.*%]")
value:match ("%[%a[%a%d%+%.%-]*:%S.*%]")
But, should we? Should |journal= be holding both original and translated journal titles? (In this discussion, that is a rhetorical question that should be taken up and answered.) The url test, as it is, may find other templates that look like this one but I suspect that there won't be many of them. If that is a reasonable assumption, I'll tweak the sandbox but leave the live version alone.
Trappist the monk (talk) 18:33, 26 September 2015 (UTC)
As far as I know, we don't have a |trans-work= or Template:Trans-journal parameter, so what's an editor to do if that editor wants to be helpful by providing a translation of a journal name?
As the category populates, we'll get a better sense of how much of this stuff is out there. – Jonesey95 (talk) 19:01, 26 September 2015 (UTC)

I have refined the test pursuant to this conversation. The new test is:

value:match ("%f[%[]%[%a[%a%d%+%.%-]*:%S.*%]")

The frontier pattern adds the requirement that any character immediately preceding an external wikilink's opening square bracket must be something other than another square bracket:

pass: doesn't find interwiki link pass: doesn't find interwiki link at start of title. 
fail: finds external link [4].  External link in |title= (help)
[5] fail: finds external link at start of title.  External link in |title= (help)
fail: finds external link [6] even with interwiki link.  External link in |title= (help)

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

Bad rendering and erroneous "extra text" message for author=Beaudet AL[edit]

I found this citation in 5-HT2C receptor:

Cite journal compare
{{ cite journal | pmid=18500341 | author=Sahoo T, del Gaudio D, German JR, Shinawi M, Peters SU, Person RE, Garnica A, Cheung SW, Beaudet AL | journal=Nat Genet | pmc=2705197 | doi=10.1038/ng.158 | title=Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster. | volume=40 | year=2008 | pages=719–21 | issue=6 }}
Live Sahoo T, del Gaudio D, German JR, Shinawi M, Peters SU, Person RE, Garnica A, Cheung SW, Beaud; et al. (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster.". Nat Genet 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341. 
Sandbox Sahoo T, del Gaudio D, German JR, Shinawi M, Peters SU, Person RE, Garnica A, Cheung SW, Beaudet AL (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster.". Nat Genet 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341. 

The |author=...Beaudet AL causes an "extra text" message to appear, and the author's name is not rendered correctly, presumably because the author's name ends in "et AL". I suppose you could say "don't list the authors that way", but a single author listed as |author=Beaudet AL is acceptable, and it generates the same error:

Cite journal compare
{{ cite journal | pmid=18500341 | author=Beaudet AL | journal=Nat Genet | pmc=2705197 | doi=10.1038/ng.158 | title=Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster. | volume=40 | year=2008 | pages=719–21 | issue=6 }}
Live Beaud; et al. (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster.". Nat Genet 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341. 
Sandbox Beaudet AL (2008). "Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster.". Nat Genet 40 (6): 719–21. doi:10.1038/ng.158. PMC 2705197. PMID 18500341. 

Just a minor bug to squish. – Jonesey95 (talk) 20:00, 26 September 2015 (UTC)

Trappist the monk (talk) 21:33, 26 September 2015 (UTC)

Cite xxx defaults to |nopp=y[edit]

Please revert to prior. (talk) 20:01, 26 September 2015 (UTC)

Trappist the monk (talk) 21:34, 26 September 2015 (UTC)

last-author-amp change[edit]

For some reason this parameter is now reporting as invalid if the value is 1, as I've been using in hundreds of articles. Changing the value to y makes it display properly. Looking at the documentation any value should work, including 1. What has happened?--Sturmvogel 66 (talk) 23:01, 26 September 2015 (UTC)

Good catch. I updated the documentation. This changed today; some parameters that had previously been lax about checking for appropriate values have been made more strict. One of the friendly gnomes here, maybe me, will be sweeping through with a script to update all of those "1" values. – Jonesey95 (talk) 23:22, 26 September 2015 (UTC)
Paging GoingBatty or someone else with access to AWB and some time on your hands. Do a search for insource:/\|\s*lastauthoramp\s*=\s*[1&]/ to see a list of between 750 and 1,000 articles containing values of "1" or "&" for |lastauthoramp=. – Jonesey95 (talk) 01:30, 27 September 2015 (UTC)
@Jonesey95: Symbol wait.svg BRFA filed. GoingBatty (talk) 12:29, 27 September 2015 (UTC)
While you were doing that I hacked a simple script to fix those |last-author-amp= parameters with something other than yes-true-y and remove |last-author-amp=no and |last-author-amp=n and that were in Category:CS1 errors: invalid parameter value.
Find: \|\s*last\-?author\-?amp\s*=\s*(?:no|n) Replace: with nothing
Find: \|\s*last\-?author\-?amp\s*=\s*[^\s\|\}]*([\s\|\}]+) Replace: |last-author-amp=yes$1
Trappist the monk (talk) 13:04, 27 September 2015 (UTC)
Nice. I've done a few dozen with an AutoEd script, but (a) 1,000 or so is more of a bot task, and (b) the errors are trickling into the category slowly, so if we can go find them before the red error messages show up for readers, that is a better approach. – Jonesey95 (talk) 14:57, 27 September 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I asked this on the BRFA, and was suggested by Batty to repeat it here: Why do we need to make the parameter more strict? Some users are likely to continue to use the old values; can't we leave in support for it but have the alternate values be undocumented? Thanks. — Earwig talk 22:38, 27 September 2015 (UTC)

See this discussion and the discussion that preceded it. We had a number of parameters that were documented inconsistently and that functioned inconsistently and, sometimes, counterintuitively. For example, setting |last-author-amp=no would give you an ampersand before the last author, even though you thought you were asking to the ampersand to be suppressed. On the other hand, setting |subscription=no worked as expected. We made these parameters work consistently.
Because some of the parameters' documentation instructed editors to use any value to make the parameter work, we are cleaning up these now non-standard usages to preserve the editors' intent. – Jonesey95 (talk) 23:10, 27 September 2015 (UTC)
Thanks, this helps clarify things. — Earwig talk 01:26, 28 September 2015 (UTC)

External link in |work= (help)[edit]

I'm seeing a template with 100s of uses throwing this error message everywhere (which it didn't previously). The help link says to not put a URL in the work but put it in the url field. But what if the specific citation AND the work as a whole each have a URL, having just one url field isn't sufficient, so you have to do |work=[someurl workname] as your only option. We often see the same problem with online accessible books/journals where you would like to have a URL for both the metadata (usually a library catalogue entry) as well as for the fulltext. One url field isn't sufficient, you really need at least 2 URL fields, one that takes you to the actual data and one that takes you to the work or meta-data that provides the contextual information surrounding the data (which might include how to interpret the data, the licensing etc). Until now you could do the work-around of having an external link in the work field or other field as necessary, but now this is prevented, how do we provide these 2 urls to the reader? I hope this can be fixed quickly. Kerry (talk) 06:51, 27 September 2015 (UTC)

@Kerry Raymond: could you provide a specific example of a citation that causes you this problem? Note that two URLs are available via |contribution-url= and |url=. Peter coxhead (talk) 08:18, 27 September 2015 (UTC)
Template:Cite QPN is one. The URL field (which is sort-of broken at the moment due to a recent change in the govt website but I am working to fix that) is different to the Work URL that explains what this data set is. Kerry (talk) 08:29, 27 September 2015 (UTC)

This is a time when the general purpose nature of {{citation}} is a benefit:

{{citation |mode=cs1 |contribution=Kenmore (41505) |contribution-url= |url= |title=Queensland Place Names |publisher=Queensland Government |access-date= |ref=CITEREFQPN41505 }}
"Kenmore (entry 41505)". Queensland Place Names. Queensland Government. Retrieved 13 September 2015. 

Trappist the monk (talk) 09:06, 27 September 2015 (UTC)

Another advantage of this approach (i.e. using the {{citation}} template as the primary one) is that by having |mode= available in the secondary template, it can be deployed in articles that use CS2. Many secondary citation templates don't allow a choice between CS1 and CS2, which prevents their use in many articles. Peter coxhead (talk) 09:40, 27 September 2015 (UTC)
Is contribution-url documented? I cannot see it. Kerry (talk) 00:33, 29 September 2015 (UTC)
Visual editor does not know about it either. Kerry (talk) 00:40, 29 September 2015 (UTC)
|contribution-url= is listed at Template:Citation#Template Data. It is a valid parameter that is an alias of |chapter-url= (also listed at Template Data). We need someone who knows and uses VE to update the VE-only documentation. As far as I know, there was never any documentation for |contribution= and |contribution-url=. There is no indication that either of these will be going away.
Trappist the monk (talk) 00:56, 29 September 2015 (UTC)

"The features of this template will be added to the citation templates in the next update."[edit]

Greetings. Template:Lang (and other templates) say that their features (which presumably includes the <span lang= microformat) will be included "in the next update". Has this been done for that specific template? I wanted to update the documentation there, but I don't know much about these übercomplicated templates.Jo-Jo Eumerus (talk, contributions) 21:15, 27 September 2015 (UTC)

Retired Editor Gadget850, once a significant contributor to this project, added that comment. I'm not sure what his intentions were nor how he imagined that the facilities of {{lang}} et al. would be included in cs1|2. At a guess, I think that support for certain languages that use non-Latin alphabets was something that he was considering. Some of the {{lang}} support is present in cs1|2 when editors use the |script-title= and |script-chapter= parameters. |language= now accepts ISO 639-1 codes. Editor Gadget850 participated regularly at this talk page and all of the cs1 template talk pages before they were merged into this talk page, and also to the talk pages for Module:Citation/CS1 and {{citation}}. Perhaps your answer lies there. If you discover what it was that he meant by that rather cryptic note, come back and tell us what you've discovered.
Trappist the monk (talk) 21:41, 27 September 2015 (UTC)
Doesn't look like it ever happened; there is a brief discussion here but if it was implemented I can't see it. My understanding is that the language class could interfere with the COinS metadata; is there a solution to that?Jo-Jo Eumerus (talk, contributions) 08:16, 28 September 2015 (UTC)
Only the |script-title=, |script-chapter=, |language= I mentioned above has been implemented. There isn't a mechanism to automagically know that the content of |title= is indeed Spanish when |language=es. I suppose we could use something similar to the language specifier that is used in |script-title= so that concerned editors could write |title=es:... or maybe create |lang-title= that would use the content of |language= to wrap the title in <span lang=...>...</span>.
Trappist the monk (talk) 10:36, 28 September 2015 (UTC)

Cite archive[edit]

Editors may be interested in this proposal for a "cite [museum] archive" template. --Izno (talk) 18:50, 28 September 2015 (UTC)

Where is the URL error here?[edit]

I must be missing something. Where is the URL error here?

U.S. Census Bureau. Census 2000, Summary File 1. GCT-PH1. Population, Housing Units, Area, and Density: 2000 - County Subdivision and Place, "Brown County, South Dakota" Check |url= scheme (help). American FactFinder. <>. Retrieved 2008-01-31. 

When I View Source on this rendered page, I do not see a problem with the URL. I need another pair of eyes. – Jonesey95 (talk) 14:37, 29 September 2015 (UTC)

Template:American Factfinder2, used in the creation of the URL, includes a comment at the beginning. Maybe that's causing the issue? --Izno (talk) 14:58, 29 September 2015 (UTC)
{{Cite American Factfinder2}} gets it's value for |url= from {{American Factfinder2}} to which is passes three values, in this case 2, 46013, and county. With those values, {{American Factfinder2}} returns this as a value for |url= GCT-PH1. Population, Housing Units, Area, and Density: 2000 - CY10,
Module:Citation/CS1 rejects it because the 'url' contains spaces which urls must not do.
Trappist the monk (talk) 15:02, 29 September 2015 (UTC)

Protected edit request on 1 October 2015[edit] (talk) 12:54, 1 October 2015 (UTC)

@ we need to know what change you desire to be made. Please provide us with some idea, preferably in a before and after format, so we know what it is you want us to do. Imzadi 1979  13:12, 1 October 2015 (UTC)

Suggestion: maintenance or error category for characters that do not belong in any citation template[edit]

This is a suggestion for a new maintenance or error category that could be created when characters are detected in citations that should not be in any citations. I'm thinking of various hidden characters and the � (question mark inside a diamond, character U+FFFD) that sometimes show up in Wikipedia articles because of copy-pasted text with hidden characters or characters that failed a transition from one character set to another. There may be a list of these undesirable characters in AWB's general fixes or somewhere else in a WP cleanup script. – Jonesey95 (talk) 01:26, 2 October 2015 (UTC)

Basically the "no such character" characters, right? Sounds good. ~ J. Johnson (JJ) (talk) 22:16, 2 October 2015 (UTC)
Are there other "no such character" characters? What other legitimate characters? Zero-width space? Soft hyphen? What about Non-breaking space?
Trappist the monk (talk) 00:29, 3 October 2015 (UTC)
I suspect that there is a list of them somewhere, possibly in the AWB source. I have one in line 20 of User:Jonesey95/AutoEd/doi.js that shows up in copy-pasted DOI values sometimes. You can't see it, but it's there and it causes a DOI validation error.
The character in line 20 of your script is the Zero-width space.
Trappist the monk (talk) 01:39, 3 October 2015 (UTC)
This MOS section may provide some guidance. – Jonesey95 (talk) 01:30, 3 October 2015 (UTC)
Wikipedia:Manual of Style/Text formatting#Private Use Area and invisible formatting characters?
Trappist the monk (talk) 01:42, 3 October 2015 (UTC)
Here's a possible solution for three of the characters:
  • Title with � character. 
  • Lorem​Ipsum with ZWS. 
  • Margaret­Are­You­Grieving with SHY. 
The test loops through all of the parameters in a template and tests each for all three. If a 'bad' character is found in a parameter, subsequent tests are not performed on that parameter. Is there a better error message? Yes, it needs proper formatting, I'll get to that.
  • Lorem​Ipsum. Margaret­Are­You­Grieving with SHY. 
Trappist the monk (talk) 12:50, 4 October 2015 (UTC)
Expanded a bit so that the test finds most of the C0 and C1 control characters
  • Lorem Ipsum with HT.  – a horizontal tab (might be best to split HT, LF, and CR into separate test)
  • U+008F between dots ..  – SS3 (single shift three)
  • Lo�rem Ipsum with BEL.  – either Lua or mediawiki replace most C0 controls with the replacement character when the citation is rendered so the test for the replacement character thinks that the string is good.
{{cite book/new |title=Margaret
  • Margaret Are You Grieving.  – each word of the title is on a different line
Trappist the monk (talk) 13:17, 5 October 2015 (UTC)
I don't think there is anything wrong with having tab characters or line breaks in citation parameter text, as long as they do not break the rendered citation. People are used to the idea that white space of various sorts is rendered as a single space, and in this case, it looks to me like a case of "it ain't broke, so don't fix it". – Jonesey95 (talk) 14:09, 5 October 2015 (UTC)
Removed, but I'm not sure that they should be. The undetected and so uncorrected C0 control characters are included in the metadata. Here is the multi-line Margaret Are You Grieving example:
<cite class="citation book">''Margaret Are You Grieving''.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
Something else has changed. When I first wrote it, the Lo�rem Ipsum with BEL test above did not render with the replacement character and showed the correct C0 controls error message. Now I can't insert the BEL character (or any other C0 control) without it is replaced. I'll leave the test in the code.
Trappist the monk (talk) 12:12, 6 October 2015 (UTC)

Citing catalogs and similar materials[edit]

What would be the best template for a product brochure? It's not really a book, and it's not really a techreport. Maybe I'm splitting hairs, or maybe there's the perfect template for this? Maury Markowitz (talk) 11:51, 2 October 2015 (UTC)

One cite episode template with multiple errors, none detected[edit]

I found the following {{cite episode}} template in Las Balsas:

Cite episode compare
{{ cite episode | network=[[BBC]] | series=Witness | time=08:50 GMT | airdate=2014-01-02 | minutes=11 | title=The Longest Ever Raft Journey | credits= | url= | station=[[BBC World Service]] | serieslink= }}
Live "The Longest Ever Raft Journey". [[7]]. 2014-01-02. 11 minutes in. BBC. BBC World Service. 
Sandbox "The Longest Ever Raft Journey". [[8]]. 2014-01-02. 11 minutes in. BBC. BBC World Service.  Check |series-link= value (help); More than one of |minutes= and |time= specified (help)

  • Both |minutes= and |time= are used, but in the documentation and the rendering, they are mutually exclusive. Should we emit a redundant parameter error?
  • The |serieslink= parameter should contain a wikilink, but it contains a URL, which breaks the rendered value of |series=. We already emit errors for errors like this in |author-link=. Should we check this -link parameter as well? – Jonesey95 (talk) 13:47, 2 October 2015 (UTC)
I've added redundant parameter error checking for |time= and |minutes=.
Also added a wikilink/url check similar to the |author-link= check to |series-link=. Should probably add checks for |title-link= and |episode-link=. That done, we should probably create a single error message/category pair for these kinds of errors to also include |author-link=, |editor-link=, and |translator-link=.
Trappist the monk (talk) 21:40, 2 October 2015 (UTC)
I agree with expanding this check to all "-link" parameters. I think that a simple "Check |editor-link= value" or "Check |title-link= value" should work as an error message. The current category is called Category:CS1 errors: authorlink. We could call the replacement category Category:CS1 errors: link, which is a bit obtuse, or perhaps Category:CS1 errors: invalid link. Modifying the documentation should be straightforward. – Jonesey95 (talk) 23:49, 2 October 2015 (UTC)
It should not be marked as any kind of error to supply a valid redlink for one of these parameters. But as long as the error checker is only looking for things that are formatted as urls rather than wikilinks. it should be ok. —David Eppstein (talk) 23:53, 2 October 2015 (UTC)
As far as I know, no one has ever suggested testing wikilinks for color. The test is looking for wikilink markup in a |<param>-link= parameter because that extra markup breaks rendering of the link:
{{cite episode/new |series=Series |series-link=[[Las Balsas]]}}
[[Las Balsas|Series]].  Check |series-link= value (help)
Trappist the monk (talk) 00:23, 3 October 2015 (UTC)
Ok, but that's a different error than the one Jonesey95 was talking about, which involved putting a URL in the link field. Those would look more like redlinks except for the URL syntax. —David Eppstein (talk) 00:30, 3 October 2015 (UTC)
I'm confused. In the example at top, the error message is present because the assigned value is a url:
My example above shows the error because of the wikilink mark up. Both of these are the same as the errors displayed when |author-link= contains a url or wikilink markup which is, I think, the error that Editor Jonesey95 was talking about, is it not? Is it even possible to get a red external link (without applying special styling)?
Trappist the monk (talk) 00:48, 3 October 2015 (UTC)
David Eppstein: Nobody is suggesting here that we check for non-existent WP article names in |whatever-link=. We are simply talking about applying the existing |author-link= check (for // and [[*]] ) to other -link parameters. The checking code in question is: if is_set( and ((nil ~="//")) or (nil ~="[%[%]]")))
As you can see in my example above (copied from an actual article), the series link is rendered as|Witness, which is clearly not the intent of the original editor. The new test will put these broken links in an error category so that we can fix them and help readers and editors find sources. – Jonesey95 (talk) 02:11, 3 October 2015 (UTC)
You know we have an article en://, right? (Well, it's a dab, but it could be an article.) Also en://Hus and a few dozen redirects [9]. How are we going to link to these after this test is made? —David Eppstein (talk) 04:09, 3 October 2015 (UTC)
Link to en:// from |editor-link=? Let's resolve that edge case when it occurs. – Jonesey95 (talk) 13:40, 3 October 2015 (UTC)
Percent encoding:
{{cite episode/new |series=// |series-link=:en:%2F%2F}}
Trappist the monk (talk) 19:41, 3 October 2015 (UTC)
That is a gross hack. Percent encoding has nothing to do with whether something is a valid URL (the same URL with slashes percent-encoded still works equally well) nor whether something is a valid wikilink. Presumably the intended meaning is "this text is unterpreted unusually so I'm going to encode it unusually" but the encoding and the semantics are otherwise unrelated. It amounts to leaving an undocumented back door in the pattern matching code (that it doesn't know how to match patterns in strings when the strings happen to be percent-encoded) with the intention of using that back door when we need to bypass the code, and hoping that some future software maintainer doesn't clean up the code to make it handle strings with different encodings more smoothly. —David Eppstein (talk) 19:57, 3 October 2015 (UTC)
Yep, this text is [i]nterpreted unusually so I'm going to encode it unusually. Not so much different from the requirement to use these replacements in urls:
sp " ' < > [ ] { | }
 %20  %22  %27  %3c  %3e  %5b  %5d  %7b  %7c  %7d
I'm all ears. If you have a better solution, tell us.
Trappist the monk (talk) 11:48, 4 October 2015 (UTC)

It occurs to me to wonder if we shouldn't refine the url test to look for a dot somewhere in the hostname. MediaWiki is confused by:


so editors must use interwiki notation:


To Module:Citation/CS1 en://hus looks like a valid url (though MediaWiki sees that it isn't):

{{cite book |title=Title |url=en://hus}}
[en://hus Title]. 

IPv4 in dot-decimal notation ( and domain names ( are hostnames with dots. IPv6 syntax is different and (at the moment) I can find no use of it as a link in en:wp. Looking for the dot that separates IPv4 elements or domain-name labels will identify and flag |url=en://hus as malformed. Looking for the dot will not identify |title-link=en://hus as an error. Looking for the dot is no help when |title-link=//hus; MediaWiki will still be confused.

Trappist the monk (talk) 13:05, 6 October 2015 (UTC)

{{cite book/new |title=Title |url=en://hus}}
[en://hus Title] Check |url= scheme (help). 
and a variety of other conditions:
pass protocol relative with dot. 
fail protocol relative without dot Check |url= scheme (help). 
[/ fail path only with dot] Check |url= scheme (help). 
[ fail labels only with dot] Check |url= scheme (help). 
pass scheme; hostname with dot. 
fail scheme; hostname without dot Check |url= scheme (help). 
[8ttp:// fail bad scheme; hostname with dot] Check |url= scheme (help). 
If this change is to be kept, it will be necessary to change the error message.
Trappist the monk (talk) 14:52, 6 October 2015 (UTC)
These look like reasonable tests. How about "check url= value" for an error message? That matches some of our other error messages. – Jonesey95 (talk) 21:25, 6 October 2015 (UTC)

I've created a new function that does this:

  1. checks |<param>-link= for illegal article title characters per WP:TSC
  2. looks for text that precedes a colon that could be a scheme
  3. looks for text that could be a protocol relative url
  4. inspects what should be the hostname for character or digit, dot, character or digit

See Editor Jonesy95's example. Here are others using |author-link= (same code as |series-link=):

Abraham Lincoln. Pass, proper usage.  – expected use
[[Abraham Lincoln|Abraham Lincoln]] Check |author-link= value (help). Fail, wikilinked. 
[[Abraham Lincoln|Abraham Lincoln]] Check |author-link= value (help). Fail, attempt to ext-wikilink to author's website. 
[Abraham Lincoln|Abraham Lincoln] Check |author-link= value (help). Fail, attempt to use plain url with scheme and author name. 
Abraham Lincoln Check |author-link= value (help). Fail, attempt to use author name and plain url with scheme. 
[Lincoln] Check |author-link= value (help). Fail, attempt to use plain url with scheme. 
[Lincoln] Check |author-link= value (help). Fail, attempt to use protocol relative url. 
[Lincoln]. Fail, link to //hus. 
Abraham Lincoln. Pass, link to en://hus. 

Still to do is |title-link= and |episode-link=. All of these should share the same error message and category so I'll think about that as well.

Trappist the monk (talk) 23:42, 6 October 2015 (UTC)

Referencing foreign language programs with English captions to be CS1 compliant[edit]

In referencing television episodes, I sometimes have to deal with cases where the episode is dubbed in a non-English language but presented with captions in English, but putting "language=Japanese with English subtitles" raises a problem with CS1. What would be the CS1-confirming way to describe that? "language=Japanese, English"? This would be for cases where the caption presented is important to the reference. Similarly what if I want to reference a program in which the English caption presented is different from the English that is said? This assumes the captions are pre-loaded for the broadcast and not transcribed on the fly. AngusWOOF (barksniff) 18:15, 4 October 2015 (UTC)

|language= is used for categorization so extraneous text confuses Module:Citation/CS1. |language= merely indicates which languages a source uses, not how they are used. As to which language should come first in your example, |language= doesn't care so it is up to you to decide whether you emphasize one language over the other by the order in which they appear in the rendered citation. You might consider |type= to point to the subtitles:
{{cite episode |title=Title |series=Series |language=en, ja |type=subtitles}}
"Title". Series (subtitles) (in English and Japanese). 
For the case where closed captioning is different from the spoken word: find a better source? Inaccurate transcriptions of the spoken word are inaccurate; they are the result of an editorial process gone awry either by omission or commission. Where this occurs, perhaps the best course is to use |quote= to include both an accurate transcription of the audio and an accurate transcription of the closed caption. Or find a better source.
Trappist the monk (talk) 11:48, 6 October 2015 (UTC)