Help talk:Citation Style 1/Archive 63

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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

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

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

The following pages have been notified:

• 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)
• WP:CENT

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

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

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

Follow up responses

• clarification needed - I assume we are just talking about CS1 template here. If so, a lot depends on which citation style our CS1 template is based upon. Different styles present websites in different ways (some italicized, some not). So which style guide is the template based on? Blueboar (talk) 15:47, 6 October 2019 (UTC)

  @Blueboar: The exact question is whether the earlier discussion applied to all references to websites, whether it applied to something lesser (e.g. as used in CS1/2), or something even smaller than that. I find it hard to believe that it would be something lesser than CS1/2 based on the discussion and context, but someone may argue such. --Izno (talk) 18:11, 6 October 2019 (UTC)

• Italics in cs 1/2 templates - per the RFC discussion above. 72.43.99.138 (talk) 15:08, 6 October 2019 (UTC)
• {{Cite web}} only. The location of the discussion, Help:Citation Style 1, put editors on notice that the RFC only applied to that style. {{Cite web}} is the only template in that style I know of that calls for giving the title of the website as such. Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. Jc3s5h (talk) 15:13, 6 October 2019 (UTC)

  Furthermore, to avoid false metadata {{Cite web}} should only be used for periodicals, so it should not be used for other websites. This is a different discussion. Let's keep on topic. 72.43.99.138 (talk) 15:17, 6 October 2019 (UTC)

• CS 1/2 only, but only web site / work, not publisher. Some discussion since the first RFC has attempted to extend the italicization to publishers (that is, organizations, not collective groups of web pages) in the absence of a web site / work parameter, and that is incorrect. This should only apply to CS1 and CS2 per WP:CITEVAR. —David Eppstein (talk) 16:52, 6 October 2019 (UTC)

  I don't think I've seen anyone claim that |publisher= should italicize anything. --Izno (talk) 18:11, 6 October 2019 (UTC)

  No but some have argued that when a website has no title, the publisher's name should be used as |website= and be italicized, which is, indeed, italicizing the publisher's name. – Levivich 18:13, 6 October 2019 (UTC)

  Which is also a different discussion. --Izno (talk) 18:19, 6 October 2019 (UTC)

• Rerun this RFC from scratch – and this time advertise it on CENT. The proposal should be clear about what will change if it passes. So "Should websites always be italicized" isn't a great question. A better one would be, "Should we make change X to the MOS", or "Should we make change X to the citation template code", or something concrete like that. We need to differentiate between an MOS-style guideline directive, and a hard change to code. We also need to differentiate between work= and publisher= as discussed above. In my view, the scope of the existing RfC is nil because of the procedural flaws. – Levivich 17:48, 6 October 2019 (UTC)

  @Levivich: The original proposal was listed on CENT. Please don't make this about whether it was advertised; that was not the question asked. --Izno (talk) 18:08, 6 October 2019 (UTC)

  Where? I couldn't find it. – Levivich 18:12, 6 October 2019 (UTC)

  @Levivich: Review the link provided in my response. --Izno (talk) 18:14, 6 October 2019 (UTC)

  I didn't see it at first but now I see it. It should be advertised clearer on CENT. For example, the CENT advertisement was "Italics of websites in citations", and not the clearer, "Should website names always be italicized?" or the even clearer, "Should {{cite web}} always require a website name, which is always italicized?" – Levivich 18:16, 6 October 2019 (UTC)

  Not per the guidelines established on Template:Centralized discussion#Style. If you take a minute to review the history of that template, the intent is to be short and sweet. I used the title the discussion was started under (for better or worse). --Izno (talk) 18:19, 6 October 2019 (UTC)

  Added to WP:CENT

  —Trappist the monk (talk) 11:30, 9 October 2019 (UTC)

