# Help talk:Citation Style 1

 .mw-parser-output .tmulti .thumbinner{display:flex;flex-direction:column}.mw-parser-output .tmulti .trow{display:flex;flex-direction:row;clear:left;flex-wrap:wrap;width:100%;box-sizing:border-box}.mw-parser-output .tmulti .tsingle{margin:1px;float:left}.mw-parser-output .tmulti .theader{clear:both;font-weight:bold;text-align:center;align-self:center;background-color:transparent;width:100%}.mw-parser-output .tmulti .thumbcaption{text-align:left;background-color:transparent}.mw-parser-output .tmulti .thumbcaption-center{text-align:center;background-color:transparent}.mw-parser-output .tmulti .text-align-left{text-align:left}.mw-parser-output .tmulti .text-align-right{text-align:right}.mw-parser-output .tmulti .text-align-center{text-align:center}@media all and (max-width:720px){.mw-parser-output .tmulti .thumbinner{width:100%!important;box-sizing:border-box;max-width:none!important;align-items:center}.mw-parser-output .tmulti .trow{justify-content:center}.mw-parser-output .tmulti .tsingle{float:none!important;max-width:100%!important;box-sizing:border-box;text-align:center}.mw-parser-output .tmulti .thumbcaption{text-align:center}}Citation templates... in conception... and in reality

## Support citewatch=... or something like it

WP:CITEWATCH is a compilation of potentially unreliable citations (see Signpost for background). It's not perfect, and it doesn't catch everything, but it does cover a lot, and will likely cover more as things get developped. However, one thing it doesn't do is have a way of determining if a citation has already been checked to see if it was appropriate to cite it. Supporting a `|citewatch=yes` or similar (`|cw-check=ok` maybe?) would let us build the compilations without having to verify the same citations over and over. For example, if citation to Pharmacologia (a source that's on Beall's list was an appropriate citation) and other questionable sources we deemed acceptable, they could be marked as such with

• `{{cite journal |doi=10.5567/pharmacologia.2012.344.347 |title=Pharmacological Properties of Scoparia Dulcis: A Review |year=2012 |last1=Murti |first1=Krishna |last2=Panchal |first2=Mayank |last3=Taya |first3=Poonam |last4=Singh |first4=Raghuveer |journal=Pharmacologia |volume=3 |issue=8 |pages=344 |cw-check=ok}}`

And, upon the next bot run a table like this

Rank Target/Group Entries (Citations, Articles) Total Citations Distinct Articles Citations/article

