Help talk:Citation Style 1

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


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

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
The arguments are good and thought out on both sides of the question. The support argument is that style guidelines like MLA and Chicago suggest italics and standardization of articles on WP. The oppose argument is that it should be up to the editors or that its not needed. The two sides are almost dead even, so this RFC is closed no consensus. There was also a tangent into work vs website that didnt come to any conclusion. AlbinoFerret 15:26, 27 October 2015 (UTC)

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)

Comments re misrepresentation, "smokescreening", etc.[edit]

I have split off the following comments as they only rehash what has been said above (or in the previous discussion) without adding anything new (to date) on the question of the RfC ("Italics or Non-Italics ..."). ~ J. Johnson (JJ) (talk) 21:34, 7 October 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)
Your comment of 21:56, 30 September 2015: "And as I have also previously said, no one is forcing you to use 'website='..." And as I replied, "I never said anyone 'is forcing you to use "website=" ' ". And that is your smokescreening. I'll explain again: 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. No one is "forcing" them, but the definition of "website" directs them to do so. (And the only time I used the word "force" is saying that the "website=" field is coded to force italics, which it does.)
It's blatantly obvious that "website" is a poor name for the field since it communicates something unintended — and I say this as an editor, journalist and author of over over 35 years. --Tenebrae (talk) 18:53, 7 October 2015 (UTC)

I have repeatedly objected to Tenebrae's misrepresentation of my views, which he has rejected as "smokescreening". Before I take this elsewhere would anyone else care to offer any comments? ~ J. Johnson (JJ) (talk) 21:37, 7 October 2015 (UTC)

And I object to J. Johnson's refusal to respond to my repeated statement that if you call a field "website", editors will put the names of websites in it — whether a particular website should be italicized or not. The field's name is needlessly misleading. If we're going to have a field that forces italics, logic demands it be called something other than "website". --Tenebrae (talk) 19:54, 8 October 2015 (UTC)
Wrong again. I originally addressed this point at 00:18, 18 Sep {"The whole problem here...."). You subsequently raised it at 21:29, 20 Sep, and I responded again at 22:49, 21 Sep. Your premise is false. ~ J. Johnson (JJ) (talk) 01:00, 9 October 2015 (UTC)
  • Sigh*. No. at 00:18, 18 Sep, you say "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=. ... and incidentally: RT is a website, and the publisher is probably Flixter, Inc.). ... 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."
So it appears we agree that the confusing parameter "website=" should be removed. And when I agree, you turn and disagree. As well, I agree with your statement that "some editors thinking |website= encompasses all websites, including those that are not 'works' ". So we're agreed that editors will place websites into a field called website=, which forces italics, even though not all websites should be italicized (such as Rotten Tomatoes and Grand Comics Database).
Yet that's not addressing the issue, but only the underlying reasons. The issue is: If the field website= forces italics on non-italicized websites, then why do we force that? Would it not make more sense to make the field non-italic and let editors quite easily italicize those websites which need it? --Tenebrae (talk) 05:14, 10 October 2015 (UTC)
No, we do not agree. I said that if the proper use of this parameter was too difficult for general understanding then perhaps this parameter should be removed. Perhaps you missed the conditional nature of "if" and "perhaps"? Would more emphasis and/or highlighting be useful? Or superfluous?
Passer-bys might note that I have opened a report at WP:ANI#User:Tenebrae. ~ J. Johnson (JJ) (talk) 20:46, 10 October 2015 (UTC)
Yes, where other editors commenting disagree with him and his belittling and inaccurate characterization of me and my position. I urge all editors to go read what they have to say, and J. Johnson's defensive reply that those editors must be wrong as well for not agreeing with him.
And his uncivil sarcasm and patronizing tone in his most recent post here aside, editors logically will place place websites into a field called website=. The field forces italics, even though not all websites should be italicized (such as Rotten Tomatoes and Grand Comics Database). So I'm not sure how "website=" is the best of all possible things to call the field. Is there really no other term whatsoever for a field that italicizes, when not all websites are italicized? No other, clearer term whatsoever?--Tenebrae (talk) 18:08, 11 October 2015 (UTC)
No, I believe sarcasm would be more in the nature of noting that your repeated reference to plural "editors commenting" at the ANI, when (so far) there is only one such editor, reflects either a failure to understand the plural form despite 35 years of editorial experience, or a failure to count. But leaving aside any such imputations, the mere existence of such a simple error seems an accurate characterization of your frequently inaccurate comprehension. ~ J. Johnson (JJ) (talk) 20:23, 11 October 2015 (UTC)
Oh, yes, heaven forfend that I skimmed something that needlessly and purely vindictively was taking up my time. Oh, the horror.
But I'm not surprised at such an attitude from an editor who tells others on his talk page: "your delusions tiresome, and your general incivility unwelcome. Please do not waste any more space here on such puerile comments." Despite his use of an incomplete sentence, incidentally, you don't see me accusing him of "a failure to speak proper English." We all know people like this who routinely insult others ... and we know what drives them to do it and how seriously to take them.
By the way, a second editor at the ANI has now taken J. Johnson to task, so "editors" plural is certainly accurate now.
And getting back to the point of this RfC: The MOS plainly states not all website names are italicized in footnotes. Nonetheless, the field "website=" forces italics. So that goes against the MOS and, I believe, common sense. Nonetheless, I suggested a compromise: Change the name of field from "website=" to something more accurate. But some people refuse to ever compromise. And we all know people like that. --Tenebrae (talk) 17:39, 12 October 2015 (UTC)
Actually, looking at my ANI comments again, I said, "As other editors note...." I didn't say as "As other editors note here on this page." So "editors" plural was indeed correct. "[A] failure to count" — wow, another inaccurate and unnecessary personal attack. At least he's not calling me delusional and puerile, as he's done with at least one other editor. --Tenebrae (talk) 17:45, 12 October 2015 (UTC)
Oh, I thought we were talking about sarcasm and what it might look like. (Sorry, but sometimes a little emphasis really is needed to avoid ambiguity.) Certainly my previous comment asking if you had missed the conditional nature of a prior comment hardly qualifies. As to the entirely hypothetical question of whether you can count: I expect you can count, and that your miscount – and despite your ex post facto revisionism it was, at the time you wrote it, a miscount – was only a minor slip. (And possibly no big deal.) What is quite telling here is how you try to justify your statement by invoking an unexpressed condition ("not: here on this page"), yet you are so careless of my explicit (and bolded) "if". As to your other rhetorical devices (specifically the unuseful one of namecalling): I have never called you delusional. Nor even ridiculous, although you have persistently insulted me with that and other disparaging terms. I will call you careless, as that seems amply demonstrated. And seems to be the grounds of most of your complaining. ~ J. Johnson (JJ) (talk) 23:37, 13 October 2015 (UTC)
Oh, please. Would you just listen to yourself. Do you have any idea how you sound? RE: "I have never called you delusional." Who's being careless now? I never said you did — and you know I did not, yet you set up a red herring to take down. You know very well I was referring to your comment to "Pete" here.
But getting back to the point: You don't want to non-italicize a field ("website=") that should not automatically italicize. I disagree, but fine. I am completely puzzled, however, that you won't even address a compromise that, seemingly in line with your own comments, would make sense: Since not all websites should be italicized, calling the field "website=" is inaccurate — and at the very least is not the best, least confusing, most optimal name for the field. I have to wonder why anyone would be so adamantly wedded to that word when a word that suggest italics always would be more accurate.--Tenebrae (talk) 18:12, 14 October 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Please stop. Both of you. – Jonesey95 (talk) 03:42, 14 October 2015 (UTC)

I agree with the sentiment. If I could suggest, then, perhaps other editors might comment on the compromise proffered? --Tenebrae (talk) 18:33, 14 October 2015 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

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)

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.  replacement character in |title= at position 12 (help)
  • Lorem​Ipsum with ZWS.  zero width space character in |title= at position 6 (help)
  • Margaret­Are­You­Grieving with SHY.  soft hyphen character in |title= at position 9 (help)
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.  zero width space character in |author= at position 6 (help); soft hyphen character in |title= at position 9 (help)
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.  horizontal tab character in |title= at position 6 (help) – a horizontal tab (might be best to split HT, LF, and CR into separate test)
  • U+008F between dots ..  C1 control character in |title= at position 22 (help) – SS3 (single shift three)
  • Lo�rem Ipsum with BEL.  replacement character in |title= at position 3 (help) – 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.  line feed character in |title= at position 9 (help) – 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> <span style="font-size:100%" class="error citation-comment">line feed character in <code style="color:inherit; border:inherit; padding:inherit;">&#124;title=</code> at position 9 ([[Help:CS1 errors#nonprint_char|help]])</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)
Because of the metadata issue, I have restored HT, CR, and LF detection. Also added Unicode Private Use Areas detection:
Margaret AreYou Grieving.  Private use area character in |title= at position 13 (help)
Margaret Are󰃿You Grieving.  Supplementary Private Use Area-A character in |title= at position 13 (help)
Margaret Are􀃿You Grieving.  Supplementary Private Use Area-B character in |title= at position 13 (help)
Trappist the monk (talk) 11:41, 10 October 2015 (UTC)

I just found this character:  in George Mason. I don't know what it is, but I don't think it has a use in citation templates.

Example template using the sandbox: George  Mason.  Specials character in |title= at position 8 (help)

Looks like it is not part of the character groups we are searching for yet. – Jonesey95 (talk) 15:09, 24 October 2015 (UTC)

U+FFFC, object replacement character, part of Specials (Unicode block). Now detected.
Trappist the monk (talk) 15:30, 24 October 2015 (UTC)

I have given this group of errors an error message that fits in form and function with the other error messages that cs1|2 emit. The error category is Category:CS1 errors: non-printable characters.

I have also tweaked the detection code a bit because, formerly, it used a for char, pattern in pairs (cfg.nonprint_chars) do construct. While that works, the order of the values returned by pairs () is arbitrary. By tweaking the code to start at the top of cfg.nonprint_chars and work down, we can check first for single characters (the replacement character for example) that are also members of the larger set of characters detected later (replacement is a member of Specials).

Trappist the monk (talk) 16:57, 30 October 2015 (UTC)

What is the best way to include a long quote in a citation so it displays an abbreviated form by default?[edit]

I was writing this and realized that if I want to include a long quote in a reference but doing so would make the reference look "ugly," I didn't know the best way to do it.

Ideally, I would use an "inline expansion template" within |quote= so the quote would be clickable/touchable/mouse-over-able and when the reader clicked/touched/moused-over the abbreviated quote the full quote would appear, but I'm not aware of any such template.

Maybe something like

