Jump to content

Help talk:Citation Style 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 203.10.55.11 (talk) at 02:34, 11 October 2019 (→‎Follow up discussion - scope of application of italics in citations RFC). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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]
  • Journal of Physical Therapy Science (7 ? and 8 ✓ in 11)
 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)[reply]

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)[reply]
@Nigel Ish: 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. {{cite journal}}: 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)[reply]
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)[reply]
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)[reply]

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. 		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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
"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)[reply]
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)[reply]

Add |zenodo=

This would allow us to cleanup all these |url=https://zenodo.org/record/3348115#.XTk3rXt7kUE or |url=https://doi.org/10.5281/zenodo.3348115 to be |zenodo=3348115 → Zenodo: 3348115 (with the green lock) instead. Or |doi=10.5281/zenodo.3348115 → |zenodo=3348115.

Headbomb {t · c · p · b} 05:04, 25 July 2019 (UTC)[reply]

I agree it would be useful: users have added thousands of links to Zenodo, which is now probably the biggest preprint/green OA server in the world apart from arxiv. (Disclosure: I'm known for liking Zenodo.) Nemo 17:27, 24 August 2019 (UTC)[reply]
I would be a bit reluctant to add |zenodo=, since |doi= and |url= can already be used to store such links. Adding custom support for identifier schemes that are covered by the DOI system defeats the point of DOIs (having a unified identifier system on top of many providers). I think Zenodo URLs can already be made canonical as things stand. − Pintoch (talk) 15:37, 27 August 2019 (UTC)[reply]
The thing is zenodo is it's own repository, and does not link to where the canonical DOI would. So if you use |doi=, then you're usurping the version of record DOI. It's the same with |biorxiv=. It's technically a doi, but it's not the DOI. Headbomb {t · c · p · b} 17:00, 27 August 2019 (UTC)[reply]
The advantage of Zenodo is that it is open access, whereas many articles which are linked to with doi require subscription. I'm in favour of providing a |zenodo=9999| field, but until then we can use |id={{zenodo|9999}}|. Wayne Jayes (talk) 05:24, 12 September 2019 (UTC)[reply]

update to the cs1|2 module suite after 2 September 2019

Now that the blocking rfc has been closed, I propose to update the live cs1|2 module suite after 2 September 2019. Changes are:

Module:Citation/CS1:

  • better |xxx-url-access= error reporting; discussion
  • remove apostrophe markup from periodical and publisher params; discussion
  • periodical templates missing periodical parameter error messaging; discussion
  • add script parameter error detection & messaging; discussion
  • add |script-periodical= and |trans-periodical= parameter support; discussion
  • deprecate and replace |dead-url= and |deadurl=; discussion
  • add |map-url-access=; discussion
  • require |title= for {{cite encyclopedia}}; discussion
  • |issue= & |volume= in {{citation}} same as cs1 templates; {{citation|website=...}} error message when |url= missing or empty; discussion
  • access icon parameter-value bug fixed; discussion
  • add support for {{cite ssrn}}; discussion
  • support single letter 2nd level domain for .company tld; discussion
  • |doi-broken= requires |doi= error messaging; discussion
  • add maint cat when various parameter values have trailing punctuation (comma, colon, or semicolon); discussion

Module:Citation/CS1/Configuration:

Module:Citation/CS1/Whitelist:

  • added missing |contribution-url-access=; discussion
  • add script parameters for all |chapter= aliases; discussion
  • add |script-periodical and |trans-periodical parameter support;
  • deprecate |lay-summary= and |laysummary=; discussion
  • deprecate |dead-url= and |deadurl=;
  • add |map-url-access=;
  • add support for {{cite ssrn}};

Module:Citation/CS1/Date validation:

Module:Citation/CS1/Identifiers:

  • zbl temporary-id support; discussion
  • access icon parameter-value bug fixed;
  • |doi=10.5555... error detection; discussion
  • tweak bibcode validation; discussion
  • refine |doi-inactive= categorization; discussion

Module:Citation/CS1/Utilities:

  • strip apostrophe markup() from ~/COinS; discussion
  • tweak strip apostrophe markup() to return text and a flag;

Module:Citation/CS1/COinS:

  • move strip apostrophe markup() to ~/Utilities;
  • add support for cite ssrn;

—Trappist the monk (talk) 14:11, 27 August 2019 (UTC)[reply]

Also Inactive DOIs are now sorted into months of the year categories. --Izno (talk) 14:23, 27 August 2019 (UTC)[reply]
No support for Help talk:Citation Style 1/Archive 58#Check for final character in several regular fields? I thought this was done/sandboxed? Headbomb {t · c · p · b} 14:28, 27 August 2019 (UTC)[reply]
Yes, both of these too. Added to the list.
—Trappist the monk (talk) 17:03, 27 August 2019 (UTC)[reply]
@Trappist the monk: shouldn't the |agency= one in here also throw an error? Headbomb {t · c · p · b} 07:22, 28 August 2019 (UTC)[reply]
I'm confused. |agency= isn't used in the templates at the link you provided.
—Trappist the monk (talk) 10:05, 28 August 2019 (UTC)[reply]
@Trappist the monk: sorry, used the wrong link apparently. Fixed now. Headbomb {t · c · p · b} 15:30, 28 August 2019 (UTC)[reply]
I guess I'm still confused. This:
{{cite book/new |title=Title |agency=Agency,}} → Title. {{cite book}}: Unknown parameter |agency= ignored (help)CS1 maint: extra punctuation (link)
does not emit a red error message but does emit the green maint cat extra punctuation message. That was all that it was intended to do,
—Trappist the monk (talk) 15:39, 28 August 2019 (UTC)[reply]
My bad, I read things too fast and had a brain fart, I thought the URL error message was the trailing garbage error message and that threw me off. Headbomb {t · c · p · b} 15:58, 28 August 2019 (UTC)[reply]

@Trappist the monk: Even with the heads up, this change caused some problems. Please assist in the questions below. JAGulin (talk) 13:53, 3 September 2019 (UTC)[reply]

The changes as a whole right now are being discussed at ANI, I would also address the comments there Monk. - Knowledgekid87 (talk) 14:10, 3 September 2019 (UTC)[reply]

Cite web error

@Trappist the monk: When using cite web a large number of red errors are sprinkled through the references saying "Cite web requires |website=". It is quite clear that cite web does not actually require the website parameter from the documentation, so whatever code is generating this error should be reverted or cut. This error is in CSS class "cs1-visible-error error citation-comment" Graeme Bartlett (talk) 11:54, 3 September 2019 (UTC)[reply]

(edit conflict) Came here to say the same thing as I noticed a large number of new errors of this type in references I wrote a while ago. Requiring |website= is dramatically unexpected behaviour and different to how I've been using the template for over 5 years. I often use publisher instead, but even if both are omitted, it should not be an error as the reference is still sufficient without either parameter as long as it includes a URL, a title and enough extra information to specify the reference if the URL breaks (e.g. author). This error type should be removed quite urgently due to the number of articles it affects. — Bilorv (talk) 12:11, 3 September 2019 (UTC)[reply]
(edit conflict) I've just noticed this error message "Cite web requires |website=" and again as Rfassbind says the citation in question has a |publisher= parameter in it. It seems a bit superfluous to me for the citation to have to read {{cite web |url=http://foo.com/the_greatest_thing_ever_told |title=Whatever |website=foo.com |publisher=The Foo Corporation}} producing
"Whatever". foo.com. The Foo Corporation. to stop the error message appearing when the publisher parameter is supplying the identification about the sources of the information. Can |publisher= be added as an acceptable alternative to the periodical parameters already listed? Nthep (talk) 13:20, 3 September 2019 (UTC)[reply]
WTF did {{Cite web}} without |website= starting spitting ugly red error messages everywhere? Especially when there's already a perfectly appropriate |publisher= in there. Andy Dingley (talk) 11:10, 3 September 2019 (UTC)[reply]
Also the documentation for {{Cite web}} doesn't mention that this param is now mandatory, and that same documentation is itself littered with these inlined red error messages. Andy Dingley (talk) 11:15, 3 September 2019 (UTC)[reply]
This is new functionality as of the update listed above about which these new sections were started. The documentation, I assume, will be updated shortly. Help:CS1 errors I know has already been updated. We knew it would affect many articles which have had more-or-less incomplete citations. Please review the documentation pointed to in the above change notes. --Izno (talk) 12:22, 3 September 2019 (UTC)[reply]
It's not an incomplete citation, Publisher is often the more fitting parameter, and in many cases neither Website nor Publisher are needed. VisualEditor's automatic citation tool uses Cite Web by default, I don't expect people to know how to open syntax mode and change Cite Web to Cite News. This requirement is not needed and it's very confusing, could you consider turning this error message off? – Thjarkur (talk) 12:43, 3 September 2019 (UTC)[reply]
Requiring website= is crazy, as the web site can be determined by the URL in most cases. Just leave it as optional. I will say this is a bungled change without care for the consequences. Graeme Bartlett (talk) 12:54, 3 September 2019 (UTC)[reply]
I agree, why was changing "url=" to "website=" a good idea again? Millions of pages are now disrupted for this minor crazy change. - Knowledgekid87 (talk) 13:02, 3 September 2019 (UTC)[reply]
Also agree, this is an incredibly poor thought-out change. GiantSnowman 13:09, 3 September 2019 (UTC)[reply]
Note that website is not a replacement for url, it's an additional parameter. I agree that it should not be mandatory, or at least it should accept |publisher= as well as the other options. JAGulin (talk) 13:53, 3 September 2019 (UTC)[reply]
I agree that {{cite web}} shouldn't require |website/work/...=. Headbomb {t · c · p · b} 14:35, 3 September 2019 (UTC)[reply]
Is there a way to make "website=" and "newspaper=" non mandatory? - Knowledgekid87 (talk) 14:43, 3 September 2019 (UTC)[reply]
I am sure there is, the question is whether it should be. I think there is a case for having a "medium" and a "publisher" parameter as sometimes they are not the same thing, instead of having a "website" parameter that commingles two not-always-identical things. Jo-Jo Eumerus (talk, contributions) 15:02, 3 September 2019 (UTC)[reply]
Well I want to point out that news doesn't only come from a "newspaper" anymore. - Knowledgekid87 (talk) 15:06, 3 September 2019 (UTC)[reply]
From this comment, it appears that Trappist sees this change as part of the advertised change periodical templates missing periodical parameter error messaging. However, the linked discussion shows {{cite journal}}, {{cite news}} and {{cite magazine}}. I seems that adding this error message to {{cite web}} has not been discussed, and in view of the apparent lack of consensus, should be reverted. Kanguole 16:16, 3 September 2019 (UTC)[reply]
Yes, that is what I think. That I omitted {{cite web}} from the discussion was merely an oversight on my part. The code that emits the missing periodical error message is the same for all of the periodical templates / parameters.
—Trappist the monk (talk) 16:31, 3 September 2019 (UTC)[reply]
It seems that few share your view that web sites should be treated like periodicals. Kanguole 16:51, 3 September 2019 (UTC)[reply]
"Works", in citation-speak, are the cited sources. They are abstractions (of the underlying material). For purposes of citing, the underlying material, be it a website, book, periodical, map, encyclopedia, etc. is not relevant. It follows they are treated the same in a consistent, well-defined citation platform. We don't care what the source is, as long as it can be identified and found in the most efficient manner. Traditionally, this meant that citations were designed around the way sources were classified and indexed. First, by name/author/date, then by classification/marketing number, more recently by digital indexing. Such classification was always based on complete units (works), as they would be expected to be searched for by the person looking for them (citations of fragments being a special case). In the world wide web, the "unit" of search, or work, is a so-called "site". The smallest web item, say a few characters text, cannot exist without a hosting site. Any citation that does not include this simple fact, which happens to be the pathway to verification, cannot really be a citation. It is something else. 69.193.220.107 (talk) 20:24, 6 September 2019 (UTC)[reply]
69.193.220.107, I grant your understanding of citations generally, especially wrt to physical media, but it's very unclear from what you've written whether you understand the difference between a website, a web page, a hosting service, a domain, and a URI, and which one corresponds to "work" and how well digital media correspond generally when considering document retrieval. The fact that you say "In the world wide web, the 'unit' of search, or work, is a so-called 'site' ", makes me think you don't understand it well, or maybe you made a slip of the tongue. Your lead-off claim about "website, book, periodical," being analogous based on that faulty understanding is therefore mistaken. Mathglot (talk) 20:47, 6 September 2019 (UTC)[reply]
Actually there are many different technical terms for periodical. As many, or more, as there are for website. And that is not the point. The point is, citations are there solely for verification. Which means, they must accommodate solely the verifier. In a non-expert citation system like Wikipedia's, which if I am not mistaken is the first large-scale such system of its kind anytime anywhere, special considerations have to be applied. Including, paring down technicalities as much as it is possible without compromising validity. In writing a citation, I cannot assume that the reader would know the nuances or even the main building blocks of a network directory system or its underlying software infrastructure. If popular libraries were organized under such a view, nobody would be able to use them unless they knew the intricacies of the Dewey Decimal. We have to stick with what is the common, popularly known laymen's terms. Which doesn't mean that they will be incorrect. In broad terms, and as far as the experience of the vast majority of users is concerned, it is safe to assume that the meaning of "site" is unambiguous: it is where one goes to find stuff on the web. And that is it. Walk backwards from that, from where a user starts. You might arrive to the conclusion that not for any reason can the website name be left out of a citation. 98.0.246.242 (talk) 23:32, 6 September 2019 (UTC)[reply]
You might arrive at a different conclusion, after watching ten different users place five different things in the website param for the same source. Noting that url is unique and unambiguous and rarely misused, and "website" is none of the above, might lead you to the conclusion that making "url" required for a web page, and "website" merely informative and optional, was another way to go. Mathglot (talk) 00:09, 7 September 2019 (UTC)[reply]
But this is more because of the confusing documentation. The reason for many of these updates is because of the misuse of the parameters. This misuse is to an extent the result of below-par documentation. It is the responsibility of those who produce these changes to document them properly. I agree that citation writers have every right to expect clear-cut and plain documentation of everything the system does. However this is separate from the design rationale. 98.0.246.242 (talk) 01:27, 7 September 2019 (UTC)[reply]
Everyone complains about the documentation yet, when asked to help improve it, those same editors seem to always find something else to do ... I have admitted for years that I suck at documentation because my writing style is too technical, too strange, too wordy, too something, to make user documentation that I have written accessible to the general editing population. If you can see how our documentation can be made better, please help us fix it.
—Trappist the monk (talk) 03:02, 7 September 2019 (UTC)[reply]
"watching ten different users place five different things in the website param" - This issue was addressed in the citation tool, at my suggestion, by changing the label from "website" to "website name". Maybe the same fix could be applied to the parameter itself? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:02, 15 September 2019 (UTC)[reply]

'This has gone far enough. It's not a documentation issue but an issue of overreaching micromanagement by the maintainers of the citation template group who have an incorrect understanding of policy. I feel that the changes (to flag "incorrectly populated" parameters) have been put through unilaterally without due concensus are detrimental to the project. As highlighted already by fellow editors, the numerous red cs1-errors tags that have been appearing since the change do not always correctly identify parameters that are problematic. Please note that few WP articles about websites have italicised titles, so it is entirely jumping the gun to decide that all websites ought to be italicised within the reference section, as no consensus has been so reached locally nor according to policy and guidelines. The way I see around the problem would be a relatively easy but fastidious fix. To ensure that the titles of sources within the reference sections display according to the names in article space, I would see little alternative but to replace the {{cite web}}, {{cite news}} with the {{citation}} template. This would then allow the unrestricted (and unflagged) use of |newspaper= and their aliases, |publisher= when appropriate. All I would need to do is to incorporate a suitable regex in my script, and those errant error messages will go away. However, I hope that we can come to a sensible arrangement with which all editors can be satisfied. -- Ohc ¡digame! 21:07, 8 September 2019 (UTC)[reply]

url-status

Same for 'dead-url' paramter... I see this is listed now as deprecated and replaced with url-status, but couldn't there be a bot or something to fix them first? Broken citations everywhere are not a good look I'd think... --IamNotU (talk) 12:10, 3 September 2019 (UTC)[reply]

What are the available options? Getting errors and not sure how to format properly. There should be a mechanism to automatically rename parameter labels of citations in production when such labels change. As a utility module perhaps. 108.182.15.109 (talk) 12:15, 3 September 2019 (UTC)[reply]

|dead-url= was deprecated in favor of |url-status=, which accepts 'dead', 'live', 'unfit', 'usurped', and 'bot: unknown' (without quotation marks of course), so the only parameters which will have changed are the first two. As for renaming, there is a bot task approved for that work to start now. --Izno (talk) 12:18, 3 September 2019 (UTC)[reply]
Wouldn't it have been better if the bot was left to run for a few weeks before this mandatory change was sprung on us without warning. Now we have surprised editors, surprised readers, links to unhelpful error messages with no useful clue how to fix it and even the template documentation has not been updated yet. A complete mess on practically every WP article that could have been easily avoided.  Stepho  talk  12:28, 3 September 2019 (UTC)[reply]
In the current template documentation, "url-status=live" is mentioned as the default value. This is not currently the case. The current default is "url-status=dead". 108.182.15.109 (talk) 12:31, 3 September 2019 (UTC)[reply]
Can confirm. Leaving it empty causes the citation to act as if the url is dead. PanagiotisZois (talk) 12:47, 3 September 2019 (UTC)[reply]
Yes please turn off these warnings until the bot has updated the parameters. – Thjarkur (talk) 12:36, 3 September 2019 (UTC)[reply]
I think it would make sense to keep the warnings, but only in preview while both parameters are supported. That would help prevent new |dead-url= tags from being added while minimizing the confusion of editors. --AntiCompositeNumber (talk) 12:49, 3 September 2019 (UTC)[reply]
I'm not sure it can be visible only in preview, is that the difference of a "warning" and an "error"? They should make sure to bot quickly and reduce this to a warning. JAGulin (talk) 13:54, 3 September 2019 (UTC)[reply]

Wikipedia:Bots/Requests for approval/Monkbot 16 —Trappist the monk (talk) 13:21, 3 September 2019 (UTC)[reply]

@Trappist the monk:Perhaps it might be a good idea to have the citation templates throw a special error message akin to "Parameter is being replaced, please change to Foo as appropriate" until the bot pass is done then switch back to the normal red error? Jo-Jo Eumerus (talk, contributions) 13:55, 3 September 2019 (UTC)[reply]
That's what the help link is for with a deprecated parameter. (An unknown parameter is a different message.) --Izno (talk) 14:08, 3 September 2019 (UTC)[reply]
The normal deprecated parameter text does not make it clear enough that there is a mass replacement effort underway and is probably too visible for this specific situation. Jo-Jo Eumerus (talk, contributions) 14:27, 3 September 2019 (UTC)[reply]
The changes in the module are proper. It is their implementation that is lacking. As it was suggested at ANI, there should have been a parallel implementation of aliases, with sufficient warnings about the impending changes. 108.182.15.109 (talk) 14:03, 3 September 2019 (UTC)[reply]
They both work at present. Here: "Title". Website. {{cite web}}: Check |archiveurl= value (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help). --Izno (talk) 14:06, 3 September 2019 (UTC)[reply]
In general, deprecated parameters should not emit red error messages. They should populate maintenance categories until they are brought down to reasonable levels, and then support removed. Then they can emit errors. Headbomb {t · c · p · b} 14:38, 3 September 2019 (UTC)[reply]

Echoing some of the other comments here regarding the rollout of this change, as well as the change itself. Why was it necessary to deprecate deadurl for this new param? And why was such a major change made, apparently, almost unilaterally? It seems to offer no obvious benefits over deadurl, and the rollout has caused an incredible amount of chaos across the project. JimmyBlackwing (talk) 21:03, 3 September 2019 (UTC)[reply]

Why has "deadurl=yes" been changed to "url-status=dead"? The latter is harder to remember, needs a hyphen, and there are more letters to type. What is the point of the change? SarahSV (talk) 00:03, 5 September 2019 (UTC)[reply]
cs1|2 has a bunch of parameters intended to hold urls. These all end in -url:
|archive-url=, |article-url=, |chapter-url=, |conference-url=, |contribution-url=, |entry-url=, |event-url=, |lay-url=, |map-url=, |section-url=, |transcript-url=
|dead-url= does not hold a url but, because it looks like it should, editors do use it to hold the dead url. |url-status= was the best name we could come up with that didn't end in -url and still conveyed the meaning that we were looking for.
—Trappist the monk (talk) 00:30, 5 September 2019 (UTC)[reply]
SV, I fully agree with this change. The new one is easier to read and its meaning is clearer. Any change that makes the cite templates easier to use and understand (as this one does) has my full support. The hyphen is an advantage (good for clarity), not a drawback. (OTOH, I disagree strongly with some of the other changes, but that's a matter for discussion elsewhere.) --NSH001 (talk) 00:48, 5 September 2019 (UTC)[reply]
Okay, that makes sense. Trappist and NSH001, thanks for explaining. Just one other question. Would it not be easier to remember "urldead?=yes/no". I was thinking the same recently about "etal?=yes/no", rather than "display-authors=etal". There is so much to remember with these templates, and a lot of it isn't in the toolbar. An extra few characters may not seem worthy of complaint, but when you spend a lot of time adding these templates, you long for simplicity, things that are easy to remember, and as few characters as possible to type. SarahSV (talk) 01:13, 5 September 2019 (UTC)[reply]
I suspect that we considered |url-dead= and rejected it because it is awkward in an English-grammar-sort-of-way. |etal= doesn't work because, besides authors, there are also contributors, editors, interviewers, and translators.
—Trappist the monk (talk) 01:26, 5 September 2019 (UTC)[reply]
The other valid values for |url-status= are "unfit" and "usurped", which would not make sense syntactically with a parameter name that included the word "dead", including the old |dead-url= parameter. As for the hyphen, CS1 was standardized long ago on hyphenated parameters when the parameter name contains more than one word. – Jonesey95 (talk) 02:42, 5 September 2019 (UTC)[reply]

Please change website equals back to url

This new change is crazy, disruptive, and does not appear to have consensus here. "URL" is much easier to remember, quicker to type in, and its something editors are used to doing. - Knowledgekid87 (talk) 13:05, 3 September 2019 (UTC)[reply]

@Knowledgekid87: You are mistaken. |url= remains entirely undeprecated. --Izno (talk) 13:20, 3 September 2019 (UTC)[reply]
Why the error message then saying "website=" is needed when a url is already provided for cite web? - Knowledgekid87 (talk) 13:21, 3 September 2019 (UTC)[reply]
|website= is a periodical parameter much like |journal= is a periodical parameter. It names the website because the website name is hidden in |url=.
—Trappist the monk (talk) 13:24, 3 September 2019 (UTC)[reply]
@Knowledgekid87: See this example for what |website= actually does: {{cite web|url=https://www.example.com/|website=ExampleWebsite |title=Webpage}} produces "Webpage". ExampleWebsite. --Izno (talk) 13:25, 3 September 2019 (UTC)[reply]
@Izno: I fixed your example to stop further misunderstanding. Another example: "Webpage". ExampleWebsite. PublisherName. -- JAGulin (talk) 14:13, 3 September 2019 (UTC)[reply]
"Website=" should not be mandatory then. - Knowledgekid87 (talk) 14:32, 3 September 2019 (UTC)[reply]

New error messages as of 2 September 2019

{{cite web}} displays new CS1 Error messages:

  • Cite uses deprecated parameter |dead-url= (help)
  • Cite web requires |website= (help) [a"publisher" parameter already exists]

The changes were probably added today and affect numerous citations (millions?). Are these permanent changes? And if so, where are they documented? Rfassbind – talk 12:30, 3 September 2019 (UTC)[reply]

Rfassbind, see #update to the cs1|2 module suite after 2 September 2019 above. The changes were made first, documentation is in the process of being updated, and bots are being written and modified to support the changes. As someone who previously didn't watch this page, they did catch me by surprise (but I guess that's what the big red warnings are for). --AntiCompositeNumber (talk) 12:44, 3 September 2019 (UTC)[reply]
Also affects {{cite news}} - error message is "Lua error in Module:Citation/CS1 at line 802: Argument map not defined for this variable." This is an incredibly poor implementation, given literally thousands of articles will be affected. If a bot is going to 'fix' them then when and how? I don't want my watchlist clogged up with 5,000 bot changes... GiantSnowman 13:08, 3 September 2019 (UTC)[reply]
It appears that this whole mess was made without first thinking of the effects done. - Knowledgekid87 (talk) 13:10, 3 September 2019 (UTC)[reply]
Can someone restore the old version until problems are resolved? Dentren | Talk 13:13, 3 September 2019 (UTC)[reply]
@Trappist the monk: Please revert your change until consensus can be established and/or there is a fix to this mess. - Knowledgekid87 (talk) 13:18, 3 September 2019 (UTC)[reply]
@GiantSnowman: That particular error is likely because of Ivanvector's revert on only one of the 7 module pages, which Ttm has now undone. --Izno (talk) 13:22, 3 September 2019 (UTC)[reply]
It's at ANI, and the original lack of discussion is paramount. ——SerialNumber54129 13:23, 3 September 2019 (UTC)[reply]

Discussion to undo all of the changes

Discussion: Wikipedia:Administrators' noticeboard#Proposal to overturn the mass change made to Module:Citation/CS1 - Knowledgekid87 (talk) 13:41, 3 September 2019 (UTC)[reply]

"mode = CS1" raises warning

@Trappist the monk: Sorry to ping you, but I know you're the expert even if I may be wrong about this. Was mode parameter check among the changes in this batch? Is it too complicated or undesirable to make value lowercase before use? Also, the Category:CS1_errors:_invalid_parameter_value seems to keeps track of each article, but not the offending Template itself. When I fixed OED 200 errors were solved in one go. If the template/doc pages were listed in a sub-category it would make it easier to fix those first. -- JAGulin (talk) 11:28, 4 September 2019 (UTC)[reply]

In cs1|2 all parameter names and all special keyword values are supposed to be lowercase. The change that enforced lowercase happened because a non-lowercase keyword caused Lua script errors (this discussion though the script error no longer shows.
Yeah, subcats might be nice but they are most times not required yet must still be maintained if they exist. It is possible to detect namespace so for pages in the Template: namespace it might be possible to add a sortkey to the category link so templates would be grouped together. I think that I remember reading that there is a standard Greek-letter sortkey specifically chosen for templates; don't remember where I read that.
—Trappist the monk (talk) 11:51, 4 September 2019 (UTC)[reply]
Usually you go with a lowercase Greek letter. β → Book:, τ → Template:, ω → Wikipedia:, etc... Headbomb {t · c · p · b} 00:33, 5 September 2019 (UTC)[reply]
@Headbomb: Do you have a link for future reference? WP:SORTKEY seems to be the place to have it, but it doesn't mention tau currently. Curiously the wp:tau redirects to the same place and I found that this edit removed the tao with reference to WP:CAT#T. I've suggested to reinstate it. @Trappist the monk: As long as the category is consistent, you can choose any way to sort. *τ {{PAGENAME}} may be the sortorder I suggest for templates, in cases like this when I want to gather them in the beginning of the list. All of this is in vain if no templates show up in the category, but I would think that at least the doc page should be listed. JAGulin (talk) 16:28, 5 September 2019 (UTC)[reply]
There's no real standardized thing, but you can check Category:All WikiProject Women in Red_pages for an example. Headbomb {t · c · p · b} 18:54, 5 September 2019 (UTC)[reply]
@Headbomb:, @Jagulin:, @Trappist the monk:: {{Namespace Greek}}. All the best: Rich Farmbrough, 11:58, 28 September 2019 (UTC).[reply]
Here is a petscan query that lists all templates in CS1 error categories. It should be perused with the following caveats: (1) there are strong objections to the "missing periodical" errors that are currently being tracked, so it may be unwise to "fix" those errors before there is further discussion; and (2) some template pages, such as Template:Cite Memoria Chilena, should not be "fixed" just because the template page itself has errors. There have been about 40 or 50 semi-permanent residents on that page for a few years. – Jonesey95 (talk) 14:12, 4 September 2019 (UTC)[reply]
@Jonesey95: Great, your query is a good way to filter. I was able to modify it to the category I wanted, but as I expected it found no templates.
@Trappist the monk: Thanks for confirming that this was an intentional change. Specifically the Limited petscan also confirms that there are no Templates in "CS1 errors: invalid parameter value". It specifically mentions filtering some namespace out, but Template is not listed among them. Could you check for it?
If it doesn't interfere with anything else, it's fine to put the templates in the same category. May I suggest using greek tau to get the templates gathered on top? If there's a better choice, you can change later.
I think that the Template:GRIN should show up, but if not, the Template:GRIN/doc#Samples also should. --JAGulin (talk) 17:45, 4 September 2019 (UTC)[reply]
Changes to templates and modules can take days, sometimes months, to affect Category membership of pages that transclude those templates, so you may have to resort to an "insource" search of pages to find what you are looking for. This search currently yields 30 pages for me, for example, but I'm going to tidy them up anon. – Jonesey95 (talk) 17:56, 4 September 2019 (UTC)[reply]
Again you show that the simple tricks are also the most effective. Thanks for cleaning those up, it effectively reduced the warnings in "my category". That said, I think it would be useful to have the templates in the "CS1 errors: invalid parameter value" category, so if it wasn't due to lag it should be fixed. Over and out, JAGulin (talk) 19:59, 4 September 2019 (UTC)[reply]
Any Template-space pages that I did not catch and fix today will eventually appear in the category if the Template page itself contains an error. Sometimes, templates cause errors only when they are used; those instances will need to be caught by examining pages in the error category.
As of this time stamp, there are 338 pages in Category:CS1 errors: invalid parameter value. Most of them are due to |deadurl=No/Yes (change to |url-status=live/dead, respectively) and to |nopp=Y (change "Y" to "y"). – Jonesey95 (talk) 21:04, 4 September 2019 (UTC)[reply]

Cite ssrn, where it is?

The change log says 'add support for {{cite ssrn}}', but no such template exist. This needs to be created. Headbomb {t · c · p · b} 14:31, 6 September 2019 (UTC)[reply]

WP:SOFIXIT Special skills not required. Copy source from {{cite ssrn/new}}.
—Trappist the monk (talk) 14:35, 6 September 2019 (UTC)[reply]
@Trappist the monk: this is LUA stuff, so yes, special skills required. Also please fix the damn {{cite web}}/{{cite news}} errors per overwhelming consensus. It's ridiculous that we're still waiting on this 3 days later. Headbomb {t · c · p · b} 14:43, 6 September 2019 (UTC)[reply]
Did you look? There is no Lua code in that template sandbox: There is an {{invoke:}} (not Lua code), {{documentation}} (not Lua code), and <includeonly>...</includeonly> & <noinclude>...</noinclude> tags (not Lua code). The invoke should not point to the module sandbox.
Template needs documentation.
—Trappist the monk (talk) 15:19, 6 September 2019 (UTC)[reply]
I have created the template and a draft documentation page (copied from cite web docs). The documentation needs examples, and probably adjusting of the transcluded contents, provided by someone who knows what the new template is for and how it is used. I think there are a couple of other pages that try to list all of the CS1 templates; those need to have the new template added to their tables/lists, with appropriate descriptions. – Jonesey95 (talk) 17:32, 6 September 2019 (UTC)[reply]

Category redirection over deletion

Since there are many pages and edit summaries that link to the old (and recently mostly deleted categories), wouldn't it be better to {{Category redirect}} them instead of deleting?   ~ Tom.Reding (talk ⋅dgaf)  12:01, 29 September 2019 (UTC)[reply]

I don't know how many edit summaries link to the various renamed categories. Most links to the old-named categories are residue from the change to the new name in non-article namespaces. This because any page that isn't an article won't be refreshed with the frequency that article-namespace pages are refreshed.
Take for example Category:CS1 maint: Multiple names: authors list. As I write this, there are 5k+ pages linking to that category Of those pages, there are three in article namespace:
Manchester City F.C. supporters (ve edit)
Sarracenia × swaniana (from ro:Sarracenia swaniana via Content translation)
Albert Schweitzer High School (Erlangen) (from de:Albert-Schweitzer-Gymnasium (Erlangen) via Content translation)
All three of these have raw (not created by the current versions of a cs1|2 template) old category link because of that abomination that is ve (copying named references from one page to another) or because the article was created by the auto-translation process (whatever that is) from another language Wikipedia.
If we redirect all of these old-named categories, it is (I think) harder to find these buggered up articles because they don't get listed in the old-name category but, instead, get lumped in with all of the articles in the new-named category.
—Trappist the monk (talk) 17:15, 29 September 2019 (UTC)[reply]

Post-update updates needed

This very long WP:AN discussion has just concluded, and requires changes to the modules, some of which have been made already:

  1. Stop categorizing "missing periodical" errors
  2. Stop displaying "missing periodical" error messages (already changed to "hidden" using CSS; change to eliminate messages entirely)

The following change has also been made since the updates listed above, but it was not mandated by the discussion closure:

  1. Stop displaying "deprecated parameter" errors for |dead-url= / |deadurl= (already changed to "hidden" using CSS)

We (Trappist, unless someone else has the programming skills) should probably make the remaining change as soon as possible. We could optionally start displaying the deprecated parameter messages, but I think that would just make people angry. I would prefer to see that happen after 99% or more of the |dead-url= / |deadurl= have been converted to the new |url-status= parameter. – Jonesey95 (talk) 21:00, 6 September 2019 (UTC)[reply]

I have asked for a bit of clarification with regard to the missing periodical errors reporting.
—Trappist the monk (talk) 21:54, 6 September 2019 (UTC)[reply]
Sounds good. While waiting, I have edited above to clarify that I believe the close means that even the hidden "missing periodical" error messages should be eliminated in the modules. – Jonesey95 (talk) 22:02, 6 September 2019 (UTC)[reply]

Trappist says everything required by the close is completed. The closing message also said "The other updates shall stand", so I think we should also monitor the progress plan for finalizing this change.

  • Monkbot task 16 - to finish replacing |dead-url=
  • Confirm that documentation is up to date to the current implementation
  • Tools are updated to conform to new documentation
  • Task-force to deal with any other problems/error categories that came out of this

The following were in scope for this change, but are now to be treated as discussions before further updates.

  • Re-instate error message for |dead-url= - is that needed and welcome?
  • What is the intended use of |website=, can documentation be updated and agreed upon?
  • How important was the italics RfC and what options are there now to reach that goal?
  • Anything else that was "reverted" and should be rescheduled for inclusion or discussion?

-- JAGulin (talk) 14:21, 8 September 2019 (UTC)[reply]

Unhide missing periodical error messages? – Levivich 14:33, 8 September 2019 (UTC)[reply]
Bumping this discussion, hopefully, since I feel the time has come. Category:CS1 errors: deprecated parameters is currently down to 48,060 pages as of typing, which is a bit over 0.8% of all Wikipedia articles (including disambiguation pages). (Live values can be found here: 0/6,892,488 = 0%.) Therefore, I request that the deadurl/dead-url errors become fully visible again. I find it useful for clean-up purposes. -BRAINULATOR9 (TALK) 14:37, 28 September 2019 (UTC)[reply]
We have to wait for Monkbot to finish going through the deprecated parameters category, after which further manual intervention will be necessary to clean up instances that the bot was unable to handle, along with instances in Category:CS1 errors: invalid parameter value. In the meantime, instructions for displaying the error messages for yourself, when you are logged in, are available at Category:CS1 errors: deprecated parameters. – Jonesey95 (talk) 16:57, 28 September 2019 (UTC)[reply]
If you would like to display them yourself, you will actually need to do something not presently documented at the category page in your CSS: 
.mw-parser-output span.cs1-hidden-error {display: inline;} /* display Citation Style 1 hidden errors */
That's because the template which tells people how to configure their CSS does not include how to configure hidden errors, which were not expected to be used again (and so I had removed when we went to TemplateStyles).... --Izno (talk) 17:12, 28 September 2019 (UTC)[reply]
That aside, I've now made the change in the module sandbox, so the next release should make them visible again. --Izno (talk) 17:16, 28 September 2019 (UTC)[reply]
OK, thank you all! -BRAINULATOR9 (TALK) 19:47, 28 September 2019 (UTC)[reply]

Differing headlines between Print and Internet articles

There's been a couple of times lately, I've been pondering how to handle the increasingly different headlines between print and Internet versions of articles. While the articles appear to be identical (occasionally with an extra paragraph or two on the Internet version - perhaps trimmed for length), the headlines can differ massively. Today's example is on page A9 of the September 1 Toronto Star called The road with NO GREED LIMIT. The internet version though is a much more politically inflammatory Birth of a fiasco: How the Ontario Tories completely botched the sale of Highway 407. So which one should be cited? My preference would be to cite both - but I don't see an appropriate field. Any thoughts? Nfitz (talk) 16:04, 1 September 2019 (UTC)[reply]

Cite the one you read. If you read both, cite both separately. You might consider leaving a hidden note that titles differ. --Izno (talk) 16:52, 1 September 2019 (UTC)[reply]
Invariably when this comes up (or at least when I notice), it's because I've started from the print, or microfilmed subscription copy, and then used that to to discover the article is available online, with a (very) different headline, while looking for a URL. Probably best include the URL ... But if I use the URL, I know that sooner or later, someone will "fix" the reference. Yeah, hidden text might be the solution - something like this? Nfitz (talk) 21:44, 1 September 2019 (UTC)[reply]
That's what I should have suggested originally, yes. :) --Izno (talk) 22:05, 1 September 2019 (UTC)[reply]

Why not title=foo [print] bar [Internet] All the best: Rich Farmbrough, 12:03, 28 September 2019 (UTC).[reply]

isbn2

plz add it ·Carn !? 09:21, 3 September 2019 (UTC)[reply]

Please provide an example where this parameter would be useful. Per WP:SAYWHEREYOUREADIT, editors should be citing the single source that they are using to back up any claim, and a single source has only one ISBN (the 10-digit and 13-digit ISBNs are equivalent for a given book, so there is no need for both).
If a second source with a different ISBN is useful for some reason, use a second citation template to cite the second source, or place the additional ISBN outside of the citation template. – Jonesey95 (talk) 16:39, 3 September 2019 (UTC)[reply]
Some books have more than one ISBN. All the best: Rich Farmbrough, 12:03, 28 September 2019 (UTC).[reply]
Citation needed. – Jonesey95 (talk) 13:50, 28 September 2019 (UTC)[reply]
Assuming they’re not just talking about ISBN-13 vs ISBN-10, some books’ edition notices might have multiple ISBNs displayed, but it will be because they list, say, the ebook and hardback ISBNs, or have different ISBNs for a boxed set and an individual volume. None of these warrant multiple inclusions in a works cited, in my view. Umimmak (talk) 14:00, 28 September 2019 (UTC)[reply]

"Eastern name order": should one use |author= or |author-mask= ?

For works where an author's name is published as Surname Given-name (authors using "Eastern name order"), which underlying code is preferred? One option is putting the family name in |last=, given name in |first=, and then using |author-mask= so that the name appears in the citation without the comma. Using |ref=harv is straightforward, but one needs to add in punctuation such as the semicolon in |author-mask= if there are any subsequent authors.

(1a) {{cite book|last=Zhang |first=San |first2=John |last2=Smith |date=2019 |title=Title |author-mask=Zhang San; |ref=harv}} with {{harv|Zhang|Smith|2019}}

Zhang San; Smith, John (2019). Title. {{cite book}}: Invalid |ref=harv (help) with (Zhang & Smith 2019)

If |author-mask= shouldn't be used to overwrite how the name appears in the citation, then one can put the entire name in the |author= field as it was published. Then one would have to use {{harvid}} within |ref= if the article uses Harvard citations/shortened footnotes.

(1b) {{cite book|author=Li Si |first2=Jane |last2=Doe |date=2019 |title=Title |ref=harvid|Li|Doe}} with {{harv|Li|Doe|2019}}

Li Si; Doe, Jane (2019). Title. with (Li & Doe 2019)

Both methods also work with editors (sparing the details of |ref={{harvid}}):

(2a) {{cite book|editor-last=Kovács |editor-first=János |editor-mask=Kovács János; |editor2-first=Max |editor2-last=Mustermann |title=Title |date=2019}}

Kovács János; Mustermann, Max, eds. (2019). Title.

(2b) {{cite book|editor=Kovács János |editor2-first=Max |editor2-last=Mustermann |title=Title |date=2019}}

Kovács János; Mustermann, Max, eds. (2019). Title.

And with contributors (and again, sparing |ref= details ):

(3a) {{cite book|contributor=Hong Gildong|contribution=Preface|last=Smith |first=John |title=Title |date=2019}}

Hong Gildong (2019). Preface. Title. By Smith, John.

(3b) {{cite book|contributor-last=Hong |contributor-first=Gildong |contributor-mask=Hong Gildong |contribution=Preface|last=Smith |first=John |title=Title |date=2019}}

Hong Gildong (2019). Preface. Title. By Smith, John.

Is there a reason why one method should be preferred over the other? Both produce the same visual output, but I was wondering if there were benefits to one over the other for other reasons. Thanks. Umimmak (talk) 05:33, 4 September 2019 (UTC)[reply]

The trailing semicolon in |author-mask= adds the article to Category:CS1 maint: extra punctuation which will no doubt get improperly fixed by someone or some bot or some script which then becomes a maintenance headache. On the other hand, for the purposes of metadata, |last= and |first= are the preferred author-name parameters so using |author-mask= to hide the name separator comma is to be preferred over |author= with {{sfnref}}.
This name order issue keeps recurring so perhaps someday we'll be brave enough or clever enough to find a solution. In the mean time (and after the current kerfuffle settles) I'll fix the code so that trailing punctuation in the mask parameters doesn't add the maint cat.
—Trappist the monk (talk) 11:26, 4 September 2019 (UTC)[reply]
Thank you, I forgot the punctuation would have added a maintenance category, so thank you for thinking about that and letting this be an exception. And yeah, no rush on this. Umimmak (talk) 14:15, 4 September 2019 (UTC)[reply]
While I’m thinking about it, Trappist the monk, is there an easy way to have |authorn-mask= accept text arguments in {{Harvc}} as well so it would work in a similar fashion? Thanks. And again, no rush on this; I know things have been a bit hectic. Umimmak (talk) 05:08, 11 September 2019 (UTC)[reply]
In the sandbox:
{{harv|Black|2019}} → (Black 2019)
{{harv|Brown|Black|2019}} → (Brown & Black 2019)
{{harvc/sandbox |last=Black |year=2019 |c=Contribution Title |in=Editor |author-mask=Black Masked}}
Black Masked. "Contribution Title". In Editor (2019).
{{harvc/sandbox |last=Brown |last2=Black |year=2019 |c=Contribution Title |in=Editor |author-mask2=2}}
Brown; ——. "Contribution Title". In Editor (2019).
{{cite book |title=Title |editor=Editor |date=2019 |ref=harv}}
Editor, ed. (2019). Title. {{cite book}}: |editor= has generic name (help); Invalid |ref=harv (help)
like that?
—Trappist the monk (talk) 15:38, 11 September 2019 (UTC)[reply]
Trappist the monk yes that's perfect! Thank you so much for making these changes! Umimmak (talk) 04:10, 12 September 2019 (UTC)[reply]
done
—Trappist the monk (talk) 11:08, 13 September 2019 (UTC)[reply]

Better explanation for "website" parameter in docs

Seems like there may soon be a very large number of new |website= parameters added to existing citations... Reading many of the recent comments, it's apparent that there's still a fairly widespread belief that |website= is for a simplified URL, like "example.com", rather than a name like "Example Domain", most often found in the HTML <title> on the home index.html page. See for example this comment and its followups: [1].

The current documentation is a little sparse:

  • website (required): Title of website; may be wikilinked. Displays in italics. Aliases: work.

and:

Title (name) of the website (or its short URL if no plain-language title is discernible); may be wikilinked; will display in italics. Having both 'publisher' and 'website' is redundant in many cases.

Example

Rotten Tomatoes

Would it be beneficial to add something along the lines of:

  • website (required): Title of website; may be wikilinked. Displays in italics. Aliases: work. This is a plain-language title or name of the overall website, often found in the HTML <title> element of the main home index page, displayed in the browser's window or tab title. For instance, at the website https://example.com, it is Example Domain. If no title is discernible, a short URL may be used. If publisher is substantially the same as website, then publisher should be omitted.

and/or:

Title (name) of the website (or its short URL if no plain-language title is discernible); may be wikilinked; will display in italics. Often found in the browser tab or window title on the home page of a website. Having both 'publisher' and 'website' is redundant in many cases; if so, 'publisher' should be omitted.

Example

Rotten Tomatoes

? --IamNotU (talk) 00:32, 5 September 2019 (UTC)[reply]

<title> simply defines the title of the HTML document, typically the title of the tab in your browser, which may or may not be the actual name of the website. For instance, on Rotten Tomatoes it is actually <title>Rotten Tomatoes: Movies | TV Shows | Movie Trailers | Reviews - Rotten Tomatoes</title>. I am under the impression that there are other tags specifically for this purpose: <meta name>, <meta title> and <meta property>. On Rotten Tomatoes it is <meta property="og:site_name" content="Rotten Tomatoes">. I use User:V111P/js/WebRef which is pretty good at fetching the correct name of the website. – Finnusertop (talk ⋅ contribs) 09:07, 5 September 2019 (UTC)[reply]
I think that things like Wikipedia:RefToolbar/2.0 are the reason for is for a simplified URL, like "example.com" and that the reason why the documentation is so vague is because it is not actually a very useful parameter that also combines several not-always-related pieces of information.
We need a discussion or RfC to decide how |website= should work. In some cases, the website is also the publisher; in others it is merely a platform where the material published by someone else is hosted. The correct way would be to make |publisher= be the essential parameter and |website= an optional one for when one is getting the info from another website than that of the publisher per WP:SAYWHEREYOUGOTIT. Jo-Jo Eumerus (talk, contributions) 09:46, 5 September 2019 (UTC)[reply]
Agreed that the /doc page needs to explain it better. Even the #Examples section at the various {{cite}} templates are not self-consistent, sometimes using an English website name ('Encyclopaedia of Things') and sometimes using the domain name ('NFL.com').
Meta property 'og:sitename' is not standard HTML; it's part of Open Graph Protocol a proprietary property in a framework used for social media (Facebook, primarily, and others). 'Title' is standard Html since the beginning, and is often a good choice for |title=, and *sometimes* for website. Agree with Jo-Jo, that it's sometimes this, and sometimes that; in organizations with many nested levels (governmental, or large private or public orgs) it can be very unclear what the 'website' really is. Because of this, making it mandatory is a bad idea, imho, because you will get editors of all different levels trying to decide what it is for a given page on the web, and coming up with ten different answers for the exact same url (except for the simple cases). A lot more thought needs to be put into this. Mathglot (talk) 09:58, 5 September 2019 (UTC)[reply]
Jo-Jo Eumerus, you're right about Citoid/RefToolbar slapping a short URL into |website= by default, that's quite counterproductive and misleading. Mathglot, the NFL example is unclear, because "NFL.com" is actually the website name of http://nfl.com, as opposed to "www.nfl.com" that Citoid generates - a lot of sites are branded that way. On the other hand, the URL given in that example, http://www.nfl.com/rulebook/digestofrules, is now a dead link that redirects to https://operations.nfl.com/ - the website name there is "NFL Football Operations"... --IamNotU (talk) 10:26, 5 September 2019 (UTC)[reply]
PS, I just updated that NFL example... --IamNotU (talk) 10:40, 5 September 2019 (UTC)[reply]
(edit conflict)Finnusertop, thanks, yes I did mention the "og:site_name" in the thread I linked above as being helpful when present, but it's part of Facebook's open graph scheme and not universally used. I also noted the fact that the HTML title of the home page typically includes the website name, but also includes things like the word "home" etc., which the editor has to figure out. What I'd like to do is give people better clues about what and where to look for the most appropriate value for |website=, not to say definitively "this is it", because it's sometimes not straightforward.
Btw., the <meta> tag is a generic way to associate a name with a set of values as metadata, "name" is an attribute of the tag, which is the name of the variable. You could define for example, <meta name="sitename" content="Example Domain" />, but there's no standard for that. <meta title> doesn't exist, there's only <title>, which like <meta> goes in the <head> of the html, and is metadata, defining the name of the page as you noted. Again, by convention the name of the home page usually includes (often among other things) the name of the website itself, but there's no real standard. --IamNotU (talk) 10:03, 5 September 2019 (UTC)[reply]
I have no issue either with short version of domain (as currently auto-populated by a number of tools), stylized with capitals or even spaces as desired (cnn.com, CNN.com, The New York Times.com) or with some other stylized name perhaps matching the name of the publisher as they so often name their website after the company in the interest of branding (CNN). Today if we talk about a website, sometimes we use the TLD and sometimes not. An example is Overstock.com (to use a favorite out of Wikipedia history). I also find this way of describing things easier for a lot of the same people who have heartburn about the italics--Overstock.com is the name of the work or website, Overstock is its owning company (I presume; just an example). I also know some sites lend themselves through branding away from the TLD and toward the name of the work i.e. the big social media sites are Facebook and Twitter and rarely include the .com in discussion today. Sometimes of course we have the name of a journalistic entity like The New York Times for which zero people have heartburn italicizing even if it's the web resource which was accessed rather than a paper copy.
I had some commentary in the context of the italics RFC that would be worth reading as well.
I do agree we should beef up the description of the parameter for cite web/citation with website regardless. I think from a bare-bones, fill-in the parameter sense, it should say "you should at least have the domain and TLD" (couched in non-technical terms as desired). If the website has an obvious name, that is preferred but not required.
I was playing around with some "personal" websites yesterday for which I do not know if there is an easy answer, but I think those are sufficiently edge-case primary/non-independent sources that don't need a whole lot of thought in this context. --Izno (talk) 13:18, 5 September 2019 (UTC)[reply]
It is better for any guidance to match the way a verifier searches for the source. If someone tells me something was on the New York Times website, I will input "New York Times" on my favorite search engine. What comes up first, is most likely a promotional page. Under it though one sees "The New York Times - Breaking News, World News & Multimedia". This is the page's html <title>. It can be abbreviated to "The New York Times" when entered as the |website= without any semantic or cosmetic loss. If I search for "NFL", one of the top results is the actual website. The website's landing page's title is "NFL.com - Official Site of the National Football League" - that is also what the pertinent search result is. Again, what comes after the dash can be omitted. So I don't think we have to agonize much about which html property is best. Just use the website's title as it comes up on a real-world search. 72.43.99.138 (talk) 13:42, 5 September 2019 (UTC)[reply]

Since the heading of this thread is "Better explanation for "website" parameter in docs" I will confine my comments to how the existing behavior could be documented, not how the parameter ought to behave.

The value of the website parameter is the title of the website, as assigned by the publisher (sometimes the author is also the publisher). The publisher is the entity responsible for the content of the website, not a web hosting service or the like.

As mentioned in other posts, it is tempting to look to the HTML title element for the title of the website. The current HTML 5 standard describes this element as

The title element represents the document's title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results. The document's title is often different from its first heading, since the first heading does not have to stand alone when taken out of context. [Internal links omitted]

But just as Wikipedia editors often are ignorant of, or defy, the documentation of parameters, website publishers often put stuff in this parameter that looks nice in a browser tab, but is not a suitable title. Furthermore, just as book publishers often display the title of books in all kinds of crazy ways on the book jacket or cover, the website publisher may display the real website title in all kinds of ways, and in various levels of the website hierarchy. It may be difficult for the Wikipedia editor to discern what the real title is.

The Wikipedia editor should inspect the website to discern what the title of the website is, using a degree of flexibility similar to the way the editor would inspect a book jacket to discern a book title. The website title should be a word or phrase that actually appears on the website. A phrase composed by the editor is a description, not a title, and is not supported by citation templates (although many printed style manuals allow a description instead of a title, with appropriate typography to inform the reader that it is not a literal title.) If the website title cannot be determined, some template other than "cite web" or "cite news" should be used, or the citation should be written without the use of templates.

The website publisher may, for branding purposes, decide to adopt a short version of the URL as the title of the website, and may also choose the shortened URL as the official name of the publisher's corporation, or may do business under the shortened URL. The shortened URL may be used as the value of the website parameter if and only if the publisher is using it as the title of the website, which is something the Wikipedia editor will have to discern by inspecting the website. Jc3s5h (talk) 13:53, 5 September 2019 (UTC)[reply]

Ok, Jc3s5h, since you have strong opinions on your belief that a snippet of text available on the web can only be part of a larger entity, a web site, and not be a standalone source in and of itself, let me ask your opinion of how we should list an academic's personal single-page web site, say for sake of example (as it's been popular in certain circles recently) http://math.mit.edu/~drew/, whose current html-encoded title is "Life, the Universe, and Everything" and whose entire content is the text "(-80538738812075974)^3 + 80435758145817515^3 + 12602123297335631^3". We could reasonably cites its author as Andrew Sutherland and its publisher as the MIT Mathematics department. Neither the person nor the organization is a website (they are, respectively, a person and an academic department, neither of which is a website). We could reasonably cite the title of the page itself as "Life, the Universe, and Everything" as its html encodes, or plausibly instead call it "Andrew Sutherland's home page" or some such. But it is not one of the official pages of MIT as a whole (an organization with a large official site but one that neither provides a clear name for the whole site nor contains Sutherland's personal page) nor of the MIT mathematics department (for the same reasons). So what grouping of pages do you think constitutes the web site that this page belongs to, what name do you think that grouping of pages should have, and by what reasoning do you come up with that name? As for your expressed opinion that the hostname of the url can be used in the website field, the community has considered that before and roundly rejected it. The site field should be a human name, not a computer identifier. What is the point of repeating parts of the url multiple times? It doesn't help anyone find anything. It's completely redundant. And if it doesn't help find or identify the resource named in the citation, it has no reason to be listed there. —David Eppstein (talk) 20:48, 6 September 2019 (UTC)[reply]
The cite web template, in its present form, is only capable of representing a titled smaller work, which is part of a titled website. So for Professor Sutherland's page, I wouldn't use a citation template at all. I'd write something like
  • Sutherland, Andrew. (n.d.). "[http://math.mit.edu/~drew/ Life, the Universe, and Everything]". Massachusetts Institute of Technology. Retrieved 6 September 2019.
which renders as
— Preceding unsigned comment added by Jc3s5h (talk • contribs)
If cite web is incapable of citing solitary web pages then it is broken. You seem to be praising that broken state, arguing that it is the only state it could be in, and (by extension) arguing that we should give up on the cite templates as unfit for purpose and unusable. I would like to think that there is still hope for continuing to use them, but this sort of dogmatism makes my hope weaker. The whole point of templates is to make things easier for human editors, but you and the other like-minded people here seem to want them to be as difficult and inflexible as possible. —David Eppstein (talk) 06:53, 7 September 2019 (UTC)[reply]
With many templates, not just citation templates, the templates get changed from time to time because a consensus forms that they should be displayed differently. Also people find ways to extract data from the templates and use the information elsewhere, such as Wikidata extracting birth and death dates from {{Infobox person}}. But that only works if parameter values are assigned in accord with the template documentation. If people assign a value that conflicts with the defined purpose because they like how the result is rendered, it will come back to bite them in the ass when the template is revised, or when some bot imports false values into Wikidata.
I have no problem with making some appropriate changes to how the template works, such as adding parameters to specify how each of the title and website-title should be rendered, with the choices being italics, double quotes, or inside square brackets (the last being for a description created by the Wikipedia editor because the author or publisher did not give the piece of writing a title). Another logic change would be to treat the website title as the title in the absence of a title parameter. Jc3s5h (talk) 11:12, 7 September 2019 (UTC)[reply]
A point about Rotten Tomatoes. Yes, it should not be italicized — no footnoting other than Wikipedia's tries to italicize it — and as WP:CITESTYLE, which allows what it calls "common sense" exceptions, even states, "Wikipedia does not [emphasis added] have a single house style"; it notes that the widley Chicago Manual of Style, which does not italicize websites, may be used here.
However, because Fandango is the parent company, some editors insist on "website=Rotten Tomatoes| publisher= Fandango", italicizing RT. That to me is like saying Marvel Comics must be italicized since Disney is the parent company. --Tenebrae (talk) 15:52, 9 September 2019 (UTC)[reply]
WP:CITESTYLE, which allows what it calls "common sense" exceptions... The words 'common sense' appear exactly twice in Wikipedia:Citing sources, the home of WP:CITESTYLE. The first is the second positional parameter in a {{redirect}} template; the second is provided by {{subcat guideline}}, a boilerplate template used in a lot of guideline pages. The word 'exceptions' occurs three times (the singular form is not used) the first in {{subcat guideline}}, the second in Wikipedia:Citing sources#How to create the list of citations and the last in Wikipedia:Citing sources#How to place an inline citation using ref tags. None of these mention italic formatting. This is not, it seems to me, much of an argument against italic formatting of 'Rotten Tomatoes' or any other website name. Rotten Tomatoes is an electronic publication of the corporate entity Fandango Media (publisher).
Yes, Wikipedia does not have a single house style and does say that the [widely used] Chicago Manual of Style ... may be used here. But, here, on this page we are discussing cs1|2. CMOS has no control over cs1|2. If you want to use CMOS in articles that you author, or edit, you are absolutely free to do so, assuming that there is consensus to support you in your efforts.
—Trappist the monk (talk) 16:21, 9 September 2019 (UTC)[reply]
I'm glad we actually agree that Wikipedia:Citing sources, of which WP:CITESTYLE is a part, says in a box at the very top that, "This page documents an English Wikipedia content guideline. It is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, [emphasis added] and occasional exceptions may apply."
RE: "None of these mention italic formatting." I find this a bad-faith argument. We've established that the Chicago Manual of Style, for one, does not italicize website names. So when WP:CITESTYLE says the Chicago Manual of Style is allowed, that means website names need not be italicized. C'mon. You know that.
And I gather you're a programmer, but could you please state this in plain English: "[W]e are discussing cs1|2. CMOS has no control over cs1|2." I know that when I use "cite web" that "website=" does not allow non-italicizing, throwing "common sense exceptions" out the window.--Tenebrae (talk) 00:26, 10 September 2019 (UTC)[reply]
A bad-faith argument? Go back and reread what I wrote. When I said: None of these mention italic formatting, I was talking about the immediately preceding sentence where I pointed out that the words "common sense" and "exceptions" appeared only in {{subcat guideline}}, the {{redirect}} template, and two subsections of WP:CITE, to wit: Wikipedia:Citing sources#How to create the list of citations and Wikipedia:Citing sources#How to place an inline citation using ref tags. None of those places mention italics.
I think that [W]e are discussing cs1|2. CMOS has no control over cs1 is plain-speak. cs1|2 is not CMOS. They are different styles just as CMOS is not ALA and CMOS is not MLA and CMOS is not Bluebook. Because cs1|2 is not CMOS, the rules that apply to CMOS do not apply to cs1|2. In the past, CMOS may have influenced the development of cs1|2. Or not, I don't know; perhaps if you troll through the archives here and the various templates and modules you can learn if and where CMOS influence is felt.
—Trappist the monk (talk) 21:57, 10 September 2019 (UTC)[reply]

So, about those required parameters...

At this point, the change that made |website= and |newspaper= (or some type of "periodical" field) in {{cite web}} and {{cite news}} has been reverted after the long discussion at ANI.

We need to discuss what the fix is going forward.

  • It is clear from those maintaining these templates that {{cite web}} and {{cite news}} should have a required periodical field (website/newspaper/work/etc.) that will populate metadata. This should not be avoided.
  • It is clear from the ANI consensus that forcing |website= and |newspaper= as an italic style ,and close to around 200-300k existing cs1 citations out there are likely using |publisher= to get a non-italic style for the name.

This confusion seems to be stemming from the assumption that websites should be treated as a periodical reference. This is true for many websites, but does not extend wholly for things like the World Health Organization. Many a discussion has been held at the MOS pages that whether website should be italicized or not, with some not so strict guidance, but enough variance that forcing websites to be in italics created problems with this change.

Understanding that before any change is done that there likely will need to be a larger RFC to confirm, and giving editors time to fix templates as needed, as well as looking for potential bot aids, there needs to be some way to resolve this.

I had at least two ideas:

  • If it is possible to add some parameter to {{citation}} that would allow the "periodical" field to not be rendered in italics. A bot could be made to convert all existing {{cite web}} and {{cite news}} that are using only |publisher= into the right parameter, and add the "no italics" flag. This seems like the easiest outside of the bot to make the automated changes.
  • Making separate templates for "non-periodical" style web and news templates, that would not use any periodical field but instead the publisher field as the key metadata one. This seems like more work for something that seems like easy add to the existing ones.

I'm sure there's other possibility and solutions. And of course, this is on reading the consensus that the ability to have non-italic website/newspaper names in the citations is what the community wants. But this is a discussion that should happen now, now that we have resolved the immediate issue. --Masem (t) 03:45, 7 September 2019 (UTC)[reply]

It is clear from the ANI consensus that forcing No, no it's not. You don't get to establish a false premise as an end-run around the consensus established at the proper location and place (above) on that point. The only real consensus from a content/style POV that discussion indicates is that people don't like errors showing up in their articles (whether deserved or not). --Izno (talk) 04:06, 7 September 2019 (UTC)[reply]
The italics thing is a red herring, and periodicals are not required by any standards. If there's a periodical, or a work, emit that metadata. If there's a publisher, emit that metadata. Neither are required, because many online things are neither part of a work, of a periodical, nor necessarily have a publisher. Headbomb {t · c · p · b} 06:23, 7 September 2019 (UTC)[reply]
I disagree to a point, that the italics aspect (more specifically the presumption that WP has in practice treated cite web's as periodical citations by default) was a major point of contention that was not part of any of the discussion into the Sept 2 changes. (Making "website" italic was discussed in the RFC). Trappist stated several times at ANI that they thought, if we were citing a report from the WHO, it should appear as the italicized |website= and not as |publisher=, which was a point of contention in the changes (not just the error message issue). Clearly there was a disconnect between those maintaining cs1 and those using cs1 for how this should apply, and - if there is a need to fill metadata - that requires figuring out how to normalize the templates. Yes, the status quo is "fine" but there sounded like there were core technical reasons to make the change for metadata filling. --Masem (t) 15:42, 7 September 2019 (UTC)[reply]
My opinion has not changed: I believe that World Health Organization is the eponymous publication of the corporate entity (publisher) World health Organization. It would seem that WHO agrees. If you look in the source for Female Genital Mutilation (the page used as an example at the WP:AN discussion) you will find this: \"SiteName\":\"World Health Organization\".
—Trappist the monk (talk) 19:46, 7 September 2019 (UTC)[reply]
A World Health Organization report is a government-type document (which is fixed, and may be available as a PDF or in HTML at a given URL, but which is still a report if it is in hard copy), right? Then {{cite report}} should be used instead! Would switching that over take care of a big chunk of the ANI debate? --Doncram (talk) 02:18, 8 September 2019 (UTC)[reply]
Masem You appear to be assuming that, when a cite web has a publisher but no website, that it can only have been done that way to avoid the italics that using website would create. That assumption is wrong and an extreme failure of WP:AGF. It is completely legitimate to use publisher= for a cite web, listing the name of an organization that published the website. It would in many cases be incorrect to assume that field to merely be a workaround for the website italics. For instance, if I were to cite "Help talk:Citation Style 1" with a publisher of "The Wikimedia Foundation", it would be grossly incorrect to think that I really meant that the website on which I found Help talk:Citation Style 1 had "The Wikimedia Foundation" as the name of its web site. (In this example, the web site is Wikipedia, not Wikimedia.) You also seem to be reading the consensus of the AN (not ANI) discussion completely backwards: It is clear that most of the discussants don't give a fuck about italic vs non-italic website name formatting, and just want their perfectly valid and non-erroneous web-page-but-no-website citations to render without complaints. —David Eppstein (talk) 06:45, 7 September 2019 (UTC)[reply]
There is absolutely no need for {{cite web}} or {{cite news}} to require a publisher. It may be required in some cases (e.g. The Eastern Daily Press newspaper is published by Archant Media Ltd). {{cite web}} does require an |url=, whereas it is an optional parameter in {{cite news}}. That is how is should be. There is no need to change it. Neither requires a mandatory|periodical= field. Mjroots (talk) 08:04, 7 September 2019 (UTC)[reply]
Pretty sure that this discussion is not about requiring |publisher= as that was not the issue at WP:AN. |publisher= is optional and allowed in all cs1|2 templates except the preprint templates {{cite arxiv}}, etc.
—Trappist the monk (talk) 19:46, 7 September 2019 (UTC)[reply]
Pretty sure that it is, at least in part, because that was one of the causes of the error messages. It really messed up a load of articles before the category was hidden. Mjroots (talk) 06:00, 8 September 2019 (UTC)[reply]
That is just not true. |publisher= has never been a required parameter. There is / was no Cite <template> requires |publisher= error message.
The requirements imposed by {{cite news}} and {{cite web}} were for some sort of periodical parameter. Those error messages were:
Cite news requires |newspaper=
Cite web requires |website=
The presence or absence of |publisher= played no part in the determination to display these two error messages. During the WP:AN discussion, it was these error messages that were hidden, not the category (Category:CS1 errors: missing periodical)
—Trappist the monk (talk) 09:21, 8 September 2019 (UTC)[reply]
@Masem:, would you please state what metadata is being emitted, and provide links to the standard that defines the metadata? Jc3s5h (talk) 16:33, 7 September 2019 (UTC)[reply]
My understanding is the TemplateData stuff at the bottom of the documentation for {{citation}} ( eg Template:Citation#TemplateData ) --Masem (t) 16:45, 7 September 2019 (UTC)[reply]
I think the templatedata is for the visual editor. Only a few of those parameters have COinS metadata. The {{cite web}} ones are listed at Template:Cite_web#COinS.   Jts1882 | talk  17:00, 7 September 2019 (UTC)[reply]
TemplateData is a poorly conceived blend of program-control and pseudo documentation. Except that it exists on cs1|2 template doc pages to support that abomination that is ve, cs1|2 has nothing, absolutely nothing to do with TemplateData. If you think that I have strong opinions about those things, you would be right.
For the metadata standard, see Module talk:Citation/CS1/COinS where there are links to the documentation that I have been able to find.
—Trappist the monk (talk) 19:46, 7 September 2019 (UTC)[reply]
A right proper opinion. ♦ J. Johnson (JJ) (talk) 20:07, 7 September 2019 (UTC)[reply]
Speaking anecdotally, but I sometimes use |publisher= in lieu of |website= only because it strikes me as more useful. I have never cared about whether it produces italics or not and I don't think that is the main problem here. Jo-Jo Eumerus (talk, contributions) 08:44, 8 September 2019 (UTC)[reply]
I'd probably ask the question, "Should |website= be a) deprecated, b) contain the hosting website and be mandatory (i.e even if |publisher= is present), c) contain the hosting website and be supplantable with |publisher=? And if c) is implemented, what kind of information should go into |publisher= and what kind of information goes into |website=?" Or something else. Jo-Jo Eumerus (talk, contributions) 08:44, 8 September 2019 (UTC)[reply]
Either deprecated (the simplest solution given it's so problematic) or made flexible so that non-periodical websites can be non-italicized. Despite what some have suggested, Wikipedia MOS has no requirement that website names be italicized. Yet one editor with programming skill makes the extremist argument that everything online — even organizations like the World Health Organization or Sears — be treated as periodicals and italicized. That is unlike any footnoting I've ever seen and contrary to things like the very widely used Chicago Manual of Style. There's no reason for Wikipedia to adopt an eccentricity.--Tenebrae (talk) 14:40, 9 September 2019 (UTC)[reply]
That would be me (I am not Voldemort, my name may be spoken).
MOS does not apply to citations. If it did, then en.wiki's own WP:CITESTYLE would be invalid. cs1|2, like it or not, has a style that has developed organically to suit en.wiki's needs. Certainly cs1|2 have been influenced by CMOS, APA, MLA, and who knows what else but, cs1|2 is none of these styles. Yep, World Health Organization and Sears are eponymous electronic publications (websites) of the corporate entities that are their publishers. As the eponymous name, or title, if you will, these names are italicized.
—Trappist the monk (talk) 15:19, 9 September 2019 (UTC)[reply]
I just find it remarkable that you seem to be saying WP:CITESTYLE does not apply to citations.
WP:CITESTYLE specifically says we can use Chicago Manual of Style, which does not italicize websites. But your programming for our citation styles does not allow this. Your citation formats essentially say we're forbidden to use Chicago Manual of Style.
FYI, I phrased it as "one editor with programming skill" so as not to personalize my argument. The salient point isn't who, but the fact that some editors can program, others cannot, and that distinction seems to be playing out.--Tenebrae (talk) 21:39, 9 September 2019 (UTC)[reply]
I wrote MOS does not apply to citations (emphasis added). MOS may not, on the one hand, permit any consistent citation style (WP:CITESTYLE) and then on another hand dictate how that citation style must be used. This, I think, is the point you are trying to make at Wikipedia talk:Citing sources § RfC appears to contradict MOS here. cs1|2, like it or not, are styles (after all they are named Citation Style 1 and Citation Style 2).
Yes, you can use CMOS, or APA, or MLA, or even Bob's Special Citation Style++ as long as you are consistent in the use of it within an article. None of these styles are cs1|2. Two or three years ago I tried an experiment that would have used |mode=mla to render a few ({{cite book}}, {{cite journal}}, and one or two others) in MLA format. The experiment 'worked' but the code to make it work was such a tangle that it would have made maintenance of the code base worse than it already is. The experiment was backed out and I hope will never be repeated.
—Trappist the monk (talk) 23:29, 9 September 2019 (UTC)[reply]
Trappist the monk, re: "Yep, World Health Organization and Sears are eponymous electronic publications (websites) of the corporate entities that are their publishers", that would be a style error. The onus is on you at this point to produce a reputable style guide that supports you. The Supreme Court of the United States is not the name or title of this website. SarahSV (talk) 22:33, 9 September 2019 (UTC)[reply]
What is a style error? According to whom?
Tell me why 'Supreme Court of the United States' is not the name of the court's website. Right there at the top of the page you linked (in the position that would be the masthead of a newspaper or a magazine or a journal were we looking at a paper copy and where those publications place their names) it says, in large white letters over a blue-gray background: 'Supreme Court of the United States' and this appears to be placed at the top of every html page at the site. Similarly, in the 'masthead' on every html page at https://www.who.int, in large blue text over a white background: 'World Health Organization'. Both look like names to me; yeah, the names are also the names of the organizations so eponymous electronic publications of their individual publishers.
cs1|2 (I keep repeating this, why?) is not any of the reputable style [guides] mentioned here and at WP:CITESTYLE. Certainly it was influenced by the reputable style [guides] but does not adhere to any particular one or group of them. Website titles have been italicized by {{cite web}} since its inception (15 years ago).
—Trappist the monk (talk) 23:29, 9 September 2019 (UTC)[reply]
Because the website is supremecourt.gov and who.int, and 'Supreme Court of the United States' and 'World Health Organization' are their publishers. Headbomb {t · c · p · b} 23:36, 9 September 2019 (UTC)[reply]
Trappist, the problem is that you, personally, are inventing new style rules, where (a) there's no need; (b) there's no consensus; and (c) the new rules show a misunderstanding of the concept title. You could also say "let's not ever capitalize letters in book titles, including the first letter", or "let's always italicize authors' names". Those would be style errors too, according to everyone. Similarly, Supreme Court of the United States is not a title.
The thing you're grappling with is that most websites don't have names, so there is no title, i.e. there is nothing that needs to be italicized. You disagree with that: you believe they all ought to have names. But as a matter of fact, they don't. Their owners did not name them. In those cases, and that is most cases, we name the publisher. SarahSV (talk) 23:46, 9 September 2019 (UTC)[reply]
You wrote this declarative sentence: The Supreme Court of the United States is not the name or title of this website. I asked you to tell me why that name is not the name of the court's website. You have not answered that question but instead, concocted speculative 'rules' about title capitalization and author-name font as examples of style errors. Then you wrote: Similarly, Supreme Court of the United States is not a title. Similar to what? How do your concocted rule examples tell me why Supreme Court of the United States is not the name of the court's website?
If I have a misunderstanding of the concept title, write something that will give me that understanding. Simply making declarative statements that Supreme Court of the United States (or World Health Organization) is not a title does not help anyone to understand why you are so certain that they are not titles.
—Trappist the monk (talk) 17:57, 10 September 2019 (UTC)[reply]
Because nobody refers to supremecourt.gov as "Supreme Court of the United States", or by any other title. It's "the Supreme Court's website", unnamed, untitled. In the below examples, green text signifies quotes from the sources provided, and not quotes from TTM.
  • New York Times: announcing that the Supreme Court’s website would start posting briefs
  • US News: a separate statement posted on the Supreme Court's website
  • Fox News: posted on the Supreme Court's website in the early afternoon
  • Forbes: The Court’s opinion is available on its website
Have you any counter examples? – Levivich 18:13, 10 September 2019 (UTC)[reply]
So you are suggesting that there is a formality criterion now? A website title is only a title when it can be used formally or informally in everyday journalism-speak? That a 'proper' website title would be used in preference to allusions or references to the entity's website ('its website', 'the <entity's> website'). Really?
—Trappist the monk (talk) 22:34, 10 September 2019 (UTC)[reply]
Concur with SarahSV. This is seeming more and more like one editor's crusade, and italicizing all website names is neither required by WP:CITESTYLE nor is it mainstream. For example, see the APA, Harvard and MLA examples here, none of which italicize the website name. --Tenebrae (talk) 00:15, 10 September 2019 (UTC)[reply]
All websites must have "names", even when these "names" are not human-friendly. Please don't repeat stuff that just isn't so. The bottom line is that citations have their own style which is related to their utility. Don't try to mix the two, citations are not about prose, and they don't concern themselves with aesthetics. They are not there to make an article pretty, they are there to make it relevant. Because "SaraSV" or "Tenebrrae" or my IP mean exactly nothing otherwise. They can be standardized for the benefit of editors, but they must be presented from the POV of their users. If you believe that this view of citations is limiting, by all means use your own presentation. And let others use the tools that suit them. 108.182.15.109 (talk) 12:42, 10 September 2019 (UTC)[reply]
Just a reminder: There was an RfC here on this page (still recorded above) that closed about two weeks ago that concluded (at 15:49, 26 August 2019 (UTC)) that "an overall consensus exists here that names of websites in citations/references should be italicized". The RfC was widely advertised (at Help talk:Citation Style 2, Template talk:Citation, Wikipedia talk:Citing sources, Wikipedia talk:Citation templates, Wikipedia talk:Manual of Style, Wikipedia:Village pump (policy) and with a long-open Administrator Noticeboard request for closure. The RfC was open for more than a full month before it was concluded. The editor in question who was not named did not initiate that RfC, and did not close it, and as far as I have noticed after a quick look, did not express an opinion in it. I therefore don't see a one-editor crusade here. —BarrelProof (talk) 16:30, 10 September 2019 (UTC)[reply]
Yes, but that RfC didn't say anything about making |website= or |newspaper= required parameters. One possible outcome, in line with the RfC, is that |website= is either in italics or blank. It's the "not blank" thing that seems to be one editor's thing, in my view, not the italics thing. – Levivich 16:58, 10 September 2019 (UTC)[reply]
OK, but the comment that I replied to was complaining about a "one editor's crusade" for "italicizing all website names". That initiative was not coming from one editor. And I think it is arguable that the help guidance already said that the "website"/"work" parameter was more necessary and fundamental to citations than the "publisher" parameter, and that a lot of people seem to have been using "publisher" and leaving the "work" parameter empty to avoid italics. —BarrelProof (talk) 17:23, 10 September 2019 (UTC)[reply]
Are you saying the RfC close now means the Chicago Manual of Style — which does not italicize websites in footnoting — is now no longer ever allowed for citations? I ask you to clarify. --Tenebrae (talk) 18:54, 10 September 2019 (UTC)[reply]
No, I'm not. I think the RfC applies when the Wikipedia CS1 citation style and its templates are used but not when CMOS citation style is used. —BarrelProof (talk) 19:57, 10 September 2019 (UTC)[reply]
OK. Whew! I think we have common ground ... because I have run across one editor who believes that the RfC here means "There was already an RFC about this, and it was decided to italicize websites. That can not be overriden...." (Also, when I went to WP:CMOS I got WikiProject Comics, and when I went to CMOS I got a page for complementary metal–oxide–semiconductor. Can you point me to the page for CMOS citation style?)
So this is everyone's understanding? That WP:CITESTYLE allows us to use Chicago Manual of Style and we're free to, but just not with the "cite web" template? --Tenebrae (talk) 20:45, 10 September 2019 (UTC)[reply]
My understanding is that the RfC implicitly only applies to the Wikipedia CS1|2 styles (and their associated templates) and that there is no plan to change WP:CITESTYLE as a result of it. As the authority on the CMOS/Chicago style, WP:CITESTYLE refers to The Chicago Manual of Style and that article refers to some printed books and a website at https://www.chicagomanualofstyle.org/. —BarrelProof (talk) 22:26, 10 September 2019 (UTC)[reply]
This is drifting a little off-topic, but I noticed something at https://www.chicagomanualofstyle.org/. I hope it is generally accepted that Wikipedia MOS guidance on typographical conformity applies to the formatting of titles that are quoted in citations (MOS:QUOTE, MOS:CONFORM, MOS:DASH, MOS:INOROUT, MOS:ITALPUNCT), and that the spirit of this aspect does not vary with the choice of citation style. —BarrelProof (talk) 23:12, 10 September 2019 (UTC)[reply]

When I waded through the chain of links within Wikipedia pages in the article and WP: space, I found myself at Z39.88-2004: The OpenURL Framework for Context-Sensitive Services The Key/Encoded-Value (KEV) Format Implementation Guidelines. These have different metadata keys for different so-called generes. Examples include

&rft.atitle=Isolation of a common receptor for coxsackie B
A title of a journal article
&rft.jtitle=Science
A title of a journal
&rft.btitle=Professional XML Meta Data
A book title

So it strikes me that {{cite web}} is emitting false metadata whenever the website is not a periodical. Due to the pervasive use of cite web for all kinds of things, I suggest that {{cite web}} be modified to not emit any metadata, to avoid emitting falsehoods. Jc3s5h (talk) 17:17, 10 September 2019 (UTC)[reply]

All cs1|2 templates emit metadata. Because the metadata standard does not directly support web citation objects, and because {{cite web}} renders stylistically like a journal citation, we use the COinS journal object with rft.genre set to unknown. For completeness:
rft.genre=article – {{cite journal}}, {{cite magazine}}, {{cite news}}
rft.genre=conference – {{cite conference}} when a periodical parameter is set
rft.genre=preprint – {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, {{cite ssrn}}
—Trappist the monk (talk) 22:12, 10 September 2019 (UTC)[reply]
It seems to me that styling the citation for a non-periodical is not as serious as emitting metadata that declares the non-periodical is a periodical. Readers tend to be more flexible than software. Jc3s5h (talk) 01:45, 11 September 2019 (UTC)[reply]

Use of |id= instead of |url= breaks |url-access= and |access-date=

I noticed in a reference to an old newspaper I added, through ProQuest, that someone changed |url=https://search.proquest.com/nahs/docview/344377835 to |id={{ProQuest|344377835}} but now using |url-access= and |access-date= creates an error message that there's no url - which makes me wonder if it's better off the way it was. Is there any other option - or an error suppression flag? Nfitz (talk) 21:49, 8 September 2019 (UTC)[reply]

No templates in section headers please.
Better off the way it was if you want the access icon and access date. These make no sense with out a value in |url=.
—Trappist the monk (talk) 22:06, 8 September 2019 (UTC)[reply]

Well ProQuest contains papers which were published in print; it's not like the access-date would be useful since it's not like it could change like other websites. For the same reason we don't have |jstor-access-date=, |doi-access-date=, etc. And just like DOIs, JSTOR IDs, etc., the default is that it's assumed a ProQuest link requires a subscription to access papers. So I'm not sure why it's necessarily better to say when you accessed a given paper via ProQuest or to use |url= and |url-access=subscription instead of just a ProQuest ID. Umimmak (talk) 23:24, 10 September 2019 (UTC)[reply]

Proposed module change: change static text relative to presentation of person roles, and related error message

The discussion "Seeking advice" on this page prompted a look at how the module presents some person roles (author, contributor and editor). I believe current presentation is confusing in a couple of cases. If memory serves, this has been remarked on before.

The examples below use {{cite book}}, but the template application is immaterial.
1. A book by an author, book edited by an editor
{{cite book|author=Author|editor=Editor|title=Title}}
displays: Author. Editor (ed.). Title. {{cite book}}: |author= has generic name (help) - OK
2. A chapter in a book by an author
{{cite book|author=Author|chapter=Chapter|title=Title}}
displays: Author. "Chapter". Title. {{cite book}}: |author= has generic name (help) - OK
3. A chapter in a book by an author, book edited by an editor
{{cite book|author=Author|chapter=Chapter|editor=Editor|title=Title}}
displays: Author. "Chapter". In Editor (ed.). Title. {{cite book}}: |author= has generic name (help) - NOT OK. I believe the editor role should be presented as in #1.
4. A contribution in a book by an author
{{cite book|author=Author|contributor=Contributor|contribution=Contribution|title=Title}}
displays: Contributor. "Contribution". Title. By Author. {{cite book}}: |author= has generic name (help) - OK
5. A contribution in a book by an author, book edited by an editor
{{cite book|author=Author|contributor=Contributor|contribution=Contribution|editor=Editor|title=Title}}
displays: Contributor. "Contribution". Title. By Author. Editor (ed.). {{cite book}}: |author= has generic name (help) - OK
6. A contribution in a collection supervised by an editor
{{cite book|contributor=Contributor|contribution=Contribution|editor=Editor|title=Title|}}
displays: Editor (ed.). "Contribution". Title. {{cite book}}: |contributor= requires |author= (help); |editor= has generic name (help) - NOT OK. I believe that there should be no error, and the static text should include "In" editor. "Author" is not really relevant here. "In editor" should be enough to show this as an edited collection of contributions.
7. A contribution in a book by many authors, book edited by an editor
{{cite book|author1=Author1|author2=Author2|author3=Author3|contributor=Contributor|contribution=Contribution|editor=Editor|title=Title|}}
displays: Contributor. "Contribution". Title. By Author1; Author2; Author3. Editor (ed.). {{cite book}}: |author1= has generic name (help); Cite has empty unknown parameter: |1= (help)CS1 maint: numeric names: authors list (link) - OK

72.43.99.130 (talk) 15:48, 9 September 2019 (UTC)[reply]

There seem to be two proposed changes here (3 and 6).
In 3, it is not clear what presentation is desired.
As for 6, I agree that |contribution= should be allowed with |editor=. That would allow us to present citations of separately-authored prefaces of edited books in a consistent way to those of authored books. In fact, I would make |contribution= an alias of |chapter=. (Other changes would be required for full consistency, though). Kanguole 18:29, 9 September 2019 (UTC)[reply]
Does CMS or any other style guide with citations similar to ours provide guidance on this issue? —David Eppstein (talk) 19:08, 9 September 2019 (UTC)[reply]
For #3, what is asked is to omit "In", instead to reserve this for edited collections. Somewhat related to #6, where "In" would signify that the editor in such cases acts more as a curator, like the supervisory editor of an encyclopedia or the senior editor of a collection of research papers. Recently, there have been additional comments at #Proposal for an "in-title" ("In" + title) parameter. 108.182.15.109 (talk) 12:05, 10 September 2019 (UTC)[reply]
But #3 does designate an author's chapter in an edited collection. Kanguole 12:43, 10 September 2019 (UTC)[reply]
That is a book by a single author, edited by an editor. In an edited collection, the editor usually determines the collection's roster of contributors and/or selects their works. As remarked, s/he acts more as a curator. The contributors are "in" hers/his collection. 108.182.15.109 (talk) 12:49, 10 September 2019 (UTC)[reply]
No, #3 really is a chapter in an edited collection of chapters by different authors, not an authored book. You have misunderstood what that form is used for, which is apparently the source of our disagreements above. Kanguole 13:11, 10 September 2019 (UTC)[reply]
Are you saying that any citation of a chapter in a book that has an editor (that's practically all of them) must necessarily mean that the work in question is an edited collection? Why? 108.182.15.109 (talk) 13:19, 10 September 2019 (UTC)[reply]
I'm saying that we use form #3 for authored chapters in edited collections, e.g. the sixth example in Template:Cite book/doc#Examples (a bit like APA citation style). Kanguole 13:24, 10 September 2019 (UTC)[reply]
Aren't "authored chapters in edited collections"... contributions? #3 cites a chapter in a book by a single author. For any or no reason, the writer of the citation has decided to add the book's editor, as s/he has a right to do. This form has been used extensively for the purpose. How else would you cite a chapter in a book by a single author? 108.182.15.109 (talk) 13:46, 10 September 2019 (UTC)[reply]
They are indeed contributions, but |chapter= was in use for separately-authored parts of edited collections for a long time before |contribution= was introduced for separately-authored parts of authored books (with inconsistent formatting, as I've said above). You are simply mistaken about how this form of the template is used. Kanguole 14:07, 10 September 2019 (UTC)[reply]
|chapter= was also in use for separately-authored parts of edited collections for a long time before |contribution= was introduced. That is one of the reasons the contributor (vs. author) parameter-group was introduced, to distinguish then from citations of chapters in single-authored or multi-authored books. A collection however is not a book with many authors. It does have separately authored parts. But no single author can take credit for the entire work, that is the job of the editor who assembled the collection. 108.182.15.109 (talk) 14:19, 10 September 2019 (UTC)[reply]

Proposal to change redirects

{{Cite document}}, {{Cite paper}}, and {{Citepaper}} all redirect to {{Cite journal}}. Since {{Cite document}}, {{Cite paper}}, and {{Citepaper}} are not likely to have the |journal= parameter populated, these citations will generate the Cite journal requires |journal= error. Would it be better to have {{Cite document}}, {{Cite paper}}, and {{Citepaper}} to redirect to {{Cite report}} instead to avoid the error? Thanks! GoingBatty (talk) 02:01, 10 September 2019 (UTC)[reply]

We might have to do something about the default "(Report)" text that appears in {{Cite report}}. See this section above for a related discussion. – Jonesey95 (talk) 02:19, 10 September 2019 (UTC)[reply]
We might also need to discuss the formatting of the title of a report. For some reports/papers/documents, because of their lengths, they'd be considered long-form documents that should be titled in italics. Some would be short enough to be a short-form document and should be titled in quotation marks. Imzadi 1979 → 02:51, 10 September 2019 (UTC)[reply]
I wonder if there is a need to distinguish the work as short-form/long-form. It adds code overhead, and the dissimilar formatting of the same argument can be confusing. I think the presentation of all aliases of the same parameter should be presented uniformly, in this case by applying emphasis. With apologies to the OP for the unrelated comment. 108.182.15.109 (talk) 12:16, 10 September 2019 (UTC)[reply]
Personally, when citing reports, I use {{cite book}} with |type=Report so that the title renders in italics. (It's rare that I'd cite something that qualifies as a report that's also short enough to be considered a short-form document, and in those few cases, I err on the side of consistency with the rest and go italics.) Imzadi 1979 → 03:59, 12 September 2019 (UTC)[reply]
I think that I'm opposed to this because presumably, editors who used those templates didn't want {{cite report}} and just repointing those redirects will break something. You might guess that I'm a bit sensitive to broken stuff right now ...
I would be in favor of eliminating these redirects and any others that point to {{cite journal}} (and, for that matter to the other cs1 templates). Then, if we decide that we need a {{cite document}} template, we create one.
—Trappist the monk (talk) 22:52, 10 September 2019 (UTC)[reply]

Should we exclude Template:Cite AV media notes from CS1 maint: others category?

{{Cite AV media notes}} uses |others= for the name of the recording's artist, and media notes often do not have a listed author. Here's an example pulled from a real article:

Cite AV media notes comparison
Wikitext {{cite AV media notes|id=B0021921-02|location=United States|others=Tove Lo|publisher=[[Universal Music Group]]|title=Queen of the Clouds|titlelink=Queen of the Clouds|type=liner notes|year=2014}}
Live Queen of the Clouds (liner notes). Tove Lo. United States: Universal Music Group. 2014. B0021921-02. {{cite AV media notes}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)CS1 maint: others in cite AV media (notes) (link)
Sandbox Queen of the Clouds (liner notes). Tove Lo. United States: Universal Music Group. 2014. B0021921-02. {{cite AV media notes}}: Unknown parameter |titlelink= ignored (|title-link= suggested) (help)CS1 maint: others in cite AV media (notes) (link)

The example categorizes the article in Category:CS1 maint: others, but this seems like a valid – and from the documentation and category population, widespread – usage.

Should we exclude Template:Cite AV media notes from the CS1 maint: others category? That would help us focus our analysis of potential problems on citations that are actually missing useful, available information. – Jonesey95 (talk) 18:56, 10 September 2019 (UTC)[reply]

What we really should do is spend some time rewriting {{cite AV media}}, {{cite episode}}, {{cite serial}} so that they properly handle name lists: don't use aliases of |authors= and don't misuse |others=. I've been saying this on and off for a long time.
—Trappist the monk (talk) 22:44, 10 September 2019 (UTC)[reply]

Support year-suffix outside the English alphabet

Accordind to the sfn documentation (More than one work in a year)

When {{sfn}} is used with {{citation}} or Citation Style 1 templates, a year-suffix letter may be added to |date= for all accepted date formats except year initial numeric (YYYY-MM-DD). It is not necessary to include both |year= and |date=. If both are included, |year= is used for the CITEREF anchor to be compliant with legacy citations.

Also with regard to the direct use of CITEREF the following advice is given

Please consider keeping reference names simple and restricted to the standard English alphabet and numerals

The function check_date (Module:Citation/CS1/Date validation) takes proper care of the optional suffix, but in an unsatisfactory way. People find natural, if not normative, to suffix the year with letters from their native alphabet.

Hence

{{cite book |last=Αργυρίου |first=Αλέξανδρος |title=Ιστορία της ελληνικής λογοτεχνίας και η πρόσληψή της στα χρόνια του Μεσοπολέμου (1918-1940) |volume=τ.Αʹ |publisher=Εκδόσεις Καστανιώτη |location=Αθήνα |year=2002α |isbn=978-960-03-3156-1 |ref=harv}}

will produce this, because the year is suffixed with a greek alpha

Αργυρίου, Αλέξανδρος (2002α). Ιστορία της ελληνικής λογοτεχνίας και η πρόσληψή της στα χρόνια του Μεσοπολέμου (1918-1940). Vol. τ.Αʹ. Αθήνα: Εκδόσεις Καστανιώτη. ISBN 978-960-03-3156-1. {{cite book}}: Invalid |ref=harv (help)

There is nothing wrong with the matching pattern, it is the use of the standard string library instead of ustring that breaks things (lines 564-5).

Is this a "feature" (a rather awkward one if you ask me) or an omission? paa (talk) 09:14, 11 September 2019 (UTC)[reply]

I’m confused, would using, e.g., 2002α, 2002β, 2002γ, to disambiguate Harvard style citations be limited to the Greek language version of Wikipedia? Or are you suggesting that the Greek alphabet be used even on the English Wikipedia to disambiguate citations which were published in Greek? Umimmak (talk) 09:55, 11 September 2019 (UTC)[reply]
I'm saying that the use of the standard string library implicitly enforces a choice that doesn't make sense to wikis whose alphabet is based on non-Latin script. Making this specific check with ustring keeps everybody happy paa (talk) 10:21, 11 September 2019 (UTC)[reply]
This issue initially raised at el:Βικιπαίδεια:Αγορά#Cite_book. Is there some reason why en.wiki should not allow non-Latin CITEREF disambiguators?
—Trappist the monk (talk) 10:34, 11 September 2019 (UTC)[reply]

Fixed in the sandbox, I think. Also required a fix to Module:Footnotes/sandbox:

{{harv/sandbox|Αργυρίου|2002α}} → (Αργυρίου 2002α)

Cite book comparison
Wikitext {{cite book|first=Αλέξανδρος|isbn=978-960-03-3156-1|last=Αργυρίου|location=Αθήνα|publisher=Εκδόσεις Καστανιώτη|ref=harv|title=Ιστορία της ελληνικής λογοτεχνίας και η πρόσληψή της στα χρόνια του Μεσοπολέμου (1918-1940)|volume=τ.Αʹ|year=2002α}}
Live Αργυρίου, Αλέξανδρος (2002α). Ιστορία της ελληνικής λογοτεχνίας και η πρόσληψή της στα χρόνια του Μεσοπολέμου (1918-1940). Vol. τ.Αʹ. Αθήνα: Εκδόσεις Καστανιώτη. ISBN 978-960-03-3156-1. {{cite book}}: Invalid |ref=harv (help)
Sandbox Αργυρίου, Αλέξανδρος (2002α). Ιστορία της ελληνικής λογοτεχνίας και η πρόσληψή της στα χρόνια του Μεσοπολέμου (1918-1940). Vol. τ.Αʹ. Αθήνα: Εκδόσεις Καστανιώτη. ISBN 978-960-03-3156-1. {{cite book}}: Invalid |ref=harv (help)

—Trappist the monk (talk) 10:34, 11 September 2019 (UTC)[reply]

Trappist the monk asked "Is there some reason why en.wiki should not allow non-Latin CITEREF disambiguators?" Yes. These disambiguators are usually (always?) associated with a list of sources in alpha-numeric order, where they are sorted first by author name(s), and with the date as a tie-breaker. All editors of the article will have occasion to re-sort the list as new sources are added. Thus the disambiguation characters should be letters of the Roman alphabet so that all editors will be able to insert new sources at their proper place in the list. It will also aid readers who are reading a version of the article which has been printed on paper, so that references to sources must be followed manually.
It's an open question whether this is a limitation that should just be documented, giving gnomes license to manually or semi-automatically convert non-Roman characters to Roman, or if it should be enforced by the citation software. Jc3s5h (talk) 16:17, 11 September 2019 (UTC)[reply]

This edit assisted by (made by?) by OAbot seems to have generated a parsing error in cite journal by adding a url parameter. I suppose it is the prior presence of "title-link", which might itself have been a misuse but one that wasn't flagged and seemed functional. Thank you for maintaining our citation templates so well. It's a pity some users are less ... Thincat (talk) 09:45, 11 September 2019 (UTC)[reply]

That template should emit an error message because you can't link |title= to two different targets. |title-link=s:Mount Everest: The Reconnaissance is a perfectly valid link into WikiSource. cs1|2 might handle this particular error a bit better by choosing either of |title-link= or |url= to link |title=. Which should it be? When more than one link target is present, it's still an error so there will be some sort of message.
OAbot should not be adding |url= to a cs1|2 template when that template has a valid title link so you should raise this issue at User talk:OAbot.
—Trappist the monk (talk) 11:11, 11 September 2019 (UTC)[reply]
Thank you, I will do that. Thincat (talk) 11:21, 11 September 2019 (UTC)[reply]

Multiple url instances

This is currently allowed:
{{cite book|author=Author|url=http://example.com|chapter-url=http://example.com/chapter1|title=Title|chapter=Chapter}}
Author. "Chapter". Title. {{cite book}}: |author= has generic name (help)
Is not the appearance of multiple urls superfluous? All that is needed to verify the citation would be one url, the more specific one (chapter location) being the obvious choice.
I am bringing this up because User:InternetArchiveBot apparently ignores in-source urls, as in this: diff
Results in clutter. I am bringing it here because if multiple urls were disallowed the bot would not be able to make the edit as effected.
24.105.132.254 (talk) 16:16, 11 September 2019 (UTC)[reply]
We allow multiple links in citations (e.g. DOI, PMID, PMC, URL, chapter, wikilinks, even links in |pages=). One editor's superfluity is another editor's helpful additional link. – Jonesey95 (talk) 18:53, 11 September 2019 (UTC)[reply]
Understood, but what you describe are different links to the source via different providers. The problem concerns urls to the same site via the same provider, which is also allowed. In the OP, |url= links the source's title/home page, and |chapter-url= uses the same link modified to locate a sub-page. This seems superfluous. The IA bot adds |url= even when an in-source location url (in the diff example, a chapter url) is already present. The source link is of course published by the same provider (the Internet Archive) in both cases. Obviously, the bot would not be able to do this if multiple instances of the same website were disallowed in a citation. 65.88.88.91 (talk) 20:07, 11 September 2019 (UTC)[reply]
Not superfluous, as sometimes it is useful to link to both the chapter, and the book or report containing it. As a particular case: the chapter-url can be used to link directly to a pdf, while the report url could link the webpage that has information about the report. At any rate, the use of both is widespread, and disallowing it would result in a lot of breakage. ♦ J. Johnson (JJ) (talk) 20:02, 13 September 2019 (UTC)[reply]

Remove |url= when |doi= is provided

Per User talk:Citation bot/Archive 18#"Removed URL that duplicated unique identifier", if |url= should be removed when a |doi= is provided, then per Masem's comment in that thread, shouldn't CS1 throw an error for the former rule, particularly in {{cite journal}}? czar 17:32, 14 September 2019 (UTC)[reply]

CS1/2 can not know where a DOI URL points. --Izno (talk) 17:36, 14 September 2019 (UTC)[reply]
And by the same logic, you can't be sure ever be sure where a DOI will point at any particular time; the purpose of DOIs is to provide a fixed way of accessing a URL that can change. For this reason, I'm not sure that it's right to remove a URL that happens right now to be where a DOI points. Peter coxhead (talk) 20:36, 14 September 2019 (UTC)[reply]
I know when citing IUCN it’s recommended to make use of both |doi= and |url= because A DOI links to a permanent web page with a specific year's assessment that will never be updated, so when a new assessment is issued, a new DOI will be created and the old one will then point to the previous assessment. An ID-based URL should always link to the current assessment, but that URL is not guaranteed to work indefinitely. Thus, it is probably best to use both, and to use the ID-based URL if only one URL will be used. But I do think in general it’s probably redundant and cluttered to have a DOI and the present address the DOI resolves to in the |url= field. The linked discussion began with examples like |url=http://www.sciencedirect.com/science/article/pii/S0277539513000915 with |doi=10.1016/j.wsif.2013.05.012. I’m not sure I see the issue with removing those sorts of |url=s. But I agree that this shouldn’t be treated as a CS1 error—particularly as the |url= often provides a different, typically free, way to access a paper. Umimmak (talk) 23:45, 14 September 2019 (UTC)[reply]
Peter coxhead I actually deliberately chose not to make a comment in that direction; mine was solely regarding what is technically possible. The module cannot access pages offwiki, which means it cannot verify for itself that a DOI at a referrer link resolves to the same location as the URL. It's a separate consensus discussion treating the question of whether such links matching the resolved DOI should be removed, but I think there's a mass of silent consensus there, since I can recall only the one discussion by the OP concerned with the practice. (Which was not the case with the bot removing the publisher.) --Izno (talk) 00:35, 15 September 2019 (UTC)[reply]

Now that #RfC on linking title to PMC has been closed, I would like an option to disable the automatic linking to PMC when it would be inappropriate (such as when the peer-reviewed version is available via DOI) in {{cite xxx}} (see previous discussion [perma]). I think the most obvious and intuitive way would be |url=none. Nardog (talk) 08:55, 16 September 2019 (UTC)[reply]

Cite news - multiple URLs

Would it be possible to have a url2 facility for URLs in {{cite news}}? I deal with a lot of clippings from newspapers.com, and when an article continues across multiple clippings, I have to append a (Continued) to the end of the reference outside of the citation template because there's no way to link clippings together at one URL. (For instance, a reference of KMCS (Kansas) needs this.) Raymie (t • c) 21:11, 16 September 2019 (UTC)[reply]

@Raymie: I've found it useful, and less confusing to link the second page number, like in footnote 123 at Michigan State Trunkline Highway System. Imzadi 1979 → 23:58, 16 September 2019 (UTC)[reply]
@Imzadi1979: Thanks for the advice! Raymie (t • c) 00:01, 17 September 2019 (UTC)[reply]
For a single article carried across several pages, where you have given a page range (something like |pages=1, 6-7), I think it suffices to give the reader the url for the first page. I am pretty sure most readers could find their way to the rest of the pages without a separate url. If you have a large article and want to provide a specific in-source location (perhaps more than one), that is best handled by appending a suitable link (or links) to the in-line citation. E.g.: <ref>{{cite news | ...|ps=,}} [https:newspapers.com/xxx6/ page 6, col. 2].</ref> ♦ J. Johnson (JJ) (talk) 21:43, 17 September 2019 (UTC)[reply]
I am pretty sure most readers could find their way to the rest of the pages without a separate url. — maybe this is just because I’m not familiar with Newspapers.com, but I’m not seeing an easy way to get from [2] to [3], especially without an account/subscription. If the editor has access to all the relevant clippings, it definitely makes it significantly more convenient to the reader and other editors to link multiple locations. Umimmak (talk) 22:50, 17 September 2019 (UTC)[reply]
"[E]specially without an account/subscription" — for sure, and that's a different problem. If you need to use multiple urls for the full citation then do as Raymie suggested: append the extra information to the template. E.g., something like: <ref>{{cite news |... |url=https://newspapers.com/xxx1|ps=,}} continued at [https://newspapers.com/xxx6/ page 6].</ref> ♦ J. Johnson (JJ) (talk) 19:41, 18 September 2019 (UTC)[reply]
As noted above, it's possible to link the second page number to the URL needed to see it, to wit:
Rook, Christine (July 12, 2009). "Finishing US 127 Still Has Support". Lansing State Journal. pp. 1A, 4A. ISSN 0274-9742. OCLC 6678181. Retrieved July 13, 2018 – via Newspapers.com.
The second page number already indicates the continuation in the original print edition. I think it just looks cleaner to keep the citation together, especially when the access date/via/etc will fall in between the page numbers and the link to the continuation. Imzadi 1979 → 23:18, 18 September 2019 (UTC)[reply]
I was responding to the comment saying it suffices to only link the first page. Linking the additional pages within |pages= works for me, although I do wonder if this might cause issues for the COinS metadata. But I’m not super familiar with that; I just vaguely recall this issue coming up in the past and another editor having that concern. Umimmak (talk) 00:58, 19 September 2019 (UTC)[reply]
Yes. That would seem to be a viable option, but I can see some possible problems, and it might have problems with parameter validation. ♦ J. Johnson (JJ) (talk) 20:27, 20 September 2019 (UTC)[reply]

Template:Citation has a mode=cs1 parameter

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

@Izno: Hi. It appears you've missed the fact that {{Citation}} has a |mode=cs1.

Here is a sample:

  • Citation using CS1: "User:Izno". Wikipedia. Wikimedia Foundation.
  • Citation using CS2: "User:Izno", Wikipedia, Wikimedia Foundation

See the difference? flowing dreams (talk page) 11:20, 18 September 2019 (UTC)[reply]

{{citation}} is not a cs1 template. It can be made to look like a cs1 template with |mode=cs1. Similarly, cs1 templates can be made to look like cs2 with |mode=cs2. Including cs2 in a table specifically intended for cs1 just muddies the water. You might consider implementing a similar table at Help:Citation Style 2.
I have reverted your edit at HELP:CS1.
—Trappist the monk (talk) 11:36, 18 September 2019 (UTC)[reply]
@Trappist the monk: I don't get it. You say it "is not a cs1 template" but "can be made to look like a cs1 template". What's the difference? The look is everything here. If it looks like one, then it is one. Or am I missing something?
Let me guess: You and the maintainers of CS2 are in competition and zealously avoid any cooperation between each other? User:Martin of Sheffield implied as much in the Teahouse discussion. flowing dreams (talk page) 11:52, 18 September 2019 (UTC)[reply]
cs2 differs from cs1 in its rendered style: element separators (cs1: period, cs2: comma); static text (cs1: capitalized, cs2: not capitalized); terminal punctuation (cs1: period, cs2: none); |ref= default value (cs1: not set, cs2: harv). When |mode=cs1 is set in {{citation}} (a cs2 template) the rendered citation uses a period for element separators, capitalized static text, has a period for terminal punctuation, and does not set |ref=. When |mode=cs2 is set in any of the cs1 templates, the rendered citation uses a comma for element separators, does not capitalize static text, does not have terminal punctuation, and sets |ref=harv.
Your guess would be wrong. I have no real preference cs1 or cs2. They are different and I don't see that any benefit is gained by blending their documentation as you apparently want to do.
I presume that the teahouse discussion you mentioned is: Wikipedia:Teahouse#Why is citing so hard?
—Trappist the monk (talk) 12:26, 18 September 2019 (UTC)[reply]
Alright, let's review what you said:
  • CS1 requires:
    • Element separators: period
    • Static text: capitalized
    • terminal punctuation: period
    • |ref= default value: not set
  • When |mode=cs1 is set in {{citation}} (a cs2 template) the rendered citation uses:
    • Element separators: period
    • Static text: capitalized
    • terminal punctuation: period
    • |ref= default value: not set
These are what you said. Conclusion: {{Citation|mode=cs1}} is/gives a CS1 citation. So how is this template counted as "not a cs1 template"? You're being contradictory here.
And yes, you have found the correct Teahouse discussion. User:Martin of Sheffield compared the proponents of CS1 as practictioners of arcane black magic who have long blocked a merger that benefits the community. He compared them to Microsoft in a bad way (He wrote M$) and went so far as saying they "put down" editors who use the wrong template. flowing dreams (talk page) 12:41, 18 September 2019 (UTC)[reply]
I might add that I don't share all of Martin's view. The context-sesitive error messages that specific-purpose CS1 templates generate are very useful. I discovered this on my own. flowing dreams (talk page) 12:54, 18 September 2019 (UTC)[reply]
Flowing dreams seemed to think all that matters is how it looks in the rendered article. Wrong. Within an article the wikitext for the various citations should be similar to make maintenance easier. Jc3s5h (talk) 13:02, 18 September 2019 (UTC)[reply]
Please elaborate. flowing dreams (talk page) 13:20, 18 September 2019 (UTC)[reply]
{{citation}} with |mode=cs1 is still a cs2 template; its rendering has just been disguised to look like the rendering of a cs1 template.
Editor Martin of Sheffield is entitled to have opinions with regard to cs1|2. This discussion is not about those opinions; it is about including cs2 template documentation in the documentation page for cs1 templates.
—Trappist the monk (talk) 13:25, 18 September 2019 (UTC)[reply]
@Jc3s5h and Trappist the monk: I totally support abandoning all side-discussion and getting to the crux of the matter, so for the third time: Apart from generating CS1-compliant output, what are the criteria for being a CS1 template? flowing dreams (talk page) 13:29, 18 September 2019 (UTC)[reply]
Aside from the style that I mentioned before, the obvious (which I didn't mention because it is obvious) is that the cs1 templates are specific to a source type: books → {{cite book}}; news sources → {{cite news}}; preprints held at arXiv → {{cite arxiv}}; dissertations and theses → {{cite thesis}}.
—Trappist the monk (talk) 13:41, 18 September 2019 (UTC)[reply]
I think the intent behind flowing dreams’s edit is just to let other editors know that, should any of the standard CS1 templates not be suitable, a workaround which would still produce the same desired visual formatting for a citation is to use {{Citation}} with |mode=cs1. Perhaps it shouldn’t be mentioned alongside {{Cite journal}} and the like, but I can understand why some editors might find it helpful to be reminded of this as a possibility when adding citations to an article in CS1 style, even if it isn’t a CS1 template itself. Umimmak (talk) 13:49, 18 September 2019 (UTC)[reply]
That may very well be true but it doesn't appear to have been an argument put forward by Editor flowing dreams. If it is, I don't object to such a mention in HELP:CS1 but not in the table that is expressly for cs1 templates.
—Trappist the monk (talk) 14:46, 18 September 2019 (UTC)[reply]
Here is a crazy idea: Forget all the arbitrary distictions between what you consider CS1 and CS2 templates. (You have already forgotten them for the most part, seeing as you didn't remember them at reversion time and after I asked thrice.) Let the only defining factor be the compilance of the output they generate with the style guides of CS1 and CS2. Then, list them in the table. Other than huge benefits of choice and consolidation, it has no drawbacks.
And by the way, if using {{citation}} instead of what you consider a "true CS1 template" 🙄 is something worrisome, then you must start getting seriously worried because I have been using this template in articles and I plan to continue doing so. It is easier to remember one template and one set of parameters instead of an arbitrary many. flowing dreams (talk page) 04:58, 19 September 2019 (UTC)[reply]
You know, I am not worried. In fact, I am entirely indifferent to which of cs1 or cs2 you use when editing en.wiki articles. You can use any citation style you want within the constraints imposed by WP:CITEVAR. Other editors will, no doubt, hold you to the requirements of WP:CITEVAR so that I need not worry about what you do.
Do not mistake my indifference to which of cs1 or cs2 you use in article space as agreement with your changes to the cs1 template documentation page; cs2 is not cs1.
—Trappist the monk (talk) 11:46, 19 September 2019 (UTC)[reply]
@Trappist the monk: Oh, I don't mistake your indifference with your act of harassment. You supplied no reason with your reversion (because you have none) and are hard-pressed to diguse it as a mere dispute. I'm only disappointed, in that it is not a deliberate malicious act of harassment by a despicable person that I can condemn, or over a subject that even matters. But I'll be sure to write about it in my public log. flowing dreams (talk page) 16:55, 20 September 2019 (UTC)[reply]
meh
—Trappist the monk (talk) 21:40, 20 September 2019 (UTC)[reply]
@Flowing dreams: Your comments are uncalled for, and contrary to WP:Civility. ♦ J. Johnson (JJ) (talk) 23:38, 20 September 2019 (UTC)[reply]
I'm sure the writers of WP:Civility never inteded it to be used to harbor harassment and edit warring. flowing dreams (talk page) 04:26, 21 September 2019 (UTC)[reply]

Not really sure what the big fuss is about, but {{citation}} isn't a CS1 template, it's a CS2 template, and shouldn't be shoehorned into CS1 advice simply because there's a |mode=cs1. Likewise, CS1 templates aren't CS2 template simply because the |mode=cs2. Headbomb {t · c · p · b} 05:38, 21 September 2019 (UTC)[reply]

And again, Trappist the monk has already said in their reply to me above that don't object to such a mention in HELP:CS1, just so long as it is not in the table that is expressly for cs1 templates. This seems like a fair compromise to all parties involved. @Flowing dreams: your comments have been quite uncivil and full of accusations of bad faith, harassment, and the like. It would have been much more productive to work with other editors—ones more familiar with Wikipedia citation templates and their documentation—in order to come up with ways of doing this instead of insisting inclusion in the table of CS1 templates. My suggestion would be a sentence in the Help:Citation Style 1 § Style section, but I would defer to those editors who have spent more time thinking about these issues. Umimmak (talk) 06:46, 21 September 2019 (UTC)[reply]
@Umimmak: While I greatly appreciate you working towards peace and progress here, I must impress upon you how humiliating and hurtful all of this are for me. To wit, look at Headbomb's comment: To him, it is not a step required by the five pillars of Wikipedia or improving, but "a great fuss". And while he states that he does not care what the subject of the discussion is, he permits himself to judge me and parrot out the fallacious "CS1 templates aren't CS2". What did I ever do to you guys to deserve this degree of bad behavior? I don't need a compromise as much as I deserve working in the spirit of teamwork. But TTM's double-talk is not teamwork. TTM's reverting my well-meaning contribution in the same curt, non-collegial way that one reverts a sabateur, is not teamwork. (By the way, what's Wikipedia's word for a sabateur?)
And please refrain from sending me reply notifications. This discussion is dead to me. I've tolerated enough harassment and anti-newcomer bias already. Perhaps, you and I will meet again and our cooperation would be an example of collegial work. flowing dreams (talk page) 07:22, 21 September 2019 (UTC)[reply]
Those are gross mischaracterizations of my comments. I'll follow up on your talk page. Headbomb {t · c · p · b} 14:08, 21 September 2019 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

script-title=missing prefix

Could a bot be used to add the prefixes for e.x. here?--Lirim | Talk 16:01, 19 September 2019 (UTC)[reply]

Of course. Properly your bot should inspect the content of the script parameters to see that the script matches the language name or code assigned to |language=. The script parameters are:
|script-article=, |script-chapter=, |script-contribution=, |script-entry=, |script-journal=, |script-magazine=, |script-newspaper=, |script-periodical=, |script-section=, |script-title=, |script-website=, |script-work=
(and yes, I have seen the specified language in |language= be different from the language used in the associated script parameter).
—Trappist the monk (talk) 17:16, 19 September 2019 (UTC)[reply]

Template:Hyphen is corrupted

|pages=e01633{{hyphen}}17 gives the following

Instead of the correct/expected

Headbomb {t · c · p · b} 17:50, 19 September 2019 (UTC)[reply]

Why |pages= instead of |page=? It looks like just one page is being cited. Using {{cite compare}}:
Cite journal comparison
Wikitext {{cite journal|date=2017-09-26|doi=10.1128/mBio.01633-17|first1=Patrick D.|first2=Mark|first3=Arturo|issue=5|journal=mBio|last1=Schloss|last2=Johnston|last3=Casadevall|page=e01633-17|pmc=5615203|pmid=28951482|title=Support science by publishing in scientific society journals|volume=8}}
Live Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.
Sandbox Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.
Here it is with |pages=:
Cite journal comparison
Wikitext {{cite journal|date=2017-09-26|doi=10.1128/mBio.01633-17|first1=Patrick D.|first2=Mark|first3=Arturo|issue=5|journal=mBio|last1=Schloss|last2=Johnston|last3=Casadevall|pages=e01633-17|pmc=5615203|pmid=28951482|title=Support science by publishing in scientific society journals|volume=8}}
Live Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.
Sandbox Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.
What am I missing? — Preceding unsigned comment added by Jonesey95 (talk • contribs)
It is just one page, yes, so |page= is technically more correct than |pages=. However, we don't mangle the output if you have something like |pages=124 or |page=124–127, so there's no reason to silently mangle the output here either. Headbomb {t · c · p · b} 18:02, 19 September 2019 (UTC)[reply]
Because editors do use semicolons in the oddest places, and because {{hyphen}} is processed before the cs1|2 template and because {{hyphen}} renders as &#45; with a trailing semicolon: then |pages=1{{hyphen}}2 becomes |pages=1&#45;2 which (because pages plural) cs1|2 treats as two separate pages 1&#45 and 2. Had you used |page=1{{hyphen}}2 (singular) then cs1|2 ignores the semicolon separator character.
This particular example is a single page and not a range (...33 to ...17 is malformed were it intended to be a range) so write |page=e01633-17 with the keyboard hyphen character; don't use {{hyphen}}.
—Trappist the monk (talk) 18:48, 19 September 2019 (UTC)[reply]
Best practice is to use {{hyphen}}, per documentation. Headbomb {t · c · p · b} 18:53, 19 September 2019 (UTC)[reply]

ISSN error

I have three issues of a paper journal, each of which carries a barcode and text reading "ISSN 977 0016639 051"; that ISSN is also found online, for example at [4].

However:

<ref name="Gibbons">{{cite journal |last1=Gibbons |first1=Sue |title=Percival Boyd |journal=Genealogists' Magazine |date=March 2005 |volume=28 |issue=5 |pages=187-195 |publisher=[[Society of Genealogists]] |issn=9770016639051}}</ref>

gives a template error[1] and https://www.worldcat.org/issn/9770016639051 find no entry.

What's up? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 22 September 2019 (UTC)[reply]

References

  1. ^ Gibbons, Sue (March 2005). "Percival Boyd". Genealogists' Magazine. 28 (5). Society of Genealogists: 187–195. ISSN 9770016639051. {{cite journal}}: Check |issn= value (help)
@Pigsonthewing: According to the ISSN article, the 8-digit ISSN is sometimes re-encoded as a 13-digit barcode. The 8-digit ISSN for the Genealogists' Magazine is listed by Worldcat as 0016-6391, using seven digits from the 13-digit version plus a new check digit. -- John of Reading (talk) 12:32, 22 September 2019 (UTC)[reply]

(edit conflict)

New to me. See this document @ §6.31. According to that:
977 is the prefix
0016639 is the issn without check digit
05 is the variant
1 is the check-digit
Adding a check-digit to the 7-digit issn gives this which worldcat thinks is the same serial publication:
ISSN 0016-6391
I suspect that it having appeared in this example publication that we should expect to see these crop up in future so perhaps we should consider adding support for issn-13. Opinions?
—Trappist the monk (talk) 12:52, 22 September 2019 (UTC)[reply]
Until these have actual widespread use, and resolve somewhere, the standard ISSN format should be enforced. Headbomb {t · c · p · b} 13:00, 22 September 2019 (UTC)[reply]

Thanks all; interesting. I am minded to agree with Headbomb that the 8-digit form should be enforced, but we could perhaps trap this alternative with a custom error message ("Did you mean..?"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:10, 22 September 2019 (UTC)[reply]

Assuming a correctly formed issn-13 then such an error message would have to present a properly formed issn-8. To do that we have to extract the seven-digit issn, calculate the appropriate checksum for display. If we are going to do all of that, use the new issn-8 to link into worldcat and no error message.
—Trappist the monk (talk) 13:49, 22 September 2019 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
The {{Cite DNB}} template has a |supplement= parameter. It's not a CS1 template, but could be the source of confusion.   Jts1882 | talk  16:18, 22 September 2019 (UTC)[reply]
Department? That really is poor in description and use, can we please add =|supplement thanks. Govvy (talk) 21:07, 22 September 2019 (UTC)[reply]
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)[reply]

Citing a box in a chapter in a supplement...

Speaking of supplements, here's a challenge for everyone: I have a citable (because it is independently written) box in a chapter in a special supplement to a volume/issue in a journal. (Supplement available here. See "How do we know the world has warmed?" on p. S26.)

The preferred result would be on the lines of: 

 Kennedy, et al., (2010) "How do we know the world has warmed?". In: "State of the Climate in 2009". Bulletin of the American Meteorological Society.  91(7):26 ....

Which I can almost do. Except that {cite journal} and {citation} ignore |chapter=, and {cite book} drops the issue number and misformats the page number. I have also tried doing a minimal {cite journal} for the box, and appending "In: {cite journal ....}}" for the the supplement, but the page number doesn't work.

So: any suggestions? ♦ J. Johnson (JJ) (talk) 22:35, 22 September 2019 (UTC)[reply]

Use |at= instead. --Izno (talk) 23:11, 22 September 2019 (UTC)[reply]
Perhaps this
{{cite journal|author=Author|title=Introduction: BoxTitle|department=Special Supplements|journal=Journal|issue=1 ''SupplementTitle''|p=S1}}
Author. "Introduction: BoxTitle". Special Supplements. Journal (1 SupplementTitle): S1. {{cite journal}}: |author= has generic name (help)
might work. 98.0.246.242 (talk) 02:06, 23 September 2019 (UTC)[reply]
Use |at= to finesse the page numbering, right? Yes, that looks good. And |deparatment=, of course, how could I have overlooked that??! Thanks to you both. ♦ J. Johnson (JJ) (talk) 20:52, 23 September 2019 (UTC)[reply]

Citing an entire issue of a journal

See also: Help talk:Citation Style 1/Archive 58 § url + title=none

There are scientific journals that do not contain articles, but simply publish scientific data at regular intervals. One example is Minor Planet Circulars. How do I cite an entire issue, without specifying the title parameter (as there is no title to specify)? Specifically, I needed to cite a new observatory code listed on page 1 of issue 85415: https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf. Typing in

{{cite journal |journal=[[Minor Planet Circulars]] |issn=0736-6884 |date=17 November 2013 |issue=85415 |page=1 |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf |format=PDF}}

obviously produces a missing title error. I've worked around it by adding |title=New observatory codes, but this is wrong, as "New observatory codes" is merely a section title, not an article title. Perhaps, there is some way to use {{citation}} template without specifying the title parameter? — UnladenSwallow (talk) 01:53, 24 September 2019 (UTC)[reply]

You could try |title=none. But that won't work for this example because then there would be nothing for the url to link to. If you had a doi instead of a url it would work. —David Eppstein (talk) 02:02, 24 September 2019 (UTC)[reply]
Given the examples demonstrated by Headbomb and me (keep in mind, Minor Planet Circulars is widely referenced on Wikipedia, and all those references are presently malformed in one way or another), I think we should consider extending {{citation}}'s behavior. Namely, if |title=none, but |issue= has a value, then the issue should get linked to the provided URL. The semantics being that the URL points to an HTML page or a file containing the entire issue of the journal in question. For example, typing the code above would produce the following:

Minor Planet Circulars (85415 (PDF)): 1. 17 November 2013. ISSN 0736-6884.

If |issue= has no value, then {{citation}} should throw an error, as it does now:

|url= missing title or issue (help)

The proposed change is small, easy to implement, and does not break anything. — UnladenSwallow (talk) 07:21, 24 September 2019 (UTC)[reply]
If Minor Planet Circulars is an oft-used source, consider making a separate template for it. Consider perhaps, {{London Gazette}} as a possible model:
{{London Gazette |issue=33000 |date=9 December 1924 |page=8957}}
"No. 33000". The London Gazette. 9 December 1924. p. 8957.
—Trappist the monk (talk) 10:42, 24 September 2019 (UTC)[reply]
{{London Gazette}} – which is a misnomer, as the template also supports Belfast Gazette and Edinburgh Gazette – is a "macro" template that saves time by building the URL automatically from |city=, |issue=, and |page=. It is certainly possible and perhaps even useful to implement a similar template for MPEC, MPC, MPS, and MPO, as they all have standard uniform URLs. But there still has to be a general solution to the problem of "article-less" journals.
Please note that I'm not proposing to trigger the "linked issue" behavior with a missing/empty |title=. A missing/empty |title= will still produce a missing title error, so the new editors will still be taught to always include the title. The behavior will only be triggered by explicitly setting |title=none, signalling: "I know what I'm doing. I'm doing this because I'm citing an "article-less" journal, and I want the issue linked to the URL."
We might also switch {{London Gazette}} to the new system, as this looks more consistent with other citations:

The London Gazette (33000): 8957. 9 December 1924.

(The current display style may be misinterpreted as an article titled "No. 33000" by The London Gazette.) — UnladenSwallow (talk) 20:58, 24 September 2019 (UTC)[reply]
I would suggest the poorly documented {{cite techreport}}:
{{cite techreport|url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf|title=Minor Planet Circulars|number=85415|institution=[[Minor Planet Center]]|date=17 November 2013|p=1|issn= 0736-6884}}
Minor Planet Circulars (PDF) (Technical report). Minor Planet Center. 17 November 2013. p. 1. ISSN 0736-6884. 85415.
24.105.132.254 (talk) 13:42, 25 September 2019 (UTC)[reply]
I should add, |type=none will remove "(Technical report)" from the display. But imo, this would not be helpful to the average Wikipedia reader re:precision. The circulars, are after all, technical reports. 24.105.132.254 (talk) 16:41, 25 September 2019 (UTC)[reply]
Thank you for your suggestion. However, there are two problems with {{cite techreport}}:
  1. Minor Planet Circulars must link to Minor Planet Center#Publications, not to a PDF of an issue.
  2. The order of elements / formatting looks completely different from {{cite journal}}, and Minor Planet Center#Publications describes Minor Planet Circulars as "a scientific journal".
I still think the best solution is to extend {{cite journal}} as I have proposed, which will produce a nice and clean result:
{{cite journal |journal=[[Minor Planet Circulars]] |issn=0736-6884 |date=17 November 2013 |issue=85415 |title=none |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf |page=1}} →
Minor Planet Circulars (85415): 1. 17 November 2013. ISSN 0736-6884.
— UnladenSwallow (talk) 10:52, 26 September 2019 (UTC)[reply]
I don't think that MPC should be considered a scientific journal except under the most expansive definition. It seems to me to be more akin to an ephemeris, which should be considered a technical report, a series continuously/periodically updated. So I believe the citation should source the data series as a whole, and keeping in mind the comments that Trappist made below, should focus on the date and page elements as the distinguishing characteristics of the particular citation. 72.43.99.138 (talk) 14:33, 26 September 2019 (UTC)[reply]
If I look at the pdf that you have linked, it appears to me that 85415 is a page number; not an issue number. The next page in that pdf is M.P.C. 85416 and so on to the end page which is M.P.C. 85916. Every one of the 502 pages in the pdf bears the date 2013 Nov 17 which is reflected in the pdf's file name (MPC_20131117.pdf). The circulars are published (issued) on a date but the pagination is continuous (it does not restart with each new issuance – see the next publication (2013 Dec 17) which begins at M.P.C. 85917).
If we take the MPC number as pagination, and the circulars as the individually titled sections, and were we citing a Kitt Peak observation found on page 85535, we might write:
{{citation |mode=cs1 |title=695 Kitt Peak |periodical=[[Minor Planet Circulars]] |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf#page=121 |page=M.P.C. 85535 |nopp=yes |date=2013-11-17}}
"695 Kitt Peak" (PDF). Minor Planet Circulars. M.P.C. 85535. 2013-11-17. {{citation}}: Unknown parameter |nopp= ignored (|no-pp= suggested) (help)
I used{{citation}} and |periodical= to get away from the journal style volume / issue / page format because, in this case, there is no volume nor issue; just page numbers; |nopp=yes hides the pagination prefix.
—Trappist the monk (talk) 13:13, 26 September 2019 (UTC)[reply]
My bad. This is, indeed, a continuous page number. And as 72.43.99.138 explained to me above, the term "technical report" encompasses periodicals, something I did not know. My apologies to all for insisting on the wrong solution. I guess the best one, after all, was proposed by 24.105.132.254:
{{cite techreport |institution=[[Minor Planet Center]] |title=Minor Planet Circulars |ISSN=0736-6884 |date=17 November 2013 |page=85535 |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf#page=121 |type=none}}
Minor Planet Circulars (PDF). Minor Planet Center. 17 November 2013. p. 85535. ISSN 0736-6884.
or, perhaps, a slight modification using |chapter= as a stand in for a batch of circulars, with its title taken from the page header:
{{cite techreport |institution=[[Minor Planet Center]] |title=[[Minor Planet Circulars]] |ISSN=0736-6884 |date=17 November 2013 |chapter=M.P.C. 2013 NOV. 17 |page=85535 |chapter-url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf#page=121 |type=none}}
"M.P.C. 2013 NOV. 17" (PDF). Minor Planet Circulars. Minor Planet Center. 17 November 2013. p. 85535. ISSN 0736-6884.
Thank you for your help! — UnladenSwallow (talk) 04:22, 27 September 2019 (UTC)[reply]

Date in non-Gregorian calendar

According to WP:CS1, "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." (my emphasis) However in Muhammad_III_of_Granada#Primary_sources, I used "1247 AH" as the date (see "Ibn al-Khaṭīb (1347 AH)") and got a validation error Check date values in: |date=. How do I fix this? HaEr48 (talk) 13:30, 25 September 2019 (UTC)[reply]

Because they are general purpose templates, cs1|2 templates are not intended support all calendars. cs1|2 templates use the Gregorian calendar because Gregorian is the most commonly used calendar. There is no fix. Yours is a case where the citation will likely have to be written manually to avoid the error message.
—Trappist the monk (talk) 13:47, 25 September 2019 (UTC)[reply]
An admittedly cludgy suggestion would be to use |date=c. 1928, plus either |orig-year=original date 1347 AH or |quote=[Source pub. date] 1347 AH [+page# where this information is found]. 24.105.132.254 (talk) 14:09, 25 September 2019 (UTC)[reply]
This is actually a pretty reasonable workaround IMO. --Izno (talk) 16:09, 25 September 2019 (UTC)[reply]

Question about Title in Template:Cite episode

This template help page states, "title: Title of source. Can be wikilinked to an existing Wikipedia article or url may be used to add an external link, but not both. Displays in italics." It actually does not display in italics, as it should not because that would be the wrong format. Episode titles are properly formatted in quotes, never italics. It does display, in fact, in quotes so that needs clarification and I'm not sure if I am allowed to edit this or not. MagnoliaSouth (talk) 18:17, 26 September 2019 (UTC)[reply]

fixed.
—Trappist the monk (talk) 18:32, 26 September 2019 (UTC)[reply]

Casing error

When url-status=dead, it correctly produces:

... Cambridge University Press, pp. 34–42, archived from the original (PDF) on 2009-09-06

When url-status=unfit, it incorrectly produces:

... Cambridge University Press, pp. 34–42, Archived from the original on 2009-09-06

The case is not agreeing with the comma before it. The second one should change to ", a", to match the first (unless there is a reason for it to be capitalized, in which case it should change to ". A"). (I'm not expert in citing, here or elsewhere.) - A876 (talk) 04:31, 29 September 2019 (UTC)[reply]

I've tweaked the sandbox:
Citation comparison
Wikitext {{citation|archive-date=2019-09-29|archive-url=//archive.org|title=Title|url-status=unfit|url=//example.com}}
Live Title, archived from the original on 2019-09-29{{citation}}: CS1 maint: unfit URL (link)
Sandbox Title, archived from the original on 2019-09-29{{citation}}: CS1 maint: unfit URL (link)
Citation comparison
Wikitext {{citation|archive-date=2019-09-29|archive-url=//archive.org|title=Title|url-status=dead|url=//example.com}}
Live Title, archived from the original on 2019-09-29
Sandbox Title, archived from the original on 2019-09-29
Citation comparison
Wikitext {{citation|archive-date=2019-09-29|archive-url=//archive.org|title=Title|url-status=live|url=//example.com}}
Live Title, archived from the original on 2019-09-29
Sandbox Title, archived from the original on 2019-09-29
Cite book comparison
Wikitext {{cite book|archive-date=2019-09-29|archive-url=//archive.org|title=Title|url-status=unfit|url=//example.com}}
Live Title. Archived from the original on 2019-09-29.{{cite book}}: CS1 maint: unfit URL (link)
Sandbox Title. Archived from the original on 2019-09-29.{{cite book}}: CS1 maint: unfit URL (link)
—Trappist the monk (talk) 08:43, 29 September 2019 (UTC)[reply]

Category:CS1: long volume value

Category:CS1: long volume value should probably display a cs1-maint (the green type) message, right? Currently it has no visual output. – Finnusertop (talk ⋅ contribs) 16:29, 29 September 2019 (UTC)[reply]

See this discussion.
—Trappist the monk (talk) 16:37, 29 September 2019 (UTC)[reply]
Without having read the initial discussion, my first thought is that "long volume value" is not an inherent problem, although many of these cases may justify the addition of a |volume-subtitle= parameter or something to that effect. -BRAINULATOR9 (TALK) 01:02, 30 September 2019 (UTC)[reply]

Zero-width joiners between emoji

What is the correct resolution for invisible character errors in citations with titles using zero-width joiners between emoji, as in the citation on 2019 in American television? —Ost (talk) 20:47, 30 September 2019 (UTC)[reply]

You could leave it out; the rendering of the emoji on my win10 machine at en.wiki is different from the rendering of the emoji at twitter. If you must keep the emoji, replace the unicode zwj with its html equivalent:
{{cite tweet|number=1155848220775452673|user=TeenNick|author=TeenNick|title=An all new season of #HunterStreet is coming to TeenNick TONIGHT at 7:30/6:30p 🕵️&#x200D;♀️ |date=July 29, 2019|accessdate=September 26, 2019}}
TeenNick [@TeenNick] (July 29, 2019). "An all new season of #HunterStreet is coming to TeenNick TONIGHT at 7:30/6:30p 🕵️‍♀️" (Tweet). Retrieved September 26, 2019 – via Twitter.
—Trappist the monk (talk) 21:50, 30 September 2019 (UTC)[reply]

Category:Articles with missing Cite arXiv inputs should only be present on Mainspace/Draftspace.

Self-explanatory. Headbomb {t · c · p · b} 05:57, 3 October 2019 (UTC)[reply]

I suspect that this is because {{cite compare}} no longer obeys |old=no; any value causes the transclusion of {{cite xxx/old}}. In this case, {{cite arXiv/old}} unconditionally adds Category:Articles with missing Cite arXiv inputs regardless of the namespace. The fix for this is at {{cite compare}} to make it obey |old=no. Pinging Editor Izno?
—Trappist the monk (talk) 10:35, 3 October 2019 (UTC)[reply]
Yes, I flipped the intent of |old= and made it so that any value caused the old template to display. The correct fix is to remove |old=no in this case. --Izno (talk) 13:17, 3 October 2019 (UTC)[reply]
Having |old=no behave the same as |old=yes is counter-intuitive. I suggest fixing that, or at least cleaning up all former uses that depended on the previous behavior. – Jonesey95 (talk) 14:28, 3 October 2019 (UTC)[reply]
I will not be doing the latter as I saw it as zero-value-add to do so. I think you should instead change your understanding of the parameter as to the former per my earlier comment, but I won't revert someone who really feels that's the Way It Should Be (that only |old=yes should trigger display of the old template). --Izno (talk) 14:58, 3 October 2019 (UTC)[reply]

spam black list and archive urls

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

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

becomes this:

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

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

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

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

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

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

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

Keep? Discard? Opinions?

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

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)[reply]
... 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)[reply]

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
Look up usurp in Wiktionary, the free dictionary.
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)[reply]
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)[reply]
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)[reply]

Inconsistent book volume bolding

These two identically formatted citations, as found in Abelian group:

  • {{cite book |last=Fuchs |first=László |date=1970 |title=Infinite Abelian Groups |series=Pure and Applied Mathematics |volume=36-I |publisher=[[Academic Press]] |mr=0255673 }}
  • {{cite book |last=Fuchs |first=László |date=1973 |title=Infinite Abelian Groups |series=Pure and Applied Mathematics |volume=36-II |publisher=[[Academic Press]] |mr=0349869 }}

produce inconsistent formatting: the first book's volume number is bolded and the second is not.

  • Fuchs, László (1970). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-I. Academic Press. pp. 1–10. MR 0255673.
  • Fuchs, László (1973). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-II. Academic Press. pp. 11–19. MR 0349869.

Maybe we should fix this? —David Eppstein (talk) 06:06, 5 October 2019 (UTC)[reply]

This is the 4-character-limit issue:
|volume=36-I → 4 characters
|volume=36-II → 5 characters
—Trappist the monk (talk) 11:41, 5 October 2019 (UTC)[reply]
Really books should display this as "Vol. 36-I", rather than "36-I". Headbomb {t · c · p · b} 13:50, 5 October 2019 (UTC)[reply]
I agree. Bolding should be reserved for the situations where we use the journal-style formatting of page numbers. Kanguole 16:29, 5 October 2019 (UTC)[reply]
It should also group volume with pages, rather than separate them with the publisher. Headbomb {t · c · p · b} 17:31, 5 October 2019 (UTC)[reply]
Unlike magazines, I disagree. The volume of a book is more a function of its title. Imzadi 1979 → 21:21, 5 October 2019 (UTC)[reply]
Not so for series of books, which is when |volume= should be used. Headbomb {t · c · p · b} 21:26, 5 October 2019 (UTC)[reply]
Yes, in this case the volumes should definitely be immediately after the series, not the title. The next most tight grouping would be that the series+volume should be adjacent to the publisher. It would be wrong to move the volume past the publisher and away from the series to put it closer to the page numbers. —David Eppstein (talk) 21:32, 5 October 2019 (UTC)[reply]

I'm thinking something like

  • Fuchs, László (1973). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-I. pp. 1–10. Academic Press. MR0349869.

Headbomb {t · c · p · b} 05:21, 6 October 2019 (UTC)[reply]

Out of curiosity, what is the urgency? This has been discussed since the change to conditional bolding was being considered, some years back. Why does this keep popping up? Either leave as is and provide a better explanation for the apparent inconsistency, or apply uniform font weight. It is a bit tiresome to keep revisiting the same issues. 72.43.99.138 (talk) 15:14, 6 October 2019 (UTC)[reply]

Why does this keep popping up? Because it's an unresolved problem? — UnladenSwallow (talk) 19:39, 6 October 2019 (UTC)[reply]
Yes, we know. The question is, why is it still unresolved after it has been brought up multiple times? As was suggested, either change the bolding, or explain it better so it isn't brought up so often. 98.0.246.242 (talk) 01:37, 7 October 2019 (UTC)[reply]

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)[reply]

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

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. {{cite book}}: |last= has generic name (help)
should instead be
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. {{cite book}}: |last= has generic name (help)
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)[reply]
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)[reply]

Italics of websites in citations and references – request for comment

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
An overall consensus exists here that names of websites in citations/references should be italicized, generally in line with current practices. Limited exceptions to italicizing were discussed by some, however no clear consensus emerged on this point. Steven Crossin Help resolve disputes! 15:49, 26 August 2019 (UTC)[reply]

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

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


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

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

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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    If someone cited WP as a source (not on WP itself, obviously, per WP:CIRCULAR), then it should be italicized. How to cite the Manx cat article at another encyclopedia: "Manx Cat", Encyclopædia Britannica, [additional cite details]. How to cite the corresponding article here: "Manx Cat", Wikipedia, [addl. details]. What's happening here is confusion of citation style with other style, like how to refer to something in running text. As a wiki, a form of service and a user community, most other publications are apt to refer to Wikipedia without italics, because they're addressing it as a wiki (service/community), not as a publication. But even in running text it would be entirely proper to use italicized Wikipedia when treating it as a publication per se, e.g. in a piece comparing Wikipedia versus Encarta accuracy and depth of coverage about Africa, or whatever.  — SMcCandlish ☏ ¢ 😼  12:30, 18 May 2019 (UTC)[reply]
  • 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)[reply]
    With no allowances for WP:COMMONNAME (policy)? - PaulT+/C 06:06, 19 May 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
  • Yes, italic, the same way we've always done it, for all actual website titles (which are sometimes, though increasingly rarely domain names in form), in citations. No sensible rationale has been provided for changing this. In short, continue to follow MOS:TITLES. This has nothing to do with whether it should be italicized in running prose; that depends on whether the site is primarily seen as a publication (Salon, TechCrunch, or something else, like a service, shop, forum, software distribution channel, or just a corporate info page. In a citation it is and only can be a publication, in that context. WP does not and cannot cite anything that is not a publication (a published source), though of course TV news programs and other A/V content count as publications in this sense; the medium is irrelevant. The citation templates automatically italicize the work title; always have, and should continue to do so (while sub-works, like articles, go in quotation marks, same as newspaper articles, etc.). If you cite, say, Facebook's usage policy in an article about Facebook-related controversies, you are citing |title=Terms of Service|work=Facebook, a published source (a publication); you are not citing a corporation (that's the |publisher=, but we would not add it in this case, as redundant; similarly we do just |work=The New York Times, not |work=The New York Times|publisher=The New York Times Company).

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

  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]
      @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)[reply]
    • "The |work= field shows italic, the |publisher= doesn't and you choose which is the best option." No; read the templates' documentation, Help:CS1, and MOS:TITLES. The work title is required; the publisher name is optional, only added when not redundant, and rarely added at all for various publications types (e.g. newspapers and journals; most websites don't need it either since most of them have a company name almost the same as the website name). No one gets to omit |work= as some kind of "give me non-italicized electronic publications or give me death" WP:GAMING move.  — SMcCandlish ☏ ¢ 😼  05:08, 19 May 2019 (UTC)[reply]
  • 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)[reply]
  • Yes italics, no change from how we currently cite. Cavalryman V31 (talk) 21:01, 18 May 2019 (UTC).[reply]
  • 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)[reply]
  • Italics—but if the website lacks a name independent of its publisher, then there's no need to invent a name for a citation just to fill in that parameter of the citation template; the publisher in |publisher= will be sufficient. 22:41, 18 May 2019 (UTC) — Preceding unsigned comment added by Imzadi1979 (talk • contribs) 22:42, 18 May 2019 (UTC)[reply]
    Already covered this above, twice. Can you provide an example of an actual reliable-source website with no name?  — SMcCandlish ☏ ¢ 😼  05:13, 19 May 2019 (UTC)[reply]
  • 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)[reply]
    This is at Help talk:Citation Style 1, so it's already clear what the scope is. If you're at an article is consistently using manual citations in some wacky style that, say, puts work titles in small-caps and italicizes author surnames (or whatever), then that same style would be applied in that article to electronic publications. (That said, any citation style that confusing is a prime candidate for a change-of-citation-style discussion on the article's talk page, per WP:CITEVAR).  — SMcCandlish ☏ ¢ 😼  05:13, 19 May 2019 (UTC)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]
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)[reply]
  • Italics, how we've always done it (or should have always done it). Kaldari (talk) 16:06, 20 May 2019 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    (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)[reply]
    Thanks, this is helpful. I'll dig into it when I have some more time. - PaulT+/C 15:00, 23 May 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • Per SMcCandlish? Can you double-check that? I believe SMcCandlish was italicize (always), not it depends. —BarrelProof (talk) 13:06, 27 May 2019 (UTC)[reply]
      • It depends in that some online entities are not italicized in running prose, being generally of the character of a service or some other non-publication, in typical-use context. If we cite them in a source/reference citation, however, we are only ever citing them as one kind of thing: a publication (a published source), so in a citation the italics belong there.  — SMcCandlish ☏ ¢ 😼  17:23, 12 June 2019 (UTC)[reply]
  • Italics per SMcCandlish. Malcolmxl5 (talk) 06:33, 26 June 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
Hey, Tenebrae, been awhile. Good to talk with you again! As for what specific points to address, please see the opinion and other posts by SMcCandlish, as I agree with it on these issues. So if you must beat someone up about it, that's the editor to mangle, because it (SMcCandlish) is always throbbingly controversial. !>) By following trends, I did not mean "passing trends", but instead those lasting ones that ultimately resulted in how external resources and Wikipedia apply the use of italics in the present day. Paine Ellsworth, ed. put'r there  01:53, 30 June 2019 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
Tenebrae: Sorry, I could have made it clearer. It is as Trappist the monk says. JG66 (talk) 04:44, 30 June 2019 (UTC)[reply]
Thank you, JG66, for thoroughly misunderstanding what I wrote, although that's probably as much my fault as yours. I think I've been with the program for many years, as I've been involved in many italics discussions and have learned much about the changes over the years in external style guides as they pertained to the applications of italics. I've always sought to improve Wikipedia's italic stylings in line with those external resources. The link I gave was just an illustration, an example, a gentle reminder that before then and since, editors have worked hard to get the policy and guidelines updated to their present not-too-shabby condition where italics are concerned. As for being some kind of fan of italics just for the sake of it, I really could care less. My only concern is whether or not this encyclopedia is consistent with other reference works in its application of italics. Paine Ellsworth, ed. put'r there  01:42, 30 June 2019 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
Maybe it's important to know (for inexperienced editors) or at least gently remember (the rest of us) that using the markup for italics in the |website= parameter eliminates the italics in the end result. For example, when one uses |website=''jnj.com'' in the citation code, it comes out upright, as in:  jnj.com. So is the solution you seek 1) to eliminate the italics in the parameter or 2) to educate editors in its correct usage? Paine Ellsworth, ed. put'r there  17:10, 30 June 2019 (UTC)[reply]
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)[reply]
  • Italics per SMC. CThomas3 (talk) 05:08, 15 July 2019 (UTC)[reply]
  • 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)[reply]
    "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)[reply]
  • 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)[reply]
Well, because it indeed might be wrong. Rotten Tomatoes, for instance, is not italicized.--Tenebrae (talk) 00:18, 7 August 2019 (UTC)[reply]

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

*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)[reply]

  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

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)[reply]

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)[reply]
@Trappist the monk: Any objection to closing now? I'm not clear on why there is an advantage to wait until the pmc rfc is ready to close. Thanks, SchreiberBike | ⌨  22:37, 27 June 2019 (UTC)[reply]
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)[reply]
Close requested here. SchreiberBike | ⌨  02:52, 28 June 2019 (UTC)[reply]
That was a full month ago. Just adding a comment here to prevent auto-archiving. —BarrelProof (talk) 02:10, 3 August 2019 (UTC)[reply]
Another two weeks. Just adding another comment here to prevent auto-archiving. —BarrelProof (talk) 23:36, 19 August 2019 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

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

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

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

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)[reply]

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

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

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)[reply]
    @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)[reply]
  • Italics in cs 1/2 templates - per the RFC discussion above. 72.43.99.138 (talk) 15:08, 6 October 2019 (UTC)[reply]
  • {{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)[reply]
    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)[reply]
  • 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)[reply]
    I don't think I've seen anyone claim that |publisher= should italicize anything. --Izno (talk) 18:11, 6 October 2019 (UTC)[reply]
    No but some have argued that when a website has no title, the publisher's name should be used as |website= and be italicized, which is, indeed, italicizing the publisher's name. – Levivich 18:13, 6 October 2019 (UTC)[reply]
    Which is also a different discussion. --Izno (talk) 18:19, 6 October 2019 (UTC)[reply]
  • Rerun this RFC from scratch – and this time advertise it on CENT. The proposal should be clear about what will change if it passes. So "Should websites always be italicized" isn't a great question. A better one would be, "Should we make change X to the MOS", or "Should we make change X to the citation template code", or something concrete like that. We need to differentiate between an MOS-style guideline directive, and a hard change to code. We also need to differentiate between work= and publisher= as discussed above. In my view, the scope of the existing RfC is nil because of the procedural flaws. – Levivich 17:48, 6 October 2019 (UTC)[reply]
    @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)[reply]
    Where? I couldn't find it. – Levivich 18:12, 6 October 2019 (UTC)[reply]
    @Levivich: Review the link provided in my response. --Izno (talk) 18:14, 6 October 2019 (UTC)[reply]
    I didn't see it at first but now I see it. It should be advertised clearer on CENT. For example, the CENT advertisement was "Italics of websites in citations", and not the clearer, "Should website names always be italicized?" or the even clearer, "Should {{cite web}} always require a website name, which is always italicized?" – Levivich 18:16, 6 October 2019 (UTC)[reply]
    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)[reply]
    Added to WP:CENT
    —Trappist the monk (talk) 11:30, 9 October 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    Just a reminder, the purpose of this discussion is to decide how to apply the determined consensus in the previous RFC, not to debate the outcome. Steven Crossin Help resolve disputes! 19:44, 6 October 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    "website=" in "cite web" automatically italicizes and does not allow manual override such as wiki markup. --Tenebrae (talk) 21:24, 8 October 2019 (UTC)[reply]
  • 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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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.   Jts1882 | talk  06:06, 7 October 2019 (UTC)[reply]
|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)[reply]
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)[reply]
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)[reply]

For the enterprising gnome

Here is some things to cleanup, most related to citations. I think the related bug in VE has been fixed. --Izno (talk) 18:03, 8 October 2019 (UTC)[reply]

I am skeptical of any claimed fixes to ve. Are you referring to this one: phab:T209493?
—Trappist the monk (talk) 18:08, 8 October 2019 (UTC)[reply]
Here's an edit adding templatestyles nonsense on 4 October 2019. It doesn't look like this bug is fixed. – Jonesey95 (talk) 18:41, 8 October 2019 (UTC)[reply]

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 {{citation}}: Check date values in: |year= (help)CS1 maint: year (link)

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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 {{citation}}: Check date values in: |date= (help). —David Eppstein (talk) 03:06, 9 October 2019 (UTC)[reply]

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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1&oldid=920655828"