Open main menu

Help talk:Citation Style 1

  (Redirected from Help talk:CS1)

Contents

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

Support citewatch=... or something like itEdit

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

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

And, upon the next bot run a table like this

Rank Target/Group Entries (Citations, Articles) Total Citations Distinct Articles Citations/article
106 Journal of Physical Therapy Science
[Beall's journal list]
15 11 1.364
601 Pharmacologia
[Beall's journal list]
1 1 1.000

could be updated to something like

Rank Target/Group Entries (Citations, Articles) Total Citations Distinct Articles Citations/article
106 Journal of Physical Therapy Science
[Beall's journal list]
15 11 1.364
601 Pharmacologia
[Beall's journal list]
1 1 1.000

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

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

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

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

Rank Target/Group Entries (Citations, Articles) Total Citations Distinct Articles Citations/article
47 Science Publishing Group
[Beall's publisher list · Beall's publisher list / update]
Social Sciences could be multiple other journals. Several of SPG journals are named either identically or are very similar to other publications, e.g. International Journal of Data Science and Analysis vs International Journal of Data Science and Analytics and may thus have similar ISO 4 abbreviations.
All 0 Science Publishing Group-related entries
43 42 1.024

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

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

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

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

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

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)

Also Inactive DOIs are now sorted into months of the year categories. --Izno (talk) 14:23, 27 August 2019 (UTC)
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)
Yes, both of these too. Added to the list.
Trappist the monk (talk) 17:03, 27 August 2019 (UTC)
@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)
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)
@Trappist the monk: sorry, used the wrong link apparently. Fixed now. Headbomb {t · c · p · b} 15:30, 28 August 2019 (UTC)
I guess I'm still confused. This:
{{cite book/new |title=Title |agency=Agency,}}Title. Agency,.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)
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)

───────────────────────── @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)

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)

Cite web errorEdit

@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)

(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)
(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)
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)
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)
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)
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)
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)
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)
Also agree, this is an incredibly poor thought-out change. GiantSnowman 13:09, 3 September 2019 (UTC)
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)
I agree that {{cite web}} shouldn't require |website/work/...=. Headbomb {t · c · p · b} 14:35, 3 September 2019 (UTC)
Is there a way to make "website=" and "newspaper=" non mandatory? - Knowledgekid87 (talk) 14:43, 3 September 2019 (UTC)
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)
Well I want to point out that news doesn't only come from a "newspaper" anymore. - Knowledgekid87 (talk) 15:06, 3 September 2019 (UTC)
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)
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)
It seems that few share your view that web sites should be treated like periodicals. Kanguole 16:51, 3 September 2019 (UTC)
"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)
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)
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)
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)
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)
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)
"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)

─────────────────────────'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)

url-statusEdit

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)

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)

|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)
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)
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)
Can confirm. Leaving it empty causes the citation to act as if the url is dead. PanagiotisZois (talk) 12:47, 3 September 2019 (UTC)
Yes please turn off these warnings until the bot has updated the parameters. – Thjarkur (talk) 12:36, 3 September 2019 (UTC)
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)
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)

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

@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)
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)
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)
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)
They both work at present. Here: "Title". Website. Archived from the original on 2001-01-01. Cite uses deprecated parameter |deadurl= (help). --Izno (talk) 14:06, 3 September 2019 (UTC)
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)

─────────────────────────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)

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)
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)
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)
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)
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)
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)

Please change website equals back to urlEdit

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)

@Knowledgekid87: You are mistaken. |url= remains entirely undeprecated. --Izno (talk) 13:20, 3 September 2019 (UTC)
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)
|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)
@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)
@Izno: I fixed your example to stop further misunderstanding. Another example: "Webpage". ExampleWebsite. PublisherName. -- JAGulin (talk) 14:13, 3 September 2019 (UTC)
"Website=" should not be mandatory then. - Knowledgekid87 (talk) 14:32, 3 September 2019 (UTC)

New error messages as of 2 September 2019Edit

{{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)

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)
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)
It appears that this whole mess was made without first thinking of the effects done. - Knowledgekid87 (talk) 13:10, 3 September 2019 (UTC)
Can someone restore the old version until problems are resolved? Dentren | Talk 13:13, 3 September 2019 (UTC)
@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)
@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)
It's at ANI, and the original lack of discussion is paramount. ——SerialNumber54129 13:23, 3 September 2019 (UTC)

Discussion to undo all of the changesEdit

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

"mode = CS1" raises warningEdit

@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)

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)
Usually you go with a lowercase Greek letter. β → Book:, τ → Template:, ω → Wikipedia:, etc... Headbomb {t · c · p · b} 00:33, 5 September 2019 (UTC)
@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)
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)
@Headbomb:, @Jagulin:, @Trappist the monk:: {{Namespace Greek}}. All the best: Rich Farmbrough, 11:58, 28 September 2019 (UTC).
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)
@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)
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)
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)
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)

Cite ssrn, where it is?Edit

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)

WP:SOFIXIT Special skills not required. Copy source from {{cite ssrn/new}}.
Trappist the monk (talk) 14:35, 6 September 2019 (UTC)
@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)
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)
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)

Category redirection over deletionEdit

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 (talkdgaf)  12:01, 29 September 2019 (UTC)

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)

Post-update updates neededEdit

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)

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)
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)

───────────────────────── 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)

Unhide missing periodical error messages? Levivich 14:33, 8 September 2019 (UTC)
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: 4/5,955,521 = 7.0E-5%.) 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)
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)
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)
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)
OK, thank you all! -BRAINULATOR9 (TALK) 19:47, 28 September 2019 (UTC)

Differing headlines between Print and Internet articlesEdit

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)

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)
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)
That's what I should have suggested originally, yes. :) --Izno (talk) 22:05, 1 September 2019 (UTC)

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

isbn2Edit

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

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)
Some books have more than one ISBN. All the best: Rich Farmbrough, 12:03, 28 September 2019 (UTC).
Citation needed. – Jonesey95 (talk) 13:50, 28 September 2019 (UTC)
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)

Template:Citation has a mode=cs1 parameterEdit

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)

{{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)
@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)
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)
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)
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)
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)
Please elaborate. flowing dreams (talk page) 13:20, 18 September 2019 (UTC)
{{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)
@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)
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)

───────────────── 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)

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)
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)
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)
@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)
meh
Trappist the monk (talk) 21:40, 20 September 2019 (UTC)
@Flowing dreams: Your comments are uncalled for, and contrary to WP:Civility. ♦ J. Johnson (JJ) (talk) 23:38, 20 September 2019 (UTC)
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)

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)

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)
@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)
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)

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.

ISSN errorEdit

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 [1].

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)

References

  1. ^ Gibbons, Sue (March 2005). "Percival Boyd". Genealogists' Magazine. Society of Genealogists. 28 (5): 187–195. ISSN 9770016639051 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)

(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)
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)

───────────────────────── 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)

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)

Supplement parameterEdit

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

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

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

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)

Use |at= instead. --Izno (talk) 23:11, 22 September 2019 (UTC)
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.
might work. 98.0.246.242 (talk) 02:06, 23 September 2019 (UTC)
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)

Citing an entire issue of a journalEdit

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)

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)
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)
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)
{{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)
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)
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)
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)
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)
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.
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)
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)

Date in non-Gregorian calendarEdit

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)

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)
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)
This is actually a pretty reasonable workaround IMO. --Izno (talk) 16:09, 25 September 2019 (UTC)

Question about Title in Template:Cite episodeEdit

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)

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

Casing errorEdit

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)

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

Category:CS1: long volume valueEdit

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

See this discussion.
Trappist the monk (talk) 16:37, 29 September 2019 (UTC)
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)

Zero-width joiners between emojiEdit

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)

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)

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

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

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)
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)
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)
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)

spam black list and archive urlsEdit

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

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

becomes this:

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

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

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

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

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

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

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

Keep? Discard? Opinions?

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

I think this is as much an acceptable solution as any, at least as long as archive services do not disallow percent-encoding referrals for whatever weird reason. A social rather than technical issue may arise from editors who may wonder why a blacklisted url displays in the first place. 72.43.99.130 (talk) 18:37, 3 October 2019 (UTC)
... editors who may wonder why a blacklisted url displays in the first place. I think that's not an issue because the title is not linked to the blacklisted url but to a (presumably) good snapshot of the website page before it was blacklisted. I presume here that the editor who chose the archive url did so in good faith and that the archived source does, indeed, support the Wikipedia article's text. I suppose that the argument might be made that a blacklisted url is a blacklisted url whether it's archived or not. Still, to your point, using |url-status=unfit or |url-status=usurped disables the link to the original url in the rendered citation.
Trappist the monk (talk) 19:12, 3 October 2019 (UTC)

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

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

Regarding this:

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

I think that shouldn't be an issue. We should distinguish between these two cases:
  1. The url (or domain) was always malware/spam; it was never suitable for a reference, and still is not.
  2. The url (or domain) started off as a good source, but is malware/spam now.
One strength of having an archive in the first place, is that it can help us deal with case #2, and provide a good copy of an url back before it changed. This may be an argument for different handling of the two cases above, which may imply different values for |url-status.
I am not certain what your expectations were about how editors should employ the values unfit and usurped , given that the CS doc for url has little to say about them. But we could, I suppose, assign (or reassign) the usurped value to case #2: that is, "The url was good once (and the archive may still retain a copy), but it isn't good anymore", which goes along with one set of display possibilities including a displayable |archive-url. That might leave unfit to cover case #1, with a different set of display characteristics (including forbidding |archive-url, if it was always bad). Or, if that's not what you intended unfit to be, then perhaps some new value (forbidden, blacklist, or whatever) to indicate that this was never a usable url and the |archive-url should be suppressed if there is one.
Whatever the case (and even if nothing changes wrt to those two values), the documentation should be updated to clearly explain these two values, and how they should be used. I'm okay with not having it updated now, especially if the usage or meaning of these values is in flux, but once things shake out, there should be a clear and thorough explanation. (If you want help editing some doc for it when the time is right, feel free to issue a request on my Talk page, and I'll be happy to help.) Mathglot (talk) 02:44, 5 October 2019 (UTC)
Original discussions about parameter values unfit and usurped are at:
Neither of those discussions consider blacklisted urls.
There were subsequent discussions with regard to parameter values:
With regard to your statement:
The url (or domain) was always malware/spam; it was never suitable for a reference, and still is not.
It has been pointed out that percent-encoding the original url in an archive url may be used to mask a cite that has always been malicious. That is also true of archive sites that support url shortening – create an archive copy of the malicious site at archive.today, use the shortened url to avoid the blacklist (until one of the bots that lengthens shortened urls arrives to lengthen it). As an aside, when these lengthening bots attempt to save an article that now has a blacklisted url embedded in an archive url, what happens?
I suppose that when archive urls link to malicious archives, the whole archive url can be blacklisted (presumably with sufficient flexibility that such blacklisting catches all archive urls regardless of timestamp). If there is a specific archive timestamp that can be shown to not be malicious, then an editor could possibly petition whomever does this sort of thing to white-list that particular archive. The question then becomes, how do we mark such white-listed archive urls?
For me, I understand unfit and usurped to mean that the url links to:
  • unfit – link farm or advertising or phishing or porn or other generally inappropriate content
  • usurped – new domain owner with legitimate content; original owner with legitimate content unrelated to the originally cited url's content
