Help talk:Citation Style 1/Archive 60

This is an archive of past discussions about Help:Citation Style 1. 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.

Archive 55

←

Archive 58

→

So, about those required parameters...

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

We need to discuss what the fix is going forward.

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

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

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

I had at least two ideas:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cite news requires |newspaper=

Cite web requires |website=

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What is a style error? According to whom?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

&rft.atitle=Isolation of a common receptor for coxsackie B: A title of a journal article
&rft.jtitle=Science: A title of a journal
&rft.btitle=Professional XML Meta Data: A book title

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

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

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

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

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

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

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

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

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

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

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

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

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

Support year-suffix outside the English alphabet

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

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

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

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

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

Hence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Proposal to change redirects

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

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

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

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

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

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

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

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

Add `|zenodo=`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In the sandbox:

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

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

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

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

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

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

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

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

like that?

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

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

done

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

Multiple url instances

This is currently allowed:

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

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

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

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

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

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

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

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

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

Remove `|url=` when `|doi=` is provided

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

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

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

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

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

Option to turn off PMC autolink

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

script-title=missing prefix

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

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

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

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

Template:Hyphen is corrupted

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

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

Instead of the correct/expected

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

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

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

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

Here it is with |pages=:

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

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

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

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

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

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

Best practice is to use {{hyphen}}, per documentation. Headbomb {t · c · p · b} 18:53, 19 September 2019 (UTC)

Cite news - multiple URLs

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

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

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

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

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

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

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

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

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

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

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

Template:Citation has a mode=cs1 parameter

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

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

Here is a sample:

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

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

{{citation}} is not a cs1 template. It can be made to look like a cs1 template with |mode=cs1. Similarly, cs1 templates can be made to look like cs2 with |mode=cs2. Including cs2 in a table specifically intended for cs1 just muddies the water. You might consider implementing a similar table at Help:Citation Style 2.

I have reverted your edit at HELP:CS1.

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

@Trappist the monk: I don't get it. You say it "is not a cs1 template" but "can be made to look like a cs1 template". What's the difference? The look is everything here. If it looks like one, then it is one. Or am I missing something?

Let me guess: You and the maintainers of CS2 are in competition and zealously avoid any cooperation between each other? User:Martin of Sheffield implied as much in the Teahouse discussion. flowing dreams (talk page) 11:52, 18 September 2019 (UTC)

cs2 differs from cs1 in its rendered style: element separators (cs1: period, cs2: comma); static text (cs1: capitalized, cs2: not capitalized); terminal punctuation (cs1: period, cs2: none); |ref= default value (cs1: not set, cs2: harv). When |mode=cs1 is set in {{citation}} (a cs2 template) the rendered citation uses a period for element separators, capitalized static text, has a period for terminal punctuation, and does not set |ref=. When |mode=cs2 is set in any of the cs1 templates, the rendered citation uses a comma for element separators, does not capitalize static text, does not have terminal punctuation, and sets |ref=harv.

Your guess would be wrong. I have no real preference cs1 or cs2. They are different and I don't see that any benefit is gained by blending their documentation as you apparently want to do.

I presume that the teahouse discussion you mentioned is: Wikipedia:Teahouse#Why is citing so hard?

—Trappist the monk (talk) 12:26, 18 September 2019 (UTC)

Alright, let's review what you said:

CS1 requires:
- Element separators: period
- Static text: capitalized
- terminal punctuation: period
- |ref= default value: not set
When |mode=cs1 is set in {{citation}} (a cs2 template) the rendered citation uses:
- Element separators: period
- Static text: capitalized
- terminal punctuation: period
- |ref= default value: not set

These are what you said. Conclusion: {{Citation|mode=cs1}} is/gives a CS1 citation. So how is this template counted as "not a cs1 template"? You're being contradictory here.

And yes, you have found the correct Teahouse discussion. User:Martin of Sheffield compared the proponents of CS1 as practictioners of arcane black magic who have long blocked a merger that benefits the community. He compared them to Microsoft in a bad way (He wrote M$) and went so far as saying they "put down" editors who use the wrong template. flowing dreams (talk page) 12:41, 18 September 2019 (UTC)

I might add that I don't share all of Martin's view. The context-sesitive error messages that specific-purpose CS1 templates generate are very useful. I discovered this on my own. flowing dreams (talk page) 12:54, 18 September 2019 (UTC)

Flowing dreams seemed to think all that matters is how it looks in the rendered article. Wrong. Within an article the wikitext for the various citations should be similar to make maintenance easier. Jc3s5h (talk) 13:02, 18 September 2019 (UTC)

Please elaborate. flowing dreams (talk page) 13:20, 18 September 2019 (UTC)

{{citation}} with |mode=cs1 is still a cs2 template; its rendering has just been disguised to look like the rendering of a cs1 template.

Editor Martin of Sheffield is entitled to have opinions with regard to cs1|2. This discussion is not about those opinions; it is about including cs2 template documentation in the documentation page for cs1 templates.

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

@Jc3s5h and Trappist the monk: I totally support abandoning all side-discussion and getting to the crux of the matter, so for the third time: Apart from generating CS1-compliant output, what are the criteria for being a CS1 template? flowing dreams (talk page) 13:29, 18 September 2019 (UTC)

