Misplaced Pages

Revision as of 22:36, 23 September 2015

This is the talk page for discussing improvements to the Citation Style 1 page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcut WT:CS1

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97Auto-archiving period: 30 days

Misplaced Pages Help B‑class High‑importance

This page is within the scope of the Misplaced Pages Help Project, a collaborative effort to improve Misplaced Pages'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.Misplaced Pages HelpWikipedia:Help ProjectTemplate:Misplaced Pages Help ProjectHelp 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.

Help: Citation Style 1

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 41, 42, 43, 44, 45, 46, 47, 48, 49, 50 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 61, 62, 63, 64, 65, 66, 67, 68, 69, 70 71, 72, 73, 74, 75, 76, 77, 78, 79, 80 81, 82, 83, 84, 85, 86, 87, 88, 89, 90 91, 92, 93, 94, 95, 96, 97

Index

This page has archives. Sections older than 30 days may be automatically archived by ClueBot III when more than 1 section is present.

• Help talk:Citation Style 1 (active, central discussion)
• Help talk:Citation Style 1/accessdate
• Help talk:CS1 errors (active)
• Template talk:Citation (the only Citation style 2 template)
• Template talk:Cite AV media notes
• Template talk:Cite AV media
• Template talk:Cite book
• Template talk:Cite conference
• Template talk:Cite DVD-notes
• Template talk:Cite encyclopedia
• Template talk:Cite episode
• Template talk:Cite interview
• Template talk:Cite journal
• Template talk:Cite mailing list
• Template talk:Cite map
• Template talk:Cite manual
• Template talk:Cite music release notes
• Template talk:Cite news
• Template talk:Cite newsgroup
• Template talk:Cite podcast
• Template talk:Cite press release
• Template talk:Cite report
• Template talk:Cite serial
• Template talk:Cite sign
• Template talk:Cite speech
• Template talk:Cite techreport
• Template talk:Cite thesis
• Template talk:Cite web
• Template talk:Citation Style documentation
• Module talk:CS1
• Module talk:Citation/CS1
• Module talk:Citation/CS1/COinS (active)
• Module talk:Citation/CS1/Configuration
• Module talk:Citation/CS1/Date validation
• Module talk:Citation/CS1/Identifiers
• Module talk:Citation/CS1/styles.css
• Module talk:Citation/CS1/Suggestions
• Module talk:Citation/CS1/Utilities
• Module talk:Citation/CS1/Whitelist
• Module talk:Citation
• Category talk:CS1 errors: dates/Archive 1

This is the talk page for discussing improvements to the Citation Style 1 page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97Auto-archiving period: 30 days

Feature request: |note= parameter

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

It would be nicer still to have a |null= to work around the red-flagging because there are time when as SMcCandlish unrecognized parameters are convenient. -- PBS (talk) 22:56, 15 July 2015 (UTC)

I think the problem with the example above is that all of the other parameters in CS1 are for bibliographic data that theoretically at least is understandable to readers and meaningful outside Misplaced Pages. Whereas that comment would be understandable to maybe 1 or 2 out of every 1,000 Misplaced Pages readers – the ones who are familiar with what WP editors usually mean when they call a source "primary". For that sort of thing, an HTML comment embedded in the wikitext seems like exactly the right way to handle it. Let's keep meta comments and WP-specific issues separate from the data. – Margin1522 (talk) 11:21, 16 July 2015 (UTC)

SMcCandlish is not proposing a display variable, but one to be used in place of <!-- a hidden comment --> as the parameter |reason= is used in the template {{Clarify}}. -- PBS (talk) 19:35, 16 July 2015 (UTC)

I can see the advantage of a |note= parameter. I find the |others= parameter very useful - today I've used it to flag "(published anonymously)". Library catalogs sometimes use square brackets for this. Aa77zz (talk) 20:19, 16 July 2015 (UTC)

Like this from Finch?:

{{ cite book | last=Leach | first=William Elford | author-link=William Elford Leach | year=1820 | chapter=Eleventh Room | title= Synopsis of the Contents of the British Museum | place=London | publisher=British Museum | edition=17th| pages=65-70 | others=(published anonymously) }}

Specifically these bits:

| publisher=British Museum and | others=(published anonymously)

One contradicts the other. And, from the template documentation at Authors:

• others: To record other contributors to the work, including illustrators and translators. For the parameter value, write Illustrated by John Smith or Translated by John Smith.

I think that your use of |others= as you have done is an improper use of the parameter.

—Trappist the monk (talk) 22:23, 16 July 2015 (UTC)

I was well aware that my use was "improper" but I had wanted to say that the author wasn't specified rather than the publisher wasn't specified. I've now deleted the parameter.Aa77zz (talk) 07:05, 17 July 2015 (UTC)

At Finch it now says: "The name of the author is not specified in the document." If that is so, then who is | last=Leach | first=William Elford?

—Trappist the monk (talk) 09:31, 17 July 2015 (UTC)

I was trying to simplify as this isn't an important reference. In the Finch article I've actually cited two sources - the other is Bock 1994. It is Bock who gives the information about the publication: "All the parts of this public guide to the British Museum are unsigned, however, this part was clearly written by Leach as indicated by the fact that he was Keeper of Zoology at the time and by the numerous references to Leach's list of family-group names by his contemporaries." I'm reluctant to add a notelist with this info. It is not uncommon to have "unsigned" articles. I've met them in 19th century book reviews. Sometimes there is a RS giving the authors name. I've seen square brackets used in references when the information isn't present on the title page - such as the author or the year of publication. Aa77zz (talk) 10:17, 17 July 2015 (UTC)

If Synopsis ... doesn't identify the authors then | last=Leach | first=William Elford | author-link=William Elford Leach should be removed from that citation. You might then change the note to read: "Attributed to Leach in Both 1994." I'm not at all sure that this is even important. Will knowing that Both thinks that Leach wrote "Eleventh Room" help readers find a copy of Synopsis ...?

—Trappist the monk (talk) 12:13, 17 July 2015 (UTC)

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

And it would actually serve the purpose Aa77zz has in mind, anyway. So, I renew the request. All fields I'm aware of, including physical sciences, social sciences, humanities, law, etc., that regularly cite sources do in fact have definitions of "primary source" and so on (even if they sometimes differ in their particulars), so the objection to my example isn't even valid. And it was just an example. There are any number of reasons to use such a parameter, e.g.:

• |note=Titled "Blood of the Isles" in the UK printing.
• |note=Paywall can be bypassed by request at URL here.
• |note=Page 17 is missing from this Project Gutenberg scan, but is not part of the cited material.
• |note=There is a newer edition, but the cited section has not changed, according to URL to changes list.
• |note=This is a master's thesis, but was reviewed by Notable Researcher Here, and has been cited in 12 journal papers as of July 2015.

etc. There's no reason to put these in messy HTML comments that some editors are apt to delete on sight because they don't like HTML comments. And, really, no one's head will asplode if someone happens to include a more WP-jargon-specific note. They'll just shrug and move on. No one will see them but wikitext-editing users anyway.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:15, 30 July 2015 (UTC)

Are you hoping that the note will appear when a user mouses over the tag as with {{clarify-inline}} ? AngusWOOF (bark • sniff) 08:12, 22 August 2015 (UTC)

That might be useful, sure, but was not central to the nature of the request, which is about keeping these notes with (i.e., inside) the citations, so that nothing is put between them, etc.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  12:50, 12 September 2015 (UTC)

Italicization of websites in citations

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

"Generally" is the key word here, though. The vast majority of the time when a WP article is referring to a website, it's referring to it a business entity (or other kind of entity, e.g. a nonprofit, a free software coding group, a government project, whatever), or in a functional way, e.g. as a service or product. But when we cite it as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  09:53, 1 August 2015 (UTC)

As a journalist and editor, I need to disagree with the premise that when we cite Amazon.com, or the British Board of Film Classification or Marvel.com that these entities transmogrify into "a major published work, like a book, journal, magazine, film, etc."

No mainstream source italicizes Amazon.com, British Board of Film Classification, Marvel.com, or, for that matter, Rotten Tomatoes or Box Office Mojo, and none of these entities themselves italicize their names.

Italicizing dotcom names is not done anywhere else, and I'm afraid I can't find a valid reason that Misplaced Pages should create a non-traditional form of punctuation. Indeed, not even Misplaced Pages italicizes these entities in their respective articles. So I'd like to ask for what compelling reason we do so here. --Tenebrae (talk) 19:43, 29 August 2015 (UTC)

I agree. Entirely. ~ J. Johnson (JJ) (talk) 22:25, 30 August 2015 (UTC)

With what, though? Half of that wasn't cogent. British Board of Film Classification is a publisher, not a work of any kind, and what source italicizes itself (except as an incidental stylistic matter)? Looking at an entire bookshelf, only a tiny handful of covers have italic titles, and if you look at the actual title on the frontispiece, and at the top or bottom of each (or every other) page in the book, it is not italicized. This tells us nothing at all about whether WP would italicize the book title in a citation to it. No one made any such argument of "transmogrification". What I actually said was 'when we cite as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.' This argument has not actually been responded to at all. Instead, Tenebrae told us what some other publishers are doing, and made some unrelated observations. But WP's citation system is not that of any other site or publication, and no case has been made for why WP should treat the titles of all major works consistently (italicizing them by template) except when they're online publications.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:21, 30 August 2015 (UTC)

The problem is with how the website parameter is used. Since it's a synonym for work, it should only be used when a work is given as the value. "Amazon.com" is not a work. Peter coxhead (talk) 00:59, 31 August 2015 (UTC)

Exactly. Titles can be italicized, so we could have Amazon.com, but only because it is a title, not because it refers to a url. As to usage outside of WP: while some aspects of other styles are questionable, and often contradictory, it is still a good idea to consider them: 1) They often reflect a lot of hard-earned experience, and it would be shameful waste to insist on having to re-experience more than is useful. 2) Making WP more different than standard uses makes it harder to edit, and can even lead to subtle problems of reading. ~ J. Johnson (JJ) (talk) 18:06, 2 September 2015 (UTC)

As Peter coxhead rightly notes, "Amazon.com" is not a work or a title. "Rotten Tomatoes" or "Rotten Tomaotes.com" are not titles. "Sears.com" is not a title. Though I certainly agree with J. Johnson (JJ) that no other reference source, nor newspapers or magazines, italicize dotcom names. There is no reason for Misplaced Pages to have a nonsensical deviation from every grammatical standard in this regard. --Tenebrae (talk) 21:40, 2 September 2015 (UTC)

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