106 Journal of Physical Therapy Science
[Beall's journal list]
15 11 1.364

601 Pharmacologia
[Beall's journal list]
1 1 1.000

could be updated to something like

Rank Target/Group Entries (Citations, Articles) Total Citations Distinct Articles Citations/article

106 Journal of Physical Therapy Science
[Beall's journal list]
15 11 1.364

601 Pharmacologia
[Beall's journal list]
1 1 1.000

For now `|cw-check=` would just be a whitelisted parameter that does nothing, although there could be some validation on what's acceptable (e.g. `|cw-check=yes`, `|cw-check=ok`) with a maintenance category for anything else. Headbomb {t · c · p · b} 03:21, 14 June 2019 (UTC)

This is a terrible idea - it isn't the purpose of relatively obscure wikiprojects to declare themselves the arbiter of what is a reliable source and what isn't (or to promote themselves using what is effectively the standaed reference system on Wikipedia - we shouldn't be giving references a badge of shame based on a very localised and dubious idea of what is reliable and what isn't - suspect sources should be discussed at Wikipedia:Reliable sources - if deemed unreliable for the context it should be removed, and if reliable for the use, it should be kept.Nigel Ish (talk) 20:45, 20 July 2019 (UTC)
It's not a thing that would be in any way visible to the reader. It would simply be to have `|cw-check=yes` not throw an error like it currently does (e.g. Smith, J. (2006). "Foobar". Quack Journal of Nonsense. 23 (3): 24. doi:10.1234/123456789. Unknown parameter `|cw-check=` ignored (help)). Likewise, WP:CITEWATCH does not take a position on weather or not a source is appropriate to cite, it just raises a flag that it's probably a good idea to double check. Headbomb {t · c · p · b} 20:55, 20 July 2019 (UTC)
My suggestion would be to have a param to signify whether the citation is being used as a primary source. That way, editors reviewing known unreliable sources can quickly parse how the citation is being used. Such a use case wouldn't be limited to citewatch. czar 20:50, 20 July 2019 (UTC)
I agree with Czar that it's better to focus on the specific content and how it's used. For instance, most people will look at whether the authors are authoritative, whether the paper builds on academic literature, any sign of substantive peer review having been performed, signs of (un)sound methodology. Some call it being "refereeable" https://arxiv.org/help/moderation or "scholarly". For us it would be "citable", to account for things like primary references, but that might prove confusing. Nemo 07:21, 25 July 2019 (UTC)

─────────────────────────

Well that's what WP:CITEWATCH picks up. Citations with high likelihood of being unreliable. Having support for `|cw-check=` (or something similar), would let us have (click [show] to see)

Rank Target/Group Entries (Citations, Articles) Total Citations Distinct Articles Citations/article

47 Science Publishing Group
[Beall's publisher list · Beall's publisher list / update]
Social Sciences could be multiple other journals. Several of SPG journals are named either identically or are very similar to other publications, e.g. International Journal of Data Science and Analysis vs International Journal of Data Science and Analytics and may thus have similar ISO 4 abbreviations.
 Hydrology (disambiguation) Hydrology (3 ? in 1, 2, 3) Science Publishing Group American Journal of Applied Mathematics (1 ✓ in 1) Bioprocess Engineering (1 ? in 1) Communications (15 ? in 14) Education Journal (2 ? in 1, 2) Industrial Engineering (2 ? in 1, 2) Social Sciences (disambiguation) Social Sciences (19 ? in 19)
43 42 1.024

Or similar (ignore the "All 0", it's a counting error due to how the template does its counting based on the currently logic) Headbomb {t · c · p · b} 09:54, 25 July 2019 (UTC)

To be clear, I do agree on the usefulness of facilitating such an outcome. Nemo 13:57, 30 July 2019 (UTC)

I would not support this. The global approach it is designed to facilitate is contrary to the idea in WP:RS that context matters. The reliability of sources used in an article is a matter to be discussed with reference to that article on the talk page or WP:RSN. It is not the function of citation templates to be applying scarlet letters to sources in article space. Kanguole 14:43, 30 July 2019 (UTC)

Again, you misunderstand the purpose. Absolutely nothing would be displayed in articles. There would be no Scarlett letters. Headbomb {t · c · p · b} 14:46, 30 July 2019 (UTC)
It is designed to facilitate a global approach to reliability, and it would put markers in wikitext, right? Kanguole 14:50, 30 July 2019 (UTC)
"A global approach to reliability" I don't know what that even means. See the Signpost article for what the citewatch is: a tool that identifies potentially problematic citations. `|cw-check=ok` would let us flag false positives, so that people who use the citewatch don't waste time reviewing the same potentially problematic sources over and over. The alternative is something ugly and error-prone like `|journal=MIT Review<!--Citewatch: This is not the hijacked journal, and is OK-->` Headbomb {t · c · p · b} 14:58, 30 July 2019 (UTC)
I think a parameter used in the individual citations is the opposite of a one-size-fits-all solution: it stresses that judgements need to be made on the individual article. However, I agree it's easy to misunderstand, so we'd need a very clear name for it. Nemo 16:05, 30 July 2019 (UTC)

## Supplement parameter

What happened to the |supplement= parameter on cite news? It either isn't working anymore or for some reason was removed which seems pretty stupid to remove that. Govvy (talk) 12:57, 22 September 2019 (UTC)

Are you sure? I don't know that `|supplement=` ever existed in cs1|2 templates.
Trappist the monk (talk) 13:10, 22 September 2019 (UTC)
True, I don't remember a "supplement" parameter either. I would use `|type=supplement` instead. If the particular supplement is a regular feature, identify the feature in e.g `|department=weekly magazine` or `|department=annual survey` or some such. 72.43.99.138 (talk) 13:43, 22 September 2019 (UTC)
For instance Sunday Times, has multiple supplements like Sports section, Business, Style Magazine, with their own page number, cite newspaper had it, now that redirects to cite news, which doesn't have |supplement parameter, can we add that please, thanks. Govvy (talk) 15:28, 22 September 2019 (UTC)
Are you sure? The first version of `{{cite newspaper}}` is as a redirect to `{{cite news}}`. Over its history, that has never changed.
As suggested before, consider `|department=`.
Trappist the monk (talk) 16:04, 22 September 2019 (UTC)
The {{Cite DNB}} template has a `|supplement=` parameter. It's not a CS1 template, but could be the source of confusion. 16:18, 22 September 2019 (UTC)
Department? That really is poor in description and use, can we please add =|supplement thanks. Govvy (talk) 21:07, 22 September 2019 (UTC)
Not as bad as you think, since supplements and specific, regular sections in newspapers and magazines are usually put together by different editorial departments. 98.0.246.242 (talk) 01:48, 23 September 2019 (UTC)
I remember this parameter, since I asked for it years ago. I asked for column per AP style, but the discussion was that folks would use this for the physical column, so the consensus was department. --21lima (talk) 23:32, 16 October 2019 (UTC)

## 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.CS1 maint: unfit url (link)
`<cite class="citation book">[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">CS1 maint: unfit url ([[:Category:CS1 maint: unfit url|link]])</span>'"`UNIQ--templatestyles-00000014-QINU`"'`

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.CS1 maint: unfit url (link)
`<cite class="citation book">[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">CS1 maint: unfit url ([[:Category:CS1 maint: unfit url|link]])</span>'"`UNIQ--templatestyles-00000018-QINU`"'`

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.

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:
Neither of those discussions consider blacklisted urls.
There were subsequent discussions with regard to parameter values:
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)

## Time to fix "In: <title>"?

Regarding the problem where "In:" is not prepended to a title when no editor is specified (previous discussion), where Kanguole demonstrated a fix that was not implemented due to press of other work: could we have that implemented now? ♦ J. Johnson (JJ) (talk) 22:34, 5 October 2019 (UTC)

@Kanguole? ♦ J. Johnson (JJ) (talk) 20:54, 10 October 2019 (UTC)

To recap, the proposal was that
`{{cite book |chapter=Chapter |first=Ann |last=Author |title=Book}}`
which is currently formatted as
Author, Ann. "Chapter". Book.
Author, Ann. "Chapter". In Book.
This compares with the formatting of
`{{cite book |chapter=Chapter |first=Ann |last=Author |title=Book |editor-first=A.N. |editor-last=Editor }}`
as
Author, Ann. "Chapter". In Editor, A.N. (ed.). Book.
It seems a clear improvement to me. The editor is flagged by "(ed.)", while "In" indicates a chapter in a book. Kanguole 22:07, 10 October 2019 (UTC)
Yes. Not the least because it is not the editors that are "in" a book, but the chapters. ♦ J. Johnson (JJ) (talk) 20:47, 11 October 2019 (UTC)
Really? Who is the muddled one? Look at where 'In' is placed in this rendering:
`{{cite book |author=Author Name |chapter=Chapter Title |editor=Editor Name |title=Book Title}}`
Author Name. "Chapter Title". In Editor Name (ed.). Book Title.CS1 maint: extra text: editors list (link)
Left to right:
Author name list precedes "Chapter Title", indicating that Author(s) is/are credited for "Chapter Title"
'In' introduces the Editor name list
Editor name list precedes Book Title, indicating that Editor(s) is/are credited for Book Title
The citation means exactly that Author's chapter is 'In' Editor's book. It does not say that Editor is in the book.
Trappist the monk (talk) 22:48, 11 October 2019 (UTC)
The author's chapter is "in" a book described by "Editor Name (ed.) Book Title". If there is no editor, the chapter is "in" a book described by "Book Title". Kanguole 23:27, 11 October 2019 (UTC)
Original discussion is at Help talk:Citation Style 1/Archive 59 § Proposal for an "in-title" ("In" + title) parameter. I think that I am opposed to this for the reasons I stated in the original discussion.
Trappist the monk (talk) 22:27, 10 October 2019 (UTC)
That was a wide-ranging discussion, but on this specific proposal I believe your argument that was that "In" marks editors, and is therefore superfluous if no editors are given. I've responded to that above. Kanguole 08:02, 11 October 2019 (UTC)
T: Your premises in the previous discussion were incorrect, and your grasp of the context muddled. It seems your underlying objection is simply WP:IDONTLIKEIT. Do we need to revisit this? ♦ J. Johnson (JJ) (talk) 20:55, 11 October 2019 (UTC)
If you believe me to be incorrect and that my grasp of the context muddled, show me where I am incorrect and muddled. Just claiming these things for whatever reasons you might have is not sufficient to persuade me to change my position. You are right, I don't like it, but I don't like for the reasons that I've stated. Tell me what you think is muddled or incorrect, and I will attempt a clearer explanation.
Trappist the monk (talk) 22:48, 11 October 2019 (UTC)

Trappist: In the previous discussion you stated (at 16:02, 22 Aug) that:

(1) The current "cs1|2 rendering has been in use for a long, long time and, so far as I know, has not caused our readers untoward confusion",
(2) "this proposal seems like a fix for something that isn't broken", and
(3) "The proposed use case ... would result in incomplete citations with, consequently, incomplete metadata."

In the previous discussion I explained why this is needed: there is an exceptional challenge in citing reports of the IPCC, especially in articles where there are dozens of such citations. Now I can't speak to what you may know about citing IPCC reports (though I suspect you have little or no experience in such cases), nor whether these details have "caused our readers untoward confusion" (how would we know?). But I can speak for editors: judging by the results it is a challenge for those who try, and with previous results being inconsistent, inadequate, and confusing. Strictly speaking your statement is correct (you don't know), but irrelevant. What is incorrect is the unstated premise that you would know if there was "untoward confusion", and the inference that therefore there isn't any problem.

As explained previously, I have developed a way of handling these cases which is fully in accord with standard citation practice, except for one little detail: cs1|2 omits the "in". That is broken.

You argue that the proposed use "would result in ... incomplete metadata". Not really, but refusing to supply "in" is not going to force inclusion of editors. It will result — and currently does — in corruption of the title metadata where editors include "in" in the title itself. You might note that in my approach the top level citation is complete in every way, including the editors (up to four).

More could be said, but let's thrash out the foregoing first. ♦ J. Johnson (JJ) (talk) 23:41, 11 October 2019 (UTC)

I don't think that there is anything wrong or muddled in any of the three statements of mine that you quote.
1. yeah, I don't know for absolute sure that the current rendering has not caused our readers untoward confusion. Do you know for absolute sure that readers have been caused untoward confusion? Without evidence either way, perhaps this point is moot.
2. I stand by that; it was the conclusion of the preceding paragraph
3. I stand by this too. In your original post you wrote: I have instances of multiple chapters in books where it is preferable to not list the book's editors in each chapter's citation, yet I would like to indicate that the chapter is "in" a larger work. This is the proposed use case. Omitting pertinent information because it is 'preferable' (the why of that has not been explained) is improper because the resulting metadata are incomplete.
I have no experience citing IPCC reports. But, let us examine the current state of Global warming and in particular AR5 Working Group I Report. In the previous discussion you provided an IPCC-preferred chapter citation so let us look at that report's citations.
• in the main book citation:
• you name IPCC as the author; IPCC does that in their 'preferred' citation. As a communal effort, I suppose that IPCC is, in a way 'the' author but the book is really the product of the editors and its various contributors.
• you use `|series=` to hold what in IPCC's citation is a subtitle. I presume that you are doing this as a way of avoiding the URL–wikilink conflict error that would arise from wikilinking part of the subtitle (`...[[IPCC Fifth Assessment Report|Fifth Assessment Report]]...`) when `|url=` has a value. This is problematic because the value assigned to `|series=` is made part of the citation's metadata in `&rft.series` misleading readers who consume the citation via the metadata into thinking that the report is part of a series named:
Contribution of Working Group I to the Fifth Assessment Report of the Intergovernmental Panel on Climate Change
• you set `|harv={{harvid|IPCC AR5 WG1|2013}}` as an anchor link from § Notes and from the various chapter citations in § Sources. I suspect that you also did this because the first four authors of "Summary for Policymakers" and "Technical summary" are the same and the first three editors of the book are also the same so Stocker et al. (2013) is ambiguous.
• in IPCC AR5 WG1 Summary for Policymakers you omit the authors entirely; not clear why
• in all of the individual chapter citations you use this construct:
`|title={{Harvnb|IPCC AR5 WG1|2013}}`IPCC AR5 WG1 2013`[[#CITEREFIPCC_AR5_WG12013|IPCC AR5 WG1 2013]]`
which makes the title in the rendered citation and in the citation's metadata be IPCC AR5 WG1 2013; not the title of the book. We have discussed this peculiar use before; you ignored me then, I expect that you will continue to do so now.
The above may be fully in accord with some (not named) standard citation practice, but not with cs1|2.
In the previous conversation I asked: Can this not be handled by a mixture of `{{sfn}}` templates pointing to `{{harvc}}` templates that point to a single full citation template? You answered: no, this can NOT [quote of my question redacted]. You did not say why. At User:Trappist the monk/sandbox/ipcc I have used `{{harvnb}}`, `{{harvc}}`, and the original `{{cite book}}` (slightly modified) to do what it is that I think you want.
Trappist the monk (talk) 15:26, 12 October 2019 (UTC)

Responses:

1. That's right: you don't know that there isn't a problem in regard of the readers. And therefore you should not claim that. However, there is a problem in regard of our editors, which is evident in various confused attempts to cite IPCC reports. (I can state from personal experience that the confused and incomplete state of some of these attempts impairs verification, and it is reasonably inferred that there is confusion amongst that small slice of the readers that attempt to go to the source.)

2. So we will have delve into your prior statements. For now I will just summarize what I (and Kanguole) have said: what is "in" a book is the chapters, not the editors. More on this later.

3. "Omitting pertinent information" and "incomplete metadata" seems to be the essential core of your complaint. (Right?) As for explaining why: I did so explain in the previous discussion. Perhaps that explanation was inadequate? Or perhaps you didn't read it? Well, I provide the same example as before of a typical citation as requested by the IPCC:

Stocker, T.F., D. Qin, G.-K. Plattner, L.V. Alexander, S.K. Allen, N.L. Bindoff, F.-M. Bréon, J.A. Church, U. Cubasch, S. Emori, P. Forster, P. Friedlingstein, N. Gillett, J.M. Gregory, D.L. Hartmann, E. Jansen, B. Kirtman, R. Knutti, K. Krishna Kumar, P. Lemke, J. Marotzke, V. Masson-Delmotte, G.A. Meehl, I.I. Mokhov, S. Piao, V. Ramaswamy, D. Randall, M. Rhein, M. Rojas, C. Sabine, D. Shindell, L.D. Talley, D.G. Vaughan and S.-P. Xie, 2013: Technical Summary. In: Climate Change 2013: The Physical Science Basis. Contribution of Working Group I to the Fifth Assessment Report of the Intergovernmental Panel on Climate Change [Stocker, T.F., D. Qin, G.-K. Plattner, M. Tignor, S.K. Allen, J. Boschung, A. Nauels, Y. Xia, V. Bex and P.M. Midgley (eds.)]. Cambridge University Press, Cambridge, United Kingdom and New York, NY, USA.

The problem here is a useless glut of metadata. As I said before (highlighting added): That's only ten editors and 34 authors (and I have several instances of over 50 authors); it does not include the chapter's contributing authors and review editors. This is a surfeit of "fullness", a useless glut of metadata that paralyzes the grasp of essential information. (A demonstration: how quickly can you scan that citation and pick out which chapter it refers to?)

It should be noted: that citation is intended to carry full details about BOTH the chapter AND the volume (book). Which is fine for a single standalone citation, but what I am dealing with is contexts where multiple chapters are cited from a given volume. In such cases repeating the volume information in each chapter's citation is not just useless redundancy, it buries the vital information (such as which chapter) in that useless information.

The "omission" here is not of editor metadata (other than being trimmed to only four editors), but of useless redundancy. That you want (?) the COinS data for a chapter to include all of the information for the volume is pointless because in most of these cases the chapter is not available separately, but only in the volume. (But of course there is an exception.) (If the emission of seemingly incomplete COinS data is a concern, then give us an option to suppress that.)

The rest of your comments are mainly an attack on the method I have developed, and not really relevant to the issue here of "in", but I will address them briefly.

• That you believe "the book is really the product of the editors and its various contributors" is wonderful, and totally immaterial: that the IPCC attributes some content as collectively "IPCC" (instead of to individual authors and editors) is their call, not yours.
• Any problems with the use of `|series=` can be discussed, but is off-topic for this discussion.
• Yes: the "IPCC AR5 WG1 ..." form is used because of multiple problems with use of author strings. Example; "Stocker et al. 2013a" and "Stocker et al. 2013b" are essentially useless, giving no information other than there are two cites to what ever report that came out in 2013.
• EVERY "Summary for Policymakers" is credited to the IPCC (and not to the drafting authors and editors) because this is per the IPCC, which is because these are "tweaked" by the governments.
• Re the rendering of "title": are you referring to the metadata for the chapter, or the book? The title of the latter is Climate Change 2013: The Physical Science Basis. The use of `|title=` in the chapter citation is as a link to the book, and can be considered as incorporating by reference all of the details of the book, including the title, subtitle, editors, publisher, isbn, other isbn, and doi. The use of a symbolic link more clearly identifies for both readers and editors the target of that link.

My reference to "standard citation practice" refers to nearly universal practice (see any style manual): chapters get an "in", even without editors. That cs1|2 does not do this is the deviation that I am trying to get fixed.

Your suggestion to use {{harvc}} is unworkable, and grotesque. Even if it produces an acceptable result, it introduces an additional, more complicated template, where many WP editors find the simpler harvnb somewhat challenging. It is grotesque in requiring the use of this additional template in every case (and additional instruction in its use), all of which would be avoided by a simple, one-time fix to cs1|2.

Your belief that "in" should be contingent on having editors I will have to address later, as I am out of time now. ♦ J. Johnson (JJ) (talk) 23:46, 12 October 2019 (UTC)

1. I have never said that en.wiki editors aren't confused when it comes to citing IPCC chapters
2. Yet another thing I have never said: I have never said that editors are in books; I have said that authors's (possessive) chapters are in editors's (possessive) book.
3. pretty much, because someone somewhere is relying on what metadata is present in an en.wiki article to be correct; IPCC AR5 WG1 2013 as a book title is definitely not the correct book title and there are no other bibliographic details, ISBN, publisher, etc that can be used as an aid to figuring out what the cryptic title really is
Yeah, IPCC's preferred citation format is a bit overmuch. By the way, it was not hard for me to skip over the author name-list to find the chapter title; it's right after the date. cs1|2 provides `|display-authors=` and `|display-editors=` as a way of reducing the quantity of author and editor names in the rendered citation; you have been using these parameters to, apparently, aid the the grasp of essential information.
Yeah, I know that you want to cite individual chapters of a source. I know that repeating the volume information in each chapter's citation is not just useless redundancy, it buries the vital information (such as which chapter) in that useless information. I know that you want to omit useless redundancy by which you mean volume or book bibliographic detail. I get that. This is precisely why `{{harvc}}` was created and it does it well without the need to misuse cs1|2 by use of invented book names and omitted bibliographic detail that results in incomplete and wrong metadata. If the emission of seemingly incomplete COinS data is a concern, then give us an option to suppress that. You have it: `{{harvc}}`.
To your bullet points:
• perhaps it is; perhaps it isn't; if IPCC truly considered itself the author, it would be so stated on the report's title page
• still subtitle in `|series=` is a misuse of `|series=` so is pertinent to this discussion about improper metadata
• am I to understand that you disapprove of any short-form citation that uses lowercase letter CITEREF disambiguation?
• I cannot speak to the validity of your claim; show me something that supports your claim
• I get that you are using the `{{harvnb}}` in the cs1|2 template's `|title=` (book title) parameter to link to the book's full citation so that you don't have to repeat all of the book's bibliographic detail for every chapter. My claim is that such use in a cs1|2 template is wrong because each cs1|2 chapter citation produced by this method generates flawed and incomplete book metadata.
"standard citation practice" refers to nearly universal practice (see any style manual) This seems to me to be an other-stuff-exists argument. cs1|2 has never inserted in between the rendered value assigned to `|chapter=` and the adjacent rendered value assigned to `|title=`. I see no reason why that practice should be changed.
Causing cs1 to insert 'In' (or 'in' with cs2) between chapter and title fixes nothing. For your use case, the chapter citations would still produce flawed and incomplete book metadata. Your characterization of `{{harvc}}` as grotesque; what does that mean? You don't like how it looks? `{{harvc}}` is more complicated than `{{harvnb}}`. But, for the most part, `{{harvc}}` uses the same parameter names as cs1|2 and `{{sfn}}` / `{{harv}}` templates. `{{harvc}}` adds `|in1=``|in4=` and `|anchor-year=`. Editors who can work out how to use cs1|2 and the short-form templates can work out how to use `{{harvc}}`. The en.wiki editor confusion is not fixed by the addition of 'in' between chapter and title.
Trappist the monk (talk) 19:29, 14 October 2019 (UTC)

### An arbitrary break where we go into whether "In" is ever "superfluous"

Trappist:

Let us consider your other contention, that cs1|2 "isn't broken" because (given chapter and title) the "in" should be contingent on specifying one or more editors.

Your statement that cs1|2 "isn't broken", the "conclusion of the preceding paragraph", goes back to our previous discussion last August, where you said: "'In' without editors, to me, seems to be extraneous because `|authorn=` (and aliases) identify the author(s) of the entire book so saying explicitly that "Chapter title" is 'In' Book title written by Author(s) is overkill or clutter."

I find this quite muddled because in the cases at hand there are not any "author(s) of the entire book". The chapters have authors (and also editors), and the books (volumes) have editors; there is NO "Book title written by Author(s)". That statement (the core of your argument!) needs considerable rework.

I am further baffled by how "'In' without editors" could be "extraneous". (I will be quite impressed if can provide a sensible explanation.)

On the otherhand, is it not clear to you that the factual nature of a chapter being in a book – both physically, and in the abstract concept of a work – is not altered by the specification, or not, of any attributes such as authors or editors, or titles, publisher, etc.? ♦ J. Johnson (JJ) (talk) 19:56, 13 October 2019 (UTC)

cs1|2 isn't broken. I stand by that overkill or clutter statement. Taking the simple case, a book authored by a single author. The book has a title: Book Title. The book is subdivided into chapters. We want to cite "Chapter 6". Because there is only one author, that author must be the author of "Chapter 6" so there is no point in saying in a cs1|2 citation that "Chapter 6" is in Book Title. Of course it is; that is obvious. There is no need to state the obvious.
The cases at hand are edited works where chapters are contributed by a variety of authors. Another simple example, a book assembled by a single editor. The book has a title: Book Title. The book is subdivided into chapters. Each chapter is written by a separate author: Author A wrote "Chapter 1", Author B wrote "Chapter 2", etc. We want to cite Author B's "Chapter 2" so cs1|2 names Author B and "Chapter 2" which is in Editor's Book Title. Because cs1|2 now adds an '(ed.)' or '(eds.)' suffix to editor name lists it might be argued that rendering 'in' when there is an editor name list is unnecessary. I have more sympathy for that argument than for adding 'in' between adjacent chapter and book title. And, I have to wonder: if it is necessary to have 'in' text between chapter and book title, isn't it also necessary to have 'in' text between journal/magazine/newspaper article and the adjacent journal/magazine/newspaper name?
The proposed change to Module:Citation/CS1 applies to my first simple example where there is no named editor, which as I have just attempted (yet again) to explain, is superfluous. The cases at hand, because the book has editors, has the 'in' text between the cited chapter and the editor list as it should. Leaving out the editor list as you want to do tells cs1|2 that there are no editors so it doesn't include the 'in' text.
cs1|2 has never supported the notion of chapter editors.
Trappist the monk (talk) 19:29, 14 October 2019 (UTC)

In your first paragraph you describe "the simple case, a book authored by a single author." (Whether authorship is a single person or entity, or plural, is immaterial, so let us agree that "author" includes "authors".) The essential character of your simple case is not "a single author", but no editors, and also no division of authorship within the work.[Removed duplicated content.]

Then you state that "The proposed change [applies to] where there is no named editor", which you describe as "superfluous". And you conclude: "Leaving out the editor list as you want to do tells cs1|2 that there are no editors so it doesn't include the 'in' text."

And there is the heart of the problem: you equate "no editors specified" (that is, no list of editors) with both no editors, AND no division of authorship. Both of those equivalences are false. (I direct your attention to the sample IPCC citation above, where the editors are listed in brackets, which indicates they are optional. I also direct your attention to the last line of my last comment: "the factual nature of a chapter being in a book [...] is not altered by the specification, or not, of any attributes such as authors or editors ...." Do you disagree?)

Your belief seems to be that listing of one or more editors is required to show when a chapter's authorship does not apply to the containing work. My view is that "In" communicates that. Which is not "superfluous" in the simple case of unitary authorship and no editor, because it is not used in that case. That is not because no editor is specified, but because authorship of the chapters is the same as for the whole work. Where chapters have different authorship it is quite legitimate to cite them without specifying the editors (if any), but "In" is required. In that regard cs1 is in fact broken.

And no, "In" is not used between the title of articles and the name of the journal or periodical because it is understood that the attributed authorship applies solely to the article.

In summary: you err in making "(eds.)" do the work of "In". ♦ J. Johnson (JJ) (talk) 23:58, 14 October 2019 (UTC)

The simple case I described was as I described it: a single author; nothing more, nothing less. Because it is a single author example, there can be no division of authorship unless it is somehow possible to subdivide the single author into halves or quarters or whatever. Had there been an editor for my single-author example, I would have so stated. The point of that example is to show that 'in' text is superfluous because the single author is understood to be the author of both the chapter and the book.
It is true that the proposed change to Module:Citation/CS1 would insert unnecessary 'in' text between chapter title and book title when the template does not have an editor name list. cs1|2 cannot discriminate between a book that has no editors and a book with editors whose names are not present in the template. It is the responsibility of the en.wiki editor to correctly fill cs1|2 template parameters or to use some other citation method.
That IPCC elects to bracket the volume's editor list does not necessarily indicate that the editor list is optional; it may just be a stylistic choice. And, IPCC's preferred citation form is neither here nor there because we are talking about cs1|2. You have evidence to support your claim that the IPCC editor list is optional in their preferred citation form?
I have never claimed that a chapter is not in a book. I have claimed that it is not necessary to state the obvious: it is obvious when the author of the chapter is the same as the author of the book (the single author example).
Yes, listing of one or more editors is required to show when a chapter's authorship does not apply to the containing work because without that list, the cs1|2 citation is incomplete. 'In', without an editor name list does not indicate that a chapter's authorship does not apply to the containing work. Inclusion of 'in' text between chapter title and book title as an indicator that editors have been omitted, as it appears you want, will misrepresent all chapter citations where the chapter author and the book author are the same. The proposed change to Module:Citation/CS1 would include 'in' text between chapter title and book title. Your statement that the simple case of unitary authorship and no editor, because it is not used in that case is contradictory to that reality because the 'in' text would be included in the unitary author case.
Where chapters have different authorship it is quite legitimate to cite them without specifying the editors (if any), but "In" is required. In that regard cs1 is in fact broken. False and false. In a cs1|2 template, naming an authored chapter in an edited work where the editor(s) has/have been omitted, misleads readers into thinking that the chapter author(s) is/are the author(s) of the book; the cs1|2 template appears to Module:Citation/CS1 as the unitary author case. cs1|2 cannot discriminate between a book that has no editors and a book with editors whose names are not present in the template. The insertion of 'in' text between the authored chapter and the edited book title (editor list omitted) says nothing about an omitted editor name list. For this, cs1|2 is not broken. The rendering of the citation that should have editors is flawed because an en.wiki editor did not include the necessary editor name list; that is not the fault of the template but is the fault of the en.wiki editor.
Trappist the monk (talk) 17:54, 15 October 2019 (UTC)

Your "subdivide the single author into halves or quarters or whatever" is bullshit, and shows just how muddled you are, and even ridiculous. There is no question here of dividing authors; the "division" refers to authorship – that is, the work, and thereby the attribution, of one, or more. authors.

Regarding your "simple case": back where you said "there is no point in saying in a cs1|2 citation that "Chapter 6" is in Book Title", I had actually agreed with that statement, and presumed that you would not say "this chapter is in this book". But the only way "In" would be included is if you did "say" (specified) "`|chapter=Chapter 6`" in the {cite book} template.

Which is wrong. In this kind of simple case you do not create a full citation (using cs1|2) for a chapter; the full citation is for the book as a whole. Citation of a specific chapter, or pages, or any other part, is specified as an in-source location. If you are not using short-cites (or similar) that data can be appended to the template along the lines of `{{cite book |year= 2001 |author= Author |title= Book Title |isbn= 99999}}, Chapter 6, p. 110.` Note: no `|chapter=`, therefore no "In" in the result. A chapter rates a full citation only where it is separately citeable, usually because of different authorship.

I may provide some explicit examples, but it looks like I don't have time for that today. ♦ J. Johnson (JJ) (talk) 19:41, 16 October 2019 (UTC)

Clearly you did not understand my use of the words single author to mean just that; a 'single author' means: 'one author'. I meant the 'subdivision' phrase to show that division of authorship is a meaningless concept then there is only one (a single) author.
Your quote of my statement misrepresents what I wrote. (I did fix the markup in the `{{tq}}` template). Here is the whole sentence: Because there is only one author, that author must be the author of "Chapter 6" so there is no point in saying in a cs1|2 citation that "Chapter 6" is in Book Title. Of course I would say: "this chapter is in this book" because it is. The proposed change to Module:Citation/CS1 would insert, unnecessarily, 'in' text between the chapter's title ("Chapter 6") and the book's title (Book Title).
Why would an en.wiki editor not specify `|chapter=` in a `{{cite book}}` template? It is done quite a bit. Here is an insource search for articles using `{{cite book}}` with `|chapter=` but without any of the `|editor...=` parameters. Because it is an insource search, the number of articles returned by the search is quite variable so the number of articles found by the search is likely quite a bit less than the actual number of articles that meet the search criteria.
Which is wrong. ... Really? Says who? Were it wrong in cs1|2 to specifically cite a chapter in a book's full citation, then cs1|2 would not allow en.wiki editors to do just that by providing and supporting the `|chapter=` parameter and its various aliases. Yeah, if en.wiki editors want, they may choose to append chapter and other in-source locator information after a cs1|2 template but why would they want to do that? That is guaranteed to produce inconsistently styled citations and to contribute to the citation maintenance headache.
Trappist the monk (talk) 18:19, 17 October 2019 (UTC)
I can think of three different situations where I would cite a chapter.
1. The chapter as a whole supports the claim in the Wikipedia article, and none of the considerations my points 2 and 3 apply. I would use "at=Chapter 3" or similar.
2. The authorship of the chapter is different than the editorship of the whole book. I would use "chapter= The Moon" or the like.
3. The chapter is available as a convenience link, but the book as a whole is not. The authorship of the book and chapter are identical. I would use a hand-typed citation spelling out the titles of both the book and the chapter, with the chapter hyperlinked to the convenience link (since the templates don't provide for this scenario).
Jc3s5h (talk) 20:45, 17 October 2019 (UTC)
Are you sure? Hyperlinking to a chapter's text someplace on the internet is why cs1|2 support `|chapter-url=` (and its aliases). Here's an example:
`{{cite book |author=Author |date=2019 |chapter=Chapter |chapter-url=//example.com |title=Title |location=Location |publisher=Publisher}}`
Author (2019). "Chapter". Title. Location: Publisher.
Trappist the monk (talk) 20:54, 17 October 2019 (UTC)
I hadn't noticed the chapter-url parameter. Jc3s5h (talk) 17:43, 18 October 2019 (UTC)
Which works fine if you are citing only one chapter. If you are actually citing the whole book, use of `|chapter=` and `|chapter-url=` would be incorrect. In that case the availability of one (or more?) chapters (your #3) is information best appended to the template. ♦ J. Johnson (JJ) (talk) 22:44, 18 October 2019 (UTC)

I have fully understood that your "simple case" is of a single author. I also understand – perhaps you do not? – that whether authorship is attributed to a single author, or multiple authors, is immaterial, as it makes no difference in the case presented. Your "subdivide the single author into halves or quarters or whatever" comment shows that you do not understand that my "division of authorship" is not over the domain of authors, but over the domain of what portion of the work is attributed to the identified author or authors.

The concept of division of authorship is not meaningless even in this simple case, because it allows for an affirmation of no such division. It also provides a basis for distinguishing a not quite so simple case of a book attributed to a single author, yet some part of it has different authorship.

And I have not misrepresented your statement. I quoted the part of your statement with which I agree. I left out your preliminary bit because it is muddled (and arguably wrong), and is immaterial to your point that "there is no point in saying ...", in order to focus on the key point.

As to saying explicitly that "this chapter is in this book": now you say "[o]f course" you would, though previously you said "there is no point}" in saying so. I think you were right the first time. Given a book with unitary authorship (that is, with no division, and regardless of whether "author" is singular or multiple), there is no point in listing all of the constituent parts. As long as the various parts have the same authorship (and date and publisher), they are presumed to be a single work. For which there should be a single full citation.

The actual point in referencing the chapter is to specify the in-source location of the content referred to. (Right?) But here you err (along with a thousand or so others) making the full citation refer to a specific part. Consider this: if you wanted to cite Chapter 1 and Chapter 6 of a book, would you invoke {cite book} twice, making two full citations? Or would you use `|chapter=Chapter 1, Chapter 6`? In such cases appending such information to the template is more sensible than trying to make the template handle all of that.

Where a chapter (or other part) should be specified in a full citation is where that is distinctly citable in its own right (typically because of differing authorship), not simply part of a larger source. E.g.: where a book is attributed to "Smith", we don't repeat that information for each chapter (let alone each page!), as each part is presumed to inherit the attributes of its parent. But if one chapter is actually written by (or with) "Jones", that needs to be said. This is where the citation should be "Chapter by Jones in Book by Smith".

"[I]nconsistently styled citations" already exist, are exactly what I am trying to address (particularly with the IPCC reports), so it rather amazing that you raise every possible objection to what I am doing. ♦ J. Johnson (JJ) (talk) 23:25, 17 October 2019 (UTC)

(edit conflict)
Apparently you don't. I think you are tying to read more into the simple example than is there. In the simple example, there is no subdivision of authorship; none; nada; the whole thing is the responsibility of the single author; every chapter, every verse, every page, every paragraph; all attributable to a single author; no other person gets credit for any of the simple example.
You want cs1|2 to add 'in' text between chapter title and book title for all book citations. There is no point to doing that. It is obvious that the chapter is in the book; it must be because it is all part of the same citation. When I read that citation, I can see that the chapter is in the book without your proposed change beating me over the head: "see, look here, this chapter is in this book." Don't need that.
You misrepresent me because the whole sentence says something different from how you are construing that little snippet.
Yes, of course I would. Given the evidence of a cs1|2 citation with `|chapter=` and `|title=` and without your proposed change to insert 'in' text between the two parameter renderings, it is obvious that the chapter is part of the book. There is no point to the extraneous addition of 'in' text between chapter and book title; they are both in the same citation.
I suppose then that you are opposed to the use of pagination or any other forms of in-source locators in full citations? I don't think that I have seen `|chapter=Chapter 1, Chapter 6` or the like in the wild. Such use would probably be contrary to the requirements of the metadata which appears to want one chapter item per `&rtf.atitle=` key. Editors usually write separate full citations using `|chapter=` for these kinds of cases or they crowbar the chapter titles into multiple `{{sfn}}` or `{{harv}}`-family templates. Appending multiple chapter names to the end of a full citation works only to the extent that the chapters are only visible to those who consume cs1|2 template visually; the chapter information is wholly lost (as it is with all short cites) to those who consume these cs1|2 citations via the template's metadata. Keeping the chapter in the cs1|2 template at least gets the metadata consumer in the general vicinity of the information being cited. And yep, free-form text inserted in the `<ref>...</ref>` tags is free-form text that one en.wiki editor will write one way, and other en.wiki editors will write in other ways. That is a recipe for inconsistency.
"Chapter by Jones in Book by Smith" is supported:
`{{cite book |title=Book by Smith |author=Smith |contribution=Chapter by Jones |contributor=Jones}} `
Jones. "Chapter by Jones". Book by Smith. By Smith.
Yep, I object to your proposed change to Module:Citation/CS1 that would unnecessarily insert 'in' text between chapter title and book title. I am in favor of consistency; tacking in-source locator information onto the end of a cs1|2 template in a free-form manner, as you have proposed here, is not going to do that.
Trappist the monk (talk) 23:11, 18 October 2019 (UTC)

I have found expert opinion (Chicago Manual of Style) that "In" is never superfluous, but required in all cases where a chapter is cited, even in a single-author book where there is no division of authorship. From the 17th edition:

14.106 Chapter in a single-author book.
When a specific chapter (or other titled part of a book) is cited in the notes, the author's name is followed by the title of the chapter (or other part), followed by in followed by the title of the book.

Similarly for multiauthor books. It appears this is to distinguish chapters, which are always in a work, from parts which are of a work. ♦ J. Johnson (JJ) (talk) 22:55, 18 October 2019 (UTC)

That's nice. cs1|2 is not CMOS; is not APA; is not MLA; is not Bluebook; is not <insert favorite style guide here>. Yeah, sure, cs1|2 may have been influenced by these style guides but cs1|2 is not beholden to them.
Trappist the monk (talk) 23:11, 18 October 2019 (UTC)

When I referred to "standard citation practice" a week ago you demurred [i.e., implied "the raising of an objection or taking of exception so as so as to delay action"] that these practices were "not named", and not in accord with cs1|2. [15:26, 12 Oct.]. But when I do name an authoritative source your response is that "cs1|2 is not beholden to them." To judge by some of your earlier statements – such as "I see no reason why that practice should be changed" – cs1|2 is beholden to only you, the self-appointed gate-keeper. This is starting to sound like a case of WP:OWN.

And now you have .. YET ANOTHER OBJECTION!! That if editors are allowed to insert free-form text into notes there will be inconsistency (gasp!), which you are not going to allow. Which is quite irrelevant to the change I am requesting, and comes into this discussion only because of your confused understanding of how to handle in-source locators. I have tried to address every objection you have made, but this is getting to be whack-a-mole. Perhaps you should codify your objections in a list, and be done with making them up as you go. ♦ J. Johnson (JJ) (talk) 21:55, 19 October 2019 (UTC)

You declined to name the 'standard' of the citation practice you are using at Global warming; that's ok, it does not really matter except that, whatever that standard citation practice is, it is certainly not in accordance with cs1|2 for the reasons that I have stated.
It is true that your authoritative source is an authoritative source about itself. But, CMOS, as an authoritative source, has no control over MLA (its own authoritative source about itself), nor APA (also its own authoritative source about itself), nor Bluebook (yep, also its own authoritative source about itself), and, therefore, no control over cs1|2. So, yeah, cs1|2, while it may have been influenced by CMOS, as it may have been influenced by MLA and influenced by APA, is not beholden to any of those authoritative sources.
It is true that I see no reason for us to change Module:Citation/CS1 to add 'in' text between chapter title and book title as you would have us do. That opinion does not make cs1|2 ... beholden to only [me] nor does my willingness to defend this opinion make me cs1|2's self-appointed gate-keeper. Such assertions are nonsense. I do not own cs1|2; never have, never will.
If you will recall, you are the one who suggested that If you are not using short-cites (or similar) that data can be appended to the template along the lines of `{{cite book |year= 2001 |author= Author |title= Book Title |isbn= 99999}}, Chapter 6, p. 110.` Note: no `|chapter=`, therefore no "In" in the result. From this I understand that you do not want en.wiki editors to use `|chapter=`, `|page=`, or the other in-source-locator parameters in a cs1|2 template but, to instead, add that information, free-form, after the template. One en.wiki editor's free-form text will be different from another en.wiki editor's free-form text so, yes, citations adhering to this method will be inconsistent.
Trappist the monk (talk) 18:55, 20 October 2019 (UTC)

You have a curious way of twisting things around. E.g., I did not "decline" to name a standard, as no one requested such information; that word is misrepresentation.

When I said I had a method "fully in accord with standard citation practice, except for one little detail", I was referring to the general forms and practice of citation that are common amongst essentially ALL citation authorities, such as the ordering and styling of author(s), title, publisher, etc. — which you can confirm by consulting what ever authority you may have at hand. And with which cs1|2 certainly IS "in accordance". The detail at issue here is a certain case where cs1|2 is not "in accord" with itself.

But your complaint here (that I did not name a particular standard) is just more bullshit, because when I do name an authoritative source you assert that it is authoritative only about itself, and assert that it "has no control" over cs1|2. Which is more twisting of reality, as no one claims that the Chicago Manual of Style has any "control" over anything but what the University of Chicago Press publishes. What you reject is the fact that CMS has influence because it is respected for providing a useful, clear, and consistent (as far as can be expected) model for citation, based on over a century of experience. Whereas your opposition is based on ... what? No authority, extremely little experience, just your personal interpretations and preferences of how matters should be.

You see no reason for this change, therefore you won't make this change. That sounds like ownership to me. If not, how about stepping aside and letting someone else make the change? ♦ J. Johnson (JJ) (talk) 21:44, 21 October 2019 (UTC)

The detail at issue here is a certain case where cs1|2 is not "in accord" with itself. How do you reckon that? Your proposal here is to insert 'in' text between chapter-title and book-title. This is something that cs1|2 has never done. How can cs1|2 not [be] "in accord" with itself for this thing that it has never done?
I did write that it is ok that you have not have named the standard that you are using at Global warming. I also wrote that whatever that standard is, it is not cs1|2 but is some other standard. It is true that CMOS has no control over cs1|2. Just because CMOS says to do something some way does not obligate cs1|2 to do the same thing the same way as CMOS would do – vice versa, cs1|2 does not dictate style to University of Chicago Press. Yes, CMOS and the others are influential, they influenced the creation of cs1|2. I have never denied that. When the original authors created the original templates more than a decade past, they chose, for whatever reason, not to insert 'in' text between chapter-title and book-title. I, for one, happen to agree with that choice. My agreement with that choice and opposition to the current proposal is not ownership.
Trappist the monk (talk) 14:32, 23 October 2019 (UTC)

What??? How can you seriously say that inserting "in" is "something that cs1|2 has never done"? Here is an instance of {cite book} (highlighting added): Author (2000). "Chapter". In Editor (ed.). Book. Do you not see "in" immediately following "Chapter"? QED: cs1 has inserted "in", and your statement that it never does is disproved.

The bottom line of all the rest you just wrote is: 1) you do not accept any external authority, and 2) you "approve" of the way cs!| works now, so are not going to change that. The problem with that first position is that you have not indicated that you accept any authority or expert guidance, showing no basis for your opinion other than undisclosed, personal LIKE. And your "approval" can't be because you think the past work of sacred authors is perfect, because you are constantly changing it. You have also made all kinds of arguments, but they're pretty much all bullshit (like your "never done" argument above, or the "free-form text" argument before it), or just irrelevant. The bottom line to all of this is: you DON'T LIKE the request, and therefore you WON'T ALLOW IT. How is this not an indication of ownership? ♦ J. Johnson (JJ) (talk) 21:47, 24 October 2019 (UTC)

The insertion of 'in' text between chapter-title and editor-name-list is not the same thing as the proposed insertion of 'in' text between chapter-title and book-title. cs1|2 has never inserted 'in' text between chapter-title and book-title which is the proposed change to cs1|2. You will recall that in my first reply to you in this subsection I said that now that the editor-name-list is annotated with '(ed.)' or with '(eds.)', I am more likely to support the removal of the 'in' text in that case because now, the editor-name-list annotation makes the 'in' text somewhat redundant or superfluous.
Trappist the monk (talk) 15:15, 25 October 2019 (UTC)

So your sense of "between" is without any other text also between, the other text being that about the editors. In that case your previous statement is missing a key qualification, and a more correct statement would be: Cs1|2 has never inserted "in" without also inserting editor(s). Which (with a possible quibble about "never") is my statement of the problem. And your position is, quite simply, "having never done this before, it never should do it." Which is absurd, and not a valid argument.

Your statement that inserting "(eds.)" "makes the 'in' text somewhat redundant or superfluous" further demonstrates that you do not understand the nature and scope of "in": it does not apply to the editors. It applies to the entire containing work (which has attributes of editor(s), title, etc.). Likely you have been confused because the list of editors immediately follows the "in", but that is incomplete; you should parse the range of "in" greedily, not parsimoniously. "Eds." describes the nature of the named persons as "editors". "In" relates the preceding part of the citation – about the chapter, which has a title and possibly zero or more named authors — to the rest of the citation, which has a title, and possibly empty list of named editors. (And I can provide an example of a book with a chapter with different authorship, and no named editors.) "In" relates the chapter to the work, quite independently of whether any editors are named; it is neither redundant nor superfluous.

"In" applies to chapters, and conditioning it on having editor(s) is thus an error. Having never been fixed is not an acceptable argument for should never be fixed. ♦ J. Johnson (JJ) (talk) 00:08, 26 October 2019 (UTC)

Yep, 'in' text without any other text also between chapter-title and book-title is the essence of your proposal and the thing that I oppose as superfluous and unnecessary. It is true that cs1|2 has never inserted "in" without also inserting editor(s). If it makes you happy to write it that way, do so. No. My position is that 'in' text without any other text also between chapter-title and book-title is superfluous and unnecessary; does not convey any information that is not already present in the rendered citation. cs1|2 has never inserted 'in' text between chapter-title and book-title; it ain't broke so it don't need fix'n.
When there is an editor name-list, 'In' text introduces the reader to the editor name-list so that the reader knows not to go into the stacks at the local library and look for the book at the chapter-author's name (the book is the editor's book and so is cataloged by editor's name). This is the only benefit that I can see for keeping the 'in' text with the editor name-list. It was more important when cs1|2 did not include the '(ed.)' or '(eds.)' annotation at the end of the editor name-list. With the annotation, the 'in' text is less important which is why I wrote that annotations [make] the 'in' text somewhat redundant or superfluous.
When there are no editors, and therefore no editor name-list to render, 'in' text does not introduce anything so is superfluous. Writing cs1|2 citation templates without editor name-lists when those templates should have editor name-lists (the apparent underlying rational for this whole proposal) is writing malformed cs1|2 citation templates.
Clearly, you and I are not going to agree. We could go on, I suppose, but unless one of us somehow manages to find and enunciate that perfect argument, neither are going to be convinced to change our positions. With the caveat that I remain opposed to the proposal, you may have the last word if you'd like it.
Trappist the monk (talk) 00:17, 29 October 2019 (UTC)

### Another arbitrary break for "in: title"

The argument that the cs1|2 templates have always done something is not a strong one, partly because the introduction of "(ed.)"/"(eds.)" has changed the context, and partly because the cs1|2 style is a collection of more-or-less arbitrary decisions taken over a long period and fossilized by the extreme difficulty of getting anything changed.
Certainly the above discussion does seem to have discussed aesthetics and different notions of consistency to the point of exhaustion. You are against the change; J. Johnson and I are in favour of it, and we know how to implement it.[1] So unless someone else chimes in, or there is some technical issue, I propose that we make the change. Kanguole 01:03, 29 October 2019 (UTC)
I am persuaded by Ttm's points. :) --Izno (talk) 01:56, 29 October 2019 (UTC)
I do not agree that the impasse between Trappist and I cannot be resolved by anything less than a perfect argument. I also think that (even after two weeks) this discussion is not mature, in that there are a lot of loose ends. Particularly, there are some possibly persuasive arguments that have not yet been presented. Even if Trappist is done with this discussion, it has been long enough that it is unrealistic to expect a reasonable evaluation of the issue without a more succinct statement of the arguments. And the argumentation is incomplete on both sides. (E.g., I can think of at least argument Tappist has not raised.) If everyone agrees that a reasonable resolution can be made as matters stand now, fine, but in the current somewhat inchoate state there could be miscomprehensions. And I think there is still a chance that Trappist could be persuaded. ♦ J. Johnson (JJ) (talk) 19:51, 30 October 2019 (UTC)
Izno: Some of Trappist's points are foolish. Could clarify which points you find persuasive? ♦ J. Johnson (JJ) (talk) 19:43, 2 November 2019 (UTC)

Trappist: Repeating an earlier request: would you mind listing all of your objections? There are so many that I am not certain I haven't overlooked any. ♦ J. Johnson (JJ) (talk) 23:57, 29 October 2019 (UTC)

### Summary of the case for this modification

The following summarizes the case for modifying the cs1|2 code so that the insertion of "in:" into a citation is conditioned on specifying a chapter.

It is standard citation practice (as recommended by all major citation authorities) to insert "in:" to indicate that a cited source is part of a larger work — such as a chapter in book — that has different authorship than the cited source. Currently cs12 does this only when one or more editors (presumably of the larger work) are specified. That functionality thus fails for actual and legitimate cases – such as contributions in conference proceedings where the editors that assemble the papers are often not named, or even books where an author includes someone else's work as chapter, but there simply is no editor – and the "in:" is needed despite the lack of any named editors.

There are also cases of works (possibly with a long list of editors) from which multiple chapters are cited, where it is unuseful and even detrimental to repeat all of the details of the work in the citation of every chapter.

In opposition (by Trappist the Monk), it has been argued that cs1|2 is "not beholden" to any of these expert authorities, and therefore they do apply here. That is an unuseful attitude. Such authorities reflect "best practices" based on years of professional experience that would be unwise to ignore, and the use of "in:" in this manner is a standard convention that readers expect.

It has also been argued that "in:" introduces the editor(s), and without a list of editors it is "superfluous and unnecessary". However, the prerequisite that "in:" introduces a list of editors is incorrect. It should be understood as applying to the work, not to just the first detail that describes the work. It might be noted that some citation authorities place the editors after the book title, which shows that the scope and meaning of "in:" is not changed by the ordering of the details of the work.

It has been argued that not specifying any editors "misleads readers into thinking that the chapter author(s) is/are the author(s) of the book...." But that is the point of "in": to indicate that a chapter has different authorship (or editorship) than the work; the problem arises not from a lack of editors, but from a missing "in:". It is precisely this point why "in" should be inserted even when no editors are specified.

The inverse has also been argued, that where the authorship of a chapter is the same as the work (book), inclusion of "in:" implies otherwise, and is extraneous. However, this only happens if `|chapter=` is specified, which is an improper usage in such cases. Full citations (such as created by cs1|2) cite only the whole source, not the constituent parts. Such cases are presumably where a WP editor is trying to provide an in-source location, which should be done by other means. As has been said before, "that is not the fault of the template". At any rate, an extraneous "in:" does no harm.

Additional arguments of opposition have been made (see the long discussion above), but are not substantive. If there are no further comments I will propose proceeding with the requested modification. ♦ J. Johnson (JJ) (talk) 21:23, 9 November 2019 (UTC)

@Kanguole:: There being no additional comments or objections, I propose we proceed with the requested modification. ♦ J. Johnson (JJ) (talk) 00:15, 13 November 2019 (UTC)

You must not take my silence as approval or even acquiescence. It is not. Neither of us were able to convince the other to change position. Nothing that I have read in your writings here since then has changed my position. Lest my self-imposed silence be misconstrued as approval or acquiescence, I must break that silence to reaffirm my opposition to this proposed change.

Trappist the monk (talk) 00:36, 13 November 2019 (UTC)

I do not take your silence as approval, and I recognize your position of WP:IDONTLIKEIT. So we will let others decide. ♦ J. Johnson (JJ) (talk) 01:03, 13 November 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. 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. 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 editSchreiberBike| ⌨  04:42, 18 May 2019 (UTC)

The following pages have been notified

### 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. 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)? - PaulT+/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. - PaulT+/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.
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.) - PaulT+/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. - PaulT+/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. 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,[a] 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.

1. ^ Relevant policies (emphasis in originals):
• WP:Verifiability: "all material must be attributable to reliable, published sources.... Articles must be based on reliable, independent, published sources with a reputation for fact-checking and accuracy. Source material must have been published.... Unpublished materials are not considered reliable.... Editors may ... use material from ... respected mainstream publications. [Details elided.] Editors may also use electronic media, subject to the same criteria."
• WP:No original research: "The phrase 'original research' (OR) is used on Wikipedia to refer to material – such as facts, allegations, and ideas – for which no reliable, published sources exist."
• WP:What Wikipedia is not: New research must be "published in other [than the researchers' own] venues, such as peer-reviewed journals, other printed forms, open research, or respected online publications".
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, - PaulT+/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. - PaulT+/C 15:00, 23 May 2019 (UTC)
Yep. 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 (talkcontribs) 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? 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 (TALKCONT) 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). 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? - PaulT+/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). Brandmeistertalk 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. - PaulT+/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. Brandmeistertalk 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. - PaulT+/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)? - PaulT+/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. - PaulT+/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? - PaulT+/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. Brandmeistertalk 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.) - PaulT+/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. Brandmeistertalk 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. - PaulT+/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. Brandmeistertalk 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. - PaulT+/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. Brandmeistertalk 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. 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 Ellsworthed. 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 Ellsworthed. 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 Ellsworthed. 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 Ellsworthed. 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. CThomas3 (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. 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)
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 hereSchreiberBike | ⌨  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. 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. 19:40, 6 October 2019 (UTC)