Aside from the style that I mentioned before, the obvious (which I didn't mention because it is obvious) is that the cs1 templates are specific to a source type: books → {{cite book}}; news sources → {{cite news}}; preprints held at arXiv → {{cite arxiv}}; dissertations and theses → {{cite thesis}}.

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

I think the intent behind flowing dreams’s edit is just to let other editors know that, should any of the standard CS1 templates not be suitable, a workaround which would still produce the same desired visual formatting for a citation is to use {{Citation}} with |mode=cs1. Perhaps it shouldn’t be mentioned alongside {{Cite journal}} and the like, but I can understand why some editors might find it helpful to be reminded of this as a possibility when adding citations to an article in CS1 style, even if it isn’t a CS1 template itself. Umimmak (talk) 13:49, 18 September 2019 (UTC)

That may very well be true but it doesn't appear to have been an argument put forward by Editor flowing dreams. If it is, I don't object to such a mention in HELP:CS1 but not in the table that is expressly for cs1 templates.

—Trappist the monk (talk) 14:46, 18 September 2019 (UTC)

Here is a crazy idea: Forget all the arbitrary distictions between what you consider CS1 and CS2 templates. (You have already forgotten them for the most part, seeing as you didn't remember them at reversion time and after I asked thrice.) Let the only defining factor be the compilance of the output they generate with the style guides of CS1 and CS2. Then, list them in the table. Other than huge benefits of choice and consolidation, it has no drawbacks.

And by the way, if using {{citation}} instead of what you consider a "true CS1 template" 🙄 is something worrisome, then you must start getting seriously worried because I have been using this template in articles and I plan to continue doing so. It is easier to remember one template and one set of parameters instead of an arbitrary many. flowing dreams (talk page) 04:58, 19 September 2019 (UTC)

You know, I am not worried. In fact, I am entirely indifferent to which of cs1 or cs2 you use when editing en.wiki articles. You can use any citation style you want within the constraints imposed by WP:CITEVAR. Other editors will, no doubt, hold you to the requirements of WP:CITEVAR so that I need not worry about what you do.

Do not mistake my indifference to which of cs1 or cs2 you use in article space as agreement with your changes to the cs1 template documentation page; cs2 is not cs1.

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

@Trappist the monk: Oh, I don't mistake your indifference with your act of harassment. You supplied no reason with your reversion (because you have none) and are hard-pressed to diguse it as a mere dispute. I'm only disappointed, in that it is not a deliberate malicious act of harassment by a despicable person that I can condemn, or over a subject that even matters. But I'll be sure to write about it in my public log. flowing dreams (talk page) 16:55, 20 September 2019 (UTC)

meh

—Trappist the monk (talk) 21:40, 20 September 2019 (UTC)

@Flowing dreams: Your comments are uncalled for, and contrary to WP:Civility. ♦ J. Johnson (JJ) (talk) 23:38, 20 September 2019 (UTC)

I'm sure the writers of WP:Civility never inteded it to be used to harbor harassment and edit warring. flowing dreams (talk page) 04:26, 21 September 2019 (UTC)

Not really sure what the big fuss is about, but {{citation}} isn't a CS1 template, it's a CS2 template, and shouldn't be shoehorned into CS1 advice simply because there's a |mode=cs1. Likewise, CS1 templates aren't CS2 template simply because the |mode=cs2. Headbomb {t · c · p · b} 05:38, 21 September 2019 (UTC)

And again, Trappist the monk has already said in their reply to me above that don't object to such a mention in HELP:CS1, just so long as it is not in the table that is expressly for cs1 templates. This seems like a fair compromise to all parties involved. @Flowing dreams: your comments have been quite uncivil and full of accusations of bad faith, harassment, and the like. It would have been much more productive to work with other editors—ones more familiar with Wikipedia citation templates and their documentation—in order to come up with ways of doing this instead of insisting inclusion in the table of CS1 templates. My suggestion would be a sentence in the Help:Citation Style 1 § Style section, but I would defer to those editors who have spent more time thinking about these issues. Umimmak (talk) 06:46, 21 September 2019 (UTC)

@Umimmak: While I greatly appreciate you working towards peace and progress here, I must impress upon you how humiliating and hurtful all of this are for me. To wit, look at Headbomb's comment: To him, it is not a step required by the five pillars of Wikipedia or improving, but "a great fuss". And while he states that he does not care what the subject of the discussion is, he permits himself to judge me and parrot out the fallacious "CS1 templates aren't CS2". What did I ever do to you guys to deserve this degree of bad behavior? I don't need a compromise as much as I deserve working in the spirit of teamwork. But TTM's double-talk is not teamwork. TTM's reverting my well-meaning contribution in the same curt, non-collegial way that one reverts a sabateur, is not teamwork. (By the way, what's Wikipedia's word for a sabateur?)

And please refrain from sending me reply notifications. This discussion is dead to me. I've tolerated enough harassment and anti-newcomer bias already. Perhaps, you and I will meet again and our cooperation would be an example of collegial work. flowing dreams (talk page) 07:22, 21 September 2019 (UTC)

Those are gross mischaracterizations of my comments. I'll follow up on your talk page. Headbomb {t · c · p · b} 14:08, 21 September 2019 (UTC)

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

ISSN error

I have three issues of a paper journal, each of which carries a barcode and text reading "ISSN 977 0016639 051"; that ISSN is also found online, for example at [3].

However:

<ref name="Gibbons">{{cite journal |last1=Gibbons |first1=Sue |title=Percival Boyd |journal=Genealogists' Magazine |date=March 2005 |volume=28 |issue=5 |pages=187-195 |publisher=[[Society of Genealogists]] |issn=9770016639051}}</ref>

gives a template error^[1] and https://www.worldcat.org/issn/9770016639051 find no entry.

What's up? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 22 September 2019 (UTC)

References

^ Gibbons, Sue (March 2005). "Percival Boyd". Genealogists' Magazine. 28 (5). Society of Genealogists: 187–195. ISSN 9770016639051. {{cite journal}}: Check |issn= value (help)

@Pigsonthewing: According to the ISSN article, the 8-digit ISSN is sometimes re-encoded as a 13-digit barcode. The 8-digit ISSN for the Genealogists' Magazine is listed by Worldcat as 0016-6391, using seven digits from the 13-digit version plus a new check digit. -- John of Reading (talk) 12:32, 22 September 2019 (UTC)

(edit conflict)

New to me. See this document @ §6.31. According to that:

977 is the prefix

0016639 is the issn without check digit

05 is the variant

1 is the check-digit

Adding a check-digit to the 7-digit issn gives this which worldcat thinks is the same serial publication:

ISSN 0016-6391

I suspect that it having appeared in this example publication that we should expect to see these crop up in future so perhaps we should consider adding support for issn-13. Opinions?

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

Until these have actual widespread use, and resolve somewhere, the standard ISSN format should be enforced. Headbomb {t · c · p · b} 13:00, 22 September 2019 (UTC)

Thanks all; interesting. I am minded to agree with Headbomb that the 8-digit form should be enforced, but we could perhaps trap this alternative with a custom error message ("Did you mean..?"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:10, 22 September 2019 (UTC)

Assuming a correctly formed issn-13 then such an error message would have to present a properly formed issn-8. To do that we have to extract the seven-digit issn, calculate the appropriate checksum for display. If we are going to do all of that, use the new issn-8 to link into worldcat and no error message.

—Trappist the monk (talk) 13:49, 22 September 2019 (UTC)

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

Speaking of supplements, here's a challenge for everyone: I have a citable (because it is independently written) box in a chapter in a special supplement to a volume/issue in a journal. (Supplement available here. See "How do we know the world has warmed?" on p. S26.)

The preferred result would be on the lines of:

 Kennedy, et al., (2010) "How do we know the world has warmed?". In: "State of the Climate in 2009". Bulletin of the American Meteorological Society.  91(7):26 ....

Which I can almost do. Except that {cite journal} and {citation} ignore |chapter=, and {cite book} drops the issue number and misformats the page number. I have also tried doing a minimal {cite journal} for the box, and appending "In: {cite journal ....}}" for the the supplement, but the page number doesn't work.

So: any suggestions? ♦ J. Johnson (JJ) (talk) 22:35, 22 September 2019 (UTC)

Use |at= instead. --Izno (talk) 23:11, 22 September 2019 (UTC)

Perhaps this

{{cite journal|author=Author|title=Introduction: BoxTitle|department=Special Supplements|journal=Journal|issue=1 ''SupplementTitle''|p=S1}}

Author. "Introduction: BoxTitle". Special Supplements. Journal (1 SupplementTitle): S1. {{cite journal}}: |author= has generic name (help)

might work. 98.0.246.242 (talk) 02:06, 23 September 2019 (UTC)

Use |at= to finesse the page numbering, right? Yes, that looks good. And |deparatment=, of course, how could I have overlooked that??! Thanks to you both. ♦ J. Johnson (JJ) (talk) 20:52, 23 September 2019 (UTC)

Date in non-Gregorian calendar

According to WP:CS1, "Sources are at liberty to use other ways of expressing dates, such as "spring/summer" or a date in a religious calendar; editors should report the date as expressed by the source." (my emphasis) However in Muhammad_III_of_Granada#Primary_sources, I used "1247 AH" as the date (see "Ibn al-Khaṭīb (1347 AH)") and got a validation error Check date values in: |date=. How do I fix this? HaEr48 (talk) 13:30, 25 September 2019 (UTC)

Because they are general purpose templates, cs1|2 templates are not intended support all calendars. cs1|2 templates use the Gregorian calendar because Gregorian is the most commonly used calendar. There is no fix. Yours is a case where the citation will likely have to be written manually to avoid the error message.

—Trappist the monk (talk) 13:47, 25 September 2019 (UTC)

An admittedly cludgy suggestion would be to use |date=c. 1928, plus either |orig-year=original date 1347 AH or |quote=[Source pub. date] 1347 AH [+page# where this information is found]. 24.105.132.254 (talk) 14:09, 25 September 2019 (UTC)

This is actually a pretty reasonable workaround IMO. --Izno (talk) 16:09, 25 September 2019 (UTC)

Question about Title in Template:Cite episode

This template help page states, "title: Title of source. Can be wikilinked to an existing Wikipedia article or url may be used to add an external link, but not both. Displays in italics." It actually does not display in italics, as it should not because that would be the wrong format. Episode titles are properly formatted in quotes, never italics. It does display, in fact, in quotes so that needs clarification and I'm not sure if I am allowed to edit this or not. MagnoliaSouth ^(talk) 18:17, 26 September 2019 (UTC)

fixed.

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

Citing an entire issue of a journal

There are scientific journals that do not contain articles, but simply publish scientific data at regular intervals. One example is Minor Planet Circulars. How do I cite an entire issue, without specifying the title parameter (as there is no title to specify)? Specifically, I needed to cite a new observatory code listed on page 1 of issue 85415: https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf. Typing in

{{cite journal |journal=[[Minor Planet Circulars]] |issn=0736-6884 |date=17 November 2013 |issue=85415 |page=1 |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf |format=PDF}}

obviously produces a missing title error. I've worked around it by adding |title=New observatory codes, but this is wrong, as "New observatory codes" is merely a section title, not an article title. Perhaps, there is some way to use {{citation}} template without specifying the title parameter? — UnladenSwallow (talk) 01:53, 24 September 2019 (UTC)

You could try |title=none. But that won't work for this example because then there would be nothing for the url to link to. If you had a doi instead of a url it would work. —David Eppstein (talk) 02:02, 24 September 2019 (UTC)

Given the examples demonstrated by Headbomb and me (keep in mind, Minor Planet Circulars is widely referenced on Wikipedia, and all those references are presently malformed in one way or another), I think we should consider extending {{citation}}'s behavior. Namely, if |title=none, but |issue= has a value, then the issue should get linked to the provided URL. The semantics being that the URL points to an HTML page or a file containing the entire issue of the journal in question. For example, typing the code above would produce the following:

Minor Planet Circulars (85415 (PDF)): 1. 17 November 2013. ISSN 0736-6884.

If |issue= has no value, then {{citation}} should throw an error, as it does now:

|url= missing title or issue (help)

The proposed change is small, easy to implement, and does not break anything. — UnladenSwallow (talk) 07:21, 24 September 2019 (UTC)

If Minor Planet Circulars is an oft-used source, consider making a separate template for it. Consider perhaps, {{London Gazette}} as a possible model:

{{London Gazette |issue=33000 |date=9 December 1924 |page=8957}}

"No. 33000". The London Gazette. 9 December 1924. p. 8957.

—Trappist the monk (talk) 10:42, 24 September 2019 (UTC)

{{London Gazette}} – which is a misnomer, as the template also supports Belfast Gazette and Edinburgh Gazette – is a "macro" template that saves time by building the URL automatically from |city=, |issue=, and |page=. It is certainly possible and perhaps even useful to implement a similar template for MPEC, MPC, MPS, and MPO, as they all have standard uniform URLs. But there still has to be a general solution to the problem of "article-less" journals.

Please note that I'm not proposing to trigger the "linked issue" behavior with a missing/empty |title=. A missing/empty |title= will still produce a missing title error, so the new editors will still be taught to always include the title. The behavior will only be triggered by explicitly setting |title=none, signalling: "I know what I'm doing. I'm doing this because I'm citing an "article-less" journal, and I want the issue linked to the URL."

We might also switch {{London Gazette}} to the new system, as this looks more consistent with other citations:

The London Gazette (33000): 8957. 9 December 1924.

(The current display style may be misinterpreted as an article titled "No. 33000" by The London Gazette.) — UnladenSwallow (talk) 20:58, 24 September 2019 (UTC)

I would suggest the poorly documented {{cite techreport}}:

{{cite techreport|url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf|title=Minor Planet Circulars|number=85415|institution=[[Minor Planet Center]]|date=17 November 2013|p=1|issn= 0736-6884}}

Minor Planet Circulars (PDF) (Technical report). Minor Planet Center. 17 November 2013. p. 1. ISSN 0736-6884. 85415.

24.105.132.254 (talk) 13:42, 25 September 2019 (UTC)

I should add, |type=none will remove "(Technical report)" from the display. But imo, this would not be helpful to the average Wikipedia reader re:precision. The circulars, are after all, technical reports. 24.105.132.254 (talk) 16:41, 25 September 2019 (UTC)

Thank you for your suggestion. However, there are two problems with {{cite techreport}}:

Minor Planet Circulars must link to Minor Planet Center#Publications, not to a PDF of an issue.
The order of elements / formatting looks completely different from {{cite journal}}, and Minor Planet Center#Publications describes Minor Planet Circulars as "a scientific journal".

I still think the best solution is to extend {{cite journal}} as I have proposed, which will produce a nice and clean result:

{{cite journal |journal=[[Minor Planet Circulars]] |issn=0736-6884 |date=17 November 2013 |issue=85415 |title=none |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf |page=1}}

→

Minor Planet Circulars (85415): 1. 17 November 2013. ISSN 0736-6884.

— UnladenSwallow (talk) 10:52, 26 September 2019 (UTC)

I don't think that MPC should be considered a scientific journal except under the most expansive definition. It seems to me to be more akin to an ephemeris, which should be considered a technical report, a series continuously/periodically updated. So I believe the citation should source the data series as a whole, and keeping in mind the comments that Trappist made below, should focus on the date and page elements as the distinguishing characteristics of the particular citation. 72.43.99.138 (talk) 14:33, 26 September 2019 (UTC)

If I look at the pdf that you have linked, it appears to me that 85415 is a page number; not an issue number. The next page in that pdf is M.P.C. 85416 and so on to the end page which is M.P.C. 85916. Every one of the 502 pages in the pdf bears the date 2013 Nov 17 which is reflected in the pdf's file name (MPC_20131117.pdf). The circulars are published (issued) on a date but the pagination is continuous (it does not restart with each new issuance – see the next publication (2013 Dec 17) which begins at M.P.C. 85917).

If we take the MPC number as pagination, and the circulars as the individually titled sections, and were we citing a Kitt Peak observation found on page 85535, we might write:

{{citation |mode=cs1 |title=695 Kitt Peak |periodical=[[Minor Planet Circulars]] |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf#page=121 |page=M.P.C. 85535 |nopp=yes |date=2013-11-17}}

"695 Kitt Peak" (PDF). Minor Planet Circulars. M.P.C. 85535. 2013-11-17. {{citation}}: Unknown parameter |nopp= ignored (|no-pp= suggested) (help)

I used{{citation}} and |periodical= to get away from the journal style volume / issue / page format because, in this case, there is no volume nor issue; just page numbers; |nopp=yes hides the pagination prefix.

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

My bad. This is, indeed, a continuous page number. And as 72.43.99.138 explained to me above, the term "technical report" encompasses periodicals, something I did not know. My apologies to all for insisting on the wrong solution. I guess the best one, after all, was proposed by 24.105.132.254:

{{cite techreport |institution=[[Minor Planet Center]] |title=Minor Planet Circulars |ISSN=0736-6884 |date=17 November 2013 |page=85535 |url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf#page=121 |type=none}}

Minor Planet Circulars (PDF). Minor Planet Center. 17 November 2013. p. 85535. ISSN 0736-6884.

or, perhaps, a slight modification using |chapter= as a stand in for a batch of circulars, with its title taken from the page header:

{{cite techreport |institution=[[Minor Planet Center]] |title=[[Minor Planet Circulars]] |ISSN=0736-6884 |date=17 November 2013 |chapter=M.P.C. 2013 NOV. 17 |page=85535 |chapter-url=https://minorplanetcenter.net/iau/ECS/MPCArchive/2013/MPC_20131117.pdf#page=121 |type=none}}

"M.P.C. 2013 NOV. 17" (PDF). Minor Planet Circulars. Minor Planet Center. 17 November 2013. p. 85535. ISSN 0736-6884.

Thank you for your help! — UnladenSwallow (talk) 04:22, 27 September 2019 (UTC)

Differing headlines between Print and Internet articles

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

Cite the one you read. If you read both, cite both separately. You might consider leaving a hidden note that titles differ. --Izno (talk) 16:52, 1 September 2019 (UTC)

Invariably when this comes up (or at least when I notice), it's because I've started from the print, or microfilmed subscription copy, and then used that to to discover the article is available online, with a (very) different headline, while looking for a URL. Probably best include the URL ... But if I use the URL, I know that sooner or later, someone will "fix" the reference. Yeah, hidden text might be the solution - something like this? Nfitz (talk) 21:44, 1 September 2019 (UTC)

That's what I should have suggested originally, yes. :) --Izno (talk) 22:05, 1 September 2019 (UTC)

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

isbn2

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

Please provide an example where this parameter would be useful. Per WP:SAYWHEREYOUREADIT, editors should be citing the single source that they are using to back up any claim, and a single source has only one ISBN (the 10-digit and 13-digit ISBNs are equivalent for a given book, so there is no need for both).

If a second source with a different ISBN is useful for some reason, use a second citation template to cite the second source, or place the additional ISBN outside of the citation template. – Jonesey95 (talk) 16:39, 3 September 2019 (UTC)

Some books have more than one ISBN. All the best: Rich Farmbrough, 12:03, 28 September 2019 (UTC).

Citation needed. – Jonesey95 (talk) 13:50, 28 September 2019 (UTC)

Assuming they’re not just talking about ISBN-13 vs ISBN-10, some books’ edition notices might have multiple ISBNs displayed, but it will be because they list, say, the ebook and hardback ISBNs, or have different ISBNs for a boxed set and an individual volume. None of these warrant multiple inclusions in a works cited, in my view. Umimmak (talk) 14:00, 28 September 2019 (UTC)

Post-update updates needed

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

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

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

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

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

I have asked for a bit of clarification with regard to the missing periodical errors reporting.

—Trappist the monk (talk) 21:54, 6 September 2019 (UTC)

Sounds good. While waiting, I have edited above to clarify that I believe the close means that even the hidden "missing periodical" error messages should be eliminated in the modules. – Jonesey95 (talk) 22:02, 6 September 2019 (UTC)

Trappist says everything required by the close is completed. The closing message also said "The other updates shall stand", so I think we should also monitor the progress plan for finalizing this change.

Monkbot task 16 - to finish replacing |dead-url=
Confirm that documentation is up to date to the current implementation
Tools are updated to conform to new documentation
Task-force to deal with any other problems/error categories that came out of this

The following were in scope for this change, but are now to be treated as discussions before further updates.

Re-instate error message for |dead-url= - is that needed and welcome?
What is the intended use of |website=, can documentation be updated and agreed upon?
How important was the italics RfC and what options are there now to reach that goal?
Anything else that was "reverted" and should be rescheduled for inclusion or discussion?

-- JAGulin (talk) 14:21, 8 September 2019 (UTC)

Unhide missing periodical error messages? – Levivich 14:33, 8 September 2019 (UTC)

Bumping this discussion, hopefully, since I feel the time has come. Category:CS1 errors: deprecated parameters is currently down to 48,060 pages as of typing, which is a bit over 0.8% of all Wikipedia articles (including disambiguation pages). (Live values can be found here: 0/6,910,663 = 0%.) Therefore, I request that the deadurl/dead-url errors become fully visible again. I find it useful for clean-up purposes. -BRAINULATOR9 (TALK) 14:37, 28 September 2019 (UTC)

We have to wait for Monkbot to finish going through the deprecated parameters category, after which further manual intervention will be necessary to clean up instances that the bot was unable to handle, along with instances in Category:CS1 errors: invalid parameter value. In the meantime, instructions for displaying the error messages for yourself, when you are logged in, are available at Category:CS1 errors: deprecated parameters. – Jonesey95 (talk) 16:57, 28 September 2019 (UTC)

If you would like to display them yourself, you will actually need to do something not presently documented at the category page in your CSS:

.mw-parser-output span.cs1-hidden-error {display: inline;} /* display Citation Style 1 hidden errors */

That's because the template which tells people how to configure their CSS does not include how to configure hidden errors, which were not expected to be used again (and so I had removed when we went to TemplateStyles).... --Izno (talk) 17:12, 28 September 2019 (UTC)

That aside, I've now made the change in the module sandbox, so the next release should make them visible again. --Izno (talk) 17:16, 28 September 2019 (UTC)

OK, thank you all! -BRAINULATOR9 (TALK) 19:47, 28 September 2019 (UTC)

Casing error

When url-status=dead, it correctly produces:

... Cambridge University Press, pp. 34–42, archived from the original (PDF) on 2009-09-06

When url-status=unfit, it incorrectly produces:

... Cambridge University Press, pp. 34–42, Archived from the original on 2009-09-06

The case is not agreeing with the comma before it. The second one should change to ", a", to match the first (unless there is a reason for it to be capitalized, in which case it should change to ". A"). (I'm not expert in citing, here or elsewhere.) - A876 (talk) 04:31, 29 September 2019 (UTC)

I've tweaked the sandbox:

Citation comparison
Wikitext	`{{citation\|archive-date=2019-09-29\|archive-url=//archive.org\|title=Title\|url-status=unfit\|url=//example.com}}`
Live	Title, archived from the original on 2019-09-29`{{citation}}`: CS1 maint: unfit URL (link)
Sandbox	Title, archived from the original on 2019-09-29`{{citation}}`: CS1 maint: unfit URL (link)

Citation comparison
Wikitext	`{{citation\|archive-date=2019-09-29\|archive-url=//archive.org\|title=Title\|url-status=dead\|url=//example.com}}`
Live	Title, archived from the original on 2019-09-29
Sandbox	Title, archived from the original on 2019-09-29

Citation comparison
Wikitext	`{{citation\|archive-date=2019-09-29\|archive-url=//archive.org\|title=Title\|url-status=live\|url=//example.com}}`
Live	Title, archived from the original on 2019-09-29
Sandbox	Title, archived from the original on 2019-09-29

Cite book comparison
Wikitext	`{{cite book\|archive-date=2019-09-29\|archive-url=//archive.org\|title=Title\|url-status=unfit\|url=//example.com}}`
Live	Title. Archived from the original on 2019-09-29.`{{cite book}}`: CS1 maint: unfit URL (link)
Sandbox	Title. Archived from the original on 2019-09-29.`{{cite book}}`: CS1 maint: unfit URL (link)

—Trappist the monk (talk) 08:43, 29 September 2019 (UTC)

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

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

Module:Citation/CS1:

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

Module:Citation/CS1/Configuration:

update bibcode url; discussion
update two error category names and many maint category names to make capitalization consistent; discussion
remove unsupported |distributor=; discussion
periodical templates missing periodical parameter error messaging;
add script parameter error detection & messaging;
add |script-periodical and |trans-periodical parameter support;
deprecate and replace |dead-url= and |deadurl=;
add |map-url-access=;
add long-missing zbl maint cat; discussion
|doi-broken= requires |doi= error messaging;

Module:Citation/CS1/Whitelist:

added missing |contribution-url-access=; discussion
add script parameters for all |chapter= aliases; discussion
add |script-periodical and |trans-periodical parameter support;
deprecate |lay-summary= and |laysummary=; discussion
deprecate |dead-url= and |deadurl=;
add |map-url-access=;
add support for {{cite ssrn}};

Module:Citation/CS1/Date validation:

fix date format bug; discussion

Module:Citation/CS1/Identifiers:

zbl temporary-id support; discussion
access icon parameter-value bug fixed;
|doi=10.5555... error detection; discussion
tweak bibcode validation; discussion
refine |doi-inactive= categorization; discussion

Module:Citation/CS1/Utilities:

strip apostrophe markup() from ~/COinS; discussion
tweak strip apostrophe markup() to return text and a flag;

Module:Citation/CS1/COinS:

move strip apostrophe markup() to ~/Utilities;
add support for cite ssrn;

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

Also Inactive DOIs are now sorted into months of the year categories. --Izno (talk) 14:23, 27 August 2019 (UTC)

No support for Help talk:Citation Style 1/Archive 58#Check for final character in several regular fields? I thought this was done/sandboxed? Headbomb {t · c · p · b} 14:28, 27 August 2019 (UTC)

Yes, both of these too. Added to the list.

—Trappist the monk (talk) 17:03, 27 August 2019 (UTC)

@Trappist the monk: shouldn't the |agency= one in here also throw an error? Headbomb {t · c · p · b} 07:22, 28 August 2019 (UTC)

I'm confused. |agency= isn't used in the templates at the link you provided.

—Trappist the monk (talk) 10:05, 28 August 2019 (UTC)

@Trappist the monk: sorry, used the wrong link apparently. Fixed now. Headbomb {t · c · p · b} 15:30, 28 August 2019 (UTC)

I guess I'm still confused. This:

{{cite book/new |title=Title |agency=Agency,}} → Title. {{cite book}}: Unknown parameter |agency= ignored (help)CS1 maint: extra punctuation (link)

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

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

My bad, I read things too fast and had a brain fart, I thought the URL error message was the trailing garbage error message and that threw me off. Headbomb {t · c · p · b} 15:58, 28 August 2019 (UTC)

@Trappist the monk: Even with the heads up, this change caused some problems. Please assist in the questions below. JAGulin (talk) 13:53, 3 September 2019 (UTC)

The changes as a whole right now are being discussed at ANI, I would also address the comments there Monk. - Knowledgekid87 (talk) 14:10, 3 September 2019 (UTC)

Cite web error

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

(edit conflict) Came here to say the same thing as I noticed a large number of new errors of this type in references I wrote a while ago. Requiring |website= is dramatically unexpected behaviour and different to how I've been using the template for over 5 years. I often use publisher instead, but even if both are omitted, it should not be an error as the reference is still sufficient without either parameter as long as it includes a URL, a title and enough extra information to specify the reference if the URL breaks (e.g. author). This error type should be removed quite urgently due to the number of articles it affects. — Bilorv (talk) 12:11, 3 September 2019 (UTC)

(edit conflict) I've just noticed this error message "Cite web requires |website=" and again as Rfassbind says the citation in question has a |publisher= parameter in it. It seems a bit superfluous to me for the citation to have to read

{{cite web |url=http://foo.com/the_greatest_thing_ever_told |title=Whatever |website=foo.com |publisher=The Foo Corporation}}

producing
"Whatever". foo.com. The Foo Corporation. to stop the error message appearing when the publisher parameter is supplying the identification about the sources of the information. Can |publisher= be added as an acceptable alternative to the periodical parameters already listed? Nthep (talk) 13:20, 3 September 2019 (UTC)

WTF did {{Cite web}} without |website= starting spitting ugly red error messages everywhere? Especially when there's already a perfectly appropriate |publisher= in there. Andy Dingley (talk) 11:10, 3 September 2019 (UTC)

Also the documentation for {{Cite web}} doesn't mention that this param is now mandatory, and that same documentation is itself littered with these inlined red error messages. Andy Dingley (talk) 11:15, 3 September 2019 (UTC)

This is new functionality as of the update listed above about which these new sections were started. The documentation, I assume, will be updated shortly. Help:CS1 errors I know has already been updated. We knew it would affect many articles which have had more-or-less incomplete citations. Please review the documentation pointed to in the above change notes. --Izno (talk) 12:22, 3 September 2019 (UTC)

It's not an incomplete citation, Publisher is often the more fitting parameter, and in many cases neither Website nor Publisher are needed. VisualEditor's automatic citation tool uses Cite Web by default, I don't expect people to know how to open syntax mode and change Cite Web to Cite News. This requirement is not needed and it's very confusing, could you consider turning this error message off? – Thjarkur (talk) 12:43, 3 September 2019 (UTC)

Requiring website= is crazy, as the web site can be determined by the URL in most cases. Just leave it as optional. I will say this is a bungled change without care for the consequences. Graeme Bartlett (talk) 12:54, 3 September 2019 (UTC)

I agree, why was changing "url=" to "website=" a good idea again? Millions of pages are now disrupted for this minor crazy change. - Knowledgekid87 (talk) 13:02, 3 September 2019 (UTC)

Also agree, this is an incredibly poor thought-out change. Giant Snowman 13:09, 3 September 2019 (UTC)

Note that website is not a replacement for url, it's an additional parameter. I agree that it should not be mandatory, or at least it should accept |publisher= as well as the other options. JAGulin (talk) 13:53, 3 September 2019 (UTC)

I agree that {{cite web}} shouldn't require |website/work/...=. Headbomb {t · c · p · b} 14:35, 3 September 2019 (UTC)

Is there a way to make "website=" and "newspaper=" non mandatory? - Knowledgekid87 (talk) 14:43, 3 September 2019 (UTC)

I am sure there is, the question is whether it should be. I think there is a case for having a "medium" and a "publisher" parameter as sometimes they are not the same thing, instead of having a "website" parameter that commingles two not-always-identical things. Jo-Jo Eumerus (talk, contributions) 15:02, 3 September 2019 (UTC)

Well I want to point out that news doesn't only come from a "newspaper" anymore. - Knowledgekid87 (talk) 15:06, 3 September 2019 (UTC)

From this comment, it appears that Trappist sees this change as part of the advertised change periodical templates missing periodical parameter error messaging. However, the linked discussion shows {{cite journal}}, {{cite news}} and {{cite magazine}}. I seems that adding this error message to {{cite web}} has not been discussed, and in view of the apparent lack of consensus, should be reverted. Kanguole 16:16, 3 September 2019 (UTC)

Yes, that is what I think. That I omitted {{cite web}} from the discussion was merely an oversight on my part. The code that emits the missing periodical error message is the same for all of the periodical templates / parameters.

—Trappist the monk (talk) 16:31, 3 September 2019 (UTC)

It seems that few share your view that web sites should be treated like periodicals. Kanguole 16:51, 3 September 2019 (UTC)

"Works", in citation-speak, are the cited sources. They are abstractions (of the underlying material). For purposes of citing, the underlying material, be it a website, book, periodical, map, encyclopedia, etc. is not relevant. It follows they are treated the same in a consistent, well-defined citation platform. We don't care what the source is, as long as it can be identified and found in the most efficient manner. Traditionally, this meant that citations were designed around the way sources were classified and indexed. First, by name/author/date, then by classification/marketing number, more recently by digital indexing. Such classification was always based on complete units (works), as they would be expected to be searched for by the person looking for them (citations of fragments being a special case). In the world wide web, the "unit" of search, or work, is a so-called "site". The smallest web item, say a few characters text, cannot exist without a hosting site. Any citation that does not include this simple fact, which happens to be the pathway to verification, cannot really be a citation. It is something else. 69.193.220.107 (talk) 20:24, 6 September 2019 (UTC)

69.193.220.107, I grant your understanding of citations generally, especially wrt to physical media, but it's very unclear from what you've written whether you understand the difference between a website, a web page, a hosting service, a domain, and a URI, and which one corresponds to "work" and how well digital media correspond generally when considering document retrieval. The fact that you say "In the world wide web, the 'unit' of search, or work, is a so-called 'site' ", makes me think you don't understand it well, or maybe you made a slip of the tongue. Your lead-off claim about "website, book, periodical," being analogous based on that faulty understanding is therefore mistaken. Mathglot (talk) 20:47, 6 September 2019 (UTC)

Actually there are many different technical terms for periodical. As many, or more, as there are for website. And that is not the point. The point is, citations are there solely for verification. Which means, they must accommodate solely the verifier. In a non-expert citation system like Wikipedia's, which if I am not mistaken is the first large-scale such system of its kind anytime anywhere, special considerations have to be applied. Including, paring down technicalities as much as it is possible without compromising validity. In writing a citation, I cannot assume that the reader would know the nuances or even the main building blocks of a network directory system or its underlying software infrastructure. If popular libraries were organized under such a view, nobody would be able to use them unless they knew the intricacies of the Dewey Decimal. We have to stick with what is the common, popularly known laymen's terms. Which doesn't mean that they will be incorrect. In broad terms, and as far as the experience of the vast majority of users is concerned, it is safe to assume that the meaning of "site" is unambiguous: it is where one goes to find stuff on the web. And that is it. Walk backwards from that, from where a user starts. You might arrive to the conclusion that not for any reason can the website name be left out of a citation. 98.0.246.242 (talk) 23:32, 6 September 2019 (UTC)

You might arrive at a different conclusion, after watching ten different users place five different things in the website param for the same source. Noting that url is unique and unambiguous and rarely misused, and "website" is none of the above, might lead you to the conclusion that making "url" required for a web page, and "website" merely informative and optional, was another way to go. Mathglot (talk) 00:09, 7 September 2019 (UTC)

But this is more because of the confusing documentation. The reason for many of these updates is because of the misuse of the parameters. This misuse is to an extent the result of below-par documentation. It is the responsibility of those who produce these changes to document them properly. I agree that citation writers have every right to expect clear-cut and plain documentation of everything the system does. However this is separate from the design rationale. 98.0.246.242 (talk) 01:27, 7 September 2019 (UTC)

Everyone complains about the documentation yet, when asked to help improve it, those same editors seem to always find something else to do ... I have admitted for years that I suck at documentation because my writing style is too technical, too strange, too wordy, too something, to make user documentation that I have written accessible to the general editing population. If you can see how our documentation can be made better, please help us fix it.

—Trappist the monk (talk) 03:02, 7 September 2019 (UTC)

"watching ten different users place five different things in the website param" - This issue was addressed in the citation tool, at my suggestion, by changing the label from "website" to "website name". Maybe the same fix could be applied to the parameter itself? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:02, 15 September 2019 (UTC)

'This has gone far enough. It's not a documentation issue but an issue of overreaching micromanagement by the maintainers of the citation template group who have an incorrect understanding of policy. I feel that the changes (to flag "incorrectly populated" parameters) have been put through unilaterally without due concensus are detrimental to the project. As highlighted already by fellow editors, the numerous red cs1-errors tags that have been appearing since the change do not always correctly identify parameters that are problematic. Please note that few WP articles about websites have italicised titles, so it is entirely jumping the gun to decide that all websites ought to be italicised within the reference section, as no consensus has been so reached locally nor according to policy and guidelines. The way I see around the problem would be a relatively easy but fastidious fix. To ensure that the titles of sources within the reference sections display according to the names in article space, I would see little alternative but to replace the {{cite web}}, {{cite news}} with the {{citation}} template. This would then allow the unrestricted (and unflagged) use of |newspaper= and their aliases, |publisher= when appropriate. All I would need to do is to incorporate a suitable regex in my script, and those errant error messages will go away. However, I hope that we can come to a sensible arrangement with which all editors can be satisfied. -- Ohc ^¡digame! 21:07, 8 September 2019 (UTC)

url-status

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

What are the available options? Getting errors and not sure how to format properly. There should be a mechanism to automatically rename parameter labels of citations in production when such labels change. As a utility module perhaps. 108.182.15.109 (talk) 12:15, 3 September 2019 (UTC)

|dead-url= was deprecated in favor of |url-status=, which accepts 'dead', 'live', 'unfit', 'usurped', and 'bot: unknown' (without quotation marks of course), so the only parameters which will have changed are the first two. As for renaming, there is a bot task approved for that work to start now. --Izno (talk) 12:18, 3 September 2019 (UTC)

Wouldn't it have been better if the bot was left to run for a few weeks before this mandatory change was sprung on us without warning. Now we have surprised editors, surprised readers, links to unhelpful error messages with no useful clue how to fix it and even the template documentation has not been updated yet. A complete mess on practically every WP article that could have been easily avoided. Stepho talk 12:28, 3 September 2019 (UTC)

In the current template documentation, "url-status=live" is mentioned as the default value. This is not currently the case. The current default is "url-status=dead". 108.182.15.109 (talk) 12:31, 3 September 2019 (UTC)

Can confirm. Leaving it empty causes the citation to act as if the url is dead. PanagiotisZois (talk) 12:47, 3 September 2019 (UTC)

Yes please turn off these warnings until the bot has updated the parameters. – Thjarkur (talk) 12:36, 3 September 2019 (UTC)

I think it would make sense to keep the warnings, but only in preview while both parameters are supported. That would help prevent new |dead-url= tags from being added while minimizing the confusion of editors. --AntiCompositeNumber (talk) 12:49, 3 September 2019 (UTC)

I'm not sure it can be visible only in preview, is that the difference of a "warning" and an "error"? They should make sure to bot quickly and reduce this to a warning. JAGulin (talk) 13:54, 3 September 2019 (UTC)

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

@Trappist the monk:Perhaps it might be a good idea to have the citation templates throw a special error message akin to "Parameter is being replaced, please change to Foo as appropriate" until the bot pass is done then switch back to the normal red error? Jo-Jo Eumerus (talk, contributions) 13:55, 3 September 2019 (UTC)

That's what the help link is for with a deprecated parameter. (An unknown parameter is a different message.) --Izno (talk) 14:08, 3 September 2019 (UTC)

The normal deprecated parameter text does not make it clear enough that there is a mass replacement effort underway and is probably too visible for this specific situation. Jo-Jo Eumerus (talk, contributions) 14:27, 3 September 2019 (UTC)

The changes in the module are proper. It is their implementation that is lacking. As it was suggested at ANI, there should have been a parallel implementation of aliases, with sufficient warnings about the impending changes. 108.182.15.109 (talk) 14:03, 3 September 2019 (UTC)

They both work at present. Here: "Title". Website. {{cite web}}: Check |archiveurl= value (help); Unknown parameter |deadurl= ignored (|url-status= suggested) (help). --Izno (talk) 14:06, 3 September 2019 (UTC)

In general, deprecated parameters should not emit red error messages. They should populate maintenance categories until they are brought down to reasonable levels, and then support removed. Then they can emit errors. Headbomb {t · c · p · b} 14:38, 3 September 2019 (UTC)

Echoing some of the other comments here regarding the rollout of this change, as well as the change itself. Why was it necessary to deprecate deadurl for this new param? And why was such a major change made, apparently, almost unilaterally? It seems to offer no obvious benefits over deadurl, and the rollout has caused an incredible amount of chaos across the project. JimmyBlackwing (talk) 21:03, 3 September 2019 (UTC)

Why has "deadurl=yes" been changed to "url-status=dead"? The latter is harder to remember, needs a hyphen, and there are more letters to type. What is the point of the change? SarahSV ^(talk) 00:03, 5 September 2019 (UTC)

cs1|2 has a bunch of parameters intended to hold urls. These all end in -url:

|dead-url= does not hold a url but, because it looks like it should, editors do use it to hold the dead url. |url-status= was the best name we could come up with that didn't end in -url and still conveyed the meaning that we were looking for.

—Trappist the monk (talk) 00:30, 5 September 2019 (UTC)

SV, I fully agree with this change. The new one is easier to read and its meaning is clearer. Any change that makes the cite templates easier to use and understand (as this one does) has my full support. The hyphen is an advantage (good for clarity), not a drawback. (OTOH, I disagree strongly with some of the other changes, but that's a matter for discussion elsewhere.) --NSH001 (talk) 00:48, 5 September 2019 (UTC)

Okay, that makes sense. Trappist and NSH001, thanks for explaining. Just one other question. Would it not be easier to remember "urldead?=yes/no". I was thinking the same recently about "etal?=yes/no", rather than "display-authors=etal". There is so much to remember with these templates, and a lot of it isn't in the toolbar. An extra few characters may not seem worthy of complaint, but when you spend a lot of time adding these templates, you long for simplicity, things that are easy to remember, and as few characters as possible to type. SarahSV ^(talk) 01:13, 5 September 2019 (UTC)

I suspect that we considered |url-dead= and rejected it because it is awkward in an English-grammar-sort-of-way. |etal= doesn't work because, besides authors, there are also contributors, editors, interviewers, and translators.

—Trappist the monk (talk) 01:26, 5 September 2019 (UTC)

The other valid values for |url-status= are "unfit" and "usurped", which would not make sense syntactically with a parameter name that included the word "dead", including the old |dead-url= parameter. As for the hyphen, CS1 was standardized long ago on hyphenated parameters when the parameter name contains more than one word. – Jonesey95 (talk) 02:42, 5 September 2019 (UTC)

Please change website equals back to url

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

@Knowledgekid87: You are mistaken. |url= remains entirely undeprecated. --Izno (talk) 13:20, 3 September 2019 (UTC)

Why the error message then saying "website=" is needed when a url is already provided for cite web? - Knowledgekid87 (talk) 13:21, 3 September 2019 (UTC)

|website= is a periodical parameter much like |journal= is a periodical parameter. It names the website because the website name is hidden in |url=.

—Trappist the monk (talk) 13:24, 3 September 2019 (UTC)

@Knowledgekid87: See this example for what |website= actually does: {{cite web|url=https://www.example.com/|website=ExampleWebsite |title=Webpage}} produces "Webpage". ExampleWebsite. --Izno (talk) 13:25, 3 September 2019 (UTC)

@Izno: I fixed your example to stop further misunderstanding. Another example: "Webpage". ExampleWebsite. PublisherName. -- JAGulin (talk) 14:13, 3 September 2019 (UTC)

"Website=" should not be mandatory then. - Knowledgekid87 (talk) 14:32, 3 September 2019 (UTC)

New error messages as of 2 September 2019

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

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

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

Rfassbind, see #update to the cs1|2 module suite after 2 September 2019 above. The changes were made first, documentation is in the process of being updated, and bots are being written and modified to support the changes. As someone who previously didn't watch this page, they did catch me by surprise (but I guess that's what the big red warnings are for). --AntiCompositeNumber (talk) 12:44, 3 September 2019 (UTC)

Also affects {{cite news}} - error message is "Lua error in Module:Citation/CS1 at line 802: Argument map not defined for this variable." This is an incredibly poor implementation, given literally thousands of articles will be affected. If a bot is going to 'fix' them then when and how? I don't want my watchlist clogged up with 5,000 bot changes... Giant Snowman 13:08, 3 September 2019 (UTC)

It appears that this whole mess was made without first thinking of the effects done. - Knowledgekid87 (talk) 13:10, 3 September 2019 (UTC)

Can someone restore the old version until problems are resolved? Dentren | ^Talk 13:13, 3 September 2019 (UTC)

@Trappist the monk: Please revert your change until consensus can be established and/or there is a fix to this mess. - Knowledgekid87 (talk) 13:18, 3 September 2019 (UTC)

@GiantSnowman: That particular error is likely because of Ivanvector's revert on only one of the 7 module pages, which Ttm has now undone. --Izno (talk) 13:22, 3 September 2019 (UTC)

It's at ANI, and the original lack of discussion is paramount. ——SerialNumber54129 13:23, 3 September 2019 (UTC)

Discussion to undo all of the changes

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

"mode = CS1" raises warning

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

In cs1|2 all parameter names and all special keyword values are supposed to be lowercase. The change that enforced lowercase happened because a non-lowercase keyword caused Lua script errors (this discussion though the script error no longer shows.

Yeah, subcats might be nice but they are most times not required yet must still be maintained if they exist. It is possible to detect namespace so for pages in the Template: namespace it might be possible to add a sortkey to the category link so templates would be grouped together. I think that I remember reading that there is a standard Greek-letter sortkey specifically chosen for templates; don't remember where I read that.

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

Usually you go with a lowercase Greek letter. β → Book:, τ → Template:, ω → Wikipedia:, etc... Headbomb {t · c · p · b} 00:33, 5 September 2019 (UTC)

@Headbomb: Do you have a link for future reference? WP:SORTKEY seems to be the place to have it, but it doesn't mention tau currently. Curiously the wp:tau redirects to the same place and I found that this edit removed the tao with reference to WP:CAT#T. I've suggested to reinstate it. @Trappist the monk: As long as the category is consistent, you can choose any way to sort. *τ {{PAGENAME}} may be the sortorder I suggest for templates, in cases like this when I want to gather them in the beginning of the list. All of this is in vain if no templates show up in the category, but I would think that at least the doc page should be listed. JAGulin (talk) 16:28, 5 September 2019 (UTC)

There's no real standardized thing, but you can check Category:All WikiProject Women in Red_pages for an example. Headbomb {t · c · p · b} 18:54, 5 September 2019 (UTC)

@Headbomb:, @Jagulin:, @Trappist the monk:: {{Namespace Greek}}. All the best: Rich Farmbrough, 11:58, 28 September 2019 (UTC).

Here is a petscan query that lists all templates in CS1 error categories. It should be perused with the following caveats: (1) there are strong objections to the "missing periodical" errors that are currently being tracked, so it may be unwise to "fix" those errors before there is further discussion; and (2) some template pages, such as Template:Cite Memoria Chilena, should not be "fixed" just because the template page itself has errors. There have been about 40 or 50 semi-permanent residents on that page for a few years. – Jonesey95 (talk) 14:12, 4 September 2019 (UTC)

@Jonesey95: Great, your query is a good way to filter. I was able to modify it to the category I wanted, but as I expected it found no templates.

@Trappist the monk: Thanks for confirming that this was an intentional change. Specifically the Limited petscan also confirms that there are no Templates in "CS1 errors: invalid parameter value". It specifically mentions filtering some namespace out, but Template is not listed among them. Could you check for it?

If it doesn't interfere with anything else, it's fine to put the templates in the same category. May I suggest using greek tau to get the templates gathered on top? If there's a better choice, you can change later.

I think that the Template:GRIN should show up, but if not, the Template:GRIN/doc#Samples also should. --JAGulin (talk) 17:45, 4 September 2019 (UTC)

Changes to templates and modules can take days, sometimes months, to affect Category membership of pages that transclude those templates, so you may have to resort to an "insource" search of pages to find what you are looking for. This search currently yields 30 pages for me, for example, but I'm going to tidy them up anon. – Jonesey95 (talk) 17:56, 4 September 2019 (UTC)

Again you show that the simple tricks are also the most effective. Thanks for cleaning those up, it effectively reduced the warnings in "my category". That said, I think it would be useful to have the templates in the "CS1 errors: invalid parameter value" category, so if it wasn't due to lag it should be fixed. Over and out, JAGulin (talk) 19:59, 4 September 2019 (UTC)

Any Template-space pages that I did not catch and fix today will eventually appear in the category if the Template page itself contains an error. Sometimes, templates cause errors only when they are used; those instances will need to be caught by examining pages in the error category.

As of this time stamp, there are 338 pages in Category:CS1 errors: invalid parameter value. Most of them are due to |deadurl=No/Yes (change to |url-status=live/dead, respectively) and to |nopp=Y (change "Y" to "y"). – Jonesey95 (talk) 21:04, 4 September 2019 (UTC)

Cite ssrn, where it is?

The change log says 'add support for {{cite ssrn}}', but no such template exist. This needs to be created. Headbomb {t · c · p · b} 14:31, 6 September 2019 (UTC)

WP:SOFIXIT Special skills not required. Copy source from {{cite ssrn/new}}.

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

@Trappist the monk: this is LUA stuff, so yes, special skills required. Also please fix the damn {{cite web}}/{{cite news}} errors per overwhelming consensus. It's ridiculous that we're still waiting on this 3 days later. Headbomb {t · c · p · b} 14:43, 6 September 2019 (UTC)

Did you look? There is no Lua code in that template sandbox: There is an {{invoke:}} (not Lua code), {{documentation}} (not Lua code), and <includeonly>...</includeonly> & <noinclude>...</noinclude> tags (not Lua code). The invoke should not point to the module sandbox.

Template needs documentation.

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

I have created the template and a draft documentation page (copied from cite web docs). The documentation needs examples, and probably adjusting of the transcluded contents, provided by someone who knows what the new template is for and how it is used. I think there are a couple of other pages that try to list all of the CS1 templates; those need to have the new template added to their tables/lists, with appropriate descriptions. – Jonesey95 (talk) 17:32, 6 September 2019 (UTC)

Category redirection over deletion

Since there are many pages and edit summaries that link to the old (and recently mostly deleted categories), wouldn't it be better to {{Category redirect}} them instead of deleting? ~ Tom.Reding (talk ⋅dgaf) 12:01, 29 September 2019 (UTC)

I don't know how many edit summaries link to the various renamed categories. Most links to the old-named categories are residue from the change to the new name in non-article namespaces. This because any page that isn't an article won't be refreshed with the frequency that article-namespace pages are refreshed.

Take for example Category:CS1 maint: Multiple names: authors list. As I write this, there are 5k+ pages linking to that category Of those pages, there are three in article namespace:

Manchester City F.C. supporters (ve edit)

Sarracenia × swaniana (from ro:Sarracenia swaniana via Content translation)

Albert Schweitzer High School (Erlangen) (from de:Albert-Schweitzer-Gymnasium (Erlangen) via Content translation)

All three of these have raw (not created by the current versions of a cs1|2 template) old category link because of that abomination that is ve (copying named references from one page to another) or because the article was created by the auto-translation process (whatever that is) from another language Wikipedia.

If we redirect all of these old-named categories, it is (I think) harder to find these buggered up articles because they don't get listed in the old-name category but, instead, get lumped in with all of the articles in the new-named category.

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

Category:CS1: long volume value

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

See this discussion.

—Trappist the monk (talk) 16:37, 29 September 2019 (UTC)

Without having read the initial discussion, my first thought is that "long volume value" is not an inherent problem, although many of these cases may justify the addition of a |volume-subtitle= parameter or something to that effect. -BRAINULATOR9 (TALK) 01:02, 30 September 2019 (UTC)

Zero-width joiners between emoji

What is the correct resolution for invisible character errors in citations with titles using zero-width joiners between emoji, as in the citation on 2019 in American television? —Ost (talk) 20:47, 30 September 2019 (UTC)

You could leave it out; the rendering of the emoji on my win10 machine at en.wiki is different from the rendering of the emoji at twitter. If you must keep the emoji, replace the unicode zwj with its html equivalent:

{{cite tweet|number=1155848220775452673|user=TeenNick|author=TeenNick|title=An all new season of  #HunterStreet is coming to TeenNick TONIGHT at 7:30/6:30p 🕵️&#x200D;♀️ |date=July 29, 2019|accessdate=September 26, 2019}}

TeenNick [@TeenNick] (July 29, 2019). "An all new season of #HunterStreet is coming to TeenNick TONIGHT at 7:30/6:30p 🕵️‍♀️" (Tweet). Retrieved September 26, 2019 – via Twitter.

—Trappist the monk (talk) 21:50, 30 September 2019 (UTC)

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

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

I suspect that this is because {{cite compare}} no longer obeys |old=no; any value causes the transclusion of {{cite xxx/old}}. In this case, {{cite arXiv/old}} unconditionally adds Category:Articles with missing Cite arXiv inputs regardless of the namespace. The fix for this is at {{cite compare}} to make it obey |old=no. Pinging Editor Izno?

—Trappist the monk (talk) 10:35, 3 October 2019 (UTC)

Yes, I flipped the intent of |old= and made it so that any value caused the old template to display. The correct fix is to remove |old=no in this case. --Izno (talk) 13:17, 3 October 2019 (UTC)

Having |old=no behave the same as |old=yes is counter-intuitive. I suggest fixing that, or at least cleaning up all former uses that depended on the previous behavior. – Jonesey95 (talk) 14:28, 3 October 2019 (UTC)

I will not be doing the latter as I saw it as zero-value-add to do so. I think you should instead change your understanding of the parameter as to the former per my earlier comment, but I won't revert someone who really feels that's the Way It Should Be (that only |old=yes should trigger display of the old template). --Izno (talk) 14:58, 3 October 2019 (UTC)

Inconsistent book volume bolding

These two identically formatted citations, as found in Abelian group:

{{cite book |last=Fuchs |first=László |date=1970 |title=Infinite Abelian Groups |series=Pure and Applied Mathematics |volume=36-I |publisher=[[Academic Press]] |mr=0255673 }}
{{cite book |last=Fuchs |first=László |date=1973 |title=Infinite Abelian Groups |series=Pure and Applied Mathematics |volume=36-II |publisher=[[Academic Press]] |mr=0349869 }}

produce inconsistent formatting: the first book's volume number is bolded and the second is not.

Fuchs, László (1970). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-I. Academic Press. pp. 1–10. MR 0255673.
Fuchs, László (1973). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-II. Academic Press. pp. 11–19. MR 0349869.

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

This is the 4-character-limit issue:

|volume=36-I → 4 characters

|volume=36-II → 5 characters

—Trappist the monk (talk) 11:41, 5 October 2019 (UTC)

Really books should display this as "Vol. 36-I", rather than "36-I". Headbomb {t · c · p · b} 13:50, 5 October 2019 (UTC)

I agree. Bolding should be reserved for the situations where we use the journal-style formatting of page numbers. Kanguole 16:29, 5 October 2019 (UTC)

It should also group volume with pages, rather than separate them with the publisher. Headbomb {t · c · p · b} 17:31, 5 October 2019 (UTC)

Unlike magazines, I disagree. The volume of a book is more a function of its title. Imzadi 1979 → 21:21, 5 October 2019 (UTC)

Not so for series of books, which is when |volume= should be used. Headbomb {t · c · p · b} 21:26, 5 October 2019 (UTC)

Yes, in this case the volumes should definitely be immediately after the series, not the title. The next most tight grouping would be that the series+volume should be adjacent to the publisher. It would be wrong to move the volume past the publisher and away from the series to put it closer to the page numbers. —David Eppstein (talk) 21:32, 5 October 2019 (UTC)

I'm thinking something like

Fuchs, László (1973). Infinite Abelian Groups. Pure and Applied Mathematics. Vol. 36-I. pp. 1–10. Academic Press. MR0349869.

Headbomb {t · c · p · b} 05:21, 6 October 2019 (UTC)

Out of curiosity, what is the urgency? This has been discussed since the change to conditional bolding was being considered, some years back. Why does this keep popping up? Either leave as is and provide a better explanation for the apparent inconsistency, or apply uniform font weight. It is a bit tiresome to keep revisiting the same issues. 72.43.99.138 (talk) 15:14, 6 October 2019 (UTC)

Why does this keep popping up? Because it's an unresolved problem? — UnladenSwallow (talk) 19:39, 6 October 2019 (UTC)

Yes, we know. The question is, why is it still unresolved after it has been brought up multiple times? As was suggested, either change the bolding, or explain it better so it isn't brought up so often. 98.0.246.242 (talk) 01:37, 7 October 2019 (UTC)

For the enterprising gnome

Here is some things to cleanup, most related to citations. I think the related bug in VE has been fixed. --Izno (talk) 18:03, 8 October 2019 (UTC)

I am skeptical of any claimed fixes to ve. Are you referring to this one: phab:T209493?

—Trappist the monk (talk) 18:08, 8 October 2019 (UTC)

Here's an edit adding templatestyles nonsense on 4 October 2019. It doesn't look like this bug is fixed. – Jonesey95 (talk) 18:41, 8 October 2019 (UTC)

end pipe not displaying

Tracked in Phabricator
Task T138229

In

Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of |V_tb|". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561.

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

That is normal. The module interprets the resulting pipe as an end-of-field character. You could try <nowiki>. 98.0.145.210 (talk) 12:45, 13 October 2019 (UTC)

Another option would be using U+200D ZERO WIDTH JOINER (&zwj;) after the pipe ~~template~~ magic word. In the original citation, the module sees two pipes in succession, therefore it ignores the additional. 72.43.99.138 (talk) 14:06, 13 October 2019 (UTC)

That is not normal {{!}} is specifically designed to render, not be treated as yet another | delimited. See e.g. {{xt|{{!}}V<sub>tb</sub>{{!}}}} which renders exactly as intended, e.g. |V_tb|. — Preceding unsigned comment added by Headbomb (talk • contribs) 18:33, 13 October 2019 (UTC)

I agree. Using the standard workaround for vertical bars in templates should work. It is a bug that it does not. I note, however, that even without that issue the title is not quite formatted correctly. If you look at the original source,

|V_{tb}|

is a mathematics formula in which the letters are all italicized. So it would be rendered better as

{{cite journal |last=Abazov |first=V.M. |collaboration=[[DØ Collaboration]] |display-authors=etal |year=2007 |title=Evidence for production of single top quarks and first direct measurement of <math>|V_{tb}|</math> |journal=[[Physical Review Letters]] |volume=98 |issue=18 |pages=181802 |doi=10.1103/PhysRevLett.98.181802 |arxiv=hep-ex/0612052 |bibcode=2007PhRvL..98r1802A |pmid=17501561 |hdl=10211.3/194387}}
Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of $|V_{tb}|$ ". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561.

—David Eppstein (talk) 18:44, 13 October 2019 (UTC)

The italics thing is besides the point. |V_tb| would equally fail to render correctly. Headbomb {t · c · p · b} 02:50, 14 October 2019 (UTC)

And it would not render with the proper serif font for math variables, again. In mathematical formulas, the correct font matters. Using a different font can often mean that you are referring to a completely different variable, or something undefined. If you don't want to use <math>, the other alternative for getting something close to acceptable mathematical formula rendering is the {{math}} series of templates, which need the {{!}} workaround but otherwise work: Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of

| V tb |

". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561. — Preceding unsigned comment added by David Eppstein (talk • contribs) 03:31, 14 October 2019 (UTC)

Again, that's besides the point. And variables certainly don't have to be rendered in serif fonts. Headbomb {t · c · p · b} 05:06, 14 October 2019 (UTC)

If you want to preserve the meaning in a mathematical text where the author is using the default serif italic for one meaning and \mathsf (LaTeX-style sans-serif) for a different meaning (and maybe bold upright and outlined upright for other meanings), then yes, they do. If you're writing something where you're choosing your own variable names, then you're free to make them sans, but they still need to stay consistently formatted rather than inheriting formatting from the surrounding text. —David Eppstein (talk) 05:36, 14 October 2019 (UTC)

Use of <math>...</math> is problematic because MediaWiki took away our ability to see the underlying content of the tag. The content of <math>...</math> is rendered visually as an image; logged in editors can select one of three styles according to a setting in their Special:Preferences. When MediaWiki took away our ability to see the image's underlying makeup, we lost the ability to render any sort of meaningful metadata. All that Module:Citation/CS1 sees is a math stripmarker that looks something like this: ?'"`UNIQ--math-0000001C-QINU`"'? (the '?' characters represent the delete character). Because we can no longer see what that stripmarker represents, all title metadata for titles with <math>...</math> in them get an error message (MATH RENDER ERROR) in place of the <math>...</math> content. So, for the example template, cs1 produces this article title metadata:

&rft.atitle=Evidence+for+production+of+single+top+quarks+and+first+direct+measurement+of+MATH+RENDER+ERROR

Cannot do anything about that until Lua is allowed access to the content of <math>...</math> tags. See the phabricator ticket.

—Trappist the monk (talk) 13:34, 14 October 2019 (UTC)

Doesn't seem like this ticket will be resolved any time soon. 72.43.99.138 (talk) 14:21, 14 October 2019 (UTC)

Interesting. Using {{pipe}} instead works as it should, so this has something to do with template expansion vs magic word rendering. It seems that the magic word is processed after the field has been formatted (with quote marks). If that is the case, instead of the module rendering |"{delimiter} it renders "{delimiter}{delimiter}. 98.0.246.242 (talk) 01:44, 14 October 2019 (UTC)

EDIT: or maybe not. Since the magic word works properly when followed by a zero width joiner, my idea that it is processed after the quote mark formatting is a dud. Something else is the culprit. 98.0.246.242 (talk) 01:48, 14 October 2019 (UTC)

Use of {{pipe}} is discouraged because it produces improper metadata.

—Trappist the monk (talk) 13:34, 14 October 2019 (UTC)

Metadata is irrelevant. I was only using {{pipe}} to illustrate that the template expands properly inside the |title= field, unlike the magic word/variable, which apparently trips when display format is applied on the parameter. 72.43.99.138 (talk) 14:08, 14 October 2019 (UTC)

Metadata is relevant to those who consume these citations via the metadata.

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

There may be some sort of interaction between the magic word/variable {{!}} and the script_concatenate function in Module:Citation/CS1 (lines 572-580). The {{!}} variable works as it should when inserted in other fields, but not for |title= (and its various aliases). The function that formats |title= (format_chapter_title) uses the function script_concatenate. See line 714, and the code comment: -- <bdi> tags, lang atribute, categorization, etc; must be done after title is wrapped. This also appears in section "format main title" starting in line 3110 (the pertinent statements are in lines 3126-3140). So |title= formatting may have something to do with the disappearing variable after all? 72.43.99.138 (talk) 13:24, 14 October 2019 (UTC)

Fixed in the sandbox:

Cite journal comparison
Wikitext	`{{cite journal\|arxiv=hep-ex/0612052\|bibcode=2007PhRvL..98r1802A\|collaboration=[[DØ Collaboration]]\|display-authors=etal\|doi=10.1103/PhysRevLett.98.181802\|first=V.M.\|hdl=10211.3/194387\|issue=18\|journal=[[Physical Review Letters]]\|last=Abazov\|pages=181802\|pmid=17501561\|title=Evidence for production of single top quarks and first direct measurement of \|V<sub>tb</sub>\|\|volume=98\|year=2007}}`
Live	Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of \|V_tb\|". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561.
Sandbox	Abazov, V.M.; et al. (DØ Collaboration) (2007). "Evidence for production of single top quarks and first direct measurement of \|V_tb\|". Physical Review Letters. 98 (18): 181802. arXiv:hep-ex/0612052. Bibcode:2007PhRvL..98r1802A. doi:10.1103/PhysRevLett.98.181802. hdl:10211.3/194387. PMID 17501561.

—Trappist the monk (talk) 13:34, 14 October 2019 (UTC)

Cool. So the module is treating the variable as a link, and is formatting accordingly, correct? 72.43.99.138 (talk) 13:55, 14 October 2019 (UTC)

Not quite. Because is_wikilink(str) in the live module does not return when it discovers that str is not a wikilink, the live module assumes that trailing (and / or leading) pipes in D and L are an acceptable form of wikilink; these all work:

[[Abraham Lincoln]] → Abraham Lincoln (no pipes)

[[|Abraham Lincoln]] → Abraham Lincoln (leading pipe)

[[Abraham Lincoln|]] → Abraham Lincoln (trailing pipe)

[[Abraham Lincoln|Abe|]] → Abe| (trailing pipe)

In this particular case, the is_wikilink() function is called because journal titles need to be kerned if the title's first and / or last character is some form of quote mark. When the title is wikilinked, the leading / trailing quote marks may be inside the display portion of the wikilink. It occurs to me that L can never have a leading pipe so L = L and mw.text.trim (L, '%s|'); is pointless. I have disabled that line while I think about it and revised the early exit test.

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

Indeed. I noticed you commented it out in your latest sandbox edit. And as indicated the problem seemed peculiar to the parsing of {{!}}. But, since the if not condition you added seems to work out, I guess this is resolved in some fashion. 172.254.98.154 (talk) 17:42, 14 October 2019 (UTC)

Two separate publication dates in a single citation

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

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

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

Stanley, Richard P. (1997, 1999), Enumerative Combinatorics, Cambridge University Press {{citation}}: Check date values in: |year= (help)CS1 maint: year (link)

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

Is there a reason why citing Volume I and Volume II separately wouldn’t work? I’m not sure I see the benefit to a single citation for both volumes. Umimmak (talk) 01:53, 9 October 2019 (UTC)

Is there a reason why a citation to a two-volume work should be forced to be artificially split into two separate but almost equal citations? Or, is there a reason why a citation to a two-volume work should be forced to be artificially split into two separate, but almost equal, citations? Does the repetition add any value to the reader? Is doing it that way better for readers? Or is your suggestion purely for the benefit of template-software authors? Or maybe you think that we should prioritize ease of coding over ease of use? —David Eppstein (talk) 02:58, 9 October 2019 (UTC) —David Eppstein (talk) 02:58, 9 October 2019 (UTC)

The pages cited come from two separate volumes, with two separate dates of publication, two separate ISBNs, two separate chapters, two separate DOIs, etc. They don’t come from the same place, so they shouldn’t be forced together in a single citation. Is there any sort of precedent for citing multiple pages from multiple volumes in a single citation? Umimmak (talk) 08:06, 9 October 2019 (UTC)

As Umimmak says: two separate volumes. They are physically separate, and published separately. The artificiality is in trying to make one citation cover two separate sources. ♦ J. Johnson (JJ) (talk) 21:08, 11 October 2019 (UTC)

David, two points. First, with respect to:

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

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

Good point. ♦ J. Johnson (JJ) (talk) 21:23, 15 October 2019 (UTC)

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

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

References

^ Stanley, Richard P. (1997). Enumerative Combinatorics. Vol. 1. Cambridge University Press.,
Stanley, Richard P. (1999). Enumerative Combinatorics. Vol. 2. Cambridge University Press. {{cite book}}: Unknown parameter |authormask= ignored (|author-mask= suggested) (help)
^ Stanley, Richard P. Enumerative Combinatorics. Vol. in two volumes. Cambridge University Press. Volume I: Cambridge (1997); volume II: Kalamazoo (1999).

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

I found this cite web template in George Washington:

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

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

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

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

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

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

Because this is how the {{sfnref}} is rendered:

{{sfnRef|"Five-star Generals, 2017"}} → CITEREF"Five-star_Generals,_2017" → CITEREF"Five-star_Generals,_2017"

Are the quote marks necessary? Probably not.

—Trappist the monk (talk) 21:33, 15 October 2019 (UTC)

The format of {{sfnref}} is non-standard in the example. I would label the anchor to follow the conventions of short refs (Author-Year) or if there is no author, Work-Year or (distant 3rd, and not unambiguous) Title-Year. If the last has to be used, there may be a case for additional markup depending on the work type. 98.7.199.92 (talk) 00:31, 16 October 2019 (UTC)

Supplement parameter

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

Are you sure? I don't know that |supplement= ever existed in cs1|2 templates.

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

True, I don't remember a "supplement" parameter either. I would use |type=supplement instead. If the particular supplement is a regular feature, identify the feature in e.g |department=weekly magazine or |department=annual survey or some such. 72.43.99.138 (talk) 13:43, 22 September 2019 (UTC)

For instance Sunday Times, has multiple supplements like Sports section, Business, Style Magazine, with their own page number, cite newspaper had it, now that redirects to cite news, which doesn't have |supplement parameter, can we add that please, thanks. Govvy (talk) 15:28, 22 September 2019 (UTC)

Are you sure? The first version of {{cite newspaper}} is as a redirect to {{cite news}}. Over its history, that has never changed.

As suggested before, consider |department=.

—Trappist the monk (talk) 16:04, 22 September 2019 (UTC)

The {{Cite DNB}} template has a |supplement= parameter. It's not a CS1 template, but could be the source of confusion. Jts1882 | talk 16:18, 22 September 2019 (UTC)

Department? That really is poor in description and use, can we please add =|supplement thanks. Govvy (talk) 21:07, 22 September 2019 (UTC)

Not as bad as you think, since supplements and specific, regular sections in newspapers and magazines are usually put together by different editorial departments. 98.0.246.242 (talk) 01:48, 23 September 2019 (UTC)

I remember this parameter, since I asked for it years ago. I asked for column per AP style, but the discussion was that folks would use this for the physical column, so the consensus was department. --21lima (talk) 23:32, 16 October 2019 (UTC)

Format for author name suffixes?

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

Does MOS:JUNIOR help?

—Trappist the monk (talk) 16:48, 19 October 2019 (UTC)

What I’ve been doing is have the surname be in |last= and then the first name and any suffixes in |first= separated with a comma, yielding examples like Doe, John, Sr. or Deer, Jason, III. Umimmak (talk) 17:51, 19 October 2019 (UTC)

Almost what I do, but per MOS:JR "Omission of the comma before Jr. or Sr. (or variations such as Jnr) is preferred." So I write |last=Doe |first=John Sr. or |last=Deer |first=Jason III etc, yielding "Doe, John Sr." or "Deer, Jason III". —David Eppstein (talk) 18:32, 19 October 2019 (UTC)

The preference in MOS:JR for omitting the comma before Jr. and Sr. only applies when the name is just in running text, not when it's inverted as in citations. See, e.g., CMoS 17 §6.43 for a style guide with similar advice: Commas are not required with Jr. and Sr., and they are never used to set off II, III, and the like when these are used as part of a name. In an inverted name, however (as in an index; see 16.41), a comma is required before such an element, which comes last. Umimmak (talk) 21:24, 19 October 2019 (UTC)

You are incorrect. Try reading a little farther down in MOS:JR: "When the surname is shown first, the suffix follows the given name, as Kennedy, John F. Jr." And the fact that the previous paragraph is the only one in the section that is explicitly stated as being for running text is a strong clue that the rest of the section does not have that restriction. —David Eppstein (talk) 22:03, 19 October 2019 (UTC)

Like Unimmak and the CMS say: with inverted names – such as in citations – include a comma. E.g.: |first=John, Sr.; |first=Jason, III. ♦ J. Johnson (JJ) (talk) 22:28, 19 October 2019 (UTC)

We have our own MOS. It is different from the CMS. And this is one of the ways in which it is different. It says not to use the comma here. —David Eppstein (talk) 22:42, 19 October 2019 (UTC)

(edit conflict) I’ve done some digging through the archives, and as much as I disagree with this, it seems this particular issue was discussed at Wikipedia talk:Manual of Style/Biography/2016 archive#A slight expansion of MOS:JR, although no one in that discussion seemed to check for precedent from other style guides. I’ll confess I overlooked the sentence David Eppstein quoted. Umimmak (talk) 22:43, 19 October 2019 (UTC)

Thanks to you all.--Sturmvogel 66 (talk) 00:01, 20 October 2019 (UTC)

Agreed with J. Johnson (and CMoS and various other sources). While the worlds' publishers are not entirely uniform on how to do this, a pattern like "Johnson, J.; Wales, Jimmy; Davis, Sammy, Jr." appears to be the most common, and it's what most of our own editors seem to be doing internally. In 14+ years here (under various usernames), no one's ever reverted me normalizing to the "Surname, GivenName[s], Suffix" format. — AReaderOutThataway ^t/_c 22:42, 20 October 2019 (UTC)

The proper place to discuss proposed changes to this portion of WP's Manual of Style is Wikipedia talk:Manual of Style/Biography, not here. – Jonesey95 (talk) 23:43, 20 October 2019 (UTC)

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

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

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

ISBN is not required, as many books do not have ISBNs. Don't overlook that the "always include" is contingent on "if one has been assigned". And I would consider the "always include" as more of an injunction – as in "you should do this" — whereas "require" (as you phrased it) is stronger, and implies that there is some kind of enforcement. That we don't have. ♦ J. Johnson (JJ) (talk) 23:13, 18 October 2019 (UTC)

I've reordered the headers at the top of the page and tweaked the talk page header a bit. {{Talk header}} does not allow for a fully custom title.

Were ISBN required, cs1|2 would emit a red error message telling you to include the ISBN; cs1|2 doesn't, so ISBN is not required. When an ISBN is available, you should provide it because readers can use it to link through Special:BookSources to various on-line places where the book might be found. All en.wiki editors should do this in consideration of our readers

—Trappist the monk (talk) 23:45, 18 October 2019 (UTC)

Thankyou for your replies. I'm well aware that not all books have ISBNs, I have myself cited books which don't. However I just think it's odd that on Wikipedia:Citing sources#Books the publisher field is not labelled optional (when it certainly is, I rarely see a book cited with the publisher filled in), and yet ISBN, which ideally would be included where available, is listed as optional. Maybe really I should take this to Wikipedia talk:Citing sources and suggest that it should be changed to something like (optional, but highly encouraged if available)?

Also given what you (Trappist the monk) say about the standard template not allowing for this customisation I think the change you made is fine. A7V2 (talk) 00:01, 19 October 2019 (UTC)

CS#Books says "typically includes", not "required". --Izno (talk) 16:12, 19 October 2019 (UTC)

But then isn't that even worse? Publisher and edition are clearly optional as well (since in practice they are often not included), but ISBN is singled out there as being the only "optional" field in a list of things only typically included. What I'm getting at is that the two pages send (in my mind) contradictory messages about expectations/requirements/etc for including ISBN when available. A7V2 (talk) 02:22, 21 October 2019 (UTC)

If |page= (or |ref=harv) is included it should be required to have either |isbn= or |publisher= + |year= - otherwise it is impossible to know which edition it is since page numbers can change depending on edition, many books have multiple editions/publishers/printings/media. -- GreenC 16:27, 19 October 2019 (UTC)

No. |Edition= is used to specify edition, and year often works to the same purpose. In the extremely rare cases where neither of those is sufficient to distinguish between two near identical documents that differ in pagination the ISBN might help. But making ISBN (or publisher) required merely because a page is given is ludicrous. ♦ J. Johnson (JJ) (talk) 22:16, 19 October 2019 (UTC)

[Gibbons-1] Gibbons, Sue (March 2005). "Percival Boyd". Genealogists' Magazine. 28 (5). Society of Genealogists: 187–195. ISSN 9770016639051. {{cite journal}}: Check |issn= value (help)

[two-cites-2] Stanley, Richard P. (1997). Enumerative Combinatorics. Vol. 1. Cambridge University Press.,
Stanley, Richard P. (1999). Enumerative Combinatorics. Vol. 2. Cambridge University Press. {{cite book}}: Unknown parameter |authormask= ignored (|author-mask= suggested) (help)

[two-volumes-one-cite-3] Stanley, Richard P. Enumerative Combinatorics. Vol. in two volumes. Cambridge University Press. Volume I: Cambridge (1997); volume II: Kalamazoo (1999).

[1]

[1]

[2]

So, about those required parameters...

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

Support year-suffix outside the English alphabet

Proposal to change redirects

Add |zenodo=

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

Multiple url instances

Remove |url= when |doi= is provided

Option to turn off PMC autolink

script-title=missing prefix

Template:Hyphen is corrupted

Cite news - multiple URLs

Template:Citation has a mode=cs1 parameter

ISSN error

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

Date in non-Gregorian calendar

Question about Title in Template:Cite episode

Citing an entire issue of a journal

Differing headlines between Print and Internet articles

isbn2

Post-update updates needed

Casing error

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

Cite web error

url-status

Please change website equals back to url

New error messages as of 2 September 2019

Discussion to undo all of the changes

"mode = CS1" raises warning

Cite ssrn, where it is?

Category redirection over deletion

Category:CS1: long volume value

Zero-width joiners between emoji

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

Inconsistent book volume bolding

For the enterprising gnome

end pipe not displaying

Two separate publication dates in a single citation

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

Supplement parameter

Format for author name suffixes?

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

Add `|zenodo=`

Remove `|url=` when `|doi=` is provided