1. the name of the website very rarely includes the domain space (.com, .org, etc)...eg. it's "Misplaced Pages" not "Misplaced Pages.org"
2. citation styles are, generally, an exception to the MoS...the citation styles are intended to reflect common citation styles. Of the common citation styles, condsider how the following handle the names of websites:

1. MLA uses italics (scroll down to the section "A page on a website")
2. Chicago uses italics
3. APA generally doesn't include the name of a website that's not scholarly website (eg. an online journal), but instead uses "Retrieved from ".
4. ASA and Oxford style also does not include the name of the website, but rather the url
5. Vancouver style (see page 5) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Misplaced Pages .

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

I don't think we need to research varied style guidelines. It's already established that websites/urls are generally not italicized at Misplaced Pages, and I'm not aware that we have separate formatting conventions for citations in this regard. The fact that cite templates equate "website" with "work" is the problem, because while one or the other should be required, they do not have the same established formatting style. Period. If I'm citing EW.com, I actually cite |work=Entertainment Weekly because the website is an obvious platform of that publication. But when you cite a website not affiliated with a conventional publication, yes it may be considered a "major published work" in the sense that it is a reliable source, but I don't see why it should be italicized when it does not meet the criteria for that formatting, and would not be italicized in other contexts at WP. I get SMcCandlish's basic argument, but it is not as if there a requirement somewhere that something has to be italicized in each citation, or that the source has to be italicized no matter what it is.— TAnthony 19:24, 3 September 2015 (UTC)

Okay, we need some clarification here, as it seems that "website" is being used in several different ways. Note that websites usually have a proper name, such as "Google", "The New York Times", "Entertainment Weekly", and "Rotten Tomatoes". Websites also have hostnames, such as (resp.) "www.google.com", "www.nytimes.com", "ew.com", and "wwww.rottentomatoes.com", which often (but not always) incorporate some form of the website's (or parent entity's) name. Hostnames are usually part of URLs (but see below), and as such have specific form and usage in the context of the Internet. As hostnames (URLs) they are not italicised, nor capitalized. What are italicized are titles, such as the names of books, periodicals, and (generally) works. A book title in the form of a hostname, such as Amazon.com, would be italicized, but only because it is a title.

It seems to me the real issue here is what constitutes a title; particularly, the name of a source. "The New York Times" and "Entertainment Week" are the names of both publications and their associated websites; "nytimes.com" and "ew.com" are not. (Entertainment Weekly could have named their website "EW.com", in which case it could be a title, but they did not.) Note that a further distinction can be made between a publisher and a publication (or work). E.g., "Amazon" (the website) might be the publisher of a reveiw found there, but is it a publication? ~ J. Johnson (JJ) (talk) 21:34, 3 September 2015 (UTC)

Amazon, or Amazon.com, indeed is not a publication. Neither is the publisher Simon & Schuster or simonandschuster.com. Likewise, Sears.com is not a publication, and citing, just for example, the number of stores that Sears owns would be to the website Sears.com, and not Sears.com.

TAnthony is correct that if we're citing something created by the editorial department of Entertainment Weekly or The New York Times, we credit the publication rather than ew.com or nytimes.com, and these publications of course are italicized. In such cases, we use "work=" or "newspaper=" or "journal=". But neither Black & Decker nor blackanddecker.com is italicized. Same with The Home Depot or homedepot.com.

The sensible solution, I believe, is to have the "website" field not italicize its contents. That way we're not putting in " Amazon.com " or " Sears.com ". If we're citing an actual publication, we have three different fields we can use. --Tenebrae (talk) 22:48, 3 September 2015 (UTC)

Careful! You seem to be sliding back to confusing the name (as in a proper name) of a website with its hostname. E.g., "Sears.com" is not the name of a website, so should not be put in anywhere. If you want to cite something from the Sears website (located at "www.sears.com"), then you cite that, not its hostname. If a website is a publication (e.g., "Rotten Tomatoes") then its name is properly italicized. ~ J. Johnson (JJ) (talk) 23:27, 3 September 2015 (UTC)

I don't think I am. And I think you are the only person on this thread making the argument that Amazon.com should be italicized. And, certainly, no one italicizes Rotten Tomatoes, not even Rotten Tomatoes, as it is not, by any definition, a publication.

What do the other editors think? Aside from one holdout, the consensus seems to be to have the "website" field be non-ital. Do we need to create a formal RfC, or have we reached consensus? --Tenebrae (talk)

If all sources are italicized, including sources that contain the cited work, then websites should be italicized for both stylistic consistency and semantic reasons (e.g. to distinguish a webpage or section from the hosting website). — Preceding unsigned comment added by 64.134.64.231 (talk) 21:43, 5 September 2015 (UTC)

T: You don't seem to understand the distinction I am making, and have thereby misstated my view. Note: I believe we have no disagreement that (e.g.) titles can be (even should be) italicized. Also, that hostnames - such as found in URLs, and when used as hostnames - are NOT italicised. What you don't seem to understand is the use of a hostname in other contexts, such as in a title, or as the proper name of a website. Where I say that "Amazon.com" - note the capitalization, which is generally not done in urls - could be italicized it is very much dependent on it being used in the context of a title (like of a book) or proper name. That you think there is consensus to not italicize "website" is only because you have conflated "website" with "hostname". This is indicated by your earlier reference to "dotcom names". Strictly speaking, there no such things, except in the casual use of "XXXX.com" to refer to the website of some company XXXX. While such uses are in the fashion of a hostname, simply adding ".com" to some name does not make it a hostname, and does not exclude it from italicization. ~ J. Johnson (JJ) (talk) 22:05, 5 September 2015 (UTC)

I believe this is a valid point. The print product Grapes of Wrath, delivered by a printer, is not the book Grapes of Wrath delivered by a publisher. The digital product Amazon.com, delivered by a software developer, is different from the website www.amazon.com delivered by an online publisher. In most cases what is cited as the source is the content, not the "delivery method/packaging", as it were.208.87.234.201 (talk) 14:43, 6 September 2015 (UTC)

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

I agree that "website" (as in "work") can be italicized; the problem seems to be where people mistakenly equate it with the url/hostname. Perhaps the documentation should be clearer about this. And perhaps a bot could flag all the instances where the value of |website= is a valid hostname. I am reluctant to deprecate |website= as I think it has a good use, but if the problem is too great then that is something to consider. ~ J. Johnson (JJ) (talk) 21:34, 6 September 2015 (UTC)

Editors were perplexed or confused with the term 'work'. In response to this feature request, |website= became an alias of |work=.

—Trappist the monk (talk) 22:12, 6 September 2015 (UTC)

Suggesting that it is the concept of "website" as a "work" that is confusing. ~ J. Johnson (JJ) (talk) 22:36, 6 September 2015 (UTC)

So Amazon.com should not be italicized by www.amazon.com should, is what you're saying? First, I'm not sure how often we would be citing a raw URL. Second, I don't see URLs italicized in any mainstream source. I'm not sure it's a positive thing for WIkipedia credibility to be adopting highly non-standard forms of citation. I'm not sure this is any different from citing authors by first name rather than last. That would be a highly non-standard way of citing, and would only make Misplaced Pages look eccentric. I'm thinking that italicizing URLs where virtually no one else does might do the same. --Tenebrae (talk) 17:03, 7 September 2015 (UTC)

No, I believe he's saying the reverse. Amazon.com is the name of a website, and as a major published work, it would be itaicized if included in a citation. On the oter hand, www.amazon.com is the hostname and wouldn't be itaicized nor would we need to cite it. Imzadi 1979 → 17:59, 7 September 2015 (UTC)

Again, no one italicizes Amazon.com or Sears.com, RottenTomatoes.com, etc., including those companies themselves. A URL / hostname / website does not suddenly change and become a book, magazine, newspaper or other "major published work." There's a reason we say things are "posted to the Web" and not "published to the Web". I think the fact no one in the mainstream italicizes these things should be a significant factor in this discussion. --Tenebrae (talk) 18:24, 8 September 2015 (UTC)

Exactly. Tenebrae, you started off with an incorrect understanding, so everything else that follows is invalid. If you start off the right way (and if you understand/accept that "website" ≠ hostname) I think you will find that we are largely in agreement. ~ J. Johnson (JJ) (talk) 20:40, 7 September 2015 (UTC)

I would like to think so, but a fundamental issue is that I believe the "website" parameter should not be italicized. Virtually no mainstream source italicizes either website names or URLs, which I take it is what you mean by "hostname". Italicizing websites/URLs is non-standard and does Misplaced Pages no good. --Tenebrae (talk) 21:52, 7 September 2015 (UTC)

You need to loosen your death-grasp on 'the "website" parameter should not be italicized'. Your implicit argument is that URLs (which includes hostnames) are not italicized. Look, we all get that part - everyone agrees that URLs should not be italicized. And that includes parts of a URL, such as hostnames. So it is a bit annoying that you keep asserting that. What you don't get is that this is irrelevant, because "website" does not equal URL/hostname. In particular, what you don't get is that a website - that is, a site on the World Wide Web with "web page" (HTML) content - can have a proper name. E.g.: the name of the website located at the WWW address "www.nytimes.com" is The New York Times - which is properly italicized. I repeat: "website" ≠ hostname. ~ J. Johnson (JJ) (talk) 21:58, 8 September 2015 (UTC)

With all respect, we're talking specifically about a field in "cite web" called "website". If we're citing The New York Times, we use "cite news or "cite newspaper" and enter the name of the paper in the field "work".

But I am confused, because it does sound as if we both agree that the name of a website is not italicized unless it's a newspaper, magazine, etc. ... in which case we wouldn't use "cite web." So ... am I wrong or do we agree that if we use "cite web" that the field "website" should not be italicized?--Tenebrae (talk) 22:29, 8 September 2015 (UTC)

Suppose one wanted to cite this web page. Becuase it isn't a newspaper, it isn't a journal, nor a book, nor anything but a web page, then I would cite it with {{cite web}} like this:

{{cite web |url=http://www.cdc.gov/ncbddd/autism/data.html |title=Autism Spectrum Disorder (ASD) |website=] |date=12 August 2015}}

"Autism Spectrum Disorder (ASD)". Centers for Disease Control and Prevention. 12 August 2015.

—Trappist the monk (talk) 23:04, 8 September 2015 (UTC)

Yet nowhere else is the Centers for Disease Control and Prevention italicized. Same with CNN or CBS News. They are not publications, and I'm not sure it makes sense for Misplaced Pages to transmogrify them and pretend that they are publications. CBS News is never italicized. CNN, Sears, BBC, Rotten Tomatoes — none of these are italicized. If virtually no one else in the mainstream is italicizing these entities, I'm not sure why Misplaced Pages would. It makes us look eccentric. Do you see my reasoning?--Tenebrae (talk) 23:54, 8 September 2015 (UTC)

Agreed, yet the name of the website at http://www.michiganhighways.org , if it were being cited, is "Michigan Highways" per the site's mastheads. If it were being cited, it should appear in italics as the name of a major work (as opposed to individual webpages within the site which would be minor works in quotation marks). There is no entity named "Michigan Highways" to be called a publisher. In some of those cases being mentioned above, what is being claimed as the name of a website is the publisher. Not all websites have names, but when they do, they should be in italics. If a website lacks a separate name, without resorting to creating "Official website of X", then |website= should be left blank. It's the same in comparing the news sites of WLUC-TV (Upper Michigan's Source) with that of WBUP-TV (no name). Imzadi 1979 → 00:48, 9 September 2015 (UTC)

cs1|2 take their styling cues from MLA, APA, CMOS, and, no doubt, stuff we've made up ourselves. There is this, which on pages 4 and 5, compares three style guides for citing online material:

"The Purdue OWL: Citation Chart" (PDF). Online Writing Lab. Purdue University. pp. 4–5.

If one is to believe that, website names are rendered in italics in citations so my CDC citation above is correctly rendered.

—Trappist the monk (talk) 00:51, 9 September 2015 (UTC)

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

Tenebrae, lets say I want to something from the New York State Department of Motor Vehicles website, something that only appears on the website, and is not in any book, pamphlet, etc. So I use cite web. And I use |website= = New York State DMV because that is the title of the web site. I know it is the title of the website because when I examine the html source for the home page of the web site I find <title>New York State DMV</title>. It should be italicised because that is the title of the work. Jc3s5h (talk) 23:06, 8 September 2015 (UTC)

Except no one other than we italicize it. New York State DMV is a proper-noun entity, but to suggest that all proper-noun entities be italicized — I dunno. I mean, what's the advantage of italicizing CBS News, Sears, New York State DMV, Yellowstone Park or United Airlines? Would readers not understand that " 'Traffic Laws in 2015'. New York State DMV." comes from the New York State DMV? I'm not sure what the advantage is of going with a deliberately eccentric format.--Tenebrae (talk) 23:58, 8 September 2015 (UTC)

At the NYS DMV website, the <title>New York State DMV</title> html officially declares to the world "the title of our website is New York State DMV. My Firefox browser responds to that declaration by putting that title in the tab associated with the web page. Style guides outside Misplaced Pages, mentioned in this discussion, explain that when a website has a title, that title is italicised, and we have decided to follow that guidance. It has nothing to do with whether "New York State DMV" is a proper noun phrase or not. Jc3s5h (talk) 14:15, 9 September 2015 (UTC)

And my Google Chrome does not italicize anything at http://dmv.ny.gov/. Nor does the title of the page itself, in big blue letters. As for "we have decided," that's what this discussion is for, to discuss a change. Because having a style that virtually no one else uses just seems remarkably eccentric for no purpose. I don't believe any of us has ever seen, anywhere, "Author's Page". Simon & Schuster. No one would ever italicize the publisher Simon & Schuster. And to suggest that Rotten Tomatoes, which is not italicized in article text, be italicized in the footnote seems determinedly inconsistent. I think we're going to need wider input from all of Misplaced Pages.--Tenebrae (talk) 16:35, 9 September 2015 (UTC)

T: We are not saying that "that all proper-noun entities be italicized". In the context of citation publications ("works") are italicized, publishers are not. This is not "eccentric", this is a standard convention. So we italicize the titles of webpages (as Jc3s5h just explained), such as Sears or New York State DMV. We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. What kind of font is used on the website has nothing to do with it. (E.g., that the New York Times uses a serif title font has absolutely no bearing whatsoever on how a citation is formatted.)

Your persistent failure to understand this is starting to sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 01:13, 10 September 2015 (UTC)

No, it is the other way around, and I'll thank you stop casting aspersions. Pick up some books with footnotes and see whether web pages are italicized. See what AP Stylebook, the largest style guide in the English-speaking world, has to say. Nobody properly writes Rotten Tomatoes in regular font in article prose and then, inconsistently, puts it in italics in footnotes. Virtually no one in the world would italicize an organization like CBS News when citing something from the CBS News website. Organizations and institutions don't suddenly become titles because they have a web page.

Try and WP:HEAR this: The information we get from the New York State Department of Motor Vehicles comes, ultimately, under the auspices of the New York State Department of Motor Vehicles and not from the Web editor who inserted the information onto the web. Just as we cite The New York Times and Entertainment Weekly and not NYTimes.com or EW.com, the information from those websites ultimately comes under the auspices of those organizations. And in the case of non-publications, those organizations' names are not italicized. Now stop making false accusations — I understand perfectly, as I've said. It's you who seem to have trouble grasping the concept. --Tenebrae (talk) 20:26, 10 September 2015 (UTC)

False accustations? Aspersions? Perhaps you should review the bit at WP:NPA that accusing someone of a personal attack can also be considered a personal attack.

My "accusation" is that you have repeatedly failed to understand what is being said here. E.g., you have just insisted that "no one in the world would italicize an organization like CBS News", and "those organizations' names are not italicized." But who has said we should? You have implied that I did (and again at the RfC (below). But that is false. I have no where said that names of organizations should be italicized. And you seem to have totally missed what I said in my last comment regarding organizations: We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. (Emphasis added for the hard of hearing.) You have mis-taken my position, and are arguing against something (italicization of organizational names) that nobody is arguing for. If you in fact do "understand perfectly" then why are you arguing a non-issue? I surmise that you have confused "website" with "publisher", just as you earlier confused it with "hostname". I submit that not understanding this despite repeated explanations does sound like a WP:HEARing problem. ~ J. Johnson (JJ) (talk) 22:38, 10 September 2015 (UTC)

Don't you dare accuse me of uncivil behavior, when you were the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning. And you compound your incivility by falsely claiming I was deliberately misunderstanding in order to obfuscate. How dare you. Look around this RfC — other people have no problem whatsoever understanding my point, so the fact that only you seem to have a problem understanding seems ironic, given your accusations. You say organizations should not be italicized, but you support leaving the "website" field italicized (01:19, 10 September 2015) because the very same words are not, in your view, that of organization anymore but of a page title. That seem contradictory. I've already explained that when we're using publications, we wouldn't be using "cite web" field but "cite news" etc., so why you keep bringing up publications is beyond me. --Tenebrae (talk) 23:23, 10 September 2015 (UTC)

Yes, I think I will dare to accuse you of uncivil behavior: of grotesquely misrepresenting my views, of attributing to me things I have clearly not said. Let's start with your statement that I was "the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning." Where? Give us a diff. That view is entirely your interpretation. As I said at the RfC, you it have backwards: I disagree with your position because your reasoning is faulty, not the other way around. As to your "deliberately misunderstanding in order to obfuscate: I asked why (if, as you stated, you "understand perfectly") you are arguing a non-issue. Again, the suggestion "in order to obfuscate" is entirely yours, not mine. But now that you have raised it, is that your answer to my question?

I think it is quite evident that your understanding of matters here (and reasoning) is faulty, but as all efforts (of others as well as mine) to explain this to you are unavailing it seems pointless to continue. If you can provide that diff, fine, but otherwise you should cease your flailing about. If anyone else thinks that I have misunderstood something, please bring it to my attention. ~ J. Johnson (JJ) (talk) 23:48, 11 September 2015 (UTC)

deprecate enumerator-in-the-middle parameters

See this archived discussion.

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

† these parameters are the canonical form

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

Makes more conceptual sense the other way around. editor2-last implies the last name of editor #2, but editor-last2 implies the second surname of the editor.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:33, 5 August 2015 (UTC)

I agree with SMC on this point and think it would make more sense to keep the number in the middle than to have it out there hanging at the end. --Izno (talk) 17:47, 6 August 2015 (UTC)

The implication arises from the sense of the digit binding more tightly than the hyphen. (I.e., to "last" rather than "editor-last".) On the otherhand, when indexing a list of authors/editors I have found it most useful to have the index digit next to the equals sign, which gives the index better visibility, and provides a handy anchor for a regex. It's also easier to scan a list of authors/editors when the index is not buried inside the string. Which all might explain the medial location is not as widespread as the terminal form. I prefer the latter. ~ J. Johnson (JJ) (talk) 20:16, 7 August 2015 (UTC)

And yet others of us view the number as better in the middle. Comparing |editor2-last= and |editor-last2=, I parse the first as being the last name of the second editor and the second as the second last name of the (singular) editor. YMMV, and as far as I'm concerned, there's no harm in retaining both forms. Imzadi 1979 → 20:44, 7 August 2015 (UTC)

I am sympathetic to both points of view though my personal preference is terminal enumerator. I have added a column to the table that shows that overall, editors who have used these enumerated parameters generally prefer to use the terminal enumerator forms.

—Trappist the monk (talk) 12:26, 8 August 2015 (UTC)

That's surely skewed by how they're documented, and likely also by some individuals, perhaps even with AWB scripts, manually changing them to your "preferred" version. I know I've occasionally seen diffs that include this change along with other "general cleanup".  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  04:06, 9 August 2015 (UTC)

Of course it's possible that the documentation has influenced one style choice over the other and its possible that editors change extant parameters to suit their own preferences. I don't know that AWB, as part of its general fixes, makes this kind of change; I haven't noticed changes of that kind. If you are suggesting that I have written an AWB script that changes enumerator-in-the-middle to enumerator-at-the-end, then you would be wrong.

—Trappist the monk (talk) 12:35, 9 August 2015 (UTC)

• Strongly oppose deprecation. These are still listed as the primary parameter names for {{citation}} and we should not diverge the CS1 and CS2 templates so far from each other as to deprecate one template's parameters in the other. Additionally, these are used by software for creating citation templates (I know, because I have written such software myself). What purpose is served by this change? What does it make better? It seems to me to be purely a foolish consistency. Finally, I note that once again Trappist is proposing major changes that relate to {{citation}} without even bothering to mention the discussion on Template talk:Citation. Trappist, you have been told over and over again: don't do that. —David Eppstein (talk) 17:14, 8 August 2015 (UTC)

  I don't understand why you think this affects {{citation}}... when it doesn't. --Izno (talk) 21:09, 8 August 2015 (UTC)

This change affects {{citation}} because {{citation}}, despite being cs2, is rendered by Module:Citation/CS1.

—Trappist the monk (talk) 21:52, 8 August 2015 (UTC)

Yes, and also because it is desirable to continue the current state of affairs in which we can change CS1 to CS2 or vice versa just by changing the template name. Not that changing the citation style of an article is frequent nor usually a good idea. But finding articles that mix the two styles is common enough, and changing them to use only one is usually a (minor) improvement. Thanks to recent improvements it's also possible to do this using a parameter but changing the actual template name seems less likely to encourage more inconsistency later. —David Eppstein (talk) 06:27, 9 August 2015 (UTC)

Standardizing on terminal enumerators will not prevent editors from changing CS1 to CS2 or vice versa just by changing the template name. Standardizing on lowercase parameter names did not change that nor did standardizing on the hyphen as a separator in parameter names change that.

—Trappist the monk (talk) 12:35, 9 August 2015 (UTC)

Citation Style 2 is distinguished from Citation Style 1 by its element separator (comma vs period), by lowercase static text (retrieved..., archived from ..., written at ..., etc. vs Retrieved..., Archived from ..., Written at ..., etc.), by terminal punctuation (none vs period), and cs2 automatically sets |ref=harv, cs1 doesn't. cs2 is not distinguished from cs1 by some subset of the commonly shared parameters.

The primary documentation for both cs1 and cs2 is {{csdoc}}. I grant that {{csdoc}} has a cs1 bias, so does Help:CS1 errors though I did a bit of work on that recently that removed some of the bias.

Of the sixteen parameters in the above table, these seven are found in Template:Citation/doc outside of the {{csdoc}} content:

|authornlink=

|authorn-link=

|editorn-first=

|editorn-last=

|editorn-link=

|editorn-given=

|editorn-surname=

Are we to believe then that the other nine are not or should not be supported by {{citation}}?

Yep, it is just for consistency whether you think it foolish or not. This choice is no different from the choice we made to standardize on parameter names that use hyphens instead of underscores or spaces; and standardize on lowercase instead of capitalized or camel-case. Choosing one flavor or the other is merely for consistency.

—Trappist the monk (talk) 21:52, 8 August 2015 (UTC)

Yes, I think it is foolish to suddenly kill off the primary documented parameter choices of the sister CS2 style, that our templates have been handling perfectly well, for the sake of no reason at all but neatness. The costs of this proposal involve breaking software or forcing the developers of the software to make parallel changes, breaking the mental model of who knows how many editors (as an example, I am still months after you made this change unable to remember to use contribution-url= in place of url= for the url of book chapters, and this is causing actual citations to be formatted wrong), forcing edits to who knows how many live citations after the red error messages start showing up, etc. The benefit of the proposal is appeasing the OCD of one single software developer who wants all the ducks to be perfectly lined up in a precise row. It's a bad idea. —David Eppstein (talk) 02:52, 9 August 2015 (UTC)

Agreed (other than the assumption of mental issues), and as I said earlier, the proposed "norms" don't make conceptual sense: |author2-last= implies the surname of the second author, while |author-last2= implies the second surname of the (singular) author. I.e., there are multiple, independent reasons not to deprecate this, and at least one to actually prefer the form Trappist wants to deprecate.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  04:00, 9 August 2015 (UTC)

Deprecation does not suddenly kill off anything.

—Trappist the monk (talk) 12:35, 9 August 2015 (UTC)

Must be why I still have an ant problem. This bug spray says "Deprecates on Contact!"  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  17:41, 10 August 2015 (UTC)

:-} ~ J. Johnson (JJ) (talk) 23:38, 11 August 2015 (UTC)

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

|authorn-last= vs. |lastn=

|editorn-first= vs. |firstn=

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

Suppress original URL

Discussion moved here for a somewhat broader audience.

When urls die for whatever reason, normal practice is to keep the url and if possible, add |archive-url= and |archive-date=. Doing so links |title= to the archive copy and links static text provided by the template to the original url.

It has been suggested that we adopt a mechanism to suppress the original url when it is not dead in the sense of 404 or gateway errors and the like, but dead in the sense that the url has been taken over by someone and is now a link farm or advertising or phishing or porn or other generally inappropriate content.

To accomplish this I have suggested modifying the code that handles |dead-url=. This parameter takes a limited set of defined keywords (yes, true, y, no) and adjusts the rendered output accordingly. We could add another keyword that would render the static text in the same way as |dead-url=yes except that this value would not link the static text with the original url.

The question is: What should this defined keyword be? These have been suggested: hide, nolink, origspam, originalspam, spam, advert, phishing, fraud, unfit, usurped.

Is any of these the best keyword? Is there another keyword that would be better?

—Trappist the monk (talk) 15:05, 12 August 2015 (UTC)

Commenters are encouraged to read through the original thread also. --Izno (talk) 15:32, 12 August 2015 (UTC)

I suggest topic-changed. This covers complete takeover by an undesireable publisher, but also covers the case of the original publisher no longer having a page that supports the material in the article. For example, software publisher X had a page about a quirk of version 99 of their software, which Misplaced Pages described with a citation to the relevant X webpage. Once version 100 of the software is released, X removes the relevant webpage and does not provide information about the quirk anywhere on their site. Jc3s5h (talk) 15:43, 12 August 2015 (UTC)

The purpose of |dead-url= is to indicate for pages which are still live that they can be accessed (when an archive url is also present) (for the case of the original publisher). So from this point of view, adding an archiveurl solves that "broader" issue. Even in the case where an archiveurl cannot be identified and subsequently provided, you can set deadurl to yes and still have that case covered. --Izno (talk) 16:06, 12 August 2015 (UTC)

I don't see any benefit in having citations provide links to dead URLs. However, if other people do, then I suggest simply |dead-url=nolink to describe the function, with an update to the template documentation describing when it is appropriate (or not) to not provide the link to a dead URL. Thanks! GoingBatty (talk) 19:01, 12 August 2015 (UTC)

The benefit I see to providing links to dead URLs (not necessarily clickable) is that the editor who marked the URL as dead might not have the knowledge to find a substitute at a related web page, but a later editor might have that knowledge; the dead URL serves as a clue for finding a substitute. Jc3s5h (talk) 19:18, 12 August 2015 (UTC)

@Jc3s5h: I agree that a later editor may be able to use the dead URL to find a substitute web page, and the archiveurl does not necessarily contain the original URL. I'm all for keeping the dead URL in the citation template for this purpose. However, I suggest that the citation only provide one link for the reader when the original URL is dead. Thanks! GoingBatty (talk) 02:38, 13 August 2015 (UTC)

What about adding a few more keywords, say:

• usurped for domains now operated by a different entity (covers advertising, linkfarm, fraud, spam, phishing, or site/content unrelated to original)
• purged for domains operated by original entity but for which the original website content has been deleted
• abandoned for domains that are no longer registered

The latter may not as desirable as the first two, as domain registrations can fluctuate. Mindmatrix 21:53, 12 August 2015 (UTC)

Multiple keywords are possible. For the purposes of this conversation, I don't think abandoned domains need to be hidden because such domains are the definition of dead. I see no reason to hide links like that.

—Trappist the monk (talk) 10:22, 13 August 2015 (UTC)

Since it has gotten quiet here I have implemented |dead-url=usurped to suppress the link to the original url:

And here are tests to show that |dead-url=no and |dead-url=yes still works as they should:

{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=no}}

"Title". Archived from the original on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=yes}}