• CS1/2 templates only. I think that's obvious from the context in which the question was asked. Were it to have been asked elsewhere (say, WT:MOS or WT:CITE), it might reasonably have been interpreted to mean all citations/references, but here, I do not think that was the case. --Izno (talk) 18:14, 6 October 2019 (UTC)
• No, the titles of websites (if they have a title; most don't) should not be italicized. Where they lack a title, the URL should not be italicized. But whether or not website titles are italicized, in no circumstances should the publisher be used as the website title and italicized. That is, the title of https://www.supremecourt.gov/ is not "Supreme Court of the United States" or, even worse, Supreme Court of the United States. That site doesn't have a title. The website's publisher is the Supreme Court of the United States, and that should never be italicized. Ditto with World Health Organization, BBC News, CNN, etc.
  The Chicago Manual of Style says: "Titles of websites mentioned or cited in text or notes are normally set in roman [not italicized], headline-style, without quotation marks." Their examples include Project Gutenberg and Wikipedia. If the website has a printed counterpart, it is italicized along with the printed version, e.g. Encyclopaedia Britannica Online. Where websites have no formal title, use a short form of the URL, e.g. Apple.com, not italicized. See The Chicago Manual of Style, section 8.191, pp. 538–539. SarahSV ^(talk) 18:49, 6 October 2019 (UTC)

  Just a reminder, the purpose of this discussion is to decide how to apply the determined consensus in the previous RFC, not to debate the outcome. Steven Crossin ^{Help resolve disputes!} 19:44, 6 October 2019 (UTC)

  Steven, I wonder whether the previous RfC delivered a clear-enough consensus. We generally don't italicize websites. Wikipedia, for example, isn't italicized; nor are Facebook, Twitter, etc. Why italicize them only in citations? Our style choices should be consistent, at least within the same article. SarahSV ^(talk) 22:20, 6 October 2019 (UTC)

  I agree with Levivich that the RfC needs to be rerun. Wikipedia:Manual of Style/Titles does not support italicizing all websites: "Website titles may or may not be italicized depending on the type of site and what kind of content it features." Online newspapers, for example, are italicized. Other types of site are not. It needs to be decided on a case-by-case basis, making sure that each article is internally consistent. It makes no sense to write "Wikipedia" without italics throughout an article, then force people to use italics in a citation, but only if a template is used. SarahSV ^(talk) 22:37, 6 October 2019 (UTC)

I agree that we shouldn't be challenging the previous outcome in this RfC, since it's not the question being asked. With that said, an important distinction getting missed is when a website is being cited as a publication for the material it supports; that's when italicization should be invoked (according to the outcome above). Simply stating "Wikipedia" or "Facebook" in running text to reference the company or entity they represent places the website name in a different context. And in regard to the Chicago MoS perpective, keep in mind that the MLA format does support italics in citations. The inconsistency you're pointing out already exists outside of Wikipedia. --GoneIn60 (talk) 06:44, 12 October 2019 (UTC)

• Rerun the RfC. CS1/2 templates. Specifically, |website= for all templates and |work= for the {{cite web}} template. So, for example, Apple is a company that publishes websites Apple (apple.com), Apple Support (support.apple.com), Apple Developer (styled  Developer ; developer.apple.com), etc. — UnladenSwallow (talk) 19:32, 6 October 2019 (UTC) Update: After thinking more about the problem, I agree with the other commenters that this RfC needs to be rerun. — UnladenSwallow (talk) 00:31, 7 October 2019 (UTC)
• Rerun RfC per Levivich. Failing that, the italicization requirement should apply only to |website= in CS1 templates, and that parameter should not be required. Nikkimaria (talk) 00:27, 7 October 2019 (UTC)
• Apply broadly: So, let's see if I am getting this wrong. 😜 You've asked people and they've told you. If the majority of the participants had a constraint in mind, they'd have told you. AFAIK the italicization helps identify the citation component, not the role and the object of the work. flowing dreams (talk page) 05:03, 7 October 2019 (UTC)

No, the reverse is true. Italicization in citations is semantic (Chicago, the city, vs. Chicago, the musical). It is not there to make a citation component stand out visually. — UnladenSwallow (talk) 09:01, 7 October 2019 (UTC)

LOL. I never said "to make a citation component stand out visually". I said "helps identify the citation component", which is a semantic role. You gave a very good example for it: "Chicago" is a publication location, "Chicago" is a published work. flowing dreams (talk page) 09:53, 7 October 2019 (UTC)

Oops. Sorry for misunderstanding you. I now get what you were saying: italicization is there to help us find the website title in a citation, not to tell us the type of the website (blog, web app, social media platform, etc.). — UnladenSwallow (talk) 20:30, 7 October 2019 (UTC)

• Apply to CS1 only: It just occurred to me that it is meaningless to conduct an RFC about the italicization of website names across several styles unless we know for sure that all those styles have vague italicization requirements. And there is no evidence to suggest that people interested in styles other than the citation style 1 have participated in the original RFC. flowing dreams (talk page) 09:40, 9 October 2019 (UTC)
• italicize |website= in CS1/2 templates – I did not participate in the original discussion, but I do follow this talk page, which is used for discussion of these templates. When someone proposes here that a certain kind of citation should look like X, or that a certain combination should be forbidden, they are understood to be talking about the behaviour of these templates. I understand that other pages are used for discussing the MOS, and no change to the wording of MOS was proposed here. Kanguole 08:45, 7 October 2019 (UTC)
• Rerun the RfC. Alternately, apply this only to the CS1/2 templates — While this was posted at CENT, such a major, major change to Wikipedia got only a couple dozen editors responding, if that. Discussions for adminship, for example, get five times as many editors commenting. Make no mistake, this is essentially a site-wide change: "Cite web" is being used more and more throughout Wikipedia since even editors adding magazine or newspaper citations often figure, "Well, it's on the web." That means the de faco Wikipedia house style italicizes company and institution names, which no mainstream footnoting format does. Without a corresponding "cite organization" template that does not automatically italicize company and institution names, italicizing websites in CS1/2 is essentially mandating an eccentric house style. That means a cite from the National Oceanic and Atmospheric Administration comes out as National Oceanic and Atmospheric Administration — misleadingly making it seem like a magazine such as National Geographic. I think something this big requires more input than the small number of editors at this relatively obscure technical page.--Tenebrae (talk) 16:06, 7 October 2019 (UTC)

  Exactly. The New York Times (www.nytimes.com) is an online news outlet and should be italicized. Google Docs (docs.google.com) is a web app and should not be italicized (apps are not italicized, as opposed to games). It follows that {{cite web}} must use manual italicization. I don't think it's such a big problem. The rules for applying italics can be put in the description of the website parameter. — UnladenSwallow (talk) 21:20, 7 October 2019 (UTC)

  IMHO, Google Docs must never appear in |website=. It belongs to |via=. Such is the case for GitHub: The repo name goees into |work=. flowing dreams (talk page) 11:55, 9 October 2019 (UTC)

Generally, yes. However, the web app name will be listed in |website= for pages like "About", "Help", "Subscription plans", etc. — UnladenSwallow (talk) 18:32, 9 October 2019 (UTC)

Oh, I see. In that case, your reference to Google Docs would be analogous to referring to an appliance's manual as opposed to referring to the appliance itself. In this case, the page to which you are linking is not an app, so, per your own criterion, definitely italize it.

But as I said, italicization has semantic meaning. This is important because |work=, |publisher= and lots of other parameters are optional. There is no telling if the citation has them. The italicization is your only clue. flowing dreams (talk page) 07:10, 10 October 2019 (UTC)

the page to which you are linking is not an app, so, per your own criterion, definitely italize it I never said app/not-an-app was my criterion. I simply offered two examples: an online news outlet (which are always italicized) and a non-game web app (which are never italicized). There are many other types of websites which may or may not be italicized. But that doesn't matter. What matters is that there are two types of websites that disagree on italicization. Therefore, we can't apply italicization automatically and must leave the decision to the template user.

You argue that Google Docs would never (or almost never) appear in |website=, so it's a bad example. Fine, let's take another example: Federal Reserve Economic Data (fred.stlouisfed.org). Certainly you would agree that it goes into |website= (and Federal Reserve Bank of St. Louis goes into |publisher=). And yet, it is always cited as FRED (no italics). There are many more examples like that. — UnladenSwallow (talk) 00:36, 11 October 2019 (UTC)

Humph. This is getting more and more complicated without any benefit. Nah. I'd say italicize all works, be it book, film, play, or app. flowing dreams (talk page) 06:54, 11 October 2019 (UTC)

This is not getting more and more complicated. I've provided you with two examples of websites: one that is italicized and one that is not. You've discarded the second example on the basis that it should always go into |publisher=, so I've replaced it with another example of a website that is not italicized.

So now we have The New York Times (www.nytimes.com) that is italicized and FRED (fred.stlouisfed.org) that is not italicized. This means that the decision on italicization should be left to the template user.

Nah. I'd say italicize all works… Wikipedia follows the existing norms as much as possible. If we wanted to keep things simple, we wouldn't have non-breaking spaces, en dashes, em dashes, etc. — UnladenSwallow (talk) 17:13, 11 October 2019 (UTC)

I said "complicated and without benefits". And you're not here to follow the existing norm; you're here to change existing norm on millions of articles. If Wikipedia wanted to follow existing norms, CS1 would have never been invented. By the way, you keep saing "FRED is not italicized". Not italicized by who? flowing dreams (talk page) 08:02, 12 October 2019 (UTC)

It's not italicized by any mainstream source whatsoever. Neither is Fannie Mae or Freddie Mac. As for "I'd say italicize all works" ... well, why? You're not giving any reason for having Wikipedia citations go outside the mainstream with some eccentric citation style used nowhere else. --Tenebrae (talk) 18:18, 27 October 2019 (UTC)

No, you didn't say "complicated and without benefits". You said This is getting more and more complicated without any benefit, which implies that "this" is: (1) getting more and more complicated; (2) does so without any benefit. I have addressed part (1), demonstrating to you that nothing is "getting more complicated"; in fact, the level of complexity is staying exactly the same as it was in my original comment: there are websites that are italicized and there are websites that are not italicized. you're not here to follow the existing norm I will decide for myself why I'm here, thank you. you keep saing "FRED is not italicized". Not italicized by who? Obviously, I'm referring to existing practice. As I've told you several comments back: "And yet, it is always cited as FRED (no italics)." Are you being intentionally obtuse? If you think I'm wrong, please demonstrate a variety of newspapers/magazines where FRED is cited as FRED (italicized). Except you can't. Because I've checked it thoroughly before posting my comment. You can continue to muddy the waters, or you can face the reality that in existing newspapers/magazines some types of websites are italicized (newspapers, journals, magazines, blogs, webcomics, etc.) and other types of websites are not (TV channels, radio stations, databases, company websites, etc.). See MOS:ITALICTITLE. — UnladenSwallow (talk) 05:53, 14 October 2019 (UTC)

Whoa! Whoa! Whoa! "Obtuse" is a personal attack. And "existing practices" is still a weasel word. FYI, not only I can face the reality, I can stare in said reality's eyes and tell it: "Hey, existing reality! I reject you, because you cannot justify your existence!" I've already done so to gender discrimination. If necessary, I'll do it to unhelpful italicization of components. flowing dreams (talk page) 07:37, 14 October 2019 (UTC)

• Steven Crossin, please offer an alternative title to this discussion so that it more accurately reflects citation practice. Citations do not italicize anything. They usually emphasize the most pertinent element, traditionally - though not exclusively - by using slanted type. Both the original RFC and this discussion keep applying the misnomer of "italics" which is solely a typographical convention and does not reflect the underlying semantic meaning. 24.105.132.254 (talk) 22:29, 7 October 2019 (UTC)

  "website=" in "cite web" automatically italicizes and does not allow manual override such as wiki markup. --Tenebrae (talk) 21:24, 8 October 2019 (UTC)

• Rerun the RfC and notify more widely. Template styles should follow the Wikipedia:Manual of Style/Titles which has a defined position on use of italics for websites (essentially being: it depends). If an overall change of style is being considered then it should be considered in that forum rather than for a specific template that users would naturally expect to follow the conventions defined in the Manual of Style. 203.10.55.11 (talk) 02:34, 11 October 2019 (UTC)
• Rerun the RfC. You can't just overturn Wikipedia:Manual of Style/Titles without even advertising the RfC there. Kaldari (talk) 23:22, 11 October 2019 (UTC)
  • The RfC didn't "overturn" anything. The wording on this particular thing at MOS:TITLES has just been confused and unclear for a long time (until MOS:ITALICTITLE); to the extent that the depending-upon-publication-type stuff could be interpreted as applying to citations (rather than use in running prose), it would not actually reflect WP practice, which has been to italicize these work names in citations, automatically, for 10+ years now.  — AReaderOutThataway ^t/_c 22:36, 20 October 2019 (UTC)
• Preferably rerun the RFC; at the very most, current consensus only allows for italics in cs 1/2 templates. Notwithstanding Steven Crossin's (understandable) request that the focus here be kept on-point, the fact remains that many editors are strongly opposed to italicising each and every website title, and/or that publisher= cannot be used instead to avoid italicising organisations in cite web. It seems to me it's a case of template managers/editors seeking to squeeze different scenarios into one tidy category – whether that's through obsessiveness or a touch of control-freakery I don't know. But, as was raised in the RfC, and has been added to or alluded to here by the likes of David Eppstein, Levivich and SarahSV, it's not a case of one-size-fits-all. I'm a professional book editor, and have been for far too many years, and the idea that an organisation has to be treated as a "work" in the interest of defining a component of the citation is, well, utterly ridiculous. AllMusic, Official Charts Company, Metacritic, Supreme Court of the United States, World Health Organization, BBC News, etc, are never italicised in regular text and need not be in a citation. (No reader's going to go: "Aaargh, you've lost me ... how do the words 'BBC News' relate to the rest of the information in that source?")

To return to the question raised here: CS1/2 currently prohibits adhering to a pretty fundamental point in British English style, which is that abbreviations such as eds, nos and vols don't require a full stop/period. In the past – I think it was with regard to the "eds" issue, if not the option to use "edn" for "edition" (which, I'd say, is also preferred in Brit English) – the response here was that editors are "welcome" to write the entire citation manually and so avoid having to conform to what they consider to be a contentious CS1/2 requirement. In the same spirit, and given the scope of the RfC anyway, editors should not be required to apply italicisation outside of CS1/2 and should be able to write the cite manually or find another way that presents the information correctly. JG66 (talk) 02:42, 17 October 2019 (UTC)

• Italicize in citations (and there is no difference in this regard between CS1 and CS2, or manually-laid-out citations). Whether to italicize in running text or not depends on whether the site is primarily like a published work (e.g. Salon or IMDb) or primarily something else (just advertising/support material like Microsoft.com, or a forum/social-networking service like Facebook). The "Rerun the RfC" stuff is patent WP:FORUMSHOPPING, an "I didn't get the result I wanted" complaint. The original RfC was widely enough advertised and ran long enough to assess consensus, and given that italicizing these in citations is already enforced by the templates and has been that way for over a decade, the "don't italicize" stuff is not a question about what consensus is, but an attempt to overturn already well-established consensus (an attempt that has failed numerous times, not just above).  — AReaderOutThataway ^t/_c 22:23, 20 October 2019 (UTC); rev'd. 06:29, 22 October 2019 (UTC)
• Italicize in CS1|2—the original forum for the RfC was on the talk page for the CS1|2 templates. As such, it should be a clear principle that the results of the RfC would be confined to those templates. There is no need to rerun the RfC. Imzadi 1979 → 15:45, 22 October 2019 (UTC)

Follow up discussion

• Comment Do you think there is any mileage in scrapping the "Cite web" template altogether, and creating a "Cite organization" in its place that does not italicise? The citation style is drawn from real-world application (i.e. the website name for a newspaper would be italicised, but for an organization it would not be) so Cite web seems to be encouraging standardisation where it does not exist. If you had to choose between Cite news, Cite book, Cite journal, Cite organization etc then the stylisation issue would take care itself. This would seem to be a fairly straightforward solution so what am I missing? Betty Logan (talk) 18:18, 10 October 2019 (UTC)

I think you may be confusing prose style with citation style. Because both are styles does not mean they have the same functionality. Citations style their content towards verifiability. One way this is accomplished is by emphasizing the source, in this case, the website, so that the reader knows immediately where to start looking. It has nothing to do with application of a prose style, neither does it have to follow the referring document's style whether that is MOS or anything else. And don't overlook the fact that use of these templates (actually, the module they are based upon) is entirely voluntary. Any citation/citation style will do, as long as is consistent within the document. 65.88.88.69 (talk) 21:03, 10 October 2019 (UTC)

I am not confusing prose and citation style. I have never italicised a company/corporation name in a citation in my professional work either. For example, if you are citing something on the BBC's website you do not italicise the "BBC" in the citation. The BBC's website is not a publication called the "BBC", it is a publication by the BBC. This is generally the norm for websites. I can think of several counter-examples: if you were citing something in the AFI Catalog you would italicise the "AFI Catalog" in the citation because it is a publication by the American Film Institute. In this capacity it functions as an online encylopedia/ebook and could be cited using an appropriate template. In the case of citing something on the AFI's general website it would be beneficial to have a "corporation" template that does not italicise the company name. The "cite web" template is promoting a standardisation where one does not really exist. Betty Logan (talk) 00:56, 11 October 2019 (UTC)

The template has a |publisher= field. That is where the publishing entity (in most cases the domain owner/registrant) should be inserted. The BBC publishes bbc.com. The latter would be the source. Sources (works) should stand out, one of the reasons being that they may include a lot of other stuff, most of it mysterious to the average Wikipedia reader. The emphasis applied on the source field through italics has nothing to do with whether the source is a website or anything else. 72.43.99.138 (talk) 14:05, 11 October 2019 (UTC)

Respectfully, there has just been an RFC that was in favor of italicizing. In that light of that RFC, this suggestion lacks pertinence. Clearly, the community sees value in distinguishing the name of the work from the name of the subwork and the publisher. If I may add, re-running the RFC reminds me of some of questionable political actions I hear about these days: The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again. flowing dreams (talk page) 11:45, 12 October 2019 (UTC)

RFCs are WP:NOTAVOTE, they are a tool for determining community opinion. Consensus on Wikipedia has never locked in a vote, chiefly because as the participants in a debate change so can opinion. Betty Logan (talk) 09:17, 14 October 2019 (UTC)

That's not what I see. RFCs are based on majority votes. In Wikipedia, minority valid concerns are ignored. In consensus-based decision making, all valid concerns are addressed. flowing dreams (talk page) 09:27, 14 October 2019 (UTC)

See WP:WHATISCONSENSUS#Not a majority vote, WP:NOTDEMOCRACY and Wikipedia:Consensus#Consensus can change (the latter two are both policies). Betty Logan (talk) 09:36, 14 October 2019 (UTC)

And here is my contribution to the consensus-building process: No! Your suggestion is egregious and without benefits, both in its own rights and in the fact that discrimination in italicization is egregious and without benefits. First, because you are operating under the wrong impression that the only websites besides news websites are organizations' websites. Not so. Second, you don't seem to have a functional reason for not italicizing certain websites. In fact, no one here seems to have. Any "reason" I see here is very arbitrary. flowing dreams (talk page) 10:13, 14 October 2019 (UTC)

Betty Logan is absolutely correct in that RfCs are not decided on by number of votes. That's not her "suggestion" but Wikipedia policy. You are completely wrong, per policy, in saying, "In Wikipedia, minority valid concerns are ignored."

As for your other points, you seem to be ignoring multiple editors in both this discussion and the closed RfC saying flat out that the names of organizations (companies, institutions) are not italicized in any mainstream footnoting style — for the very good reason of not conflating them with magazines and other periodicals. The National Oceanic and Atmospheric Administration is not National Oceanic and Atmospheric Administration, as if it were National Geographic. Having Wikipedia adopt a fringe, eccentric footnoting style makes us look like an outlier and does nothing to enhance our credibility. --Tenebrae (talk) 16:01, 15 October 2019 (UTC)

My dear esteemed colleague Tenebrae, you are being awfully forceful here. And I fear we have digressed from the discussion of a proposal for "Cite organization". I do accept that it is partly my fault. (Actually, I have nothing else to add to it, so I can bow out.) I'd be glad to have you and dear Betty in my personal talk page to talk about merits of italicizing in citations or about the de jour and de facto status of Wikipedia's consensus policy. But this thread is already a hot zone. Let's keep other hot topic out of it. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)

And incidentally, I find it odious that you compare this valid, by-the-book discussion as somehow illegitimate in the same way Trumpers try to deny the constitutionality of the impeachment process or recounts. ("The election in a state or nation does not go in favor of the ruling party, so they re-run the election over and over again.") That Trumpian position holds no water in either the political world or in a Wikipedia discussion. --Tenebrae (talk) 16:05, 15 October 2019 (UTC)

You seem to be commenting about one of those nations/states who have voided their election when it did not go according to the plan. (I'd probably look up Trumpian later.) In the meantime, we can focus on the fact that I don't see why Steven Crossin suddenly decided to void the RFC, without drawing any anologies to real-world politic situations. flowing dreams (talk page) 08:14, 16 October 2019 (UTC)

Re: "Do you think there is any mileage in scrapping the "Cite web" template altogether, and creating a "Cite organization" in its place that does not italicise?" – Absolutely not. It is not possible to cite "an organization" (or individual) on Wikipedia, only a published work. See MOS:ITALICWEBCITE and all the policy it cites on this matter (or see it here if someone's been editwarring against it again). 06:38, 22 October 2019 (UTC) — Preceding unsigned comment added by AReaderOutThataway (talk • contribs) 06:38, 2019 October 22 (UTC)

That guideline did not exist 6 months ago and is indirect contravention of WP:CITESTYLE, so I certainly won't be observing it. Betty Logan (talk) 22:03, 22 October 2019 (UTC)

Contrary to User:AReaderOutThataway's claim, I can find nothing in MOS:ITALICWEBCITE that says we italicize the names of organizations such as companies and institutions in citations. Nothing.--Tenebrae (talk) 18:28, 27 October 2019 (UTC)

I didn't suggest you would (cf. straw man). Read it again, please. You can't cite "an organization". You have to cite something published. If that's a major work (not a minor one like just an article), it's italicized per MOS:TITLES, and the templates do this automagically. The organization itself goes in the |publisher= parameter, which does not italicize. No one here is confused by that, surely not you either, so trying to make it seem like I'm suggesting italicizing organization names is disingenuous.  — AReaderOutThataway ^t/_c 20:27, 29 October 2019 (UTC)

Of course we can cite "an organization." It's done all the time hundreds of thousands of citations around the world: Doe, Jane. "Report on Apollo 11 [link]". NASA. Accessed Jan. 1, 2010. In no real-world scenario would "NASA" be italicized.--Tenebrae (talk) 21:34, 30 October 2019 (UTC)

This should be done the other way around. Don't require the use of |work= (or |website=, |newspaper=, etc.) in {{cite web}} if |publisher= is present, but create a new template, {{cite periodical}}, that does require a periodical parameter. --Ahecht (TALK
PAGE) 19:56, 28 October 2019 (UTC)

I think a "Cite organization" template is an excellent idea. As you say, it's drawn from real-world application, whereas Cite web seeks to impose "standardisation where it does not exist" (or, imo, standardisation for the sake of it). JG66 (talk) 01:04, 31 October 2019 (UTC)

I'm baffled by the failure to distinguish between |work= and |publisher= in the discussion above. Since I prefer CS2 style, if I were free to choose the citation style in an article, I would set up Tenebrae's example as:

{{citation |last=Doe |first=Jane |title=Report on Apollo 11 |publisher=NASA}} → Doe, Jane, Report on Apollo 11, NASA

This implies that the report is a stand-alone document. It is clearly different from something like the following, where the report is one of a set of components of a website.

{{citation |last=Doe |first=Jane |title=Report on Apollo 11 |work=NASA News |publisher=NASA}} → Doe, Jane, "Report on Apollo 11", NASA News, NASA

Organizations are publishers, and as such are clearly not italicized. Organizations' websites are works, and so should be italicized. Peter coxhead (talk) 10:22, 2 February 2020 (UTC)

In the case of stand-alone reports being hosted on an organization's website, say a report that was also published and made available on paper, I just use {{cite book}} and include the courtesy link to the online copy for CS1 citations:

Doe, Jane. Report on Apollo 11. NASA. Retrieved February 2, 2020.

Imzadi 1979 → 19:51, 2 February 2020 (UTC)

If you use {{Citation}}, you don't need to choose "book" or "web", which is irrelevant. The use of the different "cite" templates diverts attention from the semantics of the parameters, in my view.

{{citation |mode=cs1 |last=Doe |first=Jane |title=Report on Apollo 11 |publisher=NASA |url = http://www.example.com/ |access-date = February 2, 2020 }} → Doe, Jane. Report on Apollo 11. NASA. Retrieved February 2, 2020.

Peter coxhead (talk) 20:42, 2 February 2020 (UTC)

That's an excellent suggestion, Peter coxhead. Using Template:Citation avoids the mandatory italicization that, per the note below, should never have been made mandatory in "Cite web". I think your refreshingly simple solution is a great course until the issue below can be addressed. --Tenebrae (talk) 22:27, 3 February 2020 (UTC)

If you do use {{citation}} (a CS2 template) in an article that uses CS1 templates like {{cite web}} and {{cite book}} as the consensus citation style, please make sure to include |mode=cs1 in the {{citation}} template, as illustrated above, in order to keep the article's citation style consistent. – Jonesey95 (talk) 23:52, 3 February 2020 (UTC)

Important note

I wish I had seen this at WP:Consensus#Determining consensus earlier, since it makes this entire discussion moot: "WikiProject advice pages, how-to (emphasis added) and information pages, and template documentation pages (emphasis added) have not formally been approved by the community through the policy and guideline proposal process, thus have no more status than an essay."

That means there is no community consensus that website names should be italicized, and the coder who made that field's italicization mandatory did so without consensus. That mandatory italicization needs to be rescinded. If the coder chooses not to do so, then this issue needs to be addressed at a policy / guideline forum or at the Admin Noticeboard. The guideline page Wikipedia:Citing sources does not make it mandatory, nor does the guideline page Wikipedia:Manual of Style. --Tenebrae (talk) 20:26, 1 February 2020 (UTC)

I am about || this far from reporting you for refusing to drop the stick. --Izno (talk) 21:06, 1 February 2020 (UTC)

I find it remarkable that an admin, because he personally disagrees with an opinion in a re-opened RfC that is still open for comments, would make a threat such as that. You have the right to disagree, but to threaten a fellow editor for saying we need to follow WP:Consensus is wrong. And I'm unclear as to how I'm "wielding a stick" when you made multiple, multiple comments on this topic beginning 07:09, 18 May 2019. Disagreeing with another editor is no reason to threaten them.--Tenebrae (talk) 21:24, 1 February 2020 (UTC)

No, my issue is that you decided to forum shop this issue elsewhere, and have elsewhere decided to harass an editor directly, when you don't have consensus for your position, and moreover seem to misinterpret WP:Consensus to somehow mean that the template is acting inappropriate when there have been multiple RFCs on the point as if that doesn't create consensus for some position or another (regardless of where those RFCs have been held). None of those behaviors are appropriate. You're acting obsessive about this topic, and that's not okay. --Izno (talk) 21:32, 1 February 2020 (UTC)

Let's please take the temperature down a notch. I have not forum-shopped; as I explained to you here, I have followed all rules to the letter. Second, I'm not interpreting WP:Consensus — I quoted it directly. There has been no RfC on any policy/guideline page to make a major, site-wide change to Wikipedia. Third, I have not harassed anyone; if you're talking about my question here, I think you can see or anyone else can see it was worded extremely politely — and since that editor hasn't responded and apparently hasn't even been on Wikipedia in days, it sounds almost as if you're wikistalking me. I understand we disagree. I respect your right to do that. I believe we should confine our discussion to the issue and not make personal threats. I would like to calmly discuss. --Tenebrae (talk) 21:45, 1 February 2020 (UTC)

As editors User:Russian Rocky and User:David Eppstein note here and here, respectively, there is no policy/guideline-page consensus that the names of TV networks or companies must mandatorily be italicized. The two examples one this help page stating that they must be italicized do not represent official consensus and were false and misleading here. --Tenebrae (talk) 14:38, 19 February 2020 (UTC)

RE: "(in particular, do not leave "work" empty with "publisher" non-empty in order to avoid rendering a website's name in italics; a website is a publication and thus its name should be rendered in italics – e.g., as CNN in the example above)."

In the recent RfC and related discussions, there was no consensus that "website=" or "work=" be mandatory and required in all cases. The close certainly did not state that. Yet this passage suggests that one or other of those fields is mandatory. I think we need to establish this before having a passage that suggests they are required. The MOS, at Wikipedia:Citing sources, states directly that flexibility is required for common-sense exceptions, since there is no one-size-fits-all solution.--Tenebrae (talk) 18:42, 15 January 2020 (UTC)

The documentation is clearly wrong here, even if that CNN example will often be right. Headbomb {t · c · p · b} 19:08, 15 January 2020 (UTC)

No. Every citation must cite a source, which is what "work" represents. The work in this case happens to be a website. It has to be there. This is policy, has nothing to do with the RFC. If the module does not throw an error when work (or its aliases) are missing then something is wrong with the code. 71.247.146.98 (talk) 03:07, 16 January 2020 (UTC)

Wrong. Having something like

• Messamore, W. E. (2020). "Thank God PewDiePie Is Finally Gone". CNN.com. CNN.

is pointless. Ie |work=CNN.com if what you are citing was created for CCN.com as a website (i.e. this is the work being cited)

• Messamore, W. E. (2020). "Thank God PewDiePie Is Finally Gone". CNN.com.

if you are citing information that happens to be broadcast on TV, and merely hosted on CNN.com, then CNN (the TV network) is the publisher, not the work.

• Smith, J. (2006). "Audio reveals tense confrontation between Warren and Sanders". CNN.

or, if you feel like digging some more, you can optionally find which program the broadcast was part of, in this case Anderson Cooper 360°. That is the |work=.

• Smith, J. (2006). "Audio reveals tense confrontation between Warren and Sanders". Anderson Cooper 360°. CNN.

Headbomb {t · c · p · b} 03:23, 16 January 2020 (UTC)

It is not wrong at all. Your examples use the wrong template. This should be {{cite news}} or {{cite episode}} or {{cite serial}} or {{cite av media}}. In these templates, the work should also be emphasized. What you may exclude is the publisher, not the source (the work), though the publisher could be pertinent. Works may be published by CNN subsidiaries or divisions. 108.182.15.109 (talk) 15:03, 16 January 2020 (UTC)

Plenty of things are not part of larger works. Headbomb {t · c · p · b} 15:13, 16 January 2020 (UTC)

I don't mean to reopen the RfC debate or any other. I'm simply talking about the language in the documentation page. Simply put, I think the passage says something that isn't true — because "website=" is not required. Should what appears to be an untrue passage stay or go? --Tenebrae (talk) 00:40, 17 January 2020 (UTC)

Personally I don't care if "website" or any other alias of "work" is used. But a work has to be cited. The idea that a reader will look for the source by searching for any other parameter (publisher or anything else) is novel to me. It is also grossly inefficient, imo. 108.182.15.109 (talk) 02:06, 17 January 2020 (UTC)

"A work has to be cited". It doesn't. Many things aren't even part of larger works, e.g.

Beaudoin, N.; Landry, G.; Sandapen, R. (2013). "Generalized isospin, generalized mass groups, and generalized Gell-Mann–Okubo formalism". arXiv:1309.0517.

Headbomb {t · c · p · b} 02:28, 17 January 2020 (UTC)

This example is a bad one. First, it is based on a specialized derivative of {{cite journal}} that is of little interest to the average Wikipedia editor (per the relative number of transclusions), let alone the average reader (I imagine). As a single-source template that is mostly computer-generated, it actually obscures the work (the website arxiv.org). That is because it is targeted to specialists who would know the details. But the average reader does not. The template is badly formatted and presented considering it is part of a general-purpose encyclopedia. If the module was correctly coded, explicit absence of the work (arxiv.org) would have been flagged. Because that is where readers would go to search for, and verify the wikitext, if the specific title-link was bad, or if the in-source location (the titled paper) was not specified for whatever reason. 24.105.132.254 (talk) 16:10, 19 January 2020 (UTC)

It's a perfect example for all the reason you think it's not. The arXiv is simply a repository of preprints. arxiv.org is not the associated "work". The associated work of a paper does not change depending on where it's hosted. Headbomb {t · c · p · b} 16:28, 19 January 2020 (UTC)

For citation purposes, the "work" or source is where verifiable proof is found, if someone cares to look for it. What that work/source actually is, is immaterial. In this case, the item in question can be found in the online version of a certain repository. The distributor (Cornell) maintains a website (arxiv.org) as part of their involvement with the repository (arXiv). In this website (the source), one can find in-source locations (webpages) dedicated to specific papers. There is nothing special about these kinds of citations compared to any other kind. But there is something very special, and not in a good way, about the CS1 templates that purport to format and present these citations. In a general-purpose encyclopedia they are pretty much incomprehensible. And they violate the main rule of citing anything: that the source has to be prominent, clearly and unambiguously presented. Some weird identifier used by a software routine to build a clipped citation-like construct just doesn't cut it. It would be much more helpful to the average reader to junk all that and just state, "follow this link at the arxiv.org website. If the link doesn't work, proceed to arxiv.org and search for this paper." 98.0.246.242 (talk) 02:19, 20 January 2020 (UTC)

I think we're getting far afield. This is a focused discussion on one specific, relatively small thing: Whether to keep a 40-word passage that falsely suggests a template field is required when in fact it is not. --Tenebrae (talk) 18:36, 22 January 2020 (UTC)

It's been nearly three days without comment. Since the passage is factually inaccurate, I'm going to be WP:BOLD and remove it.

No one is arguing in favor of it except for one anon-IP comment that also is factually wrong itself in saying "website+" "has to be there. This is policy." No, it's not — it's not even required by the Manual of Style. And, "If the module does not throw an error when work (or its aliases) are missing then something is wrong with the code." There's nothing "wrong" with the code, because "website=" is not required.--Tenebrae (talk) 10:28, 25 January 2020 (UTC)

Since this discussion began, an editor unilaterally changed the passage under discussion, showing no respect to the discussion process or to any of the fellow editors here discussing in good faith. As this discussion notes, it's inaccurate to suggest a field is required when it is not. Rather than WP:OWN the article and refuse to discuss the issue, I ask the editor who inserted and unilaterally changed this to discuss it here. --Tenebrae (talk) 10:35, 25 January 2020 (UTC)

Pinging @Headbomb:, the other registered editors so far involved in this discussion, to comment on this new development.--Tenebrae (talk) 10:38, 25 January 2020 (UTC)

• @Tenebrae: as you said, there was no consensus that "website=" or "work=" be mandatory and required in all cases. Nevertheless, some users continue to revert others' edits because they consider the use of this "publisher=" parameter as a "violation of citation style". What do you advise? I think it needs to be explained in Help:Citation Style 1#Work and publisher because such a practice is unhealthy for the community.--Russian Rocky (talk) 17:49, 15 February 2020 (UTC)
  • I agree that work= or website= has never been agreed to be mandatory (regardless of whether we also have a non-empty publisher) and I don't think that the passage in question, if read carefully, supports that misinterpretation. Nevertheless it is clear from contributors above like 71.247.146.98 that editors will misinterpret it as meaning that. So I think that it needs to be worded better, to make clear that (1) publisher without work can be ok, for standalone titles that are not part of a larger work, and (2) parameters should not be misused for the purpose of formatting — if a piece of metadata really is the work and not the publisher, it should go in the work field and not the publisher field, regardless of how the editor putting it there feels about italicization. —David Eppstein (talk) 18:36, 15 February 2020 (UTC)
    • Well, this is wrong. A source is mandatory in citations per Wikipedia policy. This source is the work, whether one uses citation jargon or plain everyday English. There is confusion on the subject because of the inconsistent design logic of the citation templates which unfortunately carried over to their Lua incarnation (this has been pointed out for years...). That is why |title= (a source) in {{cite book}} signifies something different from |title= (an in-source location) in {{cite journal}}. The bad design logic subsequently led people to believe that |work= is just another parameter. It is not. As the representation of the source, it is the foundation around which anything that cites sources is based. There is no such thing as a free-standing "standalone title". A "title" is an abstraction. Actually, it is an attribute of the work, and of |work=, these two are not different entities. Because of the bad/inconsistent design the title attribute took a non-justified concrete aspect of its own. Which obviously may lead to the idea that you can have a citation that includes another source attribute (the publisher) without presenting clearly what the published work is. 98.0.246.242 (talk) 01:52, 21 February 2020 (UTC)

A web page's content is replaced monthly; if I cite a specific version, from a previous month, complete with an archive URL, what value should I use for |url-status? It's not "dead", nor is it "usurped", but neither does it display the cited content. Do we need a new value, say, "replaced"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 15 January 2020 (UTC)

Ah, this discussion again...

See Help talk:Citation Style 1 § spam black list and archive urls and preceding discussions linked from there. Apparently we don't know the answer to this question, or if we do, this editor is not clever enough to decode the answer from the discussions.

—Trappist the monk (talk) 16:13, 15 January 2020 (UTC)

If this is a FAQ, perhaps you could dial down the sarcasm, and instead add it as such in the template's documentation, which I had the courtesy to check before asking here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 15 January 2020 (UTC)

I don't really see how this case differs from citing the front page of any major news organization (for whatever reason) as the content is still provided at the archive URL (if you really want to make a point of when it was relevant, add an accessdate). |url-status=live IMO. --Izno (talk) 16:17, 15 January 2020 (UTC)

It probably isn't; but then I'm more likely to cite - and to teach others to cite - a specific news page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 15 January 2020 (UTC)

Per your OP, you want to cite a previous, archived version. If the archive is by the same publisher, you add the original url and the archive url, plus the indication that the original is no longer live. Including the access dates. If the archive is by a different publisher, you are no longer citing the original source. You are citing an archive. If it is online, use {{cite web}}. If not online, use {{citation}}. 71.247.146.98 (talk) 02:47, 16 January 2020 (UTC)

"you are no longer citing the original source" Not so; I can cite a version I saw before it was changed; and perhaps one that I have in a local copy. I might also be fixing up links from citations made when the version cited was live. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 16 January 2020 (UTC)

Versions you saw in the past and versions you have in local copy are unreliable sources. The only way to "fix" citations that used to be live-linked is to link to a reliable archive. The other option is to remove the link altogether, which means, if the citation depended on online verification, it is no longer valid. 108.182.15.109 (talk) 14:42, 16 January 2020 (UTC)

"Versions you saw in the past and versions you have in local copy are unreliable sources" That's bunkum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:15, 31 January 2020 (UTC)

Is it? Why should anyone consider you a reliable source? I hope you were not being serious. 98.0.246.242 (talk) 01:55, 21 February 2020 (UTC)

I'm proposing a Wikimedia Foundation Project Grant to study *disinformation* and provide actionable insights and recommendations.

Please check it out and endorse it if you support it.

Meta:Grants:Project/Misinformation_And_Its_Discontents:_Narrative_Recommendations_on_Wikipedia's_Vulnerabilities_and_Resilience

Cheers! -Jake Ocaasi ^{t | c} 20:28, 19 February 2020 (UTC)

Pardon me, are you being ironic? This proposal includes a fair amount of opinion and conjecture, including blatant self-references regarding Wikipedia's reliability. Wikipedia was never designed to be reliable, and it is not actually reliable no matter how many ex-post-facto studies try to prove otherwise. The simple, obvious reason is that it is based on input from anonymous contributors, which makes it a priori unreliable. This is the reason for the verification policy and the existence of pages like this one. A less charitable characterization might label the project, with no irony intended at all, as self-serving disinformation. 98.0.246.242 (talk) 02:08, 21 February 2020 (UTC)

The pmc parameter is the PubMed Central identifier. PMCs are sequential numbers beginning at 1 and counting up. Module:Citation/CS1 checks the PMC identifier to make sure that the value is a number greater than zero and less than 6000000 and that the identifier contains only digits. Further validation is not performed.

MMWR Morb Mortal Wkly Rep. 2020 Feb 7; 69(5): 140–146.
Published online 2020 Feb 7.
doi: 10.15585/mmwr.mm6905e1
PMCID: PMC7004396
PMID: 32027631

Whywhenwhohow (talk) 09:00, 20 February 2020 (UTC)

limit adjusted to 7050000 in sandbox.

—Trappist the monk (talk) 14:51, 20 February 2020 (UTC)

Was the help error message updated too? When will the changes go live? Whywhenwhohow (talk) 21:10, 20 February 2020 (UTC)

Is there a parameter that can be added to the template to disable the Check |pmc= value (help) message? Whywhenwhohow (talk) 04:56, 21 February 2020 (UTC)

No, you just need to hope that someone will treat this like a hotfix rather than a mission critical deployment that needs 4-6 months of testing. Headbomb {t · c · p · b} 11:32, 21 February 2020 (UTC)

This came up during a GAN: when using {{cite web}}, should |website= (or |work= if using that instead) show Billboard or Billboard.com? Several magazines, newspapers, etc., have both a printed version and a website with different content. Although the former use {{cite magazine}} and {{cite news}}, when used in an article, |work= (or the equivalent) appear the same for all three. If the template doesn't include an issue or page number, it isn't apparent to a reader if it's the print version or the website (except if |title= is linked).

Also, should |publisher= for a website be routinely required? According to the documentation for the templates, publisher is "Not normally used for periodicals" (although it includes an example). As a practical consideration, websites often change owners (or at least their names). It's not the same as adding a book publisher, which may be important when trying to identify a particular edition with different page numbers, spelling, etc.

—Ojorojo (talk) 16:36, 15 February 2020 (UTC)

Billboard. I don't think that there is much distinction between print and on-line; they are utterances of the same source under that source's common name. Were it me, I would use {{cite magazine}} when citing Billboard.

|publisher= for a website is not required as that quote that you included in your post illustrates. You might read Help:Citation Style 1 § Work and publisher.

—Trappist the monk (talk) 12:43, 17 February 2020 (UTC)

Thanks, that explains it (I came here directly from the template page). —Ojorojo (talk) 14:33, 17 February 2020 (UTC)

There is often quite a difference between a magazine's print and online content, no matter what some cite template editors think. I've seen examples (mojo4music and uncut.co.uk come to mind) where the online pieces either act as a teaser for the print issue, giving portions of features, or clearly state that something is online-exclusive content and invite reader (online) participation. JG66 (talk) 14:49, 17 February 2020 (UTC)

I can see how I might have been less than clear in my previous post. I was trying, and apparently failed, to say that the lack of distinction that I see is not about content but about the source: |<work alias>=[[Billboard (magazine)|Billboard]] and |<work alias>=[[Billboard.com]] are synonymous names for the same source (at en.wiki the latter is a redirect to the former). I'm pretty sure that no one in this discussion is saying that a magazine's print and online content are or must be the same. The content is still an utterance of the source whether 'tis on-line or in print. We should link to teasers only when the teaser fully supports our article's content; when it does not, and, frankly, even when it does, such links are less than ideal because the source's full context is not clear or available to our readers.

—Trappist the monk (talk) 16:17, 17 February 2020 (UTC)

"We should link to teasers only when the teaser fully supports our article's content ..." What the fuck are you talking about? Of course we'd only "link" [source a statement?] to a "teaser" if it fully supports what's stated in the article. I believe that would have something to do with WP:VERIFY.

You're just cloaking this in more foggy terminology that seems to reflect a template-is-all perspective. Template is bollocks, as far as I'm concerned, as a writer and researcher; correct representation of the source is paramount. You're talking "work" and synonymous names (in article-mainspace-speak, I'm seeing that as original research or synthesis), but a print magazine and its website are separate sources if the content differs. One would be cite magazine, the other cite web, for a start. I'm getting very concerned, further to Tenebrae's statement under the RfC above, that this citation method is the domain of a few neatness freaks that want to see everything boxed away just so and in a method of their choosing. Same as at the MoS, there is no need, no purpose, for this thing unless editors write articles that require Citation Style 1. JG66 (talk) 15:44, 21 February 2020 (UTC)

This edit request to Module:Citation/CS1/Identifiers has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

biorxiv seems to be using a new format with pages such as https://www.biorxiv.org/content/10.1101/2020.01.22.915660v1. Please change the verification to:

--[[--------------------------< B I O R X I V >-----------------------------------------------------------------

Format bioRxiv id and do simple error checking.  BiorXiv ids are of two forms:
the older form has exactly 6 digits, while the newer form is yyyy.mm.dd.6num.

There is an optional version part that we do not accept for now.

The bioRxiv id is the number following the last slash in the bioRxiv-issued DOI:
https://doi.org/10.1101/078733 -> 078733

]]

local function biorxiv(id)
	local handler = cfg.id_handlers['BIORXIV'];
	local err_cat = '';															-- presume that bioRxiv id is valid
	
	if nil == (id:match("^%d%d%d%d%d%d$") or id:match("^20%d%d.[01]%d.[0-3]%d.%d%d%d%d%d%d")) then						-- test for 6num or 20yy.mm.dd.6num
		err_cat = ' ' .. set_error( 'bad_biorxiv');	-- set an error message
	end
	
	return external_link_id({link = handler.link, label = handler.label, q = handler.q,
			prefix=handler.prefix,id=id,separator=handler.separator,
			encode=handler.encode, access=handler.access}) .. err_cat;
end

Artoria2e5 🌉 02:47, 5 February 2020 (UTC)

Further information is available at the About bioRxiv page, where they say bioRxiv DOIs assigned prior to December 11, 2019, have a simple six-digit suffix, whereas those assigned after this date will also include the date stamp for the day of submission approval. They give examples of 2019.12.11.123456 and 2019.12.11.123456v2 for the new format. – Jonesey95 (talk) 04:18, 5 February 2020 (UTC)

Fixed in the sandbox. I added some crude date validation and check for the version indicator separately:

• {{cite biorxiv/new |title=Title |biorxiv=915660}} → "Title". bioRxiv 915660. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.22.915660}} → "Title". bioRxiv 2020.01.22.915660. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.22.915660v1}} → "Title". bioRxiv 2020.01.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)