Yep, there is no bright line separating the two but, as can be seen from the original discussions of these parameter values, we struggled to get even these because the waters, they are muddy.
And I repeat myself yet again: if you can see how the documentation for these templates can be improved, please do so.
Trappist the monk (talk) 14:34, 5 October 2019 (UTC)
lengthening bots .. what happens? - I believe there is a flag to exempt bot accounts from being blocked on save. I prefer to get blocked to manually fix. My bot also decodes encoded schemes in the path/query portion so the filters are not bypassed. IMO re whitelisting, it is often a matter of judgement/opinion and also double jeaporady since the original blacklisting presumably had a consensus discussion, it opens every blacklisted URL up to a new potential consensus discussion. This is a loophole for users to get past blacklists and overhead to manage. -- GreenC 22:10, 5 October 2019 (UTC)
usurped – new domain owner with legitimate content; original owner with legitimate content unrelated to the originally cited url's content
I assumed usurped to be closer to hijacked? If there is a new, properly registered owner (publisher) did any usurpation take place? 72.43.99.138 (talk) 15:42, 6 October 2019 (UTC)
 
When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.
I think that these definitions of usurped, unfit, and possibly other values of |url-status need solid, agreed-upon definitions. Just from the point of view of English usage, never mind specialized wiki vocabulary, usurped is much more like what IP 72 stated. The sense of a new domain owner with legit content is nothing like most native English speakers would imagine, I don't think, when seeing the word usurped.
To me, your definition is a bit more like what would apply to a word like, repurposed, or reassigned, or repositioned or perhaps some word from marketing vocab when one company buys another's superannuated property, if there is such a word. The term usurped does not seem appropriate for the meaning you assume for it. This all needs further airing out, before the spam blacklist wrinkle, which is an edge case of the broader problem, can even be discussed. I have a feeling that there may be a need for at least one, perhaps two more values for |url-status to cover the different meanings that we seem to be alluding to for it, and trying to cram into two few values. Mathglot (talk) 23:12, 9 October 2019 (UTC)
Just wanted to be clear about one point: I don't think we need new values, just for the sake of new values; there's not need to distinguish every possible thing that could happen with an url. But, when they should be handled differently by the software, then, yes: we do need values for those cases. When the confusion surrounding the current meanings of usurped and unfit are settled, I suspect we will find that we will need at least one more value, in order to assign it to different handling in the software, and I think the spam blacklist case may be one such example. Mathglot (talk) 23:19, 9 October 2019 (UTC)
If you don't like the definitions that I offered above, write better definitions. I did write above: ...as can be seen from the original discussions of these parameter values, we struggled to get even these... Yeah, we know that these parameter keywords are less than optimal so there is no real need to spend a lot of words telling us what we already know. Suggest better definitions and / or suggest better keywords.
Trappist the monk (talk) 12:43, 10 October 2019 (UTC)
For domain names that are not trademarked, |url-status=reassigned would be imo a good option to clarify there is a new registrant. Obviously trademarked domains (like say, newyorktimes.com) would not normally lapse, so in these cases |url-status=usurped would be more accurate. 72.43.99.138 (talk) 13:55, 11 October 2019 (UTC)
I agree with 72.43.99.138. — UnladenSwallow (talk) 17:25, 11 October 2019 (UTC)

Inconsistent book volume boldingEdit

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. 36-I. Academic Press. pp. 1–10. MR 0255673.
  • Fuchs, László (1973). Infinite Abelian Groups. Pure and Applied Mathematics. 36-II. Academic Press. pp. 11–19. MR 0349869.

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

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)
Really books should display this as "Vol. 36-I", rather than "36-I". Headbomb {t · c · p · b} 13:50, 5 October 2019 (UTC)
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)
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)
Unlike magazines, I disagree. The volume of a book is more a function of its title. Imzadi 1979  21:21, 5 October 2019 (UTC)
Not so for series of books, which is when |volume= should be used. Headbomb {t · c · p · b} 21:26, 5 October 2019 (UTC)
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)

───────────────────────── 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)

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)

Why does this keep popping up? Because it's an unresolved problem? — UnladenSwallow (talk) 19:39, 6 October 2019 (UTC)
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)

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

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

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

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

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

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

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

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

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

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

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


Responses:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Trappist:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Italics of websites in citations and references – request for commentEdit

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

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

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


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

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

The following pages have been notified

ResponsesEdit

  • It depends Websites that are more functional and less creative like IMDB should not be italicized, while those that provide long form content of its own creativity should be. --Masem (t) 05:52, 18 May 2019 (UTC)
    This commentary on IMDB is annoying. There is significant creative effort (perhaps invisible) that goes into creating any website, much less one so large and developed as e.g. IMDB. Second, IMDB in specific has tons of user-generated content--that's why we don't treat it as a reliable source. Those people generating that content aren't contributing to some minor work. It is a major work they are contributing to. Major works get italics. Even a site like Metacritic still has a ton of work to have transcribed scores for works (magazines) that are not online. So the notion that e.g. Metacritic is also undeserving of being called a major work annoys me to no end. --Izno (talk) 07:09, 18 May 2019 (UTC)
    Sure, IMDB has effort behind it, but its not the type of "creative writing" effort that we normal see in books, magazines, newspapers and long-form websites. Its more a database first and foremost. And sure, maybe not the best example, but even with Metacritic, Rotten Tomatoes, etc. those still are database sites first and foremost and thus are treated without Italics. --Masem (t) 16:32, 18 May 2019 (UTC)
    Which is a completely arbitrary distinction. These are still websites, still created by some amount of creative effort. A designer or several took the time to make it look, feel, and read the way it does. That's something to italicize, because it's still a publication. "It depends" -> No, it basically doesn't. If you are citing it for the fact it has published something of interested, then it is de facto a publication and should accordingly be italicized (much as SMC says below). --Izno (talk) 18:27, 18 May 2019 (UTC)
    Fundamentally, someone still published the website. They put in the significant work to provide some information to the public. That e.g. Metacritic is a database does not mean there was no work done for it. The reason there are even database rights in e.g. the EU is because they recognize that the act of creating a database might have significant efforts associated with it. To go on and publish it? Yes, yes very much so it is a long work. --Izno (talk) 18:39, 18 May 2019 (UTC)
  • Yes, always italicize. A) We have MOS guidance that indicates major works should be italiziced. Period and end of story. Arbitrary distinctions of "it functions as this in this context" simply aren't necessary, and are essentially sophistry where used. They add unnecessary complexity to our understanding of what it is that we are talking about when we're talking about a source. Where the MOS does not require items be italicized, we are free to do as we please, essentially, as this is a dedicated citation style on Wikipedia. B) It decreases the complexity of the templates. That's good for new and old hands alike. Further, we would have to hack around the arbitrary desires of some small subset of users to support non-italics. (Some of whom do so based on external style guidance. That is not our MOS. Our MOS about italics can be found at MOS:ITALICS.) Who really shouldn't care. The templates take care of the styling, and are otherwise a tool so that we don't need to care. The simpler we make them accordingly, the better. As long as it doesn't affect a great many sensibilities (and I've seen little evidence that it does, not having been reverted on many, if any pages, where I've converted publisher to work or website), then we should italicize. This is molehill making. -Izno (talk) 06:58, 18 May 2019 (UTC)
  • No, only if the name of a film, newspaper, magazine, etc. normally italicized. Wikipedia itself is a website and, as a wiki, is not italicized. IMBD is a viewer-edited site and is not italicized. Etc. Randy Kryn (talk) 09:58, 18 May 2019 (UTC)
    If someone cited WP as a source (not on WP itself, obviously, per WP:CIRCULAR), then it should be italicized. How to cite the Manx cat article at another encyclopedia: "Manx Cat", Encyclopædia Britannica, [additional cite details]. How to cite the corresponding article here: "Manx Cat", Wikipedia, [addl. details]. What's happening here is confusion of citation style with other style, like how to refer to something in running text. As a wiki, a form of service and a user community, most other publications are apt to refer to Wikipedia without italics, because they're addressing it as a wiki (service/community), not as a publication. But even in running text it would be entirely proper to use italicized Wikipedia when treating it as a publication per se, e.g. in a piece comparing Wikipedia versus Encarta accuracy and depth of coverage about Africa, or whatever.  — SMcCandlish ¢ 😼  12:30, 18 May 2019 (UTC)
  • I don't think there are necessity of italicizing. References and something like that, can be written by bold texts or adjusting size. There is another way to do that kind of activity.-Sungancho951025
  • It depends. If the title can be found, word-for-word, on the web site (not necessarily in the HTML title attribute) then it should be italicized. If no suitable title can be found on the website and a description is used instead, the text in the title position should be upright, without quotes, and with no special typographic treatment; a case can be made for enclosing it in [square brackets]. Jc3s5h (talk) 11:39, 18 May 2019 (UTC)
    With no allowances for WP:COMMONNAME (policy)? - PaulT+/C 06:06, 19 May 2019 (UTC)
    Some purposes for providing a title are to allow a reader to search for the site in case of a dead link, and to confirm the reader has arrived at the correct site once a connection is made. If a description has to be used instead of an actual title, not putting the descriptive title in italics will put the reader on alert to not expect to find the exact text on the website. Jc3s5h (talk) 13:33, 19 May 2019 (UTC)
    I'm sorry. This is a hypothetical on a hypothetical that can lead to confusion for the main point of this RfC. Can you give a specific example of what you mean? I know wgbh.org (with |work= pointing to any of WGBH-TV/WGBH Educational Foundation/WGBH (FM), depending on the context of the citation) was used in the past, but I don't think that is exactly what you mean. - PaulT+/C 16:01, 19 May 2019 (UTC)
  • Yes, italic, the same way we've always done it, for all actual website titles (which are sometimes, though increasingly rarely domain names in form), in citations. No sensible rationale has been provided for changing this. In short, continue to follow MOS:TITLES. This has nothing to do with whether it should be italicized in running prose; that depends on whether the site is primarily seen as a publication (Salon, TechCrunch, or something else, like a service, shop, forum, software distribution channel, or just a corporate info page. In a citation it is and only can be a publication, in that context. WP does not and cannot cite anything that is not a publication (a published source), though of course TV news programs and other A/V content count as publications in this sense; the medium is irrelevant. The citation templates automatically italicize the work title; always have, and should continue to do so (while sub-works, like articles, go in quotation marks, same as newspaper articles, etc.). If you cite, say, Facebook's usage policy in an article about Facebook-related controversies, you are citing |title=Terms of Service|work=Facebook, a published source (a publication); you are not citing a corporation (that's the |publisher=, but we would not add it in this case, as redundant; similarly we do just |work=The New York Times, not |work=The New York Times|publisher=The New York Times Company).

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

  • What we're doing now is correct When citing a website as a work (e.g. |work=, |website=, |newspaper=, etc...), they are italicized . If they are cited as publishers (via |publisher=), they are not. This is how it is, and this is how it should be. Headbomb {t · c · p · b} 13:45, 18 May 2019 (UTC)
    To clarify, are you advocating ignoring do not abuse unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations from MOS:ITALICWEBCITE? (This is an honest question, reading your comment I can see multiple answers to it.) - PaulT+/C 06:06, 19 May 2019 (UTC)
    MOS:ITALICWEBCITE says: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." We don't have to make a black and white choice this RfC is presenting. |work= can be either italic or not, "depending on the type of site and what kind of content it features", per the MOS. -- GreenC 20:07, 21 May 2019 (UTC)
    That is refering to prose, not citations. Also, that quote is from further up in the MOS:ITALICTITLE section. MOS:ITALICWEBCITE is specifically the last part of that section dealing with citations. - PaulT+/C 15:16, 22 May 2019 (UTC)
  • Sometimes The |work= field shows italic, the |publisher= doesn't and you choose which is the best option. SMcCandlish says this RfC is about a small minority of users who dislike italic website names; I have no idea. However I have seen other users say this is about something else, namely that when citing content using {{cite web}} one should always use |work= and never use |publisher=. They arguue everything with a URL on the Internet is a publication and therefore italic. But this argument neatly covers over a complex reality that exists, it is not always right to italicize. Users need flexibility to control who is being credited and how it renders on the page without being forced to always italicize everything and anything with a URL. -- GreenC 14:17, 18 May 2019 (UTC)
    • Almost always the name of the website is the name of the (immediate) publisher; for example, CNN (the website; alternatively CNN.com) has this at the bottom: (C) 2019 Cable News Network. Turner Broadcasting System, Inc. Now, you could make the choice to do Last, First (1 January 2001). "Title". CNN. or you can do Last, First (1 January 2001). "Title". CNN. CNN. or you can do Last, First (1 January 2001). "Title". CNN. TBS. The middle one duplicates information and is also how the vast majority of websites are provided. So that's why we say basically say never to use publisher. It is correct to say that everything on the internet is a publication (you use the "Publish" button to save things onwiki, right? It's a publication when you create a webpage and make it available to other people). Anyone arguing otherwise is clearly so far into edge case territory that they probably should not be using these templates for their citation(s)... --Izno (talk) 18:34, 18 May 2019 (UTC)
      The above is what I mean about a small number of users with a radical plan to eliminate usage of |publisher= when citing anything on the Internet, and always italicizing, be it WGBH-TV or IMDB. -- GreenC 00:26, 19 May 2019 (UTC)
      @GreenC: I'm not following your argument here. Izno doesn't here appear to be arguing against |publisher= as such; but rather is noting that in the typical case it will be redundant with the work (|website=). I am a firm proponent of providing publisher information (cf. the recent contentious RfC on that issue) and even I very much agree that writing, in effect, that CNN publishes CNN or that The New York Times is published by The New York Times Company is pretty pointless. And conversely, I notice some of the outspoken opponents of providing publisher information are in this RfC arguing in favour of the consistent use of italics for the work. I absolutely believe there are some cases where it would be correct to give |publisher= instead of |website= (and obviously there are many where giving both would be appropriate); but in terms of the question in this RfC, I think Izno is correct to dismiss those as edge cases that do not have a siignificant bearing on whether or not to italicize |website=/|work=/etc.
      But your original message caught my attention for a different reason: it implies that there is a need for local (per-article) judgement on italicizing or not the |work=/|website=/|newspaper=/etc. Are you saying there is a CITEVAR issue here? I am sympathetic to the view that stylistic consistency should not be attempted imposed through technical means (whether by bot or by template) if the style choice is at all controversial (in those cases, seek consistency through softer means, such as style guides). But I can't quite see that italization of the work in itself is in any way controversial, and this RfC doesn't affect the option to choose between |website=, |publisher=, or both in those cases when those are otherwise valid options (one can disagree on when exactly those are valid options; but for the sake of discussion let's stipulate that such instances do exist). I, personally, wouldn't have batted an eye if you cited something on cnn.com or nyt.com that was part of the corporate information (investor relations, say) rather than the news reporting as {{cite web|publisher=CNN|url=…}}. Others would disagree, of course, but that issue is not affected by whether or not |work= is italicized. --Xover (talk) 04:47, 19 May 2019 (UTC)
    • "The |work= field shows italic, the |publisher= doesn't and you choose which is the best option." No; read the templates' documentation, Help:CS1, and MOS:TITLES. The work title is required; the publisher name is optional, only added when not redundant, and rarely added at all for various publications types (e.g. newspapers and journals; most websites don't need it either since most of them have a company name almost the same as the website name). No one gets to omit |work= as some kind of "give me non-italicized electronic publications or give me death" WP:GAMING move.  — SMcCandlish ¢ 😼  05:08, 19 May 2019 (UTC)
  • Italicize work/website when title is present, as we do now. As other people have already stated, this is not qualitatively different than a chapter in a book or an article in a journal or magazine, all of which follow the same convention of italicizing the larger collection that the title appears in. —David Eppstein (talk) 19:05, 18 May 2019 (UTC)
  • Yes italics, no change from how we currently cite. Cavalryman V31 (talk) 21:01, 18 May 2019 (UTC).
  • Italics (ideally using |<periodical>= in a citation template) are required when citing any published work, which, by definition, includes all websites. We have direct WP:MOST (a WP:MOS guideline) guidance on this topic at MOS:ITALICWEBCITE, which is directly backed up by three policies (WP:V, WP:NOR, and WP:NOT). Quoting from there:

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

  1. ^ Relevant policies (emphasis in originals):
    • WP:Verifiability: "all material must be attributable to reliable, published sources.... Articles must be based on reliable, independent, published sources with a reputation for fact-checking and accuracy. Source material must have been published.... Unpublished materials are not considered reliable.... Editors may ... use material from ... respected mainstream publications. [Details elided.] Editors may also use electronic media, subject to the same criteria."
    • WP:No original research: "The phrase 'original research' (OR) is used on Wikipedia to refer to material – such as facts, allegations, and ideas – for which no reliable, published sources exist."
    • WP:What Wikipedia is not: New research must be "published in other [than the researchers' own] venues, such as peer-reviewed journals, other printed forms, open research, or respected online publications".
