Help talk:Citation Style 1

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

Italics of websites in citations and references – request for comment

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

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

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

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

The following pages have been notified

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

Responses

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  (edit conflict)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discussion and alternatives

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Closing

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

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

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

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

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

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

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

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

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

---

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

RfC on linking title to PMC

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.

---

Currently if |url= is not specified, then the title of an article generated by a CS1 template is linked to the |pmc= link. Should we continue to include this link or should we remove it? Boghog (talk) 05:51, 25 May 2019 (UTC)

Include link

• The link is very useful because not everybody knows how to navigate the publication IDs or what the green link means. It's also easy to override whenever the PMC link is not the preferred final destination. In 99,9 % of cases, the PMC link is the best possible because it's official, open access and technically high quality (fast, no bloatware, no cookies or JavaScript required etc. etc.). Nemo 10:24, 27 May 2019 (UTC)
  • The link is very useful because not everybody knows how to navigate the publication IDs Delicious baloney (I actually detest baloney). My expectation, and what I think the more reasonable one is, is that if the user has URLs in the citation, he'll follow each of them (either in turn or separately) until he can access a free source. (And if there is no free source, then he will rarely access any of them as requiring extraordinary effort for anyone but the most-serious researcher.) PMC link is the best possible because it's official, open access and technically high quality None of which we care about for the purposes of a rendered citation. (Well, perhaps open-access, but that's not sufficient to duplicate a link from one place to another.) what the green link means The average reader has a browser which can display the title of the link, which is set to 'free access', when the green is present. He'll figure it out eventually. --Izno (talk) 13:57, 27 May 2019 (UTC)
    • I believe you can find many examples on wiki of me saying that I believe our readers are smarter than that... but this isn't one of them. Normal people really have no idea what those things are and don't click on them. Try it out some time. Show a Wikipedia article to your neighbors and ask them what they think all those numbers at the end are there for. Don't be surprised if the answer is something that amounts to "Nuttin' that's got anything to do with me".
      Nemo, I understand that the PMC articles are usually "author accepted article versions" (i.e., the thing that they're going to publish), but not technically the "official" version (which has the journal's official formatting style, etc.). WhatamIdoing (talk) 22:53, 27 May 2019 (UTC)
      • Without wishing to appear quarrelsome, the average reader doesn't have a browser that displays the title. The majority of pageviews now come from mobile devices, so the most probable reader has no mouse to hover over a link. --RexxS (talk) 02:53, 28 May 2019 (UTC)
• Keep What is wrong with making it easy to open a fully readable version? Doc James (talk · contribs · email) 00:23, 28 May 2019 (UTC)
• Keep link from title I believe most readers are most likely to follow a link from the article title. It's what they are used to doing on Wikipedia, and my contention is that the link from the title should be the best link we can offer the reader. If it's the same link as the PMC, then redundancy is fine: either one will do. But only today I came across a PMC that had an updated/amended later version available as free access on the journal site, and that should be the resource linked to from the title, because it's slightly better than the PMC. Either version would serve to verify the article content, but we should offer the reader the best source we can, and that's not always the PMC. I see no good reason to have the title unlinked when |url is unspecified; if the PMC is available then it is the best we have to offer and should be linked from the title as well. --RexxS (talk) 02:53, 28 May 2019 (UTC)
• Keep link from title and use the same logic for all other identifiers with free full text, such as |arXiv= or |doi= with |doi-access=free. In this way, the discrepancy between PMC and the other identifiers is resolved. As a reader, clicking on the title is more natural than having to click on an id. − Pintoch (talk) 09:42, 28 May 2019 (UTC)
• Keep and consider expanding to other parameters if they identify free-to-read urls. Changing this would be a major breaking change for articles that have been for years written without a url= link to the PMC. Readers expect article titles to be URLs if they can read them. Hieroglyphics at the end of the citation are impenetrable to normal folk. The proposal offers no benefits to the reader at all. It makes it less likely they will know they can read the source and less likely that they will read the source. See below for my comment on "duplication". -- Colin°^Talk 13:37, 29 May 2019 (UTC)
• Keep and expand functionality to other free versions of records (e.g. when |doi-access=free/|bibcode-access=free etc.). This is a huge accessibility boost to readers. Headbomb {t · c · p · b} 23:38, 1 June 2019 (UTC)
• Keep. I'll say I'm probably less intelligent than the average wikipedia reader. Here is how things work for me: I see link. I click first link. Link leads to paywall. Get sad. Go back. Click next link. Dead end. Give up. Watch YouTube. Don't learn knowledge.
  Stop making me have to guess which link works please. Just put that one first by default. It's currently almost never clear for lowly people like me. Please fix. (In case people wonder if I am joking because I am more well prosed, I'm really not. Some days I used to find reading Wikipedia very frustrating if I wanted to dig through the refs for more info. What isn't a deadlink always felt like a paywall. It felt like knowledge was being robbed from me). –MJL ‐Talk‐^☖ 05:59, 20 June 2019 (UTC)

  In case it wasn't clear, I hated digging to figure which links worked and which didn't. Of course I would give up after a while. I'll be honest and say I really miss those little locks that used to be there, I think. –MJL ‐Talk‐^☖ 06:09, 20 June 2019 (UTC)

  @MJL: PMC links are suffixed by the open padlock indicating open access anyway. Is that not enough? Keeping this feature doesn't guarantee the link will lead to a desirable version; oftentimes there are better (i.e. peer-reviewed) versions available for free. Nardog (talk) 08:25, 20 June 2019 (UTC)

  @Nardog: The padlock doesn't display on mobile devices, I thought? Also, if there are better versions available for free, why aren't they already linked to using the |url= parameter? –MJL ‐Talk‐^☖ 13:47, 20 June 2019 (UTC)

  The padlock doesn't display on mobile devices Do you have evidence to back that up? Here is a contrived {{cite journal}} template:

  {{cite journal |title=Title |url=//example.com |url-access=subscription |pmc=12345}}

  "Title". PMC 12345. {{cite journal}}: Cite journal requires |journal= (help)

  Here is the link to mobile view of this discussion: https://en.m.wikipedia.org/wiki/Help_talk:Citation_Style_1#Include_link

  We do know that MediaWiki css for Modern skin is flawed (see Help talk:Citation Style 1 § icons and the modern skin)

  —Trappist the monk (talk) 14:12, 20 June 2019 (UTC)

• Keep and expand functionality to other identifiers. Per User talk:Citation bot § "Removed URL that duplicated unique identifier", I've sat with readers who did not know to click through when the citation title was unlinked but identifiers were provided. Most people I know have no idea what "PMC", "ISSN", and sometimes even "JSTOR" means within a citation, and they'd only click through when feeling particularly adventurous. I'm glad the identifiers are there for those who desire them, but using the identifiers to link the citation title when no |url= is explicitly provided is to meet our general audience where they are. (not watching, please {{ping}}) czar 22:21, 4 August 2019 (UTC)

Remove link

• Remove as redundant to the |pmc= link. The pmc link is now followed by a "green/open padlock icon" which makes it clear that the source is free to read. Redundantly linking titles to pmc links creates a counter productive sea of blue in reference sections. Boghog (talk) 05:51, 25 May 2019 (UTC)
• Support removal – redundant; no more reason to link to |pmc= than, say, |jstor=; confusing. Peter coxhead (talk) 06:07, 25 May 2019 (UTC)
• Remove as redundant. Imzadi 1979 → 06:10, 25 May 2019 (UTC)
  • Making the PMC parameter not link will not reduce redundancy, but increase it. People will start adding links to the url parameter so that users can more easily find the link, especially as it's recommended to link a full text. Nemo 10:31, 27 May 2019 (UTC)
    • That's an assumption of user behavior without any evidence yet whatsoever. I'd expect that such people will use the URL field regardless of whether the PMC field is filled. (On the note of duplicate links, I would presume that Citoid adds the majority or entirety of duplicate links for identifiers, not the average editor.) --Izno (talk) 13:53, 27 May 2019 (UTC)
• Regardless of the merits of icons etc., this is inconsistent behavior. Identifiers should be placed in the identifiers section, and the links thereto should be relegated to that section. If someone is intent on reading some paper of interest, they're going to click every URL they can to see which will provide the easiest access; the suggested subtle cue that the URL is free if the title is linked seems like a false starting position (it's often or perhaps usually-to-mostly not--see our widespread linking to Google Books). Remove the extraneous link. --Izno (talk) 13:00, 25 May 2019 (UTC)
  • The policy is that the url parameter should normally contain freely accessible URLs. It's trivial to remove the URLs which don't comply with this. Nemo 10:31, 27 May 2019 (UTC)
    • No, it's assumed that when the URL does it holds something freely accessible. It does not require the duplication of a link from elsewhere in the citation. Certainly, I would be careful about tossing the word "policy" around when there is nothing of the sort whatsoever that is "policy". --Izno (talk) 13:49, 27 May 2019 (UTC)
      • The convention is that the link from the title is the "best" link we have to offer, because it's the most obvious to be followed. It is quite likely to be free access, as that's the principal factor in judging what's "best". It may or may not be a duplicate of another link in the citation, but omitting it on grounds of "redundancy" does a disservice to the reader: "redundant" =/= "not useful". --RexxS (talk) 03:08, 28 May 2019 (UTC)
• Remove as above. Masum Reza^📞 10:26, 27 May 2019 (UTC)
• Remove the alternative linking of the title to the pmc url. Despite the unssupported statements of Nemo and Doc James, I do not see that any case has been presented for retaining this alternative linking. And I find the statement that "not everybody knows how to navigate the publication IDs" a bit ludicrous. ♦ J. Johnson (JJ) (talk) 00:52, 28 May 2019 (UTC)
  • I've presented a case that the link from the title should be the "best" link we can offer the average reader. If readers know they can click on the title, certain that none of the other links will be better, we can eliminate the need for the average reader to have to work out which of the other coded links is best to follow. Do you want to reconsider? --RexxS (talk) 03:08, 28 May 2019 (UTC)

    No. I think your argument (above) that the title should link to the best source has some merit. But: 1) Per other editors (such as WhatamIdoing [above] and Boghog [immediately following]) I don't see that PMC is always best. 2) "Best" should be a matter for the involved editor to determine and set; I don't accept that PMC as default should be built into the software. ♦ J. Johnson (JJ) (talk) 23:19, 28 May 2019 (UTC)

    • The assumption is that the PMC is the best available link is not always true. Sometimes only the pre-publication version is stored on PMC and the original publisher has posted the final open access version that is easier to read. The automatic title link to PMC can be oven ridden by |url= but this requires the editor to insert this link which is not always done. To make matters worse, citoid often inserts |url= completely oblivious to whether it is free or not. An open/green padlock always follows the specific PMC link, so it should be obvious to the average reader that the PMC link is free. Boghog (talk) 03:44, 28 May 2019 (UTC)
      • But the assumption that the PMC link is the best is true most of the time, and that makes it a good default value for the title link – at the very least, it's guaranteed to be free. In the minority of cases when it isn't the best link, that's when we use the |url parameter to override it. Just because that's not always done doesn't stop it being the best solution. The behaviour of citoid in inserting spurious urls shouldn't be a factor deciding whether to link the title from PMC or leave it blank, as citoid's choice for |url would produce the same result in either case. --RexxS (talk) 04:43, 28 May 2019 (UTC)
        • Why is it necessary to include a redundant link in the title? Because readers can't see the open/green padlock? I think you are underestimating the average reader. Boghog (talk) 08:38, 28 May 2019 (UTC)
          • Why is it necessary to remove a useful link from the title? Readers know that if they click the link from the title, they'll most likely get the best version of the source we can deliver to them. That's how it's been for a long time, and I think you're underestimating the power of habit. If there's an open/green padlock then there's a free version, and the link from the title will be at least as good as that. No need to check multiple links until they get the best one; we serve it up on a plate (the title) for them. --RexxS (talk) 17:24, 28 May 2019 (UTC)
            • You keep using the word "best". That's not what this link represents. It is the "most-open", at best. The link to the DOI or whatnot is the "most authoritative" and could just as trivially be the preferred link. (Best is value-laden and we don't need that to be value-laden here.) In this case, it may not be the best because there may be a both free-as-in-libre and free-as-in-beer identifier which also happens to be one of the other identifiers. (Rare, but possible.) That would clearly be "the best". --Izno (talk) 17:55, 28 May 2019 (UTC)
              • I do keep using the word "best", because it's the appropriate word, and it's exactly what the link from the title represents. When multiple links occur, we are perfectly capable of picking one that is most likely to be the one an average reader will benefit most from following, and the title link is available for that purpose. Free access, full text, updated, and so on are all factors and we can order them as we see fit (usually that order). The fact that PMC will usually tick the first two boxes makes it the most likely candidate for "best link", and that's why it's copied into the title link in the absence of a link to override it (the |url=). If you don't like the word "best", just mentally substitute "most beneficial for the reader". The reasoning remains unchanged and unchallenged. There is never any good reason not to present the reader with a link from the title, unless the source simply doesn't exist online. --RexxS (talk) 19:21, 28 May 2019 (UTC)
• Remove the automatic linking as it is redundant and misleading. As discussed above, the auto-linking leads to falsely suggesting that the PMC version is the authoritative one when a reviewed and published version is available, whether behind a paywall or not. When the published version is not freely available anywhere, yet the article is referencing the published version, the title link is utterly inappropriate. When the DOI provides free access to the published version, one can override the PMC link by putting the URL the DOI redirects to in |url=, but that again is redundant and leads to WP:SEAOFBLUE, when |doi-access=free will do.

  It is inconsistent that PMC is being singled out as the only source that automatically links the title in the absence of |url=. But if we expanded this feature, determining the priority of sources would be a nightmare. The editor who inserts the template should be able to decide which part of the citation is linked where. Nardog (talk) 10:07, 28 May 2019 (UTC)

  Well said. Peter coxhead (talk) 15:26, 28 May 2019 (UTC)

• Remove links. We should only link versions that are either authoritative, or explicitly chosen by editors as the choice to link via the |url= parameter. The people commenting that "pubmed is obviously the best link" presumably work in a field covered by pubmed; for many other fields, pubmed coverage is sporadic, random, and unhelpful. In astronomy, maybe ads/abs (bibcode) is the best link; maybe in mathematics it is mathscinet (mr). I don't think we should be in the business of picking and choosing when there are multiple ids like this to link to. I would not be strongly opposed to doi links, because they are almost always authoritative, but even for those I prefer the current system of linking them only through the id. —David Eppstein (talk) 20:02, 28 May 2019 (UTC)
• Remove the redundant link. It doesn't always work (as in the original issue that led to this discussion), and fixing that would only make things more complicated. Generalizing the repeated linking to other identifiers would be yet more complexity for readers and editors, in a template already criticized as over-complicated. Kanguole 14:32, 7 June 2019 (UTC)

Discussion

See also #Stop linking paper title to PMC

The proposal is poorly stated. When |url= is non-empty it is used to link the title. The proposal appears to be: don't use |pmc= for that purpose when |url= is empty. I don't see that any "link" (or link parameter?) is being removed. It's more like a link using pmc is not created in the first place. But this is not quite certain. ♦ J. Johnson (JJ) (talk) 22:09, 25 May 2019 (UTC)

Taking an example given above by Nardog of a citation using |pmc= but not |url=:

• {{cite journal |last=Bannen |first=RM |display-authors=etal |date=2008 |title=Optimal design of thermally stable proteins |journal=Bioinformatics |volume=24 |issue=20 |pages=2339–2343 |doi=10.1093/bioinformatics/btn450 |pmc=2562006}}

currently displays as

• Bannen, RM; et al. (2008). "Optimal design of thermally stable proteins". Bioinformatics. 24 (20): 2339–2343. doi:10.1093/bioinformatics/btn450. PMC 2562006.

The proposal is that the article title should not be linked in this situation (but the doi and PMC identifiers should still be), so in comparison with the current implementation, one copy of the link would be removed from the generated HTML. Kanguole 22:35, 25 May 2019 (UTC)

(edit conflict) A title link to |pmc= is created if |url= is empty. The removal proposal is not to link the title to |pmc=. Boghog (talk) 22:51, 25 May 2019 (UTC)

So what you are proposing is: to remove the functionality of using the pmc link as an alternate title link. (Essentially: not creating a 'title->pmc' link in the first place.) Right? ♦ J. Johnson (JJ) (talk) 18:07, 26 May 2019 (UTC)

Correct. Boghog (talk) 19:26, 26 May 2019 (UTC)

I think the concern about duplicate is misplaced. In the case where a URL is supplied and to the official journal article, then the DOI link takes one to the same place. So in fact the title link is nearly always duplicating another link. Both the DOI and PMC ID are, textually, part of a full citation text, so we wouldn't eliminate them. I think the convention of having the title link to freely available editions of the article is a fine one to retain. -- Colin°^Talk 13:47, 29 May 2019 (UTC)

But many editors wouldn't supply a URL that is pointed to by the DOI. Useful URLs are alternatives to a DOI link, e.g. to a copy on the authors' website or in ResearchGate. Peter coxhead (talk) 16:13, 29 May 2019 (UTC)

The frustrating thing about this feature is that there's no way to opt it out. Even if the outcome of this turns out to be "keep", surely an option to turn it off wouldn't be controversial, or would it? Nardog (talk) 16:20, 29 May 2019 (UTC)

There's already an option to turn it off: users who don't like PMC links can effectively disable them with some custom CSS. Nemo 13:49, 23 June 2019 (UTC)

That's not a solution. I'm talking about an option to turn it off from the editor's perspective, not the reader's. Nardog (talk) 13:54, 23 June 2019 (UTC)

You could have |auto-url=none and that would be a pretty simple option to bypass things in the minority cases it doesn't make sense to have the automatic url. Headbomb {t · c · p · b} 23:25, 23 June 2019 (UTC)

Or just |url=none. Nardog (talk) 06:22, 24 June 2019 (UTC)

I would not want to have a feature where pmc gets used for the title link in the absence of |url= by default. If ever, I would like to have this feature enabled only on demand (not by default), and to also have a feature to select the identifier used for this purpose from the list of available ones. This could be easily done if the |url= parameter would support the number of supported identifiers as selectors: |url=pmc, |url=doi, etc. The advantage of having to explicitly activate this feature would also help arguments brought forward above that this should not be forced onto our users by default and that defaulting to pmc would be arbitrary.

--Matthiaspaul (talk) 23:13, 4 August 2019 (UTC)

This would also address the problem where to point to |access-date=, |archive-url= and |archive-date= parameters when an |url= parameter gets deleted because it has been found to be redundant with one of the more specific identifier links like |doi=. Some editors just remove these parameters, which in my opinion is a very bad idea and not very far-sighted, because even "permanent links" like a doi are not garanteed to be working forever, and by removing archived links and access dates we loose parts of our quality assurance ("the link was checked to be functional and supporting the statement on date xyz") and backup system against link-rot. With something like f.e. |url=doi, |access-date=, |archive-url= and |archive-date= could stay and would refer to the doi as well.

--Matthiaspaul (talk) 10:21, 5 August 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.

Support citewatch=... or something like it

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

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

And, upon the next bot run a table like this

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

could be updated to something like