"Title". Archived from the original on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 16:39, 14 August 2015 (UTC)

The documentation of the parameter value should make the intent of |dead-url=usurped clear (in accordance with the discussion above). Other than that, looks good. --Izno (talk) 16:54, 14 August 2015 (UTC)

Looks good. Mindmatrix 15:09, 16 August 2015 (UTC)

The more I think about the keyword usurped, the less I like it. The term certainly fits for those cases where a domain name has been usurped but does it fit for all other cases where it is prudent to suppress the original url? I'm not sure, so rather than use a keyword that may have limited specificity, I think we should switch to a more general keyword, perhaps unfit, which would covers a broader variety of reasons for suppression of the original url.

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

At the risk of boring all of you, I will re-express my view that the parameter value should express the function, not the reason (as I said in the previous discussion linked above, and as GoingBatty said above. I like "hide" or "nolink".

TL:DR; version: The value of |display-editors=, for example, is either a number (to show a given number of editors) or "etal" (to show "et al." without listing all of the editors in the citation template. We don't dictate why an editor should use a specific value, we just show how to get the display you want, assuming that editors will make a good choice (a bad assumption, I know, but you have to start by treating people like competent adults). There are many reasons why someone might want to suppress a link to the original URL: it is a porn site, the site has been sold, the page has been moved or archived, the editor wants a consistent citation style, or other reasons I can't think of. We can list some of them in the documentation, but assuming only one reason for hiding the URL paints us into a corner. – Jonesey95 (talk) 19:42, 17 August 2015 (UTC)

I was hoping you wouldn't re-iterate your opinion so I wouldn't have to reiterate mine. To wit: The problem I have with function over purpose is that function enables behavior that may not be desirable. For example, I can't think of any reason other than a link being a "bad" link to be correct to hide. And my feeling is that the suitable keyword should reflect the reason. This allows us to trivially say "yes, you have used this as intended". I want in fact to preempt other reasons for usage without associated keywords, because I do not want "oh, the site is dead" simply to cause the link to be suppressed (as I am sure there is at least one person who would be wont to do so). See above illustrative discussion on that point. --Izno (talk) 21:59, 17 August 2015 (UTC)

In the cases of |dead-url=hide or |dead-url=nolink or similar, we create a mechanism that doesn't explain to editors of a later age why the action was taken. With |display-editors=etal, |mode=cs2 it's pretty easy to determine why the parameter was set the way it was set and that it is, or is not, set properly. Setting |dead-url=usurped or |dead-url=unfit gives follow-on editors some indication why the original url is suppressed. Like Editor Izno, I can think of no real reason why an original url should be suppressed unless it leads to inappropriate content. As I indicated before, we can have a variety of keywords to use as reasons should experience dictate a need.

—Trappist the monk (talk) 13:08, 18 August 2015 (UTC)

Supported keywords are now unfit and usurped (also shows that auto |format=PDF works correctly when original url is suppressed):

{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=unfit}}

"Title" (PDF). Archived from the original (PDF) on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=usurped}}