To be clear, this has nothing to do with how websites should be presented in prose and only refers to citations.
Also, there is clearly ambiguity on this point as evidenced by the range of opinions on this matter presented here, but the purpose of this RfC is to attempt to gain clear community consensus in support of our established guidelines and policies. Once gained, we can then clarify the instructions as much as possible so that this consensus is clearly communicated and easily accessible to all editors. The issue right now is that many, many people are (reasonably) misunderstanding the existing guidance on this point.
Up until a few weeks ago, I was included in the group of editors that was misunderstanding these guidelines. I urge everyone to read the above guideline carefully. Try to look at it without any existing bias and seriously consider changing your opinion (not an easy task, I know!) if there is a conflict with the above. Thanks, - PaulT+/C 22:19, 18 May 2019 (UTC)
  • All of that text was added earlier this month with the stated aim of dissuading editors from de-italicising in cite template parameters. I can't see how it can now be cited as proof that the practice is disallowed, any more than if I or someone else had chosen to add guidelines supporting the practice (or went and added them now). Nor do I see that those policies directly support the idea at all. JG66 (talk) 23:21, 22 May 2019 (UTC)
    It isn't my responsibility to defend SMcCandlish's addition there (or to dispute your removal of it), but my interpretation of what he did with those edits was to bring the points into one place so as to clarify existing convention. I don't agree that this represents a change in the spirit of the MOS. - PaulT+/C 15:00, 23 May 2019 (UTC)
    Yep.  — SMcCandlish ¢ 😼  21:01, 25 May 2019 (UTC)
  • Italics—but if the website lacks a name independent of its publisher, then there's no need to invent a name for a citation just to fill in that parameter of the citation template; the publisher in |publisher= will be sufficient. 22:41, 18 May 2019 (UTC) — Preceding unsigned comment added by Imzadi1979 (talkcontribs) 22:42, 18 May 2019 (UTC)
    Already covered this above, twice. Can you provide an example of an actual reliable-source website with no name?  — SMcCandlish ¢ 😼  05:13, 19 May 2019 (UTC)
  • Per WP:CITESTYLE, "nearly any consistent [(i.e. internally within an article)] style may be used … [including] APA style, ASA style, MLA style, The Chicago Manual of Style, Author-date referencing, the Vancouver system and Bluebook." Unless we want to make an exception to that like we do for dates due to special circumstances, this is really a moot matter. If this discussion only regards how this specific template will render such things, then that needs to be made clear. — Godsy (TALKCONT) 01:34, 19 May 2019 (UTC)
    This is at Help talk:Citation Style 1, so it's already clear what the scope is. If you're at an article is consistently using manual citations in some wacky style that, say, puts work titles in small-caps and italicizes author surnames (or whatever), then that same style would be applied in that article to electronic publications. (That said, any citation style that confusing is a prime candidate for a change-of-citation-style discussion on the article's talk page, per WP:CITEVAR).  — SMcCandlish ¢ 😼  05:13, 19 May 2019 (UTC)
  • Italics, with some caveats. Websites are works, so should generally be italicised where there's an official website title. Where there isn't, or where an unofficial title is being used, they should not be italicised. Publishers of websites (eg the BBC) should never be italicised. All of this simply follows the general principles for all forms of citation, and I disagree that the question of whether there's significant creative input into the work is a factor. Espresso Addict (talk) 02:49, 20 May 2019 (UTC)
    You're almost there. To follow on your example, what is the name of the website BBC.co.uk? Isn't it "BBC" (or "BBC News", depending on the actual page) and therefore shouldn't citations from bbc.co.uk have italicized |work=[[BBC]] or |work=[[BBC News]], depending on context? - PaulT+/C 03:09, 20 May 2019 (UTC)
There isn't a single website name. www.bbc.co.uk has no obvious title; www.bbc.co.uk/news is BBC News; www.bbc.co.uk/sport is BBC Sport; and so on. The publisher is the BBC. Espresso Addict (talk) 04:31, 20 May 2019 (UTC)
Actually, in this example, there would be just one website, the one suffixed with the top-level domain. That is the work. Anything that comes after the slash is a "chapter" in that work, or a "department". If there is a prefix like news.bbc.co.uk (that is to say a subdomain), then that should be listed as the work, since such subdomains have their own hierarchy. I believe this treatment corresponds to both the technical and the functional aspects. 72.43.99.130 (talk) 13:40, 20 May 2019 (UTC)
  • Italics, how we've always done it (or should have always done it). Kaldari (talk) 16:06, 20 May 2019 (UTC)
  • It depends MOS:ITALICTITLE says that only websites with paper equivalents (The New York Times, Nature, etc) and "news sites with original content" should be italicized. Personally, however, I never italicize news websites that don't have paper equivalent or aren't e-magazines (BBC, CNN, etc). Brandmeistertalk 10:06, 21 May 2019 (UTC)
    That is true for mentions in the prose, but not for citations. MOS:ITALICTITLE also says (at MOS:ITALICWEBCITE) When any website is cited as a source, it is necessarily being treated as a publication, and in that context takes italics. (See above for the full quote and direct references to policies backing it up.) This is very clear guidance on the subject. - PaulT+/C 15:16, 22 May 2019 (UTC)
    Looks like it was removed as an undiscussed addition, also MOS:ITALICWEBCITE redirects to general Wikipedia:Manual of Style/Titles, not to specific section. That addition, if proposed, should gain consensus first. Anyway personally I don't see a compelling reason to format ref names differently compared to prose. Brandmeistertalk 22:04, 22 May 2019 (UTC)
    Yes, it was removed (see below), though I have a feeling the removal will also be disputed (hopefully it doesn't fork this discussion unnecessarily). The text is directly quoted above as well and it is directly supported by quotes from policies. References have different formatting from prose for all kinds of reasons. Our personal preferences aren't really supposed to enter into it when guidance is clear. - PaulT+/C 22:28, 22 May 2019 (UTC) Oh, and the shortcut currently points to the full WP:MOST page because the anchor was also removed. I'll have to think about whether it needs to be retargeted or not. Maybe here at #ITALICWEBCITE (at least while the discussion is ongoing)? - PaulT+/C 22:31, 22 May 2019 (UTC)
  • It depends. Per comments above by Masem and Randy Kryn. As an article writer here, I'm looking to ensure there's consistency between what appears in the text and in a citation: I wouldn't italicise AllMusic, IMDb, Metacritic, Rock's Backpages, etc, in prose, so it seems fundamentally wrong to italicise those names when they appear in a source. And not that we would be citing it in many (any?) articles, but Wikipedia itself is a good example. JG66 (talk) 14:25, 21 May 2019 (UTC)
    This is directly contrary to MOS:ITALICWEBCITE (see directly above). Citations can be (and often are) formatted differently than running prose. - PaulT+/C 15:16, 22 May 2019 (UTC)
    It's only "directly contrary" to MOS:ITALICWEBCITE because SMcCandlish bloody added the text there on 2 May!! JG66 (talk) 15:28, 22 May 2019 (UTC)
    It is probably not a good idea to outright remove it while we are in the middle of this discussion. Any chance you'll self-revert? - PaulT+/C 21:12, 22 May 2019 (UTC)
    I'm afraid not, and I think it's not a good idea that the text was added there. After all, you're repeatedly citing it as an MOS guideline supported by policy, when in fact another editor has simply invented the guideline. JG66 (talk) 23:21, 22 May 2019 (UTC)
  • Italics. For purposes of citation, it's a publication, even if it's online. Putting it in Roman instead would make the publication name blend into the other metadata elements, making it harder to read. —{{u|Goldenshimmer}} (they/their)|😹|✝️|John 15:12|☮️|🍂|T/C 18:09, 22 May 2019 (UTC)
  • Leaning toward Italics: It should be as easy as possible to write citations, and people shouldn't be gaming the system with tricks for special font formatting or using |publisher= instead of |work= when they cite some websites (which can also cause metadata to be mixed up). If I find something on the CNN website, I should be able to just use "|website=[[CNN]]", and the same for citing the website for ABC News, BBC, NPR, PBS, WGN-TV, Associated Press, Reuters, Metacritic, Rotten Tomatoes, Box Office Mojo, Salon, Wired, HuffPost, The New York Times, etc. Writing citations should be dirt simple, and these sort of references are extremely common. If we don't do that, it seems difficult to figure out what rule we would follow instead. (e.g., if it seems like the name of an organization, don't italicize it, and if it is a content aggregator without original content, don't italicize it? – that seems unlikely to be advice that editors can consistently follow in practice.) —BarrelProof (talk) 05:21, 23 May 2019 (UTC)
    No one is gaming the system. Template:Cite web allows both work= and publisher= parameters, depending on source, and lists some websites (National Football League, International Narcotics Control Board, etc) in straight format, not italics. This is because CNN, International Narcotics Control Board or National Football League are not the same type of work as Encyclopedia of Things, Nature, etc. They are authority organs rather than paper publishers and this is consistent with MOS:ITALICTITLE. Brandmeistertalk 09:41, 23 May 2019 (UTC)
    Except that those "authority organs" publish a website. When a publication is cited, it is by definition a major work and therefore take italics per MOS:ITALICTITLE (and the policy cited in #ITALICWEBCITE, before it was removed). Using |publisher= instead of |work= when citing those publications just to change formatting conflates them and pollutes the usefulness of those separate fields. (Semi-off-topic question, is there a page where the metadata created by the citation templates is explained? Having that information explicitly spelled out somewhere might be useful to this discussion as well.) - PaulT+/C 10:33, 23 May 2019 (UTC)
    Per current guideline, only "online magazines, newspapers, and news sites with original content should generally be italicized". Websites in general are not listed among "Major works". Otherwise various organizations (UN, NBA, etc), referenced in corresponding official websites, would also be treated as "works", which is nonsensical. The change of that guideline part apparently begs for talkpage discussion, because it was reverted. Brandmeistertalk 11:51, 23 May 2019 (UTC)
    You are quoting a point that only applies to running prose. No one is disputing that (the bit about how the guideline applies to prose). Anything that is a published work, which includes every website, and is used as a citation, which requires complying with WP:V, WP:OR, and WP:NOT, qualifies as a "major work" and is therefore italicized per WP:MOST. You are conflating the "various organizations" with the websites they publish, which are published works when used in a citation as described earlier. - PaulT+/C 15:00, 23 May 2019 (UTC)
    WP:MOST makes no distinction between running prose and references for that matter (which is why |publisher= does not italicize by default, unlike |work= which does). Also, treating prose and refs differently may introduce WP:CREEP and is counter-intuitive. Italicizing all website names through default italicizing ref parameter may look like making things easier, but if it ain't broke, don't fix it. Brandmeistertalk 15:52, 23 May 2019 (UTC)
    (edit conflict)
    Module talk:Citation/CS1/COinS may be helpful. The table there is generally accurate but a bit out of date (newer preprint templates not mentioned, etc). For the purposes of cs1|2, {{citation}} when any of the |work= aliases have assigned values, {{cite journal}}, {{cite magazine}}, {{cite news}}, and {{cite web}}, Module:Citation/CS1 treats these as 'journal' objects. Pertinent to this discussion, |publisher= is not made part of the COinS metadata for journal objects. When editors write cs1|2 citations with 'website names' in |publisher= to avoid italics, those who consume the citations via the metadata do not get that important piece of information. This is a large part of the rationale for the pending change that requires periodical cs1 templates to have a value assigned to a |work alias= (see this discussion and the implementation examples).
    Trappist the monk (talk) 11:57, 23 May 2019 (UTC)
    Thanks, this is helpful. I'll dig into it when I have some more time. - PaulT+/C 15:00, 23 May 2019 (UTC)
    My understanding is that the identification of the published work is considered more fundamental, at least for metadata purposes, than the name of the publisher of the work. The guidelines say that identifying the publisher is unnecessary if it is basically just redundant or obvious once the name of the work is known. This is completely straightforward when the work is The New York Times and the publisher is The New York Times Company. When publishers use their organization name as their website's name, it does seems a bit more awkward, but in my view, that what they have chosen to do – they chose what title to use for their published work, and we should just follow their choice. The CNN organization has chosen to entitle its website (i.e., its published work) as "CNN" (using italics here not because they do that, which they don't, but rather because that is how we ordinarily format the titles of works, and MOS:TM says not to imitate logo styling). I think it is too complicated to second-guess this choice they have made. If we want to cite their published work, and they have chosen the title "CNN" for their publication, we should just refer to their published work as "CNN". Otherwise, we would need to make some judgment call in every case between whether the name of the website seems more like the name of their publication or seems more like the name of their organization, and do something different in the two cases. I think that's too complicated. It would get even more complicated if we also start trying to do something different depending on whether they are publishing original content or not (e.g. Metacritic), and I don't even understand the rationale for not wanting to italicize some names – some of those sites are publishing original content, not just using what has already been published elsewhere. Anyhow, my understanding is that the intent of the parameter names is not primarily for font formatting. Choosing to fill in different parameters for font formatting purposes is what I referred to as "gaming the system", because I believe the parameter names were not really intended for that purpose. The parameter names are |work= and |publisher=, not |italicname= and |uprightname=. I suppose I might not object if someone wants the templates to support some additional parameter type like |uprightsitename=, but I think that's too complicated to expect it to be broadly understood and applied consistently. —BarrelProof (talk) 19:47, 23 May 2019 (UTC)
    I've noticed that when pointed to WP:MOST, italics supporters say it doesn't apply to refs, only to prose, but when this guideline suits their agenda, they say websites are "major works". Either one does not treat websites as "major works", because current WP:MOST does not apply to them (in which case they remain upright) or he/she respects current WP:MOST, which does not advise to italicize all websites. Seriously, double standards. Brandmeistertalk 07:05, 25 May 2019 (UTC)
  • Italics per SMcCandlish, and as I'm not seeing any compelling reason to make such a tiresomely complicated yet small change throughout all our citations. Bilorv (he/him) (talk) 19:46, 24 May 2019 (UTC)
  • Italics – I will never understand the distinction people try to make between online sources and print publications. Maybe that made sense in the 1990s but increasingly publications originate as web-only, or previously print publications cease printing and move to all-digital. I also fail to see the problem with italicizing a domain name if that's the best "title" for the publication. If a website includes the material you are citing, obviously it is serving as a publication and, as such, should be italicized. It also seems like it would circumvent a LOT of edit wars to simply declare all websites are "major works" and their names should be italicized as such in article prose, because the current weirdness of "well what kind of website is it?/what types of information does it contain/provide?" is such a stupid time sink. And that in turn would help avoid the whole "do we italicize website titles in citations?" debate, too. —Joeyconnick (talk) 20:04, 24 May 2019 (UTC)
  • Italics: I think the names of websites should be italicized. Right now we are only talking about italicizing them in citations, but I think in the long run we will italicize them at all times. Like other things we italicize, they are named works with a publisher and subparts. This is not now common but such things move slowly and websites are relatively new. For now, I would favor italicizing the names of websites in citations/references and in external links. They are published sources.
    I'd be completely comfortable saying that the name of the website is CNN or CNN.com which is published by CNN. CNN is a company which has a TV channel, a network, a publisher and a website. It publishes a bunch of TV programs and films. It also publishes a website called CNN or CNN.com. When we cite something from that website it should be italicized. SchreiberBike | ⌨  23:50, 24 May 2019 (UTC)
  • Italics. In CS1, sources such as websites are italicized, parts of sources such as webpages are quoted, and publishers such as domain owners are in plain text. This has been the consensus, and seems to be working well. 24.105.132.254 (talk) 16:42, 26 May 2019 (UTC)
  • Generally italics, but it depends - per SMcCandlish, but there are times that italics aren't needed and shouldn't be required --DannyS712 (talk) 05:39, 27 May 2019 (UTC)
    • Per SMcCandlish? Can you double-check that? I believe SMcCandlish was italicize (always), not it depends. —BarrelProof (talk) 13:06, 27 May 2019 (UTC)
      • It depends in that some online entities are not italicized in running prose, being generally of the character of a service or some other non-publication, in typical-use context. If we cite them in a source/reference citation, however, we are only ever citing them as one kind of thing: a publication (a published source), so in a citation the italics belong there.  — SMcCandlish ¢ 😼  17:23, 12 June 2019 (UTC)
        • I thought it was implicitly understood that this was talking about what to do in citations. —BarrelProof (talk) 18:57, 12 June 2019 (UTC)
  • Italics per SMcCandlish. Malcolmxl5 (talk) 06:33, 26 June 2019 (UTC)
  • Italics When I cite something I read on https://www.nbc.com, I am not citing the network because the network is on television. Something I saw on television is not my source. I am citing the website which is a periodical and just so happens to share a name with the network. The publisher is "NBCUniversal". The "website=" is the proper parameter to use in this example. I don't see why non-periodical should be treated differently. They are a body of creative work and should be italicized similar to a book, a television series, or art. Misusing "publisher=" is not acceptable no matter how long that has been the status quo. Rotten Tomatoes is published by Fandango. AllMusic is published by RhythmOne. <publisher> is different from <work>.--- Coffeeandcrumbs 04:31, 28 June 2019 (UTC)
  • I've only just been made aware of this RfC, so I'm afraid I'm weighing in late. No italics for non-periodicals When we cite The New York Times, we give The New York Times in the footnote, and not NYTimes.com. Because NYTimes.com is merely a delivery system. What we're citing is the news-gathering expertise of The New York Times. So likewise when we cite NBC News, the website NBC.com is just a delivery system. We're not citing the IT guys and website administrator — we're citing the professional journalists and editors of NBC News.
Same with institutions: The British Board of Film Classification is not a print/online book, magazine or newspaper. No one italicizes it or Dept. of Commerce or The Academy of Motion Picture Arts and Sciences. Why would we? And Rotten Tomatoes and Box Office Mojo are databases, not books or periodicals, and likewise are never italicized, by themselves or by their Wikipedia articles. What's the upside of Wikipedia using an eccentric style?
Modern Language Association (MLA) italicizes websites in footnotes. However, neither Associated Press (which eschews italics for quote marks) nor the Chicago Manual of Style (as explained here italicizes websites. (There are about 16 or 17 citation styles in more-or-less regular use, incidentally, if we really want to go through them all.) So it's not like there's any consensus in the broader world outside Wikipedia for italicizing websites. Differentiating between books / periodicals and organizations / institutions / databases is more in line with the real world and offers clarity and specificity, two things an encyclopedia at its best provides.--Tenebrae (talk) 05:13, 29 June 2019 (UTC)
  • Italics. Maintain the present status quo and cleanup where needed. The italics debate goes way, way back, and there have always been some editors who have fought the trends. The debate has been reduced significantly over the last ten years, and Wikipedia (the project) and Wikipedia (the reference work) have been much improved for it. May the Bird of Paradise fly up the nose of those few editors who still can't or won't get with the program. Best to all! Paine Ellsworthed. put'r there  09:27, 29 June 2019 (UTC)
It would be more productive to actually address the point about why we don't cite "NYTimes.com:" than to engage in ad hominen attacks on those who disagree with you. As for "following trends", an encyclopedia does what's best for clarity and specificity, regardless of passing "trends".--Tenebrae (talk) 15:40, 29 June 2019 (UTC)
Hey, Tenebrae, been awhile. Good to talk with you again! As for what specific points to address, please see the opinion and other posts by SMcCandlish, as I agree with it on these issues. So if you must beat someone up about it, that's the editor to mangle, because it (SMcCandlish) is always throbbingly controversial. !>) By following trends, I did not mean "passing trends", but instead those lasting ones that ultimately resulted in how external resources and Wikipedia apply the use of italics in the present day. Paine Ellsworthed. put'r there  01:53, 30 June 2019 (UTC)
And I think it's you who needs to "get with the program". You've linked to an RfC on the use of italics in article titles, but the issue here is whether titles of sites that are not italicised in regular text should be italicised in citations. You appear to be a fan of italicisation for the sake of it. JG66 (talk) 16:25, 29 June 2019 (UTC)
I'm a little confused since I'm saying just the opposite, as a matter of fact. If we're citing a periodical or book, whether online or printed, yes, italicization is standard. But if we're citing a company, then no. The argument that we should cite NBC.com for an NBC News citation or NYTimes.com for a The New York Times citation seems eccentric and non-standard. --Tenebrae (talk) 00:02, 30 June 2019 (UTC)
You are misstating my point. The news website that belongs to NBCUniversal is not named NBC.com. It is called NBC News and is published by a division of the same name. I would never put a .anything outside the |URL= . Two entities that belong to the same company can share the same name. In this case, there are two entities of different types: a publication (NBC News) and a publisher (NBC News division of a parent company NBCUniversal). We disambiguate them by italics. Using the proper parameter also allows it to be machine-readable. --- Coffeeandcrumbs 09:13, 4 July 2019 (UTC)
@Tenebrae: Pretty sure that Editor JG66 was not replying to you (who did not link to an rfc) but to Editor Paine Ellsworth. I am removing the indent that you added with this edit.
Trappist the monk (talk) 00:10, 30 June 2019 (UTC)
Tenebrae: Sorry, I could have made it clearer. It is as Trappist the monk says. JG66 (talk) 04:44, 30 June 2019 (UTC)
Thank you, JG66, for thoroughly misunderstanding what I wrote, although that's probably as much my fault as yours. I think I've been with the program for many years, as I've been involved in many italics discussions and have learned much about the changes over the years in external style guides as they pertained to the applications of italics. I've always sought to improve Wikipedia's italic stylings in line with those external resources. The link I gave was just an illustration, an example, a gentle reminder that before then and since, editors have worked hard to get the policy and guidelines updated to their present not-too-shabby condition where italics are concerned. As for being some kind of fan of italics just for the sake of it, I really could care less. My only concern is whether or not this encyclopedia is consistent with other reference works in its application of italics. Paine Ellsworthed. put'r there  01:42, 30 June 2019 (UTC)
Thanks for the shout-out, Paine Ellsworth. I've been away mostly since it's just these types of discussion that cause me to. As I'd mentioned, the widely used Chicago Manual of Style, for one, does not italicized websites, so this issue is not a question of Wikipedia being 'consistent with other reference works" — it is consistent with other reference works. Just not the one you prefer (MLA).
There is a valid, extremely useful distinction to be made between books / periodicals and institutions, companies and other organizations. I find the always-italics reductivism perplexing. By the arguments presented here ("I'm not citing NBC News but NBC.com), then virtually nothing would ever be non-italicized, since all companies have websites. By these arguments, we'd never cite the British Board of Film Classification but only bbfc.co.uk. We'd never cite Box Office Mojo but boxofficemojo.com. We'd never cite Johnson & Johnson but jnj.com. I think most people would find this eccentric and anti-intuitive. NBC News is not italicized, and placing it in a "website=" field that would italicize it and Dept. of Commerce and Johnson & Johnson, etc. goes against logic and common sense.--Tenebrae (talk) 12:51, 30 June 2019 (UTC)
That's more of a discussion of how to use the template. In those cases, you would use both website/work and publisher in the template. publisher=Johnson & Johnson |website=jnj.com. It would really be the same if they published a monthly journal of their own. publisher=Johnson & Johnson |work= JJ's Journal Alaney2k (talk) 14:04, 30 June 2019 (UTC)
jnj.com is not the name of the website; it is a shortened URL which a user can type into almost any browser address bar. The website has a name which happens to be the same as the name of the company that publishes it. So it would be |website=Johnson & Johnson |publisher=Johnson & Johnson. But in the same way we would not write |work=The New York Times |publisher=The New York Times Company, we would not list the Johnson & Johnson twice. Therefore, we arrive at simply |website=Johnson & Johnson. I will give you another example to demonstrate my point. NASA has many website including https://images.nasa.gov/. When citing this webiste as a source, I would not use |website=images.nasa.gov |publisher=NASA because the website has a name NASA Image and Video Library. This is a website and not a physical library. Several NASA centers contribute to it and is entirely contained online. Again here, the name of the publisher is superfluous so we also arrive at simply |website=NASA Image and Video Library. --- Coffeeandcrumbs 08:48, 4 July 2019 (UTC)
  • Italics. While there are some inconsistencies with some common usage, I think most of the issue is the misuse of the template. We should be trying to use both work/website and publisher so that we are completely informative. Italicizing the work distinguishes the two nicely when reading. Alaney2k (talk) 14:04, 30 June 2019 (UTC)
I think when the citation already links to jnj.com that it's redundant to additionally say jnj.com. It addition to being redundant, this would simply add links to a commercial concern. What is the user-benefit of helping a company by adding twice as many links to it as the citation needs? --Tenebrae (talk) 14:58, 30 June 2019 (UTC)
Maybe it's important to know (for inexperienced editors) or at least gently remember (the rest of us) that using the markup for italics in the |website= parameter eliminates the italics in the end result. For example, when one uses |website=''jnj.com'' in the citation code, it comes out upright, as in:  jnj.com. So is the solution you seek 1) to eliminate the italics in the parameter or 2) to educate editors in its correct usage? Paine Ellsworthed. put'r there  17:10, 30 June 2019 (UTC)
I completely agree with you, Paine — I was, in fact, doing that for things like Rotten Tomatoes that are not italicized. But I believe I read somewhere in this discussion that such Wiki markup in templates adversely affects the metadata. If that's incorrect, then, yeah, I think we're reaching a middle ground.
Another possibility is to have a template called something like "Cite company" or "Cite organization", where NBC, Rotten Tomatoes etc. would not be italicized. But that's probably a separate discussion.--Tenebrae (talk) 22:14, 30 June 2019 (UTC)
  • Italics per SMC. CThomas3 (talk) 05:08, 15 July 2019 (UTC)
  • Italics Normally we use "publisher" for something like NASA. "website" is only ever used for a uri, e.g. |website=astrology.org.au If there is a publisher, website is not used; it is avoided whenever possible. "work" is never used for a newspaper; "newspaper" is always used instead 9and gives you italics), and we don't bother with publisher for newspapers, journals, magazines etc "work" is also generally avoided. However, for a TV site like CNN, we use publisher.|publisher=CNN Hawkeye7 (discuss) 06:41, 15 July 2019 (UTC)
    "website" is only ever used for a uri – this is simply not true; read the discussion above, especially the explanations by SMcCandlish. |website= is an alias of |work=, and should be used in the same way, as it is in citation-generating templates like {{GRIN}}, {{WCSP}}, etc. Peter coxhead (talk) 14:59, 15 July 2019 (UTC)
  • Italics per SMC. I entirely agree that editors should not be "abus[ing] unrelated citation parameters, such as |publisher=, to evade italicization of online work titles in source citations" because I see it happen all too often, and I don't think this should have been removed from MOS:T either. I don't understand why some editors will go out of their way to avoid using a parameter that italicises something as if it's "wrong". Ss112 08:48, 21 July 2019 (UTC)
Well, because it indeed might be wrong. Rotten Tomatoes, for instance, is not italicized.--Tenebrae (talk) 00:18, 7 August 2019 (UTC)

Discussion and alternativesEdit

  • My impression is that much of the time when people list |website= in citations, they really mean |newspaper= (for newspapers that publish online copies of their stories), |magazine= (ditto), |publisher= (for the name of the company that owns the website rather than the name that company has given to that specific piece of the company's web sites), or even |via= (for sites like Legacy.com that copy obituaries or press releases from elsewhere). Newspaper and magazine names should be italicized; publisher names should not. Once we get past those imprecisions in citation, and use |website= only for the names of web sites that are not really something else, I think it will be of significantly less importance how we format those names. —David Eppstein (talk) 06:32, 18 May 2019 (UTC)
    I agree that people frequently use the wrong parameter and that this should be cleaned up, but it doesn't really address the root issue here. There's a tiny minority of editors engaged in kind of "style war" against italicizing the titles of online publications, and it's not going to stop until this or another RfC puts the matter to rest. There is nothing mystically special about an electronic publication that makes it not take italics for major works and quotation marks for minor works and sub-works, like every other form of publications, even TV series/episodes, music albums/song, and other A/V media.  — SMcCandlish ¢ 😼  12:30, 18 May 2019 (UTC)
    We might have common ground: I don't think any of us disagrees that books and periodicals, whether in print or online, should be italicized: Salon, Newsweek, etc. It's when the cite is to an organization like the British Board of Film Classification or NBC News or Rotten Tomatoes that are not books or periodicals, and are not normally italicized.--Tenebrae (talk) 22:19, 30 June 2019 (UTC)
    It's been a couple of days, and this seems the correct section, "Discussion and alternatives", to talk about middle ground. Paine Ellsworth suggested that for non-italicized companies and organizations, like NBC News and Rotten Tomatoes, that we simply do wiki-markup to de-italicize the website= field. Or, we could have an additional template called something like "Cite company" or "Cite organization", where NBC, Rotten Tomatoes etc. would not be italicized. Surely a workable, practical compromise can be reached, as is the goal of consensus. --Tenebrae (talk) 21:39, 3 July 2019 (UTC)
    Also — and as a journalist this strikes me as obvious, though it just occurred to me this might not be so to the general public — there is a critical distinction between publications (italicized), which fall under the rules of journalistic standards, practices and ethics, and companies and organizations like Sears or Rotten Tomatoes or Amtrak (not italicized), which are not obligated to follow journalistic standards, practices and ethics.--Tenebrae (talk) 19:49, 11 July 2019 (UTC)
    Sorry, but no. You think a reference to something published on the NBC News website should not use italics? How about The National Enquirer and The Daily Mirror and the Weekly World News? (Those publications don't seem to feel obliged to "follow journalistic standards, practices and ethics", so should we not use italics for those too?) Are you suggesting we use italics as an indicator of reliability? —BarrelProof (talk) 12:11, 14 July 2019 (UTC)
    You're making my point: There is no one-size-fits-all solution, because publishing, broadcasting and the web are, like humans, complex. Saying everything should be italicized is just such an impractical, one-size-fits-all solution.--Tenebrae (talk) 00:20, 7 August 2019 (UTC)

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

  • Instead of hyperbole, perhaps it would be a good thing for you to:
    1. identify the editor whom you accuse of this malfeasance
    2. identify which of the many MOS pages was modified
    3. link to the actual edit
    Trappist the monk (talk) 14:18, 9 August 2019 (UTC)
    It already was identified: At least one other editor, JG66, noted this SMcCandlish edit here not long after it happened, and somehow the comment got buried and missed in this avalanche. JG66 even included the link to the actual edit, which is this one.
    Just want to note that hyperbole means "extreme exaggeration". Stating factually that an editor in this discussion unilaterally changed the MOS page to his preferred version after this discussion began is literally not hyperbole.--Tenebrae (talk) 17:03, 11 August 2019 (UTC)
    Editor SMcCandlish's edit to MOS:TITLE occurred on 2 May 2019. Isn't that 16ish days before the 18 May 2019 start-date of this RfC? Perhaps the claim that [an] editor [SMcCandlish] in this discussion unilaterally changed the MOS page to his preferred version after this discussion began (emphasis in original) is not correct?
    Trappist the monk (talk) 22:08, 11 August 2019 (UTC)
    My apologies: Both the other editor and I must have scanned "2 May" as "22 May" in our minds. I've struck out my comments.
    That said, the 2 May edit still appears to have been done unilaterally without discussion. One editor "clarified" the MOS to his personal preference without talk-page consensus. That still is not right — and it remains a fact that italicizing EVERYTHING, even company names that are never italicized, is an extremist eccentricity not in mainstream footnoting.--Tenebrae (talk) 17:21, 21 August 2019 (UTC)

ClosingEdit

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

Are you in a hurry? If you force a conclusion to this rfc tomorrow, nothing would happen here because we is still have to conclude the pmc rfc. You might as well let this one run its full time.
Trappist the monk (talk) 00:30, 7 June 2019 (UTC)
@Trappist the monk: Any objection to closing now? I'm not clear on why there is an advantage to wait until the pmc rfc is ready to close. Thanks, SchreiberBike | ⌨  22:37, 27 June 2019 (UTC)
I did not mean to imply that this rfc closure should wait until the pmc rfc is closed. I did not / do not see any need for an early closure. Now that the rfc has expired, of course it can be closed. Don't expired rfcs end up on some list somewhere to be formally closed?
Trappist the monk (talk) 23:02, 27 June 2019 (UTC)
Close requested hereSchreiberBike | ⌨  02:52, 28 June 2019 (UTC)
That was a full month ago. Just adding a comment here to prevent auto-archiving. —BarrelProof (talk) 02:10, 3 August 2019 (UTC)
Another two weeks. Just adding another comment here to prevent auto-archiving. —BarrelProof (talk) 23:36, 19 August 2019 (UTC)

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

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

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

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

The following pages have been notified:

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

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

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

Follow up responsesEdit

  • clarification needed - I assume we are just talking about CS1 template here. If so, a lot depends on which citation style our CS1 template is based upon. Different styles present websites in different ways (some italicized, some not). So which style guide is the template based on? Blueboar (talk) 15:47, 6 October 2019 (UTC)
    @Blueboar: The exact question is whether the earlier discussion applied to all references to websites, whether it applied to something lesser (e.g. as used in CS1/2), or something even smaller than that. I find it hard to believe that it would be something lesser than CS1/2 based on the discussion and context, but someone may argue such. --Izno (talk) 18:11, 6 October 2019 (UTC)
  • Italics in cs 1/2 templates - per the RFC discussion above. 72.43.99.138 (talk) 15:08, 6 October 2019 (UTC)
  • {{Cite web}} only. The location of the discussion, Help:Citation Style 1, put editors on notice that the RFC only applied to that style. {{Cite web}} is the only template in that style I know of that calls for giving the title of the website as such. Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. Jc3s5h (talk) 15:13, 6 October 2019 (UTC)
    Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. This is a different discussion. Let's keep on topic. 72.43.99.138 (talk) 15:17, 6 October 2019 (UTC)
  • CS 1/2 only, but only web site / work, not publisher. Some discussion since the first RFC has attempted to extend the italicization to publishers (that is, organizations, not collective groups of web pages) in the absence of a web site / work parameter, and that is incorrect. This should only apply to CS1 and CS2 per WP:CITEVAR. —David Eppstein (talk) 16:52, 6 October 2019 (UTC)
    I don't think I've seen anyone claim that |publisher= should italicize anything. --Izno (talk) 18:11, 6 October 2019 (UTC)
    No but some have argued that when a website has no title, the publisher's name should be used as |website= and be italicized, which is, indeed, italicizing the publisher's name. Levivich 18:13, 6 October 2019 (UTC)
    Which is also a different discussion. --Izno (talk) 18:19, 6 October 2019 (UTC)
  • Rerun this RFC from scratch – and this time advertise it on CENT. The proposal should be clear about what will change if it passes. So "Should websites always be italicized" isn't a great question. A better one would be, "Should we make change X to the MOS", or "Should we make change X to the citation template code", or something concrete like that. We need to differentiate between an MOS-style guideline directive, and a hard change to code. We also need to differentiate between work= and publisher= as discussed above. In my view, the scope of the existing RfC is nil because of the procedural flaws. Levivich 17:48, 6 October 2019 (UTC)
    @Levivich: The original proposal was listed on CENT. Please don't make this about whether it was advertised; that was not the question asked. --Izno (talk) 18:08, 6 October 2019 (UTC)
    Where? I couldn't find it. Levivich 18:12, 6 October 2019 (UTC)
    @Levivich: Review the link provided in my response. --Izno (talk) 18:14, 6 October 2019 (UTC)
    I didn't see it at first but now I see it. It should be advertised clearer on CENT. For example, the CENT advertisement was "Italics of websites in citations", and not the clearer, "Should website names always be italicized?" or the even clearer, "Should {{cite web}} always require a website name, which is always italicized?" Levivich 18:16, 6 October 2019 (UTC)
    Not per the guidelines established on Template:Centralized discussion#Style. If you take a minute to review the history of that template, the intent is to be short and sweet. I used the title the discussion was started under (for better or worse). --Izno (talk) 18:19, 6 October 2019 (UTC)
    Added to WP:CENT
    Trappist the monk (talk) 11:30, 9 October 2019 (UTC)
  • CS1/2 templates only. I think that's obvious from the context in which the question was asked. Were it to have been asked elsewhere (say, WT:MOS or WT:CITE), it might reasonably have been interpreted to mean all citations/references, but here, I do not think that was the case. --Izno (talk) 18:14, 6 October 2019 (UTC)
  • No, the titles of websites (if they have a title; most don't) should not be italicized. Where they lack a title, the URL should not be italicized. But whether or not website titles are italicized, in no circumstances should the publisher be used as the website title and italicized. That is, the title of https://www.supremecourt.gov/ is not "Supreme Court of the United States" or, even worse, Supreme Court of the United States. That site doesn't have a title. The website's publisher is the Supreme Court of the United States, and that should never be italicized. Ditto with World Health Organization, BBC News, CNN, etc.
    The Chicago Manual of Style says: "Titles of websites mentioned or cited in text or notes are normally set in roman [not italicized], headline-style, without quotation marks." Their examples include Project Gutenberg and Wikipedia. If the website has a printed counterpart, it is italicized along with the printed version, e.g. Encyclopaedia Britannica Online. Where websites have no formal title, use a short form of the URL, e.g. Apple.com, not italicized. See The Chicago Manual of Style, section 8.191, pp. 538–539. SarahSV (talk) 18:49, 6 October 2019 (UTC)
    Just a reminder, the purpose of this discussion is to decide how to apply the determined consensus in the previous RFC, not to debate the outcome. Steven Crossin Help resolve disputes! 19:44, 6 October 2019 (UTC)
    Steven, I wonder whether the previous RfC delivered a clear-enough consensus. We generally don't italicize websites. Wikipedia, for example, isn't italicized; nor are Facebook, Twitter, etc. Why italicize them only in citations? Our style choices should be consistent, at least within the same article. SarahSV (talk) 22:20, 6 October 2019 (UTC)
    I agree with Levivich that the RfC needs to be rerun. Wikipedia:Manual of Style/Titles does not support italicizing all websites: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." Online newspapers, for example, are italicized. Other types of site are not. It needs to be decided on a case-by-case basis, making sure that each article is internally consistent. It makes no sense to write "Wikipedia" without italics throughout an article, then force people to use italics in a citation, but only if a template is used. SarahSV (talk) 22:37, 6 October 2019 (UTC)
I agree that we shouldn't be challenging the previous outcome in this RfC, since it's not the question being asked. With that said, an important distinction getting missed is when a website is being cited as a publication for the material it supports; that's when italicization should be invoked (according to the outcome above). Simply stating "Wikipedia" or "Facebook" in running text to reference the company or entity they represent places the website name in a different context. And in regard to the Chicago MoS perpective, keep in mind that the MLA format does support italics in citations. The inconsistency you're pointing out already exists outside of Wikipedia. --GoneIn60 (talk) 06:44, 12 October 2019 (UTC)
  • Rerun the RfC. CS1/2 templates. Specifically, |website= for all templates and |work= for the {{cite web}} template. So, for example, Apple is a company that publishes websites Apple (apple.com), Apple Support (support.apple.com), Apple Developer (styled  Developer ; developer.apple.com), etc. — UnladenSwallow (talk) 19:32, 6 October 2019 (UTC) Update: After thinking more about the problem, I agree with the other commenters that this RfC needs to be rerun. — UnladenSwallow (talk) 00:31, 7 October 2019 (UTC)
  • Rerun RfC per Levivich. Failing that, the italicization requirement should apply only to |website= in CS1 templates, and that parameter should not be required. Nikkimaria (talk) 00:27, 7 October 2019 (UTC)
  • Apply broadly: So, let's see if I am getting this wrong. 😜 You've asked people and they've told you. If the majority of the participants had a constraint in mind, they'd have told you. AFAIK the italicization helps identify the citation component, not the role and the object of the work. flowing dreams (talk page) 05:03, 7 October 2019 (UTC)
No, the reverse is true. Italicization in citations is semantic (Chicago, the city, vs. Chicago, the musical). It is not there to make a citation component stand out visually. — UnladenSwallow (talk) 09:01, 7 October 2019 (UTC)
LOL. I never said "to make a citation component stand out visually". I said "helps identify the citation component", which is a semantic role. You gave a very good example for it: "Chicago" is a publication location, "Chicago" is a published work. flowing dreams (talk page) 09:53, 7 October 2019 (UTC)
Oops. Sorry for misunderstanding you. I now get what you were saying: italicization is there to help us find the website title in a citation, not to tell us the type of the website (blog, web app, social media platform, etc.). — UnladenSwallow (talk) 20:30, 7 October 2019 (UTC)
  • Apply to CS1 only: It just occurred to me that it is meaningless to conduct an RFC about the italicization of website names across several styles unless we know for sure that all those styles have vague italicization requirements. And there is no evidence to suggest that people interested in styles other than the citation style 1 have participated in the original RFC. flowing dreams (talk page) 09:40, 9 October 2019 (UTC)
  • italicize |website= in CS1/2 templates – I did not participate in the original discussion, but I do follow this talk page, which is used for discussion of these templates. When someone proposes here that a certain kind of citation should look like X, or that a certain combination should be forbidden, they are understood to be talking about the behaviour of these templates. I understand that other pages are used for discussing the MOS, and no change to the wording of MOS was proposed here. Kanguole 08:45, 7 October 2019 (UTC)
  • Rerun the RfC. Alternately, apply this only to the CS1/2 templates — While this was posted at CENT, such a major, major change to Wikipedia got only a couple dozen editors responding, if that. Discussions for adminship, for example, get five times as many editors commenting. Make no mistake, this is essentially a site-wide change: "Cite web" is being used more and more throughout Wikipedia since even editors adding magazine or newspaper citations often figure, "Well, it's on the web." That means the de faco Wikipedia house style italicizes company and institution names, which no mainstream footnoting format does. Without a corresponding "cite organization" template that does not automatically italicize company and institution names, italicizing websites in CS1/2 is essentially mandating an eccentric house style. That means a cite from the National Oceanic and Atmospheric Administration comes out as National Oceanic and Atmospheric Administration — misleadingly making it seem like a magazine such as National Geographic. I think something this big requires more input than the small number of editors at this relatively obscure technical page.--Tenebrae (talk) 16:06, 7 October 2019 (UTC)
    Exactly. The New York Times (www.nytimes.com) is an online news outlet and should be italicized. Google Docs (docs.google.com) is a web app and should not be italicized (apps are not italicized, as opposed to games). It follows that {{cite web}} must use manual italicization. I don't think it's such a big problem. The rules for applying italics can be put in the description of the website parameter. — UnladenSwallow (talk) 21:20, 7 October 2019 (UTC)
    IMHO, Google Docs must never appear in |website=. It belongs to |via=. Such is the case for GitHub: The repo name goees into |work=. flowing dreams (talk page) 11:55, 9 October 2019 (UTC)
Generally, yes. However, the web app name will be listed in |website= for pages like "About", "Help", "Subscription plans", etc. — UnladenSwallow (talk) 18:32, 9 October 2019 (UTC)
Oh, I see. In that case, your reference to Google Docs would be analogous to referring to an appliance's manual as opposed to referring to the appliance itself. In this case, the page to which you are linking is not an app, so, per your own criterion, definitely italize it.
But as I said, italicization has semantic meaning. This is important because |work=, |publisher= and lots of other parameters are optional. There is no telling if the citation has them. The italicization is your only clue. flowing dreams (talk page) 07:10, 10 October 2019 (UTC)
the page to which you are linking is not an app, so, per your own criterion, definitely italize it I never said app/not-an-app was my criterion. I simply offered two examples: an online news outlet (which are always italicized) and a non-game web app (which are never italicized). There are many other types of websites which may or may not be italicized. But that doesn't matter. What matters is that there are two types of websites that disagree on italicization. Therefore, we can't apply italicization automatically and must leave the decision to the template user.
You argue that Google Docs would never (or almost never) appear in |website=, so it's a bad example. Fine, let's take another example: Federal Reserve Economic Data (fred.stlouisfed.org). Certainly you would agree that it goes into |website= (and Federal Reserve Bank of St. Louis goes into |publisher=). And yet, it is always cited as FRED (no italics). There are many more examples like that. — UnladenSwallow (talk) 00:36, 11 October 2019 (UTC)
Humph. This is getting more and more complicated without any benefit. Nah. I'd say italicize all works, be it book, film, play, or app. flowing dreams (talk page) 06:54, 11 October 2019 (UTC)
This is not getting more and more complicated. I've provided you with two examples of websites: one that is italicized and one that is not. You've discarded the second example on the basis that it should always go into |publisher=, so I've replaced it with another example of a website that is not italicized.
So now we have The New York Times (www.nytimes.com) that is italicized and FRED (fred.stlouisfed.org) that is not italicized. This means that the decision on italicization should be left to the template user.
Nah. I'd say italicize all works… Wikipedia follows the existing norms as much as possible. If we wanted to keep things simple, we wouldn't have non-breaking spaces, en dashes, em dashes, etc. — UnladenSwallow (talk) 17:13, 11 October 2019 (UTC)
I said "complicated and without benefits". And you're not here to follow the existing norm; you're here to change existing norm on millions of articles. If Wikipedia wanted to follow existing norms, CS1 would have never been invented. By the way, you keep saing "FRED is not italicized". Not italicized by who? flowing dreams (talk page) 08:02, 12 October 2019 (UTC)
No, you didn't say "complicated and without benefits". You said This is getting more and more complicated without any benefit, which implies that "this" is: (1) getting more and more complicated; (2) does so without any benefit. I have addressed part (1), demonstrating to you that nothing is "getting more complicated"; in fact, the level of complexity is staying exactly the same as it was in my original comment: there are websites that are italicized and there are websites that are not italicized. you're not here to follow the existing norm I will decide for myself why I'm here, thank you. you keep saing "FRED is not italicized". Not italicized by who? Obviously, I'm referring to existing practice. As I've told you several comments back: "And yet, it is always cited as FRED (no italics)." Are you being intentionally obtuse? If you think I'm wrong, please demonstrate a variety of newspapers/magazines where FRED is cited as FRED (italicized). Except you can't. Because I've checked it thoroughly before posting my comment. You can continue to muddy the waters, or you can face the reality that in existing newspapers/magazines some types of websites are italicized (newspapers, journals, magazines, blogs, webcomics, etc.) and other types of websites are not (TV channels, radio stations, databases, company websites, etc.). See MOS:ITALICTITLE. — UnladenSwallow (talk) 05:53, 14 October 2019 (UTC)
Whoa! Whoa! Whoa! "Obtuse" is a personal attack. And "existing practices" is still a weasel word. FYI, not only I can face the reality, I can stare in said reality's eyes and tell it: "Hey, existing reality! I reject you, because you cannot justify your existence!" I've already done so to gender discrimination. If necessary, I'll do it to unhelpful italicization of components. flowing dreams (talk page) 07:37, 14 October 2019 (UTC)
  • Steven Crossin, please offer an alternative title to this discussion so that it more accurately reflects citation practice. Citations do not italicize anything. They usually emphasize the most pertinent element, traditionally - though not exclusively - by using slanted type. Both the original RFC and this discussion keep applying the misnomer of "italics" which is solely a typographical convention and does not reflect the underlying semantic meaning. 24.105.132.254 (talk) 22:29, 7 October 2019 (UTC)
    "website=" in "cite web" automatically italicizes and does not allow manual override such as wiki markup. --Tenebrae (talk) 21:24, 8 October 2019 (UTC)
  • Rerun the RfC and notify more widely. Template styles should follow the Wikipedia:Manual of Style/Titles which has a defined position on use of italics for websites (essentially being: it depends). If an overall change of style is being considered then it should be considered in that forum rather than for a specific template that users would naturally expect to follow the conventions defined in the Manual of Style. 203.10.55.11 (talk) 02:34, 11 October 2019 (UTC)
  • Rerun the RfC. You can't just overturn Wikipedia:Manual of Style/Titles without even advertising the RfC there. Kaldari (talk) 23:22, 11 October 2019 (UTC)
    • The RfC didn't "overturn" anything. The wording on this particular thing at MOS:TITLES has just been confused and unclear for a long time (until MOS:ITALICTITLE); to the extent that the depending-upon-publication-type stuff could be interpreted as applying to citations (rather than use in running prose), it would not actually reflect WP practice, which has been to italicize these work names in citations, automatically, for 10+ years now.  — AReaderOutThatawayt/c 22:36, 20 October 2019 (UTC)
  • Preferably rerun the RFC; at the very most, current consensus only allows for italics in cs 1/2 templates. Notwithstanding Steven Crossin's (understandable) request that the focus here be kept on-point, the fact remains that many editors are strongly opposed to italicising each and every website title, and/or that publisher= cannot be used instead to avoid italicising organisations in cite web. It seems to me it's a case of template managers/editors seeking to squeeze different scenarios into one tidy category – whether that's through obsessiveness or a touch of control-freakery I don't know. But, as was raised in the RfC, and has been added to or alluded to here by the likes of David Eppstein, Levivich and SarahSV, it's not a case of one-size-fits-all. I'm a professional book editor, and have been for far too many years, and the idea that an organisation has to be treated as a "work" in the interest of defining a component of the citation is, well, utterly ridiculous. AllMusic, Official Charts Company, Metacritic, Supreme Court of the United States, World Health Organization, BBC News, etc, are never italicised in regular text and need not be in a citation. (No reader's going to go: "Aaargh, you've lost me ... how do the words 'BBC News' relate to the rest of the information in that source?")
To return to the question raised here: CS1/2 currently prohibits adhering to a pretty fundamental point in British English style, which is that abbreviations such as eds, nos and vols don't require a full stop/period. In the past – I think it was with regard to the "eds" issue, if not the option to use "edn" for "edition" (which, I'd say, is also preferred in Brit English) – the response here was that editors are "welcome" to write the entire citation manually and so avoid having to conform to what they consider to be a contentious CS1/2 requirement. In the same spirit, and given the scope of the RfC anyway, editors should not be required to apply italicisation outside of CS1/2 and should be able to write the cite manually or find another way that presents the information correctly. JG66 (talk) 02:42, 17 October 2019 (UTC)
  • Italicize in citations (and there is no difference in this regard between CS1 and CS2, or manually-laid-out citations). Whether to italicize in running text or not depends on whether the site is primarily like a published work (e.g. Salon or IMDb) or primarily something else (just advertising/support material like Microsoft.com, or a forum/social-networking service like Facebook). The "Rerun the RfC" stuff is patent WP:FORUMSHOPPING, an "I didn't get the result I wanted" complaint. The original RfC was widely enough advertised and ran long enough to assess consensus, and given that italicizing these in citations is already enforced by the templates and has been that way for over a decade, the "don't italicize" stuff is not a question about what consensus is, but an attempt to overturn already well-established consensus.  — AReaderOutThatawayt/c 22:23, 20 October 2019 (UTC)

Follow up discussionEdit

  • Comment Do you think there is any mileage in scrapping the "Cite web" template altogether, and creating a "Cite organization" in its place that does not italicise? The citation style is drawn from real-world application (i.e. the website name for a newspaper would be italicised, but for an organization it would not be) so Cite web seems to be encouraging standardisation where it does not exist. If you had to choose between Cite news, Cite book, Cite journal, Cite organization etc then the stylisation issue would take care itself. This would seem to be a fairly straightforward solution so what am I missing? Betty Logan (talk) 18:18, 10 October 2019 (UTC)
I think you may be confusing prose style with citation style. Because both are styles does not mean they have the same functionality. Citations style their content towards verifiability. One way this is accomplished is by emphasizing the source, in this case, the website, so that the reader knows immediately where to start looking. It has nothing to do with application of a prose style, neither does it have to follow the referring document's style whether that is MOS or anything else. And don't overlook the fact that use of these templates (actually, the module they are based upon) is entirely voluntary. Any citation/citation style will do, as long as is consistent within the document. 65.88.88.69 (talk) 21:03, 10 October 2019 (UTC)
I am not confusing prose and citation style. I have never italicised a company/corporation name in a citation in my professional work either. For example, if you are citing something on the BBC's website you do not italicise the "BBC" in the citation. The BBC's website is not a publication called the "BBC", it is a publication by the BBC. This is generally the norm for websites. I can think of several counter-examples: if you were citing something in the AFI Catalog you would italicise the "AFI Catalog" in the citation because it is a publication by the American Film Institute. In this capacity it functions as an online encylopedia/ebook and could be cited using an appropriate template. In the case of citing something on the AFI's general website it would be beneficial to have a "corporation" template that does not italicise the company name. The "cite web" template is promoting a standardisation where one does not really exist. Betty Logan (talk) 00:56, 11 October 2019 (UTC)
The template has a |publisher= field. That is where the publishing entity (in most cases the domain owner/registrant) should be inserted. The BBC publishes bbc.com. The latter would be the source. Sources (works) should stand out, one of the reasons being that they may include a lot of other stuff, most of it mysterious to the average Wikipedia reader. The emphasis applied on the source field through italics has nothing to do with whether the source is a website or anything else. 72.43.99.138 (talk) 14:05, 11 October 2019 (UTC)
Respectfully, there has just been an RFC that was in favor of italicizing. In that light of that RFC, this suggestion lacks pertinence. Clearly, the community sees value in distinguishing the name of the work from the name of the subwork and the publisher. If I may add, re-running the RFC reminds me of some of questionable political actions I hear about these days: The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again. flowing dreams (talk page) 11:45, 12 October 2019 (UTC)
RFCs are WP:NOTAVOTE, they are a tool for determining community opinion. Consensus on Wikipedia has never locked in a vote, chiefly because as the participants in a debate change so can opinion. Betty Logan (talk) 09:17, 14 October 2019 (UTC)
That's not what I see. RFCs are based on majority votes. In Wikipedia, minority valid concerns are ignored. In consensus-based decision making, all valid concerns are addressed. flowing dreams (talk page) 09:27, 14 October 2019 (UTC)
See WP:WHATISCONSENSUS#Not a majority vote, WP:NOTDEMOCRACY and Wikipedia:Consensus#Consensus can change (the latter two are both policies). Betty Logan (talk) 09:36, 14 October 2019 (UTC)
And here is my contribution to the consensus-building process: No! Your suggestion is egregious and without benefits, both in its own rights and in the fact that discrimination in italicization is egregious and without benefits. First, because you are operating under the wrong impression that the only websites besides news websites are organizations' websites. Not so. Second, you don't seem to have a functional reason for not italicizing certain websites. In fact, no one here seems to have. Any "reason" I see here is very arbitrary. flowing dreams (talk page) 10:13, 14 October 2019 (UTC)
Betty Logan is absolutely correct in that RfCs are not decided on by number of votes. That's not her "suggestion" but Wikipedia policy. You are completely wrong, per policy, in saying, "In Wikipedia, minority valid concerns are ignored."
As for your other points, you seem to be ignoring multiple editors in both this discussion and the closed RfC saying flat out that the names of organizations (companies, institutions) are not italicized in any mainstream footnoting style — for the very good reason of not conflating them with magazines and other periodicals. The National Oceanic and Atmospheric Administration is not National Oceanic and Atmospheric Administration, as if it were National Geographic. Having Wikipedia adopt a fringe, eccentric footnoting style makes us look like an outlier and does nothing to enhance our credibility. --Tenebrae (talk) 16:01, 15 October 2019 (UTC)
My dear esteemed colleague Tenebrae, you are being awfully forceful here. And I fear we have digressed from the discussion of a proposal for "Cite organization". I do accept that it is partly my fault. (Actually, I have nothing else to add to it, so I can bow out.) I'd be glad to have you and dear Betty in my personal talk page to talk about merits of italicizing in citations or about the de jour and de facto status of Wikipedia's consensus policy. But this thread is already a hot zone. Let's keep other hot topic out of it. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)
And incidentally, I find it odious that you compare this valid, by-the-book discussion as somehow illegitimate in the same way Trumpers try to deny the constitutionality of the impeachment process or recounts. ("The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again.") That Trumpian position holds no water in either the political world or in a Wikipedia discussion. --Tenebrae (talk) 16:05, 15 October 2019 (UTC)
You seem to be commenting about one of those nations/states who have voided their election when it did not go according to the plan. (I'd probably look up Trumpian later.) In the meantime, we can focus on the fact that I don't see why Steven Crossin suddenly decided to void the RFC, without drawing any anologies to real-world politic situations. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)

Citing online databasesEdit

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

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

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

Another option would be:

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

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

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

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

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

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

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

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

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

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

[following bibliography entry has hanging indent in original]

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

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

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

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

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

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

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

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

There's Minor Planet Center (https://minorplanetcenter.net), through which all the information about minor planets and comets flows, but it doesn't maintain explicit lists of who discovered what. There's a List Of Observatory Codes, but you can't click on an observatory to see all objects discovered there. So the astronomers use JPL's Small-Body Database Browser for this (among other reasons). It's used quite extensively on Wikipedia, hence my interest in finding/devising a proper way to format its citations. — UnladenSwallow (talk) 02:40, 7 October 2019 (UTC)
UnladenSwallow, we have a lot of specialized reference templates that cite databases. See {{Ethnologue22}} and {{SIMBAD link}}. Follow what they do. In the template code. They set up the url to include the search parameters. So you can write:
  • {{cite web |title=Borosov |url=https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=Borisov |work=JPL Solar System Dynamics |publisher=Jet Propulsion Laboratory |accessdate=6 October 2019}}
    • "Borosov". JPL Solar System Dynamics. Jet Propulsion Laboratory. Retrieved 6 October 2019.
  • {{cite web |title=11016 Borisov (1982 SG12) |url=https://ssd.jpl.nasa.gov/sbdb.cgi?ID=a0011016 |work=JPL Solar System Dynamics |publisher=Jet Propulsion Laboratory |accessdate=6 October 2019}}
StarryGrandma (talk) 02:50, 7 October 2019 (UTC)
1. Can't use your first example as the Template:Cite web documentation says that the title parameter must contain the page title, not the search string. 2. Following the example of Ethnologue, the citation could look like this:
"Borisov" at JPL Small-Body Database
Or, perhaps:
Search: "Borisov" at JPL Small-Body Database
— UnladenSwallow (talk) 03:14, 7 October 2019 (UTC)
Including |title=JPL Small-Body Database Browser as the title is also unsatisfactory as the page content changes according to the search parameters. What is the point of emitting the correct metadata for |title= when referring to a page with uncertain content. It only makes sense to refer to the naked search page, i.e. without a search. |title= needs to be accompanied by something else if it is to be useful or have an alternative parameter that can be linked without emitting metadata.   Jts1882 | talk  06:06, 7 October 2019 (UTC)
|title= needs to be accompanied by something else if it is to be useful… Hence my query parameter proposal above. The metadata output can be modified accordingly to make sense. — UnladenSwallow (talk) 08:39, 7 October 2019 (UTC)
I note that the examples in the OP don't include an acecss date, which they surely should. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:32, 10 October 2019 (UTC)
Thanks, Andy. I have omitted |access-date= in this post for brevity. I always include it in citations I add to articles. — UnladenSwallow (talk) 00:54, 11 October 2019 (UTC)
It's also worth noting that "JPL Solar System Dynamics" isn't a magazine, newspaper or journal. It's an organization, and in any mainstream footnoting style, such as Chicago Manual of Style, ALA or MLA, it's not italicized. In any mainstream form, it would go under "publisher=". --Tenebrae (talk) 21:52, 15 October 2019 (UTC)

For the enterprising gnomeEdit

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)

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)
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)

Two separate publication dates in a single citationEdit

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

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

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

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

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

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

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

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

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

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


References

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

end pipe not displayingEdit

In

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

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

"Extra punctuation" maint message that I can't figure outEdit

I found this cite web template in George Washington:

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

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

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

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

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

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

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

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

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

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

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

Format for author name suffixes?Edit

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

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

Language description needed for elements of citeEdit

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

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

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

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

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

Note that this is separate from the usage in something like

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

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

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

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

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

This doesn't answer all of your questions, but according to MOS:ROMANIZATION we should transliterate author and publisher names into the Roman alphabet, not keep them in Greek. —David Eppstein (talk) 03:28, 21 October 2019 (UTC)
Return to "Citation Style 1" page.