Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite news)
Jump to navigation Jump to search

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

Stop linking paper title to PMC[edit]

Is there a way to stop {{cite journal}} from linking the paper title to a PubMed Central URL generated from |pmc= in the absence of |url=? I cited a paper whose manuscript was on PMC but which was not otherwise freely available. I used the page numbers of the published version in footnotes, which I found preferable for obvious reasons, so it strikes me as incongruous that even though the article is explicitly referencing the published version, the title is linked to a pre-review manuscript. Removing |pmc= would disable the link, but that doesn't seem wise either because a free link to a version of the paper, even if not the most authoritative one, is definitely beneficial to readers.

While I'm at it, I don't really see the necessity of |pmc= standing in for |url= in the first place, given that a separate link is also provided and the open access is indicated by the padlock icon following the latter link. Do we need this feature? Even if so, shouldn't an editor at least be able to opt it out? Nardog (talk) 03:50, 16 May 2019 (UTC)

"I cited a paper whose manuscript was on PMC but which was not otherwise freely available." If it's an embargoed paper, use |embargo=201X-XX-XX'. If you just want a different URL than the PMC one, then just specify that URL in |url= instead. Headbomb {t · c · p · b} 04:45, 16 May 2019 (UTC)
No, not embargoed. And the published version is not available except behind a paywall. I can specify the same URL as DOI, but what would be the point of that? I want to disable the PMC link. Nardog (talk) 04:55, 16 May 2019 (UTC)
If the only free version is at PMC, and you want readers to have access to a free version, then the PMC link needs to be there, doesn't it? BlackcurrantTea (talk) 05:23, 16 May 2019 (UTC)
Yes, I just don't want the title of the paper to be linked to PMC. Nardog (talk) 05:24, 16 May 2019 (UTC)
Ah, right. Obviously I need another cuppa; I wasn't making the connection. Thanks for explaining. BlackcurrantTea (talk) 06:43, 16 May 2019 (UTC)
It is always good to provide an example so that we can see what you are seeing.
I would like nothing better than to remove that special-case pmc code. I did that once. But then WP:MED rose up with their torches and pitchforks ...
I'm not enthusiastic about making yet-another-special-case for pmc. If you want us to remove current pmc auto-linking of |title=, you must get WP:MED to agree with that, or a sufficient consensus that does not include them.
Trappist the monk (talk) 10:10, 16 May 2019 (UTC)
WP:MED does not WP:OWN the module. --Izno (talk) 12:46, 16 May 2019 (UTC)
@Trappist the monk: Why is removing the auto-linking considered "making yet-another-special-case"? Isn't it rather removing one? Nardog (talk) 14:33, 16 May 2019 (UTC)
You asked for a way to stop {{cite journal}} from linking the paper title. Presuming that the auto-linking will remain, then some way to allow editors to disable the auto-linking is yet-another-special-case for pmc.
Trappist the monk (talk) 14:46, 16 May 2019 (UTC)
If the content in the pages you are citing is not substantially/semantically different than the relevant section(s) of the pre-review version, then adding the pmc link benefits verification. You can |quote= the online paper's subheading as a pre-review copy, or quote any other part of the publication info that shows the paper is a pre-review copy. Or, add a {{link note}} to that effect after the citation. If there are semantic differences between the preliminary and the final version in the cited pages, I would leave the pmc out altogether. The citation is no longer reliable. 108.182.15.109 (talk) 13:13, 16 May 2019 (UTC)
Again, I'm only talking about the template automatically linking the title of the paper when |pmc= is given but |url= is not. I'm not talking about the utility of PMC as a whole. Nardog (talk) 13:47, 16 May 2019 (UTC)
I don't think you should compare |pmc= with |url=. One is a standard content identifier (akin to doi). The other is a locator/pointer. There are further differences between content ids such as pmc and classification/marketing ids such as isbn. The point is, is the verifiability of whatever you claim in wikitext helped by adding this parameter? This is the main point in adding citations in a project like Wikipedia. Otherwise it is just somebody blabbering at some internet site. 65.88.88.69 (talk) 19:54, 16 May 2019 (UTC)
Often PMC is the only free source. Even if it is not only the free source, what is the harm of including |pmc=? At the same time, (pitch forks or not) IMHO pmc should never be linked because it leads to a MOS:SEAOFBLUE in the reference section. Readers are intelligent enough to follow a link, even if the title is not linked. This is especially true now that File:Lock-green.svg follows the PMC link. WP:MED is insulting the intelligence of the average reader. Boghog (talk) 19:00, 16 May 2019 (UTC)

Since some people are not getting the issue even after multiple clarifications, here is an example:

  • {{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}}

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.

Notice the title of the paper is linked to PMC, even though |url= is absent. The only way to remove the link is to remove |pmc=, which, however, and of course, also removes the PMC link at the end. Nardog (talk) 05:02, 17 May 2019 (UTC)

I strongly support no longer linking the article title to the PMC; the link from the PMC is enough. What on earth is the point of duplicate links? And anyway, in this example, the most relevant link here is the doi, not the PMC. Peter coxhead (talk) 06:35, 17 May 2019 (UTC)
I agree, but others don't. Trappist has linked people arguing for duplicating the PMC link in the title; in this discussion, people argued for doing that for all free identifiers. Kanguole 09:27, 17 May 2019 (UTC)
The functionality should indeed be extended to the other free identifiers for version of record, not removed for PMCs. Headbomb {t · c · p · b} 13:07, 17 May 2019 (UTC)
No. Just no. Very often sources linked through identifiers are not free-to-read; |title= linked to a source with |url= is presumed to be free-to-read; readers expect that linked titles are free-to-read unless marked otherwise with an appropriate access icon. When multiple identifiers are provided in the template, which one wins? (there must be a winner because |title= can only link to one target). Who or what decides the priority of identifiers when more than one is provided?
Auto-linking of |pmc= should be removed and there's an end to it.
Trappist the monk (talk) 13:24, 17 May 2019 (UTC)
Kanguole and Headbomb kind of accidentally bring up very astute points that go against this feature – in theory, promoting open-access links is great. But then, why single PMC out? Why not all free identifiers? But if we stopped singling PMC out, then how does the template decide which one to link the title to when multiple free identifiers are entered?
Further, oftentimes another identifier provides open access to a more reliable version than PMC. In that case, linking the title to PMC makes little sense. The more you consider the philosophy supposedly behind the auto-linking, the more reasonable it seems to drop it. Nardog (talk) 14:01, 17 May 2019 (UTC)
Just build a hierachy. PMC > DOI > Handle > and so on. |url= overides automatical linking. If you don't want the default, have |url=doi or similar (e.g. |auto-url=doi as an override. Headbomb {t · c · p · b} 03:33, 18 May 2019 (UTC)
A DOI or Handle may or may not be free. So why should the title automatically be linked to those handles if a PMC is not present? And why should the title be linked to anything other than |url=? These other parameters already generate their own links and with |doi-access=free, etc. can be marked as free access. Boghog (talk) 05:39, 18 May 2019 (UTC)
This. Nardog (talk) 13:35, 19 May 2019 (UTC)
Likewise for |hdl-access=free and so on. Use whatever version of record is known to be free, following the hierarchy. If the default link is not desired (e.g. if the hierarchy is pmc>doi>hdl>bibcode>...), it could be overridden, either with |url=https:... or with |auto-url=hdl or similar. Headbomb {t · c · p · b} 23:14, 23 June 2019 (UTC)
I would support an RFC on removing the special-casing. --Izno (talk) 03:39, 25 May 2019 (UTC)

Italics of websites in citations and references – request for comment[edit]

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

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

The following pages have been notified

Responses[edit]

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

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

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

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

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

Discussion and alternatives[edit]

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

Closing[edit]

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

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

RfC on linking title to PMC[edit]

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[edit]

  • 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). –MJLTalk 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.MJLTalk 06:09, 20 June 2019 (UTC)
    @MJL: PMC links are suffixed by the open padlock Lock-green.svg 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? –MJLTalk 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.
    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)

Remove link[edit]

  • 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[edit]

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

deprecate |lay-summary= and |laysummary=[edit]

|lay-summary= and |laysummary= are supposed to hold the url of a lay summary. We have |lay-url= which abides by the general rule that url-holding parameter names end with -url (|dead-url= notwithstanding).

This insource search found about 4000 articles that have either of |lay-summary= and/or |laysummary= with or without assigned values.

Without objection, I shall deprecate these two parameters and write an awb script to rename |lay-summary= and |laysummary= to |lay-url= (or delete if empty).

Trappist the monk (talk) 14:00, 1 June 2019 (UTC)

What if it's not a URL? :) --Izno (talk) 16:14, 1 June 2019 (UTC)
If the value assigned to any of |lay-summary=, |laysummary=, and |lay-url= is not a url, the module knows that and emits an error message:
Cite journal compare
{{cite journal |title=Title |lay-source=Lay Source |journal=Journal |lay-summary=Lay-summary is not a url}}
Live "Title". Journal. [Lay-summary is not a url Lay summary] Check |lay-summary= value (help)Lay Source.
Sandbox "Title". Journal. [Lay-summary is not a url Lay summary] Check |lay-summary= value (help)Lay Source. Cite uses deprecated parameter |lay-summary= (help)
Trappist the monk (talk) 16:29, 1 June 2019 (UTC)
Yeah, get rid of those things. AWB/bot runs could clear the backlog and then these parameters fully removed by the next update. Headbomb {t · c · p · b} 23:29, 23 June 2019 (UTC)
Most are already gone. There are a few that may have survived or been added since the purge. Those few that remain will collect in Category:CS1 errors: deprecated parameters after the next update
Trappist the monk (talk) 23:43, 23 June 2019 (UTC)

url + title=none[edit]

For stylistic reasons, the title in

needs suppressing. However, when you set |title=none, you get

I believe in this case, we should have something like

or even something like

or

instead. Headbomb {t · c · p · b} 22:52, 6 June 2019 (UTC)