• {{cite biorxiv/new |title=Title |biorxiv=2011.01.22.915660v1}} → "Title". bioRxiv 2011.01.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2011.01.22.915660v1}} → "Title". bioRxiv 2020.13.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.35.915660v1}} → "Title". bioRxiv 2020.01.35.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)
• {{cite biorxiv/new |title=Title |biorxiv=2020.01.00.915660v1}} → "Title". bioRxiv 2020.01.00.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help)

—Trappist the monk (talk) 16:12, 5 February 2020 (UTC)

I wonder if {{cite biorxiv/new |title=Title |biorxiv=2021.01.22.915660v1}} → "Title". bioRxiv 2021.01.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help) should display an error (changed the year). --Izno (talk) 17:11, 5 February 2020 (UTC)

I too wondered that but didn't arrive at any decision. Where is the cutoff? Tomorrow? Next month? Next year? A year from today? A month from today?

—Trappist the monk (talk) 01:18, 6 February 2020 (UTC)

Tomorrow seems a pretty reasonable cutoff. Headbomb {t · c · p · b} 09:26, 19 February 2020 (UTC)

Tomorrow:

• {{cite biorxiv/new |title=Title |biorxiv=2024.04.22.915660v1}} → "Title". bioRxiv 2024.04.22.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help) today
• {{cite biorxiv/new |title=Title |biorxiv=2024.04.23.915660v1}} → "Title". bioRxiv 2024.04.23.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help) tomorrow
• {{cite biorxiv/new |title=Title |biorxiv=2024.04.24.915660v1}} → "Title". bioRxiv 2024.04.24.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help) day after tomorrow