The following pages have been notified:

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. 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. 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. 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?" 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)
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. 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.  — AReaderOutThatawayt/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).  — AReaderOutThatawayt/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 (talkcontribs) 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.  — AReaderOutThatawayt/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)

## Citing online databases

How do we cite an online database that takes a string query as an input? I'm currently doing it this way:

{{cite web |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |title=JPL Small-Body Database Browser — Search string: Borisov |website=JPL Solar System Dynamics}}

"JPL Small-Body Database Browser — Search string: Borisov". JPL Solar System Dynamics.

Another option would be:

{{cite web |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |title=JPL Small-Body Database Browser |at=Search string: Borisov |website=JPL Solar System Dynamics}}

"JPL Small-Body Database Browser". JPL Solar System Dynamics. Search string: Borisov.

I don't like either. The first one puts the query string inside the quotes, which is wrong—it's not a part of the title (at least on the website shown in the example). The second one separates the title from the query, which is ugly. There's also |entry=, but it's not available in {{cite web}}. So how do I do it?

Perhaps, we should add a special parameter to {{cite web}} to handle such citations (which are quite common is scientific articles), like so:

{{cite web |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |title=JPL Small-Body Database Browser |query=Borisov |website=JPL Solar System Dynamics}}

"JPL Small-Body Database Browser", query: Borisov. JPL Solar System Dynamics.