Rank	Target/Group	Entries (Citations, Articles)	Total Citations	Distinct Articles	⁠Citations/article⁠
106	Journal of Physical Therapy Science [Beall's journal list]	Journal of Physical Therapy Science (7 ? and 8 ✓ in 11)	15	11	1.364
601	Pharmacologia [Beall's journal list]	Pharmacologia (1 ✓ in 1)	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. {{cite journal}}: Unknown parameter |cw-check= ignored (help)). Likewise, WP:CITEWATCH does not take a position on weather or not a source is appropriate to cite, it just raises a flag that it's probably a good idea to double check. Headbomb {t · c · p · b} 20:55, 20 July 2019 (UTC)

My suggestion would be to have a param to signify whether the citation is being used as a primary source. That way, editors reviewing known unreliable sources can quickly parse how the citation is being used. Such a use case wouldn't be limited to citewatch. czar 20:50, 20 July 2019 (UTC)

I agree with Czar that it's better to focus on the specific content and how it's used. For instance, most people will look at whether the authors are authoritative, whether the paper builds on academic literature, any sign of substantive peer review having been performed, signs of (un)sound methodology. Some call it being "refereeable" https://arxiv.org/help/moderation or "scholarly". For us it would be "citable", to account for things like primary references, but that might prove confusing. Nemo 07:21, 25 July 2019 (UTC)

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

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

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

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

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

Again, you misunderstand the purpose. Absolutely nothing would be displayed in articles. There would be no Scarlett letters. Headbomb {t · c · p · b} 14:46, 30 July 2019 (UTC)

It is designed to facilitate a global approach to reliability, and it would put markers in wikitext, right? Kanguole 14:50, 30 July 2019 (UTC)

"A global approach to reliability" I don't know what that even means. See the Signpost article for what the citewatch is: a tool that identifies potentially problematic citations. |cw-check=ok would let us flag false positives, so that people who use the citewatch don't waste time reviewing the same potentially problematic sources over and over. The alternative is something ugly and error-prone like |journal=MIT Review<!--Citewatch: This is not the hijacked journal, and is OK--> Headbomb {t · c · p · b} 14:58, 30 July 2019 (UTC)

I think a parameter used in the individual citations is the opposite of a one-size-fits-all solution: it stresses that judgements need to be made on the individual article. However, I agree it's easy to misunderstand, so we'd need a very clear name for it. Nemo 16:05, 30 July 2019 (UTC)

Add |zenodo=

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

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

I agree it would be useful: users have added thousands of links to Zenodo, which is now probably the biggest preprint/green OA server in the world apart from arxiv. (Disclosure: I'm known for liking Zenodo.) Nemo 17:27, 24 August 2019 (UTC)

I would be a bit reluctant to add |zenodo=, since |doi= and |url= can already be used to store such links. Adding custom support for identifier schemes that are covered by the DOI system defeats the point of DOIs (having a unified identifier system on top of many providers). I think Zenodo URLs can already be made canonical as things stand. − Pintoch (talk) 15:37, 27 August 2019 (UTC)

The thing is zenodo is it's own repository, and does not link to where the canonical DOI would. So if you use |doi=, then you're usurping the version of record DOI. It's the same with |biorxiv=. It's technically a doi, but it's not the DOI. Headbomb {t · c · p · b} 17:00, 27 August 2019 (UTC)

The advantage of Zenodo is that it is open access, whereas many articles which are linked to with doi require subscription. I'm in favour of providing a |zenodo=9999| field, but until then we can use |id={{zenodo|9999}}|. Wayne Jayes (talk) 05:24, 12 September 2019 (UTC)

Proposal for an "in-title" ("In" + title) parameter

I propose having an |in-title= form of the title parameter that prefixes an unitalicized "In" before the title. This is currently done for the titles of books (or "works") containing chapters ("contributions") when an editor is specified, but not when an editor is not specified. 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. ♦ J. Johnson (JJ) (talk) 22:43, 20 August 2019 (UTC)

Instead of a new parameter, how about always marking a component of a larger book in that way? That is, currently the following:

• {{cite book |contributor-first=A. |contributor-last=Contributor |contribution=Introduction |title=Book |first=A. |last=BookAuthor}}
• {{cite book |contributor-first=A. |contributor-last=Contributor |contribution=Chapter |title=Book |first=A. |last=BookAuthor}}
• {{cite book |first=A. |last=ChapterAuthor |chapter=Chapter |title=Book}}
• {{cite book |first=F. |last=ChapterAuthor |chapter=Chapter |title=Book |editor-first=A.N. |editor-last=Editor}}

are rendered as

• Contributor, A. Introduction. Book. By BookAuthor, A. {{cite book}}: |contributor-last= has generic name (help)
• Contributor, A. "Chapter". Book. By BookAuthor, A. {{cite book}}: |contributor-last= has generic name (help)
• ChapterAuthor, A. "Chapter". Book.
• ChapterAuthor, F. "Chapter". In Editor, A.N. (ed.). Book. {{cite book}}: |editor-last= has generic name (help)

It would be more comprehensible to render them consistently as

• Contributor, A. Introduction. In BookAuthor, A. Book.
• Contributor, A. "Chapter". In BookAuthor, A. Book.
• ChapterAuthor, A. "Chapter". In Book.
• ChapterAuthor, F. "Chapter". In Editor, A.N. (ed.). Book. {{cite book}}: |editor-last= has generic name (help)

now that editors are marked differently from book authors. Kanguole 23:26, 20 August 2019 (UTC)

There are subtle semantic differences between "in" and "by" as used currently in book citations. It is best to leave them alone. I believe the OP's request may be more trouble than is worth? 72.43.99.130 (talk) 15:59, 21 August 2019 (UTC)

K: Your "Contributor" examples are not relevant here, as they apply (per the {{cite book}} documentation) to afterwords, forewards, introductions, and such, what might be considered ancillary parts of a work. Your "ChapterAuthor" examples illustrate the problem: "In" is supplied only when an editor is specified, which in my instances is not desired. (Or supplied outside of the template, as you did in the latter examples.) Code to display the "In" is already present; I would like to trigger that (but without the "(ed.)") without having to specify an editor. ♦ J. Johnson (JJ) (talk) 22:23, 21 August 2019 (UTC)

Leaving aside |contributor= for the present, would this change do what you want? Examples:

Cite book comparison

Wikitext	{{cite book|chapter=Chapter|first=A.|last=ChapterAuthor|sandbox=yes|title=Book}}
Live	ChapterAuthor, A. "Chapter". Book. {{cite book}}: Unknown parameter |sandbox= ignored (help)
Sandbox	ChapterAuthor, A. "Chapter". Book. {{cite book}}: Unknown parameter |sandbox= ignored (help)

Cite book comparison

Wikitext	{{cite book|chapter=Chapter|editor-first=A.N.|editor-last=Editor|first=F.|last=ChapterAuthor|sandbox=yes|title=Book}}
Live	ChapterAuthor, F. "Chapter". In Editor, A.N. (ed.). Book. {{cite book}}: |editor-last= has generic name (help); Unknown parameter |sandbox= ignored (help)
Sandbox	ChapterAuthor, F. "Chapter". In Editor, A.N. (ed.). Book. {{cite book}}: |editor-last= has generic name (help); Unknown parameter |sandbox= ignored (help)

Kanguole 14:39, 22 August 2019 (UTC)

As a result of the completion of this unrelated rfc, I have undone Editor Kanguole's changes in the sandbox to facilitate preparation for a long overdo update to the live module suite that the rfc was blocking. Editor Kanguole's changes may be restored after the next update. More at Help talk:Citation Style 1#Italics of websites in citations and references – implementation.

—Trappist the monk (talk) 11:52, 27 August 2019 (UTC)

I think that I oppose this change. 'In' ('in' in {{citation}}) appears to have a use in that it names the editors who compiled the book and whose names appear on the front cover (it is their book so they are listed in the bibliographic information for the book). Authors of the individual chapters may not be or are not so named. '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. The "Chapter title". Book title form of 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. That being the case, this proposal seems like a fix for something that isn't broken.

The proposed use case, instances of multiple chapters in books where it is preferable to not list the book's editors in each chapter's citation, would result in incomplete citations with, consequently, incomplete metadata. Why are multiple less-than-a-full citation templates preferable to full citations? Can this not be handled by a mixture of {{sfn}} templates pointing to {{harvc}} templates that point to a single full citation template?

—Trappist the monk (talk) 16:02, 22 August 2019 (UTC)

K: I think so. The result you show looks good, but I am uncertain of the code. As far as I can read it, the current code outputs "in" if (Editors) and (Chapter) is set (and "0 == #c"??), while the sandbox code leaves off testing (Chapter), tweaks (Editors) further on, then outputs "in" if (Chapter) and (Editors) or (Title)". I think the result is to do the editor stuff if (Editors) is set (independently of (Chapter)?), and do the "in" if (Chapter) plus either (Editors) or (Title) is set. Right?

If that is the case, then the missing functionality is supplied, and an explict "in-title=" parameter would not be needed.

T: Your first comment is muddled. You seem to be thinking that the ambiguity of whether "author" applies to a book-title or a chapter-title depends on whether "editors" are specified. I think it should depend on whether "chapter" is specified.

To the essential point: I am working on citing the IPCC Assessment Reviews at Global warming. Here is a fairly typical complete chapter 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.

Undoubtedly your first thought on seeing this – and perhaps second and third thoughts as well – is: it's BIG. 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?)

But wait! it gets worse. You may have noticed that this citation for a chapter carries full information of the containing volume. Which is fine if that is the only citation to that work. But at GW, between just two Assessment Reviews, we have 9 volumes that get cited by about 43 chapters. Repeating the full volume info 43 times is just pounding any useful information into the ground. To insist on complete metadata about the volume in every citation of a chapter goes beyond pedantic, it is senseless.

You might also notice that in the IPCC's own requested citation the list of editors is enclosed in square brackets. I have never seen this done in an actual citation; I take those brackets to be metadata saying the list of editors is optional.

So what I have done is work out a system where the editors of the volumes (the Reports) are listed in the full citation for the volume, but not in the full citation for each chapter. Editor metadata is complete, it just isn't uselessly replicated at a lower level. The result is much slimmer, clearer, easier to use, and less intimidating to the editors. Does that satisfactorily answer your question of "Why are multiple less-than-a-full citation templates preferable to full citations?"?

Incidentally: no, this can NOT "be handled by a mixture of {{sfn}} templates pointing to {{harvc}} templates that point to a single full citation template". And what needs fixing is the current inability to get "in" without an editor. But possibly Kangoule has a fix in hand. ♦ J. Johnson (JJ) (talk) 22:41, 23 August 2019 (UTC)

The current code prefixes "In" to Editors if Chapter is set and there are no contributors (0 == #c), so it is tied to the presence of editors. The change is to take that logic out the editors part and have a separate decision whether to insert "In". I don't see "In" as a marker of editors – that is "(eds.)" – but rather an indication that the item being referenced is "in" a book. Kanguole 23:03, 23 August 2019 (UTC)

Yes, I think that is the better way. As a little bit of a tangential matter: My recollection is that elsewhere editors are listed following the work they edited. Is there any particular reason why we display editors before the book title? ♦ J. Johnson (JJ) (talk) 00:36, 24 August 2019 (UTC)

Not a good idea to only have a contributor in a citation. Book sources are indexed by author and title, mostly. That is how most people would look for them. In cases where there is no main author, as in a collection of contributors, the editor is considered the "author". That is because in such works, the editors are the biggest influence on the work. They normally choose and vet the contributors, have knowledge of the underlying material etc. The function of editor in a single-author work is quite different. That book is "by" someone, edited by an editor. In the case of collections, the book may come about by the editor, but the contributors are "in" it. It has been far easier to find such a source when looking for the editor. Because this was traditionally the way such works were indexed. When everything is online, such indexing may not be that important since it is easier to have, for all practical purposes, custom search indices on demand. But we are not there just yet. Not every source is online. So: if the source has an author, it does not matter if that author is the person who wrote it or the person who assembled it. This person should not be left out of the citation. 72.43.99.138 (talk) 14:58, 24 August 2019 (UTC)

72.*: You have missed an essential point; please re-read my comments above. In particular, please note that I am NOT saying that editors (or a small, representative subset) should be entirely left out, I am saying that extended details about a volume — such as a list of its editors — should not have to be repeated every time a chapter of that volume is cited. Note also that even the IPCC requested citation suggests that editors may be left out, which is in fact the practice at many (all?) journals. ♦ J. Johnson (JJ) (talk) 20:36, 24 August 2019 (UTC)

I believe your OP references books specifically?? If the template in question is {{cite journal}}, then different treatment could be applied, closer to what you propose (the journal being the source, with the article being the in-source location). I believe that a journal's editor(s) need not always be cited. And I am aware that there are cases of article-specific editors, for which a case-by-case determination may be the best option. 65.88.88.93 (talk) 21:06, 24 August 2019 (UTC)

@Kanguole: See reference #20 at Schlumbergera#References. Is this the effect you want?
More generally, catering for every exceptional case in the citation templates is a mistake, in my view. Some unusual and complex citations are best handled manually. Peter coxhead (talk) 15:27, 24 August 2019 (UTC)

It was J. Johnson that was asking for this. Your example raises different issues, I think. Kanguole 17:19, 24 August 2019 (UTC)

Peter: yes, that is the effect desired. I did try that approach, but there were some other complications. That the s/w currently rejects this case appears to be an accidental oversight, and I think correcting it in the manner illustrated by Kanguole is the better approach. While the IPCC citations may be small potatoes in the overall scheme of things, yet they are essential to some of our most visible articles (such as Global warming), and need to be done well. Experience has shown that expecting editors to do much "manual assembly" of citations is not realistic, so I am trying to make these as simple as possible. ♦ J. Johnson (JJ) (talk) 20:40, 24 August 2019 (UTC)

Jumping in to note that I too have desired a similar effect at times. Template:Harvc doesn't really do what I need it to do (not enough fields for individual chapters/contributions, e.g., |author=, |orig-year=, |date= (to allow YEARa, YEARb, YEARc for sfns when multiple contributors in the same book have the same author(s)), conceivably |doi=, |translator=, but doing |title=''"[chapter title]"'', while a bit "hacky", produces the desired effect perfectly, so thanks for showing me that method, Peter coxhead. Umimmak (talk) 02:43, 26 August 2019 (UTC)

Editor Peter coxhead's suggestion is, I think, not a good suggestion. The wikisource for reference #20 is:

{{Citation |last=Hunt |first=David |title=''"Appendix III Excerpts from a Brazilian diary"''}}, in {{Harvnb|McMillan|Horobin|1995|pp=82–88}}

The metadata for the {{citation}} portion of that is this:

'"`UNIQ--templatestyles-00000087-QINU`"'<cite id="CITEREFHunt" class="citation cs2">Hunt, David, ''<span></span>''"Appendix III Excerpts from a Brazilian diary"''<span></span>''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%22Appendix+III+Excerpts+from+a+Brazilian+diary%22&rft.aulast=Hunt&rft.aufirst=David&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

That decodes to a book citation where the book's title is "Appendix III Excerpts from a Brazilian diary" (with the quote marks). There are two other citations like this in that page. An alternate would be to use individual {{harvnb}} templates for the appendix authors that link to appropriate {{harvc}} templates that in turn link to the single citation template:

the {{harvnb}} templates (in the text)

{{harvnb |Hunt |1995a}} → Hunt 1995a

{{harvnb |Hunt |1995b}} → Hunt 1995b

{{harvnb |McMillan |Horobin |Hunt |1995}} → McMillan, Horobin & Hunt 1995

the {{harvc}} templates:

{{harvc/sandbox |in=McMillan |in2=Horobin |last=Hunt |first=David |c=Appendix I Names and synonyms of the species, subspecies and interspecific hybrids |year=1995 |anchor-year=1995a |mode=cs2 |nb=yes}}

Hunt, David (1995a), "Appendix I Names and synonyms of the species, subspecies and interspecific hybrids", in McMillan & Horobin 1995

{{harvc/sandbox |in=McMillan |in2=Horobin |last=Hunt |first=David |c=Appendix III Excerpts from a Brazilian diary |year=1995 |anchor-year=1995b |mode=cs2 |nb=yes}}

Hunt, David (1995b), "Appendix III Excerpts from a Brazilian diary", in McMillan & Horobin 1995

{{harvc/sandbox |in=McMillan |in2=Horobin |last1=McMillan |first1=A.J.S. |last2=Horobin |first2=J.F. |last3=Hunt |first3=David |c=Appendix IV Checklists of historic varieties and modern cultivars |year=1995 |mode=cs2 |nb=yes}}

McMillan, A.J.S.; Horobin, J.F.; Hunt, David, "Appendix IV Checklists of historic varieties and modern cultivars", in McMillan & Horobin 1995

and the single {{citation}} template:

{{Citation |last=McMillan |first=A. J. S. |last2=Horobin |first2=J. F. |year=1995 |title=Christmas Cacti: The Genus ''Schlumbergera'' and Its Hybrids |edition=p/b |publication-place=Sherbourne, Dorset, UK |publisher=David Hunt |isbn=978-0-9517234-6-3}}

McMillan, A. J. S.; Horobin, J. F. (1995), Christmas Cacti: The Genus Schlumbergera and Its Hybrids (p/b ed.), Sherbourne, Dorset, UK: David Hunt, ISBN 978-0-9517234-6-3

This works, shows that CITEREF disambiguation works (contrary to claims by Editor Umimmak). For Editor Umimmak's other concerns, |date= has never been supported by {{harvc}} because CITEREFs produced by the {{harv}} family and {{sfn}} only use the year portion of a date; similarly, |author=, |orig-year=, and |translator= are not supported just as they are not supported by {{harv}} and {{sfn}} (there is a three-year-old request for |translator= though I do not recall having seen that request before); there may be some sense in supporting |doi= in {{harvc}} because dois are often assigned to book chapters; though, to date, no one has requested such support.

—Trappist the monk (talk) 15:41, 26 August 2019 (UTC)

I guess I'm still confused how your method works for disambiguation. It would only work as a link, no? If, say, a Wikipedia article was printed or the links break there would be no way to tell which is Hunt 1995a and which is 1995b. And I guess in citations when |author= would have been used in the CS1 family, the whole name should go in |last=? Umimmak (talk) 21:54, 26 August 2019 (UTC)

Point. I wonder if creating |anchor-year= in {{harvc}} would solve that. If that parameter has a disambiguated year (year portion must match |year=) then {{harvc}} would use that in its CITEREF anchor and render the value parenthetically after the author names; |year= would continue to be used in the CITEREF link to the cs1|2 template. Doing this would mean that {{sfnref}} templates in my examples above would not be required.

—Trappist the monk (talk) 18:05, 27 August 2019 (UTC)

I've changed the above {{harvc}} examples to {{harvc/sandbox}} which uses Module:Harvc/sandbox. The sandboxen now support |anchor-year= and |nb=. In the renderings, when |anchor-year= is used, and is the same 'year' as |year=, and has a required disambiguator, the value of |anchor-year= is used in the CITEREF identifier and is rendered after the author name-list. When |nb=yes, link to the cs1|2 template is rendered the same as a {{harvnb}} rendering.

I expect to update the live Module:Harvc shortly.

—Trappist the monk (talk) 15:24, 28 August 2019 (UTC)

Which all perhaps shows that {harvc} could be used for to get "in", but I think it would be much simpler to just fix cs1|2 to work in the expected manner.

One of the concerns I have with harvc is that it seems to be morphing into a full citation. The main function of {{Harv}} family of templates is to link to the full citation, not replace it. If harvc's use and options start looking like a full citation I think it will only further confuse some editors on how to use short-cites.

Unimmak: no! "Whole name" should not go into |author= (etc.). Universal bibilographic practice is to sort and search by surname (family name, "last" in Western usage); links to citations are (e.g.) in the form of "Smith and Jones, 2001", not "Smith, Larry, and Jones, William, 2001". ♦ J. Johnson (JJ) (talk) 23:35, 26 August 2019 (UTC)

Like I said, I was only asking about citations where |author= is more apt than |last=, |first=. Template:Harvc only has the latter which doesn’t work for, say, collective authors credited under an organizational name or whatever, and it’s also less than ideal for names with non-Western word orders as an incorrect comma gets added. Umimmak (talk) 00:43, 27 August 2019 (UTC)

harvc ... seems to be morphing into a full citation. Hardly. {{harvc}} has not been touched since December 2015. There is some sense to adding |authorn= support so that corporate authors are placed into semantically meaningful parameters; this is simply the addition of alias support (it would be the same as cs1|2 in which |lastn= and |authorn= are aliases). It is unlikely that {{harvc}} will ever be a full citation because the bibliographic detail required by a full citation is not required and not supported by {{harvc}} and would be redundant to bibliographic detail in the associated cs1|2 template. {{harvc}} supports |firstn= because the visual rendering should show all of the chapter / section / article author's name. The comma separator inserted in non-western names has been an unsolved problem in cs1|2 forever and it's no different in {{harvc}}. Find a solution for this with either of cs1|2 or {{harvc}} and you've solved the problem in both.

One other thing that might be added to {{harvc}} would be some sort of mechanism to control parentheses in the rendering to allow {{harvc}} to match parentheses rendered by the article's chosen short-form templates.

—Trappist the monk (talk) 18:05, 27 August 2019 (UTC)

@Kanguole: I think what you demonstrated would be a satisfactory resolution. Is there any chance it might be implmented soon? ♦ J. Johnson (JJ) (talk) 21:11, 27 August 2019 (UTC)

I think it's a reasonable fix, but it seems it will take a while: diff. Kanguole 23:03, 27 August 2019 (UTC)

Oh, I didn't see that comment. Okay, hopefully this will eventually be done, and I will abide a while without "in". Thank you. ♦ J. Johnson (JJ) (talk) 23:47, 27 August 2019 (UTC)

Italics of websites in citations and references – implementation

Following the close above at #Italics of websites in citations and references – request for comment, any thoughts about implementing this? I'm not feeling creative or analytical right now. SchreiberBike | ⌨  04:56, 27 August 2019 (UTC)

That's the status quo. Nothing needs to be done. Headbomb {t · c · p · b} 07:16, 27 August 2019 (UTC)

I have undone the change described at Help talk:Citation Style 1/Archive 57#2. support for use-this-parameter-value-as-written. This will now permit us to do the long overdo update that the rfc was blocking.

—Trappist the monk (talk) 11:56, 27 August 2019 (UTC)

Since the test case was in the batch, #3 in that list has two warnings I wouldn't expect for this citation: "Title". [Trans newspaper]. {{cite news}}: |trans-periodical= requires |periodical= or |script-periodical= (help). Is that intentional? --Izno (talk) 13:57, 27 August 2019 (UTC)

Yes, intentional. At the moment, there are two tests in two separate locations in the code. For the next iteration, we might refine the code so that both tests occur in the same place or do some other clever something so that only one of the two error messages is emitted. I choose to defer that until later.

—Trappist the monk (talk) 16:55, 27 August 2019 (UTC)

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

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

Module:Citation/CS1:

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

Module:Citation/CS1/Configuration:

• update bibcode url; discussion
• update two error category names and many maint category names to make capitalization consistent; discussion
  • Category:CS1 maint: Archived copy as title → Category:CS1 maint: archived copy as title
  • Category:CS1 maint: Uses authors parameter → Category:CS1 maint: uses authors parameter
  • Category:CS1 maint: Date format → Category:CS1 maint: date format
  • Category:CS1 maint: Date and year → Category:CS1 maint: date and year
  • Category:CS1 maint: Uses editors parameter → Category:CS1 maint: uses editors parameter
  • Category:CS1 maint: Extra text → Category:CS1 maint: extra text
  • Category:CS1 maint: Extra text: authors list → Category:CS1 maint: extra text: authors list
  • Category:CS1 maint: Extra text: editors list → Category:CS1 maint: extra text: editors list
  • Category:CS1 maint: Extra text: interviewers list → Category:CS1 maint: extra text: interviewers list
  • Category:CS1 maint: Extra text: translators list → Category:CS1 maint: extra text: translators list
  • Category:CS1 maint: Ignored ISBN errors → Category:CS1 maint: ignored ISBN errors
  • Category:CS1 maint: Multiple names: authors list → Category:CS1 maint: multiple names: authors list
  • Category:CS1 maint: Multiple names: editors list → Category:CS1 maint: multiple names: editors list
  • Category:CS1 maint: Multiple names: interviewers list → Category:CS1 maint: multiple names: interviewers list
  • Category:CS1 maint: Multiple names: translators list → Category:CS1 maint: multiple names: translators list
  • Category:CS1 maint: Unfit url → Category:CS1 maint: unfit url
  • Category:CS1 maint: Unrecognized language → Category:CS1 maint: unrecognized language
  • Category:CS1 maint: Untitled periodical → Category:CS1 maint: untitled periodical
  • Category:CS1 errors: Explicit use of et al. → Category:CS1 errors: explicit use of et al.
  • Category:CS1 errors: Missing pipe → Category:CS1 errors: missing pipe
• remove unsupported |distributor=; discussion
• periodical templates missing periodical parameter error messaging;
• add script parameter error detection & messaging;
• add |script-periodical and |trans-periodical parameter support;
• deprecate and replace |dead-url= and |deadurl=;
• add |map-url-access=;
• add long-missing zbl maint cat; discussion
• |doi-broken= requires |doi= error messaging;

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:

• fix date format bug; discussion

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. {{cite book}}: Unknown parameter |agency= ignored (help)CS1 maint: extra punctuation (link)

does not emit a red error message but does emit the green maint cat extra punctuation message. That was all that it was intended to do,

—Trappist the monk (talk) 15:39, 28 August 2019 (UTC)

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 error

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

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

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

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 16 —Trappist 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. {{cite web}}: Check |archiveurl= value (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (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 url

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

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

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

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

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

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 changes

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 warning

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

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)

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?

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)

Post-update updates needed

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

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

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

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

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

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)

Psycho-Pass Movie Pamphlet

I found translations for this Psycho-Pass Movie Pamphlet from 2015. How should the reference be handled? The website has some data about the pamphlet but I'm not sure what to make of it. Cheers.Tintor2 (talk) 17:07, 28 August 2019 (UTC)

Where did you find the translations? Presumably you'll be using the translations to work on the article, not the original pamphlet? So the translations are what should be cited, in whichever medium they were published. Umimmak (talk) 22:59, 29 August 2019 (UTC)

@Umimmak: Well you see, the pamphlet was not released in English regions so there's no official translations. It tends to happen to certain series that have books talking about their making but are never translated.Tintor2 (talk) 00:25, 30 August 2019 (UTC)

author-affiliation?

In collections like conference notes and similar works, it is common for authors to list their affiliations, like "Brookhaven National Laboratory". Would it be possible to get an author-affiliation tag for this purpose? It would not be for the work as a whole, which would be covered by publisher (or, I suppose, editor-affiliation?). Maury Markowitz (talk) 21:05, 28 August 2019 (UTC)

Exact same topic barely a month old. --Izno (talk) 21:18, 28 August 2019 (UTC)

And, as in that discussion, it is false that it is common to list affiliations in references or bibliographies, to the point that I don't recall having ever seen it. It is common for authors to list their own affiliations, but as we don't list the authors of Wikipedia articles there is no need to do that here. —David Eppstein (talk) 23:17, 28 August 2019 (UTC)

I don't recall ever seeing affiliations in a bibliography, either. (Bibliographies are very compressed things; it's common to omit titles of papers and to abbreviate journal names.) If an author is wiki-notable, we have the authorlink parameter, which makes their full employment history only a click away. XOR'easter (talk) 18:52, 29 August 2019 (UTC)

Et al

Does anyone know how to get rid of the script error if we write "Smith, John, et al." manually? I know we can add all the names and "display-author". But sometimes I can only remember the first author and don't have time to look up the others. I want to be able to add "et al." manually without causing the red message to appear. SarahSV ^(talk) 02:40, 30 August 2019 (UTC)

Not possible. One author name and |display-authors=etal is how it's done.

{{cite book |title=Title |author=Smith, John |display-authors=etal}}

Smith, John; et al. Title.

—Trappist the monk (talk) 02:45, 30 August 2019 (UTC)

Trappist the monk, thank you! SarahSV ^(talk) 02:48, 30 August 2019 (UTC)

"Et al." is generally applicable only with four or more authors; with two or three authors it is expected to name them all. But only by the "last" name (surname). If you are doing this for the full citation then you are omitting important bibliographic information. I would suggest that waiting until you do have such information is better than providing incomplete information. ♦ J. Johnson (JJ) (talk) 20:03, 4 September 2019 (UTC)

Differing headlines between Print and Internet articles

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

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)

isbn2

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)