Also, better new-form start-date validation:

• {{cite biorxiv/new |title=Title |biorxiv=2019.12.11.915660v1}} → "Title". bioRxiv 2019.12.11.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help) start date
• {{cite biorxiv/new |title=Title |biorxiv=2019.12.10.915660v1}} → "Title". bioRxiv 2019.12.10.915660v1. {{cite bioRxiv}}: Check |biorxiv= value (help) day before start date

—Trappist the monk (talk) 17:20, 21 February 2020 (UTC)

In Template: cite news (and other citation templates as well), would it be possible to have an access parameter for websites that are blocked in many countries? Best example being many American use websites e.g. Chicago Tribune, are blocked in the EU (& UK) due to GDPR. And it'd be good for this to be shown in the citation so that EU/UK readers don't waste their time trying to go to these URLs, in the same way you see subscription based sites in citations. Joseph2302 (talk) 12:33, 2 February 2020 (UTC)

This has been requested before and rejected accordingly. Please take a minute to search the archives. --Izno (talk) 12:51, 2 February 2020 (UTC)

This has been a recent discussion: Help talk:Citation Style 1/Archive 62#New url-status needed: content-missing --Matthiaspaul (talk) 19:29, 2 February 2020 (UTC)

I cannot find how to insert all the data into the Cite web template: for example, the template indicates only one language, that is, I understand, the language of the translation. But how do I mention the work in the original, which is important? GregZak (talk) 09:26, 10 February 2020 (UTC)