Lenore Blum? That source is open access, there is a link to the pdf from the doi-linked publisher page so:
{{citation |last=Bach |first=Eric |pages=145–146 |journal=Discrete Dynamics in Nature and Society |volume=6 |issue=2 |year=2001 |doi=10.1155/S1026022601000152 |doi-access=free |title=none}}
Bach, Eric (2001), Discrete Dynamics in Nature and Society, 6 (2): 145–146, doi:10.1155/S1026022601000152CS1 maint: Untitled periodical (link)
This form is similar to the Meer, Vavasis, and McNicholl citations in that <ref>...</ref> tag.
The https:// links above cause my current-version Chrome browser complain about security certificate mismatch. The link at the doi-linked publisher's page is an http://... url.
Trappist the monk (talk) 23:56, 6 June 2019 (UTC)
Maybe so, but that doesn't detract from the general point that this is a feature that should be supported, e.g.
Headbomb {t · c · p · b} 21:58, 25 June 2019 (UTC)

Name order[edit]

As it is, the cite book template puts the surname before the first name (e.g. "Smith, John"). I'd like someone to add a option that will force the template to order it first then last (ie "John Smith"). The only way to do this currently is to use the author= parameter, but then this causes problems with the ref= parameter and other things. Could somebody do this for me? Something like a parameter first-last-name=true. Kurzon (talk) 17:37, 15 June 2019 (UTC)

I support some version of this. Specifically, with the |af= parameter, as I proposed it in 2018. Headbomb {t · c · p · b} 18:50, 15 June 2019 (UTC)
Combined with automatic global formatting like have for dates, especially. Headbomb {t · c · p · b} 15:59, 18 June 2019 (UTC)
Why?
First-last ordering of the lead author's name in a citation is considered acceptable when the citations occur as isolated driplets across the foot of various pages because there are usually only one or two, and there is no question of ordering. On the other hand, when full citations are collected into lists it is standard to collate them in some kind of order, which is typically alphabetically by the first author's surname (family name). As most Western cultures put this name last, which is inconvenient for the primary sort-key, it is standard practice to invert the name into "last, first" order. I do not know of any reason why this should not be done for the lead author.
Variation on this point occurs regarding co-authors. That is an arguable point, and it seems to me it has been argued before. If it is going to be raised again I would expect a review of previous related discussions. ♦ J. Johnson (JJ) (talk) 21:10, 17 June 2019 (UTC)
Well, for one thing you have Asian names where the surname comes first. Previously, people just told me to use |author=. Kurzon (talk) 11:54, 18 June 2019 (UTC)
Another consideration is how certain style guides handle things. In The Chicago Manual of Style's system of footnotes/endnotes, the name order is not inverted. CMOS does invert name order in a bibliography for the first author only. For those more familiar with CMOS's methods, ours may seem strange. Imzadi 1979  12:42, 18 June 2019 (UTC)
Why? Because WP:CITEVAR mostly, and because this would allow us to have "John Smith (1903) Book of Stuff ..." types of citation with correct last/first name metadata. But also because it would let us easily support a plethora of styles, from CMOS, Bluebook, Vancouver, and many others while also ensuring full consistency and error checking on author format across the whole article by slapping the equivalent of {{use dmy dates}} on the article, like we do for dates. You could slap something like {{use Vancouver names}}, or {{cs1-name-format|Vancouver}} or similar, and not have to micromanage and review every citation after bots, tools, and editors get involved. Headbomb {t · c · p · b} 16:28, 19 June 2019 (UTC)
I second this. The first-last name order is more readable, in particular if commas are part of a name or commas are used as name separators (as it happens in some style guides). This format is therefore used in many areas outside WP (and even in WP when not using cs1 citation templates). The last-first order has advantages as well, and I think it should remain the default. However, since the usage of the citation template framework is preferable over "free-style" citations for many reasons, it is important for the framework to support all major display variants, because otherwise some people will simply not use the templates.
I would therefore applaud the addition of an af= parameter and global templates like "Use lf/fl names", and in the long run hopefully the possibility to set the preferred format in the user preferences overriding such Use names or Use dates templates.
Although I consider the usage of abbreviated names as an anachronism being difficult to read and often causing confusion (and our MOS advises against the usage of abbreviations where possible), I would even support if an af= parameter would optionally support the automatic truncation of given names, because there might be a few areas where it's actually useful (for as long as this never becomes a default). This may also help to improve the quality of our references, because people could always specify the unabbreviated names, even if only abbreviated names were to be displayed in a specific scenario.
--Matthiaspaul (talk) 10:17, 23 June 2019 (UTC)
It would also let us get rid of the awfully specific |name-list-format=vanc in favour of something scalable to other styles. Headbomb {t · c · p · b} 21:48, 25 June 2019 (UTC)
Please pay closer attention: citations in a note at the foot of a page – i.e., footnotes – are exactly where I said that author names are not inverted. In any kind of list, such as a bibliography, it is preferred to sort the entries, which is most commonly alphabetically by authors.
Kurzon: yes, with Asian style (also Hungarian) the family name (surname) comes first. If there is an possibility of confusion just use |surname=, which is a synonym for |last=. As long as we invert "last" name everything works out. If we don't invert (perhaps for co-authors), well, that would be ambiguous. The problem with using |author= or |coauthor= for this is we have no indication of which order the names are in. ♦ J. Johnson (JJ) (talk) 23:10, 18 June 2019 (UTC)

Da; there is no need for any kind of inversion. [That came in with my edit, but it's not my comment. ♦ J. Johnson (JJ) (talk) 20:31, 19 June 2019 (UTC)]

Ideally, at least for lists of citations in alphabetical order, a person from a culture where the given name is written first in running text would be "Washington, George" while a person from a culture where the surname is written first in written first would be "Mao Zedong". To achieve this ideal, it would be necessary to individually mark each name to show which convention applies, or at least, mark those that don't follow the default for an English-language publication, "Washington, George". Jc3s5h (talk) 17:38, 19 June 2019 (UTC)

That is exactly what the comma does: it indicates that a cultural-specific "normal" ordering has been inverted to put the indexed term first. A question that has been raised before (here, but also outside of WP) is whether it is proper to have a comma in "Mao, Zedong", which might imply that inversion was done. I think a better view to take is that the comma marks the index term, and (from the pov of citation) we don't really care whether inversion was necessary. ♦ J. Johnson (JJ) (talk) 20:36, 19 June 2019 (UTC)
It could also be a simple delimiter, indication delineation Mao, Tse Tung vs Mao Tse, Tung, rather than inversion. Headbomb {t · c · p · b} 21:11, 19 June 2019 (UTC)
Huh? The surname is this example is "Mao", not "Mao Tse". Why would "Mao Tse" get delimited from "Tung"? ♦ J. Johnson (JJ) (talk) 23:54, 19 June 2019 (UTC)
That's my point. In Surname, Given name the comma makes it clear where the delimitation is. It doesn't have to indicate an inversion. Headbomb {t · c · p · b} 00:06, 20 June 2019 (UTC)
Aren't we saying the same thing here? ♦ J. Johnson (JJ) (talk) 19:34, 20 June 2019 (UTC)
You're saying the comma indicates inversion. I'm saying it might simply indicate delineation. Headbomb {t · c · p · b} 19:43, 20 June 2019 (UTC)
Perhaps I was not entirely clear. What I meant above is that a comma can indicate that a Western-style first-last ordering has been inverted. But regardless of whether inversion was necessary to get the surname first, the comma marks the index term. Or to use your term, delimits it. Same thing, right? ♦ J. Johnson (JJ) (talk) 20:54, 26 June 2019 (UTC)

I read the rules and Wikipedia does not have a fixed citation style. The citation templates are optional, not mandatory. I could ignore them to do what I want. Kurzon (talk) 07:49, 20 June 2019 (UTC)

You could, but it's also why it's important that CS1 templates can accommodate small variations like that. For now, you can use |author= instead off |last=/|first=. Headbomb {t · c · p · b} 15:26, 20 June 2019 (UTC)
Templates are strongly encouraged, as otherwise the identification of sources and locating them can get murky, and verifiability (our key principle) is impaired. On the the other hand, using |authors= instead of first/last is deprecable. Yes, the documentation suggests using it, but that was never vetted, and one of these days (soon?) ought to be re-visited.
Getting back to Kurzon's initial request: I think that is a "small variation" we ought not to accommodate. I don't believe that is common practice here, and in bibliographies "last, first" is practically required. ♦ J. Johnson (JJ) (talk) 19:50, 20 June 2019 (UTC)
It's a variation that most definitely ought to be accommodated. The cost of not doing so is greater inconsistency amongst articles, and a greater refusal to adopt citation templates, and poorer metadata because |authorn= has to be used over |lastn=/|firstn=. Headbomb {t · c · p · b} 20:48, 20 June 2019 (UTC)
Misuse of |author= (and I have seen plenty of that) corrupts the metadata. But where has anyone rejected use of templates because they wanted to collate by personal name? This warrants a separate, deeper discussion. ♦ J. Johnson (JJ) (talk) 21:00, 26 June 2019 (UTC)

WP:CITESTYLE says there is no hard rule for name order. Kurzon (talk) 09:57, 21 June 2019 (UTC)

I strongly disagree that the use of |author= or |authors= could or should be deprecated. These parameters are necessary, to handle institutional authors (where the author of record is a committee or some such), and probably also necessary in some unusual circumstances to handle authors who are people but who do not have names that fit the first/last paradigm (the obligatory link). Perhaps they could be deprecated for instances where the author is a conventionally-named person or group of people but I don't see how that could be enforced. —David Eppstein (talk) 22:13, 19 July 2019 (UTC)
Authors is deprecated by maintenance message at this time, in case you were not aware. Author is supported and I expect it to be supported until we identify some alternative like org-author for organizational authors. --Izno (talk) 18:42, 21 July 2019 (UTC)
It's not just organizational authors. As I thought I already clearly stated. An example: I recently added a source whose author is credited only as "Jacob". I believe it to be a first name, but the template does not allow first= without last=. The only reasonable choice is to set author=Jacob. —David Eppstein (talk) 19:19, 21 July 2019 (UTC)
Or Riazuddin/Fayyazuddin/Plato/etc... Headbomb {t · c · p · b} 19:44, 21 July 2019 (UTC)
(edit conflict)
Nothing wrong with that. It's |authors= (plural) that is discouraged (it isn't really deprecated though I think that sometime in future it should be). This parameter is discouraged because of its free-form nature. It allows any number of names, usually human, but because human names are, per your obligatory link, so damn confounding, the module does not attempt to add the content of |authors= (plural) to the citation's metadata.
Trappist the monk (talk) 19:53, 21 July 2019 (UTC)
Not true. What WP:STYLE says is that "Wikipedia does not have a single house style". It also says (here): "The full citations are listed in alphabetical order, according to the authors' surnames, at the end of the article in a "References" section." Also (here, underlining added): "General references are usually listed at the end of the article in a "References" section, and are usually sorted by the last name of the author or the editor." As to alternative sorting, I am not aware of any instances, in or out of WP, of sorting by first (personal) names.
But don't forget what I said before: not inverting an author's name is typically done only in isolated citations, such as found in foot notes (footnotes), at the foot of a printed page, where there are only a couple of citations, and no need to sort them. ♦ J. Johnson (JJ) (talk) 21:10, 26 June 2019 (UTC)