"Title" (PDF). Archived from the original (PDF) on 2015-08-14. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 16:45, 24 August 2015 (UTC)

ISBN error category

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

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

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

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

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

If Category:Pages with ISBN errors is hard coded into the tool, I have no sympathy. Misplaced Pages:WPCleaner/Configuration/Help#isbn_errors_categories suggests that ISBN categories are kept in a configuration file somewhere though that isn't at all clear from the documentation. If this latter is true, then I see no reason not to proceed.

—Trappist the monk (talk) 13:39, 19 September 2015 (UTC)

Magioladitis, can you provide some details? If we are breaking something by standardizing this category name, we are willing to help fix it or test the tool after the change. It looks like we may need to change the second category name at User:NicoV/WikiCleanerConfiguration#ISBN; will that fix the problem? – Jonesey95 (talk) 13:46, 19 September 2015 (UTC)

Yet another example of two levels of title within a journal publication

The following reference is a paper, part of a conference proceedings that was published as an issue of a journal (whose name indicates that it regularly publishes proceedings in this way, but with a combined volume and issue numbering system that looks much more like a journal than like a book series). The following formatting produces a citation that looks correct but with what I believe to be incorrect metadata. Is there a way to get the metadata right, too, or is this the best I can do?

{{cite journal | last = Charatonik | first = Janusz J. | title = Selected problems in continuum theory | url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf | issue = 1 | journal = Topology Proceedings | mr = 2048922 | pages = 51–78 | department = Proceedings of the Spring Topology and Dynamical Systems Conference | volume = 27 | year = 2003}}

produces

Charatonik, Janusz J. (2003). "Selected problems in continuum theory" (PDF). Proceedings of the Spring Topology and Dynamical Systems Conference. Topology Proceedings. 27 (1): 51–78. MR 2048922.

—David Eppstein (talk) 01:41, 25 August 2015 (UTC)

Because there is no COinS record assigned to |department=, 'Proceedings of the Spring Topology and Dynamical Systems Conference' is not included in the metadata. Rewriting this cite to use {{cite conference}} isn't much better:

{{cite conference | last = Charatonik | first = Janusz J. | title = Selected problems in continuum theory | url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf | issue = 1 | journal = Topology Proceedings | mr = 2048922 | pages = 51–78 | booktitle= Proceedings of the Spring Topology and Dynamical Systems Conference | volume = 27 | year = 2003}}

In this case, 'Topology Proceedings' is left out which isn't any better and is probably worse, because the journal title is common to the two volumes published each year.

—Trappist the monk (talk) 10:38, 25 August 2015 (UTC)

Use of |contribution/chapter= seems more suitable, but – oops! – red messages:

• Charatonik, Janusz J. (2003). "Proceedings of the Spring Topology and Dynamical Systems Conference" (PDF). Topology Proceedings. 27 (1): 51–78. MR 2048922. {{cite journal}}: |chapter= ignored (help)

~ J. Johnson (JJ) (talk) 20:55, 26 August 2015 (UTC)

Yes, that would be my preference, if it worked. But it doesn't, {{cite journal}}/|department= does, and it appears from Trappist's message above that it doesn't even produce bogus metadata. So that's what I'll be using for now. —David Eppstein (talk) 20:11, 29 August 2015 (UTC)

On one hand, I would be happy for any reasonable work around. On the other hand, COinS is not the only kind of metadata here. The names of parameters also carry information regarding the nature of the data encoded. E.g., |journal= implies the source is journal (specfically, an academic journal), which is different from a newspaper or a book. Likewise, |department= is defined at Cite journal#Periodical as "Title of a regular department, column, or section within the periodical or journal", and has specific effects on the resulting formatting. To use these parameters for other purposes is a form of metadata corruption. And (as has been previously commented) eventually leads to some unsuspecting editor attempting to "correct" what looks like an error. ~ J. Johnson (JJ) (talk) 22:18, 30 August 2015 (UTC)

|translator=

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

|translator=

|translatorn=

|translator-first=

|translator-last=

|translator-link=

|translator-mask=

|translator-firstn=

|translator-lastn=

And an example:

{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}}

Hesiod (1810). "Works and Days". English Translations: From Ancient and Modern Poems. Vol. 2. Translated by Cooke, Thomas. N. Blandford. p. 745.

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

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

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

This is a good addition to the module. It will be welcomed by many editors. Here's how it looks with |others=:

{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}

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

That looks right to me. As for the fixed text "Translated by", I like it. Our guidance in the documentation for CS1 templates has contained only this recommended form since October 2012, as far as I can tell. – Jonesey95 (talk) 18:17, 25 August 2015 (UTC)

The ball on naming of parameters with numbers hasn't been resolved yet, so I would expect to see the number-in-the-middle variants also. --Izno (talk) 21:40, 25 August 2015 (UTC)

I don't think consistency requires us to introduce number-in-the-middle variants of new parameters, just because some of our old and entrenched parameters already have them. I'd prefer to see only one version of the new parameters rather than trying to duplicate all the variants of the old parameters. —David Eppstein (talk) 17:29, 27 August 2015 (UTC)

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

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

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

Good, as long as these also work:

|translatorn-first=

|translatorn-last=

Discussions above (e.g. #deprecate enumerator-in-the-middle parameters) do not indicate a consensus in favor of this role-lastn order, with multiple editors objecting to it as counter-intuitive.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  02:16, 29 August 2015 (UTC)

As also noted in the relevant discussion, retaining both

|n-last=

|lastn=

and

|n-first=

|firstn=

is inconsistent and could also be counterintuitive. Per your suggestion then, |lastn=, |firstn= should be deprecated? 208.87.234.201 (talk) 14:52, 12 September 2015 (UTC)

Time of day field

I would like to propose that we add an optional field to Template:Cite web (and by extension also to Template:Cite tweet) for the hours and minutes of the day, perhaps also time zone.

This data is sometimes available in things, and where it is, I think it would be a good thing to add it.

This helps in cases where there is a dispute on how to organize things, who said what first, etc.

Sometimes you might want to cite 2 news articles about something made in the same day (or 2 tweets) and knowing that information could be useful for putting them into the correct order without requiring people to constantly go and check what the tweet said. This is also particularly useful if the tweet is taken down and wasn't archived. Ranze (talk) 22:02, 28 August 2015 (UTC)

If a tweet is taken down, and has not been archived anywhere, then it is not verifiable, and I would question its suitability as a source. If you feel it is useful to document the exact time some tweet or other information is posted/published, you can always add that following the template. I am not aware that a "time" field is necessary. ~ J. Johnson (JJ) (talk) 22:47, 28 August 2015 (UTC)

I would think that in the rare instance where it was necessary to discuss the time various sources were published, it would be necessary to describe the times in the body of the article rather than leaving it to the footnotes. Jc3s5h (talk) 00:09, 29 August 2015 (UTC)

"Footnotes" is a bit ambiguous. More particularly, if short cites are used then the time could be used in the same manner as a page number, perhaps using |loc=. But however this might be done, the bottom line here is that (lacking any specific demonstrated need) we seem to have adequate means for adding timestamps, and the proposed field is not needed. ~ J. Johnson (JJ) (talk) 19:26, 2 September 2015 (UTC)

vancouver error tweak

I have noticed that a space between the two initials of a name in |vauthors= is not detected as an error. I think that I have fixed that:

—Trappist the monk (talk) 21:55, 31 August 2015 (UTC)

page protection applied to the suggestions list

Module:Citation/CS1/Suggestions has been, since it creation, unprotected. At the time, I wondered if that page should be protected, but I didn't pursue it and have come to believe that protection of that page is not necessary.

The page was set to template editor level protection by Editor Courcelles at the request of Editor CFCF. That discussion, since archived, is here. Because it has been archived, I have raised the issue here.

Is the current (template editor) protection appropriate?

Should we keep or revert?

—Trappist the monk (talk) 10:50, 4 September 2015 (UTC)

As an editor with template editor rights, I don't mind, but I think it's odd that a page that has never been vandalized or even edited incorrectly, as far as I can tell, would be protected. The page has 42 edits total, by my count.

Since you bring it up, is it somehow possible to use regular expressions on that page? I may have asked this before. There are a lot of creative spellings of |access-date=, for example, that could be caught with a few regular expressions. – Jonesey95 (talk) 14:01, 4 September 2015 (UTC)

Perhaps improperly edited once (you reverted).

Feature requests has your regex suggestion.

—Trappist the monk (talk) 15:32, 4 September 2015 (UTC)

Oops. I think my brain thought to set it to semi, and my fingers to template. Courcelles (talk) 17:32, 4 September 2015 (UTC)

pattern matching for suggestion list

Perhaps there is reason to be somewhat optimistic. I think that all of these are caught by this pattern: = 'accessdate'

• "Title". {{cite web}}: Unknown parameter |acccessdate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accesdate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |access date= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accessate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accessdare= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessdatte= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessddate= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessdte= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accessed= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accessedate= ignored (help)
• "Title". {{cite web}}: Unknown parameter |accesssdate= ignored (|access-date= suggested) (help)
• "Title". {{cite web}}: Unknown parameter |accssdate= ignored (help) – |accssdate= missing first 'e' so not a pattern match
• "Title". {{cite web}}: Unknown parameter |acessdate= ignored (|access-date= suggested) (help)

As the pattern is written, |accessdare= returns a partial match 'accessda'. I guess that could be a good or bad; too tight and we might as well just use the exact-match-method we use now or too loose and we get a lot of false positives.

At the moment, Module:Citation/CS1/sandbox only catches |access-date= errors – I did that so that I could be sure that the errors weren't being caught by the existing code. Now I have to figure out how to integrate this with the existing test. And of course, I need to ask, do we really need this?

—Trappist the monk (talk) 18:45, 4 September 2015 (UTC)

Regular exact-match-method restored. I've added a second pattern for variations on a theme of publisher using this pattern: +ers?$'] = 'publisher'