Is your post here in the proper place? What does this have to do with the various access parameters? Perhaps you should make your post and any replies a separate section of this help page.

|language= supports multiple language-names or language-codes where the parameter's value has the form of a comma-separated list: |language=de, fr, pl.

—Trappist the monk (talk) 13:01, 10 February 2020 (UTC)

Oh, thank you - I didn't see notification for your reply. Will try to grasp what exactly to do. GregZak (talk) 19:46, 22 February 2020 (UTC)

Would it be possible to add a series-link? Many books without links of their own are covered in one on the series. You can of course link them inline, but given the other -link parameters, it seems that this is not the direction the template is moving in. Hawkeye7 (discuss) 21:39, 23 February 2020 (UTC)

The template produces an error for valid biorxiv values. bioRxiv DOIs use a new format that isn't supported by the biorxiv parameter.

Excerpt from https://www.biorxiv.org/submit-a-manuscript

Preprints deposited in bioRxiv can be cited using their digital object identifier (DOI). bioRxiv DOIs assigned prior to December 11, 2019, have a simple six-digit suffix, whereas those assigned after this date will also include the date stamp for the day of submission approval (see below). Revised versions of manuscripts retain the same DOI assigned to the first version.

Examples

{{cite biorxiv | biorxiv=2020.02.07.937862 | title=Broken example}}
"Broken example". bioRxiv 2020.02.07.937862. {{cite bioRxiv}}: Check |biorxiv= value (help)
{{cite journal | biorxiv=2020.02.07.937862 | title=Broken example}}
"Broken example". bioRxiv 2020.02.07.937862. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)