*{{cite work
|url=|title=Constitution of the United States of America
|quote= We the people...this constitution of the United States of America{{Fix
 |text= full quote
 |title= We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.

which produces

My main concern is that this probably won't work with mobile and blind users who may not be able to "hover over".

My secondary concern is that the "fix" template isn't meant to be called directly and it's "link to" and "categorization" elements aren't really applicable here. Ideally there would be a standardized way of doing an abbreviated in-line quotation that expands when the user asks it to, and that method could be documented in the documentation pages for the Citation Style 1 templates.

The other option of using a <ref group=expand></ref> and {{reflist|group=expand}} within another reference is just plain awkward-looking - it's like having footnotes within footnotes.

Ideas anyone? davidwr/(talk)/(contribs) 16:50, 10 October 2015 (UTC)

I think that quotes in citations almost always look ugly regardless of length. Perhaps it is better to put the long quote in a footnote – perhaps with {{efn}} and then cite that:
Example article text that refers to a footnote.[a]
  1. ^ Here in the footnote we have the quoted text and a reference that supports it:
    "We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America."[1]


  1. ^ Constitution of the United States of America. (subscription required (help)). 
I added |subscription=yes to my example because if one is to use the title attribute in some template intended to be placed in |quote= it should stylistically resemble the pseudo-help link following the 'Subscription required' text. I think that the accessibility issues you mentioned argue against the use of such a template.
Because {{abbr}} uses the <abbr>...</abbr> tag, using that template to make tool tips from long strings of text that are not expansions of abbreviations or acronyms violates the tag's particular semantic meaning.
Trappist the monk (talk) 17:27, 10 October 2015 (UTC)
I was going to say about the same thing as Trappist, though not as well. Separate the quotation from the citation. I find that quotations within citations just get lost in the jumble of dates, italics, and author initials. – Jonesey95 (talk) 00:07, 11 October 2015 (UTC)
It's not just that "quotes in citations almost look ugly", they are somewhat immiscible. It seems that the intention of having a quote in a citation is to provide the exact text of a point that is being paraphrased in the article. I allow that can be useful in the WP context, but a citation (precisely, a full citation that identifies a source) is the wrong place. Where quotation of a passage, or any other comment about it, is useful, it should be treated like page numbers or any other information pertaining to specific passage: following the citation. I suspect many WP editors are confused about this because they often cite only a single passage in a source, and tend to incorporate the specific details into the full citation. Not only should the quotation be separate from the citation, I think we should be deprecating |quote=. ~ J. Johnson (JJ) (talk) 21:15, 11 October 2015 (UTC)
I completely disagree. Separating detailed locations within a source from the general reference information about the source can be a good thing to do in longer articles that re-use some of the same sources many times, but we should not force editors to do that. And when we have a source that is used only once, for a specific passage, a brief quote from the passage can be very helpful in making the source verifiable especially when the actual content is paywalled. Logically, your reasoning would lead us to deprecate |pages= on templates like {{cite book}}; I hope you can see how stupid an idea that would be. —David Eppstein (talk) 21:52, 11 October 2015 (UTC)
Re: paywalled sources and using quotes for verify-ability - yes yes yes this, along with making it easier for future editors to verify hardcopy references and references likely to suffer bitrot, are the primary reason I use long quotes in references. I do see the point about splitting them off if the same basic source is used many times (similar to Template:rp), but that's not the common case for things I edit. davidwr/(talk)/(contribs) 23:09, 11 October 2015 (UTC)
Both of you, please: you misunderstand what I said. I have absolutely no objection to using quotes for the purpose you describe. My objection is to using the |quote= parameter for that purpose. E.g., instead of doing something like
  • <ref>{{cite work ... |quote= We the people ...}}</ref>
we should do
  • <ref>{{cite work ...}} "We the people ..." </ref>.
That is, quotation outside of the cite template, but in the footnote. Okay? ~ J. Johnson (JJ) (talk) 22:51, 12 October 2015 (UTC)
But then when we use {{harv}} and |ref=harv the quote will be outside of the highlighted citation. —David Eppstein (talk) 23:05, 12 October 2015 (UTC)
No problem. "{Harv ...}" is a straight substitution for "{cite work ....}". E.g.:
  • <ref>{{harv ...}} "We the people ..." </ref>.
The "highlighted citation" you refer to – that would be the little drop-down box that appears when you mouse-over the hyperlink to the note? That actually includes the entire contents between the ref tags. For an example see note #12 (and others) at Leech River Fault: two Harv short-cites and a comment that includes a direct quote. Does that work for you? ~ J. Johnson (JJ) (talk) 00:04, 14 October 2015 (UTC)
No, that is not what I mean. I mean that if you use {{harv}} or its relatives somewhere in an article, and one of the CS1 templates with |ref=harv elsewhere in the article, the {{harv}} citation is shown bluelinked. If you click on the bluelink, the article scrolls to the CS1 citation that it corresponds to and highlights it. In some cases you might not want the quote to be highlighted (for instance, if the {{harv}} link is part of a reference that uses a different passage from the same book) but in other cases the quote should be highlighted, and the only way to achieve that is by including the quote in the actual citation template. —David Eppstein (talk) 00:19, 14 October 2015 (UTC)
Oh. Well, then I don't understand what you are talking about. Could you point out some examples? ~ J. Johnson (JJ) (talk) 00:29, 14 October 2015 (UTC)
Look at Riemann hypothesis. Notice that it uses parenthetical referencing (a valid and accepted Wikipedia style) rather than footnote referencing. (It also uses CS2 instead of CS1 but that makes no difference to any of this.) Click on any short reference in the text. Your browser should go to the corresponding long reference in the reference list and highlight it in a light blue color. Now notice that a couple of the references include quotes, including Radziejewski (2007) and Rosser et al (1969). The short (inline) reference to Radziejewski can be found in Riemann hypothesis#Montgomery's pair correlation conjecture. If you click on it, the whole reference, including the quote, is part of the light blue highlighted region. That would not be possible under your proposal. —David Eppstein (talk) 01:29, 14 October 2015 (UTC)
Not so much "not possible" as just not done. But so what? What is highlighted is the full citation itself, rendered as the anchor of the hyperlink. And I would say that is proper. Citations are compact and concise, and any kind of quotation confuses that. Not highlighting the quotation clarifies the citation, and does nothing to diminish the quotation. In what cases would you want the quote to also be highlighted, and why? ~ J. Johnson (JJ) (talk) 05:21, 15 October 2015 (UTC)
It should be highlighted because it is part of the full reference that one wants readers to see when they click on the short reference. Just like a quote in a footnoted reference should be part of the pop-up the readers see when they hovers over a footnote mark. Or do you want to damage that functionality too? —David Eppstein (talk) 05:28, 15 October 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── What I have suggested does not damage any functionality (as far as I see it). I am wondering about what particular kind of functionality you think you need. Note that you are mixing two different - albeit very similar - things here. In a footnoted reference the superscripted, bracketed number (e.g.: [1]) is a link to everything that was placed between <ref>...</ref> tags. By virtue of magical software hovering over the link produces (but perhaps not on the Talk page) the little pop-up box with the contents of the <ref>...</ref> tags. Which contents can be citations - or quotations, comments, whatever. In this case taking a quotation out of a citation makes no difference at all in this display functionality as it acts on the contents of the ref tags as a whole. (See Leech River Fault for examples.)


  1. ^ Citation: Smith (1900), Title . "Quotation outside of template." Comment.

In the second case ("Harvard" parenthetical style as seen at Riemann Hypothesis) the in-line link is produced by a Harv template, and hovering over it does not generate a pop-up box. When you click on the link the target you go to is the citation, embedded in the adjacent text. The only difference (from the pov of display) between having a quotation inside the citation or following it is whether it is highlighted. E.g., compare these two links:

No pop-up boxes, that is the inherent functionality of Harv, but once at the target readers see everything, including what is outside of the citation template. Is there some functionality you have in mind that I have missed? ~ J. Johnson (JJ) (talk) 22:51, 15 October 2015 (UTC)

David Eppstein: comment? I think I have shown there is no loss of functionality in not using 'quote='. Is there anything I may have missed? ~ J. Johnson (JJ) (talk) 22:07, 19 October 2015 (UTC)

Yes. You have missed that when the quote is not highlighted, it is seen by readers as not being part of the citation, when it should be treated as part of the citation and should be highlighted. What part of this is hard to understand? —David Eppstein (talk) 01:06, 20 October 2015 (UTC)
David, getting snippy is not useful. What is hard to understand here are the parts that you don't fully explain. I am trying to work out exactly what you mean, what you want, and even why you want it. My understanding (currently) of what you want is that when the reader clicks on a Harv-style link (such as Odlyzko 1992a) and lands on the target the quotation is highlighted as well as the citation. (Right?) This would be similar to the effect when using the <ref> tags where the entire note is highlighted.
Our key difference here is where you think the quotation "should be treated as part of the citation" (and thus highlighted). My objection is that quotations are not part of any citation. (Obviously!) But before we run off about that, please note that we can finesse this particular point by replacing your reference to "citation" with "note". That is, that you want to highlight both the citation (as I narrowly define it) and the quotation associated with it, in the manner seen when using <ref> tags. Whether that is a reasonable expectation is still open, but with this understanding we avoid my objection and therefore have scope for discussion. Is that acceptable? ~ J. Johnson (JJ) (talk) 23:08, 21 October 2015 (UTC)
David? I am interested in what you think. ~ J. Johnson (JJ) (talk) 19:13, 24 October 2015 (UTC)
I have already told you what I think. Anything more is just tedious wikilawyering. —David Eppstein (talk) 19:57, 24 October 2015 (UTC)
No, it is not wikilawyering, it's figuring out what you want, and why, when you told it poorly. Anything less is just subjective like/dislike, deserving no argumentive weight. I am disappointed, but so be it. ~ J. Johnson (JJ) (talk) 21:18, 26 October 2015 (UTC)

Template:Cite journal[edit]

Accordingly, "This Citation Style 1 template is used to create citations for articles in magazines, journals, newsletters, and for academic papers." Is this only true for printed articles? For instance, not all news articles on Billboard got covered on the magazine's print version. Should we use cite news instead of cite journal? Another. Should we use cite journal for this chart history?--Efe (talk) 20:44, 10 October 2015 (UTC)

The term "journal" is ambiguous. It can mean any periodical loosely (see Journal), but tends to be used more in the sense of scientific journal or academic journal. Given the existence of {{cite news}} and {{cite magazine}}, I think {{cite journal}} should be more narrowly restricted. Even though the initial sentence there is permissive, a narrower usage seems preferable, as otherwise there is a suggestion of greater authority than may be warranted.
As to to situations where a newspaper or magazine have both print and on-line versions, which are not entirely identical, it might be useful to restrict 'cite news' and 'cite magazine' to the print version, and use 'cite web' for the on-line version. Come to think of it, some journals also have "enhanced" editions on-line. Hmmm, I think this question just flooded my waders. ~ J. Johnson (JJ) (talk) 22:27, 10 October 2015 (UTC)
Use what you think makes sense. {{cite web}} is fine for pretty much anything that appears on the web.
Note that {{cite magazine}} is an alias for {{cite journal}}.
P.S. I have fixed the grammar in the sentence quoted above. – Jonesey95 (talk) 00:12, 11 October 2015 (UTC)
Hello. Thanks for the clarification. --Efe (talk) 14:40, 11 October 2015 (UTC)
I have tweaked that initial sentence. Hopefully that is a smidgin closer to perfection. ~ J. Johnson (JJ) (talk) 00:13, 14 October 2015 (UTC)
Is this allowed: cite magazine |magazine= cite newspaper |newspaper? I personally do not support the idea of using cite journal for magazines such as Billboard. Thanks. --Efe (talk) 12:41, 31 October 2015 (UTC)

How to resolve external link errors without work-url= or journal-url=?[edit]

Now that the CS1 module revision of a couple of weeks ago has had time to work through all or most of Wikipedia, we can see how many new errors were picked up by the changes. The three categories that saw the most changes were the "missing author" category (due to an error that stopped being detected in a previous revision and is now detected again), the "URL errors" category (in which there is a lot of cruft in the |url= parameter), and the "external links" category.

I'm seeing a large number of articles in Category:CS1 errors: external links that are caused by editors wanting to link |work= or |journal=, or their aliases, to an external URL. The current Help page text for this error condition says:

External link in |<param>=

This error occurs when any of the CS1 or CS2 citation title-holding parameters – |title=, |chapter=, |work= or any of their aliases – hold a properly formatted external link (URL). External links in these parameters corrupt the citation's metadata and can be the source of a variety of other error messages.

To resolve this error, remove external link syntax and put the url in the appropriate parameter (|url=, |chapter-url= etc.).

I have had no trouble fixing this problem when there was an external link in |title= or |chapter=, but I am at a loss as to what to do when there is an external link in |work=, |journal=, or their aliases.

Here are some examples from actual articles:

There are also templates that have links in |work=, such as {{Australian Wetlands Database}}, {{Cite AHPI}}, and {{Cite Monumentenregister}}.

What should our advice be? Should there be a |work-url= or |journal-url= parameter? – Jonesey95 (talk) 03:45, 12 October 2015 (UTC)

My view is that there should never (or almost never?) be the need for an external link in the |work= or |journal= fields. In the first example, the required parameter is |url= which links to the correct volume of the 'journal'. In the second of your two examples above, the journal link is simply unnecessary – the reference is to the article, not the journal. So in my view the citations should be:
(A few other changes have been made above: separating the fields of |author= and treating "Spring 2004" as a issue indicator not a volume.) Peter coxhead (talk) 09:23, 12 October 2015 (UTC)
Is there a policy or guideline that backs up your view? I'm just asking, not trying to be confrontational. I have a feeling that if I started removing these links, editors would complain that I was removing useful information that was not harming anyone.
I feel like I have seen some guidance that explains that it is OK to link to a larger work if the link serves to explain where the link to the source comes from, but I can't find that guidance now. – Jonesey95 (talk) 14:32, 12 October 2015 (UTC)
Policy doesn't support many of the restrictions in the citation templates. WP:CITEVAR is regularly invoked by editors or groups of editors to defend their right to format references virtually however they like. So I think the real issue is different: what should the citation templates support? I can only say that I see no case for them to support external links to works or journals. If editors want such links, then they can always use manual citations. Peter coxhead (talk) 15:12, 12 October 2015 (UTC)
There is this from Help:Citation Style 1#Work and publisher:
If the "title" is already linked to externally, do not externally link to the "work".
Trappist the monk (talk) 15:21, 12 October 2015 (UTC)
Suppose that we wish to cite an article in an online newsletter. Suppose also that (as often happens) the whole issue of the newsletter containing the article is available as a pdf file from the publisher's web site, but the individual article is not available as a separate download. Where, in your view, should the url for the issue of the newsletter be linked within the citation? If you rule out links on |work= or |journal=, the only choice is on the article title, but in that case we have a misleading link: readers who click on the link will be expecting the individual article and get something else. —David Eppstein (talk) 00:25, 14 October 2015 (UTC)
You don't have a choice, unless you want to extract the article in question and host it yourself, an activity of dubious legality in many cases. Put the URL for the whole PDF in the |url= parameter, just as we do with a journal article or a report or any other long document, and then use |page= and |title= (and |author=, if applicable) to guide readers to the correct location within the PDF. There is also a PDF linking trick that works with some browsers. – Jonesey95 (talk) 03:48, 14 October 2015 (UTC)

Per Editor Jonesey95 I have moved this conversation here.

Editor Peaceray posted this on my talk page:

Hi, I have been looking through various Help_talk:Citation_Style_1 discussions in an attempt to understand why having an external link in |work= is now generating an error. I have been populating this parameter with external link for years & just noticed that it now causes an error. It is obvious to me why external links in |title= & in |chapter=, as they conflict with |url= & |chapter-url= respectively. However, there is nothing like a |work-url= for |work= to conflict with. The documentation essentially just says that's the way it is.

I have seen your username all over the discussions at Help talk:Citation Style 1#choosing the correct metadata when |chapter=, |title=, and |work= are all set & Help talk:Citation Style 1#How to resolve external link errors without work-url= or journal-url=?. I am just hoping to get a succinct, coherent explanation why external links in |work= cause a problem.

I am a heavy user of citation templates. I also have been in IT for 25 years & have dabbled in my share of programming languages, so while I may not be familiar with the syntax of modules, I probably get a grasp of a moderately technical discussion.

Peaceray (talk) 21:38, 20 October 2015 (UTC)

You know that the twenty-some cs1|2 templates were created independently. {{citation/core}} was the first real attempt to consolidate them so that they were more stylistically and functionally similar than the original templates. That consolidation is ongoing in Module:Citation/CS1 and is far from complete.

Part of the consolidation that we've accomplished so far is to define a more uniform parameter naming convention. The canonical form of all URL-holding parameters is |<name>-url=. |dead-url= is an exception that still needs to be fixed.

The first mention of any prohibition of external links in |work= and alias parameters, technical or other wise, appears to come with this edit. Those words still exist in Help:Citation Style 1 though not in the same place. There have been requests in the past for the module to flag URLs in |website= because new users confuse |website= with |url=. I'm unable to locate where I read those requests but I am sure that I am not imagining that they were made.

The metadata formatting that cs1|2 uses provides for four general types of citation: book, journal, dissertation, and patent. Our challenge is to somehow shoehorn the twenty-ish cs1|2 templates into those four. In the version of the metadata code that I'm working on now, journal-type metadata are created for:

  1. {{cite arxiv}}, {{cite journal}}, {{cite news}}
  2. {{cite conference}}, {{cite interview}}, {{cite map}}, {{cite press release}}, {{cite web}} when Periodical meta-parameter is set
  3. {{citation}} when Periodical is set but |encyclopedia= is not set

All the rest of cs1|2 create book type except {{cite thesis}} which uses dissertation type. The patent-type metadata are created in the weird hybrid of {{citation}} and {{citation/patent}} and not currently supported by Module:Citation/CS1.

In the creation of the metadata, the value of |work= and aliases (the Periodical meta-parameter) is assigned to the metadata key &rft.jtitle=. That key is defined to be a character string and further defined to be a 'Journal title'.[1] I choose to read that standard strictly, so a URL is not appropriate.

It isn't because of a conflict between |title= and |url= (or the chapter pair). External links in |title= (&rft.btitle=) and |chapter= (&rft.atitle=) have similar metadata definitions so URLs in these parameters are similarly inappropriate.[2]


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

Well, the timing of that edit explains why I was able to go down the path that I did for |work=, since I started 22 months before that, &, as a part-time university reference librarian, definitely read through the citation template documentation of the time as wanted to attend to citations. I probably was obsessive-compulsive about it for awhile & tried to pack as much info in as possible.
Can anyone recommend a semi-automated tool that can help me clean up citations that I made that are now generating this error? I have used WP:AutoWikiBrowser on a couple of occasions for mass changes, but am unsure about its capability for this task.
Peaceray (talk) 22:51, 27 October 2015 (UTC)
AWB can do some very complex things so should be quite up to the task of doing what you want done.
Trappist the monk (talk) 11:24, 28 October 2015 (UTC)

Proposal for more detailed parameters than the catch-all others= parameter[edit]

I would like to propose alternative and more detailed parameters to the |others= parameter, which is currently a "catch all other contributors" parameter. If the |?-first= and |?-last= parameters are used in the remainder of the citation, they cause author and editor names to occur in the order "last, first" by default. It looks odd, if additional contributors listed under |others= still occur in the order "first last". Specifically, I propose the following optional new parameters for illustrators, correctors/pre-publish-reviewers, printers, translators and other contributors (where [?] is an optional number):

|illustrator-first[?]= |illustrator-last[?]= |corrector-first[?]= |corrector-last[?]= |printer-first[?]= |printer-last[?]= |translator-first[?]= |translator-last[?]= |contributor-first[?]= |contributor-last[?]=

At a (much) later stage, the |others= parameter could be deprecated. I'm well aware of the fact that these parameters will remain empty in most citations, but in those cases, where the information is known and presented in the book, it would be very useful to have some more organized means to include the information than possible at present. This would also help to make meta-data parsing more reliable in the future. --Matthiaspaul (talk) 15:53, 13 October 2015 (UTC)

We have |translatorn=, |translator-firstn=, |translator-lastn=, |translator-linkn=, and |translator-maskn=. These were added in a recent update because over the years they have been identified as something that editors wanted. I don't recall seeing similar desire for any of the others. We might alias |contributor= to |author= and we might add |illustrator= if there is sufficient need. How does knowing the 'corrector's' name or the 'printer's' name help readers find a copy of the cited work?
Is there something inherently wrong with keeping the catch-all |others= parameter?
Because |others= is free-form, names can be added to it in last, first order. On the other hand, there are those who believe that only the primary author should be listed last-name-first and all others shold be listed first-name-first.
Trappist the monk (talk) 17:11, 13 October 2015 (UTC)
Thanks for the hint! I wasn't aware of the |translator= group of parameters, they are not currently documented (except for the |translator-mask= parameter.
Regarding the other parameters, I don't see their main purpose in helping to locate a citation, although in some cases (f.e. with strangely formatted historical sources) they might actually help in doing so. The main purpose, as I see it, would be to help build the web and aid further research into a subject. For example, mentioning the various kinds of contributors specifically and in a standardized way would allow for much easier reverse lookup of information. This can be useful when evaluating sources in their historical context, and might reveal collaborations and connections otherwise remaining "hidden".
Regarding changing the order of names in |others= manually. Sure this could be done, but the appearance of citations might change over time as fashions and habits change (think of Wikipedia ten or twenty years in the future). Separate parameters for first and last names allow to change the visual representation of a citation without manually changing the physical wikitext again. At some point in the future it might become possible to select the preferred format of citations or set filter masks in Wikipedia's user configuration (or external "frontends"). So, better to allow editors to provide the information in a universal format right from the start (and with the source still in front of them) than having to manually edit uncountable citations later on (without neither the sources or the original editors at hands to clear up possibly arising questions).
--Matthiaspaul (talk) 22:32, 13 October 2015 (UTC)
I have no problem finding the |translator= documentation at {{cite book}}, {{cite journal}}, {{cite news}}, and {{cite web}}. Where are you looking that you only find documentation for |translator-mask=?
I don't know that build[ing] the web is in the cs1|2 remit. Perhaps that is better left to the time when (if) cs1|2 is somehow integrated with wikdata.
There are editors who have railed loudly against separate first and last parameters for author names. WP:MED uses |vauthors= preferentially to avoid the 'clutter' of last/first parameters.
Trappist the monk (talk) 23:58, 13 October 2015 (UTC)
Regarding (missing) documentation, see: Help:Citation_Style_1
--Matthiaspaul (talk) 08:01, 16 October 2015 (UTC)
Ah, yes that page. I don't know what to say about that page. It is a mix of stuff that rightly belongs there and stuff that is better left to the template pages. In the best of all possible worlds we would blank the page and start over.
Trappist the monk (talk) 11:18, 16 October 2015 (UTC)
I think, the main purpose of the cite templates is to reliably identify and locate a source, but it serves other purposes as well. We even have a range of parameters (like |lay-summary= and friends) helping readers to decide if a source might be interesting at all and worth some further study. In comparison, listing contributors is much more closely related to the original descriptive purposes of the source, but it might also help to pre-evaluate a source.
That's why I think there should be a way to more formally define how this info can be presented than putting it all into the "one-size-fits-all" parameter |others=.
I don't know if this information would ever become part of exported metadata, but if that would be desirable somewhen in the future, certainly it'll be easier to extract and process the info from separate parameters than trying to make sense of a string lumping it all together in the |others= parameter.
--Matthiaspaul (talk) 18:07, 29 October 2015 (UTC)

Date metadata[edit]

I have previously mentioned that I am going to tweak the metadata code to make it more closely reflect the cs1|2 template that is the source. To begin this process I have spent some time tweaking the tables at Module talk:Citation/CS1/COinS. That work is still incomplete.

A read of documentation at OCLC[1] shows that we aren't doing dates correctly. The documentation at OCLC refers to a document at W3C that specifies the use of ISO 8601 date formats.[2]

For dates in the Gregorian calendar converting to ISO 8601 is relatively painless for books because the value expected for & is a year value. For journals, the metadata has (currently unused) keywords &rft.ssn (season keywords: winter, spring, summer, fall), &rft.quarter (quarter keywords: 1, 2, 3, 4 – not currently supported in cs1|2), and &rft.chron (specifically allows more free-form '1st quarter', etc; don't know if it would be ok to use this keyword for season ranges).[3]

Normal Gregorian dates and date ranges can all be converted to ISO 8601. When a date falls in the Julian calendar, ISO 8601 only supports those dates as the parties sharing the date information among themselves agree. Absent such an agreement, and to make life easier (no conversion from Julian to Proleptic Gregorian calendar), I'm inclined provide only the year portion or portions of a single Julian date or date range to the metadata.

This last paragraph is here so that I don't have to go hunting for this preview copy of ISO 8601 again.


Comments or opinions?

Trappist the monk (talk) 16:54, 18 October 2015 (UTC)

I have revised the metadata code in Module:Citation/CS1/sandbox and Module:Citation/CS1/Date validation/sandbox. The date handling part of that revision is illustrated here. In the table below are the standard date formats and the expected translation to the metadata requirements. I'm clear about how most of these date formats should be translated but I'm not so sure about how we should handle season ranges (the yellow boxes in the table). For now, the code includes the yellow-box stuff in the metadata. Should it? Have I got all of the date formats?

Examples showing the new metata date handling are in the collapsed area. I'll address the other metadata changes in another discussion.

cs1|2 to COinS date translation
cs1|2 date format COinS
& &rft.ssn[a] &rft.chron[a]
yyyy-mm-dd yyyy-mm-dd
dd Mmm yyyy yyyy-mm-dd
Mmm dd, yyyy yyyy-mm-dd
Mmm yyyy yyyy-mm
any date format where 1000 ≤ year < 1582 yyyy
any date format where 100 ≤ y < 1000 0yyy
  • yyy–yyy
  • yyy–yyyy
  • yyyy–yy
  • 0yyy/0yyy
  • 0yyy/yyyy
  • yyyy/yyyy
Sss yyyy yyyy
  • winter or
  • spring or
  • summer or
  • fall
Sss yyyy–yyyy yyyy/yyyy
Sss1–Sss2 yyyy yyyy Sss1 keyword? Sss1–Sss2?
Sss1 yyyy – Sss2 yyyy yyyy Sss1 keyword? Sss1 yyyy – Sss2 yyyy?
Christmas yyyy yyyy Christmas
dd Mmm yyyy – dd Mmm yyyy yyyy-mm-dd/yyyy-mm-dd
Mmm dd, yyyy – Mmm dd, yyyy yyyy-mm-dd/yyyy-mm-dd
dd–dd Mmm yyyy yyyy-mm-dd/yyyy-mm-dd
Mmm dd–dd, yyyy yyyy-mm-dd/yyyy-mm-dd
dd Mmm – dd Mmm yyyy yyyy-mm-dd/yyyy-mm-dd
Mmm dd – Mmm dd, yyyy yyyy-mm-dd/yyyy-mm-dd
Mmm – Mmm yyyy yyyy-mm/yyyy-mm
Mmm yyyy – Mmm yyyy yyyy-mm/yyyy-mm
yyyy yyyy
  1. ^ a b journal metadata type only

Trappist the monk (talk) 15:40, 23 October 2015 (UTC)

Trappist the monk's statement "When a date falls in the Julian calendar, ISO 8601 only supports those dates as the parties sharing the date information among themselves agree" is not strictly correct. First, ISO 8601 requires the use of the proleptic Gregorian calendar or Gregorian calendar; the data exchange partners cannot vary this requirement. If they do, their statements that they are using ISO 8601 are falsehoods. Second, ISO 8601 states "Values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange." Thus there are a few months in which the Gregorian calendar is valid but nevertheless agreement among data exchange partners is required to use those months in ISO 8601.
In addition, the templates have no means to designate the calendar (Julian or Gregorian) so any date before Thursday 1 March 1923 has the potential to be Julian. Since the primary language of this encyclopedia is English, it is probable that sources with a date earlier than Thursday, 14 September 1752, are dated in the Julian calendar. Jc3s5h (talk) 16:41, 23 October 2015 (UTC)
That's a curious problem. Questions of which calendar are usually noted in the text. But as metadata?? Does COinS have any provision for specifying calendar? Perhaps other systems, like MARC? While I wonder if there enough cases where someone cites a book published in (say) 1750 that someone else has an expectation of finding at a local library (distinct from a modern edition of such a book) to make this something COinS would trouble with. Are there potential sources published with non-Western dates? A curious problem. But do we need to worry about it? ~ J. Johnson (JJ) (talk) 20:11, 24 October 2015 (UTC)

ISBN formats 10 and 13[edit]

A book I own has 4 ISBNs listed inside the cover and I am not sure which to use. Two say "bound" and the two say "paperback". The cover feels smooth and from my experience with RPGs I believe it is bound so I'll probably go with that half...

The other problem though is that there is also division into either "ISBN-10" and "ISBN-13". I am not sure which of the two we use. The ISBN-13s begin with 978- while the ISBN-10s begin with 1- and Template:Cite book includes examples of both. How do you choose which is appropriate? Ranze (talk) 04:36, 23 October 2015 (UTC)

When you have a choice between 10- and 13-digit ISBNs, choose the 13-digit.
Trappist the monk (talk) 10:14, 23 October 2015 (UTC)
I agree, but also when you have a choice between 10- and 13-digit ISBNS, there is no difference in the information content provided by the two numbers. So you're not losing anything by only including the 13-digit one. —David Eppstein (talk) 18:24, 29 October 2015 (UTC)
Yes, if the choice is only one or the other. But is there any harm in having both? E.g.: if a book that originally has only a 10-digit ISBN is reprinted with addition of 13-digit ISBN, someone with the original might not recognize it if only the 13-digit ISBN is given. Same thing where identical content is published with different covers. So why not include all of the ISBNs? ~ J. Johnson (JJ) (talk) 22:32, 29 October 2015 (UTC)
With the same argument, you should add all the ISBN numbers as books routinely have more than one ISBN number and upwards of 10 and this doesn't include different versions of books. Primary purpose of the ISBN number is to find the book. As the 10 and 13 digits are identical, only one is fine. A few countries have already run out of 10-digit numbers and are only issuing 13-digits. Bgwhite (talk) 06:58, 31 October 2015 (UTC)
Yes, but here we are bridging two kinds of cases. In the first case the source is simply an editor's source, and WP:SAYWHEREYOUGOTIT applies. Here I would argue for inclusion of only the ISBNs applicable to that specific source. But if the intent is to enable other editors and readers to find any/all editions, then, yes, it might be reasonable to list ten or more ISBNs. Not that it happens very often.
Incidentally, as the templates take only a single ISBN (the others have to be suffixed to the citation using {{ISBNT}}) I think the 13-digit ISBN should be preferred. ~ J. Johnson (JJ) (talk) 22:51, 31 October 2015 (UTC)

metadata changes[edit]

Here are test cases for metadata using new code in Module:Citation/CS1. The code was rewritten to more closely reflect the type of template for which the module is creating the metadata. The biggest changes involve which metadata key-encoded values (kev) are included. In the current live version kevs that are not defined for the selected metadata format are included in the metadata. The sandbox version attempts to closely follow the standards and only include those kevs that are defined for the specified format.

In the live version, the value assigned to &rft.genre is article, book, bookitem, or preprint. In addition to those, the sandbox makes use of conference, report, and unknown. Many of the cs1 templates now produce &rft.genre=unknown where before they were &rft.genre=book.

There are separate sections for cs1 and cs2 templates. The templates in these sections are taken from their respective documentation or from article space. I think that all of the templates are covered. Did I miss any? Do you see metadata that doesn't make sense?

The standards that I used to make this change are available through this source:

"Registry for the OpenURL Framework - ANSI/NISO Z39.88-2004". OCLC. Retrieved 2015-09-27. 



Trappist the monk (talk) 19:28, 24 October 2015 (UTC)

I would add that for the book COinS format we should not set rft.pages unless rft.genre=bookitem.
This is because |pages= combines two functions in these templates. For books it typically records the location of a statement being cites, whereas for articles in journals and chapters of books, it typically records the entire span of the article or chapter. Only in the latter case is it the same thing as rft.pages. Kanguole 14:37, 5 November 2015 (UTC)
I'm not exactly sure I understand what you're saying.
According to this, rft.pages is:
Start and end pages for parts of a book, e.g. "124-147". This can also be used for an unstructured pagination statement when data relating to pagination cannot be interpreted as a start-end pair, e.g. "A7, C4-9", "1-3,6". This data element includes the OpenURL 0.1 definition of "pages".
To me, the meaning of This data element includes the OpenURL 0.1 definition of "pages" isn't exactly clear. According to OpenURL 0.1 pages is:
Pages covered by an individual item in a bundle. The format of this field is 'spage-epage'
where 'bundle' and 'individual item' are the values assigned to rft.genre:
'bundle' is journal, book, conference
'individual item' is article, preprint, proceeding, bookitem
Which begets which? If |chapter= is not set then, rft.pages omitted even when |page= or |pages= is set and rft.genre=book? Or, does the existence of |page= or |pages= without |chapter= convert rft.genre from book to bookitem? I think that the former doesn't make much sense because a single page or multiple pages are a subset of a book. It seems silly to require our editors to always include |chapter= in {{cite book}} when they want to cite something on a single page of that book.
Although it isn't explicitly stated in OpenURL 0.1, the example at §6 shows &rft.spage=134 without an accompanying rft.epage. This could mean that we should use rft.spage when the meta-parameter Pages has a single value; use rft.spage and rft.epage when Pages has a simple page range; and rft.pages when Pages has something else. This is complicated by things like |at=Back cover or the misuse of a hyphen as a range separator instead of the proper ndash – which could explain why previous versions of the COinS code dump all page information into rft.pages.
Trappist the monk (talk) 12:45, 6 November 2015 (UTC)
The example at §6 is a fragment to illustrate syntax rather than the meaning of tags.
As I said above, |page=/|pages=/|at= are used in the templates in two different ways:
  • If we're citing a whole item (e.g. a book), the page number(s) locate the specific statement that is relied upon.
  • If we're citing a part (e.g. an article in a journal, a contribution in a book or a paper in a conference proceedings), the page number(s) delimit the extent of the part. Specifying a particular page or pages within the article is done outside the template, or with short references.
OpenURL 0.1 also distinguishes these two types as bundles (e.g. genres book and conference) and individual items (e.g. genres article, bookitem and proceeding). As laid out in Table 2 of that document, only individual items should set the rft.pages; bundles should not. (Although OpenURL 0.1 has been superseded, the standard refers to it for the meaning of rft.pages.) So indeed I am saying is that in a book where |chapter= is not set, rft.pages should not be included in the COinS metadata, though the page number would still be in the visible text. There is no need for editors to change their practice.
While looking this up, I noticed another infelicity: a paper in a conference proceedings (e.g. the Liskov & Zilles example above) should have genre proceeding, not conference (which would mean the whole book). Kanguole 14:48, 6 November 2015 (UTC)
Perhaps the example at §6 is a fragment or perhaps not. How do we know? Do you have access to more definitive documentation that clearly shows that COinS does not support a single page reference?
Where is it documented that page ranges in cs1|2 delimit the extent of the part and that particular page [specification] is done outside the template? This, to me, is counter intuitive nonsense. An article or chapter title is sufficient to delimit the extent of that part. To also include a page range spanning the whole of the part is unnecessarily redundant and is akin to identifying total number of pages which cs1|2 does not do. If the purpose of a cs1|2 template is to consolidate and render all of the information necessary for a reader to locate, within a source, the information necessary to corroborate a wp article's statement, having the page number where that information may be found is better for the reader than listing all of the article's pages and leaving it to the reader to search for the relevant information. When the wp article uses short form referencing, page numbers are not required in the matching cs1|2 template and should not be included.
{{cite conference}} needs rethinking methinks which is beyond the scope of this conversation. Until that is accomplished, I'm inclined to leave the metadata as they stand. It might be tweaked so that rft.genre=proceeding when |title= and |journal= are set or when |title= and |booktitle= are set.
Trappist the monk (talk) 11:33, 10 November 2015 (UTC)
I didn't say that COinS/OpenURL doesn't support a single page reference – there's no reason to think it doesn't. I did say
  • rft.pages was intended only for genres like article, proceeding and bookitem that represent part of a larger bundle, but not genres like conference and book that represent a whole bundle (Table 2 in the OpenURL 0.1 spec makes this clear).
  • In those cases, rft.pages holds the page range of the part (see the description of pages in the KEV format matrices; Table 1 in the OpenURL 0.1 spec says Pages covered by an individual item in a bundle).
The use of |pages= to delimit the extent of an article in a journal or a contributed chapter in a book is the common practice on Wikipedia, reflecting the habits of the world outside, and can be seen in the examples in {{cite journal}} and {{cite book}}. Most users of academic referencing would consider citations of these types to be incomplete without the page ranges for the parts. That leaves no way to indicate the specific paces referenced, unless one uses short references or additional text, an issue that has been noted many times. Kanguole 17:01, 10 November 2015 (UTC)
My understanding of the tradition of specifying the page range of the article being cited is that in mid-to-late 20th century if a library didn't have a journal that a patron requested, they would send a request to a library that did have it to make photocopies of the required pages and send them to the requesting library. The person making the photocopies might be any student who had a part-time job at the library, and might the student might not have the skill to decide what pages ought to be copied, so the citation would allow the student employee exactly which pages to copy. Jc3s5h (talk) 17:35, 10 November 2015 (UTC)
I am not trying to put words into your mouth that you did not speak. I am trying to parse apart just what it is that you are saying. When I suggested rft.spage as a solution to the single page problem, you wrote, rather assertively, that the example at §6 is a fragment to illustrate syntax rather than the meaning of tags. From which I infer, perhaps incorrectly, that you know, conclusively, that it is not permissible to use rft.spage alone, without an accompanying rft.epage and thus it is not possible to refer to a single page using COinS as it is currently defined. Hence, the reason for my question: Do you have access to more definitive documentation that clearly shows that COinS does not support a single page reference?
With regard to both of your bullet points, I understand that; I referenced the same thing from the standards docs in a previous post.
I am questioning the 'common practice' if there is such a thing. My position with regard to the examples at {{cite journal}} and {{cite book}} reflects your position with regard to the §6 example I quoted: those are simply bibliographic examples and are not definitive. The actual |page= and |pages= documentation (page & pages) says nothing about delimiting articles and chapters with page ranges. Sure, if you follow a doi or pmc or other link to a website, you will often see that there, the page range is included in the bibliographic information. But, bibliography and citation are not the same thing. For most uses in Wikipedia articles, we are writing citations where editors should be identifying the in-source location of the supporting text for the benefit of the reader. Where an editor is writing a bibliography, in-source location page numbers are not required and delimiting an article or chapter with start and end pages is merely redundant information.
I wonder if this 'common practice' of 'page-range-as-delimiters' arises because of tools like Wikipedia:RefToolbar/2.0 or User:Citation bot which can/will populate |pages= given a doi or pmid or the like. Editors assume the tool's results to be correct and do not edit the tool's results to correctly specify which page or pages support the Wikipedia article's text. These tools also produce consistent results to which editors grow accustomed so correct citations without a delimiting page range will then look 'odd' to them.
Trappist the monk (talk) 18:30, 10 November 2015 (UTC)

Protected edit request on 26 October 2015[edit]

In your template you omit a category for Paperbacks. e.g. a book is published in New York, but the paperback version in another year is brought out in Greece about the Greek War, but is in English. How do you write to include the same book in paperback in another year and/or language? Category: Language, Year/Date, Hardback/Paperback; Template: Cite book| Justin Grant-Duff 22:45, 26 October 2015 (UTC)

Is this a question about the documentation (that it should give guidance for this case) or a request for a specific change to the template, and if so what change? In any case the usual answer is: cite the edition that you got the information from. If you want to indicate that it's a reprint of a previous edition, we have the |orig-year= parameter for that. We do not have a parameter for the physical details of the binding: whether it is hardcover or softcover, whether it comes in a slipbox or not, whether it is folio, octavo, or some other size, whether the pages are deckled, etc.; why do you think these are important information for a citation? —David Eppstein (talk) 23:10, 26 October 2015 (UTC)
Red information icon with gradient background.svg Not done: Marking as not done, as it looks like this isn't a request for an update to the actual template. — Mr. Stradivarius ♪ talk ♪ 23:20, 26 October 2015 (UTC)
@Jgrantduff: There's already a way to indicate what you want. For example, if I wanted to cite the original hardcover edition of a specific book from the library, I'd use:
  • Lewis, Tom (1997). Divided Highways: Building the Interstate Highways, Transforming American Life. New York: Viking. ISBN 9780670866274. 
But since I own the paperback Updated edition, instead I'd cite:
  • Lewis, Tom (2013). Divided Highways: Building the Interstate Highways, Transforming American Life (Updated ed.). Ithaca: Cornell University Press. ISBN 9780801478222. 
In the latter case though, if they hadn't already specified it as an Updated edition, I could have used |edition=Paperback with the updated year/location/publisher details. Just another pairing to demonstrate:
Imzadi 1979  01:42, 27 October 2015 (UTC)
@Jgrantduff:: If it's not clear from the above examples, use the {{cite book}} template twice, once for each edition, if you are listing all of the editions of a book. If you are citing a source, cite only the edition that you have seen with your own eyes. See WP:SAYWHEREYOUREADIT for a full explanation. – Jonesey95 (talk) 02:54, 27 October 2015 (UTC)


How do you cite the author of a foreword? Thx! !!!! — Preceding unsigned comment added by Lfstevens (talkcontribs) 23:30, 29 October 2015‎

My best guess would be
{{cite book|others=author of foreword|page=page the foreword appears on|chapter=foreword|the other usual parameters go here}}
or something similar. davidwr/(talk)/(contribs) 05:26, 30 October 2015 (UTC)
I needed to do this, and what I did as a workaround was:
  • Phipps, Makena Elizabeth (2004). "Foreword". In Phipps, Terry W. Seasons of Sleeping Bear. Ann Arbor: University of Michigan Press. p. 5. ISBN 0-472-11445-X. 
    • {{cite book |last= Phipps |first= Makena Elizabeth |year= 2004 |chapter= Foreword |editor1-last= Phipps |editor1-first= Terry W |title= Seasons of Sleeping Bear |location= Ann Arbor |publisher= University of Michigan Press |page=5 |isbn= 0-472-11445-X}}
It's not the best solution, but it worked. When we have something better, that can be changed out.
Another option would be to list the foreword's author ahead of the citation template:
  • Phipps, Makena Elizabeth. Foreword. In Phipps, Terry W. (2004). Seasons of Sleeping Bear. Ann Arbor, MI: University of Michigan Press. p. 5. ISBN 0-472-11445-X. 
    • Phipps, Makena Elizabeth. Foreword. In {{cite book |last= Phipps |first= Terry W. |year= 2004 |title= Seasons of Sleeping Bear |location= Ann Arbor, MI |publisher= University of Michigan Press |page=5 |isbn= 0-472-11445-X}}
Imzadi 1979  22:58, 31 October 2015 (UTC)
The first form should be avoided (the foreword not being a chapter, nor the author an editor), but second form looks good in all respects. It doesn't need to – indeed, should not – generate COinS metadata because the item that COinS is identifying is the book. ~ J. Johnson (JJ) (talk) 23:15, 31 October 2015 (UTC)
Actually the first form is closer to what one would want if using short references, and the foreword is a contribution, if not a chapter. Not distinguishing book authors from editors is an issue, though. Kanguole 11:35, 1 November 2015 (UTC)
No, the first form is not acceptable, esp. as it makes Mekena Elizabeth the author of the book. But you do raise a good point: if the last names are different (let's say the foreword was by Makena Elizabeth Smith) you might want to use a short cite of "Smith 2004", and have that link to the full citation. One way is to use {{harvid}}. Or create the link yourself. I believe something like [[#CITEREFPhipps20004|Smith 2004]] would work. ~ J. Johnson (JJ) (talk) 22:55, 1 November 2015 (UTC)
It makes Makena Phipps the author of the foreword, which is correct; the error is in characterizing Terry Phipps as the editor rather than the author of the book. If it had been an invited foreword in an edited work, that would be an appropriate way to cite the foreword, as in:
  • Isaacson, Michael (2007). "Foreword". In de Silva, Clarence W. Mechatronic Systems. CRC Press. p. xiii. ISBN 978-0-8493-0776-8. 
    • {{cite book |contribution=Foreword |first=Michael |last=Isaacson |page=xiii |title=Mechatronic Systems |editor-first=Clarence W. |editor-last=de Silva |publisher=CRC Press |year=2007 |isbn=978-0-8493-0776-8}}
On the other hand, there is a similar problem with citing an invited chapter in an authored book, as in:
  • Handel, Zev J. (2003). "A Concise Introduction to Old Chinese Phonology". In Matisoff, James. Handbook of Proto-Tibeto-Burman: System and Philosophy of Sino-Tibetan Reconstruction. Berkeley: University of California Press. pp. 543–576. ISBN 978-0-520-09843-5. 
    • {{cite book |first=Zev J. |last=Handel |chapter=A Concise Introduction to Old Chinese Phonology |pages=543–576 |title=Handbook of Proto-Tibeto-Burman: System and Philosophy of Sino-Tibetan Reconstruction |editor-first=James |editor-last=Matisoff |location=Berkeley |publisher=University of California Press |year=2003 |isbn=978-0-520-09843-5 |url= }}
Here I want to cite Handel, the author of a contributed chapter, but Matisoff is the author of the book as a whole. Kanguole 00:58, 2 November 2015 (UTC)
The problem you point out arises from an implicit assumption built into the template that the attribution (responsibility) for works containing work of others is of the nature of an editor, not an author. E.g., the template works on the assumption that inviting Handel to write an introduction puts Matisoff in the role of an editor. What is displayed is fine, the only problem is in the metadata characterization of Matiswoff as an editor. I suppose we could have a |cont-author= parameter that would, in effect, tell the template that this should be displayed as the author of the contribution, with |author= displayed like an editor, but reported to COinS as the author of the work. I think Imzadi's second form (above) is a better way, along with use of harvid for the short cites. ~ J. Johnson (JJ) (talk) 22:24, 2 November 2015 (UTC)
We agree that characterizing authors of books that include contributions by others as editors is a problem, but I'm arguing that it is the only problem here. Handel's contributed chapter is properly described as a bookitem (separately authored part of a book), just as if it were in an edited collection, and for bookitems OpenURL records only the author(s) of the part. Similarly, a contributed foreword, whether in an edited collection (Isaacson) or an authored book (Makena Phipps), is also properly described as a bookitem. There might be an argument that wherever we emit COinS data for a bookitem we should also emit a record for the containing book, but that would apply to all separately cited parts of books. Kanguole 11:15, 3 November 2015 (UTC)
[a] contributed chapter is properly described as a bookitem (separately authored part of a book) Do you have a source for that? The two definitions that I'm aware of define bookitem:
a defined section of a book, usually with a separate title or number ( and
Trappist the monk (talk) 11:52, 3 November 2015 (UTC)
No, your quotation is accurate. I don't think this error affects my argument, though. Kanguole 11:59, 3 November 2015 (UTC)
I am not familiar with "book item" (and Book Item and Component Identifier is largely a dead-end), but I can see some ambiguity whether these "defined sections" can have independent author attribution. That our templates can't handle such distinctions intrinsically, well, is that really a problem? We do have a work around. ~ J. Johnson (JJ) (talk) 23:53, 3 November 2015 (UTC)
OpenURL uses rft.genre=bookitem to indicate (as Trappist quotes) "a defined section of a book, usually with a separate title or number". Handel's chapter in Matisoff's book is such, but so are invited forewords in both edited and authored books. The citation templates include that key-value pair in the COinS metadata when |chapter= (or its alias |contribution=) is used. So the above markup is appropriate for citing Handel's chapter (and, I would argue, the contributed forewords). The only issue is that I have maligned Matisoff by placing his name in |editor=, but that does not show in the page formatting or the COinS metadata. Kanguole 00:46, 4 November 2015 (UTC)
Although I am averse to such mis-use of parameter attributes, I am fine with how it is currently displayed. If there is no problem with COinS, do we really care? Is someone likely to write a bot to "fix" such "errors"? ~ J. Johnson (JJ) (talk) 23:36, 5 November 2015 (UTC)


Second form[edit]

  • I am uncomfortable with the second form,
Phipps, Makena Elizabeth. Foreword. In {{cite book |last= Phipps |first= Terry W. |year= 2004 |title= Seasons of Sleeping Bear |location= Ann Arbor, MI |publisher= University of Michigan Press |page=5 |isbn= 0-472-11445-X}}
First, it does not work properly with {{sfn}}, unless we somehow wrap the citation in an <a> element, which seems a bit too technical for most editors. Second, it does not give COinS for the author being cited but for the author of the book, so the academic brownie points go to the wrong person. As a minor quibble, most style guides would say the book author is also formatted incorrectly in this case. "Last, first" format is for the person(s) being cited. Aymatth2 (talk) 17:43, 6 November 2015 (UTC)
Then don't use sfn. Nor html elements, since (as I have previously pointed out) a short cite can be created using either {{harvid}}, or something like [[#CITEREFPhipps2004|Smith 2004]], which displays as "Smith 2004" (our putative "forwarder"), and links to the full citation (see the example above).
You have a subtle misunderstanding that needs correcting. The author parameters (including "last=" and "first=") are not necessarily "for the person(s) being cited". They apply to the item or work (book, article, etc.) described in the citation. That you are citing (say) the author of the foreword rather than the author of the book is of no significance to COinS because it is the book, not the foreword in the book, that is going be indexed and shelved in the library. There are no "academic brownie points" involved, as COinS doesn't do that, and I don't believe any "academics" are being scored for being cited on Wikipedia. ~ J. Johnson (JJ) (talk) 22:02, 6 November 2015 (UTC)
  • @J. Johnson: {{sfn}} is by far the best way to refer to different pages in a source. If a solution does not work with {{sfn}} it is not a solution. I sense that you are a bit confused between {{harvid}} and {{sfn}}. These are not alternative templates, but complementary ones. You may want to review the documentation and then experiment in your Sandbox to see how they work together – and to see why the "second form" does not work from a web page navigation viewpoint. Aymatth2 (talk) 01:22, 8 November 2015 (UTC)
Your "[i]f a solution does not work with {{sfn}} it is not a solution" is bull. Sfn might be the most convenient way to "refer to different pages in a source" for editors who are allergic to Harv, but I strongly dispute that it is "by far the best way". The second form does work; I will shortly be adding examples (below) demonstrating "web page navigation". If you are confused how to use {{Harv}} I suggest you go play in your own sandbox. ~ J. Johnson (JJ) (talk) 00:48, 9 November 2015 (UTC)
In every other case, the author parameters are used from the author(s) being cited. There is no reason not to be consistent here, and indeed everything is much simpler if we are.
Regarding COinS/OpenURL, you seem to be overlooking that it can describe different kinds of sources, namely whole books (genre book) and parts of books (genre bookitem). It is the latter we are concerned with here, and the author of the part in question is Makena Phipps. Kanguole 00:34, 7 November 2015 (UTC)
We are being consistent. The |last=, |first=, |title=, |year=, |url=, and any other pertinent parameters should all apply to the same item. So if you want to do {{citation [because we have no "cite foreword" template] |last= Phipps |first= Makena Elizabeth |year= 2004 |title= Foreword ...}} that's fine. But as no library (and I suspect no one at all) indexes forewords (and thus nothing for COinS to point to), you need to point to the book with something like: In Phipps, Terry W. (2004), Seasons of Sleeping Bear, .... (Suitably templated, of course.) So you can have an author-foreword, distinct from author-book. Just not in the same template. ~ J. Johnson (JJ) (talk) 22:56, 7 November 2015 (UTC)
Who is this "we"? This seems to be a rule that you have invented. In fact it is very common for |last= and |first= not to be the author of the subject of |title= and |url=, but rather a part of that work. What is normal in other citations is that |last= and |first= refer to the writer of the words we are citing. Kanguole 23:43, 7 November 2015 (UTC)
A point you have missed is that citation is not to authors ("writers of words"), but to the works ("words") by those authors. You have also blithely missed that last=/first= normally impute authorship to the work (e.g., a book) named in title=. The exception is when an editor is specified. Then the working of the templates assumes that authorship applies not to ithe whole work specified in title=, but only to part of the work, such as a chapter. This is not suitable in the case at hand, where "we" have separate authorship but no editor. But no problem, Imzadi showed how to do such a citation. If for some really pendantic reason you just absolutely must have "the writer of the words we are citing" put into last= and first=, I just showed you how. And will do so again, below.
The original question here is answered. ~ J. Johnson (JJ) (talk) 00:55, 9 November 2015 (UTC)
We cite works, which are written by authors. In this case, a foreword, by Makena Phipps, that is part of a book. The "exception" to your rule that you wish to discount (citations using |contribution=/|chapter=) is actually extremely common, and is the closest to the current situation. The difference is that the book has an author rather than an editor, but we discussed that issue at length regarding the Handel/Matisoff example above, and I thought you ended up agreeing that this was an appropriate way to handle that case.
The argument for putting the author of what we are citing into |first= and |last= is simplicity and consistency. Your method A below is an awkward workaround for the problem you insist on creating, but it links to the book, rather than the foreword. Method B is invalid, because the first {{citation}} is incomplete. Kanguole 11:24, 9 November 2015 (UTC)
I have not "insist[ed] on creating" any problem, and perhaps you would be so kind as to avoid making such misstatements. The problem presented by the OP (Lfstevens) is how to cite something (e.g., a forward) written by one author that is prefaced to something written by another author. The problem with using the chapter=/contribution= parameters is that it is designed for a similiar but different problem, which attributes the containing work to an editor. In the problem presented here such a characterization of the main author (e.g., Terry W. Phipps) as an editor is false. I have previously stated that though I am averse to such mis-use of the parameters I am fine with resulting display.
You (and also Aymatth2) seem hung up on insisting that "the author of what we are citing" must go into a last=/first= pair of parameters, on a supposed basis of simplicity and consistency. Perhaps you should make up your mind on what you really want. The "A" form, of prefixing suitable text to a citation template, is most simple. Your objection that short cites link to the citation of the book seems to be channeling Aymathh2's objection that "[r]eaders look forward, not back.", which I find quite trivial, even silly. But if that is a problem for you, fine, use the "B" form. It is a consistent use of the citation templates, simple enough and not at all invalid. If this specific example is incomplete please describe in what respect. ~ J. Johnson (JJ) (talk) 23:27, 9 November 2015 (UTC)
The |contribution=/|chapter= parameters are used where we want to cite a part of a book, as situation with a direct counterpart in COinS (the bookitem genre). And that is what we want to do here, and in the Handel/Matisoff example. The template is not a perfect fit, because it has paramers only for editors rather than book authors, but it is the closest we have.
Imzadi's first solution above is simple, because it uses the template with no special formatting, and uses |first= and |last= for the author of the cited item, like every other citation. It works with {{sfn}} with no special treatment (because of the consistent use of |first= and |last=). It generates the correct formatting and the correct metadata. As with the Handel/Matisoff example, the only issue is that the book author's name have been put in parameters called "editor".
Your form B is invalid because the first citation has incomplete metadata. This issue was beaten to death in this thread and I don't wish to repeat it here. Kanguole 01:57, 10 November 2015 (UTC)
You should make up your mind re what you want, as your requirements are inconsistent. E.g., you object that my form A does not parameterize the "author of the cited item", and that form B (that does parameterize the author) has incomplete metadata (how?). Yet you would give the "first form" (using contribution=) a pass even though it misstates the metadata. You have not demonstrated any incompleteness of the metadata, and your sweeping assertion of invalidity is itself invalid. ~ J. Johnson (JJ) (talk) 23:57, 10 November 2015 (UTC)

Two ways of citing a foreword. Substituting "Smith" to distinguish between Phipps. Numerous variations are possible.

  • A: Smith, Makena Elizabeth. Foreword to Phipps, Terry W. (2004a). Seasons of Sleeping Bear. Ann Arbor, MI: University of Michigan Press. p. 5. ISBN 0-472-11445-X.  [Harvid used to create "Smith" anchor aliased to Phipps.]
  • B: Smith, Makena Elizabeth (2004b), Foreword , in Phipps, Terry W. (2004b). Seasons of Sleeping Bear. Ann Arbor, MI: University of Michigan Press. p. 5. ISBN 0-472-11445-X.  [Separate templates for Smith and Phipps; each getting their own last=/first=.]

"Short cites" linking back to the full citation:

More than one way to do these things. ~ J. Johnson (JJ) (talk) 01:03, 9 November 2015 (UTC)


  • The "A." example illustrates one of the problems with the "second form". The principle of least astonishment is that things should work the way users probably to expect them to work. The link to Smith 2004a, whether placed instream with {{harvnb}} or placed in the {{reflist}} by {{sfn}}, should not jump the reader to text that starts with ""Phipps, Terry W..." and does not mention Smith. Readers look forward, not back. A website designer who insisted that was acceptable would not last long. The "B." example is bizarrely complex. Neither example addresses the COinS and author name format problems. Aymatth2 (talk) 01:50, 9 November 2015 (UTC)
If you don't like the simplicity of the "A" form, fine, use the "B" form. The latter satisfies your objections re navigability, parameterizing the forward's author, and jumping to the very front of the citation. As to addressing any COinS or formatting problems, you have not shown any. The only likely COinS problem I see is that no library has indexed the forward of this book, so there is nothing for a COinS record to point to. As to being "bizarrely complex", that's absurd. This example is a straight forward and quite ordinary use of the standard templates. But if you are not comfortable with that, please feel free to contribute your own example. ~ J. Johnson (JJ) (talk) 23:29, 9 November 2015 (UTC)
  • @J. Johnson: I think you fail to grasp how impossible the "second form" is. Apart from the obvious COinS and name format problems, it completely fails to meet accessibility requirements. The web is a very important tool to the blind. They navigate using a screen reader. A real-life example may help make this clear. Suppose a blind user is reading an article about England in 1066 with {{harvnb}} citations to the introduction by Magnusson & Palsson of a book by Sturluson. They hear something like,

    Hardrada landed near York in mid-September. Bracket link Magnusson and Palsson two thousand and five pea ex eye eye eye [pause] end-bracket. Godwinson gathered an army and marched north. Bracket link Magnusson and Palsson two thousand and five pea ex eye vee [pause] end-bracket.

The user selects the second link and hears,

Sturluson Snorri two thousand and five King Haralds Saga Aylesbury Penguin you kay eye ess bee en zero one four one nine one five zero seven two.

There is no mention of Magnusson & Palsson, They click back and replay the link, and it does indeed say Magnusson & Palsson. They click forward, and again get what appears to be a completely different book. This is not an acceptable solution. You are surely not advocating that we recommend it? Aymatth2 (talk) 01:29, 10 November 2015 (UTC)
  • The "B" form is, of course, ludicrous. I assume it is a joke. Very funny. Aymatth2 (talk) 01:29, 10 November 2015 (UTC)
Your contrived example is ludicrous. But not funny. If you are done with your little joke perhaps you might contribute an example of how you would cite a forward. ~ J. Johnson (JJ) (talk) 00:01, 11 November 2015 (UTC)


Moving forward[edit]

The Magnusson & Palsson example illustrates that the "second form" does not work with screen readers, so cannot be treated as a solution. The "B" form, using two cite templates, one for the foreword and one for the book, is clumsy to say the least and generates some strange COinS. An issue with both is that the book author is not being cited, but their name is in last-first format. Only the cited author should be in this format; some say only the first cited author, for obvious reasons. So far no workable solution has been identified for citing an introduction using the current templates, so we have to consider enhancing the templates.

Two MLA-style examples from the Harvard Guide to Using Sources:

  • Pynchon, Thomas. Foreword. Nineteen Eighty-Four. By George Orwell. New York: Plume-Penguin, 2003. vii-xxvi. Print.
  • Gillan, Jennifer. Introduction. Identity Lessons: Contemporary Writing About Learning to Be American. Ed. Maria Mazziotti Gillan and Jennifer Gillan. New York: Penguin, 1999. xii-xxi. Print.

Two APA-style examples from the same source:

  • Pynchon, T. (2003). Foreword. In G. Orwell, Nineteen eighty-four (pp. vii-xxvi). New York, NY: Penguin.
  • Gillan, J. (1999). Introduction. In M. M. Gillan & J. Gillan, (Eds.), Identity lessons: Contemporary writing about learning to be American (pp. xii-xxi). New York, NY: Penguin.

We obviously do not have to conform exactly to either style, but should observe the common principles in these and other standard citation styles. The discussion that immediately follows this one, #contribution= rather than others=, was an attempt to start thinking about how that could be done with minimal impact on the template and existing pages. The most obvious drawback, to me, is that it does not identify the person who is being cited. The WP editor should be able to easily specify that they want one or other of:

  • Pynchon, Thomas. Foreword. Nineteen Eighty-Four. By George Orwell. New York: Plume-Penguin, 2003. vii-xxvi. Print.
  • Orwell, George. Nineteen Eighty-Four. Thomas Pynchon, foreword. New York: Plume-Penguin, 2003. vii-xxvi. Print.

@Trappist the monk: @Davidwr: @J. Johnson: @Kanguole: Is anyone interested in a calm and constructive discussion on how to enhance the templates to better support citation of introductions, prefaces, chapters etc.? That is, a discussion where the need for some change to the templates is accepted and the word "you" is banned? Aymatth2 (talk) 02:49, 11 November 2015 (UTC)

The person being cited is identified in the short cite: either 'Pynchon 2003' for the foreword, or 'Orwell 2003' for the book. ~ J. Johnson (JJ) (talk) 22:47, 11 November 2015 (UTC)
  • Given your last sentence, and especially the part where you define "calm and constructive" to mean that everyone agrees to change the template, I'm a little surprised that you don't don't go farther with that thought and define it to mean that everyone agrees with you and immediately changes the template to work exactly the way you think t should work. It's a cheap rhetorical trick to dismiss the people who disagree with you as unconstructive; have more good faith in their intentions. —David Eppstein (talk) 03:59, 11 November 2015 (UTC)
  • @David Eppstein: I am starting from the premise that since no satisfactory solution using the existing template has been identified after all this discussion, there is none. We should look for ways to enhance the template that will solve the problem. I have no strong views about what the changes should be. Aymatth2 (talk) 12:40, 11 November 2015 (UTC)
There have been a number of unnecessary personal remarks in the above back-and-forth, which is why I have stayed away so far, but I appreciate Aymatth2's succinct request above.
An apparent problem with the CS1 templates has been identified. It does not appear to be possible, using the existing template, to cite Thomas Pynchon's foreword to a book authored by George Orwell in a way that accurately characterizes the metadata. Specifically, it does not appear to be possible to create the following citation:
  • Pynchon, T. (2003). "Foreword". In G. Orwell, Nineteen eighty-four (pp. vii-xxvi). New York, NY: Penguin.
I believe that our current citation templates have no trouble with the second example given by Aymatth2 above, specifically:
  • Gillan, J. (1999). "Introduction". In M. M. Gillan & J. Gillan, (eds.), Identity lessons: Contemporary writing about learning to be American (pp. xii-xxi). New York, NY: Penguin.
This second example can be handled using |last=, |first=, |editor=, etc., all existing parameters. We shouldn't use |editor=Orwell for the first example, however, since Orwell is the author of the larger work, not the editor.
I welcome suggestions with specific examples of citation templates, or changes to the existing template parameters, that address the Pynchon/Orwell citation. – Jonesey95 (talk) 06:00, 11 November 2015 (UTC)
I agree that the existing templates satisfactorily handle an introduction or foreword to an edited book, as in the Gillan (1999) example (though one might quibble about the quotation marks around a generic name). On the other hand, the original issue also arises with contributed chapters to authored works, such as
so I would characterize the issue as separately-authored contributions to authored books. The nearest approximation offered by the current templates is:
  • {{cite book |last=Pynchon |first=T. |contribution=Foreword |editor-first=G. |editor-last=Orwell |title=Nineteen eighty-four |pages=vii–xxvi |location=New York, NY |publisher=Penguin |year=2003 |isbn=978-0-452-28423-4 |ref=harv}}
  • Pynchon, T. (2003). "Foreword". In Orwell, G. Nineteen eighty-four. New York, NY: Penguin. pp. vii–xxvi. ISBN 978-0-452-28423-4. 
For this version,
  • The formatting is fine (because it does not distinguish authors from editors).
  • The COinS metadata is correct (because for the bookitem genre it does not record authors/editors of books – in fact even the book genre does not distinguish editors from authors).
  • Harvard references like Pynchon 2003:x work as expected.
But although it does not show in any of the output formats, the markup is problematic, because we have put Orwell's name in a |editor= field.
What to do? We could just declare that |editor= can also be used for book authors when we're citing a separately-authored part of a book. We could add aliases. But some future output format might distinguish editors from book authors. We could add a flag that says whether these fields refer to editors or book authors. Or we could add new parameters for book authors, distinct from those for authors (used for the part) and editors. Kanguole 11:34, 11 November 2015 (UTC)
How about aliasing a |book-author-first= to |editor-first=, mutandis mutatis? Then in the future if an update to COinS/etc ever does necessitate the distinction between editors and authors of the overall book, we already have the infrastructure in place to make that distinction? Imzadi 1979  13:08, 11 November 2015 (UTC)
|contribution= is an alias of |chapter=. There is no |contributor=. We could create a contributor suite of parameters so that we might write:
{{cite book |contributor-last=Pynchon |contributor-first=Thomas |contribution=Foreword |title=Nineteen Eighty-Four |author-first=George |author-last=Orwell |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}
The combination of |contributor= and |contribution= would require |author= (or alias) and follow the MLA style and render like this for cs1:
Pynchon, Thomas (2003). Foreword. Nineteen Eighty-Four. By George Orwell. New York: Plume-Penguin. pp. vii–xxvi.
and this for cs2:
Pynchon, Thomas (2003), Foreword, Nineteen Eighty-Four, by George Orwell, New York: Plume-Penguin, pp. vii–xxvi
If there are editors, where do those names go and, especially for cs2, how are they separated from the author name list? Semicolon as in this mock-up?
Pynchon, Thomas (2003), Foreword, Nineteen Eighty-Four, by George Orwell; Sam Smith (ed.), New York: Plume-Penguin, pp. vii–xxvi
For the metadata, do we include Pynchon and exclude Orwell? If we don't, that is similar to how cs1|2 includes a chapter-author but does not include the editors.
Is the combination of |contributor= and |contribution= restricted to {{cite book}} and to {{citation}} when |work= is not set?
Trappist the monk (talk) 13:43, 11 November 2015 (UTC)
  • I like the concept of |contributor= and |contribution=, which can be used for Introduction, Preface, Forword, Afterword. I would include contributors like this in the metadata, since they have written part of the cited book edition. It could also be used for other types of contribution like Translation and Illustration. In theory, and we would need to think very carefully about this, it could replace |others=, |editor= and even |author=. That is a distant future concern. I would limit it to {{cite book}} and {{citation}} for now. The Harvard Guide section on non-authors shows a possible problem though. It shows two MLA examples for scholarly or critical editions:
  • Achebe, Chinua. Things Fall Apart. 1958. Ed. Harold Bloom. Broomall: Chelsea House, 2003. Print.
  • Bloom, Harold, ed. Things Fall Apart. By Chinua Achebe. 1958. Broomall: Chelsea House, 2003. Print.
The first is to be used when the book is mostly being cited for the author's contribution, and the second when it is mainly being cited for the editor's contributions. We maybe have the same problem with an introduction. If it is being cited, the person who contributes the introduction goes at the front, last name first.
  • Pynchon, Thomas (2003). Foreword. Nineteen Eighty-Four. By George Orwell; Sam Smith (ed.), New York: Plume-Penguin. pp. vii–xxvi.
If the presence of the introduction is being noted as information about the edition, but the introduction is not being cited, it belongs after the editor, if present:
  • Orwell, George (2003) Nineteen Eighty-Four, Sam Smith (ed.); Thomas Pynchon (foreword), New York: Plume-Penguin, pp. vii–xxvi
I am mostly thinking of cases when the template is being used in a list of works by the person who wrote the introduction. Maybe it is not a serious issue. Aymatth2 (talk) 16:20, 11 November 2015 (UTC)
The metadata issue is problematic. In the normal case we provide author name and book title. For edited works, we provide author name, chapter, and book title; the editor is omitted because there isn't a key/value pair defined for editors. The same might be true for this case. We provide contributor name, contribution title (in rft.atitle), and book title. We could provide the book author name as a second name in Should we?
This proposal is not intended to be used for anything other than forewords and the like. It is not a replacement for |others= or for |translator=.
There are, it seems, two basic uses of the cs1|2 templates: citation and bibliography. I have wondered about using |mode= in some way to instruct Module:Citation/CS1 in the rendering of bibliographic items. This is a topic for another time and place.
Trappist the monk (talk) 14:02, 12 November 2015 (UTC)
  • I would buy that. I was maybe trying to be too ambitious, folding all the contributor roles (authors, editors, others) into a generic parameter set, then worrying about how to say which is being cited. So if the introduction is being cited, we use something like
  • |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction
but if the introduction is just being noted in a bibliography, we use
  • |others=[[Thomas Pynchon]], introduction
The |contributor= name(s) go at the front, first, last, if present, followed by the |contribution= or |chapter= value if present, followed by "In" and the standard book definition. I don't know if there should be a warning when there is no |contribution= or |chapter=. Maybe not?
That also works for a case I found lately where three people were listed as authors in the front matter, but each had written different chapters. There was no editor. So we could have
  • |contributor=Baker|chapter=Fourth Republic|author1=Abel|author2=Baker|author3=Cane|title=Suffrage in France
I would be inclined to just write metadata for the main authors. It is unfortunate that at present the COinS syntax does not let us supply data for other types of contributor, even when we have it, but that is a different subject, as is |mode=bibliography. Aymatth2 (talk) 18:47, 12 November 2015 (UTC)
@Aymatth2: In your example of three people sharing the authorship of (say) the Introduction, but not for individual chapters, what are you citing? These are different "items", with different authorship; they get cited separately. Don't try to mush everything into one package. ~ J. Johnson (JJ) (talk) 22:46, 12 November 2015 (UTC)
  • This would be citing the chapter by Baker in the book by Able, Baker and Cane. Aymatth2 (talk) 01:45, 13 November 2015 (UTC)
You have not specified to whom the writing (or editing) of the book is to be attributed. If Able, Baker, and Cain wrote (edited?) the book, then sure, the citation for Baker's words in chapter 2 is "Baker, in Able, Baker, & Cain". (With all the other bits and pieces, of course; I'm just showing the essence of the citation.) ~ J. Johnson (JJ) (talk) 23:30, 13 November 2015 (UTC)
Sort of. I think we should take 'by' from the MLA example that you posted in the first message under this heading and reserve 'in' to edited works. Contributor names are listed last, first when provided by |<name-list>-last= and |<name-list>-first= in keeping with standard cs1|2 name-list formatting. So:
{{cite book |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction |last=Orwell |first=George |title=1984 |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}
would produce:
Pynchon, Thomas (2003). Introduction. Nineteen Eighty-Four. By Orwell, George. New York: Plume-Penguin. pp. vii-xxvi. (cs1)
Pynchon, Thomas (2003), Introduction, Nineteen Eighty-Four, by Orwell, George, New York: Plume-Penguin, pp. vii-xxvi (cs2)
In one of these conversations someone wondered about quoting generic contribution titles. We might have a list of such generic contributions: afterword, foreword, introduction, preface, (are there others?) that we recognize and do not render in quotes; any other contribution title we render in quotes.
If |contributor= is set then |contribution= is required else we generate an error message. The opposite case |contribution= without |contributor= is allowed for backward compatibility. When |contributor= is set, |contribution= is not an alias of |chapter= but if both |contribution= and |chapter= are both set, we emit a redundant parameter error message.
Some thought will be necessary to make sure that CITEREF anchors are correctly generated for the contributor(s) and not the author(s) so that {{sfn|Pinchon|2003|p=xiv}} works properly.
Trappist the monk (talk) 19:55, 12 November 2015 (UTC)
  • The Harvard style examples all give only the name(s) at the start of the citation in "last, first" format, useful for alphabetical sorting, then all the other names in "first last" format. I would prefer that we comply with this convention. Some say that when there are two authors only the first should be in "last, first" format. I have no opinion on that. I do not see much difference between |chapter= and |contribution=. They both identify a part of the book. I agree the chapter is "in" the book and the intro etc. precede or follow the book "by" the author or editor. |chapter= without |contributor= is reasonable. I often cite an entry in a biographical dictionary where the author is not given. Sometimes the editor is not given either. There may sometimes be cases where |contributor= without |contribution= would be useful:
  • |contributor=Wilde, Oscar|title=Victorian quips|editor=Fred Smith
No point generating error messages for situations that cause no problems. I agree that if both |contribution= and |chapter= are present there should be an error message. A list of common generic types of contribution could also be used to give common abbreviations. Smith, intro., pref., forewd., aftwd., maybe? It should be easy to tweak. Aymatth2 (talk) 01:45, 13 November 2015 (UTC)
Name lists that use |<list-name>-last= and |<list-name>-first= in cs1|2 are rendered in last-first order. Without we change that fundamental property throughout, name lists shall continue to be rendered in that same way.
Let us solve one problem at a time. This proposal is to answer the how-to-cite-a-foreword question. We shall use the contributor/contribution pair to determine when to rearrange the final output into the <name> <date> <foreword> <title> by <author> ... format. When we actually get to the code it may be that this restriction is not necessary. We'll see. Until then |contributor= requires |contribution=. Let us not disturb the normal method of identifying an author in an edited work:
|author=Wilde, Oscar|title=Victorian quips|editor=Fred Smith
We could do abbreviations but should expand them. But, editors are endlessly inventive. I don't think that cs1|2 should be in the business of figuring out just what some editor thinks is the proper abbreviation for some contribution title. Editors can type a few more characters to get it right.
Trappist the monk (talk) 15:09, 13 November 2015 (UTC)
  • Fair enough. It is contributor(s)/contribution pair, right? There could be co-authors to an introduction, as in:
  • Magnusson, Magnus, Pálsson, Hermann (2005). Introduction. King Harald's Saga. By Sturluson, Snorri. Aylesbury: Penguin UK. ISBN 0141915072.
I prefer to follow the Harvard conventions for first/last names, but agree it is a separate question. Aymatth2 (talk) 16:00, 13 November 2015 (UTC)
Yes, as many names as are necessary as well as the -linkn and -maskn modifiers. I'll start a separate discussion referencing this one for discussion of actual implementation.
Trappist the monk (talk) 16:24, 13 November 2015 (UTC)
I would expect that the COinS author fields for a bookitem would contain the author(s) of that item, and not include other people named as author(s) of the enclosing book. So for this foreword, Pynchon but not Orwell. Kanguole 22:51, 12 November 2015 (UTC)
[ec] The following is implemented per form B (above) with the existing templates:
and can be cited as Pynchon 2003c. Key differences with the previous example:
  • Page range of the Introduction follows the Intro. specific data
  • Book author preceeds title, rather than following (and with "by)".
  • Book author name is inverted, rather than "normal" order.
Having the page range of the Introduction (or any such portion) seems like a good feature to retain, as having it follow the book data suggests that the book is "pp. vii-xxvi".
It seems to me that the other two differences can be conceived as a single alternative of formatting. E.g.:
  • <last, first>, <Title>
  • <Title> by <first last>
Could this not be handled as simple option? ~ J. Johnson (JJ) (talk) 22:57, 12 November 2015 (UTC)
No. Arguing for Form B is merely a variant of the discussion we've already had at the "Missing or empty |title=" error message discussion. In this case its a {{cite book}} template, some connective text, and another {{cite book}} template. The first {{cite book}} template attempts to cite a 'book' titled Introduction and renders that title in italics and not quoted as it should be. The metadata then is for a 'book' written by Pynchon titled 'Introduction'. Because of this malformed metadata, Form B should not be used. Also, because we have had this discussion before, I don't think I have anything more to say about it.
Trappist the monk (talk) 01:04, 13 November 2015 (UTC)
Are you paying attention? My question was whether the location and inversion (or not) of the author's name could be a simple option. Not discussed previously. And as I recall, your concluding comment on that other discussion was that you just didn't want to do it.
If using 'cite book' for only part of a book offends you, one could use {{citation}}. Of course, that's jiggered to assume a book. And we can't use 'chapter=' without a 'title=' because you screwed it up. ~ J. Johnson (JJ) (talk) 23:36, 13 November 2015 (UTC)
J. Johnson, your personal attacks and mean-spirited comments are not welcome here, not to mention your continuing muddying of discussions by introducing tangential issues and responding with comments unrelated to the main question in the thread. Many of your comments are on point, but the noise is drowning out the signal, to the detriment of any constructive progress you would like to make.
I've been doing my best to ignore your direct and indirect attacks on other editors, but this last one ("you screwed it up") pushed me over the edge. If you feel that an editor has broken something, please address it in a neutral way in a separate section. If you feel that your concerns are not being addressed effectively, there are multiple venues available on WP for dispute resolution.
If other editors feel that I am out of line with this comment, I will stand down. – Jonesey95 (talk) 00:49, 14 November 2015 (UTC)
  • I fully support the above comments by User:Jonesey95. None of us needs the aggravation. Aymatth2 (talk) 03:13, 14 November 2015 (UTC)
  • While I don't entirely agree with your comment, neither would I say it is out of line. Discussion of this might be useful.
I allow that "screwed it up" may seem overly sharp, but perhaps you would accept that the tone of my comments (in this case, and generally) arises not from mean-spiritedness, but from exasperation. E.g., just above Trappist criticises my example because it "renders that title in italics and not quoted". Well, the example could be set up to quote the title (using 'chapter='), but that runs into the "missing title=" error - which Trappist brought about, and has obstinately refused to permit an exception. He criticises a lack of quotes where he has disabled that option. I find that exasperating.
As to "muddying of discussions by introducing tangential issues" - what do you mean? I think non-navigability and screen readers are tangential isues, but those were raised by Aymatth2. My intent is always to clarify issues. If on any particular point I have failed I would appreciate a comment. ~ J. Johnson (JJ) (talk) 00:02, 16 November 2015 (UTC)
Thanks for being willing to engage in good faith. The particular example of "muddying" that I was thinking of was this response, in which you wrote a long section with multiple points/questions, some of which were about using the existing template, at the bottom of a focused conversation about how the templates could be modified to support an authored chapter in an authored (not edited) book. I found that post frustrating, since we were converging on a solution to an identified problem after realizing that the OP's request could not be met for that sort of citation need; the post has since been placed in its own section, called "Using the existing framework", which makes more sense to me.
I understand that you are exasperated. We can't all get everything that we want from these templates or from WP. Sometimes we have to live with something that is non-optimal, at least for a period of time. When I find myself in a situation that I do not like and have been unable to change on WP, I try to focus my energy on something that I can do something about. I also try to spend some time thinking about a new way of framing my dissatisfaction, or a new way to resolve a problem that might gain a broader consensus. – Jonesey95 (talk) 00:46, 16 November 2015 (UTC)
You're welcome, and I appreciate your comments. Even where I am not as nice as some editors might want, even where I am sharp with someone (usually to get their attention, but sometimes out of exasperation), I feel I am honest about my motives (ask if not clear). For that reason, and because in the end I do prefer civility, there is no reason for anyone to impugn my good faith. Where other editors get most frustrated with me seems to be in critical analysis of arguments, where for inadequacy of explanation (possibly my fault), insufficiency of patience (which I don't like to push), or various other reaons, there is incomplete understanding. E.g., my five points (below, after the section break) you deem "muddying" I see as clarifying: I was summarizing previous points. (Note especially point #2, on the distinction between using the existing templates as they are versus improving them, which drastically affects the basis for assessing the examples and arguments raised above.)
Hopefully that provides some clarification. Are there any other points I should address? ~ J. Johnson (JJ) (talk) 23:27, 16 November 2015 (UTC)

  • "Form B" cites a book called "Introduction" by Thomas Pynchon and another book called "Nineteen eighty-four" by George Orwell. It gets part way towards acceptable visual format, but is cumbersome to code and creates odd COinS. It may have value as an interim solution. I think the discussion belongs in the next section, on #Using the existing framework. Aymatth2 (talk) 01:45, 13 November 2015 (UTC)
  • I confess to being unclear about what we expect to achieve with COinS. A serious bibliographic database would not be interested in our data, and I cannot see it being used to determine citation impact. Perhaps it would be useful to someone assembling Wikipedia articles into an e-Book? Whatever the purpose, we should fill out the parameters as they are intended. They do not include editors or other secondary contributors. We should also work towards getting COinS to support more complete bibliographic data, and when that is done modify our template to generate it. Aymatth2 (talk) 01:45, 13 November 2015 (UTC)
I agree with your second sentence. The primary intention of the parameters is get the information necessary to display the citation in some form deemed acceptable. Providing COinS data is secondary. If you want COinS to support more bibliographic data I think you have to talk to the people in charge of COinS – and hasn't this already been discussed? ~ J. Johnson (JJ) (talk) 23:38, 13 November 2015 (UTC)

Using the existing framework[edit]

Fine. Now show us how (in response to the OP's question) you would use the existing templates to implement these cases. ~ J. Johnson (JJ) (talk) 22:49, 11 November 2015 (UTC)
Several points need noting:
1) The issue here is not about citing contributions to a) an edited work, where an editor is identified (which the existing templates handle just fine), but to contributions (typically forewords and introductions) to b) an authored work, where the containing work is primarily one of original authorship.
2) The original discussion was how to cite a foreword with the existing templates. The context is implicitly pragmatic, looking for the best way possible. Perfection is not required.
3) In assessing either the current alternatives, or how the templates might be modified, the assessment criteria should be selected or defined first, then applied to all alternatives.
4) There is no rule or requirement that a cited author must be in last=/first= parameters, nor (as Aymatth2 claims) that only the specifically cited author may be in last=/first= parameters. Such a requirement is purely an idiosyncratic interpretation. (Probably results from not understanding that we cite works, not authors.) A logical consequence of such a rule would be that Orwell cannot be the author of Nineteen Eighty-Four if Pynchon is cited as the author of the Foreword.
5) Aymatth2 has not provided any actual "Magnusson & Palsson example", only a supposed result from some imagined citation that is no where demonstrated. His conclusion of "no workable solution has been identified" is unsuppored, and overlooks the context of the original questions, which was to identify the best – i.e., most workable – solution possible with the existing templates.
~ J. Johnson (JJ) (talk) 22:58, 11 November 2015 (UTC)
  • @J. Johnson: This discussion seems to have forked, as they often do, While some WP editors have shown interest in exploring possible changes to the templates, others see the problem as the best way to find a solution with existing tools. Both tracks of discussion can be pursued independently. There is no reason to suppress discussion along either line. A solution, even if imperfect, that uses the existing templates would be valuable, since any non-trivial change to the templates is likely to take time. Aymatth2 (talk) 00:58, 12 November 2015 (UTC)
It's not so much that the discussion forked as you criticised a pragmatic discussion from an idealistic viewpoint. Note that I have no objection with an idealistic viewpoint in the context of what should be, and of possible improvements to the templates. But non-perfection is not suitable for assessing work-arounds. ~ J. Johnson (JJ) (talk) 23:00, 12 November 2015 (UTC)
  • I do not know of any real-world examples of the "second form" of citation, but would be very interested in a workable mock-up screen-reader example with {{harv}} or {{sfn}} of,
* Smith, Makena Elizabeth. Foreword to {{cite book |last= Phipps |first= Terry W. |year= 2004a |title= Seasons of Sleeping Bear |location= Ann Arbor, MI |publisher= University of Michigan Press |page=5 |isbn= 0-472-11445-X|ref={{harvid|Smith|2004a}}}}
That is, a mock-up where the blind user learns that Smith wrote the foreword. Aymatth2 (talk) 00:58, 12 November 2015 (UTC)
As to a mockup of the "second form", isn't that what I provided? (Above, at "#Two ways".) (Which you mocked.) How well any of that works with a screen-reader, well, you were not clear on what the problem is. If you can offer a better work-around, please do so. Otherwise that is perfectibility question. ~ J. Johnson (JJ) (talk) 23:05, 12 November 2015 (UTC)
  • My fault for not spelling out the Magnusson & Palsson example in detail. I assumed most people were familiar with the concept of a screen reader. It is a software tool for blind people that uses speech synthesis to let the user listen to web pages, and lets them navigate within and between pages using the keypad. The example, which I only outlined, is coded as,

    Hardrada landed near York in mid-September.{{harv|Magnusson & Palsson 2005|p=xiii}} Godwinson gathered an army and marched north.{{harv|Magnusson & Palsson 2005|p=xiv}}
    * Magnusson, Magnus & Pálsson, Hermann. Introduction to {{cite book|ref={{harvid|Magnusson & Palsson 2005}}|last=Sturluson|first=Snorri|year=2005|title=King Harald's Saga|location=Aylesbury|publisher=Penguin UK|ISBN=0141915072}}

This would display as,

Hardrada landed near York in mid-September.(Magnusson & Palsson 2005, p. xiii) Godwinson gathered an army and marched north.(Magnusson & Palsson 2005, p. xiv)
  • Magnusson, Magnus & Pálsson, Hermann. Introduction to Sturluson, Snorri (2005). King Harald's Saga. Aylesbury: Penguin UK. ISBN 0141915072. 
The blind user will hear something like,

Hardrada landed near York in mid-September. Bracket link Magnusson and Palsson two thousand and five [pause] pea ex eye eye eye end-bracket. Godwinson gathered an army and marched north. Bracket link Magnusson and Palsson two thousand and five [pause] pea ex eye vee end-bracket.

They select the second link and hear,

Sturluson Snorri bracket two thousand and five end-bracket King Haralds Saga Aylesbury Penguin you kay link eye ess bee en [pause] link zero one four one nine one five zero seven two.

There is no mention of Magnusson & Palsson, They click back and replay the link, and it does indeed say Magnusson & Palsson. They click forward, and again get what appears to be a completely different book. This is typical of the kind of screen reader problems created when we ignore the principle of least surprise. It is not an acceptable solution.
According to the National Federation of the Blind, there are more than 8 million blind people in the USA, in the sense that even with corrective lenses they must use alternative methods to engage in any activity that persons with normal vision would do using their eyes. The internet is an incredibly valuable tool to them, but often web pages are designed with total insensitivity to their needs. You will also see why I dislike cluttering the text with {{harv}} details. Aymatth2 (talk) 14:53, 13 November 2015 (UTC)
I know quite well what a screen reader is, and if you're going to be snotty we can just end this discussion now. Your fault was in complaining about garbage out without showing us your garbage in. You are also being ridculous. Your complaint here seems to be (you really should state what you mean, not just throw out broad hints) that Harv cites are not suitable for screen readers. Which point arose only because when you complained (17:43, 6 Nov.) that the "Second form" does not work properly with Sfn I suggested you use Harv. I assumed that you knew how to pack Harv templates in <ref>...</ref> tags (just as Sfn does) to get the standard note links, but possibly I was wrong. ~ J. Johnson (JJ) (talk) 00:11, 14 November 2015 (UTC)
  • The issue is that the blind user follows the link for "Magnusson & Palsson" and finds a citation that makes no mention of "Magnusson & Palsson". The link does not work. Aymatth2 (talk) 03:13, 14 November 2015 (UTC)
So use the other form. Of course, when I suggest "A", and you complain it isn't "b". So I suggest "B", and you complain it isn't "a". As I have said before, if you can suggest a better way using the existing templates please show us. ~ J. Johnson (JJ) (talk) 00:15, 16 November 2015 (UTC)
  • A separate, perhaps subtle, point is that in my view we are citing an author who has recorded their views in a work, rather citing than a work that happens to be written by an author. We are saying "according to J.J. Higgins, in his introduction to the 1976 book Tropical Penguins" ... rather than "according Tropical Penguins (1976), with introduction by J.J. Higgins...". Professor Higgins is the authority, not the book – although both should be identified. On the other hand, when we generate metadata for the book we should generate as much information as possible. The less complete the metadata the less value it has. Comments? Aymatth2 (talk) 00:58, 12 November 2015 (UTC)
You are essentially questioning the "we cite works, not authors". Note the subtle point that tends to confuse this: in all styles of "author-date" referencing we identify the work by the author (or authors) and date (usually just year). E.g., if Smith and Jones write a book in 2004, they, as authors, are the parties responsible for it and the presumptive authority for what we might quote. However, the source is not Smith, nor Jones, nor a Siamese twin Smith-Jones, but their work (a book), which is cited as "Smith and Jones 2004". In your example, yes, Higgins is the authority, but the source where we find his immortal words is the Introduction he wrote. In quoting Higgins, we cite the Introduction. We also cite the book because that is where the Introduction is to be found. Okay? ~ J. Johnson (JJ) (talk) 23:07, 12 November 2015 (UTC)

contribution= rather than others=[edit]

A book may have main authors and other contributors such as the author of a preface or introduction. They should display as something like

Smith, John; Doe, Jane (preface); Bloggs, Fred (illustrator) ...

At present, the other contributors are given in the free-form |others= area. No COinS metadata is generated for the other contributors, and it is probably not practical to generate metadata, because the |others= field tends to be a grab-bag for any other information that seem relevant, such as details of reprints, explanation of publication circumstances, whatever.

One approach that looks o.k. is to put the other contributors in the |author# list, with the role in parentheses:

|author1=Smith, John |author2=Doe, Jane (preface) |author3=Bloggs, Fred (illustrator)

The result looks o.k., but messes up the metadata. A possible solution would be a new set of parameters, |contribution#, whose value would show in parentheses after the author name, or first name:

|author1=Smith, John |author2=Doe, Jane |contribution2=preface |author3=Bloggs, Fred |contribution3=illustrator

This would give the right visual appearance and generate the metadata. It could also eliminate the need for the |editor= family of parameters, since editing is just a type of contribution.

Comments? Aymatth2 (talk) 16:29, 30 October 2015 (UTC)

"The best is the enemy of the good" applies here, I think. We can go on making the citation templates more and more complex to allow for every possible case, but this just makes them harder to use and more error-prone (|contribution= has an existing, different meaning; non-matching numbered parameters are a common source of error). Peter coxhead (talk) 17:02, 30 October 2015 (UTC)
This would more difficult, not less difficult, for editors, and |contribution= is already a valid parameter used for something else. – Jonesey95 (talk) 20:24, 30 October 2015 (UTC)
A contributor is not a contribution. The latter is typically used for a source, such as a paper, that was contributed to some larger work, not what an individual author contributed. If such individual contributions really warrant mention then I suggest adding them parenthetically after the first name. E.g.: "|last3=Bloggs |first3= Fred (illustrator)".
Note also that editing generally is not a form of contribution. ~ J. Johnson (JJ) (talk) 22:23, 30 October 2015 (UTC)
Adding them as part of the value of a firstN parameter will pollute the metadata, though I suppose a final parenthesized part could be stripped off. Peter coxhead (talk) 22:31, 30 October 2015 (UTC)
Anything like "|author3=Bloggs, Fred" pollutes the metadata, too. If the "last" name (which is important for bibliographic purposes) is good I am less concerned about the first name. First names tend to be squishy anyway. ~ J. Johnson (JJ) (talk) 23:13, 30 October 2015 (UTC)
I don't think this level of detail is appropriate for a reference. Citing an invited foreword in a book by another author is a different matter, to which we unfortunately don't have a good solution. There's a similar problem when a book by some author includes a chapter by another author that we want to cite – we have no way to distinguish the author of the contribution from the author of the book – calling the latter an editor would be inaccurate. But there's no need to say who wrote the foreword if we're not citing text from it. Kanguole 23:18, 30 October 2015 (UTC)
  • A few comments on points made above
  • The suggestion of "contribution" as the parameter name seems to have been unfortunate. I first thought of "author-type" but it seemed clumsy. Maybe "role" works. The author, editor, illustrator, translator, prefacer etc. all play roles in making the book.
|author1=Smith, John |author2=Doe, Jane |role2=preface |author3=Bloggs, Fred |role3=illustrator
  • If accepted, the new structure would reduce complexity by letting us remove all the "editor" parameters, which mirror all the "author" parameters. After the change had settled in, with the "editor" parameters deprecated, a bot could run through the cites replacing them, e.g. "|editor-last2=Smith" becomes "|last3=Smith|role3=editor". This would be a significant reduction in complexity and a significant gain in flexibility, since other types of contributor could now be identified and generate metadata.
  • The name should be given as precisely as possible to make the COinS metadata as useful as possible to external applications. See Template:Cite book#COinS – "As a general rule, only one data item per parameter. Do not include explanatory or alternate text." That is, do not code "|first=John (preface)".
  • Digression:
The concept of first and last names is mostly used in European-origin cultures. It is preferable to identify them where known, as
|last=León y Pizarro |first=José García de
In most of Asia, the family name is followed by the given name. "Xi Jinping" is "President Xi", a member of the Xi family. It seems quite confused to use:
|last=Xi |first=Jinping
Issa Ahmed Mohammed, who has no family name, can only be cited as
|author=Issa Ahmed Mohammed
Patxo Unzueta has a first and last name, but I do not know which is which. When in doubt, "|author=" is safest.
  • Sometimes the preface and commentary may be what are most important: the Pale Fire effect. I come across this quite often with books of "collected writings" by the subject of the article, which may include letters, diary entries and so on. The writings are primary sources, best used sparingly, but the commentary is a legitimate source. An Icelandic saga would be similar: the author of the saga may be unknown, but the author of the notes and commentary is important.
Assuming the parameter set is called |role=, or something, any other comments? Aymatth2 (talk) 01:07, 31 October 2015 (UTC)
If you wanted to use something like |role= to replace the |author= and |editor= parameters, it would take a major rewrite of the citation module code. If someone wants to take on that rewrite in a separate sandbox and then show us how it works, including all of the existing formatting and error checking, that would be impressive. – Jonesey95 (talk) 13:51, 31 October 2015 (UTC)
  • The idea is not to replace the |author= family of parameters but to supplement them.
  • Leave the existing parameters unchanged
  • Add |role=, |role1=, |role2= etc.
  • Where present, the value of the |roleN= parameter would be given in parentheses after the corresponding |authorN= or |firstN=
|last3=Smith|first3=John|role3=translator would generate Smith, John [translator]
  • The |roleN= parameter value would also be written as COinS metadata, e.g. rft.aurole=translator
This does not seem like a huge change. Later stages would be:
  • Change the documentation to deprecate the |editor= family of parameters, with |author= and |role=editor to be used instead
  • Develop a bot to run through articles changing to the new style
  • Cut out the code for the |editor= family, maybe, some day...
The job is far from trivial but simplifies the citation templates considerably and supports much more structured data. Aymatth2 (talk) 15:07, 31 October 2015 (UTC)
&rft.aurole is not supported by the metadata standard.
I'm not sure that |rolen= is necessary. The purpose of a citation template is to render in standardized format enough information for a reader to locate the source; it is not to give credit to every person who at some point in the process touched the author's work. cs1|2 should not be in the business of mimicking Hollywood film credits – we don't need to know the name of the caterer's assistant.
A more useful task I think, is to specify a method by which we can cite a foreword by someone other than the work's author(s) as was mentioned above.
Trappist the monk (talk) 19:16, 31 October 2015 (UTC)
Aymatth2: I think you have missed the significance of "editors" not being any kind of "author". Authors have original and primary responsibility for whatever they have produced at the level of a book or article. Where editors assemble a set of such books or articles they may lean on the authors, but their responsibility is at a different level. It is not just incorrect to mingle these two different levels, it would be seriously misleading, and against all established citation practice. Elimination of the various "editor" parameters is quite unlikely to happen.
You are correct (and not just as a COinS rule, but as general rule) of "only one data item per parameter". That is also why I believe in splitting the family name (or surname, our so-called "last" name) from the personal or "first" name (and I believe everyone here understands those distinctions): the last/surname is very important for lexicographical ordering, the first/personal name not so much. If the specific roles or responsibilities of any of the authors are so important that they deserve mention then I suggest stuffing it into |firstN=. But I concur with Kangoule that "this level of detail is appropriate for a reference", and with Trappist that it is not the purpose of citation "to give credit to every person who at some point in the process touched the author's work."
I agree with you that sometimes "the preface and commentary [or other material] may be what are most important". But note that a collection of someone's writing is usually credited – as a collection – to the editor/compiler, and this generally includes any commentary. If you want to cite something like a foreword then you use the "in" form. E.g.: Tom Smith, "Foreword", in Robert Brown, Autobiography. There are no COinS fields for Smith because if go to your local library what you will be looking for is Brown's book. Perhaps that suffices for your needs? ~ J. Johnson (JJ) (talk) 22:38, 31 October 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── To some of the points above:

  • It is possible to identify a preface, introduction, chapter or postscript using |chapter= and |chapterurl=. When the {{cite book}} template is used to define a section of a book in this way, the |author= parameter describes the author of the section rather than of the book as a whole. This gives credit accurately in a book with multiple authors. An editor can define (and cite) two sections of a book with different authors in this way. I think it is a non-issue.
  • rft.aurole is not yet supported by the metadata standard, but that is a chicken and egg problem. Wikipedia has a lot of influence on the standard. If we agree that it should be supported, we can pursue getting it supported. If we cannot, there is no point pushing for the extension.
  • {{cite book}} gives a way to define attributes of a book so they display in standard format with COinS metadata. The template may be used in a citation by enclosing it in <ref>...</ref> tags. I much prefer to use the {{sfn}} form of citation, with the {{cite book}} source definitions in a section at the end of the article. This unclutters the text and allows precise {{sfn}} citations to different pages in the book without repeating the {{cite book}} definition. I often also use {{cite book}} definitions when listing publications by the author who is the subject of the article. This ensures that the list of books by the subject and the list of sources for the article have consistent format.
  • I do not accept the sharp distinction between "author" and "editor". In some books the bulk of the text is in the preface and footnotes written by the editor.
  • The editor should be able to identify any information about a book that seems relevant. An easy and consistent method of identifying the different people involved in making the book would be helpful to ensure consistent format and make the metadata more useful. The editor can give any information they think is useful. We should not restrict them. For example, the {{cite book}} template could be used in an article that lists different editions of a book. The author is the same but the translator, illustrator, prefacer etc. vary from one edition to another.
  • The change would be a simplification. Instead of entering
we enter
There is one less parameter to remember and much more flexibility. What is the downside? Aymatth2 (talk) 01:16, 1 November 2015 (UTC)
  1. Yes and no. Yes, you 'could' cite a preface as a chapter and cite the preface's author but it is unlikely, is it not, that the book will be cataloged under the preface author's name?
    • I often use {{cite book}} to define a section in a book such as a preface, chapter or encyclopedia entry with its author for citation purposes. It is important to give credit to the author and avoid plagiarism if at all practical. I am obsessive enough that if an entry is signed with initials, I try to track down the corresponding name. For a recent clumsy example see Jacques-Guillaume Legrand#Sources:
    Landon, C. P. (1809). "Notice sur Legrand". Essai sur l'histoire générale de l'architecture: pour servir de texte explicatif au recueil et parallèle des édifices de tout genre, anciens et modernes, remarquables par leur beauté, leur grandeur ou leur singularité par J. G. Legrand (in French). 
    This is a preface to a book by the subject that gives a sketch biography of the subject. If you scroll up to the Publications section you will see that three of the six books by the subject were co-authored.
  2. Do we? Do we have some champion here who can give the time and whatever else is required to shepherd such changes through the standards approval process? I'm not interested in that task. Are you?
    • Yes, I would be glad to shepherd the change through, assuming we can get concurrence here. I do not anticipate any serious objections. But it needs broader discussion within Wikipedia first. Not sure the right forum... Aymatth2 (talk) 02:02, 2 November 2015 (UTC)
  3. Yes, one of the primary purposes of cs1|2 templates is to [ensure] that the list of books by the subject and the list of sources for the article have consistent format.
    • Also "Further Reading" lists – anywhere a book is defined Aymatth2 (2 November 2015). talk. (UTC). 
  4. Of course. In a book of Ansel Adams photographs, it's entirely possible that the preponderance of the text is written by an editor. The work is still that of Mr Adams.
  5. Editors are free to identify whatever information they deem relevant. But, it isn't necessary to include all of that in the cs1|2 template. Would not the different editions that you suggest have different dates? possibly different edition identifiers? possibly different publishers? possibly different ISBNs? all of which are standard elements of bibliographic catalog listings?
    • Absolutely. I imagine an article that lists editions of, say, Don Quixote. It would have a bullet list of {{cite book}} entries for each of these editions, giving year, publisher, introduction, language, illustrator, prefacer etc. It might hide the author, and perhaps title, sort of like Adolphe Landry#Publications. Aymatth2 (talk) 02:02, 2 November 2015 (UTC)
  6. I don't see |rolen= as a simplification – mostly because such a change would be felt on millions of articles for little real benefit. It's a case of 'if it ain't broke, don't fix it.' COinS currently doesn't support a link between keywords so while you champion the addition of &rft.rolen, the definition of & will need to change to support &rft.aun
    • From the viewpoint of a WP editor, going forward, it would be a simplification and would solve the problem of how to identify the "others" who have contributed to a book.
    • A one-off conversion can tidy up existing articles after the new parameter has become familiar – but there is no urgency. I can write the bot.
    • We have implemented the |author= family, then the very similar |editor= family, but we really do not want to implement the |illustrator=, |preface= and so on families. The |role= approach is a simple generalization.
    • Surely &rft.aun must be supported anyway for co-authors. The kind of non-fiction books I cite often have two or more authors. E.g. in Léon Martinaud-Déplat#Sources two books out of the eight cited have multiple authors. Ditto with Pierre Forgeot: two out of nine. Note Pierre Forgeot#Publications: he wrote the preface for two of the four books listed, and co-authored a third.
    • COinS is very much a version 0.1 standard, with a 1-dimensional structure. It obviously needs extension to support a more realistic view of publication data. Again, I would be happy to work that one through. The benefits would be obvious to any librarian. Aymatth2 (talk) 13:15, 2 November 2015 (UTC)
Trappist the monk (talk) 20:52, 1 November 2015 (UTC)
Aymatth2: that you don't accept the distinction between authors and editors (and the distinct roles of each) is not persuasive, given the long and well-established acceptance of that distinction by effectively everyone else. And in the rare cases where it is useful to add more information you are quite free to add it following the citation; a special parameter is not needed. ~ J. Johnson (JJ) (talk) 22:26, 1 November 2015 (UTC)
  • The editor is the person listed as "edited by" at the front of a book. Their role in a compilation may have been simply to assemble individual contributions. However, they may have written an extensive introduction that provides context and a summary of the rest of the book, which may be cited in an article. In this case they may be seen as one of the authors. With some of the classics, a short book is embedded in a mass of valuable material provided by the "editor". I was flipping through an edition of King Harald's Saga the other day, a translation of part of Snorri Sturluson's Heimskringla. The translators, Magnus Magnusson and Hermann Pálsson, provide a 32-page introduction plus many footnotes. Again, their contribution may be cited, and in that sense they are co-authors. We can of course muddle by as we have in the past. No changes are essential... Aymatth2 (talk) 16:12, 2 November 2015 (UTC)
If Smith and Jones write "an extensive introduction that provides context and a summary" for a collection of T. S. Eliot's poetry, does that make them coauthors of "The Love Song of J. Alfred Prufrock"? No! Their authorship is only of the introduction (or whatever they wrote); they are only editors – not authors! – of the poetry. Even if the tail is big enough to wag the dog – say a 600 page critical edition of a twenty page poem – such that Smith and Jones are deemed authors of the book, there is still no "co-" authorship with the poet. Writing an introduction, no matter how many pages, does not make Magnusson and Pálsson coauthors with Sturluson. ~ J. Johnson (JJ) (talk) 21:44, 2 November 2015 (UTC)
  • The {{cite book}} template is usually used to identify a book and its authors in a citation. In the hypothetical T. S. Eliot example, Smith & Jones are co-authors of the book and should be identified to avoid any hint of plagiarism when citing their commentary. The {{cite book}} template could also be used to describe the book in the article on Jones. Her role in creating the book must be shown. Finally, the template generates metadata that may be used by crawlers to find references to the book or to works by Eliot, Smith or Jones.
The proposal is to reduce complexity for WP editors by deprecating the |editor2= |editor2-last= |editor2-first= |editor2-link= parameters and replacing them by the equivalent |author2= parameters plus |role2=editor. The |role2= parameter could also accept values like "translator", "preface", "illustrations" and so on. This would give more consistent format in book definitions and more complete metadata generation. Aymatth2 (talk) 01:16, 3 November 2015 (UTC)
It seems you are still missing the point. Your concept seems to be that we should have a master list of persons connected with the source (person1=, person2=, etc.), and then a parallel list describing their roles. For sure, such a scheme could generate a list of the proper authors, but that is not how these things are done. Long established practice is that we list authors separately from persons in other roles. Your scheme does not reduce complexity, and having such a novel scheme entirely unknown outside of WP would make WP harder to use. ~ J. Johnson (JJ) (talk) 00:14, 4 November 2015 (UTC)



  • The proposal is indeed to change a long-established Wikipedia practice. It would simplify the templates by reducing the number of parameters needed, while giving flexible support for additional structured information. It would also bring Wikipedia into line with practice in catalogs such as the Library of Congress, Bibliothèque nationale de France and German National Library, all of which link people to publications with a data structure like:
Person ––––∈ Role ∋––––Publication
A related change, which may be done independently, would add this structure to the COinS metadata, so Wikipedia would no longer look quite so naive to the librarian community. When COinS is enhanced to support multiple authors, which is overdue but inevitable, it should be enhanced at the same time to show their roles. Aymatth2 (talk) 01:32, 4 November 2015 (UTC)
This proposal would seem to increase, not decrease, the number of parameters for each individual citation template, and not decrease the number of parameters editors need to know about. Currently, most contributors to a reference are represented by two or three parameters: surname, given name, and possibly authorlink. Your proposal would make that three or four, by adding a role for each contributor. In addition, currently, in most cases editors need to know only about author and editor parameters, which act much the same as each other. Your proposal would replace these with a single combined set of parameters, but would add the new role parameter, and a lot of special keywords for the role, not really reducing the cognitive load of working with these parameters. So overall it seems like an increase rather than a decrease in editor effort, for little purpose. —David Eppstein (talk) 02:35, 4 November 2015 (UTC)
Yes. The standard and long-accepted practice is that we have a list of authors, and it is implicit that every person (or entity) in that list is an author (coauthor). In this proposal that characterization (the metadata) is elsewhere, we have to consult a different list (of roles) to if a given person is an author, or something else. And we have to always do it, because we can never be certain without checking. It also plays hob with bibliographic sorting and indexing, because this is (and should be) done by authors, without regard to illustrators, caterers, personal assistants, etc. And if a person has more than one role, than s/he has to be listed more than once. This is more complex. ~ J. Johnson (JJ) (talk) 21:05, 4 November 2015 (UTC)
  • @J. Johnson: This may be getting into too much detail but... The article text will be parsed and loaded into memory structures, assembling items like name2, first2, last2, link2 and role2 into array entry 2, then reformatted and written out as HTML. Output code that is only interested in authors will only look at entries for authors. If a person has more than one role and both are important, they must both be identified. Today that would mean something like |last=Smith|first=John|others=Smith, John (illustrator). In the new scheme it would be like |last=Smith|first=John|role=author, illustrator, which seems a bit more natural. Aymatth2 (talk) 02:50, 5 November 2015 (UTC)
Scenario Current Proposed
Author only |last=Smith |first=John |last=Smith |first=John
Author and editor |last=Smith |first=John|editor-last=Doe |editor-first=Jane |last=Smith |first=John|last2=Doe |first2=Jane |role2=editor
Author and preface |last=Smith |first=John|others=Bloggs, Fred (preface) |last=Smith |first=John|last2=Bloggs |first2=Fred |role2=preface
Author, editor and preface |last=Smith |first=John|editor-last=Doe |editor-first=Jane|others=Bloggs, Fred (preface) |last=Smith |first=John|last2=Doe |first2=Jane |role2=editor|last3=Bloggs |first3=Fred |role3=preface
With this enhancement. the WP editor uses the |author= parameter set, which now includes |role=, for all names. They do not need the |editor= set and |others= for the names that do not fit. Typed characters are about the same. I would not enforce a standard on values for |role=, any more than standards are enforced for |others=, although the documentation should give examples, and we could generate abbreviations for the common values (e.g. "Editor" becomes "ed."). Apart from the simpler and more consistent syntax, with no significant change in the amount of typing, by taking names out of the |others= parameter the change makes it practical to consolidate the names in the displayed citation. although this is a separate discussion:
Scenario Current Possible improvement
Author only Smith, John (1977). Tropical penguins.  Smith, John (1977). Tropical penguins.
Author and editor Smith, John (1977). Doe, Jane, ed. Tropical penguins.  Smith, John; Doe, Jane, ed. (1977) Tropical penguins.
Author and preface Smith, John (1977). Tropical penguins. Bloggs, Fred (pref.).  Smith, John; Bloggs, Fred, pref. (1977) Tropical penguins.
Author, editor and preface Smith, John (1977). Doe, Jane, ed. Tropical penguins. Bloggs, Fred (pref.).  Smith, John; Doe, Jane, ed.; Bloggs, Fred, pref. (1977) Tropical penguins.
It also makes it possible to generate COinS metadata for all the names, once the standard has been upgraded to allow multiple authors. However, as J. Johnson (talk · contribs) points out, it would mean changing long-established practice, and that is not how things are done. This seems rather an obscure place to discuss it. @Trappist the monk: Is there a better forum? Aymatth2 (talk) 13:13, 4 November 2015 (UTC)
&[2..n] is a repeatable parameter so all authors are included in the COinS. Editors, translators, illustrators and names listed in |others= are not made part of the metadata because there are no key/value pairings defined for them.
  • That makes more sense. I could not see how there would be no support for multiple authors. But I am surprised at the lack of support for roles. The national libraries all index by role, which seems an obvious thing to do.
This is the proper forum for any and all topics relating to cs1|2 citation templates. You might post a note referring to this discussion at other talk pages; WT:CITE might be one-such.
Trappist the monk (talk) 16:38, 4 November 2015 (UTC)
Aymatth2: your example is inconsistent in how you apply |role=. An editor is a person with a certain function (or role); a preface is not a role, but an object (item?) for which someone might have a certain responsibility. Which might be in the form of writing it, editing it, or even illustrating it.
  • My spell checker shows "prefacer" as an error. Whatever the WP editor thinks best reflects the role defined in the book. Aymatth2 (talk) 22:20, 4 November 2015 (UTC)
So is your "prefacer" the person who wrote the preface? Or edited it? Or illustrated it? What if these are three different people? ~ J. Johnson (JJ) (talk) 01:24, 5 November 2015 (UTC)
You state that "national libraries all index by role". I don't doubt that. But I think they index them separately. Can you provide any examples where a work's authors are merged with the editors (etc.)? ~ J. Johnson (JJ) (talk) 21:25, 4 November 2015 (UTC)
  • The BnF entry for Edward Weston, 1886-1958 / essay by Terence Pitts ; a personal portrait by Anselm Adams has links to Pitts, Terence (as author), Adams, Ansel (as illustrator), Heiting, Manfred (as editor), Bosser, Jacques (as translator), Himmelberg, Wolfgang (as translator) and Weston, Edward (as subject). The BnF entry for Ansel Adams lists works by Adams as photographer, text author, illustrator, prefacer etc. I do not know how BnF represents the information internally. The syntax proposed above would do the job, or they may use a relational data structure updated by forms. I have no idea. Aymatth2 (talk) 22:20, 4 November 2015 (UTC)
I don't know how much citations are done differently in French and German, but as this is the English Wikipedia I think we should stick with examples in English. Regarding your BnF example, that is more in the nature of an old-fashioned catalog card, presenting all the information they have about that item. And while it contains the information that would be used in creating a citation, it is not an example of a citation. And as you "have no idea" of the internal representation, you really cannot claim that they are using this scheme you propose here. ~ J. Johnson (JJ) (talk) 01:26, 5 November 2015 (UTC)
  • National libraries provide indexes, not citations. They are relevant when discussing metadata. Citation style guides discuss output formats. We are on our own in deciding how we should represent information about a book internally. This proposal suggests a simpler and more flexible internal syntax. Aymatth2 (talk) 03:43, 5 November 2015 (UTC)
Yes, libraries provide indexes. We provide only citations, with the bibliographic detail appropriate for that purpose. (And I concur with Imzadi's remarks, following.) How libraries might represent information internally – which you admit you don't know – is entirely irrelevant for us. The bottom line here is: your proposed scheme is NOT "a simpler and more flexible internal syntax." ~ J. Johnson (JJ) (talk) 22:51, 5 November 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I understand what the proposal is trying to do, but the question comes down to what the core purpose of a citation is. The purpose is to identify the source so that a reader can locate his or her own copy for verification purposes. No more, no less, and I think this proposal is exceeding that core purpose. In short, we are generating citations, and we should be looking at citation guides, not library catalogs for guidance here.

Maybe someday we'll have Wikidata items on every individual source, and then those WD records can store all of the misc. contributor information while our citations parse that information for display in a standardized format in the guise of footnotes. Until then, I don't see a need for this level of complexity here. Imzadi 1979  04:41, 5 November 2015 (UTC)

  • Something tells me this proposal is not getting a lot of traction. Maybe it is just too different... Four comments:
No, it's just too wrong. ~ JJ 23:03, 5 November 2015 (UTC)
  • The proposed change is a simplification since it reduces the number of parameters an editor needs to use. There is less complexity. Aymatth2 (talk) 13:10, 5 November 2015 (UTC)
As has been explained: your proposal is NOT a simplification, does NOT reduce the number of parameters (actually increases them), and is MORE complex. ~ JJ 23:03, 5 November 2015 (UTC)
  • The purpose of a citation is to identify the source and give due credit. If a foreword is being cited, the author of the foreword should be identified. If a translation is being quoted, the translator should be identified. Aymatth2 (talk) 15:51, 5 November 2015 (UTC)
In the immediately preceeding discussion (#Forward) Imzadi showed (22:58, 31 Oct) how to cite the author of a foreword (see second form), which can be generalized to all similar cases. ~ JJ 23:03, 5 November 2015 (UTC)
  • The change gives greater structure, which makes it easier to ensure the displayed information has standard format. Most citation guides give rules for where and how "preface", "translator" etc. should be represented. MLA style examples:
With the present WP style the secondary contributors get stuck at the back in random format. Aymatth2 (talk) 13:10, 5 November 2015 (UTC)
Secondary contributors "get stuck at the back" because they are, well, secondary. How to specifically cite such secondary contributions has already been shown. ~ JJ 23:03, 5 November 2015 (UTC)
  • The greater structure also makes it practical to generate more useful metadata, helpful in linking Wikipedia and other databases. Aymatth2 (talk) 13:10, 5 November 2015 (UTC)
Wikipedia is an encyclopedia, not a bibliographic database. We provide links, starting with the ISBN, to most bibliographic databases. We don't do databases, the database people don't do encyclopedias. ~ J. Johnson (JJ) (talk) 23:03, 5 November 2015 (UTC)

VE messing up language parameter[edit]

VE is messing up the |language= parameter. It is adding en-US, en-GB, etc. Articles with this problem are ending up in Category:CS1 maint: Unrecognized language. Examples are [4] and [5]. I've filled ticket T117305.

Also of note, VE is adding nowiki tags inside references. For example, <ref><nowiki>{{cite ... }}</nowiki></ref>. A ticket on that was filed, mysteriously closed and we've reopened it again.

I haven't checked if Content Transcrapulator is doing the same problem. It and VE both use Parsoid, but different versions. So, one has to file two separate bug reports. As only a couple of our groups 40+ tickets have been fixed in 6+ months, so I don't expect this to be fixed anytime soon. Bgwhite (talk) 07:12, 31 October 2015 (UTC)

I thought that Monkbot or BattyBot had an approved task to sweep Category:CS1 maint: Unrecognized language for easy-to-fix errors like |language=español and like the one above, but I don't see that task in either bot's task list. My memory is failing me. – Jonesey95 (talk) 18:10, 31 October 2015 (UTC)
I have an AWB script that does that but haven't run it in a while. I'm doing other work elsewhere with AWB right now so I'll try to remember to run the language script when I'm done with that other task.
Trappist the monk (talk) 19:01, 31 October 2015 (UTC)
Visual Editor is a complete mess and should be buried deep.
Having said this, wouldn't it make sense to add support for these standardized language codes to the |language= parameter and let the template translate them into something meaningful for display in the citation? It doesn't seem to be much more than adding a long look-up table with aliases. If the value is found in there, it gets replaced, otherwise left as is. In the long run, this would improve machine-readability and the reliable conversion of citations for usage in other language Wikipedias. --Matthiaspaul (talk) 17:01, 1 November 2015 (UTC)
The module uses a call to mw.language.fetchLanguageName () which apparently refers to this php list. That list appears to have all of the ISO 639-1 two-character language codes so it is a convenient way to map codes to readable names. IETF language tags can be rather complicated and as such I didn't want to venture down the path of dissecting that. It is possible that we could extend language code validation to include only ISO 3166-1 alpha-2 country codes. ISO maintains a list of currently assigned code elements so making a Lua look-up table wouldn't be difficult. Then, the test is: for any hyphenated language name in the case-insensitive form ll-cc, ll must be a valid ISO 639-1 code and cc must be a valid ISO 3166-1 alpha 2 country code.
I don't know if there is a list of 'valid' pairings of the items on either side of the hyphen: |language=pt-IS (Portuguese as spoken in Iceland) would pass the just-described test but doesn't make a lot of sense. It's probably not much of an issue but typos do happen. Still, the only thing that would be displayed would be the translation of the ISO 639-1 code (except for English which isn't displayed on en:WP.
Trappist the monk (talk) 20:04, 1 November 2015 (UTC)
Sounds good to me. --Matthiaspaul (talk) 12:36, 2 November 2015 (UTC)
  • How about fixing CS1 instead? en is presumably recognised. Per long-established practice at the relevant RFC, en-GB, en-US and en-Geordie are all acceptable. They may not be recognised, but the regional sub-variation should be ignored by any compliant consumer that doesn't recognise it and the main language code processed correctly anyway.
It is never a good idea to start pruning stored metadata just because one consumer is failing to accept something that it ought to. Andy Dingley (talk) 19:21, 3 November 2015 (UTC)
I don't see where it was suggested to prune any metadata - that would be a bad idea. But yes, |language= should be expanded to accept language codes, as I suggested as well.
--Matthiaspaul (talk) 00:13, 4 November 2015 (UTC)
[6] (and many others by Trappist the monk). That's how I first noticed this issue. Andy Dingley (talk) 16:19, 4 November 2015 (UTC)
I see, thanks. No good. I agree, when the full language specifier isn't known, it should still be accepted (if its format is correct). The code should then ignore the regional sub-variant and just use the main code. --Matthiaspaul (talk) 05:56, 5 November 2015 (UTC)

Since the time of first support for ISO 639-1 codes in |language=, cs1|2 has only supported the two-character code or the language's proper name. There has never been any representation anywhere that IETF language tags or similar extensions are supported. That VE ignores the documentation is not the fault of cs1|2.

I have tweaked Module:Citation/CS1/sandbox so that it ignores IETF language tags:

{{cite book/new |title=Title |language=pt-IS, English, fr-fr}}
Title (in Portuguese, English, and French). 

Trappist the monk (talk) 13:41, 10 November 2015 (UTC)

What to use?[edit]

Sorry. I must have been confusing myself. Anyway, this is where I should probably ask for guidance. What to use for the following materials found on the website of, for instance, The Guardian, a British national daily newspaper? Such materials may or may not be found on the print version.

  • A news article.
  • An album review.
  • An interview.
  • Just any entry such as table, chart, etc.

Appreciate advice. Thanks. --Efe (talk) 13:01, 31 October 2015 (UTC)

{{cite news}} or {{cite website}} can be used to cite a news source in all of those cases, though most at this page usually tend to prefer Cite news since it is more semantic to the type of source being cited (regardless whether the source was printed online or offline). Example: {{cite news |url= |publisher=The Guardian |title=Example Title |date=October 31, 2015}} generates "Example Title". The Guardian. October 31, 2015.  In the case of an interview, I would probably tend toward using {{cite interview}} instead, since I don't think {{cite news}} can handle the interviewing piece of it. --Izno (talk) 13:23, 31 October 2015 (UTC)

The confusion (of mine) arises in those cases. It is more on the source (The Telegraph), or the material (album review) being cited? --Efe (talk) 13:28, 31 October 2015 (UTC)
The material, in the general case. We don't have anything like a "cite album review" since album reviews will generally be found on a website or in a magazine, for which we have {{cite magazine}} (with optional |url=) and {{cite website}}. --Izno (talk) 13:48, 31 October 2015 (UTC)
Hi Izno, apparently I came here because there seems to be a restrictive use of templates. For instance, if it's coming from Billboard, the {{cite journal}} was used throughout a given article. Although MOS stipulates that uniformity of style should be achieved. So, for clarification, I'm using the following examples all from Billboard site:
Am I close to being proper? --Efe (talk) 18:23, 31 October 2015 (UTC)
You can use {{cite web}} for basically any web-based source and no-one will bat an eye. Generally, the guideline "same citation style" extends only to how you format the citations at a broad level and not usually whether a specific template in the CS1 family is the correct template. on As I have already said, you should prefer a more specific type of template if you can. --Izno (talk) 12:47, 2 November 2015 (UTC)

Pages using citations with format and no URL[edit]

Pershing missile bibliography is in Category:Pages using citations with format and no URL. I enabled the error message but I still don't see what is wrong in that article. --21lima (talk) 14:54, 31 October 2015 (UTC)

One citation had |url= and |chapter-format=. Kanguole 15:12, 31 October 2015 (UTC)
Thanks. |chapter-format= does not generate an error message: title.  --21lima (talk) 15:31, 31 October 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Because the cite used {{cite journal}}, |chapter= is not part of the rendered display. When |chapter-format= is set, it is error checked and if there is no |chapter= (or alias) then an error message is added to the content of |chapter-format= and an error category is added to category list. Because this cite is {{cite journal}}, all of the chapter parameters (except |chapter-format=) are set to empty strings and |chapter-format= is simply ignored.

I have modified the sandbox so that meta-parameter ChapterFormat is not error checked for cs1|2 templates that don't support chapter parameters. Instead, ChapterFormat is checked for content and if set, the parameter-ignored-error-message and category are added to the rendered output.

Cite journal compare
{{ cite journal | url= | publisher=[[National Air Intelligence Center]] | title=Introduction to the Scene Matching Missile Guidance Technologies | chapter-format=PDF | others=SCITRAN (trans.) | author=Shi-Xue Tsai }}
Live Shi-Xue Tsai. "Introduction to the Scene Matching Missile Guidance Technologies". SCITRAN (trans.). National Air Intelligence Center. 
Sandbox Shi-Xue Tsai. "Introduction to the Scene Matching Missile Guidance Technologies". SCITRAN (trans.). National Air Intelligence Center.  |chapter-format= ignored (help)

This change also fixes an ignored parameter bug where a parameter's name is left out of the error message:

Cite journal compare
{{ cite journal | title=Title | script-chapter=Script-Chapter | journal=Journal }}
Live "Title". Journal.  |= ignored (help)
Sandbox "Title". Journal.  |script-chapter= ignored (help)

For {{cite book}} and other non-periodical cs1|2 templates that do support |chapter= and aliases and related parameters, the extant code ignores the chapter-format-requires-url error message because ChapterFormat (which has the error message) is not concatenated onto Chapter. I have changed the code so that Chapter gets the value of ChapterFormat when set:

Cite book compare
{{ cite book | chapter-format=chapter-format | title=title }}
Live title. 
Sandbox (chapter-format). title. 

Trappist the monk (talk) 16:57, 31 October 2015 (UTC)

That makes sense. --21lima (talk) 14:37, 1 November 2015 (UTC)

metadata and identifiers[edit]

cs1|2 includes the predefined identifiers, |arxiv=, |doi=, |jstor=, |isbn=, etc in the metadata. Most of these inclusions are wrong.

COinS provides keywords for |isbn= and |issn=: &rft.isbn and &rft.issn. Another keyword, &rft_id supports various forms of url. Which of these two mechanisms we use is specified in the id_handlers table in Module:Citation/CS1/Configuration. Each identifier has a table of stuff unique to that identifier, one bit of which is the COinS entry. When the value assigned to the identifier's COinS entry is info:..., code in Module:Citation/CS1 concatenates info:... and the identifier value and assigns the result to &rft_id. In all other cases, id_handlers[...].COinS is expected to hold something that looks like rft.jfm (the ampersand is added later). For these, the final metadata for |jfm=1234 eventually looks like this: &rft.jfm=1234.

But not all is well in metadata land. There are defined keywords for some of the identifiers that we support but not all. The rft.jfm example above is one-such that is not defined as a legitimate metadata keyword. Also, there are some like |asin= where id_handlers['ASIN'].COinS is set to info:asin. To use the info: uri, the domain name (asin in this case) must be registered at //

So, in the sandbox I have made some changes:

  1. in Module:Citation/CS1/Configuration/sandbox:
    1. created the keyword pre which tells code in Module:Citation/CS1/sandbox to use id_handlers[...].prefix when creating &rft_id
    2. set id_handlers[...].COinS to nil for identifiers asin, ismn, and ol to keep them out of the metadata
    3. changed id_handlers['LCCN'].COinS from unsupported rft.lccn to supported info:lccn
  2. in Module:Citation/CS1/sandbox:
    1. modified COinS () to distinguish between id_handlers[...].COinS values of info:... and rft...

The identifiers that I have set to nil (asin, ismn, and ol) are problematic. There isn't a place like Special:BookSources that ismn can link to nor is there an external repository so ismn is not included in the metadata. The other two are more complicated.

An ol identifier produces a url path that varies with the value of the last digit of the identifier value ('A', 'M', or 'W' → '/authors/OL/', '/books/OL/', /'works/OL/') which is inserted between id_handlers['OL'].prefix and |ol=. The resultant url is id_handlers['OL'].prefix + '/authors/OL/' or '/books/OL/' or /'works/OL/' + |ol=. I think that it is possible to solve this problem by simply creating three handlers that replace the one that we use now.

Similarly, an asin url can have a variety of top-level domains (.com, .au, .br,, etc); there is also a path specifier inserted between the tld and the |asin= value so the url is the concatenation of id_handlers['ASIN'].prefix + |asin-tld= or '.com' + '/dp/' + |asin=. I haven't noodled out a solution for this problem yet.

Trappist the monk (talk) 14:08, 1 November 2015 (UTC)

Bump to keep this topic from being archived.

Trappist the monk (talk) 13:00, 10 November 2015 (UTC)

non-English in date parameter[edit]

Not sure if BattyBot or one of the other bots fixes these.... Content Transcrapulator doesn't translate the contents of |date=, if it translates the cite template at all. Does the bots fix |accessdate=13 de diciembre de 2013 or if the cite template wasn't translated at all, ie |fechaacceso=13 de diciembre de 2013? Bgwhite (talk) 08:17, 2 November 2015 (UTC)

I think that the |accessdate=13 de diciembre de 2013 is the sort of thing that BattyBot 25 is intended to fix; don't know about the other. When I looked in the script for the terms diciembre and fechaacceso I didn't find them. What is Content Transcrapulator?
Trappist the monk (talk) 11:18, 2 November 2015 (UTC)
There is no bot that fixes |fechaacceso=, but I clean out the "unsupported parameter" category almost every day. Once I turn that parameter into |access-date=, BattyBot will find and fix the dates.
BattyBot Task 25 will find and fix dates in Spanish and many other languages. The key line is here:
ArticleText = Regex.Replace(ArticleText, @"(?i){{(\s*[Cc]it(?:e|ation))([^}]+)(\s*\|\s*archive-?date\s*=\s*\d{0,2}[\.,]?\s*)(?:(?:de )?(?:de[csz]embr[eo]|d[éi]ci?embre)(?: del?)?|d?e[csvz]m?e?w?mn?e?b+[ae]?r?|d[ec]+mber|decembrie|Decembwe|Disember|grudnia|декабря|декабрь|Декември|децембар|aralık|grudzien|prosinec|Rhagfyr),?\s*(\d{0,2}(?:st|nd|rd|th)?,?\.?\s*\d{4})(?:\s*г(?:ода|\.?))?,?(\s*[\|}<])", "{{$1$2$3December $4$5");
Very clever BattyBot. It runs about once a month.
"Content Transcrapulator" is Bgwhite's affectionate name for the beta "Content Translation" gadget that a few of us gnomes clean up after. It has a few bugs, like any beta software. – Jonesey95 (talk) 14:02, 2 November 2015 (UTC)
BattyBot maybe clever, but GoingBatty is a genius for creating it. Sorry, but Content Transcrapulator is not beta quality. It is horrid. But what makes it worse is all the new editors, who don't know English, creating articles. Bgwhite (talk) 20:12, 2 November 2015 (UTC)
@Bgwhite: Thanks for the kind words. BattyBot 25 will fix dates in many date parameters, it doesn't fix |fechaacceso=, because AWB's order of procedures runs the custom module before replacing template parameters. I haven't run that task in a while, so I'll do it soon. Thanks for the reminder. GoingBatty (talk) 03:37, 3 November 2015 (UTC)

Online date[edit]

An increasing number of journals have an "online first" date as well as a printed publication date. Often, the same article has two dates — the date it was first printed online, and the date of the physical paper copy. Is it possible to have a "first online" parameter? Or isn't it important to note that? (Given that the online version can appear many months before the printed one, I'd suggest it might be!) MeegsC (talk) 14:18, 4 November 2015 (UTC)

Use |date= to cite the publication date (on-line or in print) of the version you are citing to support a statement in a WP article. You don't have to overcomplicate it. – Jonesey95 (talk) 15:22, 4 November 2015 (UTC)
It's even simpler than that. The online version is a true copy of the print version, and the usual citation form for a journal article gives the volume and issue with the date they were printed. The online date is more detail than is needed. Kanguole 15:49, 4 November 2015 (UTC)
The online version for a newspaper article does not always give the page number for the physical publication. Nor does the online version of a periodical always give the volume or issue. In such cases the online date may be vital. And even for a print publication I think the publication date provides very helpful context in many cases, and should always be included in the cite if it is available. It can help in detecting out-of-date sources, or seeing a timeline of sourcing on rapidly changing events, where some events may have occurred after the pub date. Depending on the publication, it may also be easier to find by date than by vol/issue. For academic journals vol/issue is generally best, but not always for other publications, which still often use {{cite journal}} as if it were {{cite magazine}}. If both dates are present, I would use the earlier, as that is when the articel was first published in any medium. DES (talk) 19:27, 4 November 2015 (UTC)
I beg to differ: on-line versions often are not "a true copy of the print version", as the on-line versions sometimes reflect corrections. (Alternately, an on-line pre-print might not include late changes to the printed version.) A print version needs the actual date of print publication, and on-line version needs its own publication/revision date. Of course, sometimes those dates are not updated, so access-date is always important. ~ J. Johnson (JJ) (talk) 21:36, 4 November 2015 (UTC)
This isn't about author versions, but the electronic version offered by the journal, e.g. doi:10.1111/ibi.12129. The PDF there is an accurate reflection of the print copy. They also tell you how to cite the article, and that invariably uses the date of print publication. Kanguole 12:05, 5 November 2015 (UTC)
Perhaps you took "pre-print" too narrowly? I was referring to the "electronic" versions that come out ahead of the print copy. Which is usually produced from the same source as the the print copy, and so are as identical as is possible at the time of publication. But sometimes post-publication corrections or revisions are necessary, which, of course, can be done only in the on-line ("electronic") version. Same with retractions. So while the official date of publication is usually that of the print version, any subsequent revision will be found only in the on-line version, which has its own date. ~ J. Johnson (JJ) (talk) 23:27, 5 November 2015 (UTC)
Journals typically allow authors to publish errata or even to retract their papers, but do you know of any that allow post-publication corrections or revisions to the online version? Kanguole 02:16, 6 November 2015 (UTC)
Journals, no. Newspapers, yes. And our citation formatting code treats both of those as the same sort of thing. —David Eppstein (talk) 03:54, 6 November 2015 (UTC)
Journals yes. In theory I think all of them. I have seen such in Science, maybe Nature, and more than one geology journal. Off-hand I don't recall any specific cases, but for an example see this Supporting Online Material Erratum from Science, where a post-publication revision was made. Others are readily found (search for "corrections and clarifications"). ~ J. Johnson (JJ) (talk) 22:47, 6 November 2015 (UTC)
That particular example is an update to the online supporting material rather than the paper. Regarding corrections and clarifications, it seems that they are applied to the HTML version, but the PDF version is retained unmodified, but a separate erratum is added. Kanguole 00:26, 7 November 2015 (UTC)
The erratum was added to the pdf, becoming part of it. If you download the Full Text (PDF) what you get says right across the top: "CORRECTED 1 AUGUST 2008; SEE LAST 2 PAGES". And in the erratum it says: The incorrect version of Fig. 3 has been published in both the online Science Express version and the printed version of the paper. The correct Fig. 3, ... is shown here." Anyone relying on the print version, the original on-line "Full Text (PDF)", or the Science Express version (published 14 Feb.) downloaded any time prior to around 1 August would have a discrepancy with the corrected version. In this case the discrepancy is small, but crucial revisions and even retractions are handled the same way. If I cite a paper that I know has been corrected I would even add a comment to that effect lest some WP editor relying on a print copy takes exception. ~ J. Johnson (JJ) (talk) 22:09, 7 November 2015 (UTC)
P.S. It looks like the pdf linked above is behind the pay-wall. If you are really want to see it try accessing it from a university library. Or send me an e-mail. ~ J. Johnson (JJ) (talk) 22:14, 7 November 2015 (UTC)

Page display in journal could use improvement[edit]

If you use the journal template an specify a page range, you get something like "The Journal. pp. 62-64". However, if the article is a single page, and many are, you get something like "The Journal. 64" This doesn't make it obvious what the "64" is, I confused it with the issue or volume. Is there any reason this isn't "The Journal. p. 64"? Maury Markowitz (talk) 15:32, 5 November 2015 (UTC)

It's not |page= vs |pages= that makes the difference, but {{cite journal}} vs {{cite news}}. The short form is common with journal citations, where there is typically a volume and possibly an issue number before the colon. Kanguole 16:21, 5 November 2015 (UTC)
It most certainly is page vs. pages. Try it yourself, or check out the Slime (video game) article. Maury Markowitz (talk) 17:43, 5 November 2015 (UTC)
@Maury Markowitz: ok, I tried it. If you have |volume=, which should always be the case for a journal (I think), it's ok:
  • {{cite journal |author=Smith |date=2015 |title=Some article |journal=Some journal |volume=1 |page=1 }} → Smith (2015). "Some article". Some journal 1: 1. 
  • {{cite journal |author=Smith |date=2015 |title=Some article |journal=Some journal |volume=1 |pages=1–100 }} → Smith (2015). "Some article". Some journal 1: 1–100. 
However, if you omit |volume=, then you do get a strange and unhelpful format:
  • {{cite journal |author=Smith |date=2015 |title=Some article |journal=Some journal |page=1 }} → Smith (2015). "Some article". Some journal: 1. 
  • {{cite journal |author=Smith |date=2015 |title=Some article |journal=Some journal |pages=1–100 }} → Smith (2015). "Some article". Some journal: 1–100. 
I think the best solution may be to flag an error if |journal= isn't accompanied by |volume=. It's not desirable to insert "p." or "pp." because these are sometimes needed to identify a location in a long journal article while distinguishing between the page range of the journal in which the article appears and the page being referred to, as in:
  • Smith (2015). "Some article". Some journal: 30–190.  p. 54.
Peter coxhead (talk) 18:00, 5 November 2015 (UTC)
I'm somewhat confused why you suggest a change that does not address the formatting problem I'm actually having, and instead changes a very common usage to be an error. I'm even more confused why you think putting "p." in the reference, which is what we do everywhere else, is the wrong solution. Can you explain your logic here? Maury Markowitz (talk) 13:25, 6 November 2015 (UTC)
Peter, that is why we use SFN, to identify locations within a larger work. Maury Markowitz (talk) 18:23, 5 November 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The "volume: page-range" format is a space-saving convention borrowed from scientific publications. I'm not convinced that it's helpful on Wikipedia, where we don't need to save space and can't expect all readers to be familiar with scientific publishing conventions. I would be happy if we changed it to spell out "vol." and "pp." (or "p.") in all cases, e.g.

Smith (2015). "Some article". Some journal, vol. 1, pp. 1–100.

But that's a big change, so it would take a lot of effort to build a consensus. Fixing the templates so that single-page and multi-page journal articles are always formatted consistently with each other even when they don't have a volume seems like a no-brainer. —David Eppstein (talk) 19:05, 5 November 2015 (UTC)

@Maury Markowitz: if the only use of a source is for a single page, it's awkward and over the top to use {{sfn}}; you have to put the main citation in a "bibliography list" and then the use of {{sfn}} generates a reference to it in a references list.
@David Eppstein: all the tests I've tried show that single and multiple page journal articles are formatted in the same way. The problem is that without |volume= they generate forms like "Some journal: 32" and "Some journal: 32-56".
@Maury Markowitz and David Eppstein: if |volume= must always be present (and I think it has to be for a genuine journal) then the problem goes away. I haven't seen any reason put forward as to why a volume-less journal citation is needed. Peter coxhead (talk) 11:18, 6 November 2015 (UTC)
Because the vast majority of journal citations used on the wiki don't have a volume. The journal template is not used just for "true journals", but any sort of periodical. I'd say the cites without volume outnumber the ones with one at least 9 to 1.
But what really confuses me is why you would suggest that that the current format is "correct" or "better". It's certainly not obvious to the casual reader, which is the subject of all of our writing. Can you perhaps explain why you think the "p." is something that should not be there? I really cannot see a cogent argument being offered to date. Maury Markowitz (talk) 13:25, 6 November 2015 (UTC)
Do you have evidence to support your claim that the vast majority of journal citations used on the wiki don't have a volume?
If I follow the link in the Backer cite @ Slime (video game), right there at the top of the cover it shows volume 1, number 5. Adding those to the {{cite journal}} template:
{{cite journal |first=Paul |last=Backer |url= |title=Slime |journal=Electronic Fun |date=March 1983 |volume=1 |number=5 |pages=66-67}}
Backer, Paul (March 1983). "Slime" (PDF). Electronic Fun 1 (5): 66–67. 
Trappist the monk (talk) 13:37, 6 November 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Honestly, I have two ideas on how to "fix" this. The first is to automatically add the "p." or "pp." in front of the page number(s) if there is no volume or issue number specified. The second option is add "vol.", "no." and "p."/"pp." to all of the various numbers in a journal citation. (If we automatically add the "vol.", then I would drop the boldface as well.) That's just my thoughts. Imzadi 1979  15:07, 6 November 2015 (UTC)

The second of Imzadi 1979's options is the one that is clear to everyone what the meaning is so would be my preferred option. Keith D (talk) 17:12, 6 November 2015 (UTC)
I also support the display of "p." and "pp." and "vol." and "no." Science journals leave these out because space is tight, because they assume a certain knowledge among their readers, and because they have editors who can make sure that every citation contains a volume, issue, and page numbers. We have none of those things at Wikipedia, so a different approach is justified. I think it is needlessly obscure to hide those labels and assume that lay readers will figure out the meaning of the bold/colon/parentheses arrangement. – Jonesey95 (talk) 20:56, 6 November 2015 (UTC)
The first of these ideas would be a clear improvement. The second would also change the formatting of working citations, and should not be done without wider consultation. Kanguole 00:38, 7 November 2015 (UTC)
Absolutely agree would be much clearer with Imzadi 1979's suggestion, vol., no., p. or pp. (It would also be great if an actual non-techy person looked over these suggestions. I spend hours trying to decipher what is meant by some of these "clarifications". SusunW (talk) 22:16, 7 November 2015 (UTC)
  • People need to understand that {{cite journal}} is used for many things that aren't academic journals: It is really in effect cite periodical. Nor am I convinced that all academic journals use volumes numbers, although to be sure the vast majority do. I see no valid reason not to display "p." and "pp." or even "page" and "pages" as well as "vol" when the relevant parameters have been filled in, and much benefit. DES (talk) 17:33, 8 November 2015 (UTC)
I for one (and I'm sure there would be many, many other editors), would strongly object if tens of thousands of existing citations suddenly changed from the familiar "3(3):3–100" style to something else. This would also seem to be in direct contradiction to WP:CITEVAR – we used the template to achieve the formatting it does, and this should not be changed.
If, and I'm yet to be convinced, there are legitimate uses of {{cite journal}} (or {{citation}} with |journal=) without the volume parameter, then the format for these cases could be changed. If it's actually the case that {{cite journal}} is being used for publications that intrinsically don't have a volume, then a different template is needed. Peter coxhead (talk) 21:18, 8 November 2015 (UTC)
@Peter coxhed: I'm still trying to understand your objection here. Why do you feel this is not a good idea. I can only speak for myself, but "3(3):3–100" is simply gobbledygook, and I say that as a physicist. Try as I might, I cannot understand any situation where "vol:3 num:3 pp:3–100" is anything but a gigantic improvement. Can you explain your concern? Maury Markowitz (talk) 15:30, 11 November 2015 (UTC)

Perhaps the time has come to tighten the definition of {{cite journal}} to be strictly for academic journals and make a real template out of the redirect that is now {{cite magazine}}. {{cite journal}} would keep its familiar abbreviated form and {{cite magazine}} would use something akin to 'vol. #', 'no. #', 'p. #', or 'pp. #'.

I think I recall a similar conversation to this one where it was mentioned that AWB general fixes is currently renaming {{cite magazine}} to {{cite journal}}. That would need to be turned off. For {{cite magazine}}, we would need to decide what the standard prefixes for volume and issue number should be, punctuation (if any), etc.

Trappist the monk (talk) 12:52, 10 November 2015 (UTC)

@Trappist the monk: in principle, that seems a good way forward. The name of the template might be a bit of an issue; there are publications that are thought of as "magazines" that do have volume numbers: National Geographical, for example. Peter coxhead (talk) 10:13, 11 November 2015 (UTC)
Of course. The magazine that is at the root of this issue of the conversation has volume and issue and is a magazine, not an academic journal. I suspect that most periodicals do have these. {{cite periodical}} might do for a template name if {{cite magazine}} is not quite right.
Trappist the monk (talk) 12:38, 11 November 2015 (UTC)
Sorry, back.
I strongly support @Imzadi 1979:'s suggestion to use vol, p and pp. It just makes sense. no, on the other hand, does not. Non-english speakers, and even lots of them too I suspect, will not know that "no" is a short form for "number". If the goal is to make the cites easier to understand num or issue would be better choices.
As to making a new template, well that doesn't fix any of the thousands of instances we already have. Adding p and pp to this template fixes the problem, causes no breakage of existing cites, and requires no changes to existing articles. I cannot see any strong argument for adding yet another, except for semantic clarity, and in that case, simply make the two templates identical except in name. Maury Markowitz (talk) 15:21, 11 November 2015 (UTC)
The abbreviation no. is not so uncommon (if it is uncommon at all) that it shouldn't be used in cs1|2. MOS:NUMERO provides guidance on its use. At least one external style guide (Chicago) suggests the numero abbreviation in journal citations.
This is the English Wikipedia. We do not dumb it down because some readers may not understand all of the nuances of the language.
You are presuming that the thousands of instances we already have are broken. If properly complete {{cite journal}} templates are broken, then wiki projects that make heavy-use of that template would have notified us of their displeasure (WP:MED comes to mind, which project has never been timid about complaining when changes to cs1|2 weren't to its liking).
Trappist the monk (talk) 13:29, 12 November 2015 (UTC)

Citing a television episode without a title[edit]

I have a problem with this citation. The problem is caused by the fact the "Cite episode" template requires that the "title" and "series" parameters are filled in, but the episodes do not have individual episode names. Is there any way around this, or a more suitable template? Betty Logan (talk) 01:21, 7 November 2015 (UTC)

On the video, it says "Series 4 Episode 6" Use "Episode 6", "Episode #4.6" or "#4.6". Also, you can wikilink to Gordon Ramsay's F Word. Bgwhite (talk) 00:40, 8 November 2015 (UTC)

wikilink or url for images in commons[edit]

I've been going thru and removing alot of references that are to Wikipedia I've come across several references that use an image from Commons or Wikipedia. Usually its an image of an old newspaper, but not always. At the moment, I'm whitelisting them, but I wonder if there is a better way. An example from Maryland Route 213 is {{cite map| publisher=[[Bureau of Public Roads]] |title=United States System of Highways |url= |year=1926 |accessdate=2009-04-27}} or from Lizzie Borden {{Cite news |title=Sisters Estranged Over Nance O'Neill |url= |work=[[The San Francisco Call]] |date=June 7, 1905 |accessdate=June 13, 2008}}

Would adding a wikilink to the title be better? Example: [[:Image:1926us.jpg|United States System of Highways]] How would this affect importing the ref into reference software? Bgwhite (talk) 00:55, 8 November 2015 (UTC)

@Bgwhite: at least for the first citation, they could all be switched out to {{cite map |author1= [[Bureau of Public Roads]] |author2= [[American Association of State Highway Officials]] |date= November 11, 1926 |title= United States System of Highways Adopted for Uniform Marking by the American Association of State Highway Officials |url= |scale= 1:7,000,000 |location= Washington, DC |publisher= [[U.S. Geological Survey]] |oclc= 32889555 |accessdate= November 7, 2013 |via= University of North Texas Libraries |last-author-amp= yes}} for two reasons. First, it would link to the source for the current, high-resolution version of the map that's under that file name on Commons, and second, it would provide a fuller citation (correct authors, correct publisher, correct title, missing map scale, full date of publication, etc) over what's been input into some of the citations over the years. I've started replacing some of them, but there's a lot more to go, so it might be a job for someone with AWB access/skills to complete.
As for the core question, I'm not sure what the issue really is. We have many years of AASHO/AASHTO documents hosted on Commons and linked through {{AASHTO minutes}}. In building that template, I intentionally linked through the URL to Commons and noted |via=Wikimedia Commons to indicate that we're citing a document that's only hosted on Commons, not something on Wikipedia. Imzadi 1979  08:14, 8 November 2015 (UTC)
Imzadi1979 Took me a bit to figure what AASHO is and what you were talking about. I'm an expert when it comes to creating confusion. I grabbed the two examples I gave at random. No special meaning was attached. You did solve how to reference the ones about roads. My main question is, what is the best way to reference images on Wikipedia/Commons? I'll leave you a listing of the road articles on your talk page. If you fix or don't fix them, that is fine. Bgwhite (talk) 08:30, 8 November 2015 (UTC)
@Bgwhite: no need to leave me a listing, as I have that. However, it's a mind-numbing and tedious task that someone else could do a lot faster with AWB. Imzadi 1979  08:32, 8 November 2015 (UTC)
@Bgwhite: Imzadi1979's suggestion above of using |via= sounds appropriate to me.—Bagumba (talk) 23:10, 12 November 2015 (UTC)
How would this affect importing the ref into reference software? Making |title=[[:Image:1926us.jpg|United States System of Highways]] does not include the link in the metadata (also gives an access-date missing url error). To make sure that the link is part of the metadata, use |url=
Trappist the monk (talk) 12:27, 10 November 2015 (UTC)

Missing "missing url"?[edit]

I was just editing Lotte Lenya to add the following text and citation:

[[Donovan]]'s 1968 song "[[Laleña]]" was inspired by Lenya.<ref name="AllMusic">{{cite web | last=Greenwald | first=Matthew | title=Lalena | website=AllMusic | accessdate=2015-11-08}}</ref>

which gave me an odd error: the accessdate failed to appear. I eventually figured out I'd left out the "url" (d'oh!), but why didn't I get the big, bold-red "missing url" in the reference list? I tried it on other cite-web uses and found only 3 factors so far:

It never showed the "missing url"
It only lost the accessdate argument, not date, website, or author (had no time for exhaustive examination)
It didn't matter where I put any argument

Could someone look into this? ~ Jeff Q (talk) 03:06, 8 November 2015 (UTC)

cs1|2 does not do big, bold-red error messages. The missing or empty |url= error message is hidden by default as is the |access-date= requires |url= error message. To see these messages, you must enable them. See Controlling error message display. I see two error messages from your example citation:
Greenwald, Matthew. "Lalena". AllMusic. 
Trappist the monk (talk) 03:24, 8 November 2015 (UTC)

No author best practice?[edit]

The documentation specifies author=<!--Staff writer(s); no by-line.--> for a source with no credited author (I should think that the actual text in the comment is free, but the documentation doesn't say that).

In practice, as of today at least including this parameter or omitting all name information gives the same visible result as far as I can see. Example with and without the "author=<null, e.g. comment>" parameter: [1] [2]

With & without author parm

  1. ^ "Billie Fleming obituary". The Daily Telegraph. 30 May 2014. Retrieved 8 November 2015. 
  2. ^ "Billie Fleming obituary". The Daily Telegraph. 30 May 2014. Retrieved 8 November 2015. 

Question: is there a reason for specifying author= instead of simply omitting the author parameter? I would tend to say

if no author is credited, the author= parameter may be omitted, or it may be null with a clarifying comment for other editors such as author=<!--Staff writer(s); no by-line.-->

If I was sure of this I'd edit the documentation, but I'm not. If there is a consensus that this should be changed, could I ask that it be done if I don't happen to see it? Thanks. Pol098 (talk) 12:25, 8 November 2015 (UTC)

Omitting the author may lead a detail-oriented editor or GA/FA reviewer to go searching for an author in the future, for example if the article is being reviewed as part of the good article or featured article process. Making it explicit that there is no named author helps that future editor or reviewer. – Jonesey95 (talk) 17:04, 8 November 2015 (UTC)
Thanks, I thought something like that might be the case. I'd still suggest (assuming there's no special significance to "Staff writer(s); no by-line.") something like

if no author is credited, an empty author= parameter should be used, followed by an explanatory comment for other editors such as |author=<!--Staff writer(s); no by-line.-->|

Pol098 (talk) 21:55, 8 November 2015 (UTC)

|p-prefix= and |pp-prefix=[edit]

Because of the recent discussion involving page numbering, I have been looking at the mess that is page number handling in Module:Citation/CS1. There are two parameters |p-prefix= and |pp-prefix= that are, as far as I can tell, unused and are not documented. These parameters work in non-periodical cs1|2 templates but are ignored in periodical cs1|2. In these examples |pp-prefix=pgs.:

Title. pgs.13–40.  – cs1
Title, pgs.13–40  – cs2
"Title". Journal: 13–40.  – cs1
"Title", Journal: 13–40  – cs2

Because they are not used and because it is the duty of the template to provide static text in cs1|2 citations, I propose to remove these parameters. Because they are unused, deprecation seems unnecessary. Is there any reason to keep them?

Trappist the monk (talk) 16:28, 12 November 2015 (UTC)

If they are truly unused and undocumented, we should remove them from the code.
My experience with our recent transition of |month= and other parameters from deprecated to unsupported was that a few hundred articles were moved from the deprecated parameter category to the unsupported parameter category, despite all of our searching for |month=. The insource search does not reliably find all instances of the thing you are searching for.
That said, if we remove support for it, I'll be happy to clean up instances that may exist. – Jonesey95 (talk) 18:03, 12 November 2015 (UTC)

Now no longer supported:

Title. pp. 13–40.  Unknown parameter |pp-prefix= ignored (help) – cs1
Title, pp. 13–40  Unknown parameter |pp-prefix= ignored (help) – cs2

Trappist the monk (talk) 12:51, 19 November 2015 (UTC)

Ending support for |Ref= (upper case)[edit]

On a similar note to the above section, our remaining deprecated parameters are |coauthors=/|coauthor= and |Ref= (with an upper-case "R"). Given the difficulty of finding |Ref= with an insource search, I propose that we change it to unsupported to remove the last mixed-capitalization parameter from our templates (we have already removed support for the rest, like |Editor=). I'll be happy to lower-case any instances that remain after support is removed. – Jonesey95 (talk) 18:08, 12 November 2015 (UTC)

I support that. Given that only |coauthor= and |coauthors= would then remain on the deprecated list, can we now show its error messages? Earlier this year, I spent much too much time and energy whittling the category down from somewhere around 25000 pages to just more than 10000. That was a mind numbing, arduous exercise that I don't care to repeat. I know that 10k pages is a lot of pages but perhaps if more people can see the error messages, more of these will get fixed. One can always hope...
Trappist the monk (talk) 18:50, 12 November 2015 (UTC)
I haven't formulated an opinion on the coauthor thing but I also support removing upper-case Ref. —David Eppstein (talk) 19:04, 12 November 2015 (UTC)
I will make a separate discussion section for the issue of |coauthor= and |coauthors= to avoid the forking that sometimes arises on this page. – Jonesey95 (talk) 04:14, 13 November 2015 (UTC)

No longer supported. I have removed |Ref= from the whitelist and from the aliases list.

Trappist the monk (talk) 12:24, 19 November 2015 (UTC)


When language=en is specified, it seems to get omitted. I don't think it should, c.f. {{lang|en}}. It's useful when one might expect a citation to be in a foreign language but is in fact in English. (For example, the website of a foreign person or organisation). Or am I just using it wrongly? Si Trew (talk) 03:22, 13 November 2015 (UTC)

The assumption is that since this is the English Wikipedia, that our sources are in English unless specified otherwise. Imzadi 1979  03:28, 13 November 2015 (UTC)
I understand that, and that's usually a fine assumption. I don't just use these for sources but for external links too, so that I get consistent formatting (and access dates and so on) rather than "bare links". But I think that an overriding assumption would be that if an editor has explicitly put this parameter in, that editor wants it for some reason. In my case, and this is not the first time, I felt that a reader's assumption could well be that a website is in a language of its website's top-level domain (country identifier), e.g. a website with a domain name finishing .hu would likely be in Hungarian unless something else strongly indicates otherwise (the title being in English, for example). If the title were in Hungarian but the site/page in English, which might be quite legit e.g. for proper names, then the assumption is flawed.
Of course I can use {{en icon}} in addition to the cite template, but I thought the point of the language= parameter was to deprecate all of that stuff and do it inside the template itself. (Nice to have trans-title now, by the way.)
If we're not to change this (and I imagine not), could we perhaps have the template issue an editor-only warning when lang=en is used, saying that it has no effect (is a NOP)?
I presume lang=English &c. have the same behaviour, but haven't tried. Si Trew (talk) 04:02, 13 November 2015 (UTC)
Hehe, it's a bit queer of me to say "foreign person" when I live in Hungary, but of course, wherever I go, I'm not a foreigner, I'm British. :) Si Trew (talk) 04:07, 13 November 2015 (UTC)
The behavior in question is documented in the templates' documentation. See, for example, Template:Cite book#Title. If you want to see the rationale for this behavior, read Template:En icon, then read this discussion, then read this discussion. – Jonesey95 (talk) 04:31, 13 November 2015 (UTC)

Should we unhide the "deprecated parameter" error?[edit]

In a section above, Trappist the monk suggests unhiding the deprecated parameter error, since only |coauthors=/|coauthor= would remain on our deprecated parameter list. We said that we would unhide the error message when all reasonable bot fixes had been made. I think that we have reached that point. – Jonesey95 (talk) 04:13, 13 November 2015 (UTC)

There having been no opposition, I have set the hidden flag to false.
Trappist the monk (talk) 15:43, 20 November 2015 (UTC)

citing contributed forewords, prefaces etc[edit]

This topic began at Foreword and branches from Moving forward to continue here so that discussion of implementation detail can be separate from whatever conversation continues there.

The model for this feature is this {{cite book}} armature:

{{cite book |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction |last=Orwell |first=George |title=Nineteen Eighty-Four |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}

If the code is right, then Module:Citation/CS1/sandbox should produce citations that look like these hand crafted cites:

Pynchon, Thomas (2003). Introduction. Nineteen Eighty-Four. By Orwell, George. New York: Plume-Penguin. pp. vii-xxvi. (cs1)
Pynchon, Thomas (2003), Introduction, Nineteen Eighty-Four, by Orwell, George, New York: Plume-Penguin, pp. vii-xxvi (cs2)

The tests:

{{cite book/new |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction |last=Orwell |first=George |title=Nineteen Eighty-Four |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}
Pynchon, Thomas (2003). Introduction. Nineteen Eighty-Four. By Orwell, George. New York: Plume-Penguin. pp. vii–xxvi. 
{{citation/new |contributor-last=Pynchon|contributor-first=Thomas|contributor-link=Thomas Pynchon|contribution=Introduction |last=Orwell |first=George |title=Nineteen Eighty-Four |location=New York |publisher=Plume-Penguin |date=2003 |pages=vii-xxvi}}
Pynchon, Thomas (2003), Introduction, Nineteen Eighty-Four, by Orwell, George, New York: Plume-Penguin, pp. vii–xxvi 

Since this is the first test, something is bound to be wrong. In this case, 'By' should be in lowercase in the cs2 version.

Contributor has the standard enumerated suite of name parameters and modifiers. et al is not supported. This facility is only available for {{cite book}} and {{citation}} (where |work= or aliases is not set). The module understands the common contribution titles 'afterword', 'foreword', 'introduction', and 'preface' and renders these upright without quotes. For contributions that are not any of these four, the contribution title is quoted:

"Contribution". Title.  |contributor= requires |author= (help)

When |contributor= is set and |contribution= is not set the module emits an error:

"Chapter". Title.  |contributor= requires |contribution= (help); |contributor= requires |author= (help)

Errors of this type will be categorized in Category:CS1 errors: missing contribution

Still to do:

  1. fix the casing of 'by'
  2. adjust the CITEREF anchor creation to use the contributor name list when |ref=harv
  3. adjust the metadata creation to use the contributor name list instead of the author list
  4. properly handle editor(s)
  5. tests to make sure that I haven't broken anything
  6. fix other things that I've no doubt overlooked

Trappist the monk (talk) 23:41, 13 November 2015 (UTC)

Overlooked: most style guides do not invert the author(s) names after "by" or "in". ~ J. Johnson (JJ) (talk) 00:17, 14 November 2015 (UTC)
I presume that you are correct. However, cs1|2 from the days of {{citation/core}}, has rendered all |last= / |first=-defined name lists in last-first order. This change is consistent with that norm.
Trappist the monk (talk) 12:02, 14 November 2015 (UTC)

The code for CITEREF anchors has been adjusted:

  • <cite id="CITEREFPynchon2003" class="citation book">[[Thomas Pynchon|Pynchon, Thomas]] (2003). Introduction. ''Nineteen Eighty-Four''. By Orwell, George. New York: Plume-Penguin. pp.&nbsp;vii–xxvi.</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • <cite id="CITEREFLast2009" class="citation">Last, First (2009), ''Title''</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>
  • <cite id="CITEREFElast2009" class="citation">Elast, Efirst, ed. (2009), ''Title''</cite><span title="ctx_ver=Z39.88-2004&" class="Z3988"><span style="display:none;">&nbsp;</span></span>

Trappist the monk (talk) 13:46, 14 November 2015 (UTC)

And metadata as can be seen the the above examples.

Trappist the monk (talk) 15:00, 14 November 2015 (UTC)

Editor fixed, I think. |orig-year= is included because I've tweaked how the meta-parameter Date is handled at that particular point in the code:

Pynchon, Thomas (2003) [1949]. Introduction. Nineteen Eighty-Four. By Orwell, George Smithson, James; Beecham, Thomas, eds. New York: Plume-Penguin. pp. vii–xxvi. 

Trappist the monk (talk) 16:26, 14 November 2015 (UTC)

Because the |contributor= / |contribution= pair is specific to book cites with a book author, detect and flag cites with |contributor= but without one of the |author= aliases:

"Contribution". Title. 2009.  |contributor= requires |author= (help)

and flag cites that are not book cites:

"Contribution". Title. 2009.  |contributor= ignored (help) ({{cite AV media}})
"Title". 2009.  |contributor= ignored (help); |contribution= ignored (help) ({{cite journal}}|contribution= here treated as alias of |chapter=)

but {{cite book}} with |contribution= and |author=, no error:

Author (2009). "Contribution". Title. 

Because there are multiple different errors, I've changed the category name to Category:CS1 errors: contributor.

Trappist the monk (talk) 18:00, 14 November 2015 (UTC)

  • Millet, Eugène (1869). "Plans des salles du Musée de Saint-Germain". Promenades au musée de Saint-Germain. By Gabriel de Mortillet. catalogue illustré de 79 figures par Arthur Rhoné. Paris: C. Reinwald. p. 88. 
This really is a useful solution to a long-standing problem. Great job! Aymatth2 (talk) 01:49, 16 November 2015 (UTC)
It is not good practice to use the sandbox versions of cs1|2 templates in article space. The sandbox can break at any time and remain broken for extended periods. I will also note that |others=catalogue illustré de 79 figures par Arthur Rhoné is a misuse of that parameter which purpose is to "record other contributors to the work ...", not for subtitles or descriptive text.
Trappist the monk (talk) 11:52, 16 November 2015 (UTC)
  • I just wanted to try it out. Probably for Millet's bibliography it should be:
For Rhoné's bibliography it should be:
and for de Mortillet's bibliography is should be:
This seems consistent with the Harvard guideline for scholarly works, where the main person being cited goes to the front. I wonder if unrecognized types of contribution should be treated more like chapters, i.e. followed by "In"? Is there a way to make |pages=88 generate pp. 88 in a bibliography? Any idea when the new template will be released? Once again, this really is a big improvement. Aymatth2 (talk) 13:24, 16 November 2015 (UTC)
Non-standard contribution titles are treated like chapters in that they are quoted. If you mean that:
... |contributor=Contributor |contribution=Contribution |author=Author |title=Title |date=<date>|...
should render something like:
Contributor. "Contribution". In Title. By Author ...
then I see no real benefit.
I think that your Rhoné example is improper. Rhoné may have contributed the illustrations to de Mortillet's work, but there doesn't appear to be anything in that work with the proper title "Illustrations". |contribution= as currently supported is a title, not a class of things.
If you mean that you want |pages= to indicate the total number of pages, that goes against the long-defined and documented purpose of |pages= as an in-source locator; see Template:cite book#csdoc_pages.
I want to address a bug that I've found in the metadata handling of in-source locators. Since I'm there I will also see if I can address the issues raised in Help talk:Citation Style 1#Page display in journal could use improvement. So I don't know when I will update the live module.
Trappist the monk (talk) 15:45, 16 November 2015 (UTC)
  • It is quite unimportant, but in this example the plans and illustrations are "in" the book. Aymatth2 (talk) 16:09, 16 November 2015 (UTC)
  • Then I am not sure how to represent Rhoné's role in the book in his bibliography, the list of works he contributed to. He is credited on the title page with having illustrated the book with 79 figures, presumably scattered throughout it, like this one. Taken together they represent a significant work, But the credit is not really a subtitle, more a description. Aymatth2 (talk) 16:09, 16 November 2015 (UTC)
  • Understood that in a citation, |pages= gives the location in the book. But in a bibliography, list of works by the author, number of pages is a fairly significant bit of information. Again, not sure how to represent it. Aymatth2 (talk) 16:09, 16 November 2015 (UTC)
Please do not interleave your comments in mine. I have moved them.
My objection to Rhoné also applies to Millet for the same reasons.
There seems to be a wide variety of ways that illustrator bibliographies are handled. I peaked at a few articles in Category:American children's book illustrators and Category:British children's book illustrators and didn't find much in the way of consistency except, that the illustrator is rarely listed in the bibliographic entry. In most cases that I saw, bibliographic entries were composed freehand.
Primary mission for cs1|2 is, and must remain, citation. That it can be used for bibliographies is a plus. But, that is why I mentioned elsewhere that someday we might use |mode= to tell Module:Citation/CS1 to treat the template contents as a bibliographic entry rather than as a citation.
Trappist the monk (talk) 17:13, 16 November 2015 (UTC)
  • Both Rhoné and Millet are sometimes illustrators, sometimes authors.
A |mode= parameter could be useful. I would usually set it to |mode=bibliography. I almost always use {{sfn}} references that give locations in the sources and point to a list of source definitions. I often also list works by the subject of the article, so have two sections that list books and articles (by and about), both the same format. I would like both lists to give fairly complete bibliographic data. Mostly the stuff that does not fit elsewhere can go into |others=, but a clean way to cite the introduction would be useful – there is no good workaround.
Smith, Fred. Preface (2015). Poor alternative. Jane Doe. Penguin. 
Thanks, Aymatth2 (talk) 20:24, 16 November 2015 (UTC)
... but a clean way to cite the introduction would be useful – there is no good workaround. Which is what this change does so I don't understand your point.
Trappist the monk (talk) 10:39, 17 November 2015 (UTC)
  • When this enhancement is implemented, it will be a major improvement. It would be nice if the template gave fuller support for Harvard-style bibliography information in MLA format. I understand this is not a priority, and accept putting the other stuff in |others=. Aymatth2 (talk) 14:07, 17 November 2015 (UTC)

Attribution to free sources in "cite book"[edit]

A recent TFD brought up a point about giving attribution to free sources such as Google Books and the Internet Archive. I have created {{via}} to give this attribution, but I was wondering if it would make sense to add a via= parameter to {{cite book}} that could also call {{via}}, reducing the amount of templates and typing required. Primefac (talk) 06:56, 14 November 2015 (UTC)

@Primefac: there is already a |via= in the various templates. Viz:
Imzadi 1979  07:15, 14 November 2015 (UTC)
Well colour me surprised. I wonder if the new template I created is even necessary then... Primefac (talk) 07:18, 14 November 2015 (UTC)

duplicated terminal punctuation[edit]

Because I've been mucking about in a place where |author= is handled, I noticed that there are times when it is possible to have two periods following the last name in the author list. These are when the given name is an initial followed by a period and the name is wikilinked and when |date= is not set:

Cite book compare
{{ cite book | author=Lincoln, A. | title=Title }}
Live Lincoln, A. Title. 
Sandbox Lincoln, A. Title. 
Cite book compare
{{ cite book | title=Title | author-link=Abraham Lincoln | author=Lincoln, A. }}
Live Lincoln, A.. Title. 
Sandbox Lincoln, A. Title. 

I have fixed that.

Trappist the monk (talk) 19:58, 14 November 2015 (UTC)

The code that determines how to terminate the name lists was repeated in three separate places so I've consolidated it into a single function so that the three name lists, authors, contributors, and editors are all treated the same way. the translator name list is concatenated with Others so it is treated differently. These are the editor cases (the double punctuation was fixed some time ago – this shows that I haven't broken it):

Cite book compare
{{ cite book | chapter=Chapter | title=Title | editor-last=Smithson | editor-first=J. | author=Lincoln, A. }}
Live Lincoln, A. "Chapter". In Smithson, J. Title. 
Sandbox Lincoln, A. "Chapter". In Smithson, J. Title. 
Cite book compare
{{ cite book | chapter=Chapter | editor-link=James Smithson | title=Title | editor-last=Smithson | editor-first=J. | author=Lincoln, A. }}
Live Lincoln, A. "Chapter". In Smithson, J. Title. 
Sandbox Lincoln, A. "Chapter". In Smithson, J. Title. 

And these are the contributor cases:

  • Lincoln, A. Introduction. Title. By Author. 
  • Lincoln, A. Introduction. Title. By Author. 

Trappist the monk (talk) 20:39, 14 November 2015 (UTC)

Progress like this makes WP look more professional. Nice work.
Is this issue in any way related to this discussion of suppressing separators? – Jonesey95 (talk) 23:45, 14 November 2015 (UTC)
Yes and no. To do that right, I think that a lot of the code that puts all of the bits, pieces, and parts of a rendered citation together should be rewritten so that, as part of the normal way of things, the duplicate punctuation that I fixed today and the mixed punctuation described in the feature request are handled as each parameter is handled. That task is something that continues to fester in my brain at a low boil so perhaps someday I'll wake up with an Ah Ha! moment.
Trappist the monk (talk) 00:08, 15 November 2015 (UTC)

|page=, |pages=, |at=[edit]

We have a special error message and category for when a cs1|2 template contains a combination of |page=, |pages=, and |at=. Are the separate error message and category necessary? Isn't this condition merely a variant of redundant parameters like |author= and |last=? Is there any reason we shouldn't treat the extra in-source locator parameter the same as we treat any redundant parameter?

Trappist the monk (talk) 19:14, 16 November 2015 (UTC)

After reading through the error descriptions (and fixing hundreds of these errors), I think Trappist is right. We should merge these errors into the redundant parameter error category. – Jonesey95 (talk) 21:29, 16 November 2015 (UTC)
Agree, one error message and one cleanup category seems better than duplication. —David Eppstein (talk) 23:52, 16 November 2015 (UTC)

I have tweaked Module:Citation/CS1/sandbox so that it emits a redundant parameter error message (and category) when a template has more than one of |page=, |pages=, and |at=. I added |sheet= and |sheets= to the test because there is a similar test that includes all five parameters when {{cite map}} is the template. This change detects all of the redundant parameters in a single test.

Cite book compare
{{ cite book | at=78 | sheets=A–B | title=Title | sheet=A | pages=34–56 | page=12 }}
Live TitleA. p. 12 Extra |pages= or |at= (help). 
Sandbox Title. p. 12.  More than one of |pages=, |at=, |sheet=, |sheets=, and |page= specified (help)

For {{cite map}}, the new error message is more precise:

Cite map compare
{{ cite map | title=Title | sheet=A | page=12 }}
Live Title (Map). Sheet A.  More than one of |sheet=, |sheets= and |page=, |pages=, |at= specified (help)
Sandbox Title (Map). Sheet A.  More than one of |sheet= and |page= specified (help)

This change also fixes a minor bug where the |sheet= or |sheets= value is included in a non-{{cite map}} template. See the title portion of the live version of the {{cite book}} comparison.

Trappist the monk (talk) 16:08, 17 November 2015 (UTC)

This change is also an improvement in another way than discussed above: it produces an error message that's easier to understand. —David Eppstein (talk) 17:03, 17 November 2015 (UTC)
Might it make sense to allow |at= together with |page= or |pages=? Some references involve both a page number and a location, e.g. "p. 15, footnote 46", and it would be handy to be able to put the page number in |page= while also giving the extra location information. Kanguole 15:14, 19 November 2015 (UTC)
Not quite. The full citation created by cs1/2 that gives a full description of the source is distinct from the specific reference to a location within the source. In the common practice where, having only a single reference to a source, editors combine both it is better that the specific part be appended to the template rather then included in it. Inclusion implies that the specific page (or, heaven forbid, the footnote) is the entirety of the source.
Re 'cite map': in geology it is standard to describe "maps" as having a certain number of sheets (or plates, which should be an alias, which lack page numbers), AND a certain number of pages (understood to be of text). This might be confusing in regard of atlases, which are collections of maps, and might warrant a separate template. ~ J. Johnson (JJ) (talk) 21:45, 22 November 2015 (UTC)

|volume=, |issue=, |page(s)= and cite magazine[edit]

which cs1|2 templates should support
|volume=, |issue=, |page(s)=?
template |volume= |issue= |page(s)=
{{citation}} Yes Yes Yes
{{cite arXiv}} No No Yes
{{cite AV media}} Yes No No
{{cite AV media notes}} No No Yes
{{cite book}} Yes No Yes
No No Yes
Yes Yes Yes
{{cite DVD notes}} No No Yes
{{cite encyclopedia}} Yes No Yes
{{cite episode}} No Yes No
{{cite interview}} Yes Yes Yes
{{cite journal}} Yes Yes Yes
{{cite magazine}} Yes Yes Yes
{{cite mailing list}} No No No
Yes No Yes
Yes Yes Yes
{{cite news}} Yes Yes Yes
{{cite newsgroup}} No No No
{{cite podcast}} No No No
{{cite press release}} No No Yes
{{cite report}} Yes No Yes
{{cite serial}} No No No
{{cite sign}} No No No
{{cite speech}} No No No
{{cite techreport}} Yes No Yes
{{cite thesis}} No No Yes
{{cite web}} No No Yes

This topic is a follow-on from Help talk:Citation Style 1#Page display in journal could use improvement.

In the sandbox, I have limited the journal-style page rendering to {{cite journal}}:

"Title". Journal 23 (6): 101–130. 

For {{citation}}, journal-style page numbering applies only when |journal= is set. For the other aliases of |journal=, the module uses the 'p.' and 'pp.' prefixes:

"citation with journal", Journal 23 (6): 101–130 
"citation with work", Work 23 (6), pp. 101–130 

I have created Template:cite magazine/new which calls Module:Citation/CS1/sandbox. For {{cite magazine}}, the module will render the volume, issue, and page(s) as: 'vol. # no. # p. #'.

"Title". Magazine. Vol. 23 no. 6. pp. 101–130. 

Other templates that use these parameters are unaffected by this change. But, that makes me wonder if we should be limiting the rendering of these parameters. The table is a list of templates and the parameters that I think that they should support. Opinions? Comments?

Trappist the monk (talk) 15:07, 18 November 2015 (UTC)

{{cite web}} should support |page= / |pages=, as it does now. As for {{citation}}, am I the only one who sees the mixed output with the boldfaced volume, bracketed issue and prefixed page numbers as strange? Why wouldn't we completely switch that over to "vol. 23, no. 6, pp. 101–130"?
One last thought, but we should decide if there will be periods (for cs1) separating all of the entries in "vol. 23 no. 6. pp. 101–130." or not. As it is, there is no period after the volume number. Personally, even for cs1, I'd see these as connected items that should be treated as a logical group and separated by a comma and ended by a period. Imzadi 1979  23:32, 18 November 2015 (UTC)
@Imzadi1979: you may not be the only one that finds the "39(12):4–34" style strange, but it's an absolutely standard format in many (perhaps most) academic journals (Nature, for example). So it has to be supported here (given that the English Wikipedia doesn't impose a single citation style). Peter coxhead (talk) 10:59, 19 November 2015 (UTC)
I think the question was about the 23 (6), pp. 101–130 style.
Trappist the monk (talk) 11:06, 19 November 2015 (UTC)
Ah, whoops, sorry. Then I agree with Imzadi1979, it does look odd. Peter coxhead (talk) 11:50, 19 November 2015 (UTC)
No, Peter coxhead, I don't find that original, truncated output strange at all, although I would personally prefer if cs1|2, as its own style, transitioned away from it under the guise of enhanced legibility for non-academic audiences. In the meantime though, {{citation}} shouldn't output something that's half that style and half the new style in certain use cases. Imzadi 1979  14:02, 19 November 2015 (UTC)
That isn't just a {{citation}} issue (pun not intended). The 'mixed' style occurs with just about all cs1 templates (even {{cite journal}} when |journal= or an alias is not set). Mostly this is because we don't limit the use of |volume= and |issue= as we should do. That is the purpose of the table: to codify which of |volume=, |issue=, and |page(s)= is appropriate for use with which cs1|2 templates.
Trappist the monk (talk) 19:45, 19 November 2015 (UTC)
I'm inclined to agree that volume, issue and page should always be grouped together. As it is right now, that only happens with journal and map cites; all other cites can insert any or all of the meta-parameters Others, Edition, Publisher, and Agency between issue and page.
Trappist the monk (talk) 11:50, 19 November 2015 (UTC)
Reports, techreports, and serials can have volumes. I have a vague recollection of even a conference report ("book") being issue in volumes. ~ J. Johnson (JJ) (talk) 00:10, 19 November 2015 (UTC)
I've tweaked the table as above except {{cite serial}} because its documentation says it is "used to create citations for broadcast programs". I don't see how |volume= is appropriate here.
Trappist the monk (talk) 10:54, 19 November 2015 (UTC)
It seems to me that shows via DVD are often published in several sets (e.g. episodes 1-4, 5-8, etc...). Does it seem desirable to be able to delineate that, or is episode and format good enough? Presently, volume is used in that template, at least per the documentation, and that's the only plausible use I can see for volume. --Izno (talk) 12:19, 19 November 2015 (UTC)
Citing a DVD we should use {{cite AV media}}. Perhaps |volume= (or maybe a more meaningful alias) is appropriate. I've tweaked the table.
Trappist the monk (talk) 12:30, 20 November 2015 (UTC)
Interesting. The documentation then fails to recognize that in publishing (etc.) the term serial is applied to any "publication in any medium issued under the same title in a succession of discrete parts, usually numbered (or dated) and appearing at regular or irregular intervals with no predetermined conclusion." (See also Serial (publishing).) Perhaps the intended of use of this template needs reconsidering, and the documentation corrected. ~ J. Johnson (JJ) (talk) 00:15, 20 November 2015 (UTC)
Perhaps you are thinking of |series= which I think is intended to meet the needs of citing serial publications.
The definition of {{cite serial}} could certainly be tightened. It is used to cite whole seasons of television programs, to cite individual episodes of programs, to cite a series of novels, and probably other things. At some other time and place we should probably consider revision of {{cite serial}}, {{cite episode}}, {{cite AV media}} to carefully define their use and minimize overlap, among other things.
Trappist the monk (talk) 12:30, 20 November 2015 (UTC)
Perhaps you have it backwards? "Serial" seems to be the more general term, while your "whole seasons of television programs" is more generally called a series. It's bad enough if these templates were misnamed, but to double down on the error would only make WP citation even more inscrutable. ~ J. Johnson (JJ) (talk) 23:00, 20 November 2015 (UTC)
Do not blame me for the template {{cite serial}} and the parameter |series=. I had nothing to do with their creation. My previous post was merely a report of what I found when I looked at a few of the articles that transclude {{cite serial}}. Go look for yourself to see how it is used. Go look at its documentation to see how it is meant to be used.
Trappist the monk (talk) 00:04, 21 November 2015 (UTC)
FWIW, my experience is that "series" is used to refer to an entire run of a show in the US (IOW, all ten seasons of Friends make up the series), while in the UK, there would have been be ten series of Friends. Rwessel (talk) 04:20, 21 November 2015 (UTC)
Trappist, I don't blame you for the templates being possible misnamed and/or misused. (If I want to blame you for something I will find something you actually did.) And I certainly agree that "carefully refin[ing] their use" would be good. I am a little concerned lest any such refinements lock-in past mis-directions. ~ J. Johnson (JJ) (talk) 23:13, 21 November 2015 (UTC)
Another quick thought, but I'm wondering if it would be possible to invoke the new output style in {{cite map}} if |work= is used instead of |journal=? Imzadi 1979  14:02, 19 November 2015 (UTC)
To be consistent, when |magazine=Magazine:
"Title" (Map). Magazine. Vol. 23 no. 6. pp. 101–130. 
"Title" (Map). Magazine. Vol. 23 no. 6. Sheet 5. 
"Title" (Map). Journal 23 (6): 101. 
"Title" (Map). Journal 23 (6): Sheet 5. 
Title (Map). Sheet 5. 
Trappist the monk (talk) 19:45, 19 November 2015 (UTC)

I have adapted Module:Citation/CS1/sandbox so that cs1|2 templates render |volume=, |issue=, and |page(s)= as specified in the above table. So that we don't clutter this page, here is a link to a version of my test cases page that shows all of the templates.

Also at the top of that page there are test cases for {{cite magazine}}. I have tweaked its support so that it properly renders lower case for cs2. Do we need punctuation between volume and number? between number and page? If so, what is it? Are we to render |volume=, |issue=, and |page(s)= all together as a group or allow the meta-parameters Others, Edition, Publisher, and Agency to separate |issue= from |page(s)=? If all as a group, where do they go? in the same position as |volume= and |issue= are now or in the same position as |page(s)= is now:

Title Vol (Issue). Others (1st ed.). Location: Publisher. Agency. p. Page. 

Trappist the monk (talk) 14:54, 21 November 2015 (UTC)

|nopp=, |page(s)=, and the extra-text test[edit]

|nopp=, when set to any of yes, true, or y, inhibits the display of the usual p. or pp. page prefixes.

The extra-text-in-|page(s)= test is disabled when |nopp= is properly set (see this archived discussion). I now don't think that the test should be skipped. If it is because editors may have included a prefix in the value for |page(s)= then that will corrupt the citation's metadata so that is not a good reason to skip the test.

It is the job of the module to provide static text. The values assigned to |page(s)= must not contain text that is not page numbers so that the metadata are not corrupted. When it is desirable to prefix page numbers with something other than p. or pp., the non-standard prefixes might be added to |at=. Alternately, we can resurrect and document |p-prefix= and |pp-prefix= (which I just removed). The extra-text-in-|page(s)= test should emit an error message rather than its current maintenance message. In either case, to preserve the metadata, |at= should not be used as a source for the metadata rft.pages because it is a free-form parameter.

Trappist the monk (talk) 14:42, 19 November 2015 (UTC)

After poking through that maintenance category, I came to the conclusion that some editors were creating parameter values like |page=p. 45 because our template can be needlessly obscure, displaying page numbers with no indication of what the number represents in many circumstances (cf the discussion above about vol/issue/pp).
If we modify the page numbering display such that |page=45 displays "p. 45" and |page=p. 45 displays "p. p. 45", then a red error message should definitely be displayed for the latter case. But if |page=p. 45 displays "p. 45", I think you'll encounter objections from reasonable editors if you show a red error message.
Am I responding to the question that you raised, Trappist? Or am I going in a different direction? – Jonesey95 (talk) 16:34, 19 November 2015 (UTC)
Because it is the module's job to display static text, editors shouldn't, and shouldn't feel a need to, include non-page number text in |page(s)=. We don't accept extraneous text in dates; we don't require editors to provide quotation marks, brackets, and other formatting details. All we want is the data. Give us a page number and we'll add the p.&nbsp;. By providing {{cite magazine}} we remove the 'need' to add extraneous text, do we not?
This does suggest to me that we should, as a part of tightening the definition of {{cite journal}}, emit an error message for journal cites that lack both |volume= and |issue=.
Trappist the monk (talk) 20:17, 19 November 2015 (UTC)
What definition of 'journal' requires them to have either a volume number or issue number? Certainly it is a characteristic, and the lack of same might warrant a warning (as possibly incomplete), but why these be required? ~ J. Johnson (JJ) (talk) 00:25, 20 November 2015 (UTC)
There are plenty of citation style guidelines out there that have text about what to do when citing a journal that has no volume or issue numbers, so I think this is a common enough case that we need to handle it without errors and without making editors jump through complicated hoops to avoid an error. For instance from this copy of APA: "If an on-line journal gives neither volume nor issue number, simply put the journal's title and descriptor, and end with a period." This book gives an explicit example, although the journal in question seems to have acquired issue numbers at some later point. (Also, there are plenty of instances of {{cite journal}} on Wikipedia for things that are not journal papers, but it's harder to argue against emitting error messages for those cases.) —David Eppstein (talk) 00:35, 20 November 2015 (UTC)

I have changed the extra-text-in-|page(s)= so that the test is not disabled when |nopp= is properly set.

Trappist the monk (talk) 11:46, 23 November 2015 (UTC)

Work parameter and italics[edit]

I'm having trouble finding a decisive previous discussion on how websites are treated in citation templates. MOS:T states that the italicisation of websites "should be decided on a case-by-case basis", while {{cite web}} and co. force work and similar parameters to use italics. To get around this for some websites which shouldn't be italicised, I have always used the publisher parameter, but it's just been pointed out to be that this practice is discouraged by template documentation pages. Is there some consistency or consensus somewhere that I'm just not seeing? Adabow (talk) 20:59, 21 November 2015 (UTC)

#Request for Comments: Italics or Non-Italics in "website" field. First section. --Izno (talk) 21:38, 21 November 2015 (UTC)
*facepalm* Thanks Adabow (talk) 22:02, 21 November 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── OK, so my reading of that convoluted thread is that there is still no consensus around this issue. Is that a fair assessment? Adabow (talk) 22:07, 21 November 2015 (UTC)

Yup. ~ J. Johnson (JJ) (talk) 22:55, 21 November 2015 (UTC)

Auto access-date?[edit]

It will be very useful to have ability to (re-)generate access-date automatically instead of requiring to type it manually.

Yurikoles (talk) 04:01, 22 November 2015 (UTC)

I think that's outside the scope of what a template can do. Jc3s5h (talk) 13:14, 22 November 2015 (UTC)

Template name aliases[edit]

cf. Template:cite av media and Template:cite av media notes.

Consistency, please? (talk) 15:20, 22 November 2015 (UTC)

I do not understand what the request is here. The names look consistent to me. – Jonesey95 (talk) 19:40, 22 November 2015 (UTC)
Fixed with a new redirect to {{cite AV media notes}}.
Trappist the monk (talk) 19:48, 22 November 2015 (UTC)

external link in parameter[edit]

Because of this discussion, I have revisited the code that does the error checking. Part of that was to consolidate the actual validation so that this test and the test that validates urls in the url-holding parameters use as much of the same code as possible.

The other part is to detect and flag bare urls in |title=, |chapter=, and |work= parameters. I've done this because the 'fix' described in that other conversation is to change |website=[ Example] to |website= Example which doesn't actually fix the problem. This fix also improves the error messaging.

Cite web compare
{{ cite web | title=Title | website=[ example] | url= }}
Live "Title". example.  External link in |work= (help)
Sandbox "Title". example.  External link in |website= (help)
Cite web compare
{{ cite web | title=Title | website= example | url= }}
Live "Title". example. 
Sandbox "Title". example.  External link in |website= (help)

Trappist the monk (talk) 15:25, 22 November 2015 (UTC)

bug fixes for redundant parameter error messages[edit]

When there are more than one of a parameter alias in a cs1|2 template, Module:Citation/CS1 emits a redundant parameter error that lists all of the matching aliases in the error message. The first bug squashed is revealed when there are multiple calls to function select_one(). This function reads the list of aliases for a particular parameter and selects the first one that is set. If more than one is set, the function emits a redundant parameter error. Because the function is handy for other things – it is called for example, to see if any of the |contributor= parameters are set for cs1|2 templates that don't support the |contributor=/|contribution= pair – those other calls can cause duplicate reports of redundant parameters.

The second bug squashed is a flaw in how the error message itself is rendered. Enumerated parameters with the enumerator of '1' are treated the same as an non-enumerated parameter: |author= and |author1= are the same. During the test, an enumerated parameter from the numbered parameter list in Module:Citation/CS1/Configuration (written there as, for example, |translator-last#=) is modified to be {{|translator-last= and this modified value is used in the error message. Similarly, |translator#-last=) also becomes {{|translator-last= to be used in the error message. The error message reports all of the matching aliases which, because the '#' has been replaced, makes the message look odd:

Cite book compare
{{ cite book | last=Last | title=Title | author=Author }}
Live Last. Title.  More than one of |author= and |last= specified (help); More than one of |author= and |last= specified (help)
Sandbox Last. Title.  More than one of |author1= and |last= specified (help)
Cite book compare
{{ cite book | editor=Editor | editor-last=Elast | title=Title }}
Live Editor (ed.). Title.  More than one of |editor-last=, |editor-last=, and |editor= specified (help); More than one of |editor-last=, |editor-last=, and |editor= specified (help)
Sandbox Editor (ed.). Title.  More than one of |editor-last1=, |editor1-last=, and |editor= specified (help)
Cite book compare
{{ cite book | translator=Translator | title=Title | translator-last=Tlast | author=Author }}
Live Author. Title. Translated by Translator.  More than one of |translator-last=, |translator-last=, and |translator= specified (help)
Sandbox Author. Title. Translated by Translator.  More than one of |translator-last1=, |translator1-last=, and |translator= specified (help)
Cite book compare
{{ cite book | contributor-last=Clast | title=Title | contributor=Contributor | author=Author }}
Live Author. Title.  Unknown parameter |contributor-last= ignored (help); Unknown parameter |contributor= ignored (help)
Sandbox Author. Title.  More than one of |contributor-last1=, |contributor1-last=, and |contributor= specified (help); |contributor= requires |contribution= (help)

While these have been 'fixed', listing two enumerated parameters when none are actually used seems improper. I've added a note to the code to remind me to think about a better fix.

Trappist the monk (talk) 17:12, 23 November 2015 (UTC)


Can something be done to pick-up publishers which have an external link to that seems to be getting entered in several recent cites. It is usually accompanied by invalid |language=en-GB or |language=en-US. Keith D (talk) 01:39, 25 November 2015 (UTC)

Links to example edits? I think en-GB and en-US are being added by a Visual Editor tool. If we can track it down, we may be able to file a bug. – Jonesey95 (talk) 02:48, 25 November 2015 (UTC)