• Title. {{cite book}}: Unknown parameter |pubisher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publiser= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publishers= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publsher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |publsiher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |pulbisher= ignored (|publisher= suggested) (help)
• Title. {{cite book}}: Unknown parameter |pulisher= ignored (|publisher= suggested) (help)

—Trappist the monk (talk) 22:21, 4 September 2015 (UTC)

At the end of this discussion, I noted that the suggestion mechanism doesn't allow suggestions for enumerated parameters. This is true except for the specific case of |autor2= which has an exact-match rule = 'author2'. Using patterns may be a way to solve this weakness. Using this pattern: +r%d+'] = 'author#':

• Title. {{cite book}}: Unknown parameter |autor1= ignored (|author1= suggested) (help); Unknown parameter |autor1= ignored (|author1= suggested) (help)

—Trappist the monk (talk) 11:51, 5 September 2015 (UTC)

These new suggestions look helpful. Can we use something like '$1' in the suggestion to repeat the number that was detected by the pattern? – Jonesey95 (talk) 21:32, 5 September 2015 (UTC)

Without getting too complicated we can do one capture:

+r(%d+)'] = 'author$1' (see my previous example to see that it works)

More than that and some more involved code will be required.

—Trappist the monk (talk) 22:58, 5 September 2015 (UTC)

Double period bug (again)

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

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

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

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

Here is the citation from de:Digitale_Gesellschaft_(Schweiz):

{{Cite web |title=Überwachung in und aus der Schweiz: Das volle Programm |url=https://digitalcourage.de/blog/2015/ueberwachung-in-und-aus-der-schweiz-das-volle-programm |author=Digitale Gesellschaft Schweiz |publisher=Digitalcourage e.V. |date=2015-08-18 |accessdate=2015-09-07 }}

Digitale Gesellschaft Schweiz (2015-08-18). "Überwachung in und aus der Schweiz: Das volle Programm". Digitalcourage e.V. Retrieved 2015-09-07.

De:wp does not use the en:wp Module:Citation/CS1 to render citation templates. The de:wp, {{cite web}} is a template that is written using wiki markup.

Probably best to raise the issue at de:Vorlage Diskussion:Cite web.

—Trappist the monk (talk) 11:09, 7 September 2015 (UTC)

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

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

RFCs on citation templates

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

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

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Misplaced Pages technical issues and templates When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

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 ". Wrong. The most commonly-used style guides MLA (, scroll down to the section "A page on a website") and the Chicago Manual of Style () 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 "). 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: Misplaced Pages . 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." (). 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 " (brackets in original source) and to even do so if it's a publication name. It's well-established that Misplaced Pages cites The New York Times and not nytimes.com, and even editors who who want to keep the "website" field italicized agree Misplaced Pages does not and should not cite "Sears.com" or italicize names with ".com" in the formal name, like Amazon.com. 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 ". I'm referring to the fact that Amazon.com, 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 Amazon.com, 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 ." It's not common, but some publishers include the domain 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 (Salon.com 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 Misplaced Pages 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) 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). http://wardsix.bog.spot.com/.

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. ~ ONUnicornproblem 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 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 http://ngm.nationalgeographic.com/, 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 Misplaced Pages:Manual of Style/Titles#Major works states, "Website titles may or may not be italicized 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 (Salon.com 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. — TAnthony 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 Misplaced Pages 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 |website=HuffingtonPost.com anyway, but even if the url is preferred to be shown, it should be HuffingtonPost.com and not HuffingtonPost.com. — TAnthony 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 Misplaced Pages (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 Misplaced Pages 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. — TAnthony 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 FooBarBaz.com 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 FooBarBaz.com", 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=]|...}}, not {{Cite web|website=]|...}}. 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 FooBarBaz.com example. In running prose, write: "According to a FooBarBaz.com article ...", but "...as the new CEO of 's.com". 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=]|...}}, not {{Cite web|news=]|publisher=]|...}}. 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 SnorkelWeasels.com says "Copyright 2015 SnorkelWeasels.com" 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: BBFC.co.uk, State.gov, Sears.com, and DMV.NY.gov. 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 (foo.bar.UofBaz.edu) 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. USEmbassy.gov 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 Corporate.Quux.com 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. Guardian.co.uk 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 Salon.com 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 Misplaced Pages, 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 Misplaced Pages:Manual of Style/Titles#Major works states, "Website titles may or may not be italicized 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 FooBarBaz.com article" vs. "according to FooBarBaz.com'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, Amazon.com). 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 Billiards.info (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)

• Italics by default -- TRPoD aka The Red Pen of Doom 11:54, 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 (talk • contribs) 16:01, 15 September 2015‎

• • The MOS we've been talkng about this entire thread absolutely does say, " "Website titles may or may not be italicized": Misplaced Pages:Manual of Style/Titles#Major works. --Tenebrae (talk) 16:20, 15 September 2015 (UTC)

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.— TAnthony 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.— TAnthony 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 Misplaced Pages's Manual of Style. Use common sense in applying it; it will have occasional exceptions." The subject of this discussion can be considered a reasonable exception. AHeneen (talk) 17:14, 21 September 2015 (UTC)

  A "regular" or "expected" exception is an oxymoron. --Izno (talk) 19:10, 21 September 2015 (UTC)

  No. A well-defined exception is a normal part of any process or system description. – Jonesey95 (talk) 19:13, 21 September 2015 (UTC)

  I'm a little confused. By saying an exceptions can be made, are we saying we want to italicize things that should not be italicized? That doesn't really make sense. Rotten Tomatoes and Metacritic, for example, are websites that aren't italicized. So I'm not sure what AHeneen is saying.--Tenebrae (talk) 21:32, 21 September 2015 (UTC)

I have qualified my prior comment with most, as one editor keeps going around and around and around like a broken record. Tenebrae: your objections are getting tiresome, even tendentious. To your objection to certain names being italicized when they get stuffed into the 'website' parameter, my simple suggestion is this (are you paying attention?): don't stuff those names into the 'website' parameter. At a slightly higher level you object that "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)

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 Misplaced Pages 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: "Misplaced Pages:Manual of Style/Titles#Major works states, 'Website titles may or may not be italicized 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)

Add citationstyle= parameter to CS1 templates

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

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

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

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

We have a start to this in |mode= and |name-list-format=, but you're right, it would take some work. – Jonesey95 (talk) 02:58, 11 September 2015 (UTC)

Your idea has been in the back of my mind since the introduction of |mode= or there abouts. At about the same time there was a kerfuffle regarding small caps and LSA if I recall correctly. I have thought that we can extend |mode= to support clearly defined styles. Step 1 after we decide that this is something that we should be doing is to set down just exactly what it is that defines a particular style and then and only then hack the code to make it a reality.

—Trappist the monk (talk) 03:04, 11 September 2015 (UTC)

I strongly favour this idea. It would render the maintenance of citations easier if there are fewer citation template types. Also, fixing inconsistent citation styles or changing them when there is consensus to do so would be much easier.Jo-Jo Eumerus (talk, contributions) 08:54, 12 September 2015 (UTC)

Ideally, in my view, |mode= would be used with the {{citation}} template, which would make life much simpler for users – no need to choose which of the cite templates to use. However, I suspect this is difficult or impossible in all cases because there isn't always enough information to pick the right formatting. The |website= discussion above exemplifies one issue: having it as an alias of |work= loses information. Peter coxhead (talk) 10:00, 12 September 2015 (UTC)

I strongly oppose having multiple citation styles at all, much less supporting external ones (i.e. other than CS1 and CS2, and we should retire CS2). But if we're stuck with it, something like this is the way to do it, and we should get rid of external-citation-style-specific templates for Vancouver, etc., and just have it all done by the Lua module on the fly. So consider this "support until we come to our senses and have a single citation style like, well, every other publication in the world".  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  12:31, 12 September 2015 (UTC)

If we are to retire one of CS1 or CS2, I would strongly prefer it to be CS1. All. Those. Periods. Make. It. Very. Difficult. To. Read. And. Really. What's. The. Point. Of. Them? —David Eppstein (talk) 20:28, 15 September 2015 (UTC)

Not sure how I feel about this being in {{cite xxx}} / {{citation}}, but I'd definitely support this feature if it could be shoved in {{reflist}}. Headbomb {talk / contribs / physics / books} 13:27, 12 September 2015 (UTC)

Reflist is only capable controlling styling of what's inside it, but that requires a strong classing dicsipline inside the templates (so same problem as above). It has absolutely no way of controling content of these templates. -- ] {{talk}} 09:06, 13 September 2015 (UTC)

<cite> has been fixed, so we can now use it for entire citation_has_been_fixed,_so_we_can_now_use_it_for_entire_citation-2015-09-12T12:54:00.000Z">

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

Done in the sandbox; compare live:

'"`UNIQ--templatestyles-000000C7-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

to sandbox:

'"`UNIQ--templatestyles-000000C9-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 13:47, 12 September 2015 (UTC)

Two comments:

1. @Pigsonthewing:, I think this may be the incorrect way to handle the microformat. Have a look, if indeed that first span is intended as a microformat.
2. The intent was for the <cite> to wrap the entire citation, whereas the sandbox is only wrapping the title. --Izno (talk) 19:30, 12 September 2015 (UTC)

Re: #1: why do you think it's wrong?

Re: #2: I made a minimal example because that is easier to read. Here is one that is more complex:

'"`UNIQ--templatestyles-000000CB-QINU`"'<cite class="citation web cs1">. '']''. 12 August 2015.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Centers+for+Disease+Control+and+Prevention&rft.atitle=Autism+Spectrum+Disorder+%28ASD%29&rft.date=2015-08-12&rft_id=http%3A%2F%2Fwww.cdc.gov%2Fncbddd%2Fautism%2Fdata.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

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

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

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

Looks OK to me. Strictly, COinS isn't a microformat, and works differently to them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)

I would check and make sure that Mediawiki:* and other parts of the CSS cascade aren't anywhere doing anything that relies on span.citation vs just .citation, and same for the .book class selector. I.e., ensure that moving the classes from <span> to <cite> doesn't break something we don't notice immediately. Then again, if it does, I'm sure someone will tell us. I've not looked at COinS much; if the book, etc., classes are part of COinS, they do seem to need to be in <span>, so we might need both (presumably the <span> inside the <cite>, since the span by itself would have no semantic "reality" on its own); but if that's just one of WP's own classes, it can be in the <cite>.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:43, 12 September 2015 (UTC)