Whywhenwhohow (talk) 04:12, 19 February 2020 (UTC)

This is fixed in the CS1 sandboxes:

{{cite biorxiv/new | biorxiv=2020.02.07.937862 | title=Broken example}}

"Broken example". bioRxiv 2020.02.07.937862. {{cite bioRxiv}}: Check |biorxiv= value (help)

{{cite journal/new | biorxiv=2020.02.07.937862 | title=Broken example}}

"Broken example". bioRxiv 2020.02.07.937862. {{cite journal}}: Check |biorxiv= value (help); Cite journal requires |journal= (help)

The sandbox is moved to the live module every few months. – Jonesey95 (talk) 04:18, 19 February 2020 (UTC)

A fix like this should not wait a "few months". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:32, 19 February 2020 (UTC)

Is there a parameter that can be added to the template to disable the Check |biorxiv= value (help) message? Whywhenwhohow (talk) 04:58, 21 February 2020 (UTC)

Nope, you just need to wait for an indeterminate period of this to be deployed. Headbomb {t · c · p · b} 00:07, 25 February 2020 (UTC)

Inspired by a VP/T discussion, when I find a reference with archived-date + accessdate I tend to remove the latter with edit summary access-date superseded by archive-date, because having both can make the article significantly larger, e.g., +12,533 -1,811 -826, with harder to read references. –84.46.52.252 (talk) 12:09, 11 February 2020 (UTC)

Not a good practice. They are not interchangeable parameters, and the corresponding dates serve different info. 72.43.99.138 (talk) 14:20, 11 February 2020 (UTC)

This discussion is a regular one. Please feel free to review the archives. I generally take the stance of IP84 but don't spend a lot of time on articles I'm just reading. --Izno (talk) 14:49, 11 February 2020 (UTC)

I think that it is not a good idea to blanket remove |access-date=. Many upon many |archive-url= parameters are added by bot. I have seen cases where the archive does not support our article's text. This is likely because the bot cannot evaluate the archive's content to see if that content supports the text in our article. Websites are ephemeral and the 'nearest' archived copy may be markedly different from the website content on the date it was accessed. I am not necessarily opposed to removal of access dates when a proper evaluation of the archive shows that it supports our article text though it does seem better to leave it; it is not worth the effort required to save a mere few kbytes.

For your other example, when the article has {{use xxx dates}}, it is perfectly acceptable to remove |df= from all cs1|2 templates except where it is determined that a different date format for 'this' citation is necessary.

—Trappist the monk (talk) 15:22, 11 February 2020 (UTC)

Makes sense, and IIRC my efforts in this direction were limited to articles, where I did the pending checked=true on their talk page, incl. two GA candidates- On two former drafts, where preemptive IA-Bot activities ended up in url-status=live, the archive-date was close to my accessdate. –84.46.52.252 (talk) 16:26, 11 February 2020 (UTC)

This has nothing to do with readability, ease of use or article size. Both dates are verification helpers, and in the case of online-only sources, (arguably) necessary. However archives are an altogether different class of source/proof. In any case, by definition dates are terse statements. In contrast, close reading of any article may reveal sizable chunks of wikitext that are verbose or superfluous and also, not relevant to verification. I would direct my energies there. 72.43.99.138 (talk) 23:49, 11 February 2020 (UTC)

I think the access date serves important verifiability functions. When I add archives manually I attempt to find an archive after but as close to the access date. Even then web pages can change instantly, for any potentially controversial or time sensitive subjects the access date is crucial. I prefer cleaner citations so if the two dates are reasonably close I don't object to the removal of access date. If I have the time and the best way would be to Verify the facts in the article are supported by the archive then remove the access date. Hope this input is helpful. MrBill3 (talk) 11:59, 25 February 2020 (UTC)

There appears to be a problem with the rendering of a non-breaking space in the cite templates.

As an example

{{cite news|title=Test|pages=1, 9}}

Renders with "&nbsp," showing rather than a space.

"Test". pp. 1, 9.

Keith D (talk) 21:20, 25 February 2020 (UTC)

The correct practice is to use unspaced page number separators. I believe the module code uses zero-width spaces in certain fields but I am not certain. 172.254.98.154 (talk) 01:14, 26 February 2020 (UTC)

Module:Citation/CS1 doesn't care if the individual page numbers in a list are spaced or unspaced except that when there are spaces those spaces should be the plain, everyday, keyboard space character. They should not be html entities; they should not be other unicode space-like characters. The module suite does not use zero-width spaces.

Because editors have and will continue to use semicolons as page number separator characters, the module recognizes the trailing semicolon in   as a separator character, not as an integral part of the html entity. The proscription against the use of html entities in cs1|2 parameter values is noted on every cs1|2 template documentation pages as, for example, at Template:Cite news § COinS.

I think that this is the first complaint about   and a fix is relatively easy to apply.

The no-break-space entity is replaced with a simple space.

—Trappist the monk (talk) 14:18, 26 February 2020 (UTC)

The reasoning for unspaced page number separators has more to do with the fact that in some citation formats comma+space may be used as a field separator. This could make the presentation ambiguous. A rarer case of the same would involve multiple issue or volume numbers in their respective fields. 24.105.132.254 (talk) 18:34, 26 February 2020 (UTC)

I suggest adding a license parameter for values like license=CC-BY-NC-ND 4.0. To accomplish that today requires using something like id=License:CC-BY-NC-ND 4.0 but the |id= isn't supported for some subsets like biorxiv. Whywhenwhohow (talk) 19:05, 26 February 2020 (UTC)

See recent discussion in the archives. In short, "why?" --Izno (talk) 20:10, 26 February 2020 (UTC)

No. As has been repeatedly debated (see also this), the purpose of citations is to verify information. Reporting under which license a paper is published does not do anything towards verifying information. Headbomb {t · c · p · b} 21:16, 26 February 2020 (UTC)

The DOI prefix is the same. It would display medrxiv instead of biorxiv in the citations.

Whywhenwhohow (talk) 04:28, 19 February 2020 (UTC)

Really, it's high time we have a general {{cite preprint}} Headbomb {t · c · p · b} 09:24, 19 February 2020 (UTC)

I don't think anyone disagrees... we're just WP:Volunteers though. --Izno (talk) 21:13, 19 February 2020 (UTC)

If we did this, does that mean that {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, {{cite ssrn}} go away? If not, then {{cite preprint}} becomes just another limited-parameter template in which case it could be a wrapper-template that invokes the appropriate limited-parameter template according to which one of |arxiv=, |biorxiv=, |citeseerx= or |ssrn= is present in the calling template.

—Trappist the monk (talk) 22:45, 19 February 2020 (UTC)

I found seven articles that included the term medrxiv; there is no MedRxiv article. The listed dois for a couple of those articles did not work. Perhaps |medrxiv= ({{cite medrxiv}}) is an idea whose time has not yet come.

—Trappist the monk (talk) 22:45, 19 February 2020 (UTC)

MedRxiv should probably just be redirected to Cold Spring Harbour Laboratory, much like most of the Center for Open Science preprints should redirect there. Point is, these are sprouting like hot cakes, and we could be handling them with one general {{cite preprint}}, and dedicated parameters, like |arxiv=biorxiv which each have their validation (when known). Headbomb {t · c · p · b} 23:04, 19 February 2020 (UTC)

I don't think that I got an answer to my question.

I have created {{cite preprint}} as a wrapper for {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}}:

{{cite preprint |author=Author |title=Title |arxiv=gr-qc/0610068}}

Author. "Title". arXiv:gr-qc/0610068. {{cite arXiv}}: |author= has generic name (help)

{{cite preprint |author=Author |title=Title |biorxiv=108712}}

Author. "Title". bioRxiv 108712. {{cite bioRxiv}}: |author= has generic name (help); Check |biorxiv= value (help)

{{cite preprint |author=Author |title=Title |citeseerx=10.1.1.368.2254}}

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

{{cite preprint |author=Author |title=Title |ssrn=991169}}

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

The question was: create a wrapper and keep the individual {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}} templates; or create a {{cite preprint}} template as part of Module:Citation/CS1 and delete the individual preprint templates?

—Trappist the monk (talk) 15:23, 20 February 2020 (UTC)

Could just redirect them to a {{cite preprint}} and tweak the behaviour of the metatemplate based on which preprint parameter exists is declared. But the wrapper method could also work. Whatever scales best. Headbomb {t · c · p · b} 15:41, 20 February 2020 (UTC)

I think we are at the point where we should redirect/delete the individual templates. --Izno (talk) 16:22, 20 February 2020 (UTC)

If I may hijack the discussion, I think we should also add a |philsci= parameter, that would generate the text (e.g.) "PhilSci:3886". This is a link to the PhilSci-Archive, an archive of papers on the philosophy of science. There are around 25 citations to it in Wikipedia. Tercer (talk) 06:45, 28 February 2020 (UTC)

In the citation