Cite letter[edit]

Is anyone watching Template talk:Cite letter? Should it perhaps be redirected here (after the content is copied over)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:00, 21 June 2019 (UTC)

There are five watchers. Because it is a wrapper template around {{cite news}}, it is not a cs1 template so unless we intentionally decide to redirect all cs1|2 wrapper template talk pages here, we should not redirect Template talk:cite letter here.
Trappist the monk (talk) 00:14, 21 June 2019 (UTC)
I note that 'Template talk:Cite news' redirects here. There is also no certainty that those five watchers remain active. It is five years since anyone responded to an issue raised on 'Template talk:cite letter'. What are the arguments for keeping it (and the talk page of any other such wrapper) as a stand-alone page? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:09, 21 June 2019 (UTC)
{{cite news}} is a cs1 template so its talk page should redirect here because enhancements or fixes to base cs1 templates are discussed here and fixed in Module:Citation/CS1. It is true that the five watchers may no longer be among the living. I see no need to address enhancements to or fixes of wrapper templates here unless those discussions require changes in the module.
Trappist the monk (talk) 11:31, 21 June 2019 (UTC)

subscription=yes[edit]

The subscription=yes was deprecated this year. Maybe it's only me, but I don't get how the five (?) new …-access=… parameters are supposed to work. The general situation is a site using JavaScript to detect an AdBlock and not working at all, if JavaScript is disabled. What is this, …-access=limited or …-access=subscription?
Sometimes I'm too lazy to disallow JS, and get either the complete page with some anti-AdBlock-Ad, a part of the page, or nothing. If I only wanted to verify a reference a part can be already good enough, but maybe a critical BLP detail is not covered in the visible part. In that case I added subscription=yes and ignored the issue (if possible per BLP policy, no wild and wonderful statements.)
Today I tested article-url-access=limited, epic fail, I got confusing error messages about a chapter-url-access=…, and I have no clue what this is:
It is certainly not mentioned on Help:Citation Style 1, it is not explained on Template:Cite web/doc, and the cross-namespace redirection of Template talk:Cite web to Help talk:Citation Style 1 used to be a speedy deletion reason about 12 years ago. @Trappist the monk: please help.Face-sad.svg84.46.53.102 (talk) 03:42, 23 June 2019 (UTC)

