Help talk:Citation Style 1

Citation templates ... in conception ... and in reality

spam black list and archive urls

There is a discussion: Wikipedia:Village pump (technical) § Possible interaction of spam blacklist and citation archival-url. Apparently, the spam blacklist can be triggered by a url embedded in an archive.org snapshot url (and presumably in other achive urls that include the original url). This presents a problem to editors who try to fix cs1|2 template citations. One solution described at the aforementioned discussion is to percent encode the original url in the archive url; this:

https://web.archive.org/web/20091002033137/http://www.example.com/

becomes this:

https://web.archive.org/web/20091002033137/http%3A%2F%2Fwww.example.com%2F

I have hacked on Module:Citation/CS1/sandbox and implemented this solution. Here for |url= and |title=:

{{cite book/new |title=Title |url=http://www.example.com |archive-url=https://web.archive.org/web/20091002033137/http://www.example.com/ |archive-date=2009-10-02 |url-status=unfit}}

Title. Archived from the original on 2009-10-02.{{cite book}}: CS1 maint: unfit URL (link)

'"`UNIQ--templatestyles-00000023-QINU`"'<cite class="citation book cs1">[https://web.archive.org/web/20091002033137/http://www.example.com/ ''Title'']. Archived from the original on 2009-10-02.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft_id=http%3A%2F%2Fwww.example.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: CS1 maint: unfit URL ([[:Category:CS1 maint: unfit URL|link]])</span>

and here for |chapter-url= and |chapter=:

{{cite book/new |chapter=Chapter |chapter-url=http://www.example.com |title=Title |url=http://www.example.com |archive-url=https://web.archive.org/web/20091002033137/http://www.example.com/ |archive-date=2009-10-02 |url-status=unfit}}

"Chapter". Title. Archived from the original on 2009-10-02.{{cite book}}: CS1 maint: unfit URL (link)

'"`UNIQ--templatestyles-00000027-QINU`"'<cite class="citation book cs1">[https://web.archive.org/web/20091002033137/http://www.example.com/ "Chapter"]. [http://www.example.com ''Title'']. Archived from the original on 2009-10-02.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter&rft.btitle=Title&rft_id=http%3A%2F%2Fwww.example.com&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span><span class="cs1-maint citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: CS1 maint: unfit URL ([[:Category:CS1 maint: unfit URL|link]])</span>

This code looks for the original url (|url=) in the archive url (|achive-url=). If found, the achive url is split at the beginning of the embedded original url. The embedded original url is then percent encoded and the two parts rejoined to make a new archive url. The same is true when |chapter= and |chapter-url= are set, and |chapter-url-status=unfit (or usurped).

For now this applies to all 'unfit' and 'usurped' urls. Presuming we keep this, I wonder if we ought not have another keyword for |url-status=; perhaps blacklisted. A separate maintenance category might also be in order.

Keep? Discard? Opinions?

—Trappist the monk (talk) 17:00, 3 October 2019 (UTC)

I think this is as much an acceptable solution as any, at least as long as archive services do not disallow percent-encoding referrals for whatever weird reason. A social rather than technical issue may arise from editors who may wonder why a blacklisted url displays in the first place. 72.43.99.130 (talk) 18:37, 3 October 2019 (UTC)

... editors who may wonder why a blacklisted url displays in the first place. I think that's not an issue because the title is not linked to the blacklisted url but to a (presumably) good snapshot of the website page before it was blacklisted. I presume here that the editor who chose the archive url did so in good faith and that the archived source does, indeed, support the Wikipedia article's text. I suppose that the argument might be made that a blacklisted url is a blacklisted url whether it's archived or not. Still, to your point, using |url-status=unfit or |url-status=usurped disables the link to the original url in the rendered citation.

—Trappist the monk (talk) 19:12, 3 October 2019 (UTC)

Never mind. I have reverted this change per the linked discussion.

—Trappist the monk (talk) 22:30, 3 October 2019 (UTC)

Regarding this:

I suppose that the argument might be made that a blacklisted url is a blacklisted url whether it's archived or not.

I think that shouldn't be an issue. We should distinguish between these two cases:

1. The url (or domain) was always malware/spam; it was never suitable for a reference, and still is not.
2. The url (or domain) started off as a good source, but is malware/spam now.

One strength of having an archive in the first place, is that it can help us deal with case #2, and provide a good copy of an url back before it changed. This may be an argument for different handling of the two cases above, which may imply different values for |url-status.

I am not certain what your expectations were about how editors should employ the values unfit and usurped , given that the CS doc for url has little to say about them. But we could, I suppose, assign (or reassign) the usurped value to case #2: that is, "The url was good once (and the archive may still retain a copy), but it isn't good anymore", which goes along with one set of display possibilities including a displayable |archive-url. That might leave unfit to cover case #1, with a different set of display characteristics (including forbidding |archive-url, if it was always bad). Or, if that's not what you intended unfit to be, then perhaps some new value (forbidden, blacklist, or whatever) to indicate that this was never a usable url and the |archive-url should be suppressed if there is one.

Whatever the case (and even if nothing changes wrt to those two values), the documentation should be updated to clearly explain these two values, and how they should be used. I'm okay with not having it updated now, especially if the usage or meaning of these values is in flux, but once things shake out, there should be a clear and thorough explanation. (If you want help editing some doc for it when the time is right, feel free to issue a request on my Talk page, and I'll be happy to help.) Mathglot (talk) 02:44, 5 October 2019 (UTC)

Original discussions about parameter values unfit and usurped are at:

• Module talk:Citation/CS1/Feature requests/Completed § Suppress original URL
• Help talk:Citation Style 1/Archive 9 § Suppress original URL

Neither of those discussions consider blacklisted urls.

There were subsequent discussions with regard to parameter values:

• Help talk:Citation Style 1/Archive 11 § Suppressing unnecessary archive-urls
• Help talk:Citation Style 1/Archive 14 § Recycled urls
• Help talk:Citation Style 1/Archive 36 § Handling sites that have become malicious – mentions blacklisted urls
• Help talk:Citation Style 1/Archive 42 § Correct usage of dead URL?
• Help talk:Citation Style 1/Archive 43 § The dead-url=usurped mechanism seems to be broken

With regard to your statement:

The url (or domain) was always malware/spam; it was never suitable for a reference, and still is not.

It has been pointed out that percent-encoding the original url in an archive url may be used to mask a cite that has always been malicious. That is also true of archive sites that support url shortening – create an archive copy of the malicious site at archive.today, use the shortened url to avoid the blacklist (until one of the bots that lengthens shortened urls arrives to lengthen it). As an aside, when these lengthening bots attempt to save an article that now has a blacklisted url embedded in an archive url, what happens?

I suppose that when archive urls link to malicious archives, the whole archive url can be blacklisted (presumably with sufficient flexibility that such blacklisting catches all archive urls regardless of timestamp). If there is a specific archive timestamp that can be shown to not be malicious, then an editor could possibly petition whomever does this sort of thing to white-list that particular archive. The question then becomes, how do we mark such white-listed archive urls?

For me, I understand unfit and usurped to mean that the url links to:

• unfit – link farm or advertising or phishing or porn or other generally inappropriate content
• usurped – new domain owner with legitimate content; original owner with legitimate content unrelated to the originally cited url's content

Yep, there is no bright line separating the two but, as can be seen from the original discussions of these parameter values, we struggled to get even these because the waters, they are muddy.

And I repeat myself yet again: if you can see how the documentation for these templates can be improved, please do so.

—Trappist the monk (talk) 14:34, 5 October 2019 (UTC)

lengthening bots .. what happens? - I believe there is a flag to exempt bot accounts from being blocked on save. I prefer to get blocked to manually fix. My bot also decodes encoded schemes in the path/query portion so the filters are not bypassed. IMO re whitelisting, it is often a matter of judgement/opinion and also double jeaporady since the original blacklisting presumably had a consensus discussion, it opens every blacklisted URL up to a new potential consensus discussion. This is a loophole for users to get past blacklists and overhead to manage. -- GreenC 22:10, 5 October 2019 (UTC)

usurped – new domain owner with legitimate content; original owner with legitimate content unrelated to the originally cited url's content

I assumed usurped to be closer to hijacked? If there is a new, properly registered owner (publisher) did any usurpation take place? 72.43.99.138 (talk) 15:42, 6 October 2019 (UTC)

When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.

I think that these definitions of usurped, unfit, and possibly other values of |url-status need solid, agreed-upon definitions. Just from the point of view of English usage, never mind specialized wiki vocabulary, usurped is much more like what IP 72 stated. The sense of a new domain owner with legit content is nothing like most native English speakers would imagine, I don't think, when seeing the word usurped.

To me, your definition is a bit more like what would apply to a word like, repurposed, or reassigned, or repositioned or perhaps some word from marketing vocab when one company buys another's superannuated property, if there is such a word. The term usurped does not seem appropriate for the meaning you assume for it. This all needs further airing out, before the spam blacklist wrinkle, which is an edge case of the broader problem, can even be discussed. I have a feeling that there may be a need for at least one, perhaps two more values for |url-status to cover the different meanings that we seem to be alluding to for it, and trying to cram into two few values. Mathglot (talk) 23:12, 9 October 2019 (UTC)

Just wanted to be clear about one point: I don't think we need new values, just for the sake of new values; there's not need to distinguish every possible thing that could happen with an url. But, when they should be handled differently by the software, then, yes: we do need values for those cases. When the confusion surrounding the current meanings of usurped and unfit are settled, I suspect we will find that we will need at least one more value, in order to assign it to different handling in the software, and I think the spam blacklist case may be one such example. Mathglot (talk) 23:19, 9 October 2019 (UTC)

If you don't like the definitions that I offered above, write better definitions. I did write above: ...as can be seen from the original discussions of these parameter values, we struggled to get even these... Yeah, we know that these parameter keywords are less than optimal so there is no real need to spend a lot of words telling us what we already know. Suggest better definitions and / or suggest better keywords.

—Trappist the monk (talk) 12:43, 10 October 2019 (UTC)

For domain names that are not trademarked, |url-status=reassigned would be imo a good option to clarify there is a new registrant. Obviously trademarked domains (like say, newyorktimes.com) would not normally lapse, so in these cases |url-status=usurped would be more accurate. 72.43.99.138 (talk) 13:55, 11 October 2019 (UTC)

I agree with 72.43.99.138. — UnladenSwallow (talk) 17:25, 11 October 2019 (UTC)

Italics of websites in citations and references – request for comment

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

An overall consensus exists here that names of websites in citations/references should be italicized, generally in line with current practices. Limited exceptions to italicizing were discussed by some, however no clear consensus emerged on this point. Steven Crossin ^{Help resolve disputes!} 15:49, 26 August 2019 (UTC)

Amended close - based on two different users approaching me regarding the wording of the RFC above, I am amending my close, and directing the users involved here to re-advertise the follow up question on scope.

I do continue to find, as per the wording of the RFC question, a consensus exists to italicize the names of websites in citations/references. However, based on a review of the discussion, the scope to which this consensus should be applied is unclear. While the discussion was advertised widely on many citation pages, and the wording of the question may seem to imply a site-wide change, the location of this discussion, and comments in this discussion, may seem to indicate this consensus should only apply to this template. For that reason, I'm holding a subsequent discussion for 30 days so the community can conclusively determine the breadth of the application of this discussion, as it could be cut both ways here. Steven Crossin ^{Help resolve disputes!} 13:18, 6 October 2019 (UTC)

Should the names of websites in citations and references always be italicized? Please respond beginning with: Italic or Upright. There is an additional section below for discussion and alternatives.

The text above, and the notifications and headings below were proposed on this page with this edit. SchreiberBike| ⌨  04:42, 18 May 2019 (UTC)

The following pages have been notified

• Help talk:Citation Style 2
• Template talk:Citation
• Wikipedia talk:Citing sources
• Wikipedia talk:Citation templates
• Wikipedia talk:Manual of Style
• Wikipedia:Village pump (policy)

Responses

• It depends Websites that are more functional and less creative like IMDB should not be italicized, while those that provide long form content of its own creativity should be. --Masem (t) 05:52, 18 May 2019 (UTC)

  This commentary on IMDB is annoying. There is significant creative effort (perhaps invisible) that goes into creating any website, much less one so large and developed as e.g. IMDB. Second, IMDB in specific has tons of user-generated content--that's why we don't treat it as a reliable source. Those people generating that content aren't contributing to some minor work. It is a major work they are contributing to. Major works get italics. Even a site like Metacritic still has a ton of work to have transcribed scores for works (magazines) that are not online. So the notion that e.g. Metacritic is also undeserving of being called a major work annoys me to no end. --Izno (talk) 07:09, 18 May 2019 (UTC)

  Sure, IMDB has effort behind it, but its not the type of "creative writing" effort that we normal see in books, magazines, newspapers and long-form websites. Its more a database first and foremost. And sure, maybe not the best example, but even with Metacritic, Rotten Tomatoes, etc. those still are database sites first and foremost and thus are treated without Italics. --Masem (t) 16:32, 18 May 2019 (UTC)

  Which is a completely arbitrary distinction. These are still websites, still created by some amount of creative effort. A designer or several took the time to make it look, feel, and read the way it does. That's something to italicize, because it's still a publication. "It depends" -> No, it basically doesn't. If you are citing it for the fact it has published something of interested, then it is de facto a publication and should accordingly be italicized (much as SMC says below). --Izno (talk) 18:27, 18 May 2019 (UTC)

  Fundamentally, someone still published the website. They put in the significant work to provide some information to the public. That e.g. Metacritic is a database does not mean there was no work done for it. The reason there are even database rights in e.g. the EU is because they recognize that the act of creating a database might have significant efforts associated with it. To go on and publish it? Yes, yes very much so it is a long work. --Izno (talk) 18:39, 18 May 2019 (UTC)

• Yes, always italicize. A) We have MOS guidance that indicates major works should be italiziced. Period and end of story. Arbitrary distinctions of "it functions as this in this context" simply aren't necessary, and are essentially sophistry where used. They add unnecessary complexity to our understanding of what it is that we are talking about when we're talking about a source. Where the MOS does not require items be italicized, we are free to do as we please, essentially, as this is a dedicated citation style on Wikipedia. B) It decreases the complexity of the templates. That's good for new and old hands alike. Further, we would have to hack around the arbitrary desires of some small subset of users to support non-italics. (Some of whom do so based on external style guidance. That is not our MOS. Our MOS about italics can be found at MOS:ITALICS.) Who really shouldn't care. The templates take care of the styling, and are otherwise a tool so that we don't need to care. The simpler we make them accordingly, the better. As long as it doesn't affect a great many sensibilities (and I've seen little evidence that it does, not having been reverted on many, if any pages, where I've converted publisher to work or website), then we should italicize. This is molehill making. -Izno (talk) 06:58, 18 May 2019 (UTC)
• No, only if the name of a film, newspaper, magazine, etc. normally italicized. Wikipedia itself is a website and, as a wiki, is not italicized. IMBD is a viewer-edited site and is not italicized. Etc. Randy Kryn (talk) 09:58, 18 May 2019 (UTC)

  If someone cited WP as a source (not on WP itself, obviously, per WP:CIRCULAR), then it should be italicized. How to cite the Manx cat article at another encyclopedia: "Manx Cat", Encyclopædia Britannica, [additional cite details]. How to cite the corresponding article here: "Manx Cat", Wikipedia, [addl. details]. What's happening here is confusion of citation style with other style, like how to refer to something in running text. As a wiki, a form of service and a user community, most other publications are apt to refer to Wikipedia without italics, because they're addressing it as a wiki (service/community), not as a publication. But even in running text it would be entirely proper to use italicized Wikipedia when treating it as a publication per se, e.g. in a piece comparing Wikipedia versus Encarta accuracy and depth of coverage about Africa, or whatever.  — SMcCandlish ☏ ¢ 😼  12:30, 18 May 2019 (UTC)

• I don't think there are necessity of italicizing. References and something like that, can be written by bold texts or adjusting size. There is another way to do that kind of activity.-Sungancho951025
• It depends. If the title can be found, word-for-word, on the web site (not necessarily in the HTML title attribute) then it should be italicized. If no suitable title can be found on the website and a description is used instead, the text in the title position should be upright, without quotes, and with no special typographic treatment; a case can be made for enclosing it in [square brackets]. Jc3s5h (talk) 11:39, 18 May 2019 (UTC)

  With no allowances for WP:COMMONNAME (policy)? - Paul^T+/_C 06:06, 19 May 2019 (UTC)

  Some purposes for providing a title are to allow a reader to search for the site in case of a dead link, and to confirm the reader has arrived at the correct site once a connection is made. If a description has to be used instead of an actual title, not putting the descriptive title in italics will put the reader on alert to not expect to find the exact text on the website. Jc3s5h (talk) 13:33, 19 May 2019 (UTC)

  I'm sorry. This is a hypothetical on a hypothetical that can lead to confusion for the main point of this RfC. Can you give a specific example of what you mean? I know wgbh.org (with |work= pointing to any of WGBH-TV/WGBH Educational Foundation/WGBH (FM), depending on the context of the citation) was used in the past, but I don't think that is exactly what you mean. - Paul^T+/_C 16:01, 19 May 2019 (UTC)

• Yes, italic, the same way we've always done it, for all actual website titles (which are sometimes, though increasingly rarely domain names in form), in citations. No sensible rationale has been provided for changing this. In short, continue to follow MOS:TITLES. This has nothing to do with whether it should be italicized in running prose; that depends on whether the site is primarily seen as a publication (Salon, TechCrunch, or something else, like a service, shop, forum, software distribution channel, or just a corporate info page. In a citation it is and only can be a publication, in that context. WP does not and cannot cite anything that is not a publication (a published source), though of course TV news programs and other A/V content count as publications in this sense; the medium is irrelevant. The citation templates automatically italicize the work title; always have, and should continue to do so (while sub-works, like articles, go in quotation marks, same as newspaper articles, etc.). If you cite, say, Facebook's usage policy in an article about Facebook-related controversies, you are citing |title=Terms of Service|work=Facebook, a published source (a publication); you are not citing a corporation (that's the |publisher=, but we would not add it in this case, as redundant; similarly we do just |work=The New York Times, not |work=The New York Times|publisher=The New York Times Company).

  None of this is news; we've been over this many, many times before. The only reason this keeps coming up is a handful of individuals don't want to italicize the titles of online publications simply because they're online publications. I have no idea where they get the idea that e-pubs are magically different; they are not. In Jc3s5h's scenario, of a site that is reliable enough to cite but somehow has no discernible title (did you look in the <title>...</title> in the page source? What do other sources call it?), the thing to do would be |work=[Descriptive text in square brackets]; not square-bracketing it (whether it were italicized or not) would be falsifying citation data by making up a fake title; any kind of editorial change or annotation of this sort needs to be clear that it's Wikipedia saying something about the source, not actual information from the source itself. Another approach is to not use a citation template at all, and do a manual citation that otherwise makes it clear you are not using an actual title.
   — SMcCandlish ☏ ¢ 😼  12:30, 18 May 2019 (UTC)

• What we're doing now is correct When citing a website as a work (e.g. |work=, |website=, |newspaper=, etc...), they are italicized . If they are cited as publishers (via |publisher=), they are not. This is how it is, and this is how it should be. Headbomb {t · c · p · b} 13:45, 18 May 2019 (UTC)

  To clarify, are you advocating ignoring do not abuse unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations from MOS:ITALICWEBCITE? (This is an honest question, reading your comment I can see multiple answers to it.) - Paul^T+/_C 06:06, 19 May 2019 (UTC)

  MOS:ITALICWEBCITE says: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." We don't have to make a black and white choice this RfC is presenting. |work= can be either italic or not, "depending on the type of site and what kind of content it features", per the MOS. -- GreenC 20:07, 21 May 2019 (UTC)

  That is refering to prose, not citations. Also, that quote is from further up in the MOS:ITALICTITLE section. MOS:ITALICWEBCITE is specifically the last part of that section dealing with citations. - Paul^T+/_C 15:16, 22 May 2019 (UTC)

• Sometimes The |work= field shows italic, the |publisher= doesn't and you choose which is the best option. SMcCandlish says this RfC is about a small minority of users who dislike italic website names; I have no idea. However I have seen other users say this is about something else, namely that when citing content using {{cite web}} one should always use |work= and never use |publisher=. They arguue everything with a URL on the Internet is a publication and therefore italic. But this argument neatly covers over a complex reality that exists, it is not always right to italicize. Users need flexibility to control who is being credited and how it renders on the page without being forced to always italicize everything and anything with a URL. -- GreenC 14:17, 18 May 2019 (UTC)
  • Almost always the name of the website is the name of the (immediate) publisher; for example, CNN (the website; alternatively CNN.com) has this at the bottom: (C) 2019 Cable News Network. Turner Broadcasting System, Inc. Now, you could make the choice to do Last, First (1 January 2001). "Title". CNN. or you can do Last, First (1 January 2001). "Title". CNN. CNN. or you can do Last, First (1 January 2001). "Title". CNN. TBS. The middle one duplicates information and is also how the vast majority of websites are provided. So that's why we say basically say never to use publisher. It is correct to say that everything on the internet is a publication (you use the "Publish" button to save things onwiki, right? It's a publication when you create a webpage and make it available to other people). Anyone arguing otherwise is clearly so far into edge case territory that they probably should not be using these templates for their citation(s)... --Izno (talk) 18:34, 18 May 2019 (UTC)

    The above is what I mean about a small number of users with a radical plan to eliminate usage of |publisher= when citing anything on the Internet, and always italicizing, be it WGBH-TV or IMDB. -- GreenC 00:26, 19 May 2019 (UTC)

    @GreenC: I'm not following your argument here. Izno doesn't here appear to be arguing against |publisher= as such; but rather is noting that in the typical case it will be redundant with the work (|website=). I am a firm proponent of providing publisher information (cf. the recent contentious RfC on that issue) and even I very much agree that writing, in effect, that CNN publishes CNN or that The New York Times is published by The New York Times Company is pretty pointless. And conversely, I notice some of the outspoken opponents of providing publisher information are in this RfC arguing in favour of the consistent use of italics for the work. I absolutely believe there are some cases where it would be correct to give |publisher= instead of |website= (and obviously there are many where giving both would be appropriate); but in terms of the question in this RfC, I think Izno is correct to dismiss those as edge cases that do not have a siignificant bearing on whether or not to italicize |website=/|work=/etc.

    But your original message caught my attention for a different reason: it implies that there is a need for local (per-article) judgement on italicizing or not the |work=/|website=/|newspaper=/etc. Are you saying there is a CITEVAR issue here? I am sympathetic to the view that stylistic consistency should not be attempted imposed through technical means (whether by bot or by template) if the style choice is at all controversial (in those cases, seek consistency through softer means, such as style guides). But I can't quite see that italization of the work in itself is in any way controversial, and this RfC doesn't affect the option to choose between |website=, |publisher=, or both in those cases when those are otherwise valid options (one can disagree on when exactly those are valid options; but for the sake of discussion let's stipulate that such instances do exist). I, personally, wouldn't have batted an eye if you cited something on cnn.com or nyt.com that was part of the corporate information (investor relations, say) rather than the news reporting as {{cite web|publisher=CNN|url=…}}. Others would disagree, of course, but that issue is not affected by whether or not |work= is italicized. --Xover (talk) 04:47, 19 May 2019 (UTC)

  • "The |work= field shows italic, the |publisher= doesn't and you choose which is the best option." No; read the templates' documentation, Help:CS1, and MOS:TITLES. The work title is required; the publisher name is optional, only added when not redundant, and rarely added at all for various publications types (e.g. newspapers and journals; most websites don't need it either since most of them have a company name almost the same as the website name). No one gets to omit |work= as some kind of "give me non-italicized electronic publications or give me death" WP:GAMING move.  — SMcCandlish ☏ ¢ 😼  05:08, 19 May 2019 (UTC)
• Italicize work/website when title is present, as we do now. As other people have already stated, this is not qualitatively different than a chapter in a book or an article in a journal or magazine, all of which follow the same convention of italicizing the larger collection that the title appears in. —David Eppstein (talk) 19:05, 18 May 2019 (UTC)
• Yes italics, no change from how we currently cite. Cavalryman V31 (talk) 21:01, 18 May 2019 (UTC).
• Italics (ideally using |<periodical>= in a citation template) are required when citing any published work, which, by definition, includes all websites. We have direct WP:MOST (a WP:MOS guideline) guidance on this topic at MOS:ITALICWEBCITE, which is directly backed up by three policies (WP:V, WP:NOR, and WP:NOT). Quoting from there:

When any website is cited as a source, it is necessarily being treated as a publication, and in that context takes italics. Our citation templates do this automatically; do not abuse unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations.

To be clear, this has nothing to do with how websites should be presented in prose and only refers to citations.

Also, there is clearly ambiguity on this point as evidenced by the range of opinions on this matter presented here, but the purpose of this RfC is to attempt to gain clear community consensus in support of our established guidelines and policies. Once gained, we can then clarify the instructions as much as possible so that this consensus is clearly communicated and easily accessible to all editors. The issue right now is that many, many people are (reasonably) misunderstanding the existing guidance on this point.

Up until a few weeks ago, I was included in the group of editors that was misunderstanding these guidelines. I urge everyone to read the above guideline carefully. Try to look at it without any existing bias and seriously consider changing your opinion (not an easy task, I know!) if there is a conflict with the above. Thanks, - Paul^T+/_C 22:19, 18 May 2019 (UTC)

• All of that text was added earlier this month with the stated aim of dissuading editors from de-italicising in cite template parameters. I can't see how it can now be cited as proof that the practice is disallowed, any more than if I or someone else had chosen to add guidelines supporting the practice (or went and added them now). Nor do I see that those policies directly support the idea at all. JG66 (talk) 23:21, 22 May 2019 (UTC)

  It isn't my responsibility to defend SMcCandlish's addition there (or to dispute your removal of it), but my interpretation of what he did with those edits was to bring the points into one place so as to clarify existing convention. I don't agree that this represents a change in the spirit of the MOS. - Paul^T+/_C 15:00, 23 May 2019 (UTC)

  Yep.  — SMcCandlish ☏ ¢ 😼  21:01, 25 May 2019 (UTC)

• Italics—but if the website lacks a name independent of its publisher, then there's no need to invent a name for a citation just to fill in that parameter of the citation template; the publisher in |publisher= will be sufficient. 22:41, 18 May 2019 (UTC) — Preceding unsigned comment added by Imzadi1979 (talk • contribs) 22:42, 18 May 2019 (UTC)

  Already covered this above, twice. Can you provide an example of an actual reliable-source website with no name?  — SMcCandlish ☏ ¢ 😼  05:13, 19 May 2019 (UTC)

• Per WP:CITESTYLE, "nearly any consistent [(i.e. internally within an article)] style may be used … [including] APA style, ASA style, MLA style, The Chicago Manual of Style, Author-date referencing, the Vancouver system and Bluebook." Unless we want to make an exception to that like we do for dates due to special circumstances, this is really a moot matter. If this discussion only regards how this specific template will render such things, then that needs to be made clear. — Godsy ^(TALK_CONT) 01:34, 19 May 2019 (UTC)

  This is at Help talk:Citation Style 1, so it's already clear what the scope is. If you're at an article is consistently using manual citations in some wacky style that, say, puts work titles in small-caps and italicizes author surnames (or whatever), then that same style would be applied in that article to electronic publications. (That said, any citation style that confusing is a prime candidate for a change-of-citation-style discussion on the article's talk page, per WP:CITEVAR).  — SMcCandlish ☏ ¢ 😼  05:13, 19 May 2019 (UTC)

• Italics, with some caveats. Websites are works, so should generally be italicised where there's an official website title. Where there isn't, or where an unofficial title is being used, they should not be italicised. Publishers of websites (eg the BBC) should never be italicised. All of this simply follows the general principles for all forms of citation, and I disagree that the question of whether there's significant creative input into the work is a factor. Espresso Addict (talk) 02:49, 20 May 2019 (UTC)

  You're almost there. To follow on your example, what is the name of the website BBC.co.uk? Isn't it "BBC" (or "BBC News", depending on the actual page) and therefore shouldn't citations from bbc.co.uk have italicized |work=[[BBC]] or |work=[[BBC News]], depending on context? - Paul^T+/_C 03:09, 20 May 2019 (UTC)

There isn't a single website name. www.bbc.co.uk has no obvious title; www.bbc.co.uk/news is BBC News; www.bbc.co.uk/sport is BBC Sport; and so on. The publisher is the BBC. Espresso Addict (talk) 04:31, 20 May 2019 (UTC)

Actually, in this example, there would be just one website, the one suffixed with the top-level domain. That is the work. Anything that comes after the slash is a "chapter" in that work, or a "department". If there is a prefix like news.bbc.co.uk (that is to say a subdomain), then that should be listed as the work, since such subdomains have their own hierarchy. I believe this treatment corresponds to both the technical and the functional aspects. 72.43.99.130 (talk) 13:40, 20 May 2019 (UTC)

• Italics, how we've always done it (or should have always done it). Kaldari (talk) 16:06, 20 May 2019 (UTC)
• It depends MOS:ITALICTITLE says that only websites with paper equivalents (The New York Times, Nature, etc) and "news sites with original content" should be italicized. Personally, however, I never italicize news websites that don't have paper equivalent or aren't e-magazines (BBC, CNN, etc). Brandmeister^talk 10:06, 21 May 2019 (UTC)

  That is true for mentions in the prose, but not for citations. MOS:ITALICTITLE also says (at MOS:ITALICWEBCITE) When any website is cited as a source, it is necessarily being treated as a publication, and in that context takes italics. (See above for the full quote and direct references to policies backing it up.) This is very clear guidance on the subject. - Paul^T+/_C 15:16, 22 May 2019 (UTC)

  Looks like it was removed as an undiscussed addition, also MOS:ITALICWEBCITE redirects to general Wikipedia:Manual of Style/Titles, not to specific section. That addition, if proposed, should gain consensus first. Anyway personally I don't see a compelling reason to format ref names differently compared to prose. Brandmeister^talk 22:04, 22 May 2019 (UTC)

  Yes, it was removed (see below), though I have a feeling the removal will also be disputed (hopefully it doesn't fork this discussion unnecessarily). The text is directly quoted above as well and it is directly supported by quotes from policies. References have different formatting from prose for all kinds of reasons. Our personal preferences aren't really supposed to enter into it when guidance is clear. - Paul^T+/_C 22:28, 22 May 2019 (UTC) Oh, and the shortcut currently points to the full WP:MOST page because the anchor was also removed. I'll have to think about whether it needs to be retargeted or not. Maybe here at #ITALICWEBCITE (at least while the discussion is ongoing)? - Paul^T+/_C 22:31, 22 May 2019 (UTC)

• It depends. Per comments above by Masem and Randy Kryn. As an article writer here, I'm looking to ensure there's consistency between what appears in the text and in a citation: I wouldn't italicise AllMusic, IMDb, Metacritic, Rock's Backpages, etc, in prose, so it seems fundamentally wrong to italicise those names when they appear in a source. And not that we would be citing it in many (any?) articles, but Wikipedia itself is a good example. JG66 (talk) 14:25, 21 May 2019 (UTC)

  This is directly contrary to MOS:ITALICWEBCITE (see directly above). Citations can be (and often are) formatted differently than running prose. - Paul^T+/_C 15:16, 22 May 2019 (UTC)

  It's only "directly contrary" to MOS:ITALICWEBCITE because SMcCandlish bloody added the text there on 2 May!! JG66 (talk) 15:28, 22 May 2019 (UTC)

  It is probably not a good idea to outright remove it while we are in the middle of this discussion. Any chance you'll self-revert? - Paul^T+/_C 21:12, 22 May 2019 (UTC)

  I'm afraid not, and I think it's not a good idea that the text was added there. After all, you're repeatedly citing it as an MOS guideline supported by policy, when in fact another editor has simply invented the guideline. JG66 (talk) 23:21, 22 May 2019 (UTC)

• Italics. For purposes of citation, it's a publication, even if it's online. Putting it in Roman instead would make the publication name blend into the other metadata elements, making it harder to read. —{{u|Goldenshimmer}} (they/their)｜😹｜✝️｜John 15:12｜☮️｜🍂｜T/C 18:09, 22 May 2019 (UTC)
• Leaning toward Italics: It should be as easy as possible to write citations, and people shouldn't be gaming the system with tricks for special font formatting or using |publisher= instead of |work= when they cite some websites (which can also cause metadata to be mixed up). If I find something on the CNN website, I should be able to just use "|website=[[CNN]]", and the same for citing the website for ABC News, BBC, NPR, PBS, WGN-TV, Associated Press, Reuters, Metacritic, Rotten Tomatoes, Box Office Mojo, Salon, Wired, HuffPost, The New York Times, etc. Writing citations should be dirt simple, and these sort of references are extremely common. If we don't do that, it seems difficult to figure out what rule we would follow instead. (e.g., if it seems like the name of an organization, don't italicize it, and if it is a content aggregator without original content, don't italicize it? – that seems unlikely to be advice that editors can consistently follow in practice.) —BarrelProof (talk) 05:21, 23 May 2019 (UTC)

  No one is gaming the system. Template:Cite web allows both work= and publisher= parameters, depending on source, and lists some websites (National Football League, International Narcotics Control Board, etc) in straight format, not italics. This is because CNN, International Narcotics Control Board or National Football League are not the same type of work as Encyclopedia of Things, Nature, etc. They are authority organs rather than paper publishers and this is consistent with MOS:ITALICTITLE. Brandmeister^talk 09:41, 23 May 2019 (UTC)

  Except that those "authority organs" publish a website. When a publication is cited, it is by definition a major work and therefore take italics per MOS:ITALICTITLE (and the policy cited in #ITALICWEBCITE, before it was removed). Using |publisher= instead of |work= when citing those publications just to change formatting conflates them and pollutes the usefulness of those separate fields. (Semi-off-topic question, is there a page where the metadata created by the citation templates is explained? Having that information explicitly spelled out somewhere might be useful to this discussion as well.) - Paul^T+/_C 10:33, 23 May 2019 (UTC)

  Per current guideline, only "online magazines, newspapers, and news sites with original content should generally be italicized". Websites in general are not listed among "Major works". Otherwise various organizations (UN, NBA, etc), referenced in corresponding official websites, would also be treated as "works", which is nonsensical. The change of that guideline part apparently begs for talkpage discussion, because it was reverted. Brandmeister^talk 11:51, 23 May 2019 (UTC)

  You are quoting a point that only applies to running prose. No one is disputing that (the bit about how the guideline applies to prose). Anything that is a published work, which includes every website, and is used as a citation, which requires complying with WP:V, WP:OR, and WP:NOT, qualifies as a "major work" and is therefore italicized per WP:MOST. You are conflating the "various organizations" with the websites they publish, which are published works when used in a citation as described earlier. - Paul^T+/_C 15:00, 23 May 2019 (UTC)

  WP:MOST makes no distinction between running prose and references for that matter (which is why |publisher= does not italicize by default, unlike |work= which does). Also, treating prose and refs differently may introduce WP:CREEP and is counter-intuitive. Italicizing all website names through default italicizing ref parameter may look like making things easier, but if it ain't broke, don't fix it. Brandmeister^talk 15:52, 23 May 2019 (UTC)

  (edit conflict)

  Module talk:Citation/CS1/COinS may be helpful. The table there is generally accurate but a bit out of date (newer preprint templates not mentioned, etc). For the purposes of cs1|2, {{citation}} when any of the |work= aliases have assigned values, {{cite journal}}, {{cite magazine}}, {{cite news}}, and {{cite web}}, Module:Citation/CS1 treats these as 'journal' objects. Pertinent to this discussion, |publisher= is not made part of the COinS metadata for journal objects. When editors write cs1|2 citations with 'website names' in |publisher= to avoid italics, those who consume the citations via the metadata do not get that important piece of information. This is a large part of the rationale for the pending change that requires periodical cs1 templates to have a value assigned to a |work alias= (see this discussion and the implementation examples).

  —Trappist the monk (talk) 11:57, 23 May 2019 (UTC)

  Thanks, this is helpful. I'll dig into it when I have some more time. - Paul^T+/_C 15:00, 23 May 2019 (UTC)

  My understanding is that the identification of the published work is considered more fundamental, at least for metadata purposes, than the name of the publisher of the work. The guidelines say that identifying the publisher is unnecessary if it is basically just redundant or obvious once the name of the work is known. This is completely straightforward when the work is The New York Times and the publisher is The New York Times Company. When publishers use their organization name as their website's name, it does seems a bit more awkward, but in my view, that what they have chosen to do – they chose what title to use for their published work, and we should just follow their choice. The CNN organization has chosen to entitle its website (i.e., its published work) as "CNN" (using italics here not because they do that, which they don't, but rather because that is how we ordinarily format the titles of works, and MOS:TM says not to imitate logo styling). I think it is too complicated to second-guess this choice they have made. If we want to cite their published work, and they have chosen the title "CNN" for their publication, we should just refer to their published work as "CNN". Otherwise, we would need to make some judgment call in every case between whether the name of the website seems more like the name of their publication or seems more like the name of their organization, and do something different in the two cases. I think that's too complicated. It would get even more complicated if we also start trying to do something different depending on whether they are publishing original content or not (e.g. Metacritic), and I don't even understand the rationale for not wanting to italicize some names – some of those sites are publishing original content, not just using what has already been published elsewhere. Anyhow, my understanding is that the intent of the parameter names is not primarily for font formatting. Choosing to fill in different parameters for font formatting purposes is what I referred to as "gaming the system", because I believe the parameter names were not really intended for that purpose. The parameter names are |work= and |publisher=, not |italicname= and |uprightname=. I suppose I might not object if someone wants the templates to support some additional parameter type like |uprightsitename=, but I think that's too complicated to expect it to be broadly understood and applied consistently. —BarrelProof (talk) 19:47, 23 May 2019 (UTC)

  I've noticed that when pointed to WP:MOST, italics supporters say it doesn't apply to refs, only to prose, but when this guideline suits their agenda, they say websites are "major works". Either one does not treat websites as "major works", because current WP:MOST does not apply to them (in which case they remain upright) or he/she respects current WP:MOST, which does not advise to italicize all websites. Seriously, double standards. Brandmeister^talk 07:05, 25 May 2019 (UTC)

• Italics per SMcCandlish, and as I'm not seeing any compelling reason to make such a tiresomely complicated yet small change throughout all our citations. — Bilorv (he/him) _(talk) 19:46, 24 May 2019 (UTC)
• Italics – I will never understand the distinction people try to make between online sources and print publications. Maybe that made sense in the 1990s but increasingly publications originate as web-only, or previously print publications cease printing and move to all-digital. I also fail to see the problem with italicizing a domain name if that's the best "title" for the publication. If a website includes the material you are citing, obviously it is serving as a publication and, as such, should be italicized. It also seems like it would circumvent a LOT of edit wars to simply declare all websites are "major works" and their names should be italicized as such in article prose, because the current weirdness of "well what kind of website is it?/what types of information does it contain/provide?" is such a stupid time sink. And that in turn would help avoid the whole "do we italicize website titles in citations?" debate, too. —Joeyconnick (talk) 20:04, 24 May 2019 (UTC)
• Italics: I think the names of websites should be italicized. Right now we are only talking about italicizing them in citations, but I think in the long run we will italicize them at all times. Like other things we italicize, they are named works with a publisher and subparts. This is not now common but such things move slowly and websites are relatively new. For now, I would favor italicizing the names of websites in citations/references and in external links. They are published sources.
  I'd be completely comfortable saying that the name of the website is CNN or CNN.com which is published by CNN. CNN is a company which has a TV channel, a network, a publisher and a website. It publishes a bunch of TV programs and films. It also publishes a website called CNN or CNN.com. When we cite something from that website it should be italicized. SchreiberBike | ⌨  23:50, 24 May 2019 (UTC)
• Italics. In CS1, sources such as websites are italicized, parts of sources such as webpages are quoted, and publishers such as domain owners are in plain text. This has been the consensus, and seems to be working well. 24.105.132.254 (talk) 16:42, 26 May 2019 (UTC)
• Generally italics, but it depends - per SMcCandlish, but there are times that italics aren't needed and shouldn't be required --DannyS712 (talk) 05:39, 27 May 2019 (UTC)
  • Per SMcCandlish? Can you double-check that? I believe SMcCandlish was italicize (always), not it depends. —BarrelProof (talk) 13:06, 27 May 2019 (UTC)
    • It depends in that some online entities are not italicized in running prose, being generally of the character of a service or some other non-publication, in typical-use context. If we cite them in a source/reference citation, however, we are only ever citing them as one kind of thing: a publication (a published source), so in a citation the italics belong there.  — SMcCandlish ☏ ¢ 😼  17:23, 12 June 2019 (UTC)
      • I thought it was implicitly understood that this was talking about what to do in citations. —BarrelProof (talk) 18:57, 12 June 2019 (UTC)
• Italics per SMcCandlish. Malcolmxl5 (talk) 06:33, 26 June 2019 (UTC)
• Italics When I cite something I read on https://www.nbc.com, I am not citing the network because the network is on television. Something I saw on television is not my source. I am citing the website which is a periodical and just so happens to share a name with the network. The publisher is "NBCUniversal". The "website=" is the proper parameter to use in this example. I don't see why non-periodical should be treated differently. They are a body of creative work and should be italicized similar to a book, a television series, or art. Misusing "publisher=" is not acceptable no matter how long that has been the status quo. Rotten Tomatoes is published by Fandango. AllMusic is published by RhythmOne. <publisher> is different from <work>.--- Coffeeandcrumbs 04:31, 28 June 2019 (UTC)

• I've only just been made aware of this RfC, so I'm afraid I'm weighing in late. No italics for non-periodicals When we cite The New York Times, we give The New York Times in the footnote, and not NYTimes.com. Because NYTimes.com is merely a delivery system. What we're citing is the news-gathering expertise of The New York Times. So likewise when we cite NBC News, the website NBC.com is just a delivery system. We're not citing the IT guys and website administrator — we're citing the professional journalists and editors of NBC News.

Same with institutions: The British Board of Film Classification is not a print/online book, magazine or newspaper. No one italicizes it or Dept. of Commerce or The Academy of Motion Picture Arts and Sciences. Why would we? And Rotten Tomatoes and Box Office Mojo are databases, not books or periodicals, and likewise are never italicized, by themselves or by their Wikipedia articles. What's the upside of Wikipedia using an eccentric style?

Modern Language Association (MLA) italicizes websites in footnotes. However, neither Associated Press (which eschews italics for quote marks) nor the Chicago Manual of Style (as explained here italicizes websites. (There are about 16 or 17 citation styles in more-or-less regular use, incidentally, if we really want to go through them all.) So it's not like there's any consensus in the broader world outside Wikipedia for italicizing websites. Differentiating between books / periodicals and organizations / institutions / databases is more in line with the real world and offers clarity and specificity, two things an encyclopedia at its best provides.--Tenebrae (talk) 05:13, 29 June 2019 (UTC)

• Italics. Maintain the present status quo and cleanup where needed. The italics debate goes way, way back, and there have always been some editors who have fought the trends. The debate has been reduced significantly over the last ten years, and Wikipedia (the project) and Wikipedia (the reference work) have been much improved for it. May the Bird of Paradise fly up the nose of those few editors who still can't or won't get with the program. Best to all! Paine Ellsworth, ed. ^put'r there  09:27, 29 June 2019 (UTC)

It would be more productive to actually address the point about why we don't cite "NYTimes.com:" than to engage in ad hominen attacks on those who disagree with you. As for "following trends", an encyclopedia does what's best for clarity and specificity, regardless of passing "trends".--Tenebrae (talk) 15:40, 29 June 2019 (UTC)

Hey, Tenebrae, been awhile. Good to talk with you again! As for what specific points to address, please see the opinion and other posts by SMcCandlish, as I agree with it on these issues. So if you must beat someone up about it, that's the editor to mangle, because it (SMcCandlish) is always throbbingly controversial. !>) By following trends, I did not mean "passing trends", but instead those lasting ones that ultimately resulted in how external resources and Wikipedia apply the use of italics in the present day. Paine Ellsworth, ed. ^put'r there  01:53, 30 June 2019 (UTC)

And I think it's you who needs to "get with the program". You've linked to an RfC on the use of italics in article titles, but the issue here is whether titles of sites that are not italicised in regular text should be italicised in citations. You appear to be a fan of italicisation for the sake of it. JG66 (talk) 16:25, 29 June 2019 (UTC)

I'm a little confused since I'm saying just the opposite, as a matter of fact. If we're citing a periodical or book, whether online or printed, yes, italicization is standard. But if we're citing a company, then no. The argument that we should cite NBC.com for an NBC News citation or NYTimes.com for a The New York Times citation seems eccentric and non-standard. --Tenebrae (talk) 00:02, 30 June 2019 (UTC)

You are misstating my point. The news website that belongs to NBCUniversal is not named NBC.com. It is called NBC News and is published by a division of the same name. I would never put a .anything outside the |URL= . Two entities that belong to the same company can share the same name. In this case, there are two entities of different types: a publication (NBC News) and a publisher (NBC News division of a parent company NBCUniversal). We disambiguate them by italics. Using the proper parameter also allows it to be machine-readable. --- Coffeeandcrumbs 09:13, 4 July 2019 (UTC)

@Tenebrae: Pretty sure that Editor JG66 was not replying to you (who did not link to an rfc) but to Editor Paine Ellsworth. I am removing the indent that you added with this edit.

—Trappist the monk (talk) 00:10, 30 June 2019 (UTC)

Tenebrae: Sorry, I could have made it clearer. It is as Trappist the monk says. JG66 (talk) 04:44, 30 June 2019 (UTC)

Thank you, JG66, for thoroughly misunderstanding what I wrote, although that's probably as much my fault as yours. I think I've been with the program for many years, as I've been involved in many italics discussions and have learned much about the changes over the years in external style guides as they pertained to the applications of italics. I've always sought to improve Wikipedia's italic stylings in line with those external resources. The link I gave was just an illustration, an example, a gentle reminder that before then and since, editors have worked hard to get the policy and guidelines updated to their present not-too-shabby condition where italics are concerned. As for being some kind of fan of italics just for the sake of it, I really could care less. My only concern is whether or not this encyclopedia is consistent with other reference works in its application of italics. Paine Ellsworth, ed. ^put'r there  01:42, 30 June 2019 (UTC)

Thanks for the shout-out, Paine Ellsworth. I've been away mostly since it's just these types of discussion that cause me to. As I'd mentioned, the widely used Chicago Manual of Style, for one, does not italicized websites, so this issue is not a question of Wikipedia being 'consistent with other reference works" — it is consistent with other reference works. Just not the one you prefer (MLA).

There is a valid, extremely useful distinction to be made between books / periodicals and institutions, companies and other organizations. I find the always-italics reductivism perplexing. By the arguments presented here ("I'm not citing NBC News but NBC.com), then virtually nothing would ever be non-italicized, since all companies have websites. By these arguments, we'd never cite the British Board of Film Classification but only bbfc.co.uk. We'd never cite Box Office Mojo but boxofficemojo.com. We'd never cite Johnson & Johnson but jnj.com. I think most people would find this eccentric and anti-intuitive. NBC News is not italicized, and placing it in a "website=" field that would italicize it and Dept. of Commerce and Johnson & Johnson, etc. goes against logic and common sense.--Tenebrae (talk) 12:51, 30 June 2019 (UTC)

That's more of a discussion of how to use the template. In those cases, you would use both website/work and publisher in the template. publisher=Johnson & Johnson |website=jnj.com. It would really be the same if they published a monthly journal of their own. publisher=Johnson & Johnson |work= JJ's Journal Alaney2k (talk) 14:04, 30 June 2019 (UTC)

jnj.com is not the name of the website; it is a shortened URL which a user can type into almost any browser address bar. The website has a name which happens to be the same as the name of the company that publishes it. So it would be |website=Johnson & Johnson |publisher=Johnson & Johnson. But in the same way we would not write |work=The New York Times |publisher=The New York Times Company, we would not list the Johnson & Johnson twice. Therefore, we arrive at simply |website=Johnson & Johnson. I will give you another example to demonstrate my point. NASA has many website including https://images.nasa.gov/. When citing this webiste as a source, I would not use |website=images.nasa.gov |publisher=NASA because the website has a name NASA Image and Video Library. This is a website and not a physical library. Several NASA centers contribute to it and is entirely contained online. Again here, the name of the publisher is superfluous so we also arrive at simply |website=NASA Image and Video Library. --- Coffeeandcrumbs 08:48, 4 July 2019 (UTC)

• Italics. While there are some inconsistencies with some common usage, I think most of the issue is the misuse of the template. We should be trying to use both work/website and publisher so that we are completely informative. Italicizing the work distinguishes the two nicely when reading. Alaney2k (talk) 14:04, 30 June 2019 (UTC)

I think when the citation already links to jnj.com that it's redundant to additionally say jnj.com. It addition to being redundant, this would simply add links to a commercial concern. What is the user-benefit of helping a company by adding twice as many links to it as the citation needs? --Tenebrae (talk) 14:58, 30 June 2019 (UTC)

Maybe it's important to know (for inexperienced editors) or at least gently remember (the rest of us) that using the markup for italics in the |website= parameter eliminates the italics in the end result. For example, when one uses |website=''jnj.com'' in the citation code, it comes out upright, as in:  jnj.com. So is the solution you seek 1) to eliminate the italics in the parameter or 2) to educate editors in its correct usage? Paine Ellsworth, ed. ^put'r there  17:10, 30 June 2019 (UTC)

I completely agree with you, Paine — I was, in fact, doing that for things like Rotten Tomatoes that are not italicized. But I believe I read somewhere in this discussion that such Wiki markup in templates adversely affects the metadata. If that's incorrect, then, yeah, I think we're reaching a middle ground.

Another possibility is to have a template called something like "Cite company" or "Cite organization", where NBC, Rotten Tomatoes etc. would not be italicized. But that's probably a separate discussion.--Tenebrae (talk) 22:14, 30 June 2019 (UTC)

• Italics per SMC. CThomas³ (talk) 05:08, 15 July 2019 (UTC)
• Italics Normally we use "publisher" for something like NASA. "website" is only ever used for a uri, e.g. |website=astrology.org.au If there is a publisher, website is not used; it is avoided whenever possible. "work" is never used for a newspaper; "newspaper" is always used instead 9and gives you italics), and we don't bother with publisher for newspapers, journals, magazines etc "work" is also generally avoided. However, for a TV site like CNN, we use publisher.|publisher=CNN Hawkeye7 (discuss) 06:41, 15 July 2019 (UTC)

  "website" is only ever used for a uri – this is simply not true; read the discussion above, especially the explanations by SMcCandlish. |website= is an alias of |work=, and should be used in the same way, as it is in citation-generating templates like {{GRIN}}, {{WCSP}}, etc. Peter coxhead (talk) 14:59, 15 July 2019 (UTC)

• Italics per SMC. I entirely agree that editors should not be "abus[ing] unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations" because I see it happen all too often, and I don't think this should have been removed from MOS:T either. I don't understand why some editors will go out of their way to avoid using a parameter that italicises something as if it's "wrong". Ss112 08:48, 21 July 2019 (UTC)

Well, because it indeed might be wrong. Rotten Tomatoes, for instance, is not italicized.--Tenebrae (talk) 00:18, 7 August 2019 (UTC)

Discussion and alternatives

• My impression is that much of the time when people list |website= in citations, they really mean |newspaper= (for newspapers that publish online copies of their stories), |magazine= (ditto), |publisher= (for the name of the company that owns the website rather than the name that company has given to that specific piece of the company's web sites), or even |via= (for sites like Legacy.com that copy obituaries or press releases from elsewhere). Newspaper and magazine names should be italicized; publisher names should not. Once we get past those imprecisions in citation, and use |website= only for the names of web sites that are not really something else, I think it will be of significantly less importance how we format those names. —David Eppstein (talk) 06:32, 18 May 2019 (UTC)

  I agree that people frequently use the wrong parameter and that this should be cleaned up, but it doesn't really address the root issue here. There's a tiny minority of editors engaged in kind of "style war" against italicizing the titles of online publications, and it's not going to stop until this or another RfC puts the matter to rest. There is nothing mystically special about an electronic publication that makes it not take italics for major works and quotation marks for minor works and sub-works, like every other form of publications, even TV series/episodes, music albums/song, and other A/V media.  — SMcCandlish ☏ ¢ 😼  12:30, 18 May 2019 (UTC)

  We might have common ground: I don't think any of us disagrees that books and periodicals, whether in print or online, should be italicized: Salon, Newsweek, etc. It's when the cite is to an organization like the British Board of Film Classification or NBC News or Rotten Tomatoes that are not books or periodicals, and are not normally italicized.--Tenebrae (talk) 22:19, 30 June 2019 (UTC)

  It's been a couple of days, and this seems the correct section, "Discussion and alternatives", to talk about middle ground. Paine Ellsworth suggested that for non-italicized companies and organizations, like NBC News and Rotten Tomatoes, that we simply do wiki-markup to de-italicize the website= field. Or, we could have an additional template called something like "Cite company" or "Cite organization", where NBC, Rotten Tomatoes etc. would not be italicized. Surely a workable, practical compromise can be reached, as is the goal of consensus. --Tenebrae (talk) 21:39, 3 July 2019 (UTC)

  Also — and as a journalist this strikes me as obvious, though it just occurred to me this might not be so to the general public — there is a critical distinction between publications (italicized), which fall under the rules of journalistic standards, practices and ethics, and companies and organizations like Sears or Rotten Tomatoes or Amtrak (not italicized), which are not obligated to follow journalistic standards, practices and ethics.--Tenebrae (talk) 19:49, 11 July 2019 (UTC)

  Sorry, but no. You think a reference to something published on the NBC News website should not use italics? How about The National Enquirer and The Daily Mirror and the Weekly World News? (Those publications don't seem to feel obliged to "follow journalistic standards, practices and ethics", so should we not use italics for those too?) Are you suggesting we use italics as an indicator of reliability? —BarrelProof (talk) 12:11, 14 July 2019 (UTC)

  You're making my point: There is no one-size-fits-all solution, because publishing, broadcasting and the web are, like humans, complex. Saying everything should be italicized is just such an impractical, one-size-fits-all solution.--Tenebrae (talk) 00:20, 7 August 2019 (UTC)

*Wait: An editor in this discussion unilaterally changed the MOS page to his preferred version after this discussion began? That editor, who unilaterally did this on 22 May, needs to restore the status quo to what it was as of 18 May when this discussion began. We don't just change MOS pages without consensus, and the fact we're discussing this shows there's no consensus. We don't just change the MOS, then come back to a discussion and say, "Well, look what the MOS says, I'm right!" Jesus Christ. --Tenebrae (talk) 13:48, 9 August 2019 (UTC)

• Instead of hyperbole, perhaps it would be a good thing for you to:

  1. identify the editor whom you accuse of this malfeasance
  2. identify which of the many MOS pages was modified
  3. link to the actual edit

  —Trappist the monk (talk) 14:18, 9 August 2019 (UTC)

  It already was identified: At least one other editor, JG66, noted this SMcCandlish edit here not long after it happened, and somehow the comment got buried and missed in this avalanche. JG66 even included the link to the actual edit, which is this one.

  Just want to note that hyperbole means "extreme exaggeration". Stating factually that an editor in this discussion unilaterally changed the MOS page to his preferred version after this discussion began is literally not hyperbole.--Tenebrae (talk) 17:03, 11 August 2019 (UTC)

  Editor SMcCandlish's edit to MOS:TITLE occurred on 2 May 2019. Isn't that 16ish days before the 18 May 2019 start-date of this RfC? Perhaps the claim that [an] editor [SMcCandlish] in this discussion unilaterally changed the MOS page to his preferred version after this discussion began (emphasis in original) is not correct?

  —Trappist the monk (talk) 22:08, 11 August 2019 (UTC)

  My apologies: Both the other editor and I must have scanned "2 May" as "22 May" in our minds. I've struck out my comments.

  That said, the 2 May edit still appears to have been done unilaterally without discussion. One editor "clarified" the MOS to his personal preference without talk-page consensus. That still is not right — and it remains a fact that italicizing EVERYTHING, even company names that are never italicized, is an extremist eccentricity not in mainstream footnoting.--Tenebrae (talk) 17:21, 21 August 2019 (UTC)

Closing

There have been no edits on this topic in the last ten days. Is there any objection if I refer this to Wikipedia:Administrators' noticeboard/Requests for closure? Thank you. SchreiberBike | ⌨  00:08, 7 June 2019 (UTC)

Are you in a hurry? If you force a conclusion to this rfc tomorrow, nothing would happen here because we is still have to conclude the pmc rfc. You might as well let this one run its full time.

—Trappist the monk (talk) 00:30, 7 June 2019 (UTC)

@Trappist the monk: Any objection to closing now? I'm not clear on why there is an advantage to wait until the pmc rfc is ready to close. Thanks, SchreiberBike | ⌨  22:37, 27 June 2019 (UTC)

I did not mean to imply that this rfc closure should wait until the pmc rfc is closed. I did not / do not see any need for an early closure. Now that the rfc has expired, of course it can be closed. Don't expired rfcs end up on some list somewhere to be formally closed?

—Trappist the monk (talk) 23:02, 27 June 2019 (UTC)

Close requested here. SchreiberBike | ⌨  02:52, 28 June 2019 (UTC)

That was a full month ago. Just adding a comment here to prevent auto-archiving. —BarrelProof (talk) 02:10, 3 August 2019 (UTC)

Another two weeks. Just adding another comment here to prevent auto-archiving. —BarrelProof (talk) 23:36, 19 August 2019 (UTC)

---

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

Follow up discussion - scope of application of italics in citations RFC

All, based on the last RFC where I determined a consensus (#Italics of websites in citations and references – request for comment), I am holding a subsequent discussion to definitively determine how widely this should be applied, whether to all citation templates or a more limited scope. Please provide your thoughts below. I will close this discussion after 30 days. Steven Crossin ^{Help resolve disputes!} 13:18, 6 October 2019 (UTC)

Note: This is not a discussion to re-debate whether italicisation should occur, as that was already determined in the previous discussion, but to determine where this should apply only. Steven Crossin ^{Help resolve disputes!} 19:40, 6 October 2019 (UTC)

The following pages have been notified:

• Help talk:Citation Style 2
• Template talk:Citation
• Wikipedia talk:Citing sources
• Wikipedia talk:Citation templates
• Wikipedia talk:Manual of Style
• Wikipedia:Village pump (policy)
• WP:CENT

—Trappist the monk (talk) 14:18, 6 October 2019 (UTC) (initial list) 11:32, 9 October 2019 (UTC) (+WP:CENT)

This RfC arises from this discussion at closer's talk page.

—Trappist the monk (talk) 14:30, 6 October 2019 (UTC)

Follow up responses

• clarification needed - I assume we are just talking about CS1 template here. If so, a lot depends on which citation style our CS1 template is based upon. Different styles present websites in different ways (some italicized, some not). So which style guide is the template based on? Blueboar (talk) 15:47, 6 October 2019 (UTC)

  @Blueboar: The exact question is whether the earlier discussion applied to all references to websites, whether it applied to something lesser (e.g. as used in CS1/2), or something even smaller than that. I find it hard to believe that it would be something lesser than CS1/2 based on the discussion and context, but someone may argue such. --Izno (talk) 18:11, 6 October 2019 (UTC)

• Italics in cs 1/2 templates - per the RFC discussion above. 72.43.99.138 (talk) 15:08, 6 October 2019 (UTC)
• {{Cite web}} only. The location of the discussion, Help:Citation Style 1, put editors on notice that the RFC only applied to that style. {{Cite web}} is the only template in that style I know of that calls for giving the title of the website as such. Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. Jc3s5h (talk) 15:13, 6 October 2019 (UTC)

  Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. This is a different discussion. Let's keep on topic. 72.43.99.138 (talk) 15:17, 6 October 2019 (UTC)

• CS 1/2 only, but only web site / work, not publisher. Some discussion since the first RFC has attempted to extend the italicization to publishers (that is, organizations, not collective groups of web pages) in the absence of a web site / work parameter, and that is incorrect. This should only apply to CS1 and CS2 per WP:CITEVAR. —David Eppstein (talk) 16:52, 6 October 2019 (UTC)

  I don't think I've seen anyone claim that |publisher= should italicize anything. --Izno (talk) 18:11, 6 October 2019 (UTC)

  No but some have argued that when a website has no title, the publisher's name should be used as |website= and be italicized, which is, indeed, italicizing the publisher's name. – Levivich 18:13, 6 October 2019 (UTC)

  Which is also a different discussion. --Izno (talk) 18:19, 6 October 2019 (UTC)

• Rerun this RFC from scratch – and this time advertise it on CENT. The proposal should be clear about what will change if it passes. So "Should websites always be italicized" isn't a great question. A better one would be, "Should we make change X to the MOS", or "Should we make change X to the citation template code", or something concrete like that. We need to differentiate between an MOS-style guideline directive, and a hard change to code. We also need to differentiate between work= and publisher= as discussed above. In my view, the scope of the existing RfC is nil because of the procedural flaws. – Levivich 17:48, 6 October 2019 (UTC)

  @Levivich: The original proposal was listed on CENT. Please don't make this about whether it was advertised; that was not the question asked. --Izno (talk) 18:08, 6 October 2019 (UTC)

  Where? I couldn't find it. – Levivich 18:12, 6 October 2019 (UTC)

  @Levivich: Review the link provided in my response. --Izno (talk) 18:14, 6 October 2019 (UTC)

  I didn't see it at first but now I see it. It should be advertised clearer on CENT. For example, the CENT advertisement was "Italics of websites in citations", and not the clearer, "Should website names always be italicized?" or the even clearer, "Should {{cite web}} always require a website name, which is always italicized?" – Levivich 18:16, 6 October 2019 (UTC)

  Not per the guidelines established on Template:Centralized discussion#Style. If you take a minute to review the history of that template, the intent is to be short and sweet. I used the title the discussion was started under (for better or worse). --Izno (talk) 18:19, 6 October 2019 (UTC)

  Added to WP:CENT

  —Trappist the monk (talk) 11:30, 9 October 2019 (UTC)

• CS1/2 templates only. I think that's obvious from the context in which the question was asked. Were it to have been asked elsewhere (say, WT:MOS or WT:CITE), it might reasonably have been interpreted to mean all citations/references, but here, I do not think that was the case. --Izno (talk) 18:14, 6 October 2019 (UTC)
• No, the titles of websites (if they have a title; most don't) should not be italicized. Where they lack a title, the URL should not be italicized. But whether or not website titles are italicized, in no circumstances should the publisher be used as the website title and italicized. That is, the title of https://www.supremecourt.gov/ is not "Supreme Court of the United States" or, even worse, Supreme Court of the United States. That site doesn't have a title. The website's publisher is the Supreme Court of the United States, and that should never be italicized. Ditto with World Health Organization, BBC News, CNN, etc.
  The Chicago Manual of Style says: "Titles of websites mentioned or cited in text or notes are normally set in roman [not italicized], headline-style, without quotation marks." Their examples include Project Gutenberg and Wikipedia. If the website has a printed counterpart, it is italicized along with the printed version, e.g. Encyclopaedia Britannica Online. Where websites have no formal title, use a short form of the URL, e.g. Apple.com, not italicized. See The Chicago Manual of Style, section 8.191, pp. 538–539. SarahSV ^(talk) 18:49, 6 October 2019 (UTC)

  Just a reminder, the purpose of this discussion is to decide how to apply the determined consensus in the previous RFC, not to debate the outcome. Steven Crossin ^{Help resolve disputes!} 19:44, 6 October 2019 (UTC)

  Steven, I wonder whether the previous RfC delivered a clear-enough consensus. We generally don't italicize websites. Wikipedia, for example, isn't italicized; nor are Facebook, Twitter, etc. Why italicize them only in citations? Our style choices should be consistent, at least within the same article. SarahSV ^(talk) 22:20, 6 October 2019 (UTC)

  I agree with Levivich that the RfC needs to be rerun. Wikipedia:Manual of Style/Titles does not support italicizing all websites: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." Online newspapers, for example, are italicized. Other types of site are not. It needs to be decided on a case-by-case basis, making sure that each article is internally consistent. It makes no sense to write "Wikipedia" without italics throughout an article, then force people to use italics in a citation, but only if a template is used. SarahSV ^(talk) 22:37, 6 October 2019 (UTC)

I agree that we shouldn't be challenging the previous outcome in this RfC, since it's not the question being asked. With that said, an important distinction getting missed is when a website is being cited as a publication for the material it supports; that's when italicization should be invoked (according to the outcome above). Simply stating "Wikipedia" or "Facebook" in running text to reference the company or entity they represent places the website name in a different context. And in regard to the Chicago MoS perpective, keep in mind that the MLA format does support italics in citations. The inconsistency you're pointing out already exists outside of Wikipedia. --GoneIn60 (talk) 06:44, 12 October 2019 (UTC)

• Rerun the RfC. CS1/2 templates. Specifically, |website= for all templates and |work= for the {{cite web}} template. So, for example, Apple is a company that publishes websites Apple (apple.com), Apple Support (support.apple.com), Apple Developer (styled  Developer ; developer.apple.com), etc. — UnladenSwallow (talk) 19:32, 6 October 2019 (UTC) Update: After thinking more about the problem, I agree with the other commenters that this RfC needs to be rerun. — UnladenSwallow (talk) 00:31, 7 October 2019 (UTC)
• Rerun RfC per Levivich. Failing that, the italicization requirement should apply only to |website= in CS1 templates, and that parameter should not be required. Nikkimaria (talk) 00:27, 7 October 2019 (UTC)
• Apply broadly: So, let's see if I am getting this wrong. 😜 You've asked people and they've told you. If the majority of the participants had a constraint in mind, they'd have told you. AFAIK the italicization helps identify the citation component, not the role and the object of the work. flowing dreams (talk page) 05:03, 7 October 2019 (UTC)

No, the reverse is true. Italicization in citations is semantic (Chicago, the city, vs. Chicago, the musical). It is not there to make a citation component stand out visually. — UnladenSwallow (talk) 09:01, 7 October 2019 (UTC)

LOL. I never said "to make a citation component stand out visually". I said "helps identify the citation component", which is a semantic role. You gave a very good example for it: "Chicago" is a publication location, "Chicago" is a published work. flowing dreams (talk page) 09:53, 7 October 2019 (UTC)

Oops. Sorry for misunderstanding you. I now get what you were saying: italicization is there to help us find the website title in a citation, not to tell us the type of the website (blog, web app, social media platform, etc.). — UnladenSwallow (talk) 20:30, 7 October 2019 (UTC)

• Apply to CS1 only: It just occurred to me that it is meaningless to conduct an RFC about the italicization of website names across several styles unless we know for sure that all those styles have vague italicization requirements. And there is no evidence to suggest that people interested in styles other than the citation style 1 have participated in the original RFC. flowing dreams (talk page) 09:40, 9 October 2019 (UTC)
• italicize |website= in CS1/2 templates – I did not participate in the original discussion, but I do follow this talk page, which is used for discussion of these templates. When someone proposes here that a certain kind of citation should look like X, or that a certain combination should be forbidden, they are understood to be talking about the behaviour of these templates. I understand that other pages are used for discussing the MOS, and no change to the wording of MOS was proposed here. Kanguole 08:45, 7 October 2019 (UTC)
• Rerun the RfC. Alternately, apply this only to the CS1/2 templates — While this was posted at CENT, such a major, major change to Wikipedia got only a couple dozen editors responding, if that. Discussions for adminship, for example, get five times as many editors commenting. Make no mistake, this is essentially a site-wide change: "Cite web" is being used more and more throughout Wikipedia since even editors adding magazine or newspaper citations often figure, "Well, it's on the web." That means the de faco Wikipedia house style italicizes company and institution names, which no mainstream footnoting format does. Without a corresponding "cite organization" template that does not automatically italicize company and institution names, italicizing websites in CS1/2 is essentially mandating an eccentric house style. That means a cite from the National Oceanic and Atmospheric Administration comes out as National Oceanic and Atmospheric Administration — misleadingly making it seem like a magazine such as National Geographic. I think something this big requires more input than the small number of editors at this relatively obscure technical page.--Tenebrae (talk) 16:06, 7 October 2019 (UTC)

  Exactly. The New York Times (www.nytimes.com) is an online news outlet and should be italicized. Google Docs (docs.google.com) is a web app and should not be italicized (apps are not italicized, as opposed to games). It follows that {{cite web}} must use manual italicization. I don't think it's such a big problem. The rules for applying italics can be put in the description of the website parameter. — UnladenSwallow (talk) 21:20, 7 October 2019 (UTC)

  IMHO, Google Docs must never appear in |website=. It belongs to |via=. Such is the case for GitHub: The repo name goees into |work=. flowing dreams (talk page) 11:55, 9 October 2019 (UTC)

Generally, yes. However, the web app name will be listed in |website= for pages like "About", "Help", "Subscription plans", etc. — UnladenSwallow (talk) 18:32, 9 October 2019 (UTC)

Oh, I see. In that case, your reference to Google Docs would be analogous to referring to an appliance's manual as opposed to referring to the appliance itself. In this case, the page to which you are linking is not an app, so, per your own criterion, definitely italize it.

But as I said, italicization has semantic meaning. This is important because |work=, |publisher= and lots of other parameters are optional. There is no telling if the citation has them. The italicization is your only clue. flowing dreams (talk page) 07:10, 10 October 2019 (UTC)

the page to which you are linking is not an app, so, per your own criterion, definitely italize it I never said app/not-an-app was my criterion. I simply offered two examples: an online news outlet (which are always italicized) and a non-game web app (which are never italicized). There are many other types of websites which may or may not be italicized. But that doesn't matter. What matters is that there are two types of websites that disagree on italicization. Therefore, we can't apply italicization automatically and must leave the decision to the template user.

You argue that Google Docs would never (or almost never) appear in |website=, so it's a bad example. Fine, let's take another example: Federal Reserve Economic Data (fred.stlouisfed.org). Certainly you would agree that it goes into |website= (and Federal Reserve Bank of St. Louis goes into |publisher=). And yet, it is always cited as FRED (no italics). There are many more examples like that. — UnladenSwallow (talk) 00:36, 11 October 2019 (UTC)

Humph. This is getting more and more complicated without any benefit. Nah. I'd say italicize all works, be it book, film, play, or app. flowing dreams (talk page) 06:54, 11 October 2019 (UTC)

This is not getting more and more complicated. I've provided you with two examples of websites: one that is italicized and one that is not. You've discarded the second example on the basis that it should always go into |publisher=, so I've replaced it with another example of a website that is not italicized.

So now we have The New York Times (www.nytimes.com) that is italicized and FRED (fred.stlouisfed.org) that is not italicized. This means that the decision on italicization should be left to the template user.

Nah. I'd say italicize all works… Wikipedia follows the existing norms as much as possible. If we wanted to keep things simple, we wouldn't have non-breaking spaces, en dashes, em dashes, etc. — UnladenSwallow (talk) 17:13, 11 October 2019 (UTC)

I said "complicated and without benefits". And you're not here to follow the existing norm; you're here to change existing norm on millions of articles. If Wikipedia wanted to follow existing norms, CS1 would have never been invented. By the way, you keep saing "FRED is not italicized". Not italicized by who? flowing dreams (talk page) 08:02, 12 October 2019 (UTC)

It's not italicized by any mainstream source whatsoever. Neither is Fannie Mae or Freddie Mac. As for "I'd say italicize all works" ... well, why? You're not giving any reason for having Wikipedia citations go outside the mainstream with some eccentric citation style used nowhere else. --Tenebrae (talk) 18:18, 27 October 2019 (UTC)

No, you didn't say "complicated and without benefits". You said This is getting more and more complicated without any benefit, which implies that "this" is: (1) getting more and more complicated; (2) does so without any benefit. I have addressed part (1), demonstrating to you that nothing is "getting more complicated"; in fact, the level of complexity is staying exactly the same as it was in my original comment: there are websites that are italicized and there are websites that are not italicized. you're not here to follow the existing norm I will decide for myself why I'm here, thank you. you keep saing "FRED is not italicized". Not italicized by who? Obviously, I'm referring to existing practice. As I've told you several comments back: "And yet, it is always cited as FRED (no italics)." Are you being intentionally obtuse? If you think I'm wrong, please demonstrate a variety of newspapers/magazines where FRED is cited as FRED (italicized). Except you can't. Because I've checked it thoroughly before posting my comment. You can continue to muddy the waters, or you can face the reality that in existing newspapers/magazines some types of websites are italicized (newspapers, journals, magazines, blogs, webcomics, etc.) and other types of websites are not (TV channels, radio stations, databases, company websites, etc.). See MOS:ITALICTITLE. — UnladenSwallow (talk) 05:53, 14 October 2019 (UTC)

Whoa! Whoa! Whoa! "Obtuse" is a personal attack. And "existing practices" is still a weasel word. FYI, not only I can face the reality, I can stare in said reality's eyes and tell it: "Hey, existing reality! I reject you, because you cannot justify your existence!" I've already done so to gender discrimination. If necessary, I'll do it to unhelpful italicization of components. flowing dreams (talk page) 07:37, 14 October 2019 (UTC)

• Steven Crossin, please offer an alternative title to this discussion so that it more accurately reflects citation practice. Citations do not italicize anything. They usually emphasize the most pertinent element, traditionally - though not exclusively - by using slanted type. Both the original RFC and this discussion keep applying the misnomer of "italics" which is solely a typographical convention and does not reflect the underlying semantic meaning. 24.105.132.254 (talk) 22:29, 7 October 2019 (UTC)

  "website=" in "cite web" automatically italicizes and does not allow manual override such as wiki markup. --Tenebrae (talk) 21:24, 8 October 2019 (UTC)

• Rerun the RfC and notify more widely. Template styles should follow the Wikipedia:Manual of Style/Titles which has a defined position on use of italics for websites (essentially being: it depends). If an overall change of style is being considered then it should be considered in that forum rather than for a specific template that users would naturally expect to follow the conventions defined in the Manual of Style. 203.10.55.11 (talk) 02:34, 11 October 2019 (UTC)
• Rerun the RfC. You can't just overturn Wikipedia:Manual of Style/Titles without even advertising the RfC there. Kaldari (talk) 23:22, 11 October 2019 (UTC)
  • The RfC didn't "overturn" anything. The wording on this particular thing at MOS:TITLES has just been confused and unclear for a long time (until MOS:ITALICTITLE); to the extent that the depending-upon-publication-type stuff could be interpreted as applying to citations (rather than use in running prose), it would not actually reflect WP practice, which has been to italicize these work names in citations, automatically, for 10+ years now.  — AReaderOutThataway ^t/_c 22:36, 20 October 2019 (UTC)
• Preferably rerun the RFC; at the very most, current consensus only allows for italics in cs 1/2 templates. Notwithstanding Steven Crossin's (understandable) request that the focus here be kept on-point, the fact remains that many editors are strongly opposed to italicising each and every website title, and/or that publisher= cannot be used instead to avoid italicising organisations in cite web. It seems to me it's a case of template managers/editors seeking to squeeze different scenarios into one tidy category – whether that's through obsessiveness or a touch of control-freakery I don't know. But, as was raised in the RfC, and has been added to or alluded to here by the likes of David Eppstein, Levivich and SarahSV, it's not a case of one-size-fits-all. I'm a professional book editor, and have been for far too many years, and the idea that an organisation has to be treated as a "work" in the interest of defining a component of the citation is, well, utterly ridiculous. AllMusic, Official Charts Company, Metacritic, Supreme Court of the United States, World Health Organization, BBC News, etc, are never italicised in regular text and need not be in a citation. (No reader's going to go: "Aaargh, you've lost me ... how do the words 'BBC News' relate to the rest of the information in that source?")

To return to the question raised here: CS1/2 currently prohibits adhering to a pretty fundamental point in British English style, which is that abbreviations such as eds, nos and vols don't require a full stop/period. In the past – I think it was with regard to the "eds" issue, if not the option to use "edn" for "edition" (which, I'd say, is also preferred in Brit English) – the response here was that editors are "welcome" to write the entire citation manually and so avoid having to conform to what they consider to be a contentious CS1/2 requirement. In the same spirit, and given the scope of the RfC anyway, editors should not be required to apply italicisation outside of CS1/2 and should be able to write the cite manually or find another way that presents the information correctly. JG66 (talk) 02:42, 17 October 2019 (UTC)

• Italicize in citations (and there is no difference in this regard between CS1 and CS2, or manually-laid-out citations). Whether to italicize in running text or not depends on whether the site is primarily like a published work (e.g. Salon or IMDb) or primarily something else (just advertising/support material like Microsoft.com, or a forum/social-networking service like Facebook). The "Rerun the RfC" stuff is patent WP:FORUMSHOPPING, an "I didn't get the result I wanted" complaint. The original RfC was widely enough advertised and ran long enough to assess consensus, and given that italicizing these in citations is already enforced by the templates and has been that way for over a decade, the "don't italicize" stuff is not a question about what consensus is, but an attempt to overturn already well-established consensus (an attempt that has failed numerous times, not just above).  — AReaderOutThataway ^t/_c 22:23, 20 October 2019 (UTC); rev'd. 06:29, 22 October 2019 (UTC)
• Italicize in CS1|2—the original forum for the RfC was on the talk page for the CS1|2 templates. As such, it should be a clear principle that the results of the RfC would be confined to those templates. There is no need to rerun the RfC. Imzadi 1979 → 15:45, 22 October 2019 (UTC)

Follow up discussion

• Comment Do you think there is any mileage in scrapping the "Cite web" template altogether, and creating a "Cite organization" in its place that does not italicise? The citation style is drawn from real-world application (i.e. the website name for a newspaper would be italicised, but for an organization it would not be) so Cite web seems to be encouraging standardisation where it does not exist. If you had to choose between Cite news, Cite book, Cite journal, Cite organization etc then the stylisation issue would take care itself. This would seem to be a fairly straightforward solution so what am I missing? Betty Logan (talk) 18:18, 10 October 2019 (UTC)

I think you may be confusing prose style with citation style. Because both are styles does not mean they have the same functionality. Citations style their content towards verifiability. One way this is accomplished is by emphasizing the source, in this case, the website, so that the reader knows immediately where to start looking. It has nothing to do with application of a prose style, neither does it have to follow the referring document's style whether that is MOS or anything else. And don't overlook the fact that use of these templates (actually, the module they are based upon) is entirely voluntary. Any citation/citation style will do, as long as is consistent within the document. 65.88.88.69 (talk) 21:03, 10 October 2019 (UTC)

I am not confusing prose and citation style. I have never italicised a company/corporation name in a citation in my professional work either. For example, if you are citing something on the BBC's website you do not italicise the "BBC" in the citation. The BBC's website is not a publication called the "BBC", it is a publication by the BBC. This is generally the norm for websites. I can think of several counter-examples: if you were citing something in the AFI Catalog you would italicise the "AFI Catalog" in the citation because it is a publication by the American Film Institute. In this capacity it functions as an online encylopedia/ebook and could be cited using an appropriate template. In the case of citing something on the AFI's general website it would be beneficial to have a "corporation" template that does not italicise the company name. The "cite web" template is promoting a standardisation where one does not really exist. Betty Logan (talk) 00:56, 11 October 2019 (UTC)

The template has a |publisher= field. That is where the publishing entity (in most cases the domain owner/registrant) should be inserted. The BBC publishes bbc.com. The latter would be the source. Sources (works) should stand out, one of the reasons being that they may include a lot of other stuff, most of it mysterious to the average Wikipedia reader. The emphasis applied on the source field through italics has nothing to do with whether the source is a website or anything else. 72.43.99.138 (talk) 14:05, 11 October 2019 (UTC)

Respectfully, there has just been an RFC that was in favor of italicizing. In that light of that RFC, this suggestion lacks pertinence. Clearly, the community sees value in distinguishing the name of the work from the name of the subwork and the publisher. If I may add, re-running the RFC reminds me of some of questionable political actions I hear about these days: The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again. flowing dreams (talk page) 11:45, 12 October 2019 (UTC)

RFCs are WP:NOTAVOTE, they are a tool for determining community opinion. Consensus on Wikipedia has never locked in a vote, chiefly because as the participants in a debate change so can opinion. Betty Logan (talk) 09:17, 14 October 2019 (UTC)

That's not what I see. RFCs are based on majority votes. In Wikipedia, minority valid concerns are ignored. In consensus-based decision making, all valid concerns are addressed. flowing dreams (talk page) 09:27, 14 October 2019 (UTC)

See WP:WHATISCONSENSUS#Not a majority vote, WP:NOTDEMOCRACY and Wikipedia:Consensus#Consensus can change (the latter two are both policies). Betty Logan (talk) 09:36, 14 October 2019 (UTC)

And here is my contribution to the consensus-building process: No! Your suggestion is egregious and without benefits, both in its own rights and in the fact that discrimination in italicization is egregious and without benefits. First, because you are operating under the wrong impression that the only websites besides news websites are organizations' websites. Not so. Second, you don't seem to have a functional reason for not italicizing certain websites. In fact, no one here seems to have. Any "reason" I see here is very arbitrary. flowing dreams (talk page) 10:13, 14 October 2019 (UTC)

Betty Logan is absolutely correct in that RfCs are not decided on by number of votes. That's not her "suggestion" but Wikipedia policy. You are completely wrong, per policy, in saying, "In Wikipedia, minority valid concerns are ignored."

As for your other points, you seem to be ignoring multiple editors in both this discussion and the closed RfC saying flat out that the names of organizations (companies, institutions) are not italicized in any mainstream footnoting style — for the very good reason of not conflating them with magazines and other periodicals. The National Oceanic and Atmospheric Administration is not National Oceanic and Atmospheric Administration, as if it were National Geographic. Having Wikipedia adopt a fringe, eccentric footnoting style makes us look like an outlier and does nothing to enhance our credibility. --Tenebrae (talk) 16:01, 15 October 2019 (UTC)

My dear esteemed colleague Tenebrae, you are being awfully forceful here. And I fear we have digressed from the discussion of a proposal for "Cite organization". I do accept that it is partly my fault. (Actually, I have nothing else to add to it, so I can bow out.) I'd be glad to have you and dear Betty in my personal talk page to talk about merits of italicizing in citations or about the de jour and de facto status of Wikipedia's consensus policy. But this thread is already a hot zone. Let's keep other hot topic out of it. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)

And incidentally, I find it odious that you compare this valid, by-the-book discussion as somehow illegitimate in the same way Trumpers try to deny the constitutionality of the impeachment process or recounts. ("The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again.") That Trumpian position holds no water in either the political world or in a Wikipedia discussion. --Tenebrae (talk) 16:05, 15 October 2019 (UTC)

You seem to be commenting about one of those nations/states who have voided their election when it did not go according to the plan. (I'd probably look up Trumpian later.) In the meantime, we can focus on the fact that I don't see why Steven Crossin suddenly decided to void the RFC, without drawing any anologies to real-world politic situations. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)

Re: "Do you think there is any mileage in scrapping the "Cite web" template altogether, and creating a "Cite organization" in its place that does not italicise?" – Absolutely not. It is not possible to cite "an organization" (or individual) on Wikipedia, only a published work. See MOS:ITALICWEBCITE and all the policy it cites on this matter (or see it here if someone's been editwarring against it again). 06:38, 22 October 2019 (UTC) — Preceding unsigned comment added by AReaderOutThataway (talk • contribs) 06:38, 2019 October 22 (UTC)

That guideline did not exist 6 months ago and is indirect contravention of WP:CITESTYLE, so I certainly won't be observing it. Betty Logan (talk) 22:03, 22 October 2019 (UTC)

Contrary to User:AReaderOutThataway's claim, I can find nothing in MOS:ITALICWEBCITE that says we italicize the names of organizations such as companies and institutions in citations. Nothing.--Tenebrae (talk) 18:28, 27 October 2019 (UTC)

I didn't suggest you would (cf. straw man). Read it again, please. You can't cite "an organization". You have to cite something published. If that's a major work (not a minor one like just an article), it's italicized per MOS:TITLES, and the templates do this automagically. The organization itself goes in the |publisher= parameter, which does not italicize. No one here is confused by that, surely not you either, so trying to make it seem like I'm suggesting italicizing organization names is disingenuous.  — AReaderOutThataway ^t/_c 20:27, 29 October 2019 (UTC)

Of course we can cite "an organization." It's done all the time hundreds of thousands of citations around the world: Doe, Jane. "Report on Apollo 11 [link]". NASA. Accessed Jan. 1, 2010. In no real-world scenario would "NASA" be italicized.--Tenebrae (talk) 21:34, 30 October 2019 (UTC)

This should be done the other way around. Don't require the use of |work= (or |website=, |newspaper=, etc.) in {{cite web}} if |publisher= is present, but create a new template, {{cite periodical}}, that does require a periodical parameter. --Ahecht (TALK
PAGE) 19:56, 28 October 2019 (UTC)

I think a "Cite organization" template is an excellent idea. As you say, it's drawn from real-world application, whereas Cite web seeks to impose "standardisation where it does not exist" (or, imo, standardisation for the sake of it). JG66 (talk) 01:04, 31 October 2019 (UTC)

I'm baffled by the failure to distinguish between |work= and |publisher= in the discussion above. Since I prefer CS2 style, if I were free to choose the citation style in an article, I would set up Tenebrae's example as:

{{citation |last=Doe |first=Jane |title=Report on Apollo 11 |publisher=NASA}} → Doe, Jane, Report on Apollo 11, NASA

This implies that the report is a stand-alone document. It is clearly different from something like the following, where the report is one of a set of components of a website.

{{citation |last=Doe |first=Jane |title=Report on Apollo 11 |work=NASA News |publisher=NASA}} → Doe, Jane, "Report on Apollo 11", NASA News, NASA

Organizations are publishers, and as such are clearly not italicized. Organizations' websites are works, and so should be italicized. Peter coxhead (talk) 10:22, 2 February 2020 (UTC)

In the case of stand-alone reports being hosted on an organization's website, say a report that was also published and made available on paper, I just use {{cite book}} and include the courtesy link to the online copy for CS1 citations:

Doe, Jane. Report on Apollo 11. NASA. Retrieved February 2, 2020.

Imzadi 1979 → 19:51, 2 February 2020 (UTC)

If you use {{Citation}}, you don't need to choose "book" or "web", which is irrelevant. The use of the different "cite" templates diverts attention from the semantics of the parameters, in my view.

{{citation |mode=cs1 |last=Doe |first=Jane |title=Report on Apollo 11 |publisher=NASA |url = http://www.example.com/ |access-date = February 2, 2020 }} → Doe, Jane. Report on Apollo 11. NASA. Retrieved February 2, 2020.

Peter coxhead (talk) 20:42, 2 February 2020 (UTC)

That's an excellent suggestion, Peter coxhead. Using Template:Citation avoids the mandatory italicization that, per the note below, should never have been made mandatory in "Cite web". I think your refreshingly simple solution is a great course until the issue below can be addressed. --Tenebrae (talk) 22:27, 3 February 2020 (UTC)

If you do use {{citation}} (a CS2 template) in an article that uses CS1 templates like {{cite web}} and {{cite book}} as the consensus citation style, please make sure to include |mode=cs1 in the {{citation}} template, as illustrated above, in order to keep the article's citation style consistent. – Jonesey95 (talk) 23:52, 3 February 2020 (UTC)

Important note

I wish I had seen this at WP:Consensus#Determining consensus earlier, since it makes this entire discussion moot: "WikiProject advice pages, how-to (emphasis added) and information pages, and template documentation pages (emphasis added) have not formally been approved by the community through the policy and guideline proposal process, thus have no more status than an essay."

That means there is no community consensus that website names should be italicized, and the coder who made that field's italicization mandatory did so without consensus. That mandatory italicization needs to be rescinded. If the coder chooses not to do so, then this issue needs to be addressed at a policy / guideline forum or at the Admin Noticeboard. The guideline page Wikipedia:Citing sources does not make it mandatory, nor does the guideline page Wikipedia:Manual of Style. --Tenebrae (talk) 20:26, 1 February 2020 (UTC)

I am about || this far from reporting you for refusing to drop the stick. --Izno (talk) 21:06, 1 February 2020 (UTC)

I find it remarkable that an admin, because he personally disagrees with an opinion in a re-opened RfC that is still open for comments, would make a threat such as that. You have the right to disagree, but to threaten a fellow editor for saying we need to follow WP:Consensus is wrong. And I'm unclear as to how I'm "wielding a stick" when you made multiple, multiple comments on this topic beginning 07:09, 18 May 2019. Disagreeing with another editor is no reason to threaten them.--Tenebrae (talk) 21:24, 1 February 2020 (UTC)

No, my issue is that you decided to forum shop this issue elsewhere, and have elsewhere decided to harass an editor directly, when you don't have consensus for your position, and moreover seem to misinterpret WP:Consensus to somehow mean that the template is acting inappropriate when there have been multiple RFCs on the point as if that doesn't create consensus for some position or another (regardless of where those RFCs have been held). None of those behaviors are appropriate. You're acting obsessive about this topic, and that's not okay. --Izno (talk) 21:32, 1 February 2020 (UTC)

Let's please take the temperature down a notch. I have not forum-shopped; as I explained to you here, I have followed all rules to the letter. Second, I'm not interpreting WP:Consensus — I quoted it directly. There has been no RfC on any policy/guideline page to make a major, site-wide change to Wikipedia. Third, I have not harassed anyone; if you're talking about my question here, I think you can see or anyone else can see it was worded extremely politely — and since that editor hasn't responded and apparently hasn't even been on Wikipedia in days, it sounds almost as if you're wikistalking me. I understand we disagree. I respect your right to do that. I believe we should confine our discussion to the issue and not make personal threats. I would like to calmly discuss. --Tenebrae (talk) 21:45, 1 February 2020 (UTC)

DOI prefix errors

A quarry query reveals a few things. Namely

• Citations with DOI prefixes that have 10.#, where # is not 4 or 5 digits should be reported as errors.
• Citations with DOI prefixes that range from 10.0001 to 10.0999 should be reported as errors.
• Citations with DOI prefixes that range from 10.00001 to 10.09999 should be reported as errors.
• Citations with DOI prefixes that are over 10.40000 should be reported as errors.

Headbomb {t · c · p · b} 18:03, 29 December 2019 (UTC)

This is about the registrant code portion of a doi. If I understand §2.2.2 DOI prefix, nothing constrains the composition of doi prefix registrant codes. Have doi.org published someplace, anyplace, a list of valid registrant codes?

—Trappist the monk (talk) 18:43, 29 December 2019 (UTC);;

Technically, nothing restraints that. In practice, those have never been assigned. Theses checks should also be implemented in {{doi}}, with a error 'invalid registrant' or shove em in the existing categories of invalid dois. And DOI.org have never published a list of registrant, sadly. I've been in contact with them about it, and they leave that to DOI assigning agencies like CrossRef and Datacite. Headbomb {t · c · p · b} 20:37, 29 December 2019 (UTC)

~/Identifiers/sandbox tweaked. All of these emit the doi error message except the first four:

• "Title". Journal. doi:10.1000.10/somat. – prove that four-digit registrant code with sub code is accepted
• "Title". Journal. doi:10.1000/somat. – prove that four-digit registrant code is accepted
• "Title". Journal. doi:10.10000.10/somat. – prove that five-digit registrant code with sub code is accepted
• "Title". Journal. doi:10.10000/somat. – prove that five-digit registrant code is accepted
• "Title". Journal. doi:11.1000/somat. {{cite journal}}: Check |doi= value (help) – invalid directory
• "Title". Journal. doi:10.1000/somat. {{cite journal}}: Check |doi= value (help) – terminal punctuation
• "Title". Journal. doi:10.123.10/somat. – three-digit registrant with subcode
• "Title". Journal. doi:10.123/somat. {{cite journal}}: Check |doi= value (help) – three-digit registrant
• "Title". Journal. doi:10.0123.10/somat. {{cite journal}}: Check |doi= value (help) – four digit leading zero with subcode
• "Title". Journal. doi:10.0123/somat. {{cite journal}}: Check |doi= value (help) – four digit leading zero
• "Title". Journal. doi:10.01000.10/somat. {{cite journal}}: Check |doi= value (help) – five digit leading zero with subcode
• "Title". Journal. doi:10.01000/somat. {{cite journal}}: Check |doi= value (help) – five digit leading zero
• "Title". Journal. doi:10.40000.10/somat. {{cite journal}}: Check |doi= value (help) – five digit does not begin with 1, 2, or 3; is there a 40000 registrant?
• "Title". Journal. doi:10.50000/somat. – five digit does not begin with 1, 2, or 3
• "Title". Journal. doi:10.100056/somat. {{cite journal}}: Check |doi= value (help) – six+ digit registrant
• "Title". Journal. doi:10.5555/somat. {{cite journal}}: Check |doi= value (help) – test registrant

—Trappist the monk (talk) 16:55, 30 December 2019 (UTC)

Highest legit registrant I was able to find was 10.36931 [1]. I don't know how high they go, but none have crossed 10.40000 yet. Headbomb {t · c · p · b} 17:00, 30 December 2019 (UTC)

"Test to see that we haven't impacted something on the other side of the slash". Journal. doi:10.3109/15563650.2010.492350. --Izno (talk) 17:58, 30 December 2019 (UTC)

@Trappist the monk: seems I've overlooked a special case: {{doi}} is a legit DOI apparently. So 3 digits after 10. in the doi prefix structure 10.d.d, but not in 10.d. Headbomb {t · c · p · b} 14:17, 11 January 2020 (UTC)

Yeah, I saw that:

{{cite book |last=Metzinger |first=Thomas |year=2013 |title=Spirituality and Intellectual Honesty: An Essay |publisher=Self-Published |isbn=978-3-00-041539-5 |doi=10.978.300/0415395}}

Metzinger, Thomas (2013). Spirituality and Intellectual Honesty: An Essay. Self-Published. doi:10.978.300/0415395. ISBN 978-3-00-041539-5.

I'm not clear about what you mean by 10.d.d, but not in 10.d is each d three digits so, as regex, 10\.\d\d\d\.\d\d\d, but not in 10\.\d\d\d?

—Trappist the monk (talk) 14:23, 11 January 2020 (UTC)

@Headbomb: Because of this pending update, if you can clarify the question above before I make the update, any necessary fixes can be applied at the same time.

—Trappist the monk (talk) 17:27, 13 January 2020 (UTC)

I just mean that dois should start with 10.#/... or 10.#/... with the restrictions that # is 4 or 5 digits, ranging from 1000 to 40000. And if you have a 10.#.#/... then it seems those restrictions don't apply, or that 978 is a special case. Headbomb {t · c · p · b} 17:37, 13 January 2020 (UTC)

Module:Citation/CS1/Identifiers function doi() updated.

—Trappist the monk (talk) 14:33, 18 January 2020 (UTC)

Automatic link suppression not working with title-link

Hi, I encountered a small glitch using {{cite web}}{{cite book}}:

Using one of the |author-link= etc. parameters, the link will be automatically suppressed when the citation is used on the page linked to by |author-link=. This is convenient when copying citations between articles, and also helps maintenance when articles get renamed.

I thought the same feature would be available for |title-link=, but it isn't. If this is used on the target page, the link isn't suppressed and consequently is shown in boldface, which looks odd. I think we should add the same auto-suppression to |title-link= as well.

There is a related feature which would be neat to have: If one of the |*-link= parameters points to a redirect rather than an article, it should be followed and the link should be suppressed if the template happens to be invoked from the redirect's target page as well. This would not only help keeping the link suppression feature work when renaming pages, but also would allow to deliberately go through redirects in order to reduce future maintenance.

It would be great if this could be fixed and implemented. --Matthiaspaul (talk) 01:40, 10 January 2020 (UTC)

Umm, {{cite web}} doesn't support|title-link=:

{{cite web |title=Example |url=//example.com |title-link=Example |website=Example}}

"Example". Example. {{cite web}}: URL–wikilink conflict (help)

Still, for templates that do support |title-link= and do not also have a conflicting |url=, we should probably mute the self-link. I'll attend to that after the pending update.

I do not think that we will follow redirects. To do that, it is necessary to fetch information about the target page from the database; that is an expensive operation when the target page is not the current page.

—Trappist the monk (talk) 12:23, 10 January 2020 (UTC)

That's right, I encountered this using {{cite book}} rather than {{cite web}}. Thanks for correcting me.

I think this "self-link muting feature" should be a general property of all |*-link= parameters everywhere. It seems to work for the family of |author*=, |editor*=, |translator*= and |contributor*= parameters (but I haven't tried all variants), that's why I thought it would be something generic already, but apparently it is not. Are there other parameters for which a |*-link= parameter exists?

Yeah, I was afraid following redirects could be expensive, but still it would be convenient... Assuming it would not actually harm on most pages with only a few references on them, perhaps there could be something like a counter, resolving redirects up to 100 times (or whatever is considered expensive at a time given) per page invocation and then ignoring them - after all it would be just a display convenience feature, not core functionality on which users of the templates should be able to rely on. So it would work on most pages, but still with a guaranteed upper limit for stability. Just some food for thought...

Thanks anyway...

--Matthiaspaul (talk) 21:10, 10 January 2020 (UTC)

The link parameters are the name-list parameters: |author-link=, |contributor-link=, |editor-link=, |interviewer-link=, |subject-link=, and |translator-link=; and two 'title' parameters: |episode-link= and |series-link= which are aliases of the last parameter |title-link=. The name-list parameters already mute self-links and the title parameters will in a future update.

MediaWiki already resolves redirects, it does it all the time, I'm content to let it continue to do that without adding to the complexity of cs1|2.

—Trappist the monk (talk) 23:11, 10 January 2020 (UTC)

Sounds very good to me, thanks.

Would it make sense to add this to |work= and aliases as well?

--Matthiaspaul (talk) 00:12, 11 January 2020 (UTC)

I just saw that there was a related discussion at Module talk:Citation/CS1/Feature_requests#Check for wikilink to current page (although I would not have consider this to belong into CSS). --Matthiaspaul (talk) 21:25, 10 January 2020 (UTC)

When any of the name-list parameters link to the current page, Module:Citation/CS1 simply does not create a link to the current page in that template's rendering. The solution did not involve css. At the time, a css solution would have required a change to Wikipedia-wide css; with the advent of WP:TemplateStyles that requirement is, I think, lifted. Does that mean that we should apply a css solution instead of the don't-link-to-current-page solution? Don't know.

—Trappist the monk (talk) 23:11, 10 January 2020 (UTC)

I am with you here. I consider this to be functionality that should be part of the template rather than display cosmetics only, therefore I would have put it into the templates' code as well rather than trying to address it with CSS.

--Matthiaspaul (talk) 00:12, 11 January 2020 (UTC)

I have tweaked Module:Citation/CS1/sandbox/styles.css so that hyperlinks with the class mw-selflink apply font-weight:inherit instead of the MediaWiki-provided font-weight:bold. Because of this I have also disabled the code in Module:Citation/CS1/sandbox that unlinked name-list parameter values

{{cite book/new |title=Title |title-link=Help talk:Citation Style 1 |author=Bob |author-link=Help talk:Citation Style 1}}

Bob. Title.

{{cite book/new |title=[[Help talk:Citation Style 1|Title]] |author=[[Help talk:Citation Style 1|Bob]]}}

Bob. Title.{{cite book}}: CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 15:59, 4 February 2020 (UTC)

|year= fails with non-Latin script

Cite book comparison

Wikitext	{{cite book|first=سيد يوسف|last=شاه|location=لاھور|pages=١٦٠-١٦١|publisher=محمدی پریس|title=حالات مشوانی|year=١٩٣٠}}
Live	شاه, سيد يوسف (١٩٣٠). حالات مشوانی. لاھور: محمدی پریس. pp. ١٦٠-١٦١. {{cite book}}: Check date values in: |year= (help)
Sandbox	شاه, سيد يوسف (١٩٣٠). حالات مشوانی. لاھور: محمدی پریس. pp. ١٦٠-١٦١. {{cite book}}: Check date values in: |year= (help)

~/Date validation recognizes the Arabic digits as digit characters, but Lua's tonumber() function only works with Latin characters. Fixed in the sandbox. Because this is a lua script error, I will likely update ~/Date validation within the next week.

—Trappist the monk (talk) 17:24, 13 January 2020 (UTC)

Module:Citation/CS1/Date validation updated.

—Trappist the monk (talk) 14:35, 18 January 2020 (UTC)

Some SSRN documents now require payment

The parameter ssrn= automatically displays the green free access lock, which is almost always a good thing (apparently this feature was added in 2016 - see SSRN free access lock in this talk page's archives). I discovered today that SSRN hosts a few papers that require payment, such as an NBER Working Paper I cited today (that's a wikilink to the footnote). ¶ Therefore, it seems we will (eventually) need a method to indicate that an SSRN paper is not free. (I tried ssrn-access=subscription but that parameter doesn't exist.) I don't see this as a top priority—I simply wanted to bring it to the attention of folks who know how address little problems like this one. My solution today was to just leave out the SSRN link as interested readers will find it on the NBER page for the paper anyway. Thanks! - Mark ¶ P.S. My apologies if this is old news. I did search the archives but didn't find anything.   - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 04:47, 15 January 2020 (UTC)

This is surprising, SSRN has committed to remain a free open access repository since being acquired by Elsevier. I'll be writing them to see what's what. Headbomb {t · c · p · b} 17:05, 15 January 2020 (UTC)

The free access is provided for Elsevier rather than for any users. See "License to Elevier" at https://www.ssrn.com/index.cfm/en/terms-of-use/ . Elsevier charge fees because "we believe that offering the broadest array of content provides the most value to our users". See "10. What is the charge for using the SSRN eLibrary?" at https://www.ssrn.com/index.cfm/en/ssrn-faq/#elec_lib_charge . Thincat (talk) 08:38, 16 January 2020 (UTC)

How to indicate that a web page has had its content replaced

A web page's content is replaced monthly; if I cite a specific version, from a previous month, complete with an archive URL, what value should I use for |url-status? It's not "dead", nor is it "usurped", but neither does it display the cited content. Do we need a new value, say, "replaced"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 15 January 2020 (UTC)

Ah, this discussion again...

See Help talk:Citation Style 1 § spam black list and archive urls and preceding discussions linked from there. Apparently we don't know the answer to this question, or if we do, this editor is not clever enough to decode the answer from the discussions.

—Trappist the monk (talk) 16:13, 15 January 2020 (UTC)

If this is a FAQ, perhaps you could dial down the sarcasm, and instead add it as such in the template's documentation, which I had the courtesy to check before asking here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 15 January 2020 (UTC)

I don't really see how this case differs from citing the front page of any major news organization (for whatever reason) as the content is still provided at the archive URL (if you really want to make a point of when it was relevant, add an accessdate). |url-status=live IMO. --Izno (talk) 16:17, 15 January 2020 (UTC)

It probably isn't; but then I'm more likely to cite - and to teach others to cite - a specific news page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 15 January 2020 (UTC)

Per your OP, you want to cite a previous, archived version. If the archive is by the same publisher, you add the original url and the archive url, plus the indication that the original is no longer live. Including the access dates. If the archive is by a different publisher, you are no longer citing the original source. You are citing an archive. If it is online, use {{cite web}}. If not online, use {{citation}}. 71.247.146.98 (talk) 02:47, 16 January 2020 (UTC)

"you are no longer citing the original source" Not so; I can cite a version I saw before it was changed; and perhaps one that I have in a local copy. I might also be fixing up links from citations made when the version cited was live. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 16 January 2020 (UTC)

Versions you saw in the past and versions you have in local copy are unreliable sources. The only way to "fix" citations that used to be live-linked is to link to a reliable archive. The other option is to remove the link altogether, which means, if the citation depended on online verification, it is no longer valid. 108.182.15.109 (talk) 14:42, 16 January 2020 (UTC)

"Versions you saw in the past and versions you have in local copy are unreliable sources" That's bunkum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:15, 31 January 2020 (UTC)

This passage in the documentation

RE: "(in particular, do not leave "work" empty with "publisher" non-empty in order to avoid rendering a website's name in italics; a website is a publication and thus its name should be rendered in italics – e.g., as CNN in the example above)."

In the recent RfC and related discussions, there was no consensus that "website=" or "work=" be mandatory and required in all cases. The close certainly did not state that. Yet this passage suggests that one or other of those fields is mandatory. I think we need to establish this before having a passage that suggests they are required. The MOS, at Wikipedia:Citing sources, states directly that flexibility is required for common-sense exceptions, since there is no one-size-fits-all solution.--Tenebrae (talk) 18:42, 15 January 2020 (UTC)

The documentation is clearly wrong here, even if that CNN example will often be right. Headbomb {t · c · p · b} 19:08, 15 January 2020 (UTC)

No. Every citation must cite a source, which is what "work" represents. The work in this case happens to be a website. It has to be there. This is policy, has nothing to do with the RFC. If the module does not throw an error when work (or its aliases) are missing then something is wrong with the code. 71.247.146.98 (talk) 03:07, 16 January 2020 (UTC)

Wrong. Having something like

• Messamore, W. E. (2020). "Thank God PewDiePie Is Finally Gone". CNN.com. CNN.

is pointless. Ie |work=CNN.com if what you are citing was created for CCN.com as a website (i.e. this is the work being cited)

• Messamore, W. E. (2020). "Thank God PewDiePie Is Finally Gone". CNN.com.

if you are citing information that happens to be broadcast on TV, and merely hosted on CNN.com, then CNN (the TV network) is the publisher, not the work.

• Smith, J. (2006). "Audio reveals tense confrontation between Warren and Sanders". CNN.

or, if you feel like digging some more, you can optionally find which program the broadcast was part of, in this case Anderson Cooper 360°. That is the |work=.

• Smith, J. (2006). "Audio reveals tense confrontation between Warren and Sanders". Anderson Cooper 360°. CNN.

Headbomb {t · c · p · b} 03:23, 16 January 2020 (UTC)

It is not wrong at all. Your examples use the wrong template. This should be {{cite news}} or {{cite episode}} or {{cite serial}} or {{cite av media}}. In these templates, the work should also be emphasized. What you may exclude is the publisher, not the source (the work), though the publisher could be pertinent. Works may be published by CNN subsidiaries or divisions. 108.182.15.109 (talk) 15:03, 16 January 2020 (UTC)

Plenty of things are not part of larger works. Headbomb {t · c · p · b} 15:13, 16 January 2020 (UTC)

I don't mean to reopen the RfC debate or any other. I'm simply talking about the language in the documentation page. Simply put, I think the passage says something that isn't true — because "website=" is not required. Should what appears to be an untrue passage stay or go? --Tenebrae (talk) 00:40, 17 January 2020 (UTC)

Personally I don't care if "website" or any other alias of "work" is used. But a work has to be cited. The idea that a reader will look for the source by searching for any other parameter (publisher or anything else) is novel to me. It is also grossly inefficient, imo. 108.182.15.109 (talk) 02:06, 17 January 2020 (UTC)

"A work has to be cited". It doesn't. Many things aren't even part of larger works, e.g.

Beaudoin, N.; Landry, G.; Sandapen, R. (2013). "Generalized isospin, generalized mass groups, and generalized Gell-Mann–Okubo formalism". arXiv:1309.0517.

Headbomb {t · c · p · b} 02:28, 17 January 2020 (UTC)

This example is a bad one. First, it is based on a specialized derivative of {{cite journal}} that is of little interest to the average Wikipedia editor (per the relative number of transclusions), let alone the average reader (I imagine). As a single-source template that is mostly computer-generated, it actually obscures the work (the website arxiv.org). That is because it is targeted to specialists who would know the details. But the average reader does not. The template is badly formatted and presented considering it is part of a general-purpose encyclopedia. If the module was correctly coded, explicit absence of the work (arxiv.org) would have been flagged. Because that is where readers would go to search for, and verify the wikitext, if the specific title-link was bad, or if the in-source location (the titled paper) was not specified for whatever reason. 24.105.132.254 (talk) 16:10, 19 January 2020 (UTC)

It's a perfect example for all the reason you think it's not. The arXiv is simply a repository of preprints. arxiv.org is not the associated "work". The associated work of a paper does not change depending on where it's hosted. Headbomb {t · c · p · b} 16:28, 19 January 2020 (UTC)

For citation purposes, the "work" or source is where verifiable proof is found, if someone cares to look for it. What that work/source actually is, is immaterial. In this case, the item in question can be found in the online version of a certain repository. The distributor (Cornell) maintains a website (arxiv.org) as part of their involvement with the repository (arXiv). In this website (the source), one can find in-source locations (webpages) dedicated to specific papers. There is nothing special about these kinds of citations compared to any other kind. But there is something very special, and not in a good way, about the CS1 templates that purport to format and present these citations. In a general-purpose encyclopedia they are pretty much incomprehensible. And they violate the main rule of citing anything: that the source has to be prominent, clearly and unambiguously presented. Some weird identifier used by a software routine to build a clipped citation-like construct just doesn't cut it. It would be much more helpful to the average reader to junk all that and just state, "follow this link at the arxiv.org website. If the link doesn't work, proceed to arxiv.org and search for this paper." 98.0.246.242 (talk) 02:19, 20 January 2020 (UTC)

I think we're getting far afield. This is a focused discussion on one specific, relatively small thing: Whether to keep a 40-word passage that falsely suggests a template field is required when in fact it is not. --Tenebrae (talk) 18:36, 22 January 2020 (UTC)

It's been nearly three days without comment. Since the passage is factually inaccurate, I'm going to be WP:BOLD and remove it.

No one is arguing in favor of it except for one anon-IP comment that also is factually wrong itself in saying "website+" "has to be there. This is policy." No, it's not — it's not even required by the Manual of Style. And, "If the module does not throw an error when work (or its aliases) are missing then something is wrong with the code." There's nothing "wrong" with the code, because "website=" is not required.--Tenebrae (talk) 10:28, 25 January 2020 (UTC)

Since this discussion began, an editor unilaterally changed the passage under discussion, showing no respect to the discussion process or to any of the fellow editors here discussing in good faith. As this discussion notes, it's inaccurate to suggest a field is required when it is not. Rather than WP:OWN the article and refuse to discuss the issue, I ask the editor who inserted and unilaterally changed this to discuss it here. --Tenebrae (talk) 10:35, 25 January 2020 (UTC)

Pinging @Headbomb:, the other registered editors so far involved in this discussion, to comment on this new development.--Tenebrae (talk) 10:38, 25 January 2020 (UTC)

• @Tenebrae: as you said, there was no consensus that "website=" or "work=" be mandatory and required in all cases. Nevertheless, some users continue to revert others' edits because they consider the use of this "publisher=" parameter as a "violation of citation style". What do you advise? I think it needs to be explained in Help:Citation Style 1#Work and publisher because such a practice is unhealthy for the community.--Russian Rocky (talk) 17:49, 15 February 2020 (UTC)
  • I agree that work= or website= has never been agreed to be mandatory (regardless of whether we also have a non-empty publisher) and I don't think that the passage in question, if read carefully, supports that misinterpretation. Nevertheless it is clear from contributors above like 71.247.146.98 that editors will misinterpret it as meaning that. So I think that it needs to be worded better, to make clear that (1) publisher without work is ok, and (2) parameters should not be misused for the purpose of formatting — if a piece of metadata really is the work and not the publisher, it should go in the work field and not the publisher field, regardless of how the editor putting it there feels about italicization. —David Eppstein (talk) 18:36, 15 February 2020 (UTC)

Access date with signs

Maybe it would be helpful to have |accessdate= (or something similar to that parameter) work with {{cite sign}}, as signs are frequently removed, vandalised or become unreadable after exposure to the elements. This is just a suggestion; I could see it not being helpful due to how rarely signs are "archived" compared to web pages. Glades12 (talk) 18:22, 16 January 2020 (UTC)

I am afraid this is not doable. There is no way I can see to apply neutrality to such access, it is non-fungible and unprovable. 24.105.132.254 (talk) 19:22, 16 January 2020 (UTC)

Can you explain further? Can't it just be the same as with URLs, where the date is the last one at which someone went to the sign, read it and could confirm that it still verifies the information before the citation? Glades12 (talk) 19:50, 16 January 2020 (UTC)

I would think it self-evident... this is stated without attempting to be sarcastic or ironic. But what you are proposing is I think unverifiable. 108.182.15.109 (talk) 02:01, 17 January 2020 (UTC)

Access date with web pages is (if someone updates it, as they are supposed to) unverifiable too, yet we still have that. You seem to have a double standard here. Glades12 (talk) 06:45, 17 January 2020 (UTC)

CS1 / Visual Editor copy-paste bug apparently fixed

For a while, there has been a copy-paste bug in the Visual Editor (VE) that caused code like templatestyles src="Module:Citation/CS1/styles.css" to appear in articles' wikicode. The bug is described in T209493. A bug fix was reportedly deployed on 15 January 2020.

This search shows articles currently affected by the bug. In theory, if we get them all cleaned up, we can find out if the bug is still present by watching to see if it shows up as a result of a future VE copy-paste edit.

Here's how I fixed one article. Helpfully, the edit that placed the bug-infected code in the article had a nice edit summary that led me to the original wikicode, which I was able to copy and paste to replace the badly formatted references. – Jonesey95 (talk) 05:19, 21 January 2020 (UTC)

@Jonesey95: good task for a bot? Headbomb {t · c · p · b} 05:40, 21 January 2020 (UTC)

I don't know. There are only 43 articles affected, so an editor versed in AWB and/or regular expressions, or simply someone with good detective skills could probably take it on. – Jonesey95 (talk) 06:48, 21 January 2020 (UTC)

i18n: miscellaneous fixes

Since the last update, I have been engaged in discussions with the editor who maintains the cs1|2 modules at sq.wiki. Those discussions have led to some changes that, I hope, will aid editors at other wikis when they update their module suites.

• Module:Citation/CS1/sandbox:
  • the supplemental portions of the Vancouver-style and archive url error messages have been moved into a table in ~/Configuration/sandbox
  • cfg.defaults table is disabled
• Module:Citation/CS1/Configuration/sandbox:
  • added more notes to aid translators
  • removed defaults table because it only supported |url-status= and the code never actually looks for the assigned default value (dead); rather, it looks for live, unfit, usurped, and bot: unknown
  • added err_msg_supl to hold supplementary error message text for archive url, bibcode, isbn, and Vancouver style error messages
• Module:Citation/CS1/Identifiers/sandbox:
  • the supplemental portions of the bibcode and isbn error messages have been moved into a table in ~/Configuration/sandbox

—Trappist the monk (talk) 14:07, 21 January 2020 (UTC)

Date not flagged as error

Hi, just spotted that a date without a space between the day & month is not flagged as an error.

For example {{cite web |url=https://www.goethe.de/ins/ca/en/kul/sup/dsk/dstu/fvp.html |title=PEDESTAL OF THE SOCALLED "PEACE MEMORIAL“ |date=11July 1998 |publisher=Goethe |access-date=26November 2019 }}

"PEDESTAL OF THE SOCALLED "PEACE MEMORIAL"". Goethe. 11July 1998. Retrieved 26November 2019. {{cite web}}: Check date values in: |access-date= and |date= (help)

Keith D (talk) 17:31, 23 January 2020 (UTC)

I have modified the value in |date= above, removing the space to show that this is not just a problem with |access-date=. – Jonesey95 (talk) 18:16, 23 January 2020 (UTC)

Just guessing here: should ^([1-9]%d?) *(%D-) +((%d%d%d%d?)%a?)$ in Module:Citation/CS1/Date validation/sandbox have + instead of * in the 13th character position? I made that change and got the output below. I have done no further testing, which could be risky. – Jonesey95 (talk) 18:24, 23 January 2020 (UTC)

Cite web comparison

Wikitext	{{cite web|access-date=26November 2019|date=11July 1998|publisher=Goethe|title=PEDESTAL OF THE SOCALLED "PEACE MEMORIAL“|url=https://www.goethe.de/ins/ca/en/kul/sup/dsk/dstu/fvp.html}}
Live	"PEDESTAL OF THE SOCALLED "PEACE MEMORIAL"". Goethe. 11July 1998. Retrieved 26November 2019. {{cite web}}: Check date values in: |access-date= and |date= (help)
Sandbox	"PEDESTAL OF THE SOCALLED "PEACE MEMORIAL"". Goethe. 11July 1998. Retrieved 26November 2019. {{cite web}}: Check date values in: |access-date= and |date= (help)

+ is 1 or more; * is 0 or more. Your change was correct. --Izno (talk) 20:44, 23 January 2020 (UTC)

ISBN and e-book ISBN

I have had several sources which have both a paper book and an e-book available, and they naturally have both their own ISBN numbers. Should the template:Cite book have parametres for inputting both (to be used only in case they are releases of the same edition), like the journal and magazine templates have the possibility of inputting both ISSN and eISSN parametres? --XoravaX (talk) 19:16, 23 January 2020 (UTC)

It seems to me the most important thing is leading the reader to the exact page that supports the statement. Since the pages between electronic books and paper books are often different. The person completing the citation should cite the one that the editor looked at. I think the cases where the editor looked at both and confirmed the page numbers are the same are rare enough that the extra complexity in writing the template code, using the template, and understanding how to use the templates, just isn't worth it. On those rare occasions the editor can always mention the alternate version in the citation, but outside the template. Jc3s5h (talk) 19:25, 23 January 2020 (UTC)

Indeed that the page numbering often differs between the paper and e-book releases is a major concern and a good point against. I suppose you are right that the rare occasions don't justify the possibility for inputting both paper ISSN and eISSN, especially considering the chance of mix-ups if the editor doesn't check the page numbering from both. --XoravaX (talk) 19:45, 23 January 2020 (UTC)

Ability to use more than one chapter in Template talk:Cite book

Hello, is it possible that a dev add the ability to have multiple |chapter= in Template talk:Cite book? It would be useful if,for example, one is to use sources from the same book but from different chapters. Veverve (talk) 01:46, 29 January 2020 (UTC)

There is some helpful information on a variety of Wikipedia help pages like this one that provides guidance on how to cite the multiple locations in the same source. – Jonesey95 (talk) 03:29, 29 January 2020 (UTC)

This seems undesirable. In some articles, the citations are arranged in a bibliography, which is sorted alphabetically by author name. Without having separate citations, it wouldn't be possible to decide where in the list to put the cite that combines several chapters (assuming each chapter was written by different authors). Jc3s5h (talk) 03:31, 29 January 2020 (UTC)

You might take a look at articles that have complex citation styles, like Herman Melville#References or Jane Austen#Citations, to get a sense of how chapters are cited in larger works. – Jonesey95 (talk) 03:57, 29 January 2020 (UTC)

I will have a look, thanks. Veverve (talk) 16:01, 2 February 2020 (UTC)

Access parameter for sites blocked in many countries

In Template: cite news (and other citation templates as well), would it be possible to have an access parameter for websites that are blocked in many countries? Best example being many American use websites e.g. Chicago Tribune, are blocked in the EU (& UK) due to GDPR. And it'd be good for this to be shown in the citation so that EU/UK readers don't waste their time trying to go to these URLs, in the same way you see subscription based sites in citations. Joseph2302 (talk) 12:33, 2 February 2020 (UTC)

This has been requested before and rejected accordingly. Please take a minute to search the archives. --Izno (talk) 12:51, 2 February 2020 (UTC)

This has been a recent discussion: Help talk:Citation Style 1/Archive 62#New url-status needed: content-missing --Matthiaspaul (talk) 19:29, 2 February 2020 (UTC)

I cannot find how to insert all the data into the Cite web template: for example, the template indicates only one language, that is, I understand, the language of the translation. But how do I mention the work in the original, which is important? GregZak (talk) 09:26, 10 February 2020 (UTC)

Is your post here in the proper place? What does this have to do with the various access parameters? Perhaps you should make your post and any replies a separate section of this help page.

|language= supports multiple language-names or language-codes where the parameter's value has the form of a comma-separated list: |language=de, fr, pl.

—Trappist the monk (talk) 13:01, 10 February 2020 (UTC)

Protected edit request on 5 February 2020: New biorxiv format

biorxiv seems to be using a new format with pages such as https://www.biorxiv.org/content/10.1101/2020.01.22.915660v1. Please change the verification to:

--[[--------------------------< B I O R X I V >-----------------------------------------------------------------

Format bioRxiv id and do simple error checking.  BiorXiv ids are of two forms:
the older form has exactly 6 digits, while the newer form is yyyy.mm.dd.6num.

There is an optional version part that we do not accept for now.

The bioRxiv id is the number following the last slash in the bioRxiv-issued DOI:
https://doi.org/10.1101/078733 -> 078733

]]

local function biorxiv(id)
	local handler = cfg.id_handlers['BIORXIV'];
	local err_cat = '';															-- presume that bioRxiv id is valid
	
	if nil == (id:match("^%d%d%d%d%d%d$") or id:match("^20%d%d.[01]%d.[0-3]%d.%d%d%d%d%d%d")) then						-- test for 6num or 20yy.mm.dd.6num
		err_cat = ' ' .. set_error( 'bad_biorxiv');	-- set an error message
	end
	
	return external_link_id({link = handler.link, label = handler.label, q = handler.q,
			prefix=handler.prefix,id=id,separator=handler.separator,
			encode=handler.encode, access=handler.access}) .. err_cat;
end

Artoria2e5 🌉 02:47, 5 February 2020 (UTC)

Further information is available at the About bioRxiv page, where they say bioRxiv DOIs assigned prior to December 11, 2019, have a simple six-digit suffix, whereas those assigned after this date will also include the date stamp for the day of submission approval. They give examples of 2019.12.11.123456 and 2019.12.11.123456v2 for the new format. – Jonesey95 (talk) 04:18, 5 February 2020 (UTC)

Fixed in the sandbox. I added some crude date validation and check for the version indicator separately:

• {{cite biorxiv/new |title=Title |biorxiv=915660}} → "Title". bioRxiv 915660. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.22.915660}} → "Title". bioRxiv 2020.01.22.915660. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.22.915660v1}} → "Title". bioRxiv 2020.01.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)

• {{cite biorxiv/new |title=Title |biorxiv=2011.01.22.915660v1}} → "Title". bioRxiv 2011.01.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2011.01.22.915660v1}} → "Title". bioRxiv 2020.13.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.35.915660v1}} → "Title". bioRxiv 2020.01.35.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.00.915660v1}} → "Title". bioRxiv 2020.01.00.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)

—Trappist the monk (talk) 16:12, 5 February 2020 (UTC)

I wonder if {{cite biorxiv/new |title=Title |biorxiv=2021.01.22.915660v1}} → "Title". bioRxiv 2021.01.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help) should display an error (changed the year). --Izno (talk) 17:11, 5 February 2020 (UTC)

I too wondered that but didn't arrive at any decision. Where is the cutoff? Tomorrow? Next month? Next year? A year from today? A month from today?

—Trappist the monk (talk) 01:18, 6 February 2020 (UTC)

Bolding of the volume number

Are there particularly significant reasons behind why we bold volume numbers in CS1? Although it may help parse volume versus issue, it also over-emphasiseds the volume in a way that's not really very helpful. It seems to have been more common in very compact citation styles where often the title would be omitted or before the ability to link to an item. Do the benefits outweigh the drawbacks? T.Shafee(Evo&Evo)^talk 11:29, 5 February 2020 (UTC)

Because that's what most academic citation guides do. Historically because finding the volume of a print journal was the most important thing, because if you got the page number wrong, you could still find whatever article you were looking for. Headbomb {t · c · p · b} 14:01, 5 February 2020 (UTC)

In addition to what Headbomb has said, it helps distinguish the volume from, say, the year or issue. Glades12 (talk) 14:14, 5 February 2020 (UTC)

The issue number was already mentioned. Sorry for my mistake. Glades12 (talk) 14:16, 5 February 2020 (UTC)

Thanks for the points raised. Given it's historically logical roots, of course plenty implement it (e.g. Nature, Science), however there are also plenty that don't any more / never have (e.g. BMJ, Cell, PLOS, BMC). So my question is more if we were designing CS1 today, is it something that would be implemented or is it just status quo momentum. If it's mainly momentum, it might be something worth revisiting as to whether it is overall a net benefit. T.Shafee(Evo&Evo)^talk 11:13, 6 February 2020 (UTC)

Bolding of volume (presentation of |issue/number= and |page(s)= in {{cite journal}} particularly also) comes up every couple months or so and mostly just needs an RFC to decide what we want to do. I imagine a couple questions:

1. Should the volume be consistent across all templates?
2. If yes, what should that presentation be?
3. If no, in addition to which multiple presentations should we provide, which templates should have which presentations?

For reference today, at least {{cite magazine}} varies from the bold presentation ("vol #"). (I have opinions on the other questions but I don't want to get into that right now because I'm just proposing the questions. :) --Izno (talk) 17:02, 6 February 2020 (UTC)

I would say we should be consistent across all of the templates and that we should clearly show that it is the volume by outputting "Vol." before it or else how do people know it is a volume? Keith D (talk) 18:35, 6 February 2020 (UTC)

This is certainly how journals are cited in most style guides, but I think it looks a bit jarring when citing books. Chicago (mostly), APA and MLA use "Vol.", Blue Book just a plain number. None bold. – Finnusertop (talk ⋅ contribs) 19:16, 6 February 2020 (UTC)

I believe journals go this way in style guides today because there is at least one international standard that lays out the expected styling for journals. --Izno (talk) 19:34, 6 February 2020 (UTC)

We used different rendering of page numbers (colon vs pp.) depending on whether the item is a journal or not. I would suggest we render volumes as bold in the former case and with "vol." otherwise. Kanguole 18:43, 6 February 2020 (UTC)

We should be clear on page numbers as well and always use "p." or "pp." in all templates. This is so people do not have to guess the meaning of the figures. Keith D (talk) 18:52, 6 February 2020 (UTC)

Et al, try not to get bogged down in the what it should be already :). I think what would be best right now is to (dis)agree that my questions are the questions we want to answer (in an RFC) and then to do the research necessary to present the question to the wider community (both what is done today in CS1/2 and what is done by external style guides, if we should choose to take external inspiration). Are those questions reasonable? Is there one to add? --Izno (talk) 19:31, 6 February 2020 (UTC)

From the above, we have three styles for rendering volumes and pages:

	Book	Journal
Current	3, pp. 12–56.	3: 12–56.
Proposal 1	vol. 3, pp. 12–56.	3: 12–56.
Proposal 2	vol. 3, pp. 12–56.

and maybe variants of the first two without bolding. In my view the volume needs to be set off in some way, if not by bolding then with a prefix. Kanguole 19:17, 6 February 2020 (UTC)

I am naturally concerned about the presentation in our other templates, such as cite encyclopedia and cite magazine. --Izno (talk) 19:31, 6 February 2020 (UTC)

[edit conflict] I would be happy with proposal 2 here. We are not an academic publisher and when academic standards are too technical for a general readership we should set them aside. —David Eppstein (talk) 19:32, 6 February 2020 (UTC)

Ah, I thought of the proposal 3: Full text, which has been floated much more rarely (e.g. volume 3, pages 12-56). I doubt it is an attractive option to anyone, but I do think the rationale for having our citations be one way vice another does partially come down to readability of the citation, and that is the most readable. (I think the contra-argument, if anyway, is that full text is hard to parse when we have the reference structure we do across the board, which largely emulates citations found in journal papers (multiple columns of citation/content) rather than in books, which I believe are usually single line + hanging indent or single line bullet points in one column). (I am not claiming this is what's done, just that's my impression of the matter.) --Izno (talk) 19:38, 6 February 2020 (UTC)

Just add the full text version as proposal 4. How should we proceed with the rendering of issues and numbers (and the less common, but nevertheless existing case of journals/magazine showing both at the same time)? Should we offer rendering options for them as well as part of an RfC, or should we just sort this out at a later stage? --Matthiaspaul (talk) 21:36, 6 February 2020 (UTC)

I reread what you wrote. Issues/numbers can be a part of this discussion, but I think the "uses both" needs some more thought on proposed implementation (i.e. do we run a bot to remove one or the other across the board and let people who know better correct it? etc.). That said, issue/number would need some more discussion in this section. --Izno (talk) 21:42, 6 February 2020 (UTC)

(EC) I'm partial to proposal 1 for now, because bolding volumes for books make no sense. I'm of two minds on bolding volumes for journals, first because it's rather clear that in, e.g. Quark ref 13 that this refers to the volume, and this is a great and concise visual format in scientific articles, and what is recommended by most style guides. At the same time, while grating, having an explicit vol. #, iss. #, pages #-# isn't completely the worst, however headaches will abound when people get confused/angry by issue vs number. Could probably be avoided with "vol. A, #B, pages C" or similar though. Headbomb {t · c · p · b} 21:39, 6 February 2020 (UTC)

Fully against full text though. That's just a waste of space and time. Headbomb {t · c · p · b} 21:41, 6 February 2020 (UTC)

Just a reminder that long volume values are not rendered in bold, e.g. "Title". Journal Name. Volume (Issue): Pages. 2020. {{cite journal}}: |issue= has extra text (help); |volume= has extra text (help) If we are going to do an RFC, that existing condition needs to be thrown into the soup. – Jonesey95 (talk) 22:42, 6 February 2020 (UTC)

Para ref causes extra punct maintenance category

I am not sure if this is intended, but this edit clears the "extra punctuation" category. Should |ref= actually be checked for extra punctuation? --Izno (talk) 20:51, 6 February 2020 (UTC)

It also seems to be checked in |author-mask=, which is intended to have dashes, as with here. I do not know about the correct solution in this case either, though I have found a preferable solution in the context of these templates. --Izno (talk) 21:23, 6 February 2020 (UTC)

See the explanatory text at Category:CS1 maint: extra punctuation for an explanation of the first edit. As for the second one, it looks like you may have seen Template:Cite book#Display options, which shows the supported options for |author-mask=. {{long dash}} renders as &nbsp;<span style="letter-spacing:-.25em;">———</span>&nbsp; – note the ending semicolon, which places the citation in the "extra punctuation" category. – Jonesey95 (talk) 22:37, 6 February 2020 (UTC)

Right... I'm aware of why I needed to make the changes. It is not however obvious to me that the two parameters in question should have these changes made. --Izno (talk) 22:39, 6 February 2020 (UTC)

I think this is why the category is currently a maintenance category, with a hidden error message that normal editors don't see. We usually set up maintenance categories if we are unsure of the scope of a potential problem, or unsure if we will catch false positives, or both. In this case, we are catching a false positive in the first instance. One could argue that the |author-mask= usage is not compliant with the documentation, but I could go either way.

In any event, no, you don't have to "fix" these conditions, but it's worth discussing whether those parameters should be excluded from this particular error check. – Jonesey95 (talk) 22:45, 6 February 2020 (UTC)

Well, it's designed to catch obvious nonsense like |author-mask=3;, but really the ideal solution is to exclude well-formed HTML entities from it. Headbomb {t · c · p · b} 23:35, 6 February 2020 (UTC)

I've added a line of code that allows for <, >, &, ", and   html entities as the final 'character' in a parameter. Here are the two templates mentioned above:

• Vermont State Archives (June 12, 2006). "General Election Results, U.S. Representatives, 1822–1830 (Five Districts)" (PDF). www.sec.state.vt.us. Montpelier, VT: Vermont Secretary of State.
•  ———  (1962). "Theism and Utopia". Philosophy. 37 (140): 153–158. doi:10.1017/S0031819100036810. ISSN 1469-817X. JSTOR 3748372. {{cite journal}}: Invalid |ref=harv (help)

This is not a perfect solution. For example, this, which uses |author=  will no longer be detected:

  (2005-12-21). "TWU Leaders Refuse To Back Down Despite Threat Of Jail Time". NY1. Archived from the original on April 3, 2008. Retrieved 2014-04-04.{{cite web}}: CS1 maint: extra punctuation (link)

I'm not sure if this is a net gain or loss.

—Trappist the monk (talk) 17:17, 7 February 2020 (UTC)

Never mind, I've been reverted.

—Trappist the monk (talk) 17:25, 7 February 2020 (UTC)

I reverted your change, mostly to demonstrate an alternative: I didn't realize that we had a whitelist of parameters, so I've added "Ref" there. I do think it would be a net loss for something like that in |author= not to be caught would be unfortunate. What I didn't try is to put the Mask parameters in the whitelist. Do you think that's possible with the current code? Or do we think it is not worth it and users should be instructed to provide an alphanumeric directly in |author-mask= et al, and to continue checking it like it is today? I think I tend toward continuing to check it and instructing users--which might lead to a stronger parameter check than currently (because this kind of check is fairly soft). --Izno (talk) 17:28, 7 February 2020 (UTC)

Adding meta-parameter Ref to that whitelist 'works' but we lose the ability to detect stray comma-colon-semicolon punctuation.

I don't know how common the |author=  problem is; MediaWiki repeatedly dies, returns nothing, or times out when I try to search for |author= .

We could, if we can determine that it is warranted, check for parameter values that are only white-space 'characters' that are html entities ( ,  , etc) with or without ascii space characters mixed in. When these strings of html whitespace characters are detected, the whole parameter value would be set to nil and the module would emit an error message or maint cat.

—Trappist the monk (talk) 00:36, 8 February 2020 (UTC)

Use high-resolution icons

The styles in Module:Citation/CS1/styles.css define a few new link icons, but they use low-resolution images, which look ugly on high-resolution screens (or when zooming in), particularly when shown next to default MediaWiki link icons, which are high-resolution.

For example, look at reference 2 on It (novel)#References.

I recommend using the same approach as MediaWiki to load SVG images on browsers that support them: https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.less/mediawiki.mixins.less#L31

Namely, please make these changes to Module:Citation/CS1/styles.css:

Extended content

Old New .id-lock-free a, .citation .cs1-lock-free a { background: url(//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png) no-repeat; background-position: right .1em center; } .id-lock-limited a, .id-lock-registration a, .citation .cs1-lock-limited a, .citation .cs1-lock-registration a { background: url(//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png) no-repeat; background-position: right .1em center; } .id-lock-subscription a, .citation .cs1-lock-subscription a { background: url(//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png) no-repeat; background-position: right .1em center; } .id-lock-free a, .citation .cs1-lock-free a { background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png); background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/6/65/Lock-green.svg); background-repeat: no-repeat; background-size: 9px; background-position: right .1em center; } .id-lock-limited a, .id-lock-registration a, .citation .cs1-lock-limited a, .citation .cs1-lock-registration a { background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png); background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/d/d6/Lock-gray-alt-2.svg); background-repeat: no-repeat; background-size: 9px; background-position: right .1em center; } .id-lock-subscription a, .citation .cs1-lock-subscription a { background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png); background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/a/aa/Lock-red-alt-2.svg); background-repeat: no-repeat; background-size: 9px; background-position: right .1em center; } .cs1-ws-icon a { background: url(//upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Wikisource-logo.svg/12px-Wikisource-logo.svg.png) no-repeat; background-position: right .1em center; } .cs1-ws-icon a { background-image: url(//upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Wikisource-logo.svg/12px-Wikisource-logo.svg.png); background-image: linear-gradient(transparent, transparent), url(//upload.wikimedia.org/wikipedia/commons/4/4c/Wikisource-logo.svg); background-repeat: no-repeat; background-size: 12px; background-position: right .1em center; }

Matma Rex talk 17:41, 7 February 2020 (UTC)

 Not done: Please feel free to add them to the sandbox, Matma Rex. Izno (talk) 17:45, 7 February 2020 (UTC)

Like this, I guess? I'm not familiar with the template stuff on this wiki. Matma Rex talk 18:12, 7 February 2020 (UTC)

@Matma Rex: Yes. Now, this won't be deployed until the next cycle in a month or two, so I'm disabling the edit request for that as well. --Izno (talk) 18:23, 7 February 2020 (UTC)

I like this. Quite a while ago I asked at the graphics lab about how to make these icon images clearer. I never got an answer so I'm glad to see that there is a way to make the images less fuzzy.

—Trappist the monk (talk) 00:38, 8 February 2020 (UTC)

Footnote and endnote parameters needed

I have just normalised a book citation, which cited a specific footnote. So I inserted a 'footnote = ' in front. It is an unrecognised parameter. Can this be added? And I suppose we better have endnote= too. The context for this is when the cited book itself cites an inaccessible source. --John Maynard Friedman (talk) 19:13, 8 February 2020 (UTC)

@John Maynard Friedman: Can you describe in more detail what you are trying to do? --Izno (talk) 19:19, 8 February 2020 (UTC)

You can specify both a page and footnote with |at=p. 117, footnote 77. Kanguole 19:30, 8 February 2020 (UTC)

yes, that would probably do, if I could see how to integrate it. Here is the citation as written:

• {{cite book| url = https://academic.oup.com/past/article/149/1/95/1460442 | title= Calendar Reform in eighteenth-century England | last= Poole | first= Robert | date= 1995| series= Oxford Academic Past & Present| page = 117 | footnote=77}}

It seems to me that footnote= sits more easily with the rest of the syntax. --John Maynard Friedman (talk) 19:43, 8 February 2020 (UTC)

It would be

{{cite book| url = https://academic.oup.com/past/article/149/1/95/1460442 | title= Calendar Reform in eighteenth-century England | last= Poole | first= Robert | date= 1995 | series= Oxford Academic Past & Present | at = p. 117, footnote 77}}

• Poole, Robert (1995). Calendar Reform in eighteenth-century England. Oxford Academic Past & Present. p. 117, footnote 77.

but actually this is a journal citation, so the specific location has to go outside it anyway:

{{cite journal | title = 'Give us back our eleven days!': Calendar Reform in eighteenth-century England | last= Poole | first= Robert | date= 1995 | journal= Past & Present | volume = 149 | issue = 1 | pages = 95–139 | doi = 10.1093/past/149.1.95 }} p. 117, footnote 77.

• Poole, Robert (1995). "'Give us back our eleven days!': Calendar Reform in eighteenth-century England". Past & Present. 149 (1): 95–139. doi:10.1093/past/149.1.95. p. 117, footnote 77.

Kanguole 20:38, 8 February 2020 (UTC)

"has to" is strong verbiage given what |page= (even in journal citations) is supposed to be used for according to its documentation. :^) There is nothing to prevent JMF from having the specific page and I'm sure I would not be alone in recommending he add the specific page number. --Izno (talk) 20:45, 8 February 2020 (UTC)

The Wikipedia article in question appears to be "Calendar (New Style) Act 1750". It's a hopeless mix of {{Citation}}, Cite xxx, short footnotes, cites to books without using short footnotes as an intermediary, citations using special purpose templates, and citations that do not use templates. It seems to me you need to figure out what the citation system will be for the article before trying to improve individual endnotes. Jc3s5h (talk) 20:50, 8 February 2020 (UTC)

If you do go for short footnotes, this could be done with {{sfn|Poole|1995|p=117|loc=footnote 77}}. Kanguole 20:57, 8 February 2020 (UTC)

It turns out that Poole 1995 is already in the reference list for this article, so the above {{sfn}} will work as given. Kanguole 22:22, 8 February 2020 (UTC)

If this is actually a footnote, add "n" at the end of the page number: |p=117n. If there is more than one footnote in the same page, these are usually numbered (or otherwise separated), so you should include that number/separator: |p=117n2. This has been the way to signify footnotes, since … forever. If it is a note at the end of a chapter or a book, these are usually in a separate, titled section. In this case you are citing a note in that section. Input the section title after the chapter title |chapter=Chapter: Section (most likely, "Notes"), or if at the end, |chapter=Section or |chapter=End matter and |at=End matter, p. [number], n. [number]. Edit: I moved "End matter" to |at= because only a limited number of special front/back sections are not quoted by the module. 98.0.246.242 (talk) 22:08, 8 February 2020 (UTC)

As Jc3s5h observes, the article where this question arose is indeed a mess of various citation styles. I made the mistake of thinking I could clean them up using a mobile (cell phone). Not a good idea. Thank you all for the suggestions, I will review the whole article when I have time to do it properly. --John Maynard Friedman (talk) 08:29, 9 February 2020 (UTC)

add chapter-archive-url

The template provides an archive-url parameter but does not provide an equivalent parameter for the archive of the chapter-url. It would be useful to provide an archive for the referenced chapter when chapter-url is present. Adding chapter-archive-url would need chapter-archive-date, chapter-url-status, and chapter-access-date parameters. Whywhenwhohow (talk) 20:48, 9 February 2020 (UTC)

There are half a dozen "-url" arguments. I think we are archiving any one of them, of which |archive-url= is the placeholder. Suggest extra archives added to {{webarchive}} which can hold up to 10. -- GreenC 20:59, 9 February 2020 (UTC)

How do I cite a Russian webpage with translation from a Latin book?

I need to cite several webpages with modern (2011) scholarly translations into Russian of mediaeval Italian chronicles written in Latin, translated from their 19-century publication in book series form printed in Germany. GregZak (talk) 09:21, 10 February 2020 (UTC)

Cite the source that you consulted; see WP:SAYWHEREYOUREADIT. If you consulted a Russian-language website where the content is taken from a German book, cite the website. If the Russian website holds a facsimile of the German book, cite the website as a book.

It is always true that examples of what you want to do will aid editors here in their attempts to help you.

—Trappist the monk (talk) 12:56, 10 February 2020 (UTC)

language parameter tweak

I've tweaked |language= handling so that it accepts ISO 639-2, -3 codes with IETF tags (yue-HK); ISO 639-1 with IETF tags already accepted.

Cite book comparison

Wikitext	{{cite book|language=yue-HK|title=Title}}
Live	Title (in Cantonese).
Sandbox	Title (in Cantonese).

—Trappist the monk (talk) 18:46, 10 February 2020 (UTC)

Thanks, Trappist the monk! Immediately a big change to Category:CS1 maint: unrecognized language. What are the new codes that are accepted? Can they be added to Template:Citation Style documentation/language/doc? = paul2520 (talk) 13:50, 11 February 2020 (UTC)

Umm, nothing has happened. The change that I made was only to the sandbox. I trolled through Category:CS1 maint: unrecognized language yesterday with an awb script and then manually. Both those efforts cleared a couple of hundred articles from the category and was the impetus for the sandbox fix that I made (one article with the yue-HK IETF language tag).

The content of Template:Citation Style documentation/language/doc will not change as a result of this fix. Module:Citation/CS1 accepts language codes with various tags but those tags are discarded. The listed codes and languages are the codes and languages that MediaWiki defines augmented with a very limited list of codes and languages that cs1|2 has overridden or added. When MediaWiki changes their list, the list at ~/language/doc will automatically reflect that change.

—Trappist the monk (talk) 14:26, 11 February 2020 (UTC)

Nomination for deletion of Module:Citation/testcases

Module:Citation/testcases has been nominated for deletion. You are invited to comment on the discussion at the module's entry on the Templates for discussion page. * Pppery * _{it has begun...} 01:44, 11 February 2020 (UTC)

Cite web accessdate vs. archived-date

Inspired by a VP/T discussion, when I find a reference with archived-date + accessdate I tend to remove the latter with edit summary access-date superseded by archive-date, because having both can make the article significantly larger, e.g., +12,533 -1,811 -826, with harder to read references. –84.46.52.252 (talk) 12:09, 11 February 2020 (UTC)

Not a good practice. They are not interchangeable parameters, and the corresponding dates serve different info. 72.43.99.138 (talk) 14:20, 11 February 2020 (UTC)

This discussion is a regular one. Please feel free to review the archives. I generally take the stance of IP84 but don't spend a lot of time on articles I'm just reading. --Izno (talk) 14:49, 11 February 2020 (UTC)

I think that it is not a good idea to blanket remove |access-date=. Many upon many |archive-url= parameters are added by bot. I have seen cases where the archive does not support our article's text. This is likely because the bot cannot evaluate the archive's content to see if that content supports the text in our article. Websites are ephemeral and the 'nearest' archived copy may be markedly different from the website content on the date it was accessed. I am not necessarily opposed to removal of access dates when a proper evaluation of the archive shows that it supports our article text though it does seem better to leave it; it is not worth the effort required to save a mere few kbytes.

For your other example, when the article has {{use xxx dates}}, it is perfectly acceptable to remove |df= from all cs1|2 templates except where it is determined that a different date format for 'this' citation is necessary.

—Trappist the monk (talk) 15:22, 11 February 2020 (UTC)

Makes sense, and IIRC my efforts in this direction were limited to articles, where I did the pending checked=true on their talk page, incl. two GA candidates- On two former drafts, where preemptive IA-Bot activities ended up in url-status=live, the archive-date was close to my accessdate. –84.46.52.252 (talk) 16:26, 11 February 2020 (UTC)

This has nothing to do with readability, ease of use or article size. Both dates are verification helpers, and in the case of online-only sources, (arguably) necessary. However archives are an altogether different class of source/proof. In any case, by definition dates are terse statements. In contrast, close reading of any article may reveal sizable chunks of wikitext that are verbose or superfluous and also, not relevant to verification. I would direct my energies there. 72.43.99.138 (talk) 23:49, 11 February 2020 (UTC)

Interaction with Use dmy dates

Picking up a point I made at the talk page of {{Use dmy dates}}, the consequence of the CS1/2 templates using this template to standardize dates in citations is that it violates WP:CITERETAIN, because of the retrospective element. There are articles to which {{Use dmy dates}} was added years ago (one example I found is from 2005). When these have consistent (or almost consistent) YYYY-MM-DD access and archive dates, these get changed to DMY dates, contrary to well established guidelines. It's no defence to say that this behaviour can be over-ridden by the use of |cs1-dates=, since no editor knew until the change was made that this parameter was necessary or even existed.

The CS1/2 templates should stop changing the displayed format of access and archive dates when {{Use dmy dates}} is present without |cs1-dates=. Peter coxhead (talk) 11:01, 13 February 2020 (UTC)

i18n: wikisource tweak;

Because there are different language versions of wikisource, en.wikisource should not be hard-coded into Module:Citation/CS1. Tweaked the sandbox to use the local language's language code (from Module:Citation/CS1/Configuration) as the second-level domain name.

—Trappist the monk (talk) 15:36, 14 February 2020 (UTC)

comma space error

did a search on the archive and found this which fixed the |page= option, but it also happens on the |issue= option. Dave Rave (talk) 00:47, 15 February 2020 (UTC)

A real-life example of what you mean will help us help you. Example please?

—Trappist the monk (talk) 01:12, 15 February 2020 (UTC)

any page with the option on it would show it to you .... you could sandbox it ?? oh, let me just hold your hand for a bit Dave Rave (talk) 01:16, 15 February 2020 (UTC)

Not helpful. If there is a problem with a citation template, please provide exact information. Vague statements about archived discussions involving unspecified options in "pages" will delay resolution of the issue if there is any. You could have stated that |issue= does not render properly if it includes a comma as in 5-digit numbers. That would have moved the discussion faster. 199.102.115.203 (talk) 15:03, 15 February 2020 (UTC)

Dave Rave, the {{cite compare}} template is very useful for demonstrating simple test cases for all of the CS1 templates. You can see examples of its use above. – Jonesey95 (talk) 16:25, 15 February 2020 (UTC)

Website= name & linking

This came up during a GAN: when using {{cite web}}, should |website= (or |work= if using that instead) show Billboard or Billboard.com? Several magazines, newspapers, etc., have both a printed version and a website with different content. Although the former use {{cite magazine}} and {{cite news}}, when used in an article, |work= (or the equivalent) appear the same for all three. If the template doesn't include an issue or page number, it isn't apparent to a reader if it's the print version or the website (except if |title= is linked).

Also, should |publisher= for a website be routinely required? According to the documentation for the templates, publisher is "Not normally used for periodicals" (although it includes an example). As a practical consideration, websites often change owners (or at least their names). It's not the same as adding a book publisher, which may be important when trying to identify a particular edition with different page numbers, spelling, etc.

—Ojorojo (talk) 16:36, 15 February 2020 (UTC)