• Puharic, Douglas (December 2013 – January 2014). "Review of Chases and Escapes". The Mathematics Teacher. 107 (5): 395. doi:10.5951/mathteacher.107.5.0394. JSTOR 10.5951/mathteacher.107.5.0394. {{cite journal}}: Check date values in: |date= (help); no-break space character in |date= at position 16 (help)

I am getting an error message "Check date values in: |date=". This is the correct date (JSTOR lists it as "December 2013/January 2014"). MOS:DATERANGE, in the bullet point with the bold headings "month–month" and "between months in different years", give exactly this format, with a spaced en-dash, citing for instance the example of "May 1940 – July 1940". How can I convince the citation template that this is a valid format? —David Eppstein (talk) 00:01, 23 February 2020 (UTC)

In your citation there is a no-break-space character after the ndash; see here. Use a plain everyday ordinary space character:

Puharic, Douglas (December 2013 – January 2014). "Review of Chases and Escapes". The Mathematics Teacher. 107 (5): 395. doi:10.5951/mathteacher.107.5.0394. JSTOR 10.5951/mathteacher.107.5.0394.

—Trappist the monk (talk) 00:08, 23 February 2020 (UTC)

Well I can't see that when I edit the source. That error message is singularly unhelpful as a way of diagnosing this. And in fact the MOS explicitly recommends a no-break space (but on the other side of the en-dash, not here). Is there some reason you can't just treat it as a space? —David Eppstein (talk) 00:12, 23 February 2020 (UTC)

It is interesting that it is apparently you who added the nbsp to the date range when you converted December 2013/January 2014 to December 2013 – January 2014. The solidus-separated date range at jstor does not include the nbsp character.

—Trappist the monk (talk) 13:08, 23 February 2020 (UTC)

