Help talk:Citation Style 1

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

Stop linking paper title to PMC

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

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

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

The following pages have been notified

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

Responses

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  (edit conflict)

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

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

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

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

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

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

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

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

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

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

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

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)

Discussion and alternatives

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

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

Closing

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

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

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

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

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

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

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

Odd PMC error

PMC 6509194 appears to be valid, yet displays the following warning:

• Carroll LM, Gaballa A, Guldimann C, Sullivan G, Henderson LO, Wiedmann M (May 2019). "Identification of Novel Mobilized Colistin Resistance Gene mcr-9 in a Multidrug-Resistant, Colistin-Susceptible Salmonella enterica Serotype Typhimurium Isolate". mBio. 10 (3): e00853–19. doi:10.1128/mBio.00853-19. PMC 6509194. PMID 31064835.

Any ideas on what triggered this warning? Boghog (talk) 11:35, 18 May 2019 (UTC)

pmc is just digits. To detect too many digits (because of typo or whatever) there is a limit to the max value of the digits. The limit value for the test is currently 6500000. I will change that to 7000000.

—Trappist the monk (talk) 11:46, 18 May 2019 (UTC)

Thanks for the explanation and for fixing it. Boghog (talk) 13:46, 18 May 2019 (UTC)

@Boghog: Could we change it to 9999999 (or something similar) so we don't run into this problem again in a few years (especially since a lot of smaller wikis copy our templates)? Kaldari (talk) 16:12, 20 May 2019 (UTC)

fixed in the live module because nothing else changes in Module:Citation/CS1/Identifiers and because normal update won't happen until after the completion or the two rfcs on this page (here and here).

—Trappist the monk (talk) 10:28, 6 June 2019 (UTC)

cite citeseerx

We have a template {{cite citeseerx}}. It doesn't have any documentation.

{{cite citeseerx}} is treated like {{cite arxiv}} and {{cite biorxiv}} in that it supports a limited subset of the cs1 parameter set and, in the metadata, as a preprint citation, but is it? Our CiteSeerX article doesn't use the term 'preprint' so shouldn't citeseerx metadata specify rft.genre=article or possibly, something else?

—Trappist the monk (talk) 13:03, 23 May 2019 (UTC)

@Trappist the monk: the fact that it's transcluded only once makes me think it's a useless template. Furthermore, the doi it lists is faulty and even on CiteSeerX the link to the document is a 404. – Finnusertop (talk ⋅ contribs) 23:51, 25 May 2019 (UTC)

You mean this one from Social media? Repeated here:

{{cite citeseerx |last1=Lundblad |first1=Niklas |title=Privacy in a Noisy Society |citeseerx=10.1.1.67.965}}

Lundblad, Niklas. "Privacy in a Noisy Society". CiteSeerX 10.1.1.67.965.

What am I missing? The link works for me.

I don't know if its a useless template. I would suspect that part of the not-used-very-much problem is that there is no documentation, it isn't listed with the other cs1|2 templates in {{Citation Style documentation/cs1}} or {{Citation Style 1}} or anywhere else for that matter so no one knows that it exists.

—Trappist the monk (talk) 00:22, 26 May 2019 (UTC)

does anyone use it? AManWithNoPlan (talk) 01:31, 26 May 2019 (UTC)

@Trappist the monk: The link to CiteseerX does work. But the download link on CiteseerX doesn't. And the doi is broken. – Finnusertop (talk ⋅ contribs) 22:47, 26 May 2019 (UTC)

A citeseerx 'doi' is not the same as a doi.org 'doi' so, of course, if you give the citeseerx doi to doi.org, doi.org will choke on it. Yeah, that download link doesn't work but if you click the pdf icon, it sends you to this pdf which looks to me like it is the article.

—Trappist the monk (talk) 23:04, 26 May 2019 (UTC)

Only ONE page uses this thing. AManWithNoPlan (talk) 02:11, 27 May 2019 (UTC)

Why so hostile? Editor Finnusertop has already noted (with this edit) that the template is currently used in only one article. Write some documentation for it. Include it in {{Citation Style documentation/cs1}} and {{Citation Style 1}}. Mention that it exists at the appropriate wiki projects. If, after all of that, and some time for editors to use it, there is still only one transclusion, then perhaps we should take it to tfd.