There's six of them, but it's unclear what they are for. The docs say If the restriction applies to an identifier, these parameters should be omitted.Since the docs say citations within a given article should follow a consistent style, it looks like the access icons need to be suppressed throughout the article. Face-confused.svg Hawkeye7 (discuss) 05:41, 23 June 2019 (UTC)
Neither of your two diffs show any epic fail. I do see that this edit caused an error message. |article-url-access= is an alias of |chapter-url-access= in the same way that |article-url= is an alias of |chapter-url=. That error message occurs because there is no |article-url= in the citation template, which, in any case, is not supported by {{cite web}}.
I get that the 'chapter' error message is a bit confusing. That issue has been fixed in Module:Citation/CS1/sandbox:
{{cite web/new|url=https://www.smdailyjournal.com/opinion/columnists/young-influencers/article_f5ab5274-b886-11e8-91c4-7375caf77776.html|title=Young influencers|first=Brooke|last=Hanshaw|date=September 15, 2018|website=SMDailyJournal.com|article-url-access=limited}}
Hanshaw, Brooke (September 15, 2018). "Young influencers". SMDailyJournal.com. |article-url-access= requires |article-url= (help)
Trappist the monk (talk) 10:39, 23 June 2019 (UTC)
Thanks, I'll test article-url-access=… again when I stumble over a reference, where nothing is wrong with the URL, but major parts of the article are blurred/hidden, unless "whatever" (registration, subscription, free trial countdown exhausted, no AdBlock, 3rd party cookies required, …) –84.46.53.196 (talk) 21:02, 24 June 2019 (UTC)

Here's my problem:

Lytton, Henry D. (1 April 1983). "Bombing Policy in the Rome and Pre-Normandy Invasion Aerial Campaigns of World War II: Bridge-Bombing Strategy Vindicated - and Railyard-Bombing Strategy Invalidated". Military Affairs. 47 (2): 53–60. ISSN 0026-3931. ProQuest 1296644342.
How do you add the "subscription required"? Hawkeye7 (discuss) 23:51, 23 June 2019 (UTC)
Like this:
{{cite journal |last=Lytton |first=Henry D. |title=Bombing Policy in the Rome and Pre-Normandy Invasion Aerial Campaigns of World War II: Bridge-Bombing Strategy Vindicated - and Railyard-Bombing Strategy Invalidated |journal=Military Affairs |url=https://search.proquest.com/docview/1296644342 |url-access=subscription |issn=0026-3931 |volume=47 |issue=2 |pp=53–60 |date=1 April 1983 |via=[[ProQuest]]}}
Lytton, Henry D. (1 April 1983). "Bombing Policy in the Rome and Pre-Normandy Invasion Aerial Campaigns of World War II: Bridge-Bombing Strategy Vindicated - and Railyard-Bombing Strategy Invalidated". Military Affairs. 47 (2): 53–60. ISSN 0026-3931 – via ProQuest.
{{ProQuest}} in its present form doesn't bring anything to the table. It might if it were rewritten to take advantage of features available in {{Catalog lookup link}} – notably |url-accessn=. But, with only one identifier, not needed here.
Trappist the monk (talk) 00:35, 24 June 2019 (UTC)

Zbl check[edit]

As a follow up on Help talk:Citation Style 1/Archive 36#Zbl error checking and Help talk:Citation Style 1/Archive 39#8 digit ZBL, the Zbl error checking should allow for all numeric (8 digit specifically) possibilities, as Zbl can have temporary assignments, such as Zbl 07013361 and Zbl 06949999 found in Vladimir Mazya, or Zbl 06684722 found in Lou van den Dries.

Those could be put in a Category:CS1 maintenance: Temporary Zbl or similar. Headbomb {t · c · p · b} 17:51, 24 June 2019 (UTC)

I have discovered that part of the code already has a maint cat that has fortunately never been used. The code looks for a 'zbl' prefix in the identifier: |zbl=Zbl 1260.11001. When found, the prefix is stripped and the article added to an undefined category. Because undefined, if ever a zbl had the prefix we would have gotten a glaring red script error. That we haven't (or that no one has complained), perhaps this check is unnecessary. For the moment the check remains in place:
{{cite journal/new |title=Title |journal=Journal |zbl=Zbl 1260.11001}}
"Title". Journal. Zbl Zbl 1260.11001 Check |zbl= value (help).
and a sanity check using the zbl without prefix:
{{cite journal/new |title=Title |journal=Journal |zbl=1260.11001}}
"Title". Journal. Zbl 1260.11001.
Assuming that temporary assignments are always eight digits:
{{cite journal/new |title=Title |journal=Journal |zbl=06066616}}
"Title". Journal. Zbl 06066616.CS1 maint: ZBL (link)
but seven digits:
{{cite journal/new |title=Title |journal=Journal |zbl=6066616}}
"Title". Journal. Zbl 6066616 Check |zbl= value (help).
Trappist the monk (talk) 12:34, 25 June 2019 (UTC)
{{cite journal/new |title=Title |journal=Journal |zbl=Zbl 1260.11001}} ... I don't like that. The error should be pointed out. This isn't like in the case of the PMCID where the 'pmc' is actually part of the identifier. Headbomb {t · c · p · b} 15:46, 25 June 2019 (UTC)
Tweaked.
Trappist the monk (talk) 16:40, 25 June 2019 (UTC)

Nomination for deletion of Template:Cs1 function[edit]

Ambox warning blue.svgTemplate:Cs1 function has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. – Finnusertop (talkcontribs) 19:08, 25 June 2019 (UTC)

Update URL for bibcode tag[edit]

Please update the URL for bibcode=..., for example bibcode=1974AJ.....79..819H form http://adsabs.harvard.edu/abs/1974AJ.....79..819H to https://ui.adsabs.harvard.edu/abs/1974AJ.....79..819H . ADS Classic is now deprecated. It will be completely retired in October 2019. Read here: https://adsabs.github.io/blog/transition-reminder https://adsabs.github.io/blog/ave-atque-vale — Preceding unsigned comment added by Infin2694529 (talkcontribs) 19:30, 25 June 2019 (UTC)

I would personally hold on from that until the last moment we could. The old ADS site is much, muuuuch faster and does not require javascript. Headbomb {t · c · p · b} 20:18, 25 June 2019 (UTC)
Thank you for taking these technical issues in consideration, —PaleoNeonate – 20:22, 25 June 2019 (UTC)
There's a detailed, archived thread here: Help_talk:Citation_Style_1/Archive_56#Old_NASA_ADS_is_retiring_this_summer:_change_Bibcode_URLs_to_new_UI?. The most important response from Kelly from the ADS seems to me to be "in actuality we'll just be taking down the search pages and user accounts. Existing abstract page links will still work indefinitely, though they'll likely redirect to the equivalent pages in the new system at some point in the future."" Given the discussion there, I don't have a strong opinion about whether we should update Template:cite journal and Template:bibcode to the new URL (though switching from http:// to https:// would definitely be justified). Some arguments: In favour of updating: if a URL is going to become a redirect, making it direct will reduce a little bit of wasted cpu power and bandwidth. In favour of delaying: there's no big risk in waiting until the switch to a redirect occurs; delaying will reduce the amount of wasted javascript nonsense and need for uMatrix or similar blocking. I guess we should update the documentation where people expect to find it - probably a brief note at Template:Cite_journal/doc. Boud (talk) 18:57, 30 June 2019 (UTC)
Doc update done. Boud (talk) 19:35, 30 June 2019 (UTC)

Check for final character in several regular fields[edit]

For example, no author name ends with a , or ; or :. We could have a check for

  • |lastn=firstn

to make sure they don't end with such a comma, colon, or semi-colon, giving things like

  • Smith,, James D.:. "Article of stuff". Journal of Things. 24 (4, ): 32.

Likewise for a slew of parameters, which are basically every parameter except

  • |url=
  • |article-url=
  • |chapter-url=
  • |contribution-url=
  • Any other parameters (e.g. |arxiv=) which have their own, more-stringent, checks.

I also propose they are initially made as maintenance categories so they don't get thrown as big red errors to readers while kinks get worked out, and (possibly) corner cases identified.

The only parameters I see this as potentially problematic is |chapter=/|title=/|quote= (for technical documentation, like |title=Reasons not to use & over &amp;).

Headbomb {t · c · p · b} 21:19, 25 June 2019 (UTC)

I've cleaned up ~3000 such so far. Haven't seen an issue with the proposed logic above (for commas), although I did avoid touching |chapter=/|title=. I'll be tackling colons and semicolons next. Headbomb {t · c · p · b} 00:32, 27 June 2019 (UTC)
Dash (-) and its variants is another common trailing garbage character. Yes, please skip URLs. -- GreenC 01:00, 27 June 2019 (UTC)
Checking for these characters is fine, as they indicate a possible problem. But assuming that the problem is simply the presence of such characters, which problem is fixed by removing those characters, invites a bigger problem: overlooking that something might be missing. These characters all imply continuation. E.g., where |chapter=Chapter 1: really should be |chapter=Chapter 1: Introduction. Or |title=A History of the World: is really |title=A History of the World: the Last Five Years. The seemingly extraneous terminal character is actually a signal, or at least a clue, that something else is missing. Looking at this a minor cleanup of extraneous characters removes those clues. If they were to be the basis of a maintenance category there should be an instruction to first check the source to if the chapter/title/whatever needs to be completed. ♦ J. Johnson (JJ) (talk) 19:52, 27 June 2019 (UTC)
Well regardless, |chapter=Chapter 1 is still correct and better |chapter=Chapter 1:, likewise for |title=A History of the World. But that's the sort of thing we'd find out through maintenance categories. This is also why |chapter=/|title= are also a bit different from |pages=, where a |pages=32: is clearly an error. Headbomb {t · c · p · b} 20:04, 27 June 2019 (UTC)
No. "Chapter 1" is better only if that is the full name of the chapter. If the chapter is actually titled "Chapter 1: Introduction", then that is the correct – and thereby better – value. I grant you pagination, but with titles mindless lopping off a character because it is terminal, when really it should be intermedial, loses an indication that the title might be incomplete. ♦ J. Johnson (JJ) (talk) 23:32, 27 June 2019 (UTC)
See truncation and subtitle for why people might refer to Newton's work as |title=The First Three Minutes rather than |title=The First Three Minutes: A Modern View of the Origin of the Universe. Either way, the maintenance category would be appropriate. Headbomb {t · c · p · b} 00:49, 28 June 2019 (UTC)
Because I was curious about how this might be solved, I've hacked the sandbox:
{{cite book/new |title=Title:}}Title:.
{{cite book/new |title=Title |url=//example.com;}}Title Check |url= value (help).
{{cite book/new |title=Title |agency=Agency,}}Title. Agency,.CS1 maint: extra punctuation (link)
{{cite book/new |title=Title |quote=quote,}}Title. quote,
{{cite book/new |title=Title |postscript=;}}Title;
This version of the code looks at every parameter value in a citation except for the parameters that convert to these internal meta-parameters:
	'BookTitle', 'Chapter', 'ScriptChapter', 'ScriptTitle', 'Title', 'TransChapter', 'Transcript', 'TransMap',	'TransTitle',
	'PostScript', 'Quote',
	'ArchiveURL', 'ChapterURL', 'ConferenceURL', 'LayURL', 'MapURL', 'TranscriptURL', 'URL'
If the code finds any one of the characters in the set [,;:] then it adds the article to Category:CS1 maint: extra punctuation.
Trappist the monk (talk) 23:16, 28 June 2019 (UTC)
@Trappist the monk: isn't there also a |delimiter= or |seperator= or something that should be added to the excepted parameters? Headbomb {t · c · p · b} 17:44, 29 June 2019 (UTC)
There used to be |author-name-separator=, |author-separator=, |editor-name-separator=, |editor-separator=, |name-separator=, and |separator=. Those all went away when we adopted |mode=.
Trappist the monk (talk) 19:15, 29 June 2019 (UTC)

Also, I think it's worth thinking about expanding the set to other characters e.g., , ; : & ( ^ [ < ... They don't all have to be done right away, but it's something to think about. It would be good to know what the explicit list of parameters that would have this check so we can see if there are corner cases (e.g. final - in author is an issue, but a final - in |pages= might not be (e.g. |pages=33-), or have a customized list of checks, e.g. pseudocode

finalcheck
, = allowed {quote, url}
. = disallowed {last, editor-last, year, date, volume, issue, pages, page, at, ...}
& = disallowed {all}
; = allowed {chapter, title, quote, ...}
$ = allowed {chapter, title, quote, ...}

Headbomb {t · c · p · b} 17:59, 29 June 2019 (UTC)

Commonly found trailing garbage in URLs includes:

  • [.,;:-l]$ (eg. example.com/index.htmll)
  • "<string>$ (eg. example.com/index.htm"Title")
  • [']{2}<string>$ (eg. example.com/index.htm''Title'')
  • [%][a-z0-9][a-z0-9]$ (exceptions: %22, %29, %5B, %7B) (eg. example.com/index.htm%7C)

-- GreenC 23:56, 28 June 2019 (UTC)

The thing is, urls can end many of those and remain valid. Ending with a comma or a period for example, is perfectly fine, even if it will sometimes be wrong. Headbomb {t · c · p · b} 17:42, 29 June 2019 (UTC)

@Headbomb: right, sometimes wrong:

How often it is not-wrong for comparison is the question. Which is worse tracking or not. -- GreenC 05:11, 30 June 2019 (UTC)

Given you'll have .html endings, or plenty of &value=something with a something that ends in l, I can't see that the false positives would not overwhelm the actual problems. Headbomb {t · c · p · b} 09:38, 30 June 2019 (UTC)
Just check for double l's or "htmll" or "pdfl" etc.. -- GreenC 15:18, 30 June 2019 (UTC)
That could be a separete check for invalid file extensions. Just a final character check isn't good enough for those. Headbomb {t · c · p · b} 17:54, 30 June 2019 (UTC)
It's a trailing garbage check. Limiting it to a single character is arbitrary. When you add something let me know in the mean time my bot keeps fixing problems.[7] -- GreenC 06:09, 1 July 2019 (UTC)

Monkbot[edit]

Now that a bot is changing field names, a concerning issue arises if "website=" can take no wiki-markup. "Website=" automatically italicizes anything in the field. Yet many things, like the names of TV networks (ABC, CNN) and non-periodical sites like Rotten Tomatoes and AllMusic, are not italicized, and having them appear non-italicized in text and italicized in References is inconsistent and contrary to most standard footnoting style. I would note the MOS indicates that non-periodical websites are not italicized and that only this template forces that. What can we do to address this? --Tenebrae (talk) 21:00, 27 June 2019 (UTC)

No. But see #Italics of websites in citations and references – request for comment. --Izno (talk) 21:05, 27 June 2019 (UTC)
This conversation apparently derives from one begun (and now closed because this one exists) on my talk page: User talk:Trappist the monk § Monkbot question.
Trappist the monk (talk) 22:16, 27 June 2019 (UTC)

The bot is doing the right thing. When I cite something I read on https://www.nbc.com, I am not citing the network because the network is on television. 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. If you believe "website=" should not be italicized, let's have that discussion. Or advocate for another parameter for non-periodical websites (but I don't see why they should be treated differently. They are a body of work and should be italicized). Misusing "publisher=" is not a solution no matter how long that has been the status quo. Rotten Tomatoes is published by Fandango. AllMusic is published by RhythmOne. --- Coffeeandcrumbs 04:24, 28 June 2019 (UTC)

Neither AllMusic nor Rotten Tomatoes is italicized, per WP:COMMONNAME and standard usage. And NBCUniversal is not a publisher but an owner. I don't believe Wiikipedia's credibility is helped by redefining words to try to make them fit an arbitrary footnote style. --Tenebrae (talk) 17:31, 28 June 2019 (UTC)
This nothing to do with COMMONNAME which is an article title policy. This is about references. Check MLA, APA, or any citation style. Websites are italicized. Please continue this discussion in the above RfC. --- Coffeeandcrumbs 17:45, 28 June 2019 (UTC)

cite encyclopedia without |title=[edit]

Way back at this discussion → Help talk:Citation Style 1/Archive 4#Looking for trans title for {{cite encyclopedia}}, I wrote code in Module:Citation/CS1 that remaps the various |title=, |article= (or alias), and |encyclopedia= parameters of {{cite encyclopedia}} and {{citation}} templates according to whichever combination of parameters is present. One of those remappings is |encyclopedia= to |title= when |title= and |article= are both missing / empty. What that does is this:

{{cite encyclopedia |encyclopedia=Encyclopedia}}Encyclopedia.
{{citation |encyclopedia=Encyclopedia}}Encyclopedia

I don't know what I was thinking. cs1|2 citations require titles.

Internally, Module:Citation/CS1 copies the value assigned to |encyclopedia= into a meta-parameter Periodical. When there is no |title= and no |article=, then the module copies the content of Periodical to the title meta-parameter Title and resets Periodical to an empty string. This satisfies the requirement for a cs1|2 title. But should it?

I discovered this because I've been working on cleaning up various cs1 wrapper templates that link to wikisource ({{cite EB1911}}, {{cite Catholic Encyclopedia}}, etc). Those templates force a title when |wstitle= and |title= are missing or empty:

<sup>[[Wikisource:1911 Encyclopædia Britannica|<span style="color:red">article name needed</span>]]</sup>

Beyond the fact that there is no title, the problem with this way of dealing with the missing title is that the label portion of that wikilink, the part that goes into the citation's metadata, has html markup which it should not. So, I have tweaked the module to be more like other templates where |title= is missing or empty:

Cite encyclopedia compare
{{cite encyclopedia |encyclopedia=Encyclopedia}}
Live Encyclopedia.
Sandbox Encyclopedia. Missing or empty |title= (help)
Cite encyclopedia compare
{{cite encyclopedia |encyclopedia=Encyclopedia |article=Article}}
Live "Article". Encyclopedia.
Sandbox "Article". Encyclopedia.
Cite encyclopedia compare
{{cite encyclopedia |title=Title |article=Article}}
Live "Article". Title.
Sandbox "Article". Title.
Citation compare
{{citation |encyclopedia=Encyclopedia}}
Live Encyclopedia
Sandbox Encyclopedia Missing or empty |title= (help)
Citation compare
{{citation |encyclopedia=Encyclopedia |article=Article}}
Live "Article", Encyclopedia
Sandbox "Article", Encyclopedia

Trappist the monk (talk) 15:41, 28 June 2019 (UTC)

Maybe you want to reconsider. Encyclopedias are composed of articles, entries, or contributions, and are indexed accordingly. There are no titled works present, apart from the encyclopedia title itself and perhaps, special chapter-titles. Just like {{cite book}} uses |title= as an alias of the "work" (the book). It would make more sense to introduce (in both {{cite book}} and {{cite encyclopedia}}) a parameter |book= and to alias it with |title= rather than increasing the confusion. Edited collections are also books, in print or otherwise. 98.0.246.242 (talk) 01:55, 29 June 2019 (UTC)
I don't think so. This change is not made to do anything more than alert editors that a {{cite encyclopedia}} citation template is missing an article title whether that be |title= or any of the |article= aliases. Restructuring the existing template suite to be more semantically correct may be something that we want to do but that is a topic for another time and place.
Trappist the monk (talk) 09:15, 29 June 2019 (UTC)
And how do you cite the encyclopedia then? Is title=none an option? 98.0.145.210 (talk) 12:17, 29 June 2019 (UTC)
Why would you want to cite an entire encyclopedia instead of a relevant article in an encyclopedia?
Trappist the monk (talk) 12:37, 29 June 2019 (UTC)
If you are including the encyclopedia in a bibliography, or are citing several articles from the same encyclopedia:Nigel Ish (talk) 12:53, 29 June 2019 (UTC)
  • Dear, I. C. B.; Foot, M. R. D., eds. (1995). The Oxford Companion to World War II. Oxford University Press. ISBN 0-19-866225-4.
    • Dear, I. C. B.; Foot, M. R. D., eds. (1995). "Automededon". The Oxford Companion to World War II. Oxford University Press. p. 93. ISBN 0-19-866225-4.
    • Chapman, John (1995). "Signals Intelligence Warfare". In Dear, I. C. B.; Foot, M. R. D. (eds.). The Oxford Companion to World War II. Oxford University Press. pp. 1004–1008. ISBN 0-19-866225-4.
— Preceding unsigned comment added by Nigel Ish (talkcontribs) 12:53, 29 June 2019 (UTC)
All of that repeated bibliographic detail ... (use {{harvc}})
You can do this:
{{cite encyclopedia/new |editor1-last=Dear |editor1-first=I. C. B.|editor2-last=Foot |editor2-first=M. R. D. |title=The Oxford Companion to World War II |year=1995 |publisher=Oxford University Press |isbn=0-19-866225-4}}
Dear, I. C. B.; Foot, M. R. D., eds. (1995). The Oxford Companion to World War II. Oxford University Press. ISBN 0-19-866225-4.
The template is happy because it has a title; the metadata are happy because there is a title. In this form, {{cite encyclopedia}} is mostly the same as {{cite book}} in both its rendering and its metadata.
Trappist the monk (talk) 13:13, 29 June 2019 (UTC)
So, is |title= an alias for "work" (|encyclopedia=) in {{cite encyclopedia}} now? 65.88.88.75 (talk) 15:22, 29 June 2019 (UTC)
This is {{cite encyclopedia}}, it is different. In the discussion I mentioned, I discuss how Module:Citation/CS1 remaps the various parameters. When |title= is empty or omitted, |encyclopedia= is promoted to |title= so that the citation's metadata will have that meaningful information (&rft.btitle=). Given |title= alone, nothing promotes and we have good metadata. |encyclopedia= is not an alias of |title= nor is |title= an alias of |article= though in both cases the former can be promoted to the latter under appropriate conditions.
Trappist the monk (talk) 16:20, 29 June 2019 (UTC)
This maybe the wrong forum. Questions involving basic human understanding of how citations are to be applied in plain everyday English (hopefully), which may be the common lot of the average Wikipedia editor, are answered with technicalities about keeping middleware happy. Why is that? Not asking sarcastically or with any intent to insult or belittle. 24.105.132.254 (talk) 18:51, 29 June 2019 (UTC)
Because I'm a technical sort of person, I write from a technical point of view. This is why I do not write the documentation for these templates.
Trappist the monk (talk) 19:38, 29 June 2019 (UTC)

Add Introduction, Prologue, Foreword, Epilogue, Afterword?[edit]

I don't know how to do this myself, but would Wikipedia and/or fellow Wikipedians please consider how to add both "Introduction" and "Introduction-first"/"Introduction-last" to the book citation template? Ditto for Prologue, Foreword, Epilogue, Afterword? I ask because often one or more experts will kindly not edit a famous book but will add expert commentary before and/or after a book's text. Thank you Aboudaqn (talk) 18:28, 29 June 2019 (UTC)

What part of the book are you citing as a reference, and why does it not work for you to cite that specific part as a contribution within a book rather than requiring separate parameters? —David Eppstein (talk) 18:37, 29 June 2019 (UTC)
{{cite book}} supports |contribution= and |contributor= (and firt/last variants):
{{cite book |title=Title |author = Author |contribution=Preface |contributor=Contributor}}
Contributor. Preface. Title. By Author.
This feature is only for {{cite book}} (or book cites using {{citation}}).
When the book's author or editor also wrote the preface, introduction, ... use |chapter= or |contribution=.
Trappist the monk (talk) 19:30, 29 June 2019 (UTC)

Dates in author field[edit]

Hello, I have located around 200 |author= fields that contain a date of some form prefixed by "Published". Would be good if someone could move the date detail to the |date= field, assuming the field is blank, formatting it appropriately. If the |date= matches the date in the |author= field then ignore it. In either case just blank the |author= field. Hopefully that should just leave a few cases to handle manually where the date from the |author= field does not match the |date= field. Keith D (talk) 19:59, 29 June 2019 (UTC)

bibcode/ADS - URL base is deprecated[edit]

The cite journal template needs to be updated. I couldn't find which particular page codes for the bibcode= parameter in cite journal, so sorry if this is the wrong talk page. See my fix of the direct bibcode template for what needs doing. For example,

The fix will affect a huge amount of pages. Double-check and triple-check before hitting "Publish changes"...! Boud (talk) 01:55, 30 June 2019 (UTC)

We have already discussed this here and here. Please search before making a new thread in the future. --Izno (talk) 13:27, 30 June 2019 (UTC)
I reverted the change at Template:Bibcode, the javascript version load times for abstract pages are way too massive right now to be worth switching to the new UI. Headbomb {t · c · p · b} 17:53, 30 June 2019 (UTC)
Thanks for the fast responses. Izno: to repeat what I stated above: I did spend quite a bit of time trying to find which page contained the actual coding for the old URL, and I was unsuccessful. It's not obvious that discussion of Template: fixes should go on a talk page in the Help: namespace. My search obviously missed the archival talk page Help talk:Citation Style 1/Archive 56. Anyway, I'll continue in the non-closed thread. Boud (talk) 18:41, 30 June 2019 (UTC)

Books with volumes and parts[edit]

Some books are differentiated from each other by volumes and parts. For example:

  • "Smith (1900) History of Apples, Vol. 1"
  • "Smith (1901) History of Apples, Vol. 2, Part 1"
  • "Smith (1902) History of Apples, Vol. 2, Part 2".

How would I cite the last two? If I use the "issue" parameter in 'cite book' template it doesn't show:

  • Smith (1901). History of Apples. 2.
  • Smith (1902). History of Apples. 2.

--Brianann MacAmhlaidh (talk) 22:50, 3 July 2019 (UTC)

There is no 'official' way to do what you want. Why? Don't know. Insufficient interest or need? The metadata standard for books that {{cite book}} uses doesn't support part. The metadata standard doesn't support issue or number for books either which is why {{cite book}} doesn't support those parameters. One way to accomplish what you want is this:
{{cite book |last=Smith |title=History of Apples |year=1901 |volume=2 |at=pt. 1}}
Smith (1901). History of Apples. 2. pt. 1.
If you are citing specific pages in that part, then |at=pt. 1 pp. 75–83
Trappist the monk (talk) 00:13, 4 July 2019 (UTC)
Brianann MacAmhlaidh I've had the same issue. What I end up doing is just {{citation}} with |mode=cs1, as in
  • Smith (1902). History of Apples. 2 (2).
It'd be great if {{cite book}} allowed both |volume= and |issue=, but this work-around ends up producing the right results. Umimmak (talk)
Don't rely on that work-around remaining. It is a bug that should be fixed.
Trappist the monk (talk) 11:50, 4 July 2019 (UTC)
Why would this be considered a bug that needs fixing? Umimmak (talk) 23:05, 4 July 2019 (UTC)
From the {{citation}} documentation:
"If the correct parameters are used, this template produces output identical to that of the Cite templates, such as {{Cite book}} and {{Cite web}}, ..." (The documentation goes on to talk about separators and automatic anchor generation.)
{{cite book}} does not support |issue= so book citations rendered with {{citation}} should do the same. The journal-style volume and issue format rendered by your example looks like a journal cite without an article title – a style that is allowed in journal citations where |title=none. As you can see, your example mimics that style but produces invalid metadata were it used to create journal citations without article title.
Trappist the monk (talk) 00:07, 5 July 2019 (UTC)
One thing I've love to have is that books would display "Vol. " (or the full "Volume" or "vol." or whatever). I.e.
Sunada, T. (2013). "Generalities on Graphs". In Bloch, A.; Epstein, C.L.; Goriely, A.; Greengard, L. (eds.). Topological Crystallography. Surveys and Tutorials in the Applied Mathematical Sciences. Vol. 6, pp. 21–35. Tokyo: Springer. doi:10.1007/978-4-431-54177-6_3. ISBN 978-4-431-54177-6.
instead of
Sunada, T. (2013). "Generalities on Graphs". In Bloch, A.; Epstein, C.L.; Goriely, A.; Greengard, L. (eds.). Topological Crystallography. Surveys and Tutorials in the Applied Mathematical Sciences. 6. Tokyo: Springer. pp. 21–35. doi:10.1007/978-4-431-54177-6_3. ISBN 978-4-431-54177-6.CS1 maint: Uses editors parameter (link)
which is completely unclear. And even group Vol. 6, pp. 21–35. together for sanity. Headbomb {t · c · p · b} 02:18, 4 July 2019 (UTC)
I am fairly certain the bolding in cite book is new, and is basically {{cite journal}} leaking its styling... but that may just be my bad memory. --Izno (talk) 03:14, 4 July 2019 (UTC)
{{cite book}}, even in olden days, bolded |volume=:
Cite book compare
{{cite book |chapter=Generalities on Graphs |last=Sunada |editors=Bloch, A.; Epstein, C.L.; Goriely, A.; Greengard, L. |isbn=978-4-431-54177-6 |doi=10.1007/978-4-431-54177-6_3 |series=Surveys and Tutorials in the Applied Mathematical Sciences |title=Topological Crystallography |publisher=Springer |year=2013 |volume=6 |location=Tokyo |pages=21–35 |first=T.}}
Old Sunada, T. (2013). "Generalities on Graphs". In Bloch, A.; Epstein, C.L.; Goriely, A.; Greengard, L.. Topological Crystallography. Surveys and Tutorials in the Applied Mathematical Sciences. 6. Tokyo: Springer. pp. 21–35. doi:10.1007/978-4-431-54177-6_3. ISBN 978-4-431-54177-6. 
Live Sunada, T. (2013). "Generalities on Graphs". In Bloch, A.; Epstein, C.L.; Goriely, A.; Greengard, L. (eds.). Topological Crystallography. Surveys and Tutorials in the Applied Mathematical Sciences. 6. Tokyo: Springer. pp. 21–35. doi:10.1007/978-4-431-54177-6_3. ISBN 978-4-431-54177-6.CS1 maint: Uses editors parameter (link)
Trappist the monk (talk) 11:50, 4 July 2019 (UTC)

A related issue is that a book may have multiple volumes for its particular title, and also have a different numbering as a volume within a book series. What I've usually resorted to in such cases is to put, e.g. "Vol. I" into the title parameter, and use the volume parameter for the book series volume number. —David Eppstein (talk) 19:01, 4 July 2019 (UTC)

As I noted earlier in this discussion, {{citation}} is broken. I've tweaked the sandbox to fix that:

book and encyclopedia cites do not show issue:

  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |year=1902 |volume=2 |issue=2}}Smith (1902). History of Apples. 2.
  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |encyclopedia=Encyclopedia |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Encyclopedia. 2.

periodical cites (|journal=, |magazine=, |news=) show issue:

  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |journal=Journal |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Journal. 2 (2).
  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |magazine=Magazine |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Magazine. Vol. 2 no. 2.
  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |newspaper=Newspaper |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Newspaper. 2 (2).

web cites (|website=) show neither volume nor issue:

  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |website=Website |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Website. Missing or empty |url= (help)

|script-<periodical>= except |script-website= show both volume and issue:

  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |script-journal=ar:Script-Journal |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Script-Journal. 2 (2).

with |script-website= shows neither volume nor issue:

  • {{citation/new|mode=cs1 |last=Smith |title=History of Apples |script-website=ar:Script-Website |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Script-Website. Missing or empty |url= (help)

cs1 templates to show that I haven't broken anything:

  • {{cite encyclopedia/new |last=Smith |title=History of Apples |encyclopedia=Encyclopedia |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Encyclopedia. 2.
  • {{cite news/new |last=Smith |title=History of Apples |newspaper=Newspaper |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Newspaper. 2 (2).
  • {{cite web/new |last=Smith |title=History of Apples |website=Website |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Website. Missing or empty |url= (help)

with |script-<periodical>=:

  • {{cite journal/new |last=Smith |title=History of Apples |script-journal=ar:Script-Journal |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Script-Journal. 2 (2).
  • {{cite web/new |last=Smith |title=History of Apples |script-website=ar:Script-Website |year=1902 |volume=2 |issue=2}}Smith (1902). "History of Apples". Script-Website. Missing or empty |url= (help)

While making these fixes, I also noticed that {{citation|website=...}} without |url= does not show the missing url error message. Fixed that:

Citation compare
{{citation |website=Website |title=Title}}
Live "Title", Website
Sandbox "Title", Website Missing or empty |url= (help)

Trappist the monk (talk) 16:44, 5 July 2019 (UTC)

I've never liked the way "volume" appears for books. The template uses the form appropriate for journals. Would it be possible for it to render as "Vol. XXX" like suggested above? Hawkeye7 (discuss) 01:36, 15 July 2019 (UTC)

How to handle a pseudonym[edit]

A book that appeared with the author given on the title page as "A Virginian", but you know his real name, how is this best handled? I wish there were a "pseudonym" field.

Please don't get off on how we know the real name. That's a different topic.

This was posted unsuccessfully at Teahouse. Thanks for any help. deisenbe (talk) 01:42, 5 July 2019 (UTC)

You cite the work as it appears in the copy you referenced. --Izno (talk) 02:30, 5 July 2019 (UTC)
You can also mention the author's actual identity in the article's prose (ideally with a citation confirming the identity), while leaving the citation to have however the author is listed in the source. As to how to include it, CMOS 17 has some guidelines which you might be interested in: If a work is attributed to an invented or descriptive name, and the author’s real name is not known, pseud. (roman, in brackets) may follow the name, especially if it might not be immediately clear to readers that the name is false (as in the first two examples below). (An initial The or A may be omitted. In a text citation, or in a shortened form in a note, pseud. is usually omitted.), A widely used pseudonym is generally treated as if it were the author’s real name., The real name, if of interest to readers, may follow the pseudonym in brackets., If the author’s real name is better known than the pseudonym, the real name should be used. Umimmak (talk) 04:31, 5 July 2019 (UTC)
Alas, CMOS is not cs1|2. Editor Izno is correct. Cite the author as identified in the work that you consulted. Extraneous text of any sort does not belong in cs1|2 template parameters.
Trappist the monk (talk) 10:46, 5 July 2019 (UTC)
Which is not to say that notes cannot be left outside the citation-proper, whether inside the ref tag or in the article-proper. If the author or even his pseudonym is notable, one can also link the page instead of either of those two workarounds. --Izno (talk) 13:53, 5 July 2019 (UTC)
If the author has a separate article, you can also use an article-link parameter to link to the article. If you do that, the linked article should mention the pseudonym, to avoid confusing readers. —David Eppstein (talk) 20:53, 5 July 2019 (UTC)

Display problem with issue parameter[edit]

When issue=10,000 is used in {{cite news}} (e.g. to cite a daily newspaper), the number is displayed as 10, 000 (with a space), which goes against MOS:DIGITS. If issue=10000 is used, template shows 10000 (without a comma), which is also against the Manual of Style. issue=1,000 produces the same result, but at least it can be avoided, as 1000 is accepted by the MOS: Numbers with exactly four digits left of the decimal point may optionally be grouped (either 1,250 or 1250), provided that this is consistent within each article. SLBedit (talk) 01:15, 14 July 2019 (UTC)

Related discussion.
Trappist the monk (talk) 03:01, 14 July 2019 (UTC)

Why no doi-access=subscription?[edit]

Why is the option doi-access=subscription not allowed when in fact most DOI lead to journal websites that require subscription or access via university libraries? --bender235 (talk) 15:38, 15 July 2019 (UTC)

The norm in access requirements is not indicated. However, I believe a registration option should be allowed for subscription-normal content identifiers such as doi or jstor. I have encountered registration-required access situations for both. 72.43.99.130 (talk) 15:46, 15 July 2019 (UTC)
There is a url-access=subscription, which is why I was asking. --bender235 (talk) 15:49, 15 July 2019 (UTC)
Because, for named identifiers, the linked source usually lies behind some sort of registration barrier or paywall. When that isn't the case, that is when (for |doi= as an example) |doi-access=free should be used. For |url=, the norm is that the linked source is usually free-to-read. When that isn't the case, that is when |url-access=subscription, |url-access=registration, or |url-access=limited should be used.
This is explained in the template documentation: Template:Citation Style documentation § Subscription or registration required. Is the documentation insufficient?
Trappist the monk (talk) 16:13, 15 July 2019 (UTC)
Maybe it would be good to accept the value instead of reject it and then display nothing, as well as a maintenance message. --Izno (talk) 17:50, 15 July 2019 (UTC)
meh. Then no one learns anything and it becomes busy work for some bot or dedicated gnome to fix. And we'll start getting: 'I added |doi=subscription but it isn't showing the red lock. How come?'
Trappist the monk (talk) 20:01, 15 July 2019 (UTC)
As mentioned above, |doi|jstor=registration should be added for content that requires registration only. Without this clarification, readers are not offered an existing path to non-paid verification. 65.88.88.91 (talk) 18:24, 15 July 2019 (UTC)
That will just add complication and confusion. The rule is as simple as I think we can make it: sources linked by the named identifiers are behind some sort of restrictive barrier unless marked otherwise with |<identifier>-access=free.
Trappist the monk (talk) 20:01, 15 July 2019 (UTC)
I don't understand who would be confused by this? There is already a similar array of access options for |url= and I cannot remember anybody complaining about it. The same array of options (with allowances for the access norm) should be extended to all content identifiers. The specific case has the potential to make verifiability easier/more accessible. I would think this would make it a no-brainer. 65.88.88.91 (talk) 20:39, 15 July 2019 (UTC)
Oh, so for DOI "subscription" is the default, and "free" would be the exceptional case. I see. But shouldn't the template then display the little red lock Paid subscription required by default, too? --bender235 (talk) 19:31, 15 July 2019 (UTC)
Not quite. For most identifiers, the default is: not-free-to-read. The default state says nothing about what kind of restrictions the publisher has placed on the source. We do not highlight the norm and, because there are subscription, registration, and limited access options, it is not possible for the templates to apply an appropriate lock icon without being told what that lock icon should be.
Trappist the monk (talk) 20:01, 15 July 2019 (UTC)
@Bender235: we had this exact debate when we implemented this - I was of the same opinion as you, but we could only get the change to pass in this form. − Pintoch (talk) 12:14, 19 July 2019 (UTC)

Fill in archive-date automatically[edit]

When adding an archive link, the archive-date has to be entered manually, even if the archive-url already contains it:

https://web.archive.org/web/20020120142510/http://example.com/

Many other archives besides Wayback include the date (also the source URL) in the snapshot URL as well.

Couldn't this be automated? That would be more convenient, and less error-prone. Toxide (talk) 10:57, 17 July 2019 (UTC)

This was also cross-posted at Template talk:Webarchive § Fill in date automatically?. One conversation in one place, I have answered here.
Related discussion: Help talk:Citation Style 1/Archive 39 § Archive-date parameter
I can imagine that {{webarchive}} and the cs1|2 modules might share some bit of code that would extract an archive date from |archive-url={{webarchive}} already does this. I have not determined whether or not that functionality is easily shared without substantial changes to either or both of cs1|2 and {{webarchive}}.
In the best of all possible worlds, it would seem to me that if we are to adopt this, |archive-date= should go away entirely but that would mean that anything put in |archive-url= must have an encoded archive date. At present, there is no requirement that |archive-url= hold a url of an archival service (though best-practices would suggest that non-archival-service urls are suspect).
Trappist the monk (talk) 14:35, 17 July 2019 (UTC)
Not all archive services use 14-digit timestamps, or don't use them by requirements. WP:WEBARCHIVES lists the archive providers in use on Enwiki (there are others in other languages not listed) though new archive providers do appear may not be listed here. WP:WEBARCHIVES shows the URL formats we are dealing with and any software would be expected to parse. As you can see, not all use 14-digit timestamps. -- GreenC 15:14, 17 July 2019 (UTC)
It is possible for the software to compare the date in |archive-date= with the 14-digit timestamp, if it exists, and generate a red tracking message about a mismatch. {{webarchive}} already does this and CS1|2 might also. My bot WaybackMedic is able to fix these, and on occasion runs through the {{webarchive}} tracking category to clear it. -- GreenC 15:19, 17 July 2019 (UTC)

Author affiliation for cite journal? (As in the university an author works at), and also adding editors of books with chapters written by different people?[edit]

1. Has anyone considered adding author affiliation as a feature of cite journal? For example in Ottoman_constitution_of_1876#Further_reading I wanted to state the university affiliation of a journal article author, but that would mean putting parentheses in the author field. Is there a way for the template to display affiliation in this way without having parentheses in the author field?

2. I haven't used citation templates to cite works where a book contains multiple essays written by different people, as you have the author of the essay itself and then the editors of the book in question. Is this functionality there in the template? If not, would it be OK to add it?

Thanks, WhisperToMe (talk) 21:32, 17 July 2019 (UTC)

An affiliation is not part of an author's name so doing as you did at Ottoman constitution of 1876 § Further reading:
|author=Korkut, Huseyin ([[Kırklareli University]])
corrupts the author metadata (not only the parentheses but also the wikimarkup).
What is really missing from that citation template is the journal. With the next release of the cs1|2 module suite, {{cite journal}} will require |journal=
Edited books with multiple section / chapter / entry authors is supported:
{{cite book |author=Author |chapter=Chapter Title |editor=Editor |title=Book Title}}
Author. "Chapter Title". In Editor (ed.). Book Title.
Trappist the monk (talk) 21:53, 17 July 2019 (UTC)
Thanks for the info! In that case it would be nice to add an "affiliation" function so that can be noted after each author. As for the editor function, I'll try that. I'll see if multiple editors may be supported WhisperToMe (talk) 23:16, 17 July 2019 (UTC)
I was able to get an instance working at History of the Central Americans in Houston! I wonder how to get both ISBNs in, though, as I looked at the documentation and couldn't see how to enter ISBN-10 and ISBN-13 separately WhisperToMe (talk) 23:22, 17 July 2019 (UTC)
I've never seen a citation style where the institutional affiliation of each author gets included; that seems like unnecessary clutter. |editorN-first= and |editorN-first= can support different numbers of N to allow multiple editors. I also don't see the reason to include an ISBN-10 when you have access to an ISBN-13. Just cite the ISBN-13. Umimmak (talk) 23:51, 17 July 2019 (UTC)
In many academic journal articles it's common to name the university the author works at, and to do so prominently (in the lead of the article and/or with a footnote attached to the name). Based on the prominence there, I thought that in academic journal citations it's important to indicate the author's institution in parentheses. WhisperToMe (talk) 00:11, 18 July 2019 (UTC)
It's common to do so in the article itself, but I have never seen it in a citation – our citations have enough overkill already. Triptothecottage (talk) 00:14, 18 July 2019 (UTC)
But those don't ever appear in citations. Journal articles often also include the authors' email addresses but it would be overkill to have that in a citation to that paper. If the authors' institutional affiliation is essential, then you can mention it in the article prose -- not in the citation. Umimmak (talk) 00:26, 18 July 2019 (UTC)
I agree with others, it is non-standard in academic writing to include the author's affiliation in the citation. If it's important, it's important enough to mention in the text instead of in the citation, like this

John Doe, director of the Institute of Dust Bunny Studies, stated that....34

Jc3s5h (talk) 10:29, 18 July 2019 (UTC)
Fair enough... I'll just mention it in the prose. WhisperToMe (talk) 11:37, 18 July 2019 (UTC)

Another thing I'd like to explore: Is there a function where a URL can be given for a particular page in a book and that makes the page number clickable? The reason why I want this is that I want the title of the book to serve as a Wikipedia link to an article about the book itself (I often intentionally write Wikipedia articles about books used as sources so readers can learn about the background of the book), while the page number would be the place where one can click for the source content. WhisperToMe (talk) 11:37, 18 July 2019 (UTC)

{{cite book |author=Author |chapter=Chapter Title |editor=Editor |title=Book Title |page=[//example.com 25]}}
Author. "Chapter Title". In Editor (ed.). Book Title. p. 25.
Trappist the monk (talk) 12:03, 18 July 2019 (UTC)
Thank you! WhisperToMe (talk) 12:21, 18 July 2019 (UTC)

access icon parameter value bug[edit]

This bug has been in the code since we added support for the access icons. Surprising that it's not been noticed until now. Fixed in the sandbox:

Cite book compare
{{cite book |chapter=Chapter |chapter-url-access=Subscription |title=Title |chapter-url=//example.com}}
Live Lua error in Module:Citation/CS1 at line 427: attempt to index field '?' (a nil value).
Sandbox "Chapter". Title. Invalid |chapter-url-access=Subscription (help)

Trappist the monk (talk) 22:28, 17 July 2019 (UTC)

Thank you for this fix! − Pintoch (talk) 12:12, 19 July 2019 (UTC)

cite ssrn[edit]

Harking back to this discussion, I found this:

{{Cite journal|last=Balding|first=Christopher|last2=Clarke|first2=Donald|date=17 April 2019|title=WHO OWNS HUAWEI?|url=https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3372669|journal=SSRN|volume=|page=4|pages=15|via=SSRN}}
Balding, Christopher; Clarke, Donald (17 April 2019). "WHO OWNS HUAWEI?". SSRN: 4 – via SSRN. More than one of |pages= and |page= specified (help)

and that lead me to create {{cite ssrn/new}} to become {{cite ssrn}} after the next module update:

{{cite ssrn/new |last=Balding |first=Christopher |last2=Clarke |first2=Donald |date=17 April 2019 |title=Who Owns Huawei? |ssrn=3372669 |page=4}}
Balding, Christopher; Clarke, Donald (17 April 2019). "Who Owns Huawei?". p. 4. SSRN 3372669.

Like {{cite arxiv}}, {{cite bioRxiv}}, and {{cite citeseerx}}, this template accepts only a limited subset of the cs1|2 parameters.

Keep? Discard?

Needs documentation which I leave to someone else.

I will note that {{cite citeseerx}} still needs documentation ...

Trappist the monk (talk) 23:56, 18 July 2019 (UTC)

The solution, I feel, is to create a {{cite preprint}} and ultimately redirect cite arxiv/biorxiv/citeseerx/ssrn there, or have {{cite arxiv}} be a wrapper of {{cite preprint|mode=arxiv}} or something. But that might be more complex than individual templates. Headbomb {t · c · p · b} 00:57, 19 July 2019 (UTC)
Yeah, maybe. Not clear to me how such a template would handle metadata if it were presented with more than one identifier (specifically rft.jtitle). That suggests that only one of |arxiv= (or |eprint=), |biorxiv=, |citeseerx=, or |ssrn= would be allowed in any one instance of {{cite preprint}}. That means that the preprint parameters would all be pseudo-aliases of each other for the purpose of duplication detection (and error messaging) but as individual parameters for the purpose of rendering the proper link.
Trappist the monk (talk) 11:53, 19 July 2019 (UTC)

|url=?[edit]

I just ran across this:

{{Cite arXiv|url=https://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks.pdf|title=Sequence to sequence learning with neural networks|last=Sutskever|first=I.|last2=Vinyals|first2=O.|date=2014|website=|publisher=NIPS'2014|access-date=|last3=Le|first3=Q. V.|eprint=1409.3215|class=cs.CL}}
Sutskever, I.; Vinyals, O.; Le, Q. V. (2014). "Sequence to sequence learning with neural networks" (PDF). NIPS'2014. arXiv:1409.3215 [cs.CL]. Unknown parameter |publisher= ignored (help)

This template makes me wonder if supporting |url= in {{cite arxiv}} and the other preprint templates is the correct thing. For this particular example, I would say no. In this case, the paper was presented at the Twenty-eighth Conference on Neural Information Processing Systems (NIPS 2014 video of the talk linked from the conference schedule). So, this template is one that is better rewritten to use {{cite conference}} (which I will do).

Is there any reason that the identifier-based preprint templates need |url=?

Trappist the monk (talk) 14:25, 21 July 2019 (UTC)

On requiring the journal parameter[edit]

I read above that:

With the next release of the cs1|2 module suite, {{cite journal}} will require |journal=

Are we sure about this? There are thousands of journals which use DataCite DOIs, but the funny thing (as someone highlighted to me at some recent conferences) is that the DataCite schema doesn't have a field for the journal name. This might be dismissed as irrelevant but is a sign of what is considered important. Nemo 13:27, 19 July 2019 (UTC)

I see no reason not to require |journal= when using {{cite journal}} – that is, after all, the purpose of the template.
Shouldn't the data that support a journal article be cited from that journal article and not from a Wikipedia article?
Aren't the data that the author(s) used in their research and from which they drew their conclusions, a primary source that is not subject to the normal editorial processes of publication and review? (WP:PRIMARY)
If it is determined that citing research data is an appropriate thing to do, then shouldn't cs1|2 have a template specific to that requirement so that editors don't misuse other templates? ({{cite data}})
Trappist the monk (talk) 14:42, 19 July 2019 (UTC)
Primary sources can be used in Wikipedia with care. One might imagine, for example, a definition that needs to be precisely stated in a Wikipedia article, but the term is undefined, or vaguely defined in a journal article; the precise definition needs to be retrieved from the data. Or perhaps two different journal articles appear to rely on the same data, and citations to the data for each article are needed to confirm this.
The problem with a special template that doesn't exist is that an editor can't be expected to wait for one of the few people who understand the monster that the citation templates have become to provide a special template. The editor would hand-code a citation. The editor would even be justified in rewriting every citation in the article to some other style that doesn't require templates, to avoid the suppression of acceptable sources by inadequate software. Jc3s5h (talk) 15:07, 19 July 2019 (UTC)
I don't think that I said that primary sources could not be used. I do question the validity of citing research data here, at Wikipedia, because raw data are so often subject to interpretation which editors here should not be doing. I accept that there may be the occasional need to cite research data. If we are going to support that, we should provide a template specifically tailored to that task.
Yeah, such a template doesn't exist. So what? If it is needed it will be created and yeah, that creation won't be instantaneous. Again, so what?
Trappist the monk (talk) 18:55, 19 July 2019 (UTC)
@Trappist the monk: There is a reason, {{cite paper}} and {{cite document}} redirect to {{cite journal}}. Headbomb {t · c · p · b} 16:07, 19 July 2019 (UTC)
I spent a few minutes looking at a few dozen {{cite paper}} and {{cite document}} transclusions. From that small sample, it seems to me that most could be (should be) rewritten to use a more appropriate template; obvious choices for the citations that I inspected were: {{cite arxiv}}, {{cite book}}, {{cite citeseerx}}, {{cite conference}}, {{cite journal}}, {{cite thesis}}, {{cite web}}. Template redirects do not act any differently from the template that they alias; editors should not expect different action simply because of a redirect's name. Perhaps this exercise will show that we need separate {{cite paper}} and {{cite document}} templates.
Trappist the monk (talk) 18:55, 19 July 2019 (UTC)
Perhaps they should be rewritten before you break them all by making |journal= mandatory? —David Eppstein (talk) 22:08, 19 July 2019 (UTC)
If the objective is to require that "cite journal" is only used for documents which belong to some kind of "journal", also known as "papers", I suspect that requiring to provide a journal name is not the easiest or most efficient way to do it. Nemo 17:12, 19 July 2019 (UTC)
{{cite journal}} is a periodical template – always has been. Individual papers and documents are not periodicals. We already have some templates that are suitable for citing preprints of individual papers so it isn't much of a stretch to imagine that we should also have templates specifically for citing individual papers and documents – the {{cite paper}} redirect might be usurped for that purpose and the {{cite document}} redirect pointed at {{cite paper}} instead of {{cite journal}}.
You suspect that requiring to provide a journal name is not the easiest or most efficient way to ensure that journal cites name the journal. State the better method; don't just leave us hanging ...
Trappist the monk (talk) 18:55, 19 July 2019 (UTC)
I'd be more than fine having a fork of {{cite paper}}/{{cite document}} as a distinct template from {{cite journal}} if we're going to make |journal= mandatory. Likely first as a maintenance category to see how bad things are have a preliminary round of cleanup through citation bot and the like. Headbomb {t · c · p · b} 20:42, 19 July 2019 (UTC)
The better method is something both understandable to users and easy to verify. I would personally prefer a superset of the publications eligible for plan S, namely one of their requirements which is easy to use: «Use of persistent identifiers (PIDs) for scholarly publications (with versioning, for example, in case of revisions), such as DOI (preferable), URN, or Handle».
On the other hand, if the objective is to prevent usage of this template by articles or depending templates for unforeseen citations which end up creating undue style demands or other hurdles for the maintainer(s) of this template, I don't have an easy answer. I wish we could fix the (technical? social?) problem with those usages rather than force their hand by breaking them. Nemo 09:34, 20 July 2019 (UTC)
Plan S is fine and all, but that retroactively make some self-published 1928 paper from Johann Gambolputty all of a sudden become published and have a DOI. Headbomb {t · c · p · b} 10:08, 20 July 2019 (UTC)
Surely we don't expect a wikitext condition to be able to take care of such undesired events though. Nemo 10:41, 20 July 2019 (UTC)
Sure. With cite paper. Not cite journal. Headbomb {t · c · p · b} 11:02, 20 July 2019 (UTC)
(edit conflict)
I think that you are describing a solution to a problem that isn't the journal-cite-without-journal-title problem. I do not think that there should be any requirement for persistent identifiers in {{cite journal}} because there likely to be sources that can use {{cite journal}} that lived and died before persistent identifiers were invented. Nor do I think that a persistent-identifier-requirement is a solution to your research data concern.
An actual {{cite paper}} template to replace the redirect to {{cite journal}} would handle individually published papers that do not belong to some kind of "journal". This template can use but must not require persistent identifiers, does not allow |journal= or aliases, gets the metadata right. {{cite paper}} should require |publisher= because WP:V. These same might apply to a {{cite data}} template were we to decide that citing research data is something that cs1|2 should support.
Trappist the monk (talk) 11:13, 20 July 2019 (UTC)

Break Category:Pages with DOIs inactive as of 2019 into months[edit]

3000 pages makes it very hard to check what's backlogged vs what's newly broken. Breaking down by months would make it easier to manage. Headbomb {t · c · p · b} 07:19, 20 July 2019 (UTC)

I've tweaked Module:Citation/CS1/Identifiers/sandbox so that it adds a sortkey to the category when it can decode a month value from |doi-broken=
To prove that it is working, copy this:
{{cite journal/new |title=Title |journal=Journal |doi=10.1212/something |doi-broken=January 2019}}
into Special:ExpandTemplates (the Input wikitext box) to see the category with sortkey (cs1|2 does not add categories when in the Help talk namespace). Change the date, give it invalid date, etc.
When not given a month, does not add a sortkey. We might want to change that so that month-less articles don't sort by article-name first-letter. Might also want to change the sort key from month-name to month number.
Another option is to create subcategories: Category:Pages with DOIs inactive as of 2019/January
Trappist the monk (talk) 13:18, 20 July 2019 (UTC)
I would much prefer monthly categories. A sortkey, numerical or not, would not let you easily separate items by date (J = January, June, July; 1 = January, October, November, December). Headbomb {t · c · p · b} 17:19, 20 July 2019 (UTC)
Ok, Category:Pages with DOIs inactive as of 2019 January
Trappist the monk (talk) 10:59, 21 July 2019 (UTC)

Support citewatch=... or something like it[edit]

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

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

And, upon the next bot run a table like this

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

could be updated to something like

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

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

This is a terrible idea - it isn't the purpose of relatively obscure wikiprojects to declare themselves the arbiter of what is a reliable source and what isn't (or to promote themselves using what is effectively the standaed reference system on Wikipedia - we shouldn't be giving references a badge of shame based on a very localised and dubious idea of what is reliable and what isn't - suspect sources should be discussed at Wikipedia:Reliable sources - if deemed unreliable for the context it should be removed, and if reliable for the use, it should be kept.Nigel Ish (talk) 20:45, 20 July 2019 (UTC)
@Nigel Ish: It's not a thing that would be in any way visible to the reader. It would simply be to have |cw-check=yes not throw an error like it currently does (e.g. Smith, J. (2006). "Foobar". Quack Journal of Nonsense. 23 (3): 24. doi:10.1234/123456789. Unknown parameter |cw-check= ignored (help)). Likewise, WP:CITEWATCH does not take a position on weather or not a source is appropriate to cite, it just raises a flag that it's probably a good idea to double check. Headbomb {t · c · p · b} 20:55, 20 July 2019 (UTC)
My suggestion would be to have a param to signify whether the citation is being used as a primary source. That way, editors reviewing known unreliable sources can quickly parse how the citation is being used. Such a use case wouldn't be limited to citewatch. czar 20:50, 20 July 2019 (UTC)