— UnladenSwallow (talk) 20:34, 6 October 2019 (UTC)

It is generally not advisable to cite search results, as a host of things may get out of sync/change. I would cite a specific entry, and perhaps note it is part of a series in a {{link note}}. 98.0.246.242 (talk) 22:27, 6 October 2019 (UTC)
Well, we have the same situation even with ordinary web pages: a host of things may get out of sync/change. That's why we use archive-urls, which we can use just as well with search results. This particular citation is required to back up the claim of a certain specific number of comets having been discovered (see Gennadiy Borisov), so I can't cite a specific entry. Even if cited each individual entry, that would only "prove" that at least that number of comets have been discovered—it wouldn't prove that exactly that number comets have been discovered. — UnladenSwallow (talk) 23:19, 6 October 2019 (UTC)
Cite web emits metadata consistent with the item cited being a periodical. A database is not a periodical. Therefore we shouldn't use cite web at all for a database. I don't know of any cite xxx template intended for databases. I suggest not using a template at all. Jc3s5h (talk) 23:41, 6 October 2019 (UTC)

───────I looked at Chicago Manual of Style 17th ed., "Scientific Databases", p. 14.257. It gives this example of a footnote and bibliography entry that are similar to what you seek:

1. NASA/IPAC Extragalactic Database (object name IRAS F00400+4059; accessed April 6, 2016), http://ned.ipac.caltech.edu/.

[following bibliography entry has hanging indent in original]

NASA/IPAC Extragalactic Database (object name IRAS F00400+4059; accessed April 6, 2016), http://ned.ipac.caltech.edu/.

Jc3s5h (talk) 00:04, 7 October 2019 (UTC)

1. Cite web emits metadata consistent with the item cited being a periodical. A database is not a periodical. Therefore we shouldn't use cite web at all for a database. The Template:Cite web documentation says something entirely different: This Citation Style 1 template is used to create citations for web sources that are not characterized by another CS1 template. From which it follows that {{cite web}} is suitable for citing a database. Either your reasoning is wrong, or the documentation is wrong. 2. Thanks for the relevant CMOS excerpt. — UnladenSwallow (talk) 01:23, 7 October 2019 (UTC)
The documentation is not wrong. To suggest that {{cite web}} should only be used to cite periodicals is an entirely novel interpretation that has nothing to do with how the template's usage was understood to apply, since its inception. 98.0.246.242 (talk) 01:30, 7 October 2019 (UTC)
Then the documentation and the code are inconsistent with each other. To avoid error messages (currently hidden) one must specify a website title, and another title. The former is treated by the code like a journal title, and the latter is treated like an article title. The titles are marked in the metadata as journal and article titles respectively. Jc3s5h (talk) 01:54, 7 October 2019 (UTC)
If that's what the code does, then it's clearly wrong. I've seen {{cite web}} used for all kinds of sites that were not journals. In fact, I've never seen it used for a journal. — UnladenSwallow (talk) 02:13, 7 October 2019 (UTC)
Editors use `{{cite web}}` as a catch-all for everything. Editor Jc3s5h is incorrect: To avoid error messages (currently hidden) one must specify a website title... The website-required-check has been wholly disabled per this discussion at WP:AN.
Trappist the monk (talk) 13:19, 7 October 2019 (UTC)

The sync problem with search queries in citations is not about the results, primarily. Queries do not provide consistent targets, and the query syntax itself may change. Apart from that they are susceptible to bias: they can be structured with a bias towards a desired set of results. The cited material must have an unambiguous, singular verification target. As mentioned previously, if you want to cite a set of entries in a database, cite the first one, and optionally add a note that this is one of several such entries. I would also take a look at {{cite techreport}}. 98.0.246.242 (talk) 00:31, 7 October 2019 (UTC)

Queries do not provide consistent targets… In general case, yes. In this particular case, even if Gennady Borisov discovers another 10 comets, and the Small-Body Database changes its output, the citation will still be correct, because the relevant sentence in the article says "Between 2013 and 2017, he has discovered seven comets" and the database output will always list 7 comets discovered between 2013 and 2017. The Small-Body Database is not like Google Search: it doesn't change its output rapidly, it's not user- or location-sensitive, it shows all matching results, and its output changes are incremental, i.e. new results are appended to the bottom of the output list. Apart from that they are susceptible to bias: they can be structured with a bias towards a desired set of results. The same can be said about citations in general: they can be selected with a bias towards desired conclusions. That doesn't mean that citations should not be used. Similarly, the fact that someone may use a biased query does not mean that queries should not be used. In fact, queries are better in this regard, because a query can always be inspected and is executed automatically by a machine, so a biased query would be immediately visible, while the process of citation selection by an editor is completely opaque and cannot be inspected by other editors. I would also take a look at {{cite techreport}}. I don't quite understand how to apply {{cite techreport}} in this case and would be grateful if you could expand on this. — UnladenSwallow (talk) 02:09, 7 October 2019 (UTC)
An article's positional bias is irrelevant to citations. A verifiable citation from a reliable source that supports a biased claim in an article is a good citation. However searches introduce potential confirmation bias in the structure of the citation itself. Remove this potential source of bias by not citing searches, which consist of more-or-less arbitrarily formatted questions. But apart from that, the item that supports the claim in an article must be unambiguous and consistent. We have no way of knowing if a certain query will consistently produce the same result. You may believe that a particular query is stable and well-formatted, but in the meantime you introduce an additional verification condition: I now have to verify whether the query itself is appropriately formatted, even before I arrive at the claimed proof. And all of this can, and should, be avoided. In the meantime, you are free to use any search template in support of your claim in a footnote, not a citation, as long as you expressly declare the search. 72.43.99.138 (talk) 14:14, 7 October 2019 (UTC)

To add, it seems to me that citing every record cannot be avoided if the information about the number of comets etc. is included. 98.0.246.242 (talk) 00:38, 7 October 2019 (UTC)

The way it works now is that https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov shows 7 comets discovered between 2013 and 2017 (entries starting with "C", the numbers after "C" are years of discovery) and all of them have "Borisov" in parentheses, which means that Borisov is the discoverer (the standard scheme of designating comets). Therefore, this output is enough to back up the claim that Borisov is the discoverer of exactly 7 comets (not less, not more) between 2013 and 2017. JPL's Small-Body Database is an authoritative source in astronomy. — UnladenSwallow (talk) 02:25, 7 October 2019 (UTC)
I don't dispute the reliability of the source, and I wish I could think of some way to present this better. There have been discussions about grouping citations from the same source in the past, but I don't think they went anywhere. The only other option that comes close would be a complicated application of {{harvc}}. It may be better to write your own, non-templated citation. 72.43.99.138 (talk) 15:11, 7 October 2019 (UTC)

Isn't there any other reliable source that aggregates the information? 98.0.246.242 (talk) 00:40, 7 October 2019 (UTC)