—Trappist the monk (talk) 02:50, 27 May 2019 (UTC)

I am not hostile. More just concerned aver the proliferation of subtlety different templates. Cite article, work, paper, document, conference, news, newspaper, book, journal, magazine, etc. AManWithNoPlan (talk) 03:47, 27 May 2019 (UTC)

proliferation? Five of the templates that you named are redirects to cs1 templates. We have no control over editors creating whatever redirects that they want. If you think that there are too many, then WP:RFD is the proper venue. These are the redirects that you named, with year of creation and target:

• {{cite article}} (2007) → {{cite news}}
• {{cite document}} (2010) → {{cite journal}}
• {{cite newspaper}} (2008) → {{cite news}}
• {{cite paper}} (2006) → {{cite journal}}
• {{cite work}} (2012) → {{cite book}}

The others that you named with year of creation:

• {{cite book}} – 2006
• {{cite conference}} – 2006
• {{cite journal}} – 2005
• {{cite magazine}} – 2006 (as a redirect), 2015 as a template
• {{cite news}} – 2006

And, for completeness, the rest of the cs1|2 templates and year of creation:

• {{cite arXiv}} – 2006
• {{cite AV media}} – 2005
• {{cite AV media notes}} – 2006
• {{cite bioRxiv}} – 2017
• {{cite citeseerx}} – 2017
• {{cite encyclopedia}} – 2005
• {{cite episode}} – 2007
• {{cite episode}} – 2006
• {{cite mailing list}} – 2007
• {{cite map}} – 2007
• {{cite newsgroup}} – 2006
• {{cite podcast}} – 2006
• {{cite press release}} – 2006
• {{cite report}} – 2008
• {{cite serial}} – 2007
• {{cite sign}} – 2006
• {{cite speech}} – 2006
• {{cite techreport}} – 2006
• {{cite thesis}} – 2009
• {{cite web}} – 2004
• {{Citation}} – Citation

I don't see any proliferation trend here. The bulk of these templates were created between 2004 and 2009:

2004 (1×), 2005 (3×), 2006 (13×), 2007 (4×), 2008 (1×), 2009 (1×)

The most recent creations were {{cite bioRxiv}} and {{cite citeseerx}}, both created in 2017.

—Trappist the monk (talk) 13:20, 27 May 2019 (UTC)

Really, {{cite arXiv}}, {{cite bioRxiv}}, {{cite citeseerx}} and (a newly created) {{cite SSRN}} should all be merged into a {{cite preprint}}. Headbomb {t · c · p · b} 01:39, 31 May 2019 (UTC)

RfC on linking title to PMC

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

Include link

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

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

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

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

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

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

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

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

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

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

Remove link

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

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

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

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

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

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

Discussion

See also #Stop linking paper title to PMC

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

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

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

currently displays as

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

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

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

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

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

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

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

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

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

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

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

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

deprecate |lay-summary= and |laysummary=

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

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

deprecate |dead-url= and |deadurl=

This to follow up on this discussion (and the three previous discussions mentioned there); all of which has dragged on for far too long.

There are about 173,000 articles (astonishingly, the search did not time out) that use |dead-url= and |deadurl=.

Since there is a vague acceptance of |url-status= as a replacement, I am going to deprecate |dead-url= and |deadurl= and add support for |url-status= with appropriate keywords to replace yes and no with dead and live.

In parallel with that I shall write a bot task to replace existing instances of these parameters.

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

The deprecation and replacement looks like this:

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=dead|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.
Sandbox	Title. Archived from the original on 2015-05-19.

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=live|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.
Sandbox	Title. Archived from the original on 2015-05-19.

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=usurped|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)
Sandbox	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=unfit|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)
Sandbox	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: unfit URL (link)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=bot: unknown|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: bot: original URL status unknown (link)
Sandbox	Title. Archived from the original on 2015-05-19.{{cite book}}: CS1 maint: bot: original URL status unknown (link)