Proposal to overturn the mass change made to Module:Citation/CS1

Please comment at Wikipedia:Administrators' noticeboard#Proposal to overturn the mass change made to Module:Citation/CS1. --- Coffeeandcrumbs 13:58, 3 September 2019 (UTC)

Omitting "website=" for simple, one page sites

A page I've cited a lot is https://dadgum.com/giantlist/. It's a single-page database of programmers for early video games. Most of the citations of this I've seen set "title", but not "website", because it isn't clear what the website tag should be. The same as the title? The domain name? Both of those are redundant. Feels like this is a legitimate reason to omit "website" without having a warning displayed. Dgpop (talk) 16:47, 3 September 2019 (UTC)

Dgpop, you can use "Programming in the Twenty-first Century", "Halcyon Days", "The Giant List of Classic Game Programmers" for website=.

{{cite web|url=https://dadgum.com/halcyon/BOOK/BILLYARD.HTM|title=Adam Billyard|website=The Giant List of Classic Game Programmers|access-date=3 September 2019}}

"Adam Billyard". The Giant List of Classic Game Programmers. Retrieved 3 September 2019. --- Coffeeandcrumbs 16:58, 3 September 2019 (UTC)

You can also addvia=Dadgum.com. --- Coffeeandcrumbs 17:01, 3 September 2019 (UTC)

Some change was made to cite web that I think has to do with this discussion thread. An article I made a few days back, Eddie Picken, now shows several red error messages in the references section, stating "cite web requires | website = (help)". Someone please fix this citation template back. SportsGuy789 (talk) 17:04, 3 September 2019 (UTC)

This is currently being discussed at WP:AN, I would place your input there before making any edits. - Knowledgekid87 (talk) 17:06, 3 September 2019 (UTC)

Good to know. This appears to be the current source of the problem. Dgpop (talk) 17:41, 3 September 2019 (UTC)

ye, seems silly with the element |=website, coming up on red on thousands of articles, can we reverse this fix? Govvy (talk) 17:45, 3 September 2019 (UTC)

Dgpop, for that particular example, I'd take dadgum.com as the overall website, which has a number of pages. The |website= parameter is for the name of the website, most often that's found in the html "title" on the home index page of the site. In this case, going to https://dadgum.com/, it's "Dadgum Games". I think it should be:

{{cite web|last=Hague|first=James|url=https://dadgum.com/giantlist/|title=The Giant List of Classic Game Programmers|website=Dadgum Games|access-date=3 September 2019}}

Hague, James. "The Giant List of Classic Game Programmers". Dadgum Games. Retrieved 3 September 2019.

I don't really understand the other example, or the use of |via=, suggested above.

On the other hand, it's a good point, because there are many true single-page websites, where the title of the page and the name of the website are the same. If both parameters are now required, it will be redundant. --IamNotU (talk) 23:19, 4 September 2019 (UTC)

I'm seeing hundreds of "cite web requires website=" error messages in article references that were previously non-problematic. Category:CS1 errors: missing periodical has over 100,000 of them (I think this is where these errors are being listed). I don't think that this has been adequately discussed. Please reverse. —David Eppstein (talk) 20:08, 3 September 2019 (UTC)

• Trappist the monk, someone has made a change that is causing lots of error messages. For example, if we use publisher= in cite news, it says we have to use newspaper, work etc. For example, the following now causes an error message: "Story title". BBC News. 3 September 2019.. Publisher is often appropriate in cite web too. Please undo that change. SarahSV ^(talk) 20:54, 3 September 2019 (UTC)

If that's a citation to a story on the BBC News website, it seems like a good example of what not to do. It should be "Story title". BBC News. 3 September 2019. instead. See the RFC here that was closed at 15:49, 26 August 2019 (UTC). —BarrelProof (talk) 23:27, 5 September 2019 (UTC)

See, my feeling is that BBC News is an organization and should not be italicized. For instance: CBS News is an organization. CBS Evening News is a TV program. Italicizing CBS News gives a factual misimpression, and why would we want to do that? When CBS News and CBS Evening News are treated differently in the real world, I'm not sure what's gained by eccentrically and confusingly treating them the same in Wikipedia.--Tenebrae (talk) 23:53, 5 September 2019 (UTC)

CBS News is an organization, and if you go to that organization's website, the website is named CBS News. Wikipedia's style is that the names of websites in references are italicized. It wouldn't be italicized in text, but it is in a reference. SchreiberBike | ⌨  00:11, 6 September 2019 (UTC)

Actually, WP:CITESTYLE says "Wikipedia does not [emphasis added] have a single house style, though citations within any given article should follow a consistent style. A number of citation styles exist [emphasis added] including those described in the Wikipedia articles for Citation, APA style, ASA style, MLA style, The Chicago Manual of Style, Author-date referencing, the Vancouver system and Bluebook." The Chicago Manual of Style, for example, does not italicize website names. --Tenebrae (talk) 01:02, 6 September 2019 (UTC)

And one of the styles that can be used on Wikipedia is called WP:Citation Style 1, what we are talking about is how Citation Style 1 is formatted. In Citation Style 1, website names, such as CNN and CBS News and Reuters, are rendered in italics. If you want to use a different style instead of using Citation Style 1, that is permitted (provided that the style is consistent within the article). —BarrelProof (talk) 05:46, 6 September 2019 (UTC)

I understand. Yet there's no alternative cite style that doesn't automatically italicize the field ... and Citation Style 1 doesn't allow markup to de-italicize. So for all intents and purposes, it prevents Chicago Manual of Style from being used. And yes, we're not required to use citation templates, but editors regularly take footnotes not using a template and put them into a template, so that really doesn't work. Citation Style 1 needs to allow markup for flexibility — or else we've have, in any practical sense, forbidden Chicago Manual of Style to be used. --Tenebrae (talk) 21:35, 9 September 2019 (UTC)

Template documentation updates needed in cite template examples for dead-url= parameter

I have been away for a few months, so I am not up to date on the detailed discussions about |dead-url= and what it should be replaced with. It looks like documentation updates are needed on some or all of the doc pages for the individual cite templates listed at Help:Citation Style 1.

Can someone who understands the changes better than I please take on the (onerous, I know) task of replacing |dead-url= with its updated equivalent every time it appears on {{cite news/doc}} and the doc pages for the other CS1 templates? It may help reduce the controversy around the latest updates. – Jonesey95 (talk) 17:06, 3 September 2019 (UTC)

This is currently being discussed at WP:AN, I would place your input there before making any edits. - Knowledgekid87 (talk) 17:06, 3 September 2019 (UTC)

Thanks, I did that already. Part of the complaint there is that the documentation has not yet been updated, hence my request here. I believe that the main complaint is the requirement of |website= for {{cite web}}. The change to |dead-url= in articles is just housekeeping and can be fixed by a bot, so I think that the documentation will need to be updated at some point. – Jonesey95 (talk) 17:34, 3 September 2019 (UTC)

Whatever all this means, the reference sections in articles now look diabolical. - NewTestLeper79 talk 17:47, 3 September 2019 (UTC)

Yes, but only in preview mode. SLBedit (talk) 20:37, 3 September 2019 (UTC)

When was this proposal made? I don't see any of the wikiprojects getting notified for this change or even the discussion to make this change.Blue Pumpkin Pie (talk) 20:44, 3 September 2019 (UTC)

Sorry, my mistake. SLBedit (talk) 20:52, 3 September 2019 (UTC)

The fact that there are no red links there on the Template doc page now, is thanks to these changes by Coffeeandcrumbs (talk · contribs), who was kind enough to clean up after someone else crapped all over the place. Mathglot (talk) 20:59, 3 September 2019 (UTC)

I agree with the changes that were recently made. I made the Template doc changes to align with the new parameters. I don't think "someone else crapped all over the place". The crap was already there. They just exposed it so it can be fixed. I have fixed the GA's I have promoted such as Yuri Gagarin and Mae Jemison. I also fixed some pages linked from Main Page like The Breeders Tour 2014 and tomorrow's TFA Sasha (DJ) so people would stop complaining and get to fixing the issues. --- Coffeeandcrumbs 21:14, 3 September 2019 (UTC)

I'm suddenly getting a lot of warnings "Cite web requires |website=". Under no circumstances will I supply this, so I need to switch off the warning. Anyone know where it comes from and how to shut it off? Hawkeye7 (discuss) 21:10, 3 September 2019 (UTC)

Please see the much larger discussion of this at WP:AN. —David Eppstein (talk) 23:45, 3 September 2019 (UTC)

Help:Duplicate parameters

I am just going to ask it here: Is it possible that we do something like this but only for instances of a missing |website= parameter for {{cite web}}?

It's just a question. I do not intend to promote this as a solution to the current predicament or engaging in that drama. I'm just curious if it can be done on a technical level. –MJL ‐Talk‐^☖ 21:02, 3 September 2019 (UTC)

Preview-only error messages are possible. Unfortunately, my anecdotal experience with them is that they are rarely fixed, especially those where the error message is remote from where the error occurs and where the editor is focusing their attention.

—Trappist the monk (talk) 11:31, 4 September 2019 (UTC)

@Trappist the monk: Would you be willing to help a smaller language wiki implement it at the very least based off consensus there? –MJL ‐Talk‐^☖ 16:11, 4 September 2019 (UTC)

I am but am hesitant to do so be cause that can and likely will create a roadblock to future updates happening here. I try to write code that will work most anywhere, only requiring local changes to Module:Citation/CS1/Configuration – that isn't always possible but is the goal. Modifying a copy of the module suite specifically for other wikis will likely require that someone there be willing and capable to: reapply the changes with every update, never update again, or continue development on their own on a divergent path from en.wiki cs1|2.

—Trappist the monk (talk) 17:29, 4 September 2019 (UTC)

Cite web requires website

I'm suddenly getting a lot of warnings "Cite web requires |website=". Under no circumstances will I supply this, so I need to switch off the warning. Anyone know where it comes from and how to shut it off? Hawkeye7 (discuss) 21:10, 3 September 2019 (UTC)

Right, I am arriving too to ask about the same. Whatever change just implemented has caused that display error in tens of thousands of WikiProject NRHP articles, where a standard reference citing a National Register document uses the cite web template (John Boyum House being one new example). A url is in fact provided within this reference to a standard NRHP nomination document provided by the National Park Service. I have always thought "cite web" was the right way to refer to these. It is certainly not "cite news". So I think whatever changed should be reversed, probably, though I admit I don't know much about what is going on here. Anyhow, it has affected probably the majority of 68,918 current articles about NRHP listings. --Doncram (talk) 21:23, 3 September 2019 (UTC)

I find "cite web" to be an extraordinarily troublesome template. MOS does not say that anything other than a newspaper, magazine or journal must be italicized, but cite web italicizes the website field automatically. So we wind up with ridiculous things like Marvel Comics italicized since we can't put it in the "publisher" field because the "publisher" is The Walt Disney Company.

And even though MOS says to use common sense, editors in the closed discussion above argue for italicizing everything, no exceptions, no matter what. Thank you "cite web." --Tenebrae (talk) 21:45, 3 September 2019 (UTC)

This is not correct. First, there has to be leeway on the application of WP:MOS when it comes to what is for all intents and purposes an article's back matter. Citation systems target ease-of-proof, concisely presented. Doubly so in a delivery system like Wikipedia where the vast majority of users are non-experts. In the outside world, the decision to follow the style of content in references is entirely up to the individual editor or to her/his publisher's own editing guidelines. Generally, part of a citation's ease-of-verifiability is to make the most important parameter (the source or "work") the most easily identifiable one. The way this happens in CS1 is by applying emphasis. That is why the particular source (happens to be a website in this case) is italicized. Citations are not prose. 108.182.15.109 (talk) 01:04, 4 September 2019 (UTC)

Citing books, magazines and newspapers in italics and company names and the like in non-italics has worked fine and clearly for a couple hundred years. Adding bad grammar and factual inaccuracy to footnotes for the sake of an extremist and arbitrary one-size-fits-all policy is wrong.--Tenebrae (talk) 21:02, 4 September 2019 (UTC)

Cite tweet is affected by this as well. AngusWOOF (bark • sniff) 23:32, 3 September 2019 (UTC)

Please see the much larger discussion of this at WP:AN. —David Eppstein (talk) 23:44, 3 September 2019 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The trailing semicolon in |author-mask= adds the article to Category:CS1 maint: extra punctuation which will no doubt get improperly fixed by someone or some bot or some script which then becomes a maintenance headache. On the other hand, for the purposes of metadata, |last= and |first= are the preferred author-name parameters so using |author-mask= to hide the name separator comma is to be preferred over |author= with {{sfnref}}.

This name order issue keeps recurring so perhaps someday we'll be brave enough or clever enough to find a solution. In the mean time (and after the current kerfuffle settles) I'll fix the code so that trailing punctuation in the mask parameters doesn't add the maint cat.

—Trappist the monk (talk) 11:26, 4 September 2019 (UTC)

Thank you, I forgot the punctuation would have added a maintenance category, so thank you for thinking about that and letting this be an exception. And yeah, no rush on this. Umimmak (talk) 14:15, 4 September 2019 (UTC)

While I’m thinking about it, Trappist the monk, is there an easy way to have |authorn-mask= accept text arguments in {{Harvc}} as well so it would work in a similar fashion? Thanks. And again, no rush on this; I know things have been a bit hectic. Umimmak (talk) 05:08, 11 September 2019 (UTC)

In the sandbox:

{{harv|Black|2019}} → (Black 2019)

{{harv|Brown|Black|2019}} → (Brown & Black 2019)

{{harvc/sandbox |last=Black |year=2019 |c=Contribution Title |in=Editor |author-mask=Black Masked}}

Black Masked. "Contribution Title". In Editor (2019).

{{harvc/sandbox |last=Brown |last2=Black |year=2019 |c=Contribution Title |in=Editor |author-mask2=2}}

Brown; ——. "Contribution Title". In Editor (2019).

{{cite book |title=Title |editor=Editor |date=2019 |ref=harv}}

Editor, ed. (2019). Title. {{cite book}}: |editor= has generic name (help); Invalid |ref=harv (help)

like that?

—Trappist the monk (talk) 15:38, 11 September 2019 (UTC)

Trappist the monk yes that's perfect! Thank you so much for making these changes! Umimmak (talk) 04:10, 12 September 2019 (UTC)

done

—Trappist the monk (talk) 11:08, 13 September 2019 (UTC)

template styles is broken?

Yesterday when I decided to hide the deprecated parameter and missing periodical error messages, I thought that just switching the error conditions hidden value from false to true would be sufficient. It wasn't so I implemented a brute force method in Module:Citation/CS1/Utilities that did work. I have undone the brute force method in the sandbox. This very simple template should not be showing an error message:

{{cite journal/new |title=Title}} → "Title". {{cite journal}}: Cite journal requires |journal= (help)

'"`UNIQ--templatestyles-000000D0-QINU`"'<cite class="citation journal cs1">"Title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Cite journal requires <code class="cs1-code">&#124;journal=</code> ([[Help:CS1 errors#missing_periodical|help]])</span>

The module clearly thinks that the error message should be hidden because it has added class cs1-hidden-error to the wrapping span. The old show-every-error css in my common.css is commented out so that isn't it. @Izno, you're more knowledgeable about css than I, any ideas?

—Trappist the monk (talk) 11:05, 4 September 2019 (UTC)

What TemplateStyles does is de-duplicate rather than 'cascade'. That means we must be sensitive to where we are testing the CSS. In phab:T200441 I requested and got a way to do so. Here is a sandbox with the issue:

"Title". {{cite journal}}: Cite journal requires |journal= (help)

And one I think should be without:

"Title". {{cite journal}}: Cite journal requires |journal= (help)

But I have to save this to see if this works the way I think it does. --Izno (talk) 12:56, 4 September 2019 (UTC)

So, the above works (apparently with/without adding a custom class? bizarre). I had to remove my personal CSS. You are still seeing them? --Izno (talk) 13:13, 4 September 2019 (UTC)

Just to play separately, xyz

xyz

xyz should display nothing. --Izno (talk) 13:42, 4 September 2019 (UTC)

Okay, so, I can confirm that TemplateStyles isn't broken (by doing some fun inverse testing). @Trappist the monk: The issue, as I thought might be the case, is that you have global CSS (presumably to help other wikis). See meta:User:Trappist_the_monk/global.css. --Izno (talk) 14:08, 4 September 2019 (UTC)

Just to follow up, the wrapper element on the sandbox template must be removed when you sync to live in the general case. But otherwise, it can provide for same-page/side-by-side testing simply by wrapping the sandbox template in an element with the class you specify as the wrapper class (see second example above). --Izno (talk) 14:10, 4 September 2019 (UTC)

Yeah, the global css was it (this is why global variables in Lua are bad). Thanks.

—Trappist the monk (talk) 14:41, 4 September 2019 (UTC)

Wrapper

@Izno: What does this change do? What happens when that module is copied to Module:Citation/CS1?

—Trappist the monk (talk) 11:07, 5 September 2019 (UTC)

See my follow up above; it must be removed each time you go to sync to the sandbox. I was thinking on the way in to work that there is a more elegant way to do this like we have today with the other sandbox lines. But it does allow us to sandbox CSS changes on the same page as a non-sandbox template. --Izno (talk) 12:44, 5 September 2019 (UTC)

Where is the templatestyles wrapper parameter documented?

—Trappist the monk (talk) 15:59, 8 September 2019 (UTC)

The only place it is documented is the task linked in phab:T200441. It should probably also be documented on the extension/help pages on Mediawiki.org, but is not. --Izno (talk) 16:37, 8 September 2019 (UTC)

I've reopened that task. Likely it will be promptly closed without action but I can always hope ...

—Trappist the monk (talk) 16:48, 8 September 2019 (UTC)

Better explanation for "website" parameter in docs

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

The current documentation is a little sparse:

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

and:

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

Example

Rotten Tomatoes

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

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

and/or:

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

Example

Rotten Tomatoes

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

<title> simply defines the title of the HTML document, typically the title of the tab in your browser, which may or may not be the actual name of the website. For instance, on Rotten Tomatoes it is actually <title>Rotten Tomatoes: Movies | TV Shows | Movie Trailers | Reviews - Rotten Tomatoes</title>. I am under the impression that there are other tags specifically for this purpose: <meta name>, <meta title> and <meta property>. On Rotten Tomatoes it is <meta property="og:site_name" content="Rotten Tomatoes">. I use User:V111P/js/WebRef which is pretty good at fetching the correct name of the website. – Finnusertop (talk ⋅ contribs) 09:07, 5 September 2019 (UTC)

I think that things like Wikipedia:RefToolbar/2.0 are the reason for is for a simplified URL, like "example.com" and that the reason why the documentation is so vague is because it is not actually a very useful parameter that also combines several not-always-related pieces of information.

We need a discussion or RfC to decide how |website= should work. In some cases, the website is also the publisher; in others it is merely a platform where the material published by someone else is hosted. The correct way would be to make |publisher= be the essential parameter and |website= an optional one for when one is getting the info from another website than that of the publisher per WP:SAYWHEREYOUGOTIT. Jo-Jo Eumerus (talk, contributions) 09:46, 5 September 2019 (UTC)

Agreed that the /doc page needs to explain it better. Even the #Examples section at the various {{cite}} templates are not self-consistent, sometimes using an English website name ('Encyclopaedia of Things') and sometimes using the domain name ('NFL.com').

Meta property 'og:sitename' is not standard HTML; it's part of Open Graph Protocol a proprietary property in a framework used for social media (Facebook, primarily, and others). 'Title' is standard Html since the beginning, and is often a good choice for |title=, and *sometimes* for website. Agree with Jo-Jo, that it's sometimes this, and sometimes that; in organizations with many nested levels (governmental, or large private or public orgs) it can be very unclear what the 'website' really is. Because of this, making it mandatory is a bad idea, imho, because you will get editors of all different levels trying to decide what it is for a given page on the web, and coming up with ten different answers for the exact same url (except for the simple cases). A lot more thought needs to be put into this. Mathglot (talk) 09:58, 5 September 2019 (UTC)

Jo-Jo Eumerus, you're right about Citoid/RefToolbar slapping a short URL into |website= by default, that's quite counterproductive and misleading. Mathglot, the NFL example is unclear, because "NFL.com" is actually the website name of http://nfl.com, as opposed to "www.nfl.com" that Citoid generates - a lot of sites are branded that way. On the other hand, the URL given in that example, http://www.nfl.com/rulebook/digestofrules, is now a dead link that redirects to https://operations.nfl.com/ - the website name there is "NFL Football Operations"... --IamNotU (talk) 10:26, 5 September 2019 (UTC)

PS, I just updated that NFL example... --IamNotU (talk) 10:40, 5 September 2019 (UTC)

(edit conflict)Finnusertop, thanks, yes I did mention the "og:site_name" in the thread I linked above as being helpful when present, but it's part of Facebook's open graph scheme and not universally used. I also noted the fact that the HTML title of the home page typically includes the website name, but also includes things like the word "home" etc., which the editor has to figure out. What I'd like to do is give people better clues about what and where to look for the most appropriate value for |website=, not to say definitively "this is it", because it's sometimes not straightforward.

Btw., the <meta> tag is a generic way to associate a name with a set of values as metadata, "name" is an attribute of the tag, which is the name of the variable. You could define for example, <meta name="sitename" content="Example Domain" />, but there's no standard for that. <meta title> doesn't exist, there's only <title>, which like <meta> goes in the <head> of the html, and is metadata, defining the name of the page as you noted. Again, by convention the name of the home page usually includes (often among other things) the name of the website itself, but there's no real standard. --IamNotU (talk) 10:03, 5 September 2019 (UTC)

I have no issue either with short version of domain (as currently auto-populated by a number of tools), stylized with capitals or even spaces as desired (cnn.com, CNN.com, The New York Times.com) or with some other stylized name perhaps matching the name of the publisher as they so often name their website after the company in the interest of branding (CNN). Today if we talk about a website, sometimes we use the TLD and sometimes not. An example is Overstock.com (to use a favorite out of Wikipedia history). I also find this way of describing things easier for a lot of the same people who have heartburn about the italics--Overstock.com is the name of the work or website, Overstock is its owning company (I presume; just an example). I also know some sites lend themselves through branding away from the TLD and toward the name of the work i.e. the big social media sites are Facebook and Twitter and rarely include the .com in discussion today. Sometimes of course we have the name of a journalistic entity like The New York Times for which zero people have heartburn italicizing even if it's the web resource which was accessed rather than a paper copy.

I had some commentary in the context of the italics RFC that would be worth reading as well.

I do agree we should beef up the description of the parameter for cite web/citation with website regardless. I think from a bare-bones, fill-in the parameter sense, it should say "you should at least have the domain and TLD" (couched in non-technical terms as desired). If the website has an obvious name, that is preferred but not required.

I was playing around with some "personal" websites yesterday for which I do not know if there is an easy answer, but I think those are sufficiently edge-case primary/non-independent sources that don't need a whole lot of thought in this context. --Izno (talk) 13:18, 5 September 2019 (UTC)

It is better for any guidance to match the way a verifier searches for the source. If someone tells me something was on the New York Times website, I will input "New York Times" on my favorite search engine. What comes up first, is most likely a promotional page. Under it though one sees "The New York Times - Breaking News, World News & Multimedia". This is the page's html <title>. It can be abbreviated to "The New York Times" when entered as the |website= without any semantic or cosmetic loss. If I search for "NFL", one of the top results is the actual website. The website's landing page's title is "NFL.com - Official Site of the National Football League" - that is also what the pertinent search result is. Again, what comes after the dash can be omitted. So I don't think we have to agonize much about which html property is best. Just use the website's title as it comes up on a real-world search. 72.43.99.138 (talk) 13:42, 5 September 2019 (UTC)

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

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

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

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

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

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

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

Ok, Jc3s5h, since you have strong opinions on your belief that a snippet of text available on the web can only be part of a larger entity, a web site, and not be a standalone source in and of itself, let me ask your opinion of how we should list an academic's personal single-page web site, say for sake of example (as it's been popular in certain circles recently) http://math.mit.edu/~drew/, whose current html-encoded title is "Life, the Universe, and Everything" and whose entire content is the text "(-80538738812075974)^3 + 80435758145817515^3 + 12602123297335631^3". We could reasonably cites its author as Andrew Sutherland and its publisher as the MIT Mathematics department. Neither the person nor the organization is a website (they are, respectively, a person and an academic department, neither of which is a website). We could reasonably cite the title of the page itself as "Life, the Universe, and Everything" as its html encodes, or plausibly instead call it "Andrew Sutherland's home page" or some such. But it is not one of the official pages of MIT as a whole (an organization with a large official site but one that neither provides a clear name for the whole site nor contains Sutherland's personal page) nor of the MIT mathematics department (for the same reasons). So what grouping of pages do you think constitutes the web site that this page belongs to, what name do you think that grouping of pages should have, and by what reasoning do you come up with that name? As for your expressed opinion that the hostname of the url can be used in the website field, the community has considered that before and roundly rejected it. The site field should be a human name, not a computer identifier. What is the point of repeating parts of the url multiple times? It doesn't help anyone find anything. It's completely redundant. And if it doesn't help find or identify the resource named in the citation, it has no reason to be listed there. —David Eppstein (talk) 20:48, 6 September 2019 (UTC)

The cite web template, in its present form, is only capable of representing a titled smaller work, which is part of a titled website. So for Professor Sutherland's page, I wouldn't use a citation template at all. I'd write something like

• Sutherland, Andrew. (n.d.). "[http://math.mit.edu/~drew/ Life, the Universe, and Everything]". Massachusetts Institute of Technology. Retrieved 6 September 2019.

which renders as

• Sutherland, Andrew. (n.d.). "Life, the Universe, and Everything". Massachusetts Institute of Technology. Retrieved 6 September 2019.

— Preceding unsigned comment added by Jc3s5h (talk • contribs)

If cite web is incapable of citing solitary web pages then it is broken. You seem to be praising that broken state, arguing that it is the only state it could be in, and (by extension) arguing that we should give up on the cite templates as unfit for purpose and unusable. I would like to think that there is still hope for continuing to use them, but this sort of dogmatism makes my hope weaker. The whole point of templates is to make things easier for human editors, but you and the other like-minded people here seem to want them to be as difficult and inflexible as possible. —David Eppstein (talk) 06:53, 7 September 2019 (UTC)

With many templates, not just citation templates, the templates get changed from time to time because a consensus forms that they should be displayed differently. Also people find ways to extract data from the templates and use the information elsewhere, such as Wikidata extracting birth and death dates from {{Infobox person}}. But that only works if parameter values are assigned in accord with the template documentation. If people assign a value that conflicts with the defined purpose because they like how the result is rendered, it will come back to bite them in the ass when the template is revised, or when some bot imports false values into Wikidata.

I have no problem with making some appropriate changes to how the template works, such as adding parameters to specify how each of the title and website-title should be rendered, with the choices being italics, double quotes, or inside square brackets (the last being for a description created by the Wikipedia editor because the author or publisher did not give the piece of writing a title). Another logic change would be to treat the website title as the title in the absence of a title parameter. Jc3s5h (talk) 11:12, 7 September 2019 (UTC)

A point about Rotten Tomatoes. Yes, it should not be italicized — no footnoting other than Wikipedia's tries to italicize it — and as WP:CITESTYLE, which allows what it calls "common sense" exceptions, even states, "Wikipedia does not [emphasis added] have a single house style"; it notes that the widley Chicago Manual of Style, which does not italicize websites, may be used here.

However, because Fandango is the parent company, some editors insist on "website=Rotten Tomatoes| publisher= Fandango", italicizing RT. That to me is like saying Marvel Comics must be italicized since Disney is the parent company. --Tenebrae (talk) 15:52, 9 September 2019 (UTC)

WP:CITESTYLE, which allows what it calls "common sense" exceptions... The words 'common sense' appear exactly twice in Wikipedia:Citing sources, the home of WP:CITESTYLE. The first is the second positional parameter in a {{redirect}} template; the second is provided by {{subcat guideline}}, a boilerplate template used in a lot of guideline pages. The word 'exceptions' occurs three times (the singular form is not used) the first in {{subcat guideline}}, the second in Wikipedia:Citing sources#How to create the list of citations and the last in Wikipedia:Citing sources#How to place an inline citation using ref tags. None of these mention italic formatting. This is not, it seems to me, much of an argument against italic formatting of 'Rotten Tomatoes' or any other website name. Rotten Tomatoes is an electronic publication of the corporate entity Fandango Media (publisher).

Yes, Wikipedia does not have a single house style and does say that the [widely used] Chicago Manual of Style ... may be used here. But, here, on this page we are discussing cs1|2. CMOS has no control over cs1|2. If you want to use CMOS in articles that you author, or edit, you are absolutely free to do so, assuming that there is consensus to support you in your efforts.

—Trappist the monk (talk) 16:21, 9 September 2019 (UTC)

I'm glad we actually agree that Wikipedia:Citing sources, of which WP:CITESTYLE is a part, says in a box at the very top that, "This page documents an English Wikipedia content guideline. It is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, [emphasis added] and occasional exceptions may apply."

RE: "None of these mention italic formatting." I find this a bad-faith argument. We've established that the Chicago Manual of Style, for one, does not italicize website names. So when WP:CITESTYLE says the Chicago Manual of Style is allowed, that means website names need not be italicized. C'mon. You know that.

And I gather you're a programmer, but could you please state this in plain English: "[W]e are discussing cs1|2. CMOS has no control over cs1|2." I know that when I use "cite web" that "website=" does not allow non-italicizing, throwing "common sense exceptions" out the window.--Tenebrae (talk) 00:26, 10 September 2019 (UTC)

A bad-faith argument? Go back and reread what I wrote. When I said: None of these mention italic formatting, I was talking about the immediately preceding sentence where I pointed out that the words "common sense" and "exceptions" appeared only in {{subcat guideline}}, the {{redirect}} template, and two subsections of WP:CITE, to wit: Wikipedia:Citing sources#How to create the list of citations and Wikipedia:Citing sources#How to place an inline citation using ref tags. None of those places mention italics.

I think that [W]e are discussing cs1|2. CMOS has no control over cs1 is plain-speak. cs1|2 is not CMOS. They are different styles just as CMOS is not ALA and CMOS is not MLA and CMOS is not Bluebook. Because cs1|2 is not CMOS, the rules that apply to CMOS do not apply to cs1|2. In the past, CMOS may have influenced the development of cs1|2. Or not, I don't know; perhaps if you troll through the archives here and the various templates and modules you can learn if and where CMOS influence is felt.

—Trappist the monk (talk) 21:57, 10 September 2019 (UTC)

Irritating change to allowed values of mode parameter

Previously, both lowercase "cs" and uppercase "CS" were allowed in values of |mode=. Now the uppercase isn't recognized, generating many unnecessary errors. Please fix this. Peter coxhead (talk) 02:33, 5 September 2019 (UTC)

Peter coxhead, I attempted a few hours ago to fix all instances of upper-case "CS" in article and template space, using insource searches to locate the problem articles. Please link to a couple of articles that still have the problem, and I will continue the fixes. Thanks. – Jonesey95 (talk) 02:39, 5 September 2019 (UTC)

I think this is a decent search? --Izno (talk) 02:50, 5 September 2019 (UTC)

I used that search to scour all namespaces, and I found only a half-dozen article-space pages and a few talk-space pages and User pages. I carefully fixed some of the User pages and Talk pages after looking at the context of the templates, on the good-faith assumption that people want their meanings to be preserved even when template functionality changes. I left the remaining three pages alone where I could not be sure that changing the past would be a good thing. Peter coxhead, I changed two of your User-space pages; if that is an unwelcome intrusion, I apologize and will be happy to be reverted. – Jonesey95 (talk) 03:56, 5 September 2019 (UTC)

Two of the three remaining, I think could be changed without affecting the meaning of those examples. I think a clear error log is useful and the disgrace of changing archived content is probably forgivable. Help_talk:Citation_Style_1/Archive_7#Display_parameters:_do_we_need_them? is an interesting counter-example to that. It was in 2014 the test case to make sure that "|mode= is case insensitive". There's also the negative test to make sure "Invalid |mode=cs3".

As Coxhead hinted, I think removing that case insensitivity was not motivated. Even so, going as far as exposing this as an Error was unnecessary. If there was a wide consensus on it, the manual or bot-assisted search&replace could have been done before activating the error. And releasing this change at the same time as the "italics war" was hardly helping the discussion.

PS. There is a similar thread already as #"mode = CS1" raises warning, that focus on assisting the "cleaning up" activity. JAGulin (talk) 10:36, 5 September 2019 (UTC)

@Jonesey95: given that the change had been made, I'm happy with all of your clean-up activities. But it remains an irritating change, that was not, so far as I can tell, discussed. I have several personal tools and templates that now need to be checked to prevent them causing errors. I see no need for the restriction, which is inconsistent with the way we normally use "CS1" and "CS2" in other contexts. Peter coxhead (talk) 15:51, 5 September 2019 (UTC)

I don't see it in the list of changes in the section above, but apparently there was a bug that was demonstrated in this discussion and fixed during the latest update. I was away from WP for the last few months, so I don't know the reason that the restriction was put in place, but I'm happy to tidy up the few hundred pages that are now out of compliance. I know how you feel about the scripts that you have worked so hard to maintain, though; I have AutoEd scripts that I use for gnome work, and they require continual care and feeding, just like any modern bit of software. – Jonesey95 (talk) 19:37, 5 September 2019 (UTC)

Format vs type

I'm now seeing errors about lacking urls when filling in the format field. I thought that was the right one to use for electronic versions like .azw or .epub. If those should be used in the type field instead, the documentation needs to clearly state that as neither are currently mentioned at all.--Sturmvogel 66 (talk) 19:11, 5 September 2019 (UTC)

See Template:Cite web#URL for instructions. – Jonesey95 (talk) 19:19, 5 September 2019 (UTC)

Why? Given that electronic books are books, first and foremost, why would that even be relevant? It seems very counter-intuitive.--Sturmvogel 66 (talk) 19:39, 5 September 2019 (UTC)

For books, see Template:Cite book#URL. The documentation is essentially the same. |format= is for URLs, as described in the documentation. The documentation under format says For media format, use type. The documentation for type says type: Provides additional information about the media type of the source. If you have suggestions for how the documentation could be improved, this page is a good place to make those suggestions. – Jonesey95 (talk) 20:10, 5 September 2019 (UTC)

That is the correct intent of format, but the format per the documentation has always been about the URL. If you do not have a URL, you should not have a |format= parameter. There has been previous discussion about changing the name to e.g. |url-format= or |url-file-format= to make that clear, but no-one has moved on that. --Izno (talk) 19:22, 5 September 2019 (UTC)

That would clear things up, but clarity should be added to the documentation regarding the proper place for electronic books.--Sturmvogel 66 (talk) 19:39, 5 September 2019 (UTC)

The format parameter is there to alert the user of a citation that there may be additional requirements in order to verify the wikitext. A common example is |format=pdf which displays as (pdf) after the source. This alerts the reader that s/he has to have Adobe document format functionality on their device, perhaps as a browser add-in. Another common use would be in situations where the source may be formatted in one of the picture formats. 24.105.132.254 (talk) 20:12, 5 September 2019 (UTC)

Then why would it be necessarily need to be linked to a url?--Sturmvogel 66 (talk) 21:06, 5 September 2019 (UTC)

Because you are providing a path to online verification. |format= refers to the digital file format. It is irrelevant when a digital means to verify the citation is not given. The media type that is referenced by |type= is the medium the source was accessed in: print, video, digital etc. Hope this is clearer. 72.43.99.138 (talk) 23:22, 5 September 2019 (UTC)

Cite tweet

I know it's already been pointed out elsewhere and the folks maintaining these templates are dealing with a lot right now, but {{cite tweet}} is still generating a "cite web requires website" error (not visible, but categorized). That's clearly not how that's supposed to work, but I don't know how to fix it. I was just working on David Akin where there is a tweet citation, if you want to see for yourself. Just one more requested bugfix for your attention, I'm sure it'll be repaired eventually. Ivanvector (^Talk/_Edits) 20:22, 5 September 2019 (UTC)

It'll go away at the same time that the {{cite web}} errors will go away, since {{cite tweet}} invokes {{cite web}}. Headbomb {t · c · p · b} 20:24, 5 September 2019 (UTC)

I realize that, the error message is already hidden unless you have the css hack to display the hidden errors. I mean that it seems to be a problem in the way that cite tweet calls cite web, in that cite tweet doesn't supply anything to the |website= parameter. And seemingly rightly so, as the output of cite tweet doesn't render anything in italics, and that seems to be the correct format based on sources like this and this and this. Should cite tweet use a different underlying template maybe? Ivanvector (^Talk/_Edits) 20:59, 5 September 2019 (UTC)

I suppose you could always hack something, but waiting should be enough to return things to the norm. Headbomb {t · c · p · b} 23:45, 6 September 2019 (UTC)

No suitable template for top level of a website

Suppose I want to cite the top level of a website. For purposes of this discussion, the thing I want to cite only exists in the form of a website, and the true nature of it is a website. It isn't a book, journal, newspaper, or anything but a website. For example, I want to make the claim "USAGov is the Official Guide to Government Information and Services" and I wish to cite https://www.usa.gov/. I'm citing the top level of the website, and the website is a large work, so I should cite it like this:

Cite web comparison

Wikitext	{{cite web|url=https://www.usa.gov/|website=USA.gov: The U.S. Government's Official Web Portal}}
Live	USA.gov: The U.S. Government's Official Web Portal https://www.usa.gov/. {{cite web}}: Missing or empty |title= (help)
Sandbox	USA.gov: The U.S. Government's Official Web Portal https://www.usa.gov/. {{cite web}}: Missing or empty |title= (help)

Since I have an extra level of error messages being shown (I forget how I set it) and there has been recent play with error display, I will state that when I look at the rendered citations, I see Missing or empty |title=

If I were citing a much smaller website, I would want to be able to use the same citation, but somehow indicate that the website title should be surrounded by double quotes rather than be in italics. Jc3s5h (talk) 20:32, 5 September 2019 (UTC)

I would instead cite this case (if indeed it is valid for a general fact) instead as "USA.gov: The U.S. Government's Official Web Portal". USAGov. because that fact will have been found on a specific page, not in/on the work in its entirety.

The part before the bar at the end is essentially the name of the main page. The part after the bar is the part that persists to other parts of the work, which is what is usually the name of the website as a whole.

Remember that you must provide a sufficient level of detail for someone else to identify where the fact resides which you are verifying. --Izno (talk) 21:17, 5 September 2019 (UTC)

Izno, In this case, "USAGov" is the publisher, not the website name. On many websites, the part after the bar in page titles is either the publisher or the website name, or they're both the same thing. Jc3s5h, see also § Omitting "website=" for simple, one page sites, above. "USA.gov: The U.S. Government's Official Web Portal" is the title of the home page, not the name of the website. The website name is "USA.gov", as explained at "About the Website USA.gov": "USA.gov is an interagency product administered by USAGov (formerly the Federal Citizen Information Center), a division of the U.S. General Services Administration's Technology Transformation Service." So, in the current incarnation of {{cite web}}, it's |website=USA.gov. The publisher would be USAGov, but since it's substantially the same as USA.gov, it should be omitted. For the page title, you can use |title=USA.gov: The U.S. Government's Official Web Portal.

To your last question about how to "somehow indicate that the website title should be surrounded by double quotes rather than be in italics", the answer is you can't, not with {{cite web}}. Apparently it's been decided that all website names will be in italics, though that might be up in the air at the moment, not sure - check the Admin Noticeboard... --IamNotU (talk) 22:34, 5 September 2019 (UTC)

I've been involved in that a discussion here at WP:AN, and the majority of editors there are in fact not in favor of the extremist position that all website names be in italics, even the World Health Organization and Sears.--Tenebrae (talk) 22:40, 5 September 2019 (UTC)

IamNotU, feel free to comment above at Help_talk:Citation_Style_1#Better_explanation_for_"website"_parameter_in_docs; I've laid out a comment there that already covers that to some/large degree. --Izno (talk) 00:08, 6 September 2019 (UTC)

Categories for doi-broken-date

[2] by Trappist the monk started adding month (when specified) to categories for pages with DOIs inactive: table.insert( z.error_categories, 'Pages with DOIs inactive as of ' .. inactive_year .. ' ' .. inactive_month); -- use inactive month in category name. For example, the page Template:Cite journal displays a {{cite journal}} example with doi-broken-date=2019-01-01. The module edit has moved the page from Category:Pages with DOIs inactive as of 2019 to Category:Pages with DOIs inactive as of 2019 January. Special:PrefixIndex/Category:Pages with DOIs inactive shows none of the monthly categories currently exist. Template:Cite journal#Examples claims another category name is added: If the doi link is broken, then use of doi-broken-date unlinks the doi value, indicates when the doi-problem was first noticed, and will also add the page to "Category:Pages with DOIs broken since YYYY". Special:PrefixIndex/Category:Pages with DOIs broken shows no such categories. I don't care how this is solved as long as articles stop showing red maintenance categories. One solution is to create the monthly categories with the current red names. Category:Pages with DOIs inactive as of 2019 August currently has 1175 members. PrimeHunter (talk) 15:35, 6 September 2019 (UTC)

The most straightforward fix would be to have a bot create the categories with {{broken doi explanation}}[[Category:Pages with inactive DOIs|year]][[Category:CS1 maintenance|D]], I believe. Jo-Jo Eumerus (talk, contributions) 15:53, 6 September 2019 (UTC)

That edit is the result of this discussion. Anyone can create those categories; it doesn't have to be me. I've done it for 2019 but this issue will show itself again in January 2020.

—Trappist the monk (talk) 16:12, 6 September 2019 (UTC)

Issue issues

Can someone tell me what has gone wrong here:

{{cite book |last=French |first=David |year=2003 |title=Invading Europe: The British Army and Its Preparations for the Normandy Campaign, 1942–44 |journal=Diplomacy and Statecraft |volume=14 |issue=2 |pp=271–294 |doi=10.1080/09592290412331308891 |issn=0959-2296 }}

gives:

French, David (2003). Invading Europe: The British Army and Its Preparations for the Normandy Campaign, 1942–44. Vol. 14. pp. 271–294. doi:10.1080/09592290412331308891. ISSN 0959-2296. {{cite book}}: |journal= ignored (help)

Where did the issue number go? It used to say 14(2). The reader needs the issue number to find it. Hawkeye7 (discuss) 22:48, 6 September 2019 (UTC)

You should be using {{cite journal}} to cite |journal=Diplomacy and Statecraft. {{cite book}} does not support |issue=

—Trappist the monk (talk) 22:52, 6 September 2019 (UTC)

D'oh! Hawkeye7 (discuss) 04:47, 7 September 2019 (UTC)

Trappist, why can't it allow "issue=" in case someone makes a mistake? Rather than people having to fight with templates and search for another one. Flexibility would be much appreciated. SarahSV ^(talk) 23:02, 6 September 2019 (UTC)

Because the cs1|2 templates create COinS metadata. {{cite book}} creates book-object metadata. Book-object metadata does not support issue. We do not control the metadata standard. If all you are writing is book and periodical citations you can use {{citation}} which will most-of-the-time get it right. If you want cs1 styling with that set |mode=cs1:

{{citation |last=French |first=David |year=2003 |title=Invading Europe: The British Army and Its Preparations for the Normandy Campaign, 1942–44 |journal=Diplomacy and Statecraft |volume=14 |issue=2 |pp=271–294 |doi=10.1080/09592290412331308891 |issn=0959-2296 |mode=cs1}}

French, David (2003). "Invading Europe: The British Army and Its Preparations for the Normandy Campaign, 1942–44". Diplomacy and Statecraft. 14 (2): 271–294. doi:10.1080/09592290412331308891. ISSN 0959-2296.

—Trappist the monk (talk) 23:14, 6 September 2019 (UTC)

If "issue=" isn't in the template people choose, they will simply leave out the issue number. That doesn't help the metadata aspect. What would be wonderful is, if someone adds "issue=" to cite book and saves or previews, for an error message to say (for a few seconds before disappearing): "Did you mean to use cite journal?" The problem with the templates is that they sometimes leave us baffled with no clear solution.

Trappist, I don't know whether you do this work purely as a volunteer. If you do, you should consider going to meta and asking the WMF for a project grant. They give out grants for all kinds of (sometimes puzzling) things. What you're doing here is core work that a huge percentage of editors rely on. SarahSV ^(talk) 23:37, 6 September 2019 (UTC)

I cannot even blame the generally unhelpful documentation for the OP's error. At some point, common sense should dictate that when you want to cite a journal, the template to use would likely be {{cite journal}}. No offense intended, but if one wants to use this citation system they should at least familiarize themselves with its components. Also, the error messaging described above is I'm afraid beyond the scope of this project. But even if it was, I don't think that the complexity of adding conditional error levels would justify the effort. 24.105.132.254 (talk) 15:26, 7 September 2019 (UTC)

The thing that might be done for this particular condition would be to emit an error message when a periodical parameter is used with a non-periodical template. Having been nearly drawn and quartered at WP:AN for presuming to require periodical parameters in periodical templates does not make me enthusiastic about prohibiting periodical parameters in non-periodical templates. Attempting to be helpful with Did you mean ... messaging as described would be complex and, I think, not really worth the effort. We have page preview so that editors can inspect their work before they hit the Publish changes button.

—Trappist the monk (talk) 19:11, 7 September 2019 (UTC)

In the new and improved doc, an additional distinction? "Universal" vs. "Template-specific" parameters perhaps. Corresponding to the treatment of the underlying module arguments, so that aliases are properly identified for the benefit of the "higher" level citation writers. It seems the current monolithic presentation of parameters is not enough. 72.89.161.42 (talk) 21:33, 7 September 2019 (UTC)

what cite template should be used now for govt docs such as NRHP nominations?

WikiProject NRHP has 50,000 or so citations using "cite web" to National Register of Historic Places (NRHP) nomination/registration documents, from the 1970s until now. These are not "news" items nor are they "periodicals" or "journals". It has seemed best to use "cite web". For ones hosted by the National Park Service supposedly in Washington D.C., we include "publisher=National Park Service". For the same document hosted by a state website, we would include "publisher=State of Arkansas" or whatever. These documents exist, published or not, somewhere, for every NRHP listing. (Addition: Well, sometimes the document used to justify NRHP listing is on a different state or local form.) Sometimes they are not available anywhere online (especially archeological site ones). Some states like Louisiana and Arkansas and New York have their own separate systems making these available, and make decisions differently than does the National Park Service about which documents to make available, or what versions of them. For a long time New York State provided archeological site ones which were not redacted to conceal location information, while the National Park Service is more likely to provide redacted versions, if they provide anything at all. It seems to me that it is reasonable to say the "publisher" is the government entity that is putting forth, on the internet, the specific document that is linked. I don't think saying "website=State of Arkansas" would make sense, because the state government is not a website. And these documents are sometimes available in quite scattered places, often not just in one coherent "website".

Given recent changes to the CS templates, and/or recent decisions about displaying italics or not and using "website=" and "publisher=", or whatever, I am now completely unclear on what Wikipedia citation experts want for us to do now. I personally don't care what shows in italics or not; I'd just like to do whatever makes sense and does not show display errors. Help! What are we supposed to do, going forward? --Doncram (talk) 23:11, 6 September 2019 (UTC)

Can you provide an example or three of these citations so that we all know what it is that you are talking about?

—Trappist the monk (talk) 23:17, 6 September 2019 (UTC)

@Doncram: what you need to do is exactly nothing save for waiting until Trappist the monk stops being dense, or that someone else with editing rights and LUA knowledge stops the nonsense going on with {{cite web}} and {{cite news}}. Your usage of the templates is most likely correct. Headbomb {t · c · p · b} 23:44, 6 September 2019 (UTC)

(ec) Sure:

1. Francis Rahrer House in Montana, has a fairly regular NRHP Registration document, available from the National Park Service:

2. Joliet Bridge, also in Montana, is documented in a "Montana Historical and Archeological Inventory" form, in lieu of an official national NRHP form, but nonetheless served up by the National Park Service:

3. Magnolia Petroleum Company Filling Station, in Arkansas, on a national NRHP form but available from (published by) the state, and not available from the national NRHP system.

4. Muskegon Historic District, in Michigan. This reference should include "publisher=National Archives" but happens not to, and maybe it should include a note about photos it includes. Michigan NRHP docs are not ever available from the National Park Service, but they are mostly available now from the National Archives and Records Administration.

More and more files from states or from the National Park Service are being added to the National Archives, but it is better to cite the Texas-state-published version which loads quickly, say, rather than the slow/big National Archives version. Sometimes there are different versions of NRHP documents for one historic site available at different places, e.g. including photos or not, or including copies of correspondence from during the nomination process, or including copies of earlier local registration documents preceding a new NRHP registration. Sometimes a draft version may be available first and used in Wikipedia, from a temporary "Announcements of new listings in February 2019" page of a state's historical society, which I think should be noted as the "publisher". Which may disappear, before or after a "final" version shows up in some supposedly permanent location.

References

These are all government documents supposedly kept permanently, forever documenting why each listing was done. Note that most of us use the "title=" field to spell out the type of form and then a colon and then the name of the specific historic site. In our practice the "work=" field is rarely used, but I think some editors have used that to state "National Register of Historic Places Inventory/Nomination" and just put the name of individual site in the "title=" field. Also I don't mind if it might take us a long time to edit, using a bot or manually, all our references over into any "better" citation format, if there is one. --Doncram (talk) 00:05, 7 September 2019 (UTC)

Oh, the 4th one above used template:citation rather than template:cite web.

Hmm, there does exist {{cite report}}, which i've never considered using. Its intro documentation says it is for government documents and mentions "title=", "url=", and "publisher=" fields without mentioning the problematic/difficult-for-me-to-understand "website=" field. So if we switched from "cite web" to "cite report" maybe we would not get the current display problems? But much further down in the documentation, it is mentioned that "website=" is an allowable field.

Lemme try those same four references, just changing to "cite report" from "cite web":

References

Okay, hey, there are no display errors currently! (is that because previous changes have been rolled back or because this is cite report now rather than cite web? hmm, now the previous ones using "cite web" show no problems, either) So WikiProject NRHP could conceivably change their 50,000 or so references to use "cite report", and get out of whatever are the current issues, perhaps? These references do each include display of the term "(Report)" which seems non-helpful, not exactly applicable. These docs are documentations of historicity, usually submitted voluntarily; it is maybe a stretch to call them "Reports", as if they are the results of a required or requested study/report on whatever. I wonder if that element of display can be turned off? When I have seen NRHP documents cited outside of Wikipedia, I have NEVER EVER seen '(Report)' randomly included. --Doncram (talk) 04:03, 7 September 2019 (UTC)

Partially rolled back. --Izno (talk) 04:11, 7 September 2019 (UTC)

Cite report oddity: please drop display of "(Report)"

Well, although the error displays are gone now in all versions, I am still open to the idea that the NRHP documents are fundamentally "reports", suitable for "cite report", and should not have been using "cite web". In fact sometimes I want to refer to one of these which is only available offline, and "cite web" then shows errors, i.e. if "url=" is blank. And whatever is the philosophical issue with "cite web" that makes some want to require a "website=" field, may really be valid, despite some rollback just done. Perhaps it is more correct to remove the NRHP docs from the "cite web" world. But, it remains that "cite report" inserts display of "(Report)" into the reference. I have NEVER EVER seen that done in any non-Wikipedia citation of government documents, so that seems just awkward and wrong, and I would like to remove it from "cite report". Else it sorta seems "cite report" cannot be used. Although I must confess i don't know how often it has been used in practice, or for what types of government documents it is used without editors' objections. This is the forum to discuss changes in {{cite report}} though, right? I hereby request the change of dropping default display of "(Report)" or at least being allowed to turn that off. --Doncram (talk) 05:49, 7 September 2019 (UTC)

Cite report defaults the |type= parameter to "Report". You can choose to set it to another value if you have a preferable one: {{cite report |title=ReportTitle |type=registration}} outputs ReportTitle (registration)..

As for the rest of your text, yes, if these are occasionally or even usually offline-only, it would be better to select one of the other {{cite}} templates. I thought {{cite document}} might be available, but that unfortunately redirects to {{cite journal}}. --Izno (talk) 05:59, 7 September 2019 (UTC)

{{cite report}} is supposed to render with the |type= preset to Report. You will also notice that the report title is not quoted. You can prevent the rendering of the Report annotation by setting |type=none.

—Trappist the monk (talk) 19:16, 7 September 2019 (UTC)

Wow, thank you very much, Izno and Trappist the monk. This probably should be used for NRHP docs, I am thinking. I wouldn't want to include "(Registration)" or any other word that way, given how I/we have been including the title of the form (which usually includes "Registration" or "Inventory-Nomination") in the title= field already. I note that the documentation at {{Cite report}} does not mention this "type=" usage at all. It uses the word "type" in several ways, including one mention which should probably wikilink to some detail about this type of type somewhere else, i.e. probably to {{para}} which where Trappist the Monk pipelinks to just now. And the documentation should be expanded a little to cover this, which maybe I can try to do, within Template:Cite report/doc.

Just testing now with "type=none" for the four NRHP doc examples.

References

In preview mode, I can see that seems to work fine. Okay, good, I think I am convinced that using "cite report" is better for NRHP documents, and I will advocate for switchover (though that could take a long time, perhaps years). It seems better because it is not asserting/implying the source is a website, with all that entails, when in fact it is just a single document that happens to be available on the internet, at one or more URLs. This should take NRHP docs away from the concerns about what "cite web" should display for real websites. And this allows uniform treatment of many NRHP docs which are available only off-line, too, for which "url=" will be blank. Maybe NRHP editors can be involved constructively in developing "cite report" going forward, e.g. perhaps for explicit presentation of multiple urls with same or slightly varying versions of a document, providing backup when the National Park Service's website or other sources are down, which happens often. Thank you all for your assistance! (Do any NRHP editors have concerns? I will ask at wt:NRHP.) --Doncram (talk) 22:47, 7 September 2019 (UTC)

Protected edit request on 7 September 2019

For Module:Citation/CS1:

In Special:Diff/914376409, Trappist the monk updated the module and, in doing so, also wrapped the output in the `cs1-sandbox` class by adding , wrapper=".cs1-sandbox" to line 3885. I think this was a mistake during the update (ping @Trappist the monk just in case). Accordingly, please replace

return table.concat ({citation0( config, args), frame:extensionTag ('templatestyles', '', {src=styles, wrapper=".cs1-sandbox"})});

with

return table.concat ({citation0( config, args), frame:extensionTag ('templatestyles', '', {src=styles})});

Thanks, --DannyS712 (talk) 03:34, 7 September 2019 (UTC)

 Done Izno (talk) 03:40, 7 September 2019 (UTC)

So, about those required parameters...

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

We need to discuss what the fix is going forward.

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

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

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

I had at least two ideas:

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

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

It is clear from the ANI consensus that forcing No, no it's not. You don't get to establish a false premise as an end-run around the consensus established at the proper location and place (above) on that point. The only real consensus from a content/style POV that discussion indicates is that people don't like errors showing up in their articles (whether deserved or not). --Izno (talk) 04:06, 7 September 2019 (UTC)

The italics thing is a red herring, and periodicals are not required by any standards. If there's a periodical, or a work, emit that metadata. If there's a publisher, emit that metadata. Neither are required, because many online things are neither part of a work, of a periodical, nor necessarily have a publisher. Headbomb {t · c · p · b} 06:23, 7 September 2019 (UTC)

I disagree to a point, that the italics aspect (more specifically the presumption that WP has in practice treated cite web's as periodical citations by default) was a major point of contention that was not part of any of the discussion into the Sept 2 changes. (Making "website" italic was discussed in the RFC). Trappist stated several times at ANI that they thought, if we were citing a report from the WHO, it should appear as the italicized |website= and not as |publisher=, which was a point of contention in the changes (not just the error message issue). Clearly there was a disconnect between those maintaining cs1 and those using cs1 for how this should apply, and - if there is a need to fill metadata - that requires figuring out how to normalize the templates. Yes, the status quo is "fine" but there sounded like there were core technical reasons to make the change for metadata filling. --Masem (t) 15:42, 7 September 2019 (UTC)

My opinion has not changed: I believe that World Health Organization is the eponymous publication of the corporate entity (publisher) World health Organization. It would seem that WHO agrees. If you look in the source for Female Genital Mutilation (the page used as an example at the WP:AN discussion) you will find this: \"SiteName\":\"World Health Organization\".

—Trappist the monk (talk) 19:46, 7 September 2019 (UTC)

A World Health Organization report is a government-type document (which is fixed, and may be available as a PDF or in HTML at a given URL, but which is still a report if it is in hard copy), right? Then {{cite report}} should be used instead! Would switching that over take care of a big chunk of the ANI debate? --Doncram (talk) 02:18, 8 September 2019 (UTC)

Masem You appear to be assuming that, when a cite web has a publisher but no website, that it can only have been done that way to avoid the italics that using website would create. That assumption is wrong and an extreme failure of WP:AGF. It is completely legitimate to use publisher= for a cite web, listing the name of an organization that published the website. It would in many cases be incorrect to assume that field to merely be a workaround for the website italics. For instance, if I were to cite "Help talk:Citation Style 1" with a publisher of "The Wikimedia Foundation", it would be grossly incorrect to think that I really meant that the website on which I found Help talk:Citation Style 1 had "The Wikimedia Foundation" as the name of its web site. (In this example, the web site is Wikipedia, not Wikimedia.) You also seem to be reading the consensus of the AN (not ANI) discussion completely backwards: It is clear that most of the discussants don't give a fuck about italic vs non-italic website name formatting, and just want their perfectly valid and non-erroneous web-page-but-no-website citations to render without complaints. —David Eppstein (talk) 06:45, 7 September 2019 (UTC)

There is absolutely no need for {{cite web}} or {{cite news}} to require a publisher. It may be required in some cases (e.g. The Eastern Daily Press newspaper is published by Archant Media Ltd). {{cite web}} does require an |url=, whereas it is an optional parameter in {{cite news}}. That is how is should be. There is no need to change it. Neither requires a mandatory|periodical= field. Mjroots (talk) 08:04, 7 September 2019 (UTC)

Pretty sure that this discussion is not about requiring |publisher= as that was not the issue at WP:AN. |publisher= is optional and allowed in all cs1|2 templates except the preprint templates {{cite arxiv}}, etc.

—Trappist the monk (talk) 19:46, 7 September 2019 (UTC)

Pretty sure that it is, at least in part, because that was one of the causes of the error messages. It really messed up a load of articles before the category was hidden. Mjroots (talk) 06:00, 8 September 2019 (UTC)

That is just not true. |publisher= has never been a required parameter. There is / was no error message.

The requirements imposed by {{cite news}} and {{cite web}} were for some sort of periodical parameter. Those error messages were:

The presence or absence of |publisher= played no part in the determination to display these two error messages. During the WP:AN discussion, it was these error messages that were hidden, not the category (Category:CS1 errors: missing periodical)

—Trappist the monk (talk) 09:21, 8 September 2019 (UTC)

@Masem:, would you please state what metadata is being emitted, and provide links to the standard that defines the metadata? Jc3s5h (talk) 16:33, 7 September 2019 (UTC)

My understanding is the TemplateData stuff at the bottom of the documentation for {{citation}} ( eg Template:Citation#TemplateData ) --Masem (t) 16:45, 7 September 2019 (UTC)

I think the templatedata is for the visual editor. Only a few of those parameters have COinS metadata. The {{cite web}} ones are listed at Template:Cite_web#COinS.   Jts1882 | talk  17:00, 7 September 2019 (UTC)

TemplateData is a poorly conceived blend of program-control and pseudo documentation. Except that it exists on cs1|2 template doc pages to support that abomination that is ve, cs1|2 has nothing, absolutely nothing to do with TemplateData. If you think that I have strong opinions about those things, you would be right.

For the metadata standard, see Module talk:Citation/CS1/COinS where there are links to the documentation that I have been able to find.

—Trappist the monk (talk) 19:46, 7 September 2019 (UTC)

A right proper opinion. ♦ J. Johnson (JJ) (talk) 20:07, 7 September 2019 (UTC)

Speaking anecdotally, but I sometimes use |publisher= in lieu of |website= only because it strikes me as more useful. I have never cared about whether it produces italics or not and I don't think that is the main problem here. Jo-Jo Eumerus (talk, contributions) 08:44, 8 September 2019 (UTC)

I'd probably ask the question, "Should |website= be a) deprecated, b) contain the hosting website and be mandatory (i.e even if |publisher= is present), c) contain the hosting website and be supplantable with |publisher=? And if c) is implemented, what kind of information should go into |publisher= and what kind of information goes into |website=?" Or something else. Jo-Jo Eumerus (talk, contributions) 08:44, 8 September 2019 (UTC)

Either deprecated (the simplest solution given it's so problematic) or made flexible so that non-periodical websites can be non-italicized. Despite what some have suggested, Wikipedia MOS has no requirement that website names be italicized. Yet one editor with programming skill makes the extremist argument that everything online — even organizations like the World Health Organization or Sears — be treated as periodicals and italicized. That is unlike any footnoting I've ever seen and contrary to things like the very widely used Chicago Manual of Style. There's no reason for Wikipedia to adopt an eccentricity.--Tenebrae (talk) 14:40, 9 September 2019 (UTC)

That would be me (I am not Voldemort, my name may be spoken).

MOS does not apply to citations. If it did, then en.wiki's own WP:CITESTYLE would be invalid. cs1|2, like it or not, has a style that has developed organically to suit en.wiki's needs. Certainly cs1|2 have been influenced by CMOS, APA, MLA, and who knows what else but, cs1|2 is none of these styles. Yep, World Health Organization and Sears are eponymous electronic publications (websites) of the corporate entities that are their publishers. As the eponymous name, or title, if you will, these names are italicized.

—Trappist the monk (talk) 15:19, 9 September 2019 (UTC)

I just find it remarkable that you seem to be saying WP:CITESTYLE does not apply to citations.

WP:CITESTYLE specifically says we can use Chicago Manual of Style, which does not italicize websites. But your programming for our citation styles does not allow this. Your citation formats essentially say we're forbidden to use Chicago Manual of Style.

FYI, I phrased it as "one editor with programming skill" so as not to personalize my argument. The salient point isn't who, but the fact that some editors can program, others cannot, and that distinction seems to be playing out.--Tenebrae (talk) 21:39, 9 September 2019 (UTC)

I wrote MOS does not apply to citations (emphasis added). MOS may not, on the one hand, permit any consistent citation style (WP:CITESTYLE) and then on another hand dictate how that citation style must be used. This, I think, is the point you are trying to make at Wikipedia talk:Citing sources § RfC appears to contradict MOS here. cs1|2, like it or not, are styles (after all they are named Citation Style 1 and Citation Style 2).

Yes, you can use CMOS, or APA, or MLA, or even Bob's Special Citation Style++ as long as you are consistent in the use of it within an article. None of these styles are cs1|2. Two or three years ago I tried an experiment that would have used |mode=mla to render a few ({{cite book}}, {{cite journal}}, and one or two others) in MLA format. The experiment 'worked' but the code to make it work was such a tangle that it would have made maintenance of the code base worse than it already is. The experiment was backed out and I hope will never be repeated.

—Trappist the monk (talk) 23:29, 9 September 2019 (UTC)

Trappist the monk, re: "Yep, World Health Organization and Sears are eponymous electronic publications (websites) of the corporate entities that are their publishers", that would be a style error. The onus is on you at this point to produce a reputable style guide that supports you. The Supreme Court of the United States is not the name or title of this website. SarahSV ^(talk) 22:33, 9 September 2019 (UTC)

What is a style error? According to whom?

Tell me why 'Supreme Court of the United States' is not the name of the court's website. Right there at the top of the page you linked (in the position that would be the masthead of a newspaper or a magazine or a journal were we looking at a paper copy and where those publications place their names) it says, in large white letters over a blue-gray background: 'Supreme Court of the United States' and this appears to be placed at the top of every html page at the site. Similarly, in the 'masthead' on every html page at https://www.who.int, in large blue text over a white background: 'World Health Organization'. Both look like names to me; yeah, the names are also the names of the organizations so eponymous electronic publications of their individual publishers.

cs1|2 (I keep repeating this, why?) is not any of the reputable style [guides] mentioned here and at WP:CITESTYLE. Certainly it was influenced by the reputable style [guides] but does not adhere to any particular one or group of them. Website titles have been italicized by {{cite web}} since its inception (15 years ago).

—Trappist the monk (talk) 23:29, 9 September 2019 (UTC)

Because the website is supremecourt.gov and who.int, and 'Supreme Court of the United States' and 'World Health Organization' are their publishers. Headbomb {t · c · p · b} 23:36, 9 September 2019 (UTC)

Trappist, the problem is that you, personally, are inventing new style rules, where (a) there's no need; (b) there's no consensus; and (c) the new rules show a misunderstanding of the concept title. You could also say "let's not ever capitalize letters in book titles, including the first letter", or "let's always italicize authors' names". Those would be style errors too, according to everyone. Similarly, Supreme Court of the United States is not a title.

The thing you're grappling with is that most websites don't have names, so there is no title, i.e. there is nothing that needs to be italicized. You disagree with that: you believe they all ought to have names. But as a matter of fact, they don't. Their owners did not name them. In those cases, and that is most cases, we name the publisher. SarahSV ^(talk) 23:46, 9 September 2019 (UTC)

You wrote this declarative sentence: The Supreme Court of the United States is not the name or title of this website. I asked you to tell me why that name is not the name of the court's website. You have not answered that question but instead, concocted speculative 'rules' about title capitalization and author-name font as examples of style errors. Then you wrote: Similarly, Supreme Court of the United States is not a title. Similar to what? How do your concocted rule examples tell me why Supreme Court of the United States is not the name of the court's website?

If I have a misunderstanding of the concept title, write something that will give me that understanding. Simply making declarative statements that Supreme Court of the United States (or World Health Organization) is not a title does not help anyone to understand why you are so certain that they are not titles.

—Trappist the monk (talk) 17:57, 10 September 2019 (UTC)

Because nobody refers to supremecourt.gov as "Supreme Court of the United States", or by any other title. It's "the Supreme Court's website", unnamed, untitled. In the below examples, green text signifies quotes from the sources provided, and not quotes from TTM.

• New York Times: announcing that the Supreme Court’s website would start posting briefs
• US News: a separate statement posted on the Supreme Court's website
• Fox News: posted on the Supreme Court's website in the early afternoon
• Forbes: The Court’s opinion is available on its website

Have you any counter examples? – Levivich 18:13, 10 September 2019 (UTC)

So you are suggesting that there is a formality criterion now? A website title is only a title when it can be used formally or informally in everyday journalism-speak? That a 'proper' website title would be used in preference to allusions or references to the entity's website ('its website', 'the <entity's> website'). Really?

—Trappist the monk (talk) 22:34, 10 September 2019 (UTC)

Concur with SarahSV. This is seeming more and more like one editor's crusade, and italicizing all website names is neither required by WP:CITESTYLE nor is it mainstream. For example, see the APA, Harvard and MLA examples here, none of which italicize the website name. --Tenebrae (talk) 00:15, 10 September 2019 (UTC)

All websites must have "names", even when these "names" are not human-friendly. Please don't repeat stuff that just isn't so. The bottom line is that citations have their own style which is related to their utility. Don't try to mix the two, citations are not about prose, and they don't concern themselves with aesthetics. They are not there to make an article pretty, they are there to make it relevant. Because "SaraSV" or "Tenebrrae" or my IP mean exactly nothing otherwise. They can be standardized for the benefit of editors, but they must be presented from the POV of their users. If you believe that this view of citations is limiting, by all means use your own presentation. And let others use the tools that suit them. 108.182.15.109 (talk) 12:42, 10 September 2019 (UTC)

Just a reminder: There was an RfC here on this page (still recorded above) that closed about two weeks ago that concluded (at 15:49, 26 August 2019 (UTC)) that "an overall consensus exists here that names of websites in citations/references should be italicized". The RfC was widely advertised (at Help talk:Citation Style 2, Template talk:Citation, Wikipedia talk:Citing sources, Wikipedia talk:Citation templates, Wikipedia talk:Manual of Style, Wikipedia:Village pump (policy) and with a long-open Administrator Noticeboard request for closure. The RfC was open for more than a full month before it was concluded. The editor in question who was not named did not initiate that RfC, and did not close it, and as far as I have noticed after a quick look, did not express an opinion in it. I therefore don't see a one-editor crusade here. —BarrelProof (talk) 16:30, 10 September 2019 (UTC)

Yes, but that RfC didn't say anything about making |website= or |newspaper= required parameters. One possible outcome, in line with the RfC, is that |website= is either in italics or blank. It's the "not blank" thing that seems to be one editor's thing, in my view, not the italics thing. – Levivich 16:58, 10 September 2019 (UTC)

OK, but the comment that I replied to was complaining about a "one editor's crusade" for "italicizing all website names". That initiative was not coming from one editor. And I think it is arguable that the help guidance already said that the "website"/"work" parameter was more necessary and fundamental to citations than the "publisher" parameter, and that a lot of people seem to have been using "publisher" and leaving the "work" parameter empty to avoid italics. —BarrelProof (talk) 17:23, 10 September 2019 (UTC)

Are you saying the RfC close now means the Chicago Manual of Style — which does not italicize websites in footnoting — is now no longer ever allowed for citations? I ask you to clarify. --Tenebrae (talk) 18:54, 10 September 2019 (UTC)

No, I'm not. I think the RfC applies when the Wikipedia CS1 citation style and its templates are used but not when CMOS citation style is used. —BarrelProof (talk) 19:57, 10 September 2019 (UTC)

OK. Whew! I think we have common ground ... because I have run across one editor who believes that the RfC here means "There was already an RFC about this, and it was decided to italicize websites. That can not be overriden...." (Also, when I went to WP:CMOS I got WikiProject Comics, and when I went to CMOS I got a page for complementary metal–oxide–semiconductor. Can you point me to the page for CMOS citation style?)

So this is everyone's understanding? That WP:CITESTYLE allows us to use Chicago Manual of Style and we're free to, but just not with the "cite web" template? --Tenebrae (talk) 20:45, 10 September 2019 (UTC)

My understanding is that the RfC implicitly only applies to the Wikipedia CS1|2 styles (and their associated templates) and that there is no plan to change WP:CITESTYLE as a result of it. As the authority on the CMOS/Chicago style, WP:CITESTYLE refers to The Chicago Manual of Style and that article refers to some printed books and a website at https://www.chicagomanualofstyle.org/. —BarrelProof (talk) 22:26, 10 September 2019 (UTC)

This is drifting a little off-topic, but I noticed something at https://www.chicagomanualofstyle.org/. I hope it is generally accepted that Wikipedia MOS guidance on typographical conformity applies to the formatting of titles that are quoted in citations (MOS:QUOTE, MOS:CONFORM, MOS:DASH, MOS:INOROUT, MOS:ITALPUNCT), and that the spirit of this aspect does not vary with the choice of citation style. —BarrelProof (talk) 23:12, 10 September 2019 (UTC)

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

&rft.atitle=Isolation of a common receptor for coxsackie B

A title of a journal article

&rft.jtitle=Science

A title of a journal

&rft.btitle=Professional XML Meta Data

A book title

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

All cs1|2 templates emit metadata. Because the metadata standard does not directly support web citation objects, and because {{cite web}} renders stylistically like a journal citation, we use the COinS journal object with rft.genre set to unknown. For completeness:

rft.genre=article – {{cite journal}}, {{cite magazine}}, {{cite news}}

rft.genre=conference – {{cite conference}} when a periodical parameter is set

rft.genre=preprint – {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, {{cite ssrn}}

—Trappist the monk (talk) 22:12, 10 September 2019 (UTC)

It seems to me that styling the citation for a non-periodical is not as serious as emitting metadata that declares the non-periodical is a periodical. Readers tend to be more flexible than software. Jc3s5h (talk) 01:45, 11 September 2019 (UTC)

Review of current release process and suggestion of improvements

The recent discussion is a manifestation of the reaction to an enWp-wide impact of a change in this module. Trying to make a summary, the public reaction were basically triggered by these:

• The release notes didn't cover all changes introduced.
• Some changes were not presented with enough impact analysis.
  • What may have been intended or understood as catching an obvious error turned out to be of wide-spread impact and high visibility.
• Some changes were based on RfC/consensus that were later seen as misinterpreted or misused.
• Due to this, when introduced the change was perceived as "out of the blue" and "agenda-driven".

Looking back to learn from this event is not so much about the exact conditions of this event, but what can be made to minimized the risk of similar protests again.

@Trappist the monk: This may not be the most urgent action just now, but it is important to get your view of what lead to the situation. Please address it when time permits.

@Izno: I'm starting this topic as you said you considered in AN. Please help moderate it and invite relevant participants. JAGulin (talk) 11:50, 7 September 2019 (UTC)

Let me add, that the concern about changes in "cite web" was widespread perhaps in part because of inappropriate use of "cite web", which probably should be about sources that are real websites. A sensible change for treating website sources causes errors for sources that are not properly websites, but are using "cite web" anyhow. See #what cite template should be used now for govt docs such as NRHP nominations? (a discussion section currently located above on this page), where Izno and Trappist the monk are helpful, and where I come to conclusion that all 50,000 plus NRHP documents cited in Wikipedia should be taken out of the "cite web" domain, and moved over to more proper "cite report" usage (appropriate for government documents). Maybe other big chunks of current "cite web" usage should be moved out, too, such as World Health Organization reports. --Doncram (talk) 23:14, 7 September 2019 (UTC) 02:20, 8 September 2019 (UTC)

Doncram, there's often no need to specify "website=" in {{cite web}}. Supreme Court of the United States is not the name of a creative work (in this case a website) in {{cite web |title=About the Court |url=https://www.supremecourt.gov/about/about.aspx |publisher=Supreme Court of the United States}} We could add "supremecourt.gov", but it's superfluous and italicizing it looks odd. Most websites don't have names, i.e. there is no title to italicize. That seems to be the issue some template editors are struggling with. SarahSV ^(talk) 01:43, 9 September 2019 (UTC)

This template editor is not struggling. Supreme Court of the United States is the eponymous electronic publication (website) of the government entity that is Supreme Court of the United States, the publisher. It is, really, just that simple.

creative work? What does that really mean? Whatever it is, it is, I think, a poorly chosen term that, at best, is wholly subjective.

—Trappist the monk (talk) 14:57, 9 September 2019 (UTC)

Saying a website is a publication is like saying a library is a publication. – Levivich 15:10, 9 September 2019 (UTC)

Really? That is a stretch. How do you figure?

There are online locations, archive.org for one, that hold facsimiles of whole books. Were you citing On the Origin of Species at archive.org, you wouldn't use {{cite web}} and |website=. Instead, you would use {{cite book}} and |via=Internet Archive. archive.org, in this case, could be considered to be like a library. Regular websites like those published by World Health Organization, Supreme Court of the United States, Sears, corporate and governmental organizations recently mentioned, are not like libraries.

—Trappist the monk (talk) 15:39, 9 September 2019 (UTC)

Is Google the eponymous name of a publication (google.com) published by Google? If so, how do you determine which edition of the publication you're citing, since this "publication" is updated in real-time? Suppose I want to cite to a card in my library's card catalog. Is the card catalog at Anytown Public Library a publication called Anytown Public Library or Anytown Public Library Card Catalog? Or is it "Card catalog, Anytown Public Library"? Suppose I cite to Episode 1 of the YouTube channel PewDiePie. Is PewDiePie the publication, or is it YouTube? And if PDP is the publication, then what does that make YouTube? The publication's publication? Unnamed != eponymous; to say otherwise is to invent a rule. To say that the same website is sometimes a publication with a name (PewDiePie), and sometimes an eponymous publication (YouTube, when it's, say, the YouTube About Us page), is also just inventing a rule. If YouTube.com is not the publication YouTube when I'm citing to YouTube.com/PewDiePie, then it's also not the publication YouTube when I'm citing YouTube.com/AboutUs. Unless the publication changes its name depending on what part of the publication you're reading? – Levivich 16:06, 9 September 2019 (UTC)

If you mean citing Google search results that are updated in real-time, what would be the purpose of citing the results if the results can change moment to moment? Still, I'll bite. You might archive a snapshot of the Google search results, give them some sort of title, perhaps the search string, and set |website=Google.

cs1|2 is a general purpose citation system with some specialized templates. There isn't a cs1 template to cite the card in your local library's card catalog. You'll have to cite that manually.

This whole discussion is about |website= in {{cite web}}. Citing a PewDiePie episode or any other AV media is best done with the appropriate templates ({{cite episode}}, {{cite AV media}}, {{cite serial}}) which, not being {{cite web}}, are out of scope here. If you want to cite something on the YouTube/About page with {{cite web}} then: |website=YouTube.

—Trappist the monk (talk) 17:05, 9 September 2019 (UTC)

If YouTube.com is not the publication YouTube when I'm citing to YouTube.com/PewDiePie [with {{cite episode}}], then it's also not the publication YouTube when I'm citing YouTube.com/AboutUs [with {{cite web}}], because the website YouTube.com either is, or is not, a publication. It can't be a publication when you cite one of its pages (/About Us), but not a publication when you cite a different page (/PewDiePie). – Levivich 17:11, 9 September 2019 (UTC)

Please do not put words into my mouth that I have not spoken. Your use of {{tq}} (Talk quote inline) implies that all of the green text in the first sentence of your post originates with me. It does not. Please don't do that again.

Earlier I provided the example of a facsimile of On the Origin of Species at archive.org. Here is one such facsimile. Clearly, the publisher is D. Appleton and Company, not archive.org. archive.org is the deliverer so for these kinds of citations, |via=Internet Archive in {{cite book}}. If you were citing what archive.org has to say about the Political TV Ad Archive on its projects page, then |website=Internet Archive in {{cite web}}. So too with PewDiePie (author / publisher) and YouTube (deliverer) using an appropriate cs1 template; YouTube/About with {{cite web}} and |website=YouTube.

—Trappist the monk (talk) 18:13, 9 September 2019 (UTC)

I think this argument inadvertently shows the inherent inconsistency of treating all websites as "electronic publications," which is term Trappist the monk did use. The very same entity being italicized in one footnote but not in another footnote is an eccentricity I've never seen followed in any other footnoting style — in which something either is or isn't a publication. YouTube, the entity, doesn't magically change back and forth. --Tenebrae (talk) 18:22, 9 September 2019 (UTC)

For those platforms like archive.org that host both their own and others' content, how you use the name (in this case 'Internet Archive') identifies the role of the host. When the publication is their own content, then |website=Internet Archive (italicized); when hosting content belonging to someone else (a hosted publisher's publication) the |via=Internet Archive (not italicized). Two adjacent citations rendering Internet Archive differently? You can see at a glance the role played by the host.

—Trappist the monk (talk) 22:35, 9 September 2019 (UTC)

That is an eccentric citation style I don't believe is used anywhere outside Wikipedia. And one can see the role played simply by whether there is the "via=" parameter, so we don't need to use eccentric citations.--Tenebrae (talk) 23:11, 9 September 2019 (UTC)

Seeking advice

Can anyone advise how I can write this with {{cite book}}?

Stouck, David (1993). "Introduction", in Willa Cather and Georgine Milmine. The Life of Mary Baker G. Eddy and the History of Christian Science. Lincoln: University of Nebraska Press, p. xvii.

This is where Cather and Milmine are the book's authors, not the editors. SarahSV ^(talk) 01:57, 8 September 2019 (UTC)

Not quite the same, but

{{cite book|last1=Cather|first1=Willa|last2=Milmine|first2=Georgine|title=The Life of Mary Baker G. Eddy and the History of Christian Science|location=Lincoln|publisher=University of Nebraska Press|year=1993|page=xvii|contribution=Introduction|contribution-url=https://books.google.com/books?id=bfUVPgvoNCkC&pg=PTxv|contributor-first=David|contributor-last=Stouch|contributor-link=David Stouck}}

produces

Stouch, David (1993). Introduction. The Life of Mary Baker G. Eddy and the History of Christian Science. By Cather, Willa; Milmine, Georgine. Lincoln: University of Nebraska Press. p. xvii.

—David Eppstein (talk) 02:01, 8 September 2019 (UTC)

Hi David, thanks for that. The only problem is that it introduces a different citation style. I don't know how difficult it would be to edit the template so that using "contributor=" doesn't move the authors to the end. SarahSV ^(talk) 04:59, 8 September 2019 (UTC)

??? The author of the item you cite is in the correct place, right at the beginning, followed by the next important thing, the item itself. As one reads the citation, it can be seen that this item is not the actual source, i.e. in order to easily find it, one has to look for something else. The actual source is emphasized for clarity. And the source's author ("by") is right after. David Eppstein's rendering is the correct one. 72.43.99.138 (talk) 13:37, 8 September 2019 (UTC)

The rearranged order and flagging with "By" were originally introduced to mark the difference between an authored book and edited one, but are no longer necessary as editors are now marked with (ed.)/(eds.). I would also suggest that "Introduction" should be removed from the list of special contributions that are dequoted, yielding a more consistent layout:

Stouck, David (1993). "Introduction". In Cather, Willa; Milmine, Georgine. The Life of Mary Baker G. Eddy and the History of Christian Science. Lincoln: University of Nebraska Press. p. xvii.

which is closer to the format you wanted. Kanguole 09:04, 8 September 2019 (UTC)

The rearranged order and flagging with "By" were originally introduced to mark the difference between an authored book and edited one, but are no longer necessary as editors are now marked with (ed.)/(eds.). This is not so. There are obvious semantic differences between contributions in an authored book vs an edited one. The rationale for adding the contributor params in the templates was laid out in several posts through the years. One impetus was the relative obscurity and complexity of {{harvc}}. The reason Introduction is not in quotes is because it is considered a standard part of a book (see front matter and back matter). The module strips the quotes. Similarly, one would not quote "Table of Contents", or "Index". However, if the Introduction was titled, then it is properly quoted, as in "Introduction: My Wonderful Introduction". 72.43.99.138 (talk) 13:50, 8 September 2019 (UTC)

Kanguole, yes, that's roughly what I'm looking for. How do we make that happen? SarahSV ^(talk) 00:47, 9 September 2019 (UTC)

72.43.99.138, we should be able to do with the templates what we do manually. We often need the kind of citation I've written above, and since starting to use templates (relatively recently), I've had to do it manually. An author might write a chapter in a book otherwise authored by others, where the latter are named as authors not editors. Or one of the main authors might write a chapter on her own that needs to be highlighted for some reason.

As for "Introduction" not being in quotes, there's no difference between that and a chapter title. In the introduction above, David Stouck explains over 14 pages why Willa Cather is named as an author, whereas in earlier editions she wasn't. It's an essay or chapter with the title "Introduction". SarahSV ^(talk) 00:47, 9 September 2019 (UTC)

we should be able to do with the templates what we do manually. No. By their very nature templates are / can / will never be as flexible as manual, free-form-text citations.

—Trappist the monk (talk) 10:19, 9 September 2019 (UTC)

SarahSV: changing the formatting would need an RFC, but might be possible now that (ed.)/(eds.) has been added.

"Introduction" is something of a borderline case. The MLA style, for example, treats it similarly to "Preface", "Foreword" and "Afterword" and presents it unquoted in contrast to descriptive chapter names. Kanguole 10:46, 9 September 2019 (UTC)

Any element that doesn't have a title by definition cannot be in quotation marks, because there is nothing to quote. In contrast, when one cites "Preface: A really good preface" one literally quotes from the work. The Preface in that work is named (a name that may or may not include the word "Preface") and, if it is the element cited, it should be presented accordingly. Otherwise, might as well quote page numbers too. 72.43.99.130 (talk) 14:47, 9 September 2019 (UTC)

TemplateData and IABot and website param

IABot (User:InternetArchiveBot / @Cyberpower678:) reads and respects TemplateData specifically Template:Cite_web/doc#TemplateData. Recently it was changed that |website= is "required". As a result IABot automatically adds an empty |website= to every template it touches. Example. It also adds |website= when a |newspaper= already exists thus creating a duplication. Example. I'm not sure what to do as there are multiple issues but want to bring it to the attention what is occurring. -- GreenC 13:44, 8 September 2019 (UTC)

Your first example is difficult, because it may also involve |publisher=. The second is easier. If {{cite news}} is used, use |newspaper=. If {{cite web}} is used, use |website=. Both stand for the same thing (the work), therefore the module ignores additional instances of the same argument. 72.43.99.138 (talk) 14:15, 8 September 2019 (UTC)

|website= is no longer required per the AN thread closure. Does that resolve this issue, GC? – Levivich 14:27, 8 September 2019 (UTC)

Adding empty parameters is just proliferating clutter. IABot, and any other tool, should not do that. As for the TemplateData, if it's broke, fix it.

—Trappist the monk (talk) 14:40, 8 September 2019 (UTC)

I reverted the change to TemplateData done September 3. Please discuss before re-adding. Given how powerful TemplateData can impact automated tools it is surprising it is not locked like templates. IABot has added thousands of empty and duplicate parameters in the past 5 days. -- GreenC 14:47, 8 September 2019 (UTC)

Before you posted this I did not know that IABot uses TemplateData. Perhaps Editor Cyberpower678 should document what is used and how it is used at Template:Cite web § TemplateData and the other cs1|2 templates that IABot interacts with so that editors can be aware of that usage.

—Trappist the monk (talk) 15:21, 8 September 2019 (UTC)

I added a warning banner [3] and linked to a new section Help:Citation_Style_1#TemplateData to document. Feel free to adjust as needed. -- GreenC 16:00, 8 September 2019 (UTC)

Trappist the monk, oh that’s just the beginning. In IABot v2.1, it will parse the CS1|2 configuration page and self-update which parameters to use. —CYBERPOWER (Chat) 18:56, 8 September 2019 (UTC)

Module:Citation/CS1/Configuration is much less susceptible to changes made by well-meaning editors who may or may not have a good grasp of the consequences of their edits. Anyone can edit templatedata, not so with ~/Configuration. When can we expect IABot 2.1?

—Trappist the monk (talk) 19:09, 8 September 2019 (UTC)

Cyberpower678, I would caution any bot operator against programming a bot to be dependent on the contents of an unprotected page. TemplateData code typically lives on unprotected documentation pages (don't get me started; see Trappist's valid rant elsewhere on this page for views similar to mine). It sounds like you are moving toward making IABot dependent on the actual module code; let us know here if you need assistance. – Jonesey95 (talk) 23:59, 8 September 2019 (UTC)

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

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

No templates in section headers please.

Better off the way it was if you want the access icon and access date. These make no sense with out a value in |url=.

—Trappist the monk (talk) 22:06, 8 September 2019 (UTC)

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

Question about use of cite journal for academic/scientific papers

Template:Cite journal is for "citations for academic and scientific papers and journals." When citing a paper that appears in a journal, I agree that the citation should contain the journal name in the |journal= parameter. The new error and corresponding Category:CS1 errors: missing periodical will help us find (and fix) these. However, what's the proper solution for academic and scientific papers that were not published in a journal? For example, see the citations in 2 Andromedae, 46,XX testicular disorders of sex development, 5 Lacertae, and 54 Piscium. I tried using {{cite paper}}, but that just redirects to {{cite journal}} and retains the error message. Thanks! GoingBatty (talk) 03:15, 9 September 2019 (UTC)

P.S. I find that some errors should be fixed by changing {{cite journal}} to {{cite report}} or {{cite thesis}} when the cited material is a report or thesis, but don't want to use those templates incorrectly just to make an error go away. GoingBatty (talk) 03:42, 9 September 2019 (UTC)

Running citation bot will often deal with those errors. In the case of 46,XX testicular disorders of sex development, I believe GeneReviews is a database, so a cite web / cite encyclopedia would be appropriate. Headbomb {t · c · p · b} 03:48, 9 September 2019 (UTC)

Can you be specific as to which references are academic papers which were not published in a journal, and which aren’t a thesis or a report? I’m not sure which citation examples you have in mind. Umimmak (talk) 03:50, 9 September 2019 (UTC)

@Umimmak:

• Headbomb kindly fixed 2 Andromedae reference #5 with Citation bot in this edit.
• I fixed 46,XX testicular disorders of sex development reference #2 by changing it to {{cite web}} per Headbomb's suggestion in this edit
• Headbomb kindly fixed 5 Lacertae reference #10 with Citation bot in this edit.
• Headbomb kindly fixed 54 Piscium reference #4 by changing it to {{cite book}} in this edit. GoingBatty (talk) 04:09, 9 September 2019 (UTC)

The second reference seems to be mixing the authors of the article and the editors of the whole work. Using editor parameters with {{cite web}} leaves the title in a strange place with repect to the authors. {{cite journal}} produces the same result. The NCBI seem to treat GeneReviews like an online book and suggest the following citation:

Délot EC, Vilain EJ. Nonsyndromic 46,XX Testicular Disorders of Sex Development. 2003 Oct 30 [Updated 2015 May 7]. In: Adam MP, Ardinger HH, Pagon RA, et al., editors. GeneReviews® [Internet]. Seattle (WA): University of Washington, Seattle; 1993-2019. Available from: https://www.ncbi.nlm.nih.gov/books/NBK1416/

This can be most closely matched with {{cite book}} and |chapter=.

There is also the issue of how to handle the "last updated" part. Tagging it on at the end (as now) seems inappropriate and is it necessary with the access date given?   Jts1882 | talk  07:42, 9 September 2019 (UTC)

References

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

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

The examples below use {{cite book}}, but the template application is immaterial.

1. A book by an author, book edited by an editor

{{cite book|author=Author|editor=Editor|title=Title}}

displays: Author. Editor (ed.). Title. {{cite book}}: |author= has generic name (help) - OK

2. A chapter in a book by an author

{{cite book|author=Author|chapter=Chapter|title=Title}}

displays: Author. "Chapter". Title. {{cite book}}: |author= has generic name (help) - OK

3. A chapter in a book by an author, book edited by an editor

{{cite book|author=Author|chapter=Chapter|editor=Editor|title=Title}}

displays: Author. "Chapter". In Editor (ed.). Title. {{cite book}}: |author= has generic name (help) - NOT OK. I believe the editor role should be presented as in #1.

4. A contribution in a book by an author

{{cite book|author=Author|contributor=Contributor|contribution=Contribution|title=Title}}

displays: Contributor. "Contribution". Title. By Author. {{cite book}}: |author= has generic name (help) - OK

5. A contribution in a book by an author, book edited by an editor

{{cite book|author=Author|contributor=Contributor|contribution=Contribution|editor=Editor|title=Title}}

displays: Contributor. "Contribution". Title. By Author. Editor (ed.). {{cite book}}: |author= has generic name (help) - OK

6. A contribution in a collection supervised by an editor

{{cite book|contributor=Contributor|contribution=Contribution|editor=Editor|title=Title|}}

displays: Editor (ed.). "Contribution". Title. {{cite book}}: |contributor= requires |author= (help); |editor= has generic name (help) - NOT OK. I believe that there should be no error, and the static text should include "In" editor. "Author" is not really relevant here. "In editor" should be enough to show this as an edited collection of contributions.

7. A contribution in a book by many authors, book edited by an editor

{{cite book|author1=Author1|author2=Author2|author3=Author3|contributor=Contributor|contribution=Contribution|editor=Editor|title=Title|}}

displays: Contributor. "Contribution". Title. By Author1; Author2; Author3. Editor (ed.). {{cite book}}: |author1= has generic name (help); Cite has empty unknown parameter: |1= (help)CS1 maint: numeric names: authors list (link) - OK

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

There seem to be two proposed changes here (3 and 6).

In 3, it is not clear what presentation is desired.

As for 6, I agree that |contribution= should be allowed with |editor=. That would allow us to present citations of separately-authored prefaces of edited books in a consistent way to those of authored books. In fact, I would make |contribution= an alias of |chapter=. (Other changes would be required for full consistency, though). Kanguole 18:29, 9 September 2019 (UTC)

Does CMS or any other style guide with citations similar to ours provide guidance on this issue? —David Eppstein (talk) 19:08, 9 September 2019 (UTC)

For #3, what is asked is to omit "In", instead to reserve this for edited collections. Somewhat related to #6, where "In" would signify that the editor in such cases acts more as a curator, like the supervisory editor of an encyclopedia or the senior editor of a collection of research papers. Recently, there have been additional comments at #Proposal for an "in-title" ("In" + title) parameter. 108.182.15.109 (talk) 12:05, 10 September 2019 (UTC)

But #3 does designate an author's chapter in an edited collection. Kanguole 12:43, 10 September 2019 (UTC)

That is a book by a single author, edited by an editor. In an edited collection, the editor usually determines the collection's roster of contributors and/or selects their works. As remarked, s/he acts more as a curator. The contributors are "in" hers/his collection. 108.182.15.109 (talk) 12:49, 10 September 2019 (UTC)

No, #3 really is a chapter in an edited collection of chapters by different authors, not an authored book. You have misunderstood what that form is used for, which is apparently the source of our disagreements above. Kanguole 13:11, 10 September 2019 (UTC)

Are you saying that any citation of a chapter in a book that has an editor (that's practically all of them) must necessarily mean that the work in question is an edited collection? Why? 108.182.15.109 (talk) 13:19, 10 September 2019 (UTC)

I'm saying that we use form #3 for authored chapters in edited collections, e.g. the sixth example in Template:Cite book/doc#Examples (a bit like APA citation style). Kanguole 13:24, 10 September 2019 (UTC)

Aren't "authored chapters in edited collections"... contributions? #3 cites a chapter in a book by a single author. For any or no reason, the writer of the citation has decided to add the book's editor, as s/he has a right to do. This form has been used extensively for the purpose. How else would you cite a chapter in a book by a single author? 108.182.15.109 (talk) 13:46, 10 September 2019 (UTC)

They are indeed contributions, but |chapter= was in use for separately-authored parts of edited collections for a long time before |contribution= was introduced for separately-authored parts of authored books (with inconsistent formatting, as I've said above). You are simply mistaken about how this form of the template is used. Kanguole 14:07, 10 September 2019 (UTC)

|chapter= was also in use for separately-authored parts of edited collections for a long time before |contribution= was introduced. That is one of the reasons the contributor (vs. author) parameter-group was introduced, to distinguish then from citations of chapters in single-authored or multi-authored books. A collection however is not a book with many authors. It does have separately authored parts. But no single author can take credit for the entire work, that is the job of the editor who assembled the collection. 108.182.15.109 (talk) 14:19, 10 September 2019 (UTC)

Proposal to change redirects

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

We might have to do something about the default "(Report)" text that appears in {{Cite report}}. See this section above for a related discussion. – Jonesey95 (talk) 02:19, 10 September 2019 (UTC)

We might also need to discuss the formatting of the title of a report. For some reports/papers/documents, because of their lengths, they'd be considered long-form documents that should be titled in italics. Some would be short enough to be a short-form document and should be titled in quotation marks. Imzadi 1979 → 02:51, 10 September 2019 (UTC)

I wonder if there is a need to distinguish the work as short-form/long-form. It adds code overhead, and the dissimilar formatting of the same argument can be confusing. I think the presentation of all aliases of the same parameter should be presented uniformly, in this case by applying emphasis. With apologies to the OP for the unrelated comment. 108.182.15.109 (talk) 12:16, 10 September 2019 (UTC)

Personally, when citing reports, I use {{cite book}} with |type=Report so that the title renders in italics. (It's rare that I'd cite something that qualifies as a report that's also short enough to be considered a short-form document, and in those few cases, I err on the side of consistency with the rest and go italics.) Imzadi 1979 → 03:59, 12 September 2019 (UTC)

I think that I'm opposed to this because presumably, editors who used those templates didn't want {{cite report}} and just repointing those redirects will break something. You might guess that I'm a bit sensitive to broken stuff right now ...

I would be in favor of eliminating these redirects and any others that point to {{cite journal}} (and, for that matter to the other cs1 templates). Then, if we decide that we need a {{cite document}} template, we create one.

—Trappist the monk (talk) 22:52, 10 September 2019 (UTC)

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

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

Cite AV media notes comparison

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

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

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

What we really should do is spend some time rewriting {{cite AV media}}, {{cite episode}}, {{cite serial}} so that they properly handle name lists: don't use aliases of |authors= and don't misuse |others=. I've been saying this on and off for a long time.

—Trappist the monk (talk) 22:44, 10 September 2019 (UTC)

Support year-suffix outside the English alphabet

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

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

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

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

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

Hence

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

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

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

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

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

I’m confused, would using, e.g., 2002α, 2002β, 2002γ, to disambiguate Harvard style citations be limited to the Greek language version of Wikipedia? Or are you suggesting that the Greek alphabet be used even on the English Wikipedia to disambiguate citations which were published in Greek? Umimmak (talk) 09:55, 11 September 2019 (UTC)

I'm saying that the use of the standard string library implicitly enforces a choice that doesn't make sense to wikis whose alphabet is based on non-Latin script. Making this specific check with ustring keeps everybody happy paa (talk) 10:21, 11 September 2019 (UTC)

This issue initially raised at el:Βικιπαίδεια:Αγορά#Cite_book. Is there some reason why en.wiki should not allow non-Latin CITEREF disambiguators?

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

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

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

Cite book comparison

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

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

Trappist the monk asked "Is there some reason why en.wiki should not allow non-Latin CITEREF disambiguators?" Yes. These disambiguators are usually (always?) associated with a list of sources in alpha-numeric order, where they are sorted first by author name(s), and with the date as a tie-breaker. All editors of the article will have occasion to re-sort the list as new sources are added. Thus the disambiguation characters should be letters of the Roman alphabet so that all editors will be able to insert new sources at their proper place in the list. It will also aid readers who are reading a version of the article which has been printed on paper, so that references to sources must be followed manually.

It's an open question whether this is a limitation that should just be documented, giving gnomes license to manually or semi-automatically convert non-Roman characters to Roman, or if it should be enforced by the citation software. Jc3s5h (talk) 16:17, 11 September 2019 (UTC)

Adding url= to ref with title-link generates an error.

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

That template should emit an error message because you can't link |title= to two different targets. |title-link=s:Mount Everest: The Reconnaissance is a perfectly valid link into WikiSource. cs1|2 might handle this particular error a bit better by choosing either of |title-link= or |url= to link |title=. Which should it be? When more than one link target is present, it's still an error so there will be some sort of message.

OAbot should not be adding |url= to a cs1|2 template when that template has a valid title link so you should raise this issue at User talk:OAbot.

—Trappist the monk (talk) 11:11, 11 September 2019 (UTC)

Thank you, I will do that. Thincat (talk) 11:21, 11 September 2019 (UTC)

Multiple url instances

This is currently allowed:

{{cite book|author=Author|url=http://example.com|chapter-url=http://example.com/chapter1|title=Title|chapter=Chapter}}

Author. "Chapter". Title. {{cite book}}: |author= has generic name (help)

Is not the appearance of multiple urls superfluous? All that is needed to verify the citation would be one url, the more specific one (chapter location) being the obvious choice.

I am bringing this up because User:InternetArchiveBot apparently ignores in-source urls, as in this: diff

Results in clutter. I am bringing it here because if multiple urls were disallowed the bot would not be able to make the edit as effected.

24.105.132.254 (talk) 16:16, 11 September 2019 (UTC)

We allow multiple links in citations (e.g. DOI, PMID, PMC, URL, chapter, wikilinks, even links in |pages=). One editor's superfluity is another editor's helpful additional link. – Jonesey95 (talk) 18:53, 11 September 2019 (UTC)

Understood, but what you describe are different links to the source via different providers. The problem concerns urls to the same site via the same provider, which is also allowed. In the OP, |url= links the source's title/home page, and |chapter-url= uses the same link modified to locate a sub-page. This seems superfluous. The IA bot adds |url= even when an in-source location url (in the diff example, a chapter url) is already present. The source link is of course published by the same provider (the Internet Archive) in both cases. Obviously, the bot would not be able to do this if multiple instances of the same website were disallowed in a citation. 65.88.88.91 (talk) 20:07, 11 September 2019 (UTC)

Not superfluous, as sometimes it is useful to link to both the chapter, and the book or report containing it. As a particular case: the chapter-url can be used to link directly to a pdf, while the report url could link the webpage that has information about the report. At any rate, the use of both is widespread, and disallowing it would result in a lot of breakage. ♦ J. Johnson (JJ) (talk) 20:02, 13 September 2019 (UTC)

Remove |url= when |doi= is provided

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

CS1/2 can not know where a DOI URL points. --Izno (talk) 17:36, 14 September 2019 (UTC)

And by the same logic, you can't be sure ever be sure where a DOI will point at any particular time; the purpose of DOIs is to provide a fixed way of accessing a URL that can change. For this reason, I'm not sure that it's right to remove a URL that happens right now to be where a DOI points. Peter coxhead (talk) 20:36, 14 September 2019 (UTC)

I know when citing IUCN it’s recommended to make use of both |doi= and |url= because A DOI links to a permanent web page with a specific year's assessment that will never be updated, so when a new assessment is issued, a new DOI will be created and the old one will then point to the previous assessment. An ID-based URL should always link to the current assessment, but that URL is not guaranteed to work indefinitely. Thus, it is probably best to use both, and to use the ID-based URL if only one URL will be used. But I do think in general it’s probably redundant and cluttered to have a DOI and the present address the DOI resolves to in the |url= field. The linked discussion began with examples like |url=http://www.sciencedirect.com/science/article/pii/S0277539513000915 with |doi=10.1016/j.wsif.2013.05.012. I’m not sure I see the issue with removing those sorts of |url=s. But I agree that this shouldn’t be treated as a CS1 error—particularly as the |url= often provides a different, typically free, way to access a paper. Umimmak (talk) 23:45, 14 September 2019 (UTC)

Peter coxhead I actually deliberately chose not to make a comment in that direction; mine was solely regarding what is technically possible. The module cannot access pages offwiki, which means it cannot verify for itself that a DOI at a referrer link resolves to the same location as the URL. It's a separate consensus discussion treating the question of whether such links matching the resolved DOI should be removed, but I think there's a mass of silent consensus there, since I can recall only the one discussion by the OP concerned with the practice. (Which was not the case with the bot removing the publisher.) --Izno (talk) 00:35, 15 September 2019 (UTC)

Option to turn off PMC autolink

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

Cite news - multiple URLs

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

@Raymie: I've found it useful, and less confusing to link the second page number, like in footnote 123 at Michigan State Trunkline Highway System. Imzadi 1979 → 23:58, 16 September 2019 (UTC)

@Imzadi1979: Thanks for the advice! Raymie (t • c) 00:01, 17 September 2019 (UTC)

For a single article carried across several pages, where you have given a page range (something like |pages=1, 6-7), I think it suffices to give the reader the url for the first page. I am pretty sure most readers could find their way to the rest of the pages without a separate url. If you have a large article and want to provide a specific in-source location (perhaps more than one), that is best handled by appending a suitable link (or links) to the in-line citation. E.g.: <ref>{{cite news | ...|ps=,}} [https:newspapers.com/xxx6/ page 6, col. 2].</ref> ♦ J. Johnson (JJ) (talk) 21:43, 17 September 2019 (UTC)

I am pretty sure most readers could find their way to the rest of the pages without a separate url. — maybe this is just because I’m not familiar with Newspapers.com, but I’m not seeing an easy way to get from [4] to [5], especially without an account/subscription. If the editor has access to all the relevant clippings, it definitely makes it significantly more convenient to the reader and other editors to link multiple locations. Umimmak (talk) 22:50, 17 September 2019 (UTC)

"[E]specially without an account/subscription" — for sure, and that's a different problem. If you need to use multiple urls for the full citation then do as Raymie suggested: append the extra information to the template. E.g., something like: <ref>{{cite news |... |url=https://newspapers.com/xxx1|ps=,}} continued at [https://newspapers.com/xxx6/ page 6].</ref> ♦ J. Johnson (JJ) (talk) 19:41, 18 September 2019 (UTC)

As noted above, it's possible to link the second page number to the URL needed to see it, to wit:

Rook, Christine (July 12, 2009). "Finishing US 127 Still Has Support". Lansing State Journal. pp. 1A, 4A. ISSN 0274-9742. OCLC 6678181. Retrieved July 13, 2018 – via Newspapers.com.

The second page number already indicates the continuation in the original print edition. I think it just looks cleaner to keep the citation together, especially when the access date/via/etc will fall in between the page numbers and the link to the continuation. Imzadi 1979 → 23:18, 18 September 2019 (UTC)

I was responding to the comment saying it suffices to only link the first page. Linking the additional pages within |pages= works for me, although I do wonder if this might cause issues for the COinS metadata. But I’m not super familiar with that; I just vaguely recall this issue coming up in the past and another editor having that concern. Umimmak (talk) 00:58, 19 September 2019 (UTC)

Yes. That would seem to be a viable option, but I can see some possible problems, and it might have problems with parameter validation. ♦ J. Johnson (JJ) (talk) 20:27, 20 September 2019 (UTC)

Template:Citation has a mode=cs1 parameter

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

---

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

Here is a sample:

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

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

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

script-title=missing prefix

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

Of course. Properly your bot should inspect the content of the script parameters to see that the script matches the language name or code assigned to |language=. The script parameters are:

|script-article=, |script-chapter=, |script-contribution=, |script-entry=, |script-journal=, |script-magazine=, |script-newspaper=, |script-periodical=, |script-section=, |script-title=, |script-website=, |script-work=

(and yes, I have seen the specified language in |language= be different from the language used in the associated script parameter).

—Trappist the monk (talk) 17:16, 19 September 2019 (UTC)

Template:Hyphen is corrupted

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

• Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.

Instead of the correct/expected

• Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.

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

Why |pages= instead of |page=? It looks like just one page is being cited. Using {{cite compare}}:

Cite journal comparison

Wikitext	{{cite journal|date=2017-09-26|doi=10.1128/mBio.01633-17|first1=Patrick D.|first2=Mark|first3=Arturo|issue=5|journal=mBio|last1=Schloss|last2=Johnston|last3=Casadevall|page=e01633-17|pmc=5615203|pmid=28951482|title=Support science by publishing in scientific society journals|volume=8}}
Live	Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.
Sandbox	Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.

Here it is with |pages=:

Cite journal comparison

Wikitext	{{cite journal|date=2017-09-26|doi=10.1128/mBio.01633-17|first1=Patrick D.|first2=Mark|first3=Arturo|issue=5|journal=mBio|last1=Schloss|last2=Johnston|last3=Casadevall|pages=e01633-17|pmc=5615203|pmid=28951482|title=Support science by publishing in scientific society journals|volume=8}}
Live	Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.
Sandbox	Schloss, Patrick D.; Johnston, Mark; Casadevall, Arturo (2017-09-26). "Support science by publishing in scientific society journals". mBio. 8 (5): e01633-17. doi:10.1128/mBio.01633-17. PMC 5615203. PMID 28951482.

What am I missing? — Preceding unsigned comment added by Jonesey95 (talk • contribs)

It is just one page, yes, so |page= is technically more correct than |pages=. However, we don't mangle the output if you have something like |pages=124 or |page=124–127, so there's no reason to silently mangle the output here either. Headbomb {t · c · p · b} 18:02, 19 September 2019 (UTC)

Because editors do use semicolons in the oddest places, and because {{hyphen}} is processed before the cs1|2 template and because {{hyphen}} renders as - with a trailing semicolon: then |pages=1{{hyphen}}2 becomes |pages=1-2 which (because pages plural) cs1|2 treats as two separate pages 1&#45 and 2. Had you used |page=1{{hyphen}}2 (singular) then cs1|2 ignores the semicolon separator character.

This particular example is a single page and not a range (...33 to ...17 is malformed were it intended to be a range) so write |page=e01633-17 with the keyboard hyphen character; don't use {{hyphen}}.

—Trappist the monk (talk) 18:48, 19 September 2019 (UTC)

Best practice is to use {{hyphen}}, per documentation. Headbomb {t · c · p · b} 18:53, 19 September 2019 (UTC)

ISSN error

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

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

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

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

Are you sure? I don't know that |supplement= ever existed in cs1|2 templates.

—Trappist the monk (talk) 13:10, 22 September 2019 (UTC)

True, I don't remember a "supplement" parameter either. I would use |type=supplement instead. If the particular supplement is a regular feature, identify the feature in e.g |department=weekly magazine or |department=annual survey or some such. 72.43.99.138 (talk) 13:43, 22 September 2019 (UTC)

For instance Sunday Times, has multiple supplements like Sports section, Business, Style Magazine, with their own page number, cite newspaper had it, now that redirects to cite news, which doesn't have |supplement parameter, can we add that please, thanks. Govvy (talk) 15:28, 22 September 2019 (UTC)

Are you sure? The first version of {{cite newspaper}} is as a redirect to {{cite news}}. Over its history, that has never changed.

As suggested before, consider |department=.

—Trappist the monk (talk) 16:04, 22 September 2019 (UTC)

The {{Cite DNB}} template has a |supplement= parameter. It's not a CS1 template, but could be the source of confusion.   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)

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

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

The preferred result would be on the lines of:

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

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

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

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. {{cite journal}}: |author= has generic name (help)

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 journal

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

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

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

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

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)

Date in non-Gregorian calendar

According to WP:CS1, "Sources are at liberty to use other ways of expressing dates, such as "spring/summer" or a date in a religious calendar; editors should report the date as expressed by the source." (my emphasis) However in Muhammad_III_of_Granada#Primary_sources, I used "1247 AH" as the date (see "Ibn al-Khaṭīb (1347 AH)") and got a validation error Check date values in: |date=. How do I fix this? HaEr48 (talk) 13:30, 25 September 2019 (UTC)

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)