There's Minor Planet Center (https://minorplanetcenter.net), through which all the information about minor planets and comets flows, but it doesn't maintain explicit lists of who discovered what. There's a List Of Observatory Codes, but you can't click on an observatory to see all objects discovered there. So the astronomers use JPL's Small-Body Database Browser for this (among other reasons). It's used quite extensively on Wikipedia, hence my interest in finding/devising a proper way to format its citations. — UnladenSwallow (talk) 02:40, 7 October 2019 (UTC)
UnladenSwallow, we have a lot of specialized reference templates that cite databases. See {{Ethnologue22}} and {{SIMBAD link}}. Follow what they do. In the template code. They set up the url to include the search parameters. So you can write:
• `{{cite web |title=Borosov |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |work=JPL Solar System Dynamics |publisher=Jet Propulsion Laboratory |accessdate=6 October 2019}}`
• "Borosov". JPL Solar System Dynamics. Jet Propulsion Laboratory. Retrieved 6 October 2019.
• `{{cite web |title=11016 Borisov (1982 SG12) |url=https://ssd.jpl.nasa.gov/sbdb.cgi?ID=a0011016 |work=JPL Solar System Dynamics |publisher=Jet Propulsion Laboratory |accessdate=6 October 2019}}`
StarryGrandma (talk) 02:50, 7 October 2019 (UTC)
1. Can't use your first example as the Template:Cite web documentation says that the title parameter must contain the page title, not the search string. 2. Following the example of Ethnologue, the citation could look like this:
"Borisov" at JPL Small-Body Database
Or, perhaps:
Search: "Borisov" at JPL Small-Body Database
— UnladenSwallow (talk) 03:14, 7 October 2019 (UTC)
Including `|title=JPL Small-Body Database Browser` as the title is also unsatisfactory as the page content changes according to the search parameters. What is the point of emitting the correct metadata for `|title=` when referring to a page with uncertain content. It only makes sense to refer to the naked search page, i.e. without a search. `|title=` needs to be accompanied by something else if it is to be useful or have an alternative parameter that can be linked without emitting metadata. 06:06, 7 October 2019 (UTC)
|title= needs to be accompanied by something else if it is to be useful… Hence my query parameter proposal above. The metadata output can be modified accordingly to make sense. — UnladenSwallow (talk) 08:39, 7 October 2019 (UTC)
I note that the examples in the OP don't include an acecss date, which they surely should. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:32, 10 October 2019 (UTC)
Thanks, Andy. I have omitted |access-date= in this post for brevity. I always include it in citations I add to articles. — UnladenSwallow (talk) 00:54, 11 October 2019 (UTC)
It's also worth noting that "JPL Solar System Dynamics" isn't a magazine, newspaper or journal. It's an organization, and in any mainstream footnoting style, such as Chicago Manual of Style, ALA or MLA, it's not italicized. In any mainstream form, it would go under "publisher=". --Tenebrae (talk) 21:52, 15 October 2019 (UTC)
1. The first sentence that greets the visitors to the website is: Welcome to the JPL solar system dynamics web site. The header above says: JPL Solar System Dynamics. It's pretty clear that "JPL Solar System Dynamics" is the name of the website, not the publisher. The publisher is "Solar System Dynamics Group", as can be inferred from the footer: This site is maintained by JPL's Solar System Dynamics Group. Therefore, "JPL Solar System Dynamics" goes into website, not publisher. 2. I share your displeasure at the {{cite web}} automatically italicizing the website parameter. As you can see from the discussion above, I am against it. However, that's what the template is currently doing. — UnladenSwallow (talk) 14:24, 26 October 2019 (UTC)
I think we're in general agreement. I'm seeing the title at the top of page at that website as Solar System Dynamics, published by the NASA Jet Propulsion Laboratory, specifically the division titled Solar System Dynamics Group. Similarly the database/aggregator Rotten Tomatoes is the publisher of, say, the critics aggregation for Zombieland: Double Tap. Yet because RT has a parent company which editors put "publisher=," editors then put RT in the "website=" field even though RT is not italicized in citations anywhere else in the mainstream. It's like italicizing Marvel Comics when no one else does simply because its parent company is Disney.
It's a growing issue that a "cite organization" template would solve. That way we have "organization=" and, if someone wants to be didactic, "parent=". --Tenebrae (talk) 18:50, 27 October 2019 (UTC)

## Two separate publication dates in a single citation

In Schröder–Hipparchus number, we have a citation

{{citation|title=Enumerative Combinatorics|first=Richard P.|last=Stanley|authorlink=Richard P. Stanley|publisher=Cambridge University Press|year=1997, 1999}}

that accurately describes the publication dates of this book: Volume I was published in 1997, Volume II in 1999, and after the end of the template the rest of the footnote refers to several pages from each volume. (This is citation style 2, not CS1, but it makes no difference for the issue at hand). Although the template formats this correctly, it also throws a reference error because of the date format:

Stanley, Richard P. (1997, 1999), Enumerative Combinatorics, Cambridge University Press Check date values in: `|year=` (help)

Trying to be helpful, Yiosie2356 "fixed" the error by changing it to 1997–1999, which indeed is no longer marked by the citation template as being an error but is in fact more erroneous than the original citation. The book was not published over a range of dates, it was published in two volumes on two separate and specific dates, and the original citation reflected that while the "fixed" version does not. Is there some way to continue to use the citation template to get both the correct dates and no error? Or is this one of the many recent instances where the increasing rigidity of the template conflicts with the flexibility of real-world citations and forces us to format the citation manually? For instance, {{harvs}} has a `|year2=` parameter; maybe we could consider having a similar parameter in the citation templates themselves? —David Eppstein (talk) 01:08, 9 October 2019 (UTC)

Is there a reason why citing Volume I and Volume II separately wouldn’t work? I’m not sure I see the benefit to a single citation for both volumes. Umimmak (talk) 01:53, 9 October 2019 (UTC)
Is there a reason why a citation to a two-volume work should be forced to be artificially split into two separate but almost equal citations? Or, is there a reason why a citation to a two-volume work should be forced to be artificially split into two separate, but almost equal, citations? Does the repetition add any value to the reader? Is doing it that way better for readers? Or is your suggestion purely for the benefit of template-software authors? Or maybe you think that we should prioritize ease of coding over ease of use? —David Eppstein (talk) 02:58, 9 October 2019 (UTC) —David Eppstein (talk) 02:58, 9 October 2019 (UTC)
The pages cited come from two separate volumes, with two separate dates of publication, two separate ISBNs, two separate chapters, two separate DOIs, etc. They don’t come from the same place, so they shouldn’t be forced together in a single citation. Is there any sort of precedent for citing multiple pages from multiple volumes in a single citation? Umimmak (talk) 08:06, 9 October 2019 (UTC)
As Umimmak says: two separate volumes. They are physically separate, and published separately. The artificiality is in trying to make one citation cover two separate sources. ♦ J. Johnson (JJ) (talk) 21:08, 11 October 2019 (UTC)
David, two points. First, with respect to:

Is there a reason why a citation to a two-volume work should be forced to be artificially split into two separate but almost equal citations?

Did you really mean two citations, or two references? Because they are not the same thing. One possible solution might be two citations in one reference.[1] Or why not take advantage of the fact that any text can be placed between <ref> tags, and do something creative, that gives verifiable citations as well as being user-friendly at the same time; perhaps something like this;[2] or whatever makes sense in the individual case. This is far more adaptable than trying to get the software to handle cases that haven't been dreamed of yet. Mathglot (talk) 20:05, 13 October 2019 (UTC)
Good point. ♦ J. Johnson (JJ) (talk) 21:23, 15 October 2019 (UTC)

Relatedly, the documentation says "Sources are at liberty to use other ways of expressing dates, such as "spring/summer" or a date in a religious calendar; editors should report the date as expressed by the source." However, it appears to be false that freeform dates are allowed. Maybe we should either remove this claim or clarify what types of dates are allowed? For instance {{citation|title=Persian calendar|title-link=Iranian calendars|date=1398 SH}} does not work: Persian calendar, 1398 SH Check date values in: `|date=` (help). —David Eppstein (talk) 03:06, 9 October 2019 (UTC)

It's not a false claim; it's an indication that the date should be expressed in a way that readers can be confident they found the right source once they locate a source that might be the right one, even if that means not using a template. I clarified that on the help page. Jc3s5h (talk) 03:53, 9 October 2019 (UTC)

References

1. ^ Stanley, Richard P. (1997). Enumerative Combinatorics. 1. Cambridge University Press.,
——— (1999). Enumerative Combinatorics. 2. Cambridge University Press.
2. ^ Stanley, Richard P. Enumerative Combinatorics. in two volumes. Cambridge University Press. Volume I: Cambridge (1997); volume II: Kalamazoo (1999).

## end pipe not displaying

In

The final |, generated though `{{!}}`, is missing. The title should display as ... direct measurement of |Vtb|. Headbomb {t · c · p · b} 01:59, 13 October 2019 (UTC)

That is normal. The module interprets the resulting pipe as an end-of-field character. You could try <nowiki>. 98.0.145.210 (talk) 12:45, 13 October 2019 (UTC)
Another option would be using U+200D (HTML `&#8205;` · `&zwj;`) after the pipe template magic word. In the original citation, the module sees two pipes in succession, therefore it ignores the additional. 72.43.99.138 (talk) 14:06, 13 October 2019 (UTC)
That is not normal {{!}} is specifically designed to render, not be treated as yet another | delimited. See e.g. `{{xt|{{!}}V<sub>tb</sub>{{!}}}}` which renders exactly as intended, e.g. |Vtb|. — Preceding unsigned comment added by Headbomb (talkcontribs) 18:33, 13 October 2019 (UTC)
I agree. Using the standard workaround for vertical bars in templates should work. It is a bug that it does not. I note, however, that even without that issue the title is not quite formatted correctly. If you look at the original source, ${\displaystyle |V_{tb}|}$  is a mathematics formula in which the letters are all italicized. So it would be rendered better as
• {{cite journal |last=Abazov |first=V.M. |collaboration=[[DØ Collaboration]] |display-authors=etal |year=2007 |title=Evidence for production of single top quarks and first direct measurement of [itex]|V_{tb}|[/itex] |journal=[[Physical Review Letters]] |volume=98 |issue=18 |pages=181802 |doi=10.1103/PhysRevLett.98.181802 |arxiv=hep-ex/0612052 |bibcode=2007PhRvL..98r1802A |pmid=17501561 |hdl=10211.3/194387}}
• Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of ${\displaystyle |V_{tb}|}$ ". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561.
David Eppstein (talk) 18:44, 13 October 2019 (UTC)
The italics thing is besides the point. |Vtb| would equally fail to render correctly. Headbomb {t · c · p · b} 02:50, 14 October 2019 (UTC)
And it would not render with the proper serif font for math variables, again. In mathematical formulas, the correct font matters. Using a different font can often mean that you are referring to a completely different variable, or something undefined. If you don't want to use [itex], the other alternative for getting something close to acceptable mathematical formula rendering is the {{math}} series of templates, which need the {{!}} workaround but otherwise work: Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of |Vtb|". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561. — Preceding unsigned comment added by David Eppstein (talkcontribs) 03:31, 14 October 2019 (UTC)
Again, that's besides the point. And variables certainly don't have to be rendered in serif fonts. Headbomb {t · c · p · b} 05:06, 14 October 2019 (UTC)
If you want to preserve the meaning in a mathematical text where the author is using the default serif italic for one meaning and \mathsf (LaTeX-style sans-serif) for a different meaning (and maybe bold upright and outlined upright for other meanings), then yes, they do. If you're writing something where you're choosing your own variable names, then you're free to make them sans, but they still need to stay consistently formatted rather than inheriting formatting from the surrounding text. —David Eppstein (talk) 05:36, 14 October 2019 (UTC)
Use of `[itex]...[/itex]` is problematic because MediaWiki took away our ability to see the underlying content of the tag. The content of `[itex]...[/itex]` is rendered visually as an image; logged in editors can select one of three styles according to a setting in their Special:Preferences. When MediaWiki took away our ability to see the image's underlying makeup, we lost the ability to render any sort of meaningful metadata. All that Module:Citation/CS1 sees is a math stripmarker that looks something like this: `?'"`UNIQ--math-0000001C-QINU`"'?` (the '?' characters represent the delete character). Because we can no longer see what that stripmarker represents, all title metadata for titles with `[itex]...[/itex]` in them get an error message (`MATH RENDER ERROR`) in place of the `[itex]...[/itex]` content. So, for the example template, cs1 produces this article title metadata:
`&rft.atitle=Evidence+for+production+of+single+top+quarks+and+first+direct+measurement+of+MATH+RENDER+ERROR`
Cannot do anything about that until Lua is allowed access to the content of `[itex]...[/itex]` tags. See the phabricator ticket.
Trappist the monk (talk) 13:34, 14 October 2019 (UTC)
Doesn't seem like this ticket will be resolved any time soon. 72.43.99.138 (talk) 14:21, 14 October 2019 (UTC)
Interesting. Using {{pipe}} instead works as it should, so this has something to do with template expansion vs magic word rendering. It seems that the magic word is processed after the field has been formatted (with quote marks). If that is the case, instead of the module rendering `|"{delimiter}` it renders `"{delimiter}{delimiter}`. 98.0.246.242 (talk) 01:44, 14 October 2019 (UTC)
EDIT: or maybe not. Since the magic word works properly when followed by a zero width joiner, my idea that it is processed after the quote mark formatting is a dud. Something else is the culprit. 98.0.246.242 (talk) 01:48, 14 October 2019 (UTC)
Use of `{{pipe}}` is discouraged because it produces improper metadata.
Trappist the monk (talk) 13:34, 14 October 2019 (UTC)
Metadata is irrelevant. I was only using {{pipe}} to illustrate that the template expands properly inside the `|title=` field, unlike the magic word/variable, which apparently trips when display format is applied on the parameter. 72.43.99.138 (talk) 14:08, 14 October 2019 (UTC)
Metadata is relevant to those who consume these citations via the metadata.
Trappist the monk (talk) 15:14, 14 October 2019 (UTC)
There may be some sort of interaction between the magic word/variable {{!}} and the `script_concatenate` function in Module:Citation/CS1 (lines 572-580). The {{!}} variable works as it should when inserted in other fields, but not for `|title=` (and its various aliases). The function that formats `|title=` (`format_chapter_title`) uses the function `script_concatenate`. See line 714, and the code comment: -- <bdi> tags, lang atribute, categorization, etc; must be done after title is wrapped. This also appears in section "format main title" starting in line 3110 (the pertinent statements are in lines 3126-3140). So `|title=` formatting may have something to do with the disappearing variable after all? 72.43.99.138 (talk) 13:24, 14 October 2019 (UTC)
Fixed in the sandbox:
WT `{{cite journal |pmid=17501561 |last=Abazov |year=2007 |collaboration=[[DØ Collaboration]] |pages=181802 |first=V.M. |journal=[[Physical Review Letters]] |issue=18 |title=Evidence for production of single top quarks and first direct measurement of |Vtb| |arxiv=hep-ex/0612052 |volume=98 |doi=10.1103/PhysRevLett.98.181802 |bibcode=2007PhRvL..98r1802A |hdl=10211.3/194387 |display-authors=etal}}` Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of |Vtb". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561. Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of |Vtb|". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561.
Trappist the monk (talk) 13:34, 14 October 2019 (UTC)
Cool. So the module is treating the variable as a link, and is formatting accordingly, correct? 72.43.99.138 (talk) 13:55, 14 October 2019 (UTC)
Not quite. Because `is_wikilink(str)` in the live module does not return when it discovers that `str` is not a wikilink, the live module assumes that trailing (and / or leading) pipes in `D` and `L` are an acceptable form of wikilink; these all work:
`[[Abraham Lincoln]]`Abraham Lincoln (no pipes)
`[[|Abraham Lincoln]]`Abraham Lincoln (leading pipe)
`[[Abraham Lincoln|]]`Abraham Lincoln (trailing pipe)
`[[Abraham Lincoln|Abe|]]`Abe| (trailing pipe)
In this particular case, the `is_wikilink()` function is called because journal titles need to be kerned if the title's first and / or last character is some form of quote mark. When the title is wikilinked, the leading / trailing quote marks may be inside the display portion of the wikilink. It occurs to me that `L` can never have a leading pipe so `L = L and mw.text.trim (L, '%s|');` is pointless. I have disabled that line while I think about it and revised the early exit test.
Trappist the monk (talk) 15:14, 14 October 2019 (UTC)
Indeed. I noticed you commented it out in your latest sandbox edit. And as indicated the problem seemed peculiar to the parsing of {{!}}. But, since the `if not` condition you added seems to work out, I guess this is resolved in some fashion. 172.254.98.154 (talk) 17:42, 14 October 2019 (UTC)

## "Extra punctuation" maint message that I can't figure out

I found this cite web template in George Washington:

WT `{{cite web |access-date=November 1, 2018 |date=2017 |publisher=U.S. Army Center of Military History |title=How Many U.S. Army Five-star Generals Have There Been and Who Were They? |url=https://history.army.mil/html/faq/5star.html |ref=CITEREF"Five-star_Generals,_2017"}}` "How Many U.S. Army Five-star Generals Have There Been and Who Were They?". U.S. Army Center of Military History. 2017. Retrieved November 1, 2018.CS1 maint: extra punctuation (link) "How Many U.S. Army Five-star Generals Have There Been and Who Were They?". U.S. Army Center of Military History. 2017. Retrieved November 1, 2018.CS1 maint: extra punctuation (link)

I'm seeing "CS1 maint: extra punctuation". At the linked help page, I see "The test that adds articles to this category is currently limited to checking for trailing commas, colons, or semicolons (`,:;`)."

I do not see any trailing `,:;` in this citation.