Old values "yes" and "no" still work: not any more

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=yes|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=yes (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=yes (help)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|title=Title|url-status=no|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=no (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Invalid |url-status=no (help)

the deprecated parameters still work:

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|dead-url=no|title=Title|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

Cite book comparison

Wikitext	{{cite book|archive-date=2015-05-19|archive-url=//example.com/Archive|dead-url=true|title=Title|url=//example.com/Original}}
Live	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)
Sandbox	Title. Archived from the original on 2015-05-19. {{cite book}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

—Trappist the monk (talk) 15:43, 1 June 2019 (UTC)

Phab for IABot T224807 -- GreenC 15:54, 1 June 2019 (UTC)

To clarify, we are increasing complexity from two possibles:

|dead-url=yes

|dead-url=no

To six possibilities:

|dead-url=yes

|dead-url=no

|url-status=yes

|url-status=no

|url-status=dead

|url-status=live

(plus bot: unknown, usurped and unfit and aliases without the dash) -- GreenC 17:00, 1 June 2019 (UTC)

No. During the deprecation period, |dead-url= and |deadurl= will work as they did previously except that templates that use those parameters will show the deprecated parameter error message. At the same time, |url-status= must also be supported. Because |url-status=yes and |url-status=no convey little or no meaning (much more 'no' meaning than 'little' meaning), I had not bothered with detecting those nonsense values. But, since you have made the claim that doing this change will increase the complexity of the system, I have increased the complexity of the code to handle those nonsense parameter/keyword combinations – to be undone at a future update to the module.

—Trappist the monk (talk) 17:28, 1 June 2019 (UTC)

The 5.7+ million wiki articles is a universal shared base to every human editor and automated process, unlike a single CS1|2 Lua module which is maybe complex to the relatively few programmers who work with it. Thank you for eliminating two of the six. Editors are accomplished at making shorcuts (least number of keystrokes) so converting |dead-url=yes to |url-status=yes would be a logical thing to do ie. the argument name has changed so change the argument name. I wouldn't advise removing a value check because if it can be done editors will do it, leaving it to others to fix the hard way: discovering the problem exists, starting BRFAs, writing bots to clean it up, requesting warning messages and tracking categories. -- GreenC 18:32, 1 June 2019 (UTC)

You're right, if it can be done editors will do it. But, you know, the sky would not have fallen if we did have six possibilities. We suck at documenting this cs1|2 stuff but, I like to think that, were we implementing this change right-now today, we would have got the help-text more-or-less right at Help:CS1 errors#Cite uses deprecated parameter |<param> so that those editors who are at least minimally conscientious, would not have gone astray littering the encyclopedia with crap (I suspect that most editors will ignore the error and wait for someone or someone's bot to fix it; that is, apparently, the most common response to cs1|2 errors).

1. there is no discovering the problem exists – that 'discovery', if it could be called that, is a natural consequence of the decision that we take here to deprecate |dead-url= and |deadurl=
2. the bot task that I mentioned at the top of this discussion is written
3. no point in starting a WP:BRFA yet because approval usually requires trial runs that can't be done without we first update the module suite which must wait for the resolution of the website italic rfc and the pmc autolink rfc. About the time that those are closed I'll start the brfa.

None of this seems to be leaving it to others to fix the hard way. In fact, leaving it to others to fix the hard way would be for us to do nothing except change the module suite. Clearly, that isn't in the plan; never has been.

—Trappist the monk (talk) 23:35, 1 June 2019 (UTC)

I was not aware of Monkbot 15 (missed that sentence), that would basically resolve the concern I had. Once 15 gets approval, I plan on adding code to do the same in WaybackMedic's regular maintenance since in my experience even if all were eliminated today in 6 months there will be thousands more, via many routes (reverts to old revisions, copy-paste from elsewhere, force of habit, other tools and bots not yet changed, etc) - returning from the dead, so to speak, for many years. -- GreenC 01:22, 2 June 2019 (UTC)

Deprecate format

Since we're apparently doing deprecations this round, we might consider replacing |format= as well, with |url-file-format= or similar. I know there's an (old) discussion lying around about how ambiguous "format" is. --Izno (talk) 15:24, 1 June 2019 (UTC)

Find that discussion? I don't remember it ...

—Trappist the monk (talk) 15:43, 1 June 2019 (UTC)

That might take some time. One minute/hour/day ~ --Izno (talk) 16:02, 1 June 2019 (UTC)

The reason you do not remember is because you were uninvolved and it was off in a tiny corner of the world. :) Module talk:Citation/CS1/Feature requests#Format size was about having a format size and then DF suggested changing the name. I'm fairly certain we've had followup discussion but insource search is not finding my proposed name in the relevant namespaces. --Izno (talk) 16:14, 1 June 2019 (UTC)

link rot

In CS1|2 there are multiple URLs in a citation but space for only one archive. For example there can be a |url= and |lay-url=. Would it ever make sense to have |lay-archive-url=, or is it better to replace the URL inside |lay-url= with an archive URL? -- GreenC 19:39, 3 June 2019 (UTC)

I guess another possibility is |format=addlarchives in {{webarchive}} which can support multiple archives. -- GreenC 12:23, 5 June 2019 (UTC)

url + title=none

For stylistic reasons, the title in

• Bach, Eric (2001), "Book review: Complexity and real computation, by Lenore Blum, Felipe Cucker, Michael Shub, and Steve Smale" (PDF), Discrete Dynamics in Nature and Society, 6 (2): 145–146, doi:10.1155/S1026022601000152{{citation}}: CS1 maint: unflagged free DOI (link)

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

• Bach, Eric (2001), Discrete Dynamics in Nature and Society, 6 (2): 145–146, doi:10.1155/S1026022601000152 https://downloads.hindawi.com/journals/ddns/2001/120718.pdf {{citation}}: |url= missing title (help)CS1 maint: unflagged free DOI (link) CS1 maint: untitled periodical (link)

I believe in this case, we should have something like

• Bach, Eric (2001), Discrete Dynamics in Nature and Society, 6 (2): 145–146, doi:10.1155/S1026022601000152, available here.
• Bach, Eric (2001), Discrete Dynamics in Nature and Society, 6 (2): 145–146, doi:10.1155/S1026022601000152, available at https://downloads.hindawi.com/journals/ddns/2001/120718.pdf

or even something like

• Bach, Eric (2001), Discrete Dynamics in Nature and Society, 6 (2): 145–146, doi:10.1155/S1026022601000152

or

• Bach, Eric (2001), Discrete Dynamics in Nature and Society, 6 (2): 145–146, doi:10.1155/S1026022601000152

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/S1026022601000152{{citation}}: CS1 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.

• Directory of Shopping Centers in the United States. 20. National Research Bureau. 1979. ISSN 1071-5835 https://books.google.com/books?id=ep5IAAAAYAAJ. Retrieved 2015-03-12. {{cite journal}}: |url= missing title (help)CS1 maint: untitled periodical (link)

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

icons and the modern skin

If I view this page with Chrome and use the modern skin, access and wikisource icons in these example citations are not displayed and, in the pdf example, the pdf icon is different from other skins:

{{cite journal |title=Title |journal=Journal |url=http://www.example.com/Article |url-access=subscription |doi=10.99999/bogus.doi.article |doi-access=free}}

"Title". Journal. doi:10.99999/bogus.doi.article. {{cite journal}}: Check |doi= value (help)

{{cite wikisource|Sense and Sensibility|Jane Austen}}

Jane Austen. Sense and Sensibility  – via Wikisource.

{{cite book |title=Title |url=http://example.com/title.pdf}}

Title (PDF).

Modern renders http: and https: urls differently:

http://www.example.com → http://www.example.com – the generic external link icon

https://www.example.com → https://www.example.com – a yellow lock icon

The doi link in the first example is a protocol relative link; modern renders those with the generic external link icon:

[//doi.org/10.99999%2Fbogus.doi.article //doi.org/10.99999%2Fbogus.doi.article] → //doi.org/10.99999%2Fbogus.doi.article

In the wikisource citation, Module:Citation/CS1 creates an https: url to the wikisource article so that it can render the wikisource icon in the same way that access icons are rendered.

For those who do not use modern skin, follow this link to re-render this page using modern skin.

and for the curious, the other skins:

• Cologne Blue
• MinervaNeue
• MonoBook
• Timeless
• Vector (default)

Do we know why access and wikisource icons do not work with modern but do with the other skins? Where is the modern skin css?

—Trappist the monk (talk) 12:32, 10 June 2019 (UTC)

Probably related to the discussion at MediaWiki_talk:Common.css/Archive_18#PDF_rules_(pt_1), when I removed the highly specific rules in our Common.css. On-wiki, mediawiki:modern.css; phabricator repo for Modern; main.css. It looks like the rules in Modern should have been updated when the rules in the other skins were on similar CSS the others skins have, to be less specific:

#mw_content a.external {
	/* @embed */
	background: url( images/external.png ) center right no-repeat;
	padding-right: 13px;
}

#mw_content a.external[ href^='https://' ],
.link-https {
	/* @embed */
	background: url( images/lock_icon.gif ) center right no-repeat;
	padding-right: 16px;
}

#mw_content a.external[ href^='mailto:' ],
.link-mailto {
	/* @embed */
	background: url( images/mail_icon.gif ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href^='news:' ] {
	/* @embed */
	background: url( images/news_icon.png ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href^='ftp://' ],
.link-ftp {
	/* @embed */
	background: url( images/file_icon.gif ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href^='irc://' ],
#mw_content a.external[ href^='ircs://' ],
.link-irc {
	/* @embed */
	background: url( images/discussionitem_icon.gif ) center right no-repeat;
	padding-right: 18px;
}

#mw_content a.external[ href$='.ogg' ],
#mw_content a.external[ href$='.OGG' ],
#mw_content a.external[ href$='.mid' ],
#mw_content a.external[ href$='.MID' ],
#mw_content a.external[ href$='.midi' ],
#mw_content a.external[ href$='.MIDI' ],
#mw_content a.external[ href$='.mp3' ],
#mw_content a.external[ href$='.MP3' ],
#mw_content a.external[ href$='.wav' ],
#mw_content a.external[ href$='.WAV' ],
#mw_content a.external[ href$='.wma' ],
#mw_content a.external[ href$='.WMA' ],
.link-audio {
	/* @embed */
	background: url( images/audio.png ) center right no-repeat;
	padding-right: 13px;
}

#mw_content a.external[ href$='.ogm' ],
#mw_content a.external[ href$='.OGM' ],
#mw_content a.external[ href$='.avi' ],
#mw_content a.external[ href$='.AVI' ],
#mw_content a.external[ href$='.mpeg' ],
#mw_content a.external[ href$='.MPEG' ],
#mw_content a.external[ href$='.mpg' ],
#mw_content a.external[ href$='.MPG' ],
.link-video {
	/* @embed */
	background: url( images/video.png ) center right no-repeat;
	padding-right: 13px;
}

#mw_content a.external[ href$='.pdf' ],
#mw_content a.external[ href$='.PDF' ],
#mw_content a.external[ href*='.pdf#' ],
#mw_content a.external[ href*='.PDF#' ],
#mw_content a.external[ href*='.pdf?' ],
#mw_content a.external[ href*='.PDF?' ],
.link-document {
	/* @embed */
	background: url( images/document.png ) center right no-repeat;
	padding-right: 12px;
}

#mw_content probably should be updated to .mw-parser-output, as with the other skins. There's basically nothing we can do to fix this problem with those specificity on the elements those are on. --Izno (talk) 14:15, 10 June 2019 (UTC)

I've filed a task for it. Who knows how long it will be. --Izno (talk) 14:30, 10 June 2019 (UTC)

Thank you. According to Help talk:External link icons § Were these icons useful?, most icons were withdrawn by the end of January 2015; modern and monobook, apparently, excepted.

—Trappist the monk (talk) 15:04, 10 June 2019 (UTC)

Wikipedia:Redirects for discussion/Log/2019 June 1#Journal of the American Society of Nephrology : JASN

Please comment. The outcome of this discussion could greatly impact our ability to cleanup articles. Headbomb {t · c · p · b} 18:33, 11 June 2019 (UTC)

cite map and |map-url-access=

Current version of Module:Citation/CS1 does not support |map-url-access=. It should. I found this citation at M-6 (Michigan highway):

{{cite map |map-url = http://www.traillink.com/trail-maps/fred-meijer-m-6-trail.aspx |map = Fred Meijer M-6 Trail |title = TrailLink |publisher = Rails-to-Trails Conservancy |author = Google |access-date = September 19, 2010 |date = September 19, 2010 |url-access=registration }}

Google (September 19, 2010). "Fred Meijer M-6 Trail" (Map). TrailLink. Rails-to-Trails Conservancy. Retrieved September 19, 2010. {{cite map}}: |author= has generic name (help); |url-access= requires |url= (help)

Fixed I think, in the sandbox:

Cite map comparison

Wikitext	{{cite map|access-date=September 19, 2010|author=Google|date=September 19, 2010|map-url-access=registration|map-url=http://www.traillink.com/trail-maps/fred-meijer-m-6-trail.aspx|map=Fred Meijer M-6 Trail|publisher=Rails-to-Trails Conservancy|title=TrailLink}}
Live	Google (September 19, 2010). "Fred Meijer M-6 Trail" (Map). TrailLink. Rails-to-Trails Conservancy. Retrieved September 19, 2010. {{cite map}}: |author= has generic name (help)
Sandbox	Google (September 19, 2010). "Fred Meijer M-6 Trail" (Map). TrailLink. Rails-to-Trails Conservancy. Retrieved September 19, 2010. {{cite map}}: |author= has generic name (help)

The usual error detection applies:

{{cite map/new |map=Map |map-url=//example.com |map-url-access=free}}

"Map" (Map). Title. {{cite map}}: Invalid |map-url-access=free (help)

{{cite map/new |map=Map |map-url-access=subscription}}

"Map" (Map). Title. {{cite map}}: |map-url-access= requires |map-url= (help)

|map-url-access= only applies to |map-url= so is only used when |map= and |map-url= are used.

Ping Imzadi1979: you are, I think, our local expert on the use of this template, do you know of any cases where this new functionality falls on its face?

—Trappist the monk (talk) 19:41, 12 June 2019 (UTC)

@Trappist the monk: I don't know of any, no. Imzadi 1979 → 00:58, 13 June 2019 (UTC)

Support citewatch=... or something like it

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

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

And, upon the next bot run a table like this

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

could be updated to something like

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

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

Name order

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)

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

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

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. –84.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. 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. {{cite web}}: |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

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. {{cite journal}}: 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.{{cite journal}}: CS1 maint: Zbl (link)

but seven digits:

{{cite journal/new |title=Title |journal=Journal |zbl=6066616}}

"Title". Journal. Zbl 6066616. {{cite journal}}: 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

Template: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 (talk ⋅ contribs) 19:08, 25 June 2019 (UTC)

Update URL for bibcode tag

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 (talk • contribs) 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)

Check for final character in several regular fields

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.{{cite journal}}: CS1 maint: extra punctuation (link)

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

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. {{cite book}}: Check |url= value (help)

{{cite book/new |title=Title |agency=Agency,}} → Title. {{cite book}}: Unknown parameter |agency= ignored (help)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)

Monkbot

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=

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. {{cite encyclopedia}}: Missing or empty |title= (help)

{{citation |encyclopedia=Encyclopedia}} → Encyclopedia {{citation}}: Missing or empty |title= (help)

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 comparison

Wikitext	{{cite encyclopedia|encyclopedia=Encyclopedia}}
Live	Encyclopedia. {{cite encyclopedia}}: Missing or empty |title= (help)
Sandbox	Encyclopedia. {{cite encyclopedia}}: Missing or empty |title= (help)

Cite encyclopedia comparison

Wikitext	{{cite encyclopedia|article=Article|encyclopedia=Encyclopedia}}
Live	"Article". Encyclopedia.
Sandbox	"Article". Encyclopedia.

Cite encyclopedia comparison

Wikitext	{{cite encyclopedia|article=Article|title=Title}}
Live	"Article". Title.
Sandbox	"Article". Title.

Citation comparison

Wikitext	{{citation|encyclopedia=Encyclopedia}}
Live	Encyclopedia {{citation}}: Missing or empty |title= (help)
Sandbox	Encyclopedia {{citation}}: Missing or empty |title= (help)

Citation comparison

Wikitext	{{citation|article=Article|encyclopedia=Encyclopedia}}
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. {{cite encyclopedia}}: Missing or empty |title= (help)
  • 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 (talk • contribs) 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?

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. {{cite book}}: |author= has generic name (help)

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

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)