The extent of .citation in Common.css is the following:

/* Highlight clicked reference in blue to help navigation */
span.citation:target {
    background-color: #DEF;
}
/* Styling for citations (CSS3). Breaks long urls, etc., rather than overflowing box */
.citation {
    word-wrap: break-word;
}
/* For linked citation numbers and document IDs, where
   the number need not be shown on a screen or a handheld,
   but should be included in the printed version */
@media screen, handheld {
    .citation .printonly {
        display: none;
    }
}

Indeed, @Edokter: I'm not sure about that first item there. Does the <ref>...</ref> include a span when it drops its content into the bottom of the page, or is that meant to specifically target our various and sundry reference templates? --Izno (talk) 00:13, 13 September 2015 (UTC)

That's the thing that makes the or whatever of the ref citation turn light blue when you are in the refs section and click on the ^ link to get back to where you were in the text. So, yeah, that would need to change to refer to the <cite>, or to be a class by itself without the element being named (unless we really do need the span as well; I'm still not sure if that class has anything to do with COinS). Ultimately it probably does not matter if have a <cite><span>{{cite journal|...}}</span></cite> structure; costs nothing but a few bytes.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  03:21, 13 September 2015 (UTC)

The Cite extension already provides the styles to turn the automatically generated referneces blue with the selector ol.references li:target, sup.reference:target. The span.citation:target snippet is an old remnant of the old link targeting mechanism, before the extension took over. The current snippet is useless and can be safely removed, because 1) references generated by citation templates, by themselves (ususally appearing between {{refbegin}}/{{refend}}), have no id and therefor 2) are not (and cannot) be linked to. That makes :target pretty pointless. -- ] {{talk}} 10:01, 13 September 2015 (UTC)

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

References

1. Blue 2008.
2. Not blue 2008.

• Blue (2008). Title. {{cite book}}: Invalid |ref=harv (help)
• Not blue (2008). Title. {{cite book}}: Invalid |ref=harv (help)

—Trappist the monk (talk) 11:05, 13 September 2015 (UTC)_has_been_fixed,_so_we_can_now_use_it_for_entire_citation"> _has_been_fixed,_so_we_can_now_use_it_for_entire_citation">

I see. In that case, The span should be removed or replaced by <cite>. Though it will work without the element in the selector, I'd prefer to keep the specificity consistent to prevent accidental linking to other elements with the .citation class. But that should not be a problem until the conversion is complete. -- ] {{talk}} 12:36, 13 September 2015 (UTC)

Sorry, I do not understand what you just wrote. In Module:Citation/CS1/sandbox, the cs1|2 template output (except for the COinS) was wrapped in <span>...</span>. It is now wrapped in <cite>...</cite>. My example shows, I think, that <cite class="citation"> is required to get the blue highlight when the target cs1|2 template is outside of a {{reflist}} as commonly occurs when an article uses {{sfn}} and {{harv}} et al.

—Trappist the monk (talk) 13:19, 13 September 2015 (UTC)

I was talking about the selector in Common.css. It should match whatever the module outputs. It now targets neither span or cite tags; just the .citation class, which is too broad. So I will make it target only cite.citation once the modules have been converted. If you still don't understand, don't worry about it. -- ] {{talk}} 21:52, 13 September 2015 (UTC)

FWIW, I am seeing blue highlight for the ref even for the "Not blue" sample above, when I click on it's "^" link-back. I'm supposing this is because the underlying sandbox code has changed in the interim, but thought I'd report it in case not, and the example is supposed to do something else, since it might be relevant for debugging, if so.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  16:21, 14 September 2015 (UTC)

The superscripts do have the blue highlight; that isn't the issue. The issue is with the long-form citations; these links: #CITEREFBlue2008 and #CITEREFNot_blue2008 (or their mates in the reference list). The 'Blue' citation was rendered with <cite class="citation book"> but the 'Not blue' citation was rendered with <cite class="book">.

—Trappist the monk (talk) 16:33, 14 September 2015 (UTC)

Hack to Module:Citation/CS1/sandbox in support of the examples I made here is undone.

—Trappist the monk (talk) 11:23, 19 September 2015 (UTC)

@SMcCandlish: Congratulations on getting this fixed; it's good to see us as a movement contributing in that way. I've previously had WP:NOT cited at me when I've tried to get us to lead by example in similar areas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 12 September 2015 (UTC)

Pfft! WP:NOT has no power whatsoever to tell me who I can and can't contact off-wiki to fix things like W3C contradicting their own standards. >;-) It's the kind of thing I'd do anyway; the WP issue just made me notice this particular case. This may actually have quite noteworthy longer-term effects; apparently the entire W3C Cheatsheet was not being synched with the actual, live W3C Recommendation (the real spec), but had only been synched by hand or something to some old version in 2009! And WHATWG does what the Cheatsheet says. And browser makers and many others do what WHATWG says, to some extent. As far as I know, WHATWG has not updated its own materials yet since this W3C fix, but they should soon enough. I suspect and hope that much of what we're seeing with browsers lagging so far behind what the W3C HTML5 Recommendation says to do may be directly and primarily due to this synchronization failure. It would certainly be hot if that's the case, and all of sudden they started consistently implementing stuff we've been waiting on since 2013.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:28, 12 September 2015 (UTC)

2013 is awfully optimistic. --Izno (talk) 00:06, 13 September 2015 (UTC)

Hee haw! Yeah, I mean just the new stuff; I wasn't talking about stuff we've been waiting to work properly since the '90s. LOL. There did seem to be a rush to implement (at least with prefixes) lots and lots of stuff from the old draft and early release versions of HTML5, and then it just kind of stopped. I think it's because the Cheatsheet wasn't updated, so WHATWG didn't update. Then the HTML5 spec was revamped in 2013, and kinda nothing happened.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  03:09, 13 September 2015 (UTC)

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

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

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

Handling multiple italicized titles

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

Another example would be: {{Cite book|chapter=Foreign Words and Phrases|work-noitalic=yes|work=''Blood of the Isles: Exploring the Genetic Roots of Our Tribal History'' |...}}.

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

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

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

{{cite encyclopedia}} does something like this:

{{cite encyclopedia |chapter=Chapter |title=Title |encyclopedia=Anthology}}

"Chapter". Title. Anthology.

and so does {{cite book}} (sort of):

{{cite book |chapter=Chapter |title=Title |encyclopedia=Anthology}}

"Chapter". Title. {{cite book}}: Unknown parameter |encyclopedia= ignored (help)

There are constraints imposed by the metadata. A book title in the metadata is two parts: article (chapter) title and book title. {{cite encyclopedia}} emits the value from |chapter= and |encyclopedia=. {{cite book}} on the other hand, emits the values from |chapter= and |title=. Presumably, the {{cite encyclopedia}} model is the preferred model for an anthology because, one presumes, that parameters like ISBN, publisher, etc. apply to the anthology and not to the component book. There is no way that I know of to feed a three-part title to the metadata.

It would seem not to difficult a task to create {{cite anthology}} and |anthology= so that we don't 'misuse' {{cite encyclopedia}}.

—Trappist the monk (talk) 17:15, 14 September 2015 (UTC)

The example of different titles depending on place of publication seems to go against the principle of editors citing the copy that they examined. In most cases one editor would add the cite, and would have had access to only one copy. If an American and UK edition were used, probably they were used by two different editors, and the two editors would not necessarily know if the pagination in the two versions was the same. Jc3s5h (talk) 17:55, 14 September 2015 (UTC)

Right. Titles are the primary identifier of books (and other items), and if a publisher changes the title there is no telling what else may have been changed. If two titles are actually identical than one might be considered a reprint of the other, but how would an editor know that? Best that distinct titles have distinct citations. If a book or article has been republished under a different title that can be mentioned following the citation. ~ J. Johnson (JJ) (talk) 22:40, 14 September 2015 (UTC)

This isn't quite what I'm getting at. These are works that I have on hand, and they have three relevant titles: "Chapter/Article", Logical Book, Physical Book, in the one case, and "Chapter/Article", Regional Book Title I , in the other. In the first case, I'm citing the specifics of a single work that has a hierarchy of three, not two, titles. In the other, I'm providing information to help readers locate the same source under two names (it has a typical hierarchy of two titles, but the major title has two variants). They're different cases.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  01:23, 15 September 2015 (UTC)

Oh. What you are talking about is not alternative titles, but titles at hierarchial levels of organization (e.g., work/chapter/section) - right? I got into that with the IPCC citations, but I am disinclined to re-visit it. ~ J. Johnson (JJ) (talk) 23:04, 15 September 2015 (UTC)

Cite book needs work alias for title

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

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

For the purposes of cs1|2, {{citation/core}} is dead.

{{cite book}} only supports |work= visually (discussed here) for which reason I have suggested elsewhere in these pages that |work= and its aliases should be ignored by {{cite book}} as they were in the old days of {{citation/core}}.

—Trappist the monk (talk) 17:54, 14 September 2015 (UTC)

That you have a preference in this regard doesn't address why lack of support for |work= is problematic. I'm not suggesting that {{Cite book}} handle |title= and |work= as separate entities, but rather alias one to the other, the same way |accessdate= can also be called |access-date=. I'm not sure what "only supports |work= visually" even means, but have to run for now; will re-read that stuff and see if I can suss your meaning, if you don't clarify in the interim.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  01:27, 15 September 2015 (UTC)

{{cite book}} only supports |work= visually... means that you can have |work= in {{cite book}} with |title= and you will see it in the rendered citation. But, a value in |work= without |chapter= causes an error in the metadata – the citation is treated as a journal article (a bug I think that bears some thinking on). When |chapter= is included with |title= and |work= in {{cite book}}, |work= is rendered but not made part of the metadata while the other two parameters are (correctly this time).

—Trappist the monk (talk) 03:03, 15 September 2015 (UTC)

That sounds like it would be fixed by having |work= and |title= be the same thing (one an alias for the other). Why would we want {{Cite book|title=...|work=...}}? That would generally make the same not-sense as {{Cite journal|journal=...|work=...}}. That said, having a special case where the use of both would case |work= to render but be omitted from the metadata would actually resolve my above need for being able to cite The Oxford Guide to Style (a logical |work=, and previously published as a separate volume, and in both editions having its own chapters and authors and such), and the Oxford Style Guide (a published |title= of the book in the "bound thing of paper in my hands" sense). In pseudocode:

if $title

if $work

print italicized $work ; print ', in '; print italicized $title ;

else print italicized $title

else if $work

print $work

else throw missing-title error

Seems pretty simple, though I forget what is using template code and what is using Lua in these things. This could even be used for bound journals, with the bound physical book being cited as the |work= and the journal issue being cited as |journal=. I ran into this problem before trying to cite my bound volumes of Jugend, The Studio, etc., in some Art Nouveau articles, and again ended up doing the two-citations-back-to-back thing: {{Cite journal}} followed by a {{Cite book}} for the bound volume that was largely a redundant citation, but necessary to both WP:SAYWHEREYOUGOTIT and preserve the details of the bound and original publications. This can be important because, e.g. The International Studio was bound by more than one operation, and differently; I have some bound volumes of it that overlap, with some being bound by calendar year, the others being bound by the journal's own volume/issue numbering order.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:49, 16 September 2015 (UTC)

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

{{cite book|first1=Elwyn R.|last1=Berlekamp|first2=John H.|last2=Conway|first3=Richard K.|last3=Guy|title=]|volume=Volume 2: Games in Particular|year=1982|publisher=Academic Press}}

Berlekamp, Elwyn R.; Conway, John H.; Guy, Richard K. (1982). Winning Ways for your Mathematical Plays. Vol. Volume 2: Games in Particular. Academic Press. {{cite book}}: |volume= has extra text (help)

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

Request move for Module talk:Citation/CS1

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

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

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

{{cite ___ |title=Title |chapter=Chapter |work=Work}}

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

and cs2:

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

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

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

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

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

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

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

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

Module:Citation/CS1/sandbox tweaked. These are {{cite conference}} examples:

• |title=, |chapter=, |work= – uses jtitle, atitle, and sets genre to article
  • '"`UNIQ--templatestyles-000000FA-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=conference&rft.jtitle=Work&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
• |title=, |chapter= – uses btitle, atitle, and sets genre to bookitem
  • '"`UNIQ--templatestyles-000000FC-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.atitle=Chapter&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
• |title= – uses btitle and sets genre to book
  • '"`UNIQ--templatestyles-000000FE-QINU`"'<cite class="citation conference cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

the same but this time with the one-way alias |book-title=; chapter is held in |title= (|chapter= is ignored when |book-title= is set):

• |book-title=, |title=, |work= – uses jtitle, atitle, and sets genre to article
  • '"`UNIQ--templatestyles-00000100-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''. ''Work''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=conference&rft.jtitle=Work&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
• |book-title=, |title= – uses btitle, atitle, and sets genre to bookitem
  • '"`UNIQ--templatestyles-00000102-QINU`"'<cite class="citation conference cs1">"Chapter". ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.atitle=Chapter&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
• |book-title= – uses btitle and sets genre to book
  • '"`UNIQ--templatestyles-00000104-QINU`"'<cite class="citation conference cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 15:05, 15 September 2015 (UTC)

|section= not working in cite news?

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

This?

{{cite news |last = Hampton |first = Howard |title = Black Flag: Waving Goodbye to the World |newspaper = ] |date = 1984-04-17 |page = 8 |section = 3 |url = https://news.google.com/newspapers?nid=1959&dat=19840417&id=OXMhAAAAIBAJ&sjid=OogFAAAAIBAJ&pg=2247,1781571&hl=en |ref = harv}}

Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. p. 8. {{cite news}}: |section= ignored (help); Invalid |ref=harv (help)

|section= is an alias of |chapter=, hence the error message. Consider |at=Section 3, p. 8

Hampton, Howard (1984-04-17). "Black Flag: Waving Goodbye to the World". The Phoenix. Section 3, p. 8. {{cite news}}: Invalid |ref=harv (help)

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

Is |section= (or |chapter= or whatever) not supposed to work, then? Curly Turkey 🍁 ¡gobble! 00:29, 16 September 2015 (UTC)

The mention of |chapter= and |section= in Template:Cite news#COinS could lead someone to think it is OK to use those parameters in {{cite news}}. GoingBatty (talk) 02:31, 16 September 2015 (UTC)

I sthere some reason it shouldn't be? The newspaper I cited had sections with their own paginations. Curly Turkey 🍁 ¡gobble! 03:58, 16 September 2015 (UTC)

Isn't it true that most newspapers have separate sections and pagination? The documentation for |at= at {{cite news}} specifically includes Section. The decision to make |section= an alias of |chapter= was taken long ago in support of another template ({{cite manual}} I think). Chapters are not supported in periodicals because it is not possible to shoehorn three cs1|2 title-holding parameters (|newspaper=, |title=, and |section= in this case) into the two metadata title-holding parameters (rft.jtitle and rft.atitle). Because there is an in-source metadata parameter (rft.pages), setting |at=Section 3, p. 8 renders the complete citation visually as well as in the metadata.

—Trappist the monk (talk) 10:46, 16 September 2015 (UTC)

Well, that went over my head, but okay ... But wouldn't it be better to have the template automatically format it at least, rather than spit out an error? Curly Turkey 🍁 ¡gobble! 12:18, 16 September 2015 (UTC)

The template spits out an error because it doesn't know what to do with a chapter alias in a periodical-style citation. How should it be automatically formatted? Quoted? Italics? Neither of those? Where in the rendered citation should it go? The answers to these questions must apply to a very large majority of the templates in which |section= is used.

—Trappist the monk (talk) 15:02, 16 September 2015 (UTC)

Well, if it's what I have to do then it's what I have to do, but it (a) feels like a hack, and (b) is totally unintuitive. |at= "May be used instead of 'page' or 'pages' where a page number is inappropriate or insufficient"—in this case |page= sure doesn't seem insufficient (it's on page 8!), and |at= isn't the obvious answer (you have to dig to find it, and then interpret the documentation as "Aha! This situation!").

if |section= et. al don't work, then shouldn't they be removed from the "COinS metadata is created for these parameters" section? Curly Turkey 🍁 ¡gobble! 23:27, 16 September 2015 (UTC)

|section= should be supported in periodicals, independently of |chapter=, because there are important sources that do break articles by sections. Also by paragraphs. ~ J. Johnson (JJ) (talk) 22:40, 17 September 2015 (UTC)

error message tweak

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

• "Title". Journal. {{cite journal}}: |chapter= ignored (help)
• "Title". Journal. {{cite journal}}: |contribution= ignored (help)
• "Title". Journal. {{cite journal}}: |entry= ignored (help)
• "Title". Journal. {{cite journal}}: |article= ignored (help)
• "Title". Journal. {{cite journal}}: |section= ignored (help)

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

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

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

</nowiki>

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

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

—Trappist the monk (talk) 09:59, 17 September 2015 (UTC)

COinS and smallcaps

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

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

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

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

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

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

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

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

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

Changes to Module:Citation/CS1 are:

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

Changes to Module:Citation/CS1/Configuration are:

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

Changes to Module:Citation/CS1/Whitelist are:

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

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

1. hyphenate parameter names in error messages; discussion

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

Looks good to me. Look at all of the good work we have accomplished in the last couple of months! – Jonesey95 (talk) 13:45, 19 September 2015 (UTC)

Test for date in |author=?

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

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

If such a test is to be created, bear in mind we allow editors to enter corporate authors in this field. Some organizations have a date fragment in their name. So the test should only be triggered if a well-formed date containing a year, month, and day is present. Jc3s5h (talk) 14:11, 19 September 2015 (UTC)

@Jonesey95: Edits like the one you've mentioned are a result of editors not fixing the suggestions given by Reflinks before saving their edits. We tried to discuss this with Dispenser but did not get any answer. BattyBot tries to fix/remove some bad author values, but can't fix them all. Therefore, I support a maintenance category. GoingBatty (talk) 14:16, 19 September 2015 (UTC)

Reflinks was the tool: diff and diff. But, like any edit, the tool-user is equally culpable.

If this is a problem caused by a tool, then the tool should be fixed. I suspect that searching for date formats that both do and don't comply with WP:DATESNO is a challenge that we should only accept if there is significant evidence of widespread malformed |author= parameters in the field.

(I've renamed this section to remove {{para}} so that section links from watch lists work.)

—Trappist the monk (talk) 14:31, 19 September 2015 (UTC)

@Trappist the monk: A quick search of the September 2015 database dump of found 2,304 results. I'm sure other formats will find additional instances. I'm adding some rules for BattyBot to remove the date from the author parameter when it matched the YYYY-MM-DD date in the date parameter. I'd also be happy if ReferenceBot would notify editors when they added references with incorrect parameters like this. GoingBatty (talk) 15:40, 19 September 2015 (UTC)

Is that number sufficiently large to make us add code to the module and create some sort of category to support it? Is this an automated tool issue or is it an error commonly made by editors filling out the template?

—Trappist the monk (talk) 16:06, 19 September 2015 (UTC)

@Trappist the monk: To determine if it's sufficiently large enough, I guess you would first identify the most common incorrect formats, see how many added/tweaked rules could be added to BattyBot, and then see how many are left. My guess is this is commonly an issue of people not taking care when using automated tools (and people unwilling to fix their tools), but I have no statistics on that. GoingBatty (talk) 18:32, 19 September 2015 (UTC)

How can BattyBot fix these errors if they are not yet in a category? – Jonesey95 (talk) 20:31, 19 September 2015 (UTC)

@Jonesey95: I built the list of articles based on a database search for author\s*=\s*(January|February|March|April|May|June|July|August|September|October|November|December)\s+\d{1,2},\s+\d{4}. GoingBatty (talk) 20:40, 19 September 2015 (UTC)

Citeweb website parameter

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

Foreign language authors & publishers

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

References

1. 고경석 (3 December 2010). '헬로우 고스트' 명품조연 고창석-장영남, 코믹귀신 '변신' . 아시아경제 . Retrieved 22 September 2015. {{cite news}}: Invalid |script-title=: missing prefix (help)

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

Non-standard romanisations could be addressed by including the author's ORCID iD, or other authority control (or even a Wikidata ID), where they have one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:11, 23 September 2015 (UTC)r

• B-Class Help articles
• High-importance Help articles
• Misplaced Pages Help Project pages
• Misplaced Pages requests for comment