Removing the `|ref=` parameter and its value appears to eliminate the maintenance message:

WT `{{cite web |access-date=November 1, 2018 |date=2017 |publisher=U.S. Army Center of Military History |title=How Many U.S. Army Five-star Generals Have There Been and Who Were They? |url=https://history.army.mil/html/faq/5star.html}}` "How Many U.S. Army Five-star Generals Have There Been and Who Were They?". U.S. Army Center of Military History. 2017. Retrieved November 1, 2018. "How Many U.S. Army Five-star Generals Have There Been and Who Were They?". U.S. Army Center of Military History. 2017. Retrieved November 1, 2018.

...but I do not know why. What am I missing? – Jonesey95 (talk) 20:57, 15 October 2019 (UTC)

Because this is how the `{{sfnref}}` is rendered:
`{{sfnRef|"Five-star Generals, 2017"}}``CITEREF&quot;Five-star_Generals,_2017&quot;` → CITEREF"Five-star_Generals,_2017"
Are the quote marks necessary? Probably not.
Trappist the monk (talk) 21:33, 15 October 2019 (UTC)
The format of {{sfnref}} is non-standard in the example. I would label the anchor to follow the conventions of short refs (Author-Year) or if there is no author, Work-Year or (distant 3rd, and not unambiguous) Title-Year. If the last has to be used, there may be a case for additional markup depending on the work type. 98.7.199.92 (talk) 00:31, 16 October 2019 (UTC)

## ISBN required or not? (And a small problem with this talk page)

In Wikipedia:Citing sources#Books, it lists ISBN as optional, below a list of other fields that are very often not included (at least in what I've seen) implying that this field is not particularly important. Yet in Template:Cite book/doc under "Brief instructions/notes" for isbn, it states "always include ISBN, if one has been assigned ", with one of only two bold parts in the whole table. Well which is it then? Is it optional, or required? And if something is optional but strongly encouraged, is it really appropriate to present it this way in the documentation?

On an unrelated note, the notice at the top of this page needs to be changed or removed. It states "This is the talk page for discussing improvements to the Citation Style 1 page.", but as mentioned AFTER that, (and as one would find if clicking talk from a different page) this is actually a centralised discussion page for several pages, so I feel this needs to be removed as it is confusing (well it was to me at least!) A7V2 (talk) 22:42, 18 October 2019 (UTC)

ISBN is not required, as many books do not have ISBNs. Don't overlook that the "always include" is contingent on "if one has been assigned". And I would consider the "always include" as more of an injunction – as in "you should do this" — whereas "require" (as you phrased it) is stronger, and implies that there is some kind of enforcement. That we don't have. ♦ J. Johnson (JJ) (talk) 23:13, 18 October 2019 (UTC)
I've reordered the headers at the top of the page and tweaked the talk page header a bit. `{{Talk header}}` does not allow for a fully custom title.
Were ISBN required, cs1|2 would emit a red error message telling you to include the ISBN; cs1|2 doesn't, so ISBN is not required. When an ISBN is available, you should provide it because readers can use it to link through Special:BookSources to various on-line places where the book might be found. All en.wiki editors should do this in consideration of our readers
Trappist the monk (talk) 23:45, 18 October 2019 (UTC)
Thankyou for your replies. I'm well aware that not all books have ISBNs, I have myself cited books which don't. However I just think it's odd that on Wikipedia:Citing sources#Books the publisher field is not labelled optional (when it certainly is, I rarely see a book cited with the publisher filled in), and yet ISBN, which ideally would be included where available, is listed as optional. Maybe really I should take this to Wikipedia talk:Citing sources and suggest that it should be changed to something like (optional, but highly encouraged if available)?
Also given what you (Trappist the monk) say about the standard template not allowing for this customisation I think the change you made is fine. A7V2 (talk) 00:01, 19 October 2019 (UTC)
CS#Books says "typically includes", not "required". --Izno (talk) 16:12, 19 October 2019 (UTC)
But then isn't that even worse? Publisher and edition are clearly optional as well (since in practice they are often not included), but ISBN is singled out there as being the only "optional" field in a list of things only typically included. What I'm getting at is that the two pages send (in my mind) contradictory messages about expectations/requirements/etc for including ISBN when available. A7V2 (talk) 02:22, 21 October 2019 (UTC)
If `|page=` (or `|ref=harv`) is included it should be required to have either `|isbn=` or `|publisher=` + `|year=` - otherwise it is impossible to know which edition it is since page numbers can change depending on edition, many books have multiple editions/publishers/printings/media. -- GreenC 16:27, 19 October 2019 (UTC)
No. `|Edition=` is used to specify edition, and year often works to the same purpose. In the extremely rare cases where neither of those is sufficient to distinguish between two near identical documents that differ in pagination the ISBN might help. But making ISBN (or publisher) required merely because a page is given is ludicrous. ♦ J. Johnson (JJ) (talk) 22:16, 19 October 2019 (UTC)

## Format for author name suffixes?

What's the proper format for name suffixes like Jr. or III?--Sturmvogel 66 (talk) 16:36, 19 October 2019 (UTC)

Does MOS:JUNIOR help?
Trappist the monk (talk) 16:48, 19 October 2019 (UTC)
What I’ve been doing is have the surname be in `|last=` and then the first name and any suffixes in `|first=` separated with a comma, yielding examples like Doe, John, Sr. or Deer, Jason, III. Umimmak (talk) 17:51, 19 October 2019 (UTC)
Almost what I do, but per MOS:JR "Omission of the comma before Jr. or Sr. (or variations such as Jnr) is preferred." So I write `|last=Doe` `|first=John Sr.` or `|last=Deer` `|first=Jason III` etc, yielding "Doe, John Sr." or "Deer, Jason III". —David Eppstein (talk) 18:32, 19 October 2019 (UTC)
The preference in MOS:JR for omitting the comma before Jr. and Sr. only applies when the name is just in running text, not when it's inverted as in citations. See, e.g., CMoS 17 §6.43 for a style guide with similar advice: Commas are not required with Jr. and Sr., and they are never used to set off II, III, and the like when these are used as part of a name. In an inverted name, however (as in an index; see 16.41), a comma is required before such an element, which comes last. Umimmak (talk) 21:24, 19 October 2019 (UTC)
You are incorrect. Try reading a little farther down in MOS:JR: "When the surname is shown first, the suffix follows the given name, as Kennedy, John F. Jr." And the fact that the previous paragraph is the only one in the section that is explicitly stated as being for running text is a strong clue that the rest of the section does not have that restriction. —David Eppstein (talk) 22:03, 19 October 2019 (UTC)
Like Unimmak and the CMS say: with inverted names – such as in citations – include a comma. E.g.: `|first=John, Sr.`; `|first=Jason, III`. ♦ J. Johnson (JJ) (talk) 22:28, 19 October 2019 (UTC)
We have our own MOS. It is different from the CMS. And this is one of the ways in which it is different. It says not to use the comma here. —David Eppstein (talk) 22:42, 19 October 2019 (UTC)
(edit conflict) I’ve done some digging through the archives, and as much as I disagree with this, it seems this particular issue was discussed at Wikipedia talk:Manual of Style/Biography/2016 archive#A slight expansion of MOS:JR, although no one in that discussion seemed to check for precedent from other style guides. I’ll confess I overlooked the sentence David Eppstein quoted. Umimmak (talk) 22:43, 19 October 2019 (UTC)
Thanks to you all.--Sturmvogel 66 (talk) 00:01, 20 October 2019 (UTC)
Agreed with J. Johnson (and CMoS and various other sources). While the worlds' publishers are not entirely uniform on how to do this, a pattern like "Johnson, J.; Wales, Jimmy; Davis, Sammy, Jr." appears to be the most common, and it's what most of our own editors seem to be doing internally. In 14+ years here (under various usernames), no one's ever reverted me normalizing to the "Surname, GivenName[s], Suffix" format.  — AReaderOutThatawayt/c 22:42, 20 October 2019 (UTC)
The proper place to discuss proposed changes to this portion of WP's Manual of Style is Wikipedia talk:Manual of Style/Biography, not here. – Jonesey95 (talk) 23:43, 20 October 2019 (UTC)

## Language description needed for elements of cite

I'm working on articles employing Greek, containing quoted ancient or modern text, etc. Not surprisingly, the modern quotes actually have cites. Unfortunately (as likely is true for other major languages?) parts of those cites contain Greek language text, either wholly or in part. In one cite I might find "|publisher=Έκδοσις Μεγάλης Στρατιωτικής και Ναυτικής Εγκυκλοπαιδείας". In another cite might be "|author=ΒΙΚΤΩΡΑΣ ΝΕΤΑΣ". Another might have "|title=Πολυτεχνείο: Η δίκη των Συνταγματαρχών".

I see in the documentation some reference to different forms for specific cite parts, e.g.

• |title=Tōkyō tawā |script-title=ja:東京タワー |trans-title=Tokyo Tower
• |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower

and of course there is "language: The language in which the source is written" to describe the text within the work/edition as a whole.

Is there a general mechanism to say "here is the author's name and it is in Greek"? Or publisher? Or we have only the original title in the original Greek? If the purpose of cites is to sort and qualify the identifying qualities, shouldn't language be one of those qualities?

Note that this is separate from the usage in something like

|quote=«Αποδέχομαι την συμμετοχήν μου ...

where one is able to insert language qualification inline, like so:

|quote={{lang|el|«Αποδέχομαι την συμμετοχήν μου ...}}

The other example cite parts mentioned above get quite sick if language templates are inserted in their texts.

While someone might say that 'everyone' could recognise these as Greek, and so no qualification is needed, how are you on your Coptic? - {{lang|cop|ⲠⲚⲞⲨⲦⲈ ⲠϢⲎⲢⲈ ⲚⲞⲨⲰⲦ}} Shenme (talk) 02:44, 21 October 2019 (UTC)

This doesn't answer all of your questions, but according to MOS:ROMANIZATION we should transliterate author and publisher names into the Roman alphabet, not keep them in Greek. —David Eppstein (talk) 03:28, 21 October 2019 (UTC)
With the exception of `|trans-map=`, all `|trans-<param>=` parameters have a matching `|script-<param>=`. These are the parameters for which language has been deemed important.
base param trans-param script-param
article trans-article script-article
chapter trans-chapter script-chapter
contribution trans-contribution script-contribution
entry trans-entry script-entry
journal trans-journal script-journal
magazine trans-magazine script-magazine
map (sandboxed) trans-map
newspaper trans-newspaper script-newspaper
periodical trans-periodical script-periodical
section trans-section script-section
title trans-title script-title
website trans-website script-website
work trans-work script-work
`|language=` accepts a comma-separated list of languages; not just one language as you state in your post. There is nothing in cs1|2 to say that author / editor / ... names are written in a particular script. Romanizing names per MOS:ROMANIZATION might be the appropriate thing to do until the name-list parameters are (if they ever are) modified to support a `|trans-<param>=` form.
Do not use `{{lang}}` in any of the parameters that contribute to the citation's metadata. The parameters are listed on all cs1|2 template doc pages; see for example: Template:Cite book#COinS metadata is created for these parameters.
I will look into what is needed to support `|script-map=`.
Trappist the monk (talk) 14:02, 21 October 2019 (UTC)
I have added `|script-map=` to the sandbox:
`{{Cite map/new |map=Map |trans-map=Trans Map |script-map=zh:Script Map |title=Title}}`
"Map" Script Map [Trans Map] (Map). Title.
Trappist the monk (talk) 16:25, 21 October 2019 (UTC)
until the name-list parameters are (if they ever are) modified to support a |trans-<param>= form I'm sure you meant to say |script-<param>= form, as translating names (trans- prefix) doesn't make sense. (Unfortunately, "trans" can be interpreted as both "translation" and "transcription", which leads to confusion; it would be better to use transl- .) — UnladenSwallow (talk) 15:01, 26 October 2019 (UTC)

## Date format - "Midsummer 1911"

The instructions state that a journal's own date format should be followed - in this case, "Midsummer 1911". However that generates a red error. What should be done? Andy Dingley (talk) 10:48, 21 October 2019 (UTC)

I doubt any journal would have such publication date. It is very likely that this is an issue "name", in which case it can be inserted in the `|issue=` field. Journals with such seasonal dates usually provide an actual publication schedule near the editorial masthead or elsewhere in front matter. Look for text like "Published the first week of July", or similar, and cite the date appropriately. 69.94.58.75 (talk) 11:10, 21 October 2019 (UTC)
"I doubt that" is WP:OR and is not how we should treat external metadata. WIKINEOLOGISMs are bad enough as it is. It might even be right, but it's not how we should treat metadata which has been given to us from an external source.
The magazine here is The Shipbuilder, which AFAICS was quarterly with additional special subject-themed issues from time to time (costing several times the usual cover price, and presumably thicker), such as this. Now "Special Issue 1911" would be a reasonable description of it, but that doesn't fit with `|date=` either. 'June 1911' is no good because that would have been the regular quartely issue, a different magazine. Here's an archive source for it, using 'Midsummer 1911' https://www.gjenvick.com/OceanTravel/Titanic/25-ImageLibrary/TheShipbuilder-01-WhiteStarLine.html There's a cover scan which seems to describe it as "Special Issue, 1911", because there was often a desire to make these special issues less time-specific, so giving them a longer sales life. Andy Dingley (talk) 12:15, 21 October 2019 (UTC)
This is about this citation at Arrol Gantry? Do you have a copy of that periodical in hand? If not, then it would appear to me that you are citing the Gjenvick-Gjønvik Archives website so perhaps the citation should read:
`{{Cite web |website=Gjenvick-Gjønvik Archives |title=Titanic Images - The Shipbuilder - 2: Harland & Wolff |at=Fig. 3: Plan of the Queen's Island Works |access-date=2019-10-21 |url= https://www.gjenvick.com/OceanTravel/Titanic/25-ImageLibrary/TheShipbuilder-02-HarlandAndWolff.html}}`
"Titanic Images - The Shipbuilder - 2: Harland & Wolff". Gjenvick-Gjønvik Archives. Fig. 3: Plan of the Queen's Island Works. Retrieved 2019-10-21.
Trappist the monk (talk) 13:22, 21 October 2019 (UTC)
That's an awful citation. It presents the archive as if they're the authors. It also hides the real source, making it hard for a future editor to find alternative routes to the real source, should the website disappear in the future. Nor does it answer the question. Andy Dingley (talk) 14:17, 21 October 2019 (UTC)
I'm confused. On that web page, the cover of the issue clearly shows the date as "1911" and the issue as "Special Number" (note: not "Special Issue", text possibly invented by the editor above; be careful out there!). I see "Midsummer" only in the text of the web page, so it might be a word that was invented for the web page. Unless I had the issue in hand and could verify I would use "year=1911" and "issue=Special Number" or just "issue=Special", because that is what is clearly verifiable from the scans. – Jonesey95 (talk) 14:31, 21 October 2019 (UTC)
Splitting onto `|issue=` might work. Andy Dingley (talk) 14:43, 21 October 2019 (UTC)
The way this is presented, it is not a citation of a magazine. The source here is an online archive. Absent a full citation of a consulted magazine copy, Trappist's citation is the correct way to go about it. And this has nothing to do with authors, who are correctly omitted in Trappist's rendition. 24.105.132.254 (talk) 14:48, 21 October 2019 (UTC)
(edit conflict)
You did not answer my question to you: Do you have a copy of that periodical in hand? WP:SAYWHEREYOUGOTIT always applies. If you do not have a copy of the periodical in hand, you are citing the website. It is not clear to me that the Gjenvick-Gjønvik Archives webpage is a faithful facsimile of the periodical. Sure, the images are, but is the (limited amount) of text directly quoted from the periodical or is it paraphrased by Gjenvick-Gjønvik Archives? Is that all of the text that there is in the periodical? I think not.
You can archive that page at archive.org so that if the Gjenvick-Gjønvik Archives webpage goes away you can fall-back on the archived copy with `|archive-url=` set to the url of that archive and `|url-status=live`.
Alternately, you can cite the magazine itself:
`{{Cite magazine |magazine=The Shipbuilder |volume=VI |issue=Special Number |date=1911 |title=The Builders of the "Olympic" and "Titanic" |at=Fig. 3: Plan of the Queen's Island Works |url= https://archive.org/details/the_shipbuilder_special_numbers_images_201909/page/n197 |via=Internet Archive}}`
"The Builders of the "Olympic" and "Titanic"". The Shipbuilder. Vol. VI no. Special Number. 1911. Fig. 3: Plan of the Queen's Island Works – via Internet Archive.
Trappist the monk (talk) 15:05, 21 October 2019 (UTC)