Of course I put it there. Did you even read the bug report? The bug is that when I tried to add this citation I could not figure out why it was giving me an error, because the difference between the correct coding and the coding I was using was not visible. So I left it there in an erroneous state because I could not figure out how to change it to be non-erroneous. I think the explanation for this instance is probably a lot more boring than you expect. I copied and pasted the citation format from some custom software I use to convert bibtex into citation templates. For some reason it put an nbsp there. That is not the only bug, but the other ones are more visible than the difference between a space and a no-break space. I think the nbsp is there in the citation template because the software wants it to be there in the bibtex version of the same date (so that we don't get a weird line break in the middle of a date range in bibtex-formatted bibliographies) and it doesn't know that the citation template is so much less forgiving of slightly-variant dates than bibtex is. I may be able to fix it but (because of the vagaries of Python/OS-X interoperation) I am not entirely certain I can compile it any more. And in any case the same bug would happen if I were typing dates manually — the correct key presses are space, option-key down, hyphen, option-key up, space and I would get the same exact string as the one in question if my left-right hand coordination were a little off and I left the option key down while typing the second space. (On the Mac, option-space translates to no-break space.) So it could have easily happened manually even though in this case it didn't. —David Eppstein (talk) 02:19, 26 February 2020 (UTC)

I don't really understand why it doesn't show an error in the sandbox, but I've made a modification that would make non-breaking spaces obvious there. See:

• Puharic, Douglas (December 2013 – January 2014). "Review of Chases and Escapes". The Mathematics Teacher. 107 (5): 395. doi:10.5951/mathteacher.107.5.0394. JSTOR 10.5951/mathteacher.107.5.0394.

--Izno (talk) 00:48, 23 February 2020 (UTC)

Because there isn't a nbsp character in your example citation? There is here:

{{cite book/new |title=Title |date=December 2013 – January 2014}} → Title. December 2013 – January 2014. {{cite book}}: Check date values in: |date= (help); no-break space character in |date= at position 16 (help)

I don't remember if we elected to not detect the nbsp character when we added invisible character detection. At the moment I can't think of a reason why we shouldn't be detecting that character.

—Trappist the monk (talk) 00:56, 23 February 2020 (UTC)

I did not see it in the originating discussion. --Izno (talk) 02:38, 23 February 2020 (UTC)

That said, the particular character is the next after the C1 control characters. Should it be in that test or should it be separate? (I can see benefit both ways.) --Izno (talk) 02:42, 23 February 2020 (UTC)

Probably best as a separate. Even though nbsp is listed in C1 Controls and Latin-1 Supplement it is not a c1 control character as we annotate them in the invisible-character error message. We test shy separately so we should test nbsp separately.

—Trappist the monk (talk) 13:08, 23 February 2020 (UTC)

Check to see if nbsp is broken (aside from below): Title. December 2013 – January 2014. {{cite book}}: Check date values in: |date= (help). So the test for the invisible character now functions and people can be made aware that they should not add a non-breaking space here (perhaps in contravention to the MOS). Perhaps the module should consider enforcing the no-breaking-space addition before the dash as well? --Izno (talk) 01:38, 26 February 2020 (UTC)

{{cite journal}} also gives a red "check date values in" warning for some citations generated automatically in the Visual Editor, because the source date is filled in as, e.g., "2020-02". It's an easy manual fix, of course, once you know that "February 2020" would be a replacement that's acceptable to the software, but all the same, it's vaguely exasperating that the output of one program isn't acceptable to the other. XOR'easter (talk) 18:14, 26 February 2020 (UTC)

YYYY-MM dates are not acceptable to en.wiki's MOS so cs1|2 does not accept them as valid dates. In our moderately recent past (2017), there was discussion about modifying Citoid to emit numeric dates using formats defined in something called EDTF (Extended date time format) which became part of ISO DIS 8601 2016 to handle YYYY-MM and other sorts of 'incomplete' dates. I don't know if that ever made it into a real standard or no. See the stalled discussion at phab:T132308 and these archived discussions: Help talk:Citation Style 1/Archive 33#edtf date formats as cs1|2 date parameter values and Help talk:Citation Style 1/Archive 37#edtf experiment removed.

—Trappist the monk (talk) 18:49, 26 February 2020 (UTC)

The problem with YYYY-MM date will always remain, they are ambiguous and confusing because you don't know if you're looking at YYYY-MM or YYYY-YY. 2007-08 could mean 2007–2008 just as it could mean August 2007. Headbomb {t · c · p · b} 21:38, 26 February 2020 (UTC)

Which was why the proposal allowed for YYYY-MM-XX where ISO DIS 8601 2016 defines -XX to mean an unspecified day. At the time of the experiment, the Module sandbox accepted '-UU' (the form suggested by EDTF) but rendered the YYYY-MM-UU date as Mmmm YYYY. The YYYY-?? form where ?? < 13 was (and without -XX) was not allowed because of year/month ambiguity and still required YY in YYYY-YY to represent a year one-year greater than year YYYY.

—Trappist the monk (talk) 23:50, 26 February 2020 (UTC)

https://www.loc.gov/standards/datetime/background.html indicates that EDTF became part of ISO 8601 in 2019 and the standard was revised to https://www.loc.gov/standards/datetime/. --AntiCompositeNumber (talk) 17:04, 1 March 2020 (UTC)

Thanks for that. I've added the link to the standard to the phab discussion.

—Trappist the monk (talk) 18:07, 1 March 2020 (UTC)

Per a discussion which occured on WP:Discord, I was hoping we could do a similar cat_maint to archived_copy for when the |title= input is "Bloomberg - Are you a robot?" or "Bloomberg – Are you a robot?". It'd just to help keep track of that because there are a few hundred articles which have that problem. –MJL ‐Talk‐^☖ 17:01, 1 March 2020 (UTC)

Wouldn't it be better to fix the source of those 'titles'? I've seen edits that created these come from ReFill (example) and from ve (example). They can also be created by RefToolBar. All of that suggests that the real culprit is Citoid. I don't see a need for a special category if Citoid gets fixed.

—Trappist the monk (talk) 18:18, 1 March 2020 (UTC)

Agreed, fixing the source of the problem is best. If Citoid is fixed and returns the correct metadata, the 684 affected articles could be fixed automatically or semi-automatically. --AntiCompositeNumber (talk) 19:22, 2 March 2020 (UTC)

Hi, I encountered a small glitch using {{cite web}}{{cite book}}:

Using one of the |author-link= etc. parameters, the link will be automatically suppressed when the citation is used on the page linked to by |author-link=. This is convenient when copying citations between articles, and also helps maintenance when articles get renamed.

I thought the same feature would be available for |title-link=, but it isn't. If this is used on the target page, the link isn't suppressed and consequently is shown in boldface, which looks odd. I think we should add the same auto-suppression to |title-link= as well.

There is a related feature which would be neat to have: If one of the |*-link= parameters points to a redirect rather than an article, it should be followed and the link should be suppressed if the template happens to be invoked from the redirect's target page as well. This would not only help keeping the link suppression feature work when renaming pages, but also would allow to deliberately go through redirects in order to reduce future maintenance.

It would be great if this could be fixed and implemented. --Matthiaspaul (talk) 01:40, 10 January 2020 (UTC)

Umm, {{cite web}} doesn't support|title-link=:

{{cite web |title=Example |url=//example.com |title-link=Example |website=Example}}

"Example". Example. {{cite web}}: URL–wikilink conflict (help)

Still, for templates that do support |title-link= and do not also have a conflicting |url=, we should probably mute the self-link. I'll attend to that after the pending update.

I do not think that we will follow redirects. To do that, it is necessary to fetch information about the target page from the database; that is an expensive operation when the target page is not the current page.

—Trappist the monk (talk) 12:23, 10 January 2020 (UTC)

That's right, I encountered this using {{cite book}} rather than {{cite web}}. Thanks for correcting me.

I think this "self-link muting feature" should be a general property of all |*-link= parameters everywhere. It seems to work for the family of |author*=, |editor*=, |translator*= and |contributor*= parameters (but I haven't tried all variants), that's why I thought it would be something generic already, but apparently it is not. Are there other parameters for which a |*-link= parameter exists?

Yeah, I was afraid following redirects could be expensive, but still it would be convenient... Assuming it would not actually harm on most pages with only a few references on them, perhaps there could be something like a counter, resolving redirects up to 100 times (or whatever is considered expensive at a time given) per page invocation and then ignoring them - after all it would be just a display convenience feature, not core functionality on which users of the templates should be able to rely on. So it would work on most pages, but still with a guaranteed upper limit for stability. Just some food for thought...

Thanks anyway...

--Matthiaspaul (talk) 21:10, 10 January 2020 (UTC)

The link parameters are the name-list parameters: |author-link=, |contributor-link=, |editor-link=, |interviewer-link=, |subject-link=, and |translator-link=; and two 'title' parameters: |episode-link= and |series-link= which are aliases of the last parameter |title-link=. The name-list parameters already mute self-links and the title parameters will in a future update.

MediaWiki already resolves redirects, it does it all the time, I'm content to let it continue to do that without adding to the complexity of cs1|2.

—Trappist the monk (talk) 23:11, 10 January 2020 (UTC)

Sounds very good to me, thanks.

Would it make sense to add this to |work= and aliases as well?

--Matthiaspaul (talk) 00:12, 11 January 2020 (UTC)

I just saw that there was a related discussion at Module talk:Citation/CS1/Feature_requests#Check for wikilink to current page (although I would not have consider this to belong into CSS). --Matthiaspaul (talk) 21:25, 10 January 2020 (UTC)

When any of the name-list parameters link to the current page, Module:Citation/CS1 simply does not create a link to the current page in that template's rendering. The solution did not involve css. At the time, a css solution would have required a change to Wikipedia-wide css; with the advent of WP:TemplateStyles that requirement is, I think, lifted. Does that mean that we should apply a css solution instead of the don't-link-to-current-page solution? Don't know.

—Trappist the monk (talk) 23:11, 10 January 2020 (UTC)

I am with you here. I consider this to be functionality that should be part of the template rather than display cosmetics only, therefore I would have put it into the templates' code as well rather than trying to address it with CSS.

--Matthiaspaul (talk) 00:12, 11 January 2020 (UTC)

I have tweaked Module:Citation/CS1/sandbox/styles.css so that hyperlinks with the class mw-selflink apply font-weight:inherit instead of the MediaWiki-provided font-weight:bold. Because of this I have also disabled the code in Module:Citation/CS1/sandbox that unlinked name-list parameter values

{{cite book/new |title=Title |title-link=Help talk:Citation Style 1 |author=Bob |author-link=Help talk:Citation Style 1}}

Bob. Title.

{{cite book/new |title=[[Help talk:Citation Style 1|Title]] |author=[[Help talk:Citation Style 1|Bob]]}}

Bob. Title.{{cite book}}: CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 15:59, 4 February 2020 (UTC)

It's a problem in cite journal too. URL from PMC breaks with people using title-link to link to some page they decided was somehow related. Example diff.   — Chris Capoccia 💬 21:05, 2 March 2020 (UTC)

Resolved

Could someone edit he PMC parameter? PMC IDs are now greater than 7000000, so warnings are popping up where it is not necessary.  Bait30  ^Talk? 19:47, 27 February 2020 (UTC)

@Bait30: See Help talk:Citation Style 1#pmc can be larger than 6000000. Headbomb {t · c · p · b} 20:15, 27 February 2020 (UTC)

idk how I missed that. That's unfortunate because it seems like such an easy fix. Hopefully an admin can come by and fix this soon.  Bait30  ^Talk? 20:22, 27 February 2020 (UTC)

The fix is easy, has been done in the sandboxen but is not pressing; there are no lua script errors and at this writing, only 14 of some 4.3-ish million articles that use the module suite are showing the error. Were there lua script errors or thousands of articles showing this particular error, then certainly this would have been fixed by now. Changing one of the modules to fix a minor error dumps all 4.3-ish million articles onto the MediaWiki job queue. So, we defer updates until there are more substantive changes to be made, and then update the module suite. Category:CS1 errors: PMC (0)

—Trappist the monk (talk) 20:49, 27 February 2020 (UTC)

And in the meantime, annoy editors and readers with errors than aren't errors. Both this one and the biorxiv one. Headbomb {t · c · p · b} 21:36, 27 February 2020 (UTC)

Fixing this out of order may open this page to more such requests for all kinds of minor changes. I believe Trappist's rationale is valid. 98.0.246.242 (talk) 23:14, 28 February 2020 (UTC)

Anytime where there's a visible BIG ERROR MESSAGE being emitted erroneously, the template should be updated immediately upon having a fix. This isn't just tweaking a bad comma, it's an active call to action to every editor and reader out there. Headbomb {t · c · p · b} 01:05, 29 February 2020 (UTC)

Umm, cs1|2 deliberately tones down the red error messages. We could have made big error messages but instead we chose to write normal-sized error messages. If only it were true that these error messages were an active call to action to every editor and reader out there; then the several subcategories of Category:CS1 errors holding several thousand articles would have been cleared log ago.

—Trappist the monk (talk) 01:24, 29 February 2020 (UTC)

They are still visible messages being emitted erroneously. As far as calls to actions, some problems are simply easier to tackle than others. Observe the Category:CS1 errors: DOI category for example, which is kept to very close to empty at most times, despite routinely having new items in it. Headbomb {t · c · p · b} 01:32, 29 February 2020 (UTC)

The easiest way to fix the issue you believe to exist is to get consensus that we should break from our regular deployment schedule for minor issues likes this one. You have yet to do so. (I have separately been entertaining writing a little blurb somewhere on this page or nearby so that we have a page to point to about why these modules do not update often, and instructions to deploy, and the pages to notify a week prior.) --Izno (talk) 02:24, 29 February 2020 (UTC)

The easiest way to fix the issue is to update the damned module with the working fix, rather than wait for months in the hope that Trappist unilateraly decides there's enough issues to push the updates live. No other template or module on Wikipedia has a delayed fix schedule that is subject to the whims of a select few who happen to know LUA and possess the admin bit. There's no issue with putting 4 million articles in an update queue. From WP:PERF:

Nothing in this page is to say that editors should not be mindful of performance, only that it should not limit project development.

Headbomb {t · c · p · b} 02:41, 29 February 2020 (UTC)

... So, you're not going to get consensus for your position. That seems somewhere in the realm of unproductive for now and the multiple iterations in the future we'll have this discussion, because this isn't the first time. As for PERF, this module has brought the wiki to its knees before, such that WMF engineers have come to say "no, please don't" after the fact.

I'll speak specifically to No other template or module on Wikipedia has a delayed fix schedule: CS1/2 alone is used sometimes hundreds of times per page and moreover is changed the most of any of the most-widely used templates. Almost every other widely used module or template is stable, simple, and more-or-less has been so for the past half-decade that Lua has been around.

As you might note, I also have declined to push this change live. In doing so, know that I'm respecting the active consensus as I've observed it (and which no-one has challenged in any meaningful sense). If you should achieve consensus that changes like this minor ID check increment can be deployed ad hoc, I will respect that consensus instead. --Izno (talk) 03:21, 29 February 2020 (UTC)

The WMF has never asked anyone to not update or even slow down the updating schedule of the templates, nor has there ever been consensus to stagger updates that would fix things by months because of WP:PERF-reasons. Headbomb {t · c · p · b} 03:32, 29 February 2020 (UTC)

Which is a strawman. At the end of the day, get consensus. --Izno (talk) 03:44, 29 February 2020 (UTC)

This practice has been unilaterally started by Trappist the monk, without any discussion, nor any significant support. Show me consensus for it and I'll shut up. Headbomb {t · c · p · b} 03:45, 29 February 2020 (UTC)

I asked a WMF SRE about it in #wikimedia-tech, and they said that there is a potential for problems and that similar templates have caused issues in the past. Their recommendation was to make any such changes on a weekday during US and Europe working hours when most sysadmins are available.

Making changes to widely-transcluded templates is obviously something we don't want to do recklessly or needlessly, but delaying changes until an undetermined later time is also not a solution. I would suggest that Trappist and others with experience here write up a deployment guide and include a weekly or bi-weekly deployment window, preferably one that doesn't conflict with other related deployments. Having someone check #wikimedia-operations to make sure we're not in the middle of an incident would be a good idea too. There are plenty of other deployments that happen every week that could have a similar or greater affect on stability. --AntiCompositeNumber (talk) 04:41, 29 February 2020 (UTC)

The Anome has updated the identifier check. – Jonesey95 (talk) 20:54, 6 March 2020 (UTC)

I've also notified Trappist the monk that I've done this, as I've only updated the live version, not the version in the staging sandbox. -- The Anome (talk) 21:16, 6 March 2020 (UTC)

It's a bit irritating that you can't manually italicize a newspaper under the publisher parameter. I don't know who thought that a good idea but it's a tad annoying. I am aware that newspaper= works but it's not a good idea showing errors when you try to italicize under the publisher parameter. Sort it out, thanks.♦ Dr. Blofeld 10:21, 7 March 2020 (UTC)

The name of the newspaper goes in the |newspaper= or |work= parameter. The template does the italicization for you. – Jonesey95 (talk) 15:11, 7 March 2020 (UTC)

sort it out lol if you only knew.. -- GreenC 16:19, 7 March 2020 (UTC)

The whole concept of using one of the cite xxx templates is to describe what the text string is, such as publisher or work, and let the template figure out where it should go and how it should look. The problem is when some publications don't follow the traditions that developed during the 19th and 20th century, and decide that they don't need to distinguish between the title of a website and the name of the corporation that publishes it. Or, when a work (not necessarily online) doesn't provide a title at all, and the person citing it has no choice but to write a description that serves in place of a title; CS1 has no way to indicate this. Jc3s5h (talk) 17:32, 7 March 2020 (UTC)

That is all lovely, and could be addressed once again in a separate thread, but Dr. Blofeld specifically addressed putting the name of a newspaper into |publisher=, which is what my answer was attempting to respond to. – Jonesey95 (talk) 19:42, 7 March 2020 (UTC)

And my answer is Dr. Blofeld's request should be rejected. Jc3s5h (talk) 20:34, 7 March 2020 (UTC)

Picking up a point I made at the talk page of {{Use dmy dates}}, the consequence of the CS1/2 templates using this template to standardize dates in citations is that it violates WP:CITERETAIN, because of the retrospective element. There are articles to which {{Use dmy dates}} was added years ago (one example I found is from 2005). When these have consistent (or almost consistent) YYYY-MM-DD access and archive dates, these get changed to DMY dates, contrary to well established guidelines. It's no defence to say that this behaviour can be over-ridden by the use of |cs1-dates=, since no editor knew until the change was made that this parameter was necessary or even existed.

The CS1/2 templates should stop changing the displayed format of access and archive dates when {{Use dmy dates}} is present without |cs1-dates=. Peter coxhead (talk) 11:01, 13 February 2020 (UTC)

On the contrary, parameters allowing a particular citation to contradict the date format set for the entire rest of a page should be deleted. ―cobaltcigs 07:06, 8 March 2020 (UTC)

@Cobaltcigs: see MOS:DATEUNIFY, which is very clear: "Access and archive dates in an article's citations should all use the same format, which may be: the format used for publication dates in the article; the format expected in the citation style adopted in the article (e.g. 20 Sep 2008); or yyyy-mm-dd". I repeat that retrospectively changing the style of citations is a violation of WP:CITERETAIN, and seems to be part of a long (and in this case underhand) campaign by some editors to prevent the allowed use of "yyyy-mm-dd" dates in some contexts. Peter coxhead (talk) 10:30, 8 March 2020 (UTC)