─────────────────Virtually all citation styles lead off the citation with either the authors' names, or the title of the article (or larger work if not an article). If necessary, the so-called title can be a description devised by the person writing the citation and enclosed in square brackets. But in this case, we can't read the article in The Shipbuilder so we can't name the author, we can't give the exact title of the article, and we can't even give a decent description of the article. I see no choice but to cite the archive rather than the article, although the fact that The Shipbuilder is the original source should be mentioned. Jc3s5h (talk) 15:02, 21 October 2019 (UTC)

Why wouldn't publications be dated Midsummer? There are certainly academic journals that (as an affectation, I think) have other date formats like "Michaelmas". See e.g. The Michaelmas 2017 issue of Clinical Neuroscience (oddly, they also have "Michaelmas" as an issue number rather than a date, so that would probably be allowed by the templates), the Trinity/Michaelmas 2017 issue of Law and Justice. —David Eppstein (talk) 16:30, 21 October 2019 (UTC)
I know why they shouldn't: Midsummer is hemisphere dependent (which is also why periodicals shouldn't use season dates). That such dates aren't a good idea, has never stopped periodicals from using them. cs1|2 can (and does) support named dates, though, at the moment, only one: Christmas. Other named dates can be added if there is sufficient need to do so.
Trappist the monk (talk) 16:44, 21 October 2019 (UTC)
The other reason not to use season dates is that (even assuming Northern Hemisphere) I can never tell whether Winter 2017 should come before or after Summer 2017, because the season boundaries overlap the year boundaries. But still, we should accurately represent what they actually do, not what they should do. —David Eppstein (talk) 17:46, 21 October 2019 (UTC)
This seems like an unnecessary diversion. All public materials are made so (published) at certain date(s), independent of how cute or boring (depending on your perspective) the material's publishers may be. And such material will have the actual publication date or range somewhere, in non-pseudoironic language. It can be rather hard to market or distribute said material otherwise. The actual publication date(s) (that's the objective - as in factual - information) can be found. If one wants to cite properly, one will make some sort of effort to find them. Anyway, they can always ask here if they are lazy. 24.105.132.254 (talk) 18:31, 21 October 2019 (UTC)
In case I was not clear, I am not saying that information such as these special names should not be included in the citation. On the contrary, since that info may be a way to discover the source. I just don't think that these should be `|date=` values. 24.105.132.254 (talk) 18:37, 21 October 2019 (UTC)
• You're confusing "they shouldn't" with "they don't". It's not WP's role to redefine how a journal chooses to identify its issues. Andy Dingley (talk) 19:01, 21 October 2019 (UTC)

## Missing spacing after colons

Is there supposed to be no space rendered after the colon following the parameter denotations `Bibcode` and `doi`? If so, why exactly?--Hildeoc (talk) 14:41, 23 October 2019 (UTC)

Can't say for sure other than that is how `|doi=` has been rendered for a very long time:
WT `{{cite journal |title=Title |doi=10.12345/12345 |journal=Journal}}` "Title". Journal. doi:10.12345/12345. "Title". Journal. doi:10.12345/12345.
Trappist the monk (talk) 15:09, 23 October 2019 (UTC)
2.6 Visual presentation and other representation of DOI names. 24.105.132.254 (talk) 15:35, 23 October 2019 (UTC)
Thanks – also @24.105.132.254! What about Bibcode, then?--Hildeoc (talk) 15:37, 23 October 2019 (UTC)
It doesn't seem that "bibcode" is the identifier's official label. As far as I can tell "ref code" or "bibliographic reference code" is used to refer to the id, again not sure if these are official labels. As a matter of variance, Wikipedia's own {{Bibcode}} adds a hard space before the number. 24.105.132.254 (talk) 15:51, 23 October 2019 (UTC)

## Valid DOI ending in punctuation

Category:CS1 errors: DOI is showing error for doi:10.1130/focus122009.1. because it ends in punctuation (see Paleocene), but it's a valid DOI.  — Chris Capoccia 💬 02:08, 26 October 2019 (UTC)

This is strange. We have not allowed spaces in DOIs or full stops (periods) at the end of a DOI for about five years, but looking at the current version and archived versions of the DOI numbering spec, I do not see a mention of these restrictions. I did a little digging in the archives of this page, and I found the thread where these errors were discussed, but I don't see a rationale for them based on a specification. That said, almost every time a space, terminal period, or en dash exists in a DOI, it is invalid. Maybe we just need to depend on Citation bot to mark DOIs as broken, like this. Thoughts are welcome. – Jonesey95 (talk) 04:56, 26 October 2019 (UTC)
Is this doi really broken? As far as I know, this is the first notice here of a doi that ends with a punctuation character. Are there other dois that end with punctuation characters?
I have reported the dot-less doi to cross ref and invited them to participate in this discussion.
Trappist the monk (talk) 11:55, 26 October 2019 (UTC)
This DOI is functional, in the sense that it resolves correctly. Removing the period results in no link to a web page. – Jonesey95 (talk) 15:05, 26 October 2019 (UTC)
Our article digital object identifier says only that "most legal unicode" characters are allowed in doi strings, and that they are case-insensitive. It says nothing about syntactical restrictions. This appears to be yet another case where something that citations often don't do has been interpreted rigidly by the templates as a hard prohibition. This rigidity makes the templates unnecessarily difficult to use. —David Eppstein (talk) 20:36, 29 October 2019 (UTC)
Apparently we haven't discussed this terminal punctuation thing much. I didn't find any discussion that indicates the why of the terminal punctuation prohibition.
Help talk:Citation Style 1/Archive 4 § doi subthread – original implementation
Help talk:Citation Style 1/Archive 8 § DOI throwing an error – wherein is discussed erroneous inclusion of terminal punctuation
I suspect that the extraneous punctuation tacked on to the end of a valid doi is the reason that we have that error detection in the code. After all, en.wiki editors do add extraneous punctuation to cs1|2 parameter values which is why we now have Category:CS1 maint: extra punctuation‎ (21,375) (currently constrained to `,:;` characters).
We might implement the doubled parentheses markup mechanism to suppress the error message (cs1|2 does not modify the identifier) so, for those obviously rare cases where a trailing dot or trailing comma really is part of the doi identifier, editors might write:
`{{cite journal |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year= 2009 |volume=37 |issue=12 |pages=1147–1148 |doi=((10.1130/focus122009.1.)) |bibcode=2009Geo....37.1147B}}`
Trappist the monk (talk) 13:08, 30 October 2019 (UTC)

## Possible page numbering regression

The documentation for pages= says:

Hyphens are automatically converted to en dashes; if hyphens are appropriate, for example: pp. 3-1–3-15, use `|pages=3{{hyphen}}1{{ndash}}3{{hyphen}}15`

Presumably, that advice used to work, but it no longer appears to (the example below uses `|pages=3{{hyphen}}1{{ndash}}3{{hyphen}}15`):

WT `{{cite journal |journal=Journal |pages=3-1–3-15 |title=Title}}` "Title". Journal: 3-, 1–3-, 15. "Title". Journal: 3-1–3-15.

Did I miss a change that necessitates updating this documentation? Is this related to this recent discussion about large page numbers? – Jonesey95 (talk) 05:11, 26 October 2019 (UTC)

That occurs due to function `hyphen_to_dash` in Module:Citation/CS1 which includes `mw.text.split (str, '%s*[,;]%s*')`. That regards any commas or semicolons as page number separators. The fact that the semicolon is removed from the `&#45;` produced by {{hyphen}} gives the strange result. It seems that was introduced on 29 September 2018 and surrounding the page numbers with double parentheses works. Johnuniq (talk) 06:36, 26 October 2019 (UTC)
Who do we approach to get this fixed? - Chris.sherlock (talk) 20:03, 26 October 2019 (UTC)
Trappist the monk (talk · contribs) is just about the only person that can do maintenance on this template. Technically anyone with LUA skills could though, but that's pretty rare on Wikipedia. Headbomb {t · c · p · b} 21:58, 26 October 2019 (UTC)
"Technically anyone with LUA skills could" isn't true. I would consider myself to have Lua skills, but consider the coding of citation modules to be too complex for me to understand and make fixes to. * Pppery * it has begun... 22:28, 26 October 2019 (UTC)
Hence the 'technically', rather than 'in practice' Headbomb {t · c · p · b} 22:30, 26 October 2019 (UTC)
And it appears that if Trappist doesn't want to do something it won't get done. ♦ J. Johnson (JJ) (talk) 21:31, 27 October 2019 (UTC)
I gave a diff at the parallel discussion on WP:VPT with the solution that I hinted at above, namely: I fixed Antimatter with double-parens in this edit. The idea is that the double parentheses tell the module that you are sure the page numbering syntax does not need auto-fixing. The module does not need to be changed. Johnuniq (talk) 22:11, 26 October 2019 (UTC)

─────────────────────────Then I guess the documentation needs to be modified. I have done so. Here's the above citation with double parentheses:

WT `{{cite journal |journal=Journal |pages=((3-1–3-15)) |title=Title}}` "Title". Journal: 3-1–3-15. "Title". Journal: 3-1–3-15.

Thanks for the help! – Jonesey95 (talk) 23:51, 26 October 2019 (UTC)

The documentation is fine, what needs to be updated is the POLA-violating behaviour of the template.
• `{{cite book |article=Picking a band |title=The ARRL Operating Manual |edition=8th |editor=Ford, Steve |page=1{{hyphen}}15 |publisher=[[American Radio Relay League]] |place=Newington, CT}}`
• Ford, Steve (ed.). "Picking a band". The ARRL Operating Manual (8th ed.). Newington, CT: American Radio Relay League. p. 1-15.
works just fine. So should the problematic example above. Headbomb {t · c · p · b} 21:58, 27 October 2019 (UTC)

## i18n of limited parameter values

There are several cs1|2 parameters that accept only certain parameter values: `|url-status=` will only accept `dead`, `live`, `usurped`, `unfit`, `bot: unknown` is one example of these kinds of parameters.

A discussion at my talk page showed that the current module suite doesn't provide good support for internationalization of these parameter values. So, I have tweaked the sandboxen to do that.

Here is an example of that change that uses French and German keywords (these keywords will be removed from the ~/Configuration/sandbox before updating the live modules):

`{{cite journal/new |journal=Journal |mode=cs2 |last=Brown |first1=Alpha Bravo |last2=Red |first2=Charlie Delta |name-list-format=vanc |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2019-10-08 |url-status=vivre |doi=10.1234/12345 |doi-access=frei}}`
Brown AB, Red CD, "Title", Journal, doi:10.1234/12345, archived from the original on 2019-10-08

And, unsupported keywords are still flagged as errors:

`{{cite book/new |title=Title |url=//example.com |url-access=frei}}`
Title. Invalid `|url-access=frei` (help)

Trappist the monk (talk) 14:04, 27 October 2019 (UTC)

## Citing music videos with Template:Cite AV media

Per MOS:NOITALIC, short musical works, such as songs (and therefore also music video titles; the MOS specifically lists songs, album tracks and other short musical works) should appear between quotation marks but not be italicized. Template:Cite music video redirects to Template:Cite AV media, yet the latter automatically italicizes the title of the work. Is there any way to circumvent this other than by entering the work title as below?

```|title = ''"Music video title that should not be italicized"''
```

Furthermore, should there be a separate template to handle cases like this? Armadillopteryxtalk 02:13, 28 October 2019 (UTC)

In citations it is good practice to distinguish the source. The work is italicized for emphasis. Citation style doesn't have the same objectives that body style has. Normally, short works were not widely published (in a conventional sense) as standalone publications. Usually it was easier to find them (and therefore cite them) in collections. That citation would "quote" the title of the short included in the larger collection. I do not think another template is necessary. 100.38.149.132 (talk) 11:11, 28 October 2019 (UTC)
`{{cite av media}}` has italicized title from its pre-`{{citation/core}}` days; see this 2006 edit when the template was still `{{cite video}}`.
In cs1|2, quoted upright font is reserved for those things that are sub-things of a larger thing being cited; chapters of a book; articles of a journal/magazine/newspaper; entries of an encyclopedia; pages of a website. Unless the quote marks (") are actually part of the work's title, they should not be included in `|title=` because they will also be included in the citation's metadata where they will be wrong.
This template suffers from a far greater problem in my mind and that is the use of `|people=` as a parameter and with en.wiki editors' inclusion of other 'stuff' in that parameter (producer, director, assistant whatever; affiliations, ...). Because `|people=` is an alias of `|authors=`, none of the contributors are included in the citation's metadata. A solution to this might be to enable `|contributorn=` for this template and also create a `|rolen=` parameter so that en.wiki editors might write:
`{{cite av media |contributor1=Contributor Name |role1=Contributor's role |title=Media Title}}`
and which might render as:
Contributor Name (Contributor's role). Media Title
Trappist the monk (talk) 14:02, 30 October 2019 (UTC)
My memory on the issue is foggy, but I believe the reason the unfortunate "people" was chosen, was because in some creative works like theater plays, films etc. there is no unambiguous "author". Several people may have important roles in creating the work, and the norm in such works is to credit them. I vote for the contributor-role combination. 108.182.15.109 (talk) 15:13, 30 October 2019 (UTC)

## Template:Cite_podcast should support |number=

Podcast episodes are usually numbered, but {{cite podcast}} doesn't support a parameter for them. It should. --AntiCompositeNumber (talk) 01:31, 30 October 2019 (UTC)

You do not give an example where `|number=` might be required. There was a previous discussion that might be useful:
Help talk:Citation Style 1/Archive 36 § Citing podcast episodes by number
Trappist the monk (talk) 14:10, 30 October 2019 (UTC)
These are the examples of podcasts that I could quickly find that have numbers but don't put them in the titles: [2] [3] [4] [5]. In other podcasts, the combined number and title string differs across platforms, often changing the prefix or punctuation around the number. Furthermore, I wouldn't write `|title=#80 | Virtual Choir` for the same reason I wouldn't write `|title=Important Book, 100th Edition`. To the point about metadata in the previous discussion, just because your particular client does not expose the metadata does not mean it doesn't exist. --AntiCompositeNumber (talk) 14:39, 30 October 2019 (UTC)
Please do not put words into my mouth that I did not speak. In the previous discussion, I said nothing about metadata.
I've tweaked the module sandbox:
`{{cite podcast/new |host=Dallas Taylor |subject2=Eric Whitacre |title=Virtual Choir |work=Twenty Thousand Hertz |number=80 |url=https://www.20k.org/episodes/virtualchoir}}`
Dallas Taylor; Eric Whitacre. "Virtual Choir". Twenty Thousand Hertz (Podcast). No. 80.
Trappist the monk (talk) 17:13, 30 October 2019 (UTC)

## i18n: language-category tweaks

A discussion on my talk page has prompted changes to the cs1|2 language support. I have tweaked Module:Citation/CS1/sandbox so that it emits a category when `|language=` is set to the local language and when a flag in Module:Citation/CS1/Configuration/sandbox, `local_lang_cat_enable` is set to `true`. At en.wiki we do not categorize articles with cs1|2 templates that have `|language=en` or `|language=English` so here `local_lang_cat_enable` is set to `false`.

As part of this change, I have also fixed the `|script-<param>=` code so that language-names used in the titles of subcategories in Category:CS1 uses foreign language script are in the local language instead of in English.

Trappist the monk (talk) 14:49, 2 November 2019 (UTC)

## access-date for archived urls

I fixed a dead link by adding a link to its entry in the Wayback Machine. There was already an access-date parameter, do I now update it? The documentation is not clear on this; maybe an additional archive-access-date parameter is needed. – gpvos (talk) 17:11, 3 November 2019 (UTC)

The edit: [6]. – gpvos (talk) 17:12, 3 November 2019 (UTC)
No. `|access-date=` identifies the date when the source linked by `|url=` supported the en.wiki article text. Adding an archive link does not change that. In your example, I would suggest choosing an archive snapshot closer to the 20 August 2013 access date than the 2018 snapshot that you chose; this 2013-08-15 snapshot perhaps. Besides that, no further action on your part is required.
Trappist the monk (talk) 17:36, 3 November 2019 (UTC)

## revised language support

I have tweaked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to harmonize cs1|2 with Module:lang because the various `{{xx icon}}` templates are deprecated. These `{{xx icon}}` templates are not related at all to cs1|2 except in how cs1|2 displays language names from IANA and ISO 639-2 and -3 codes. More detail is available in these four discussions (which are mostly me talking and no one responding):

Here is how the changes look:

• Blackfoot:
WT `{{cite book |title=Title |language=blackfoot}}` Title (in blackfoot).CS1 maint: unrecognized language (link) Title (in Blackfoot).
WT `{{cite book |title=Title |language=bla}}` Title (in Siksika). Title (in Blackfoot).
• Ilocano:
WT `{{cite book |title=Title |language=Ilocano}}` Title (in Ilocano).CS1 maint: unrecognized language (link) Title (in Ilocano).
WT `{{cite book |title=Title |language=ilo}}` Title (in Iloko). Title (in Ilocano).
• Kölsch:
WT `{{cite book |title=Title |language=kölsch}}` Title (in kölsch).CS1 maint: unrecognized language (link) Title (in Kölsch).
WT `{{cite book |title=Title |language=kolsch}}` Title (in kolsch).CS1 maint: unrecognized language (link) Title (in Kölsch).
WT `{{cite book |title=Title |language=ksh}}` Title (in Colognian). Title (in Kölsch).
• Colognian:
WT `{{cite book |title=Title |language=Colognian}}` Title (in Colognian). Title (in Colognian).
WT `{{cite book |title=Title |language=ksh-x-colog}}` Title (in ksh-x-colog).CS1 maint: unrecognized language (link) Title (in Colognian).
• Ripuarian:
WT `{{cite book |title=Title |language=Ripuarian}}` Title (in Ripuarian).CS1 maint: unrecognized language (link) Title (in Ripuarian).
WT `{{cite book |title=Title |language=mis-x-ripuar}}` Title (in mis-x-ripuar).CS1 maint: unrecognized language (link) Title (in Ripuarian).
• Taiwanese Hokkien:
WT `{{cite book |title=Title |language=Taiwanese Hokkien}}` Title (in Taiwanese Hokkien).CS1 maint: unrecognized language (link) Title (in Taiwanese Hokkien).
WT `{{cite book |title=Title |language=nan-tw}}` Title (in nan-tw).CS1 maint: unrecognized language (link) Title (in Taiwanese Hokkien).
• Min Nan Chinese:
WT `{{cite book |title=Title |language=Min Nan Chinese}}` Title (in Min Nan Chinese). Title (in Min Nan Chinese).
WT `{{cite book |title=Title |language=nan}}` Title (in Min Nan Chinese). Title (in Min Nan Chinese).

Trappist the monk (talk) 19:07, 3 November 2019 (UTC)

I think Trappist said it best at the Taiwainese discussion (copy-pasted to the other talk pages as well): Article name should match category names should match template renderings. I support consistency. When discussions lead to changes in article titles, it is straightforward to change the article, affected categories, and templates to match the new article titles. – Jonesey95 (talk) 22:35, 3 November 2019 (UTC)

`mis-x-colog` changed to `ksh-x-colog` per discussion at Talk:Ripuarian language § language naming inconsistencies.

Trappist the monk (talk) 14:45, 13 November 2019 (UTC)

## What to do about ISBN-10s

10-digit ISBNs have been deprecated since about 2007 and should be replaced by 13-digit ISBNs (now called just "ISBNs") wherever found. Conversion is a simple task (prepend "978-" and calculate a new check digit).

Correct grouping of the other digits (based on "group" and "publisher" identifier lengths) is quite a bit more complicated and would require some kind of periodically updated table.

I do have a javascript that accurately does both of these things while editing, so it could probably be converted to a lua module to do them while rendering instead. And I do mean a separate module, not just a new feature in {{cite book}}. That way it can also replace the contents of the standalone {{ISBN}} template, which currently looks dreadful.

If the above sounds like too much of a cosmetic execution-timesink (I suppose I'd need to create the module first and see how badly it performs), we could resort to tracking categories to fix the input rather than the output:

• A maintenance category when the number of digits is 10 and should be converted to 13.
• This would be in addition to the error category when the number of digits is neither 10 nor 13.
• A maintenance category whenever `(digits == 10 && hyphens != 3) || (digits == 13 && hyphens != 4)`, because these are sure to be wrong.

Note that detecting ISBNs with the correct number of hyphens at incorrect positions would probably be nearly as expensive as actually fixing them, so they would be neglected in the latter strategy. ―cobaltcigs 02:46, 8 November 2019 (UTC)

I guess I disagree with your premise that 10-digit ISBNs...should be replaced by 13-digit ISBNs (now called just "ISBNs") wherever found. A 10-digit isbn in a book printed in 1982 is and forever shall be a 10-digit isbn. Editors at en.wiki are admonished to WP:SAYWHEREYOUGOTIT. Part of that is accurately recording bibliographic details from the book that they are being citing. If the isbn on the title page of the book is 10 digits, use 10 digits in the citation, don't convert it to 13 digits. See the cs1|2 isbn documentation.
Trappist the monk (talk) 03:05, 8 November 2019 (UTC)
citation bot does the conversion IF the year is 2007 or later. That way we follow the say where you got it rule. In defense of isbn13 in older books, it COULD be thought of as adding area codes to older phone numbers—it is a stretch. AManWithNoPlan (talk) 03:39, 8 November 2019 (UTC)
IPv4 → IPv6 seems like a better analogy. ―cobaltcigs 20:47, 8 November 2019 (UTC)

The ponderous tome I linked to above says (emphasis mine):

```All new ISBN assignments are based on ISBN-13. If a 10 digit ISBN is
found on the resource, it should be converted to a 13 digit number,
following the rules set out later in this section, before being
encoded into the URN framework. According to the rules of the ISBN
standard, such conversion does not create a new ISBN for the book,
but a new representation of the existing ISBN.
[...]
The ISBN in thirteen digit form is defined by the ISO Standard
2108-2005 and later editions. It was previously referred to as
“ISBN-13” to distinguish it from “ISBN-10”, but since all ISBNs are
now valid only in the 13 digit format and ISBN-10 is deprecated,
ISBN-13 should be referred to as “ISBN”, although in this document
ISBN-13 is  used for the sake of clarity.
```

Note that it very clearly says "all ISBNs" and not "ISBNs of books published in or after 2007" and that there is no reference to any "grandfather clause" or continued validity of ISBN-10s for any duration of time after 2007.

I do know Google Books (surely a more popular "where you got it" source than physical books anymore) info shows both 10- and 13-digit ISBNs, without regard to year of publication and without indicating which of them was ever printed on a physical book. Of course, according to the above document, they could have stopped displaying ISBN-10s (or recognizing them for search) twelve years ago without violating any standards. And since Google Books is an order of magnitude more popular than anything else on the Special:BookSources list, Wikipedia and the rest of the world would have immediately followed suit, if only they had done that. ―cobaltcigs 04:49, 8 November 2019 (UTC)

I find it difficult to get worked up about this cosmetic difference that has no effect on the verifiability of sources or readers' ability to find books when there are hundreds of pages with actual ISBN problems on them. – Jonesey95 (talk) 05:21, 8 November 2019 (UTC)
That document is about how isbn's are or should be used in the context of Uniform Resource Names. cs1|2 does not use urns so the requirements of that document do not apply here.
Trappist the monk (talk) 12:08, 8 November 2019 (UTC)
Also, conversion is not simply a matter of prepending "978" to an ISBN. The prefix may also be 979 or in the future, something else. The ISBN registrar for the United States has a conversion tool but it is for US & Australia ISBNs only, see About ISBN (notice section on 979) and Converter. 72.43.99.138 (talk) 15:06, 8 November 2019 (UTC)
ISBNs starting with prefixes other than 978- will have no 10-digit equivalent. ―cobaltcigs 20:01, 8 November 2019 (UTC)
Did I miss something? I did not see any such statement. To quote from Bowker (the "About ISBN") link above, "A 10-digit ISBN cannot be converted to 13-digits merely by placing three digits in front of the 10-digit number. There is an algorithm that frequently results in a change of the last digit of the ISBN". So I assume this means there may be potentially a problem with the check digit in a text-based replacement. 98.0.246.242 (talk) 20:48, 8 November 2019 (UTC)
• Every 13-digit ISBN beginning with 978- corresponds to exactly one deprecated ISBN-10.
• "Corresponds to" means both forms refer to the same book publication and share a substring of 9 "significant" digits.
• These 9 are followed by a final check digit, which is calculated differently depending on which form and will differ about 91% of the time.
• Every 13-digit ISBN beginning with 979- corresponds to… no other number at all.
• Every 13-digit ISBN beginning with any other prefix… doesn't exist yet. Hopefully nobody still uses ISBN-10s at such future time.
• The "algorithm" is not as complicated as you may fear.
Hope this clears up some confusion. ―cobaltcigs 22:42, 8 November 2019 (UTC)
No, not really. But imo this discussion is becoming non-relevant as far as citations are concerned. As was stated before, editors should cite what they consult. If they consult a source with a 10 digit ISBN, then that is what belongs in the citation. If one feels so strongly about ISBN-13s, they should:
Find a source with a published ISBN-13
Verify the wikitext claim (previously supported by an ISBN-10 source) based on the new source
Replace and rewrite the citation based on the newly consulted source
What should not be done is replacing an ISBN-10 with an ISBN-13. These are marketing ids assigned to publishers by the proper agencies. Personally, I would reject any citation with a Wikipedia editor-manufactured ISBN-13 as original research or misdirection. Conversions of ISBN-10s are supposed to be done (and published) by the entities the ISBN's are assigned to. It is not up to Wikipedia to provide such service.
Not relevant to the above, are the various assignations. First, a straight text replacement is not the right way to go about it. Secondly, conversion tools, and their respective algorithms, seem specific to geographical areas. It is also not clear to me if outside the US "979" prefixes have not been used to replace ISBN-10s. In non-US materials, I have seen non-book ISBN-10s replaced by 979-prefixed ISBN-13s (sorry I have no real-world example handy). It would be perhaps relevant for citations to provide for an International Article Number (EAN) id, since that is what ISBN-13 is purported to align to. 108.182.15.109 (talk) 14:54, 9 November 2019 (UTC)
The above should be amended, as according to the latest edition of the ISBN Users' Manual (2017), "ISBN is now fully compatible with GTIN-13" (7th ed., p. 10, find it here). So I suppose that it would be a Global Trade Item Number id rather than an EAN that could be added if needed. 24.105.132.254 (talk) 18:39, 9 November 2019 (UTC)

─────────────────────────

• Math is not original research, especially not when the agency issuing these numbers has published very specific instructions for performing said math. The result is as deterministic as an MD5 hash. It just happens to be 5 lines of code and not 109. Here's another tool that does the exact same math. Using that is not original research either.
• Here are Google Books data examples from 1972 and from 2017, both of which show (mathematically!) equivalent 10- and 13-digit ISBNs side-by-side. Choosing the longer one in both cases, for the sake of consistency and forward compatibility, is not original research either.
• There will eventually come a day when some of the hundreds of databases shown at Special:BookSources will cease to recognize 10-digit ISBNs. This will probably coincide with the assignment of 979s in the United States (when the confusion begins affecting people whose opinions matter). At that point our only choice will be to unlist certain book sources or quickly convert numbers to continue using them.
• Here's a French children's book with a 979- ISBN and no short form next to it, because 979 ISBNs are not convertible to a 10-digit format and exist only in a 13-digit format. Any replacement such as you describe would have to be a bonehead error, or the intentional re-assignment of a whole new ISBN to an old edition of a book (not any conversion at all). Any claim that one of the latter two things routinely happens would be original research. Hopefully it's all just a false memory.
• Do you read many books from France, South Korea, and/or Italy? Serious question.

cobaltcigs 20:01, 9 November 2019 (UTC)

This is not how citations work. They involve published material from reliable secondary sources. ISBNs are legally issued and assigned identifiers through organizations established for this purpose. Even when the use of the conversion tools is allowable by third parties, the result would be unacceptable in a citation. The officially (by publishers) converted ISBNs have to be assigned by the ISBN agencies, like any other ISBN, and the source officially published with that ISBN. Anyone else doing a conversion and publishing it as an "ISBN" is doing OR as far as citations are concerned. Never mind wading into legally dubious territory. And that is assuming the algorithms don't change in the meantime.
We have no way of knowing if or when, book-source databases stop recognizing anything. The data is already entered and structured. There is no rule that says ISBN-10 should not be listed in such databases, nor that it should be replaced by ISBN-13. In contrast, book-marketing databases (including publisher databases) are told by the International ISBN Org. to no longer quote ISBN-10s, but this is irrelevant.
Additionally ISBNs have country codes irrespective of language. Different English-speaking countries may have different ISBN structures. The allocation of ISBNs is not cut and dried either. An educational music work could have been legally assigned an ISBN-10, and could be additionally assigned a 979 ISBN-13. A commercial music work would not have been assigned an ISBN-10, but perhaps an ISMN. Now however it can be assigned a 979 ISBN, since all these ids are compatible with GTIN-13, the new standard that is subsuming them.
And who says that anything involving math cannot be OR? It's not just how you arrive at the numbers, but also how and why you use the results. 24.105.132.254 (talk) 20:51, 9 November 2019 (UTC)
Anyway, ISBNs are so frustratingly unreliable in Wikipedia. How often I seen metadata for an ISBN be out of sync with the metadata in the cite book template (year/publisher). This can happen for a number of reasons, but mainly books have multiple years of publication and multiple publishers such as the co. name vs. imprint name vs. later editions. So someone may put the original year of publication in `|year=` while using the ISBN of their in-print edition which might be 20 years later. Then how do you know which edition it is? One could assume the ISBN is correct, but I've seen people and scripts add missing ISBNs to templates without a clear indication they are choosing the one intended, and not just the most recently published in-print edition. Particularly by people pushing links to bookseller sites for a certain edition. -- GreenC 19:53, 8 November 2019 (UTC)
Isn't this more of a behavioral issue. There are many admonishments in various help pages for editors to cite what they actually consult. If the consulted online link refers to a different edition than the one originally consulted to write the citation, such information is relevant and should be included somewhere, maybe in a link note. 98.0.246.242 (talk) 20:56, 8 November 2019 (UTC)
Also when you see a plural `| pages =` parameter followed by only one page number, there's a 90% chance it's the last page (often intentionally blank). ―cobaltcigs 21:19, 8 November 2019 (UTC)

This thread is full of obviously wrong information. Some quick facts. All books with and isbn10 have an isbn13 — it’s automatic. It does not mean that it is printed in the book obviously. The EAN for a book is the isbn13. The GTIN 13 for a book is the isbn13 number. Lastly converting an isbn10 to isbn13 is easy: just add the prefix and change the check digit. AManWithNoPlan (talk) 18:53, 9 November 2019 (UTC)

Well, none of the above are facts, quick or otherwise, according to the official ISBN manual or the official ISBN issuing authorities. I suggest you go back and check. 24.105.132.254 (talk) 20:51, 9 November 2019 (UTC)
Since you (24.105.132.254) are unwilling to do even a basic google search to see that you are wrong, here are the links. https://www.isbn.org/about_ISBN_standard and https://en.wikipedia.org/wiki/International_Standard_Book_Number#ISBN-10_to_ISBN-13_conversion all isbn10's have an isbn13 equivalent. https://en.wikipedia.org/wiki/International_Standard_Book_Number#EAN_format_used_in_barcodes,_and_upgrading and https://www.barcoding.com/blog/bookland-13-ean-13-and-isbn-numbers-one-in-the-same/ All ISBN13 are EAN. All ISBN's a GTIN https://en.wikipedia.org/wiki/Global_Trade_Item_Number#Format_and_encodings AManWithNoPlan (talk) 00:52, 10 November 2019 (UTC)
Since I was the one who originally used these links on this discussion I know very well what they are about, and the background. 72.89.161.42 (talk) 02:22, 10 November 2019 (UTC)
• I normally copy the ISBN from the indicia of the book. If it's an ISBN-10, a Bot will convert it to an ISBN-13. It did have an instance where the ISBN-10 in the book was incorrect; libraries had filed it both under the incorrect number and the correct one. After a discussion, it was agreed to substitute the ISBN-13. However, we have detected hoaxes based on invalid ISBNs. Hawkeye7 (discuss) 20:21, 9 November 2019 (UTC)
If you add anything that is not published at the source, it makes for an invalid citation. I thought this was clear. How can you "cite" something that is not there? 24.105.132.254 (talk) 20:54, 9 November 2019 (UTC)
The point is that even though the ISBN13 in not in the book, it is still a proper way to refer to the book. Just like journals from 1800 with DOIs and ISSNs and Such . AManWithNoPlan (talk) 23:41, 9 November 2019 (UTC)
Only if the later assignations have been published by reliable sources. If they have been concocted by Wikipedia bots or by anyone else they are not citable material. 72.89.161.42 (talk) 02:22, 10 November 2019 (UTC)

## URL from archive.org is marked as bad URL

Does anyone else get this error message? I've noticed it in the citation named "Guardian: how the rich" in Panama Papers, and I suspect that it's because the archive.org URL contains a second "http://" inside it, because of the truncated way the URL is displayed, but that doesn't ever appear to have been recognised as a problem before. I suspect a bug. --Florian Blaschke (talk) 09:54, 8 November 2019 (UTC)

Thanks a lot; I had kept looking at the wrong ref, because the one with the problem was "OCCRP Giant leak", and it turned out a mere typo.   Fixed --Florian Blaschke (talk) 14:21, 8 November 2019 (UTC)