Help talk:Citation Style 1

Citation templates (conception)

Citation templates (reality)

Working on Category:CS1 errors: invisible characters

I know that most of the editors who hang out here are gnomes that prefer to work quietly, but sometimes it's fun to take on a project as a team. This is an invitation to do just that. I'm planning to work on Category:CS1 errors: invisible characters, which has about 3,105 pages in it as of this writing.

I have found that most of the errors are straightforward line feeds and tab characters that should be replaced with spaces. Other characters should be replaced by a dash, apostrophe (single quote mark), space, ellipsis, quote mark, an accented character, or nothing. You can usually figure it out by context, or by checking the original source. I have some regexes that mostly work (each one needs to be checked manually) in the "invisible character" section of User:Jonesey95/AutoEd/unnamed.js, an AutoEd script. You are welcome to copy and refine those regexes, use manual searches, or adopt any other method you want.

I am planning to make a pass through the category to fix the easy errors, then see what's left. Feel free to join me, and post here with questions or comments. – Jonesey95 (talk) 05:56, 3 December 2017 (UTC)

Down to 2,800 at this writing. There is still a lot of low-hanging fruit in this category. – Jonesey95 (talk) 16:40, 24 December 2017 (UTC)

Now at 2773. I basically went after the first page in each alphabetical section (why not?). However, I stumbled across several pages with errors inside non-English text--mostly related to Sri Lanka--which I think will require some work by someone with language skills (example at Cadex 2009). I checked on one editor but he/she has not been here since 2011.--Georgia Army Vet Contribs Talk 20:19, 24 December 2017 (UTC)

Thanks for contributing! I've been skipping those zero-width joiner characters so far, as well as right-to-left text, which does not behave well in my editor. – Jonesey95 (talk) 21:49, 24 December 2017 (UTC)

We recently fixed that issue for several Indic scripts. A bit of Googling seems to show that zwj is also required for Sinhalese so I've added detection for Sinh script to Module:Citation/CS1/Configuration/sandbox (and fixed a bug at the same time):

Cite news comparison

Wikitext	{{cite news|accessdate=2009-10-16|date=2009-10-11|first=Keerthi|language=Sinhala|last=Warnakulasuriya|pages=18|title=යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ|work=Divaina}}
Live	Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18. {{cite news}}: |access-date= requires |url= (help)
Sandbox	Warnakulasuriya, Keerthi (2009-10-11). "යුද රහස් හෙලි කල එන්. ජී. ඕ ක්‍රියාකාරිකයාගේ සුලමුල හෙලිවේ". Divaina (in Sinhala). p. 18. {{cite news}}: |access-date= requires |url= (help)

—Trappist the monk (talk) 22:04, 24 December 2017 (UTC)

Is there a validation process before this is implemented?--Georgia Army Vet Contribs Talk 03:52, 29 December 2017 (UTC)

Horizontal tab

Is there any use, anywhere, in Wikipedia for the horizontal tab, U+0009 (HT)? I've been editing for seven years plus and can't think of one. If there isn't one, I don't see why we can't ask the folks who work on bots to do a search and replace and substitute a <space> for every <HT>. In some cases, we might get strings of spaces but that would still be an improvement. I'm a big fan of letting computers do my work for me. Or am I over simplifying this?--Georgia Army Vet Contribs Talk 23:58, 30 December 2017 (UTC)

Tab can be seen on programming pages in and out of article space. You might also see it in <pre> and <poem> blocks, or even outside to provide the latter (since a space at the beginning of a line starts a block). --Izno (talk) 00:10, 31 December 2017 (UTC)

Oh, well.<sigh>--Georgia Army Vet Contribs Talk 00:32, 31 December 2017 (UTC)

Update one month in

A little over one month in, we are down to 2,149. I am working backwards through the alphabet and have hit pages starting with S-Z so far. Steady progress. – Jonesey95 (talk) 05:25, 10 January 2018 (UTC)

We need to get implementation on ignoring the zero-length characters in Indic(?). I think every page in the U's "suffers" from that condition.--Georgia Army Vet Contribs Talk 15:17, 12 January 2018 (UTC)

It has been implemented in the sandbox. It will be useful to go through the rest of the category to see if there are any other bugs that need to be fixed. – Jonesey95 (talk) 15:41, 12 January 2018 (UTC)

1,294. 0–9, A–I. Meet at N? :)

I'm seeing a lot of tabs and newlines, mainly in |title=, but also in other params. These should be possible to automate: in all params (except |quote=, see below; and with a caveat, ditto), all runs of whitespace can be safely collapsed to a single space character. Another big class is apostrophes, long dashes, and smart quotation marks copied from unlabelled Windows code page 1252 (and a few other charsets) that can probably be automated with an acceptable error rate. Then there's a bunch of completely garbled text, titles mostly, that suffers from the same problem but which can't really be fixed automatically or semi-automatically. There's also a few similarly garbled author names, but not a lot of them. And, of course, a lot of ZWJ warnings in various asian scripts (possibly only in Sinhalese, but there may have been some Malayalam and Hindic etc. too) that, I believe, are just false positives.

And then there's a ton of newlines in |quote= that can't really be fixed, neither automated nor manually. Truncating the quote or simply removing the newlines is likely to annoy the natives (local editors), and I don't know of a workaround. This needs to be resolved somewhere, somehow: drop support for |quote= entirely; set a hard limit on what it can contain; or permit newlines inside this specific parameter.

And then there is {{cite tweet}}.

Which wraps {{cite web}}, but for its |title= parameter documents: "Entire content of the tweet, including hashtags (#), at signs (@), and links". This, to me, is bogus in so many ways; but in any case, this module's check for newlines is in direct conflict with that template's documented behaviour. In other words, this can't be cleaned up by gnomes. --Xover (talk) 17:54, 14 January 2018 (UTC)

Thanks for the comments. I wonder if silently converting all white space to spaces without emitting error messages would bother editors. We currently collapse white space and emit an error message; it might be more fruitful to do so without an error message. Here's an example of how we do it now:

Cite web comparison

Wikitext	{{cite web|author=Author|date=January 1, 2000|title=Text followed by new line Second line Third lines|url=http://www.example.com}}
Live	Author (January 1, 2000). "Text followed by new line Second line Third lines". {{cite web}}: |author= has generic name (help); line feed character in |title= at position 26 (help)
Sandbox	Author (January 1, 2000). "Text followed by new line Second line Third lines". {{cite web}}: |author= has generic name (help); line feed character in |title= at position 26 (help)

Perhaps someone here could remind us why we emit error messages for harmless white space. I forget, and I am too busy doing other stuff (lazy?) to dig through this page's archives right now. Maybe later. – Jonesey95 (talk) 18:02, 14 January 2018 (UTC)

For |quote=, newlines can be replaced with <br /> tags:

{{cite book |title=Title |quote=Text followed by new line<br />Second line<br />Third line}}

Title. Text followed by new line
Second line
Third line

or, depending on context, <p>...</p> tags:

{{cite book |title=Title |quote=Paragraph followed by<p>Second paragraph</p><p>Third paragraph</p>}}

Title. Paragraph followed by

Second paragraph

Third paragraph

We find tabs, line feeds, carriage return characters because they generally don't belong in the metadata along with all of the other ascii characters with byte value less than 32 decimal (0x20 hex) – the space character.

—Trappist the monk (talk) 18:59, 14 January 2018 (UTC)

Thanks. I don't know why I was convinced <br /> and <p>...</p> wouldn't work here. Possibly I'd been doing battle with errors related to strip markers and such. In any case, most |quote= parameters now look like they can be fixed this way (some cases require too much tag soup so I'm leaving them alone). In view of that, what I'm leaving behind (not touching) are mainly ZWJ cases and {{cite tweet}} (which would turn into tag soup if handled this way).

Incidentally, in going back over these articles I've found (in Fuk'anggan) that Manchu alphabet and Mongolian script (the former seems to be an extension/adaption of the latter) also require ZWJ. Otherwise the ZWJ cases so far are all Sinhalese. --Xover (talk) 11:51, 16 January 2018 (UTC)

(added) Oh, and I nearly forgot: based on Characters of Casualty, certain cases of Emoji also require ZWJs, which will be an increasing issue as we copy whole tweets into citations. See this link on emojipedia for details. Not sure what, if anything, can be done about this (detect and ignore them in Emoji sequences?). --Xover (talk) 11:58, 16 January 2018 (UTC)

Additional case of legitimate use / false positive: Burmese script does not use spaces for word boundaries, so a Zero width space character is often used at phrase boundaries to facilitate line breaking. See UNICODE technical note 11 for details. Example in Ayeyarwady Region Government. --Xover (talk) 09:32, 19 January 2018 (UTC)

I came across a "line feed in quote" in El Rancho Hotel and Casino last night that I could not find. I decided the error was from an included {{collapsible list}}, which I remmed out. It worked but left a very long reference which I'm not sure is necessary.--Georgia Army Vet Contribs Talk 19:25, 14 January 2018 (UTC)

I haven't looked at the source, but a quote that long is likely to be a copyright violation. I have found a couple of those while cleaning out this category, and my fix is to remove all but a sentence or two, preserving the relevant text that supports the statement in the article's prose. – Jonesey95 (talk) 19:46, 14 January 2018 (UTC)

I went back and "aggressively trimmed" the quote.--Georgia Army Vet Contribs Talk 16:30, 16 January 2018 (UTC)

Pretty much done

At this writing, we have reduced this category from 3,000+ pages to 193 pages. One more pass through the letters P, R, and S could probably fix a couple dozen more pages. I haven't done an exact count, but I think at least half of the remaining pages are false positives – Sinhalese and other scripts that use allowable zero width joiner characters. The CS1 sandbox has been partially updated to account for these; once it is moved to production, we can null-edit the whole category to find (and, ideally, fix) the remaining errors. Great work, everyone! – Jonesey95 (talk) 05:19, 23 January 2018 (UTC)

144, after a manual pass through all the remaining pages. The vast majority are zero width joiners in Singhala script, with a single Manchu and a couple of Emoji cases in the mix. There's also a bunch of tweets quoted entire (some using cite web, some using cite tweet). And a few archives that I don't feel comfortable editing for various reasons (some shady "Trappist the monk" character demonstrating nested references on the technical village pump, for instance). And then there are these: NEC V60 and Bill, the Galactic Hero on the Planet of Bottled Brains...

In any case, when the script-related false positives are eliminated, the category will be essentially empty except for tweets and archives.

But working on this I've noticed new cases being added at an alarming rate (on the order of 5-10 per day). To keep this down we're going to need some way to prevent these from getting added in the first place. Perhaps it'd be worthwhile to explore some validation or other measure in Citoid (which is the backend for both reFill and Visual Editor)? The garbage data is mostly coming from the source website through indiscriminate cut&paste / import, and Citoid is in a position to prevent a significant portion of these from getting in. The remainder would probably need to be handled (if needed) by some more assertive warning from Module:Citation/CS1. --Xover (talk) 22:02, 24 January 2018 (UTC)

User:ReferenceBot used to post on editors' talk pages when they added a page to one of the "empty" CS1 categories. Its notices resulted in fixes from editors who could understand the error messages and how to fix them, which was maybe around half. That's considerably better than nothing. The bot has been inactive for nearly a year. Maybe a bot request would result in another editor taking on that bot task. – Jonesey95 (talk) 22:23, 24 January 2018 (UTC)

Maybe the category count should be something like PAGESINCATEGORY <= 10. Sometimes, a lot can happen at once.--Georgia Army Vet Contribs Talk 23:07, 24 January 2018 (UTC)

ReferenceBot did not pay attention to any category's population count. It had a list of categories (provided by me, as it happens) that were deemed "empty" at some point, and notified editors when they added an article to one of those categories. The reason you need to empty the category first is to prevent a revert or a false positive or other constructive action from adding to the category. As we have seen with the invisible character category, we found some false positives while emptying it. – Jonesey95 (talk) 03:54, 25 January 2018 (UTC)

Italic lint error

In some citations with italics in the title (if nowhere else), lint errors are being caused. (There is a similar issue reported by @IKhitron: regarding bolding at phab:T140358, and I've left some comments there.) One example is at Geodesic convexity, the Rapcsák reference, which I believe to be legitimate. Currently, the HTML served (so, module + parser + Tidy) is (abbreviated for relevance):

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b></i><sup>n</sup>.</cite>

-> Rapcsák, Tamás. Smooth nonlinear optimization in Rn.

Like a previous post of mine at Template talk:Lang, this is clearly wrong, as the italics should surround the entirety of the title.

However, in a world where Tidy is turned off, the same citation returns:

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b><sup></sup></i>n<i></i>.</cite>

Which causes the misplacement of the sup tag and a subsequent visual rendering difference (in that the "n" is no longer superpositioned). (Aside: This seems also to cause a number of the errors related to the cite tag and template:Reflist in the misnesting category.)

The correct fix would be for all of the italic tags to be included (by changing Module:Citation/CS1/Configuration to add HTML italics rather than wikitext italics) and for the inner italics to be de-italicized. The HTML of that is the following:

<cite class="citation book">Rapcsák, Tamás (1997). <i>Smooth nonlinear optimization in <b>R</b><sup><i>n</i></sup></i>.</cite>

To de-italicize the inner italics, we would need to make a change to the CSS files of interest (at least on en.wp). However, making this particular fix would not preserve the italicization of the source currently: I have tested what happens when we have italics wrapping italics at this perma-link--in short, nothing! We could probably hack around this issue in this specific case at MediaWiki:Common.css by adding CSS to the tune of i sup i {font-style: normal;}, but this is sadly a not-so-general solution (I'll leave the exercise of futility to the reader). LESS could fix this according to StackOverflow, but we can't use LESS on-wiki.

So, the optimal solution to the problem is the following:

1. Change Module:Citation/CS1/Configuration to italicize using HTML. This removes the lint errors (which is categorically good because of problems like that reference, IK's reference) but does not preserve the sense of the italics.
2. Use LESS to style the <i> tag generally on Wikipedia (where its parent text is unitalicized, italicize; where its parent text is italizied, unitalicized). This would require a MediaWiki change.

I'm looking for thoughts, interim steps, and such agreement as can be found on Wikipedia (ping SSastry (WMF) for good measure) to a) making sure all of the italics render correctly, and b) the template is future-proof to the removal of Tidy. --Izno (talk) 02:54, 19 January 2018 (UTC)

All of your suggested formats are wrong. Math formulas in titles should not be italicized, because mathematics uses different font styles to encode different meanings, so changing the font style changes the meaning. Unfortunately, the {{math}} templates don't do anything to avoid italicizing when they are used in an italic context, and it would be really really ugly to put in explicit un-italic coding in the title parameter. So the only option we're left with is <math>:

{{cite book|last=Rapcsák|first=Tamás|title=Smooth nonlinear optimization in <math>\mathbf{R}^n</math>}}

Rapcsák, Tamás. Smooth nonlinear optimization in $\mathbf {R} ^{n}$.

—David Eppstein (talk) 04:03, 19 January 2018 (UTC)

That's not an unreasonable approach in the context of math, but my problem is clearly more general. :^) --Izno (talk) 04:13, 19 January 2018 (UTC)

PS if you look up a preview of the book itself, you'll find that it's printed on the front cover as "Smooth Nonlinear Optimization in $R^{n}$", with an italic (not bold) R. So it's a bad example of the issue for multiple reasons. —David Eppstein (talk) 04:41, 19 January 2018 (UTC)

I think quote parsing in MediaWiki is somewhat hacky because of unintended interactions between quotes in template args and quotes in the template source and this seems to be a common problem (I've seen this on many wikis including itwiki, svwiki, and others). But, I digress. In this case, what I have seen itwiki do is exactly what Izno proposes which is to change the template to use the HTML <i> tag instead of '' and <b> tag instead of '''. I recommended the same solution for svwiki. That said, given that some pages (like the Geodesic convexity example) "hack" their way to intended rendering by deliberately breaking quoting, with this fix by itself, rendering for those refs can change. I feel like using CSS to preserve it is another hack (which, we could add if it became necessary, but not sure what other unintended effects it could have). Ideally, the pages using this hack would be changed. One option is to use math as User:David Eppstein recommends. Another is to use a styled span tag around the text that needs de-italicising. But, that depends on how many pages are actually relying on this quote-hack. SSastry (WMF) (talk) 05:15, 19 January 2018 (UTC)

Thank you for noticing. Something weird. The problem I described in the task was fixed a couple of months ago. I totally forgot about filing the task, closed it now. It was my understanding of situation - the cause was <span /> in the code of the module. It was fixed in enwiki, and I fixed it in our wiki when I been told about this. I believed there could not be something you're describing. Can you please give a simple nowiki example that can create a problem in enwiki now? IKhitron (talk) 10:29, 19 January 2018 (UTC)

I'm on wiki break right now so my participation in this conversation will be sporadic. The <math>...</math>-markup-in-cs1|2-titles-solution is problematic. It used to be that the module could extract the raw content of markup for use in its metadata, but MediaWiki was broken some time ago and never fixed. See this and linked discussions.

Presently, cs1|2 render an error message in the metadata in lieu of a stripmarker:

'"`UNIQ--templatestyles-00000047-QINU`"'<cite id="CITEREFRapcsák" class="citation book cs1">Rapcsák, Tamás. ''Smooth nonlinear optimization in '"`UNIQ--math-00000046-QINU`"'''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Smooth+nonlinear+optimization+in+MATH+RENDER+ERROR&rft.aulast=Rapcs%C3%A1k&rft.aufirst=Tam%C3%A1s&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

—Trappist the monk (talk) 12:02, 19 January 2018 (UTC)

Lay source

I discovered during my work for the above that the current module processes LaySource by adding italics and then invoking safe_for_italics (and then closing the italics). Is there a reason we're not using wrap_style here (I think it's possible but I can be told I'm wrong :D)? --Izno (talk) 03:42, 19 January 2018 (UTC)

The more important question is: should cs1|2 support lay sourcing at all? If the lay source is important enough to cite, shouldn't it get its own cs1|2 template? Aren't cs1|2 templates intended to cite a single source per template? That is, after all the reason cs1|2 doesn't support multiple ISBNs; why should a layman's version of a source be any different?

—Trappist the monk (talk) 12:07, 19 January 2018 (UTC)

What is a lay source? Also, "shouldn't it get its own cs1|2 template" is confusing. Of course we do not have separate cs1 or 2 templates for each source, such as the notional {{cite-tale-of-two-cities}}.So it isn't clear what this phrase means. Jc3s5h (talk) 16:39, 19 January 2018 (UTC)

I would guess a "lay source" (it's completely undocumented from what I can tell) is a source which explains a source only understandable by subject matter experts. There are only about 3k uses.— Preceding unsigned comment added by Izno (talk • contribs) 17:27, 19 January 2018 (UTC)

Template:Cite journal#Lay summary.

—Trappist the monk (talk) 01:43, 20 January 2018 (UTC)

Is language=Bengali an error?

I am seeing articles in Category:CS1 maint: Unrecognized language due to |language=Bengali (example: 1950 East Pakistan riots), but this apparently official link says that Bengali is the official language name. What am I missing? – Jonesey95 (talk) 16:35, 19 January 2018 (UTC)

Help talk:Citation Style 1#mediawiki and language names/code again. The sandbox accepts Bengali and bn even though MediaWiki thinks that bn = {{#language:bn|en}} → Bangla.

—Trappist the monk (talk) 01:39, 20 January 2018 (UTC)

Dispute over Template:Citation Style documentation/journal – handling of complex |issue= information

I updated the documentation of the |issue= parameter to account for cases like "#293, Vol. 24, No. 5" (i.e., two different kinds of issue numbering), by adding the instruction "When a total issue number and an issue within a volume are both given – e.g., "#293, Vol. 24, No. 5" – this can be coded as |volume=24|issue=5 [total issue #293]." [1]; the documentation has for years already accounted for issue naming, with "When the issue has a special title of its own, this may be given, in italics, along with the issue number, e.g. |issue=2, ''Modern Canadian Literature''." This was not only reverted, but the revert included removal of both of these instructions, with an edit summary that doesn't make much sense to me: "no; abusing |issue= is no substitute for abusing |page=; one piece of information per parameter" [2]. Using |issue= for issue information is not "abuse" of the parameter, it's what the parameter exists for. Nor is there any principle here of "one piece of information per parameter", or we'd have separate parameters for middle names of authors, separate parameters for countries of city locations, separate parameters for days and months in dates, separate parameters for subtitles, and so on.

The problem to solve is that people are randomly actually abusing completely unrelated parameters like |page= and |publisher= to try to shoe-horn complex issue information into the template, when it obviously belongs in |issue=. But not obviously enough, or people wouldn't be doing that and we wouldn't need to have clearer documentation.

The only other alternative it to introduce yet more parameters for such things, and I think that's a terrible idea. So, I think this version should be restored.  — SMcCandlish ☏ ¢ 😼  12:28, 5 February 2018 (UTC)

I concur with SMcCandlish. Jc3s5h (talk) 16:20, 5 February 2018 (UTC)

That was me. It is not correct for us to 'permit' the misuse of a parameter just because editors have abused another parameter. The correct approach to the cumulative-issue-number vs. volume-issue-number question is to permit either but not both and to proscribe |volume= when a cumulative issue number is supplied in |issue=. For the issue-number-issue-title question, we have two fundamentally different pieces of information: the number is the basic descriptive unit typical of almost all periodicals and issue titles are generally rare special cases where the title merely supplements the issue number. Choose one, do not include wiki markup because the value assigned to |issue= is made part of the metadata.

No we would not have separate parameters for author middle names because we we have no need for that granularity; same for country location; same for dates. The question of subtitles is vaguely similar to the issue-number-issue-title question. There have been occasional requests here for a subtitle parameter but the community (not necessarily me) have rejected that, ostensibly because subtitles are merely extensions of the title. One might stretch the subtitle-as-title-extension point to argue that we should permit extension of issue number with issue title. I do not think that we should; extending a title with more title text is not the same as extending a sequence number with wiki markup and title text.

I don't see much value in the inclusion of issue titles in a citation. If the primary purpose of a citation is to help reader locate source material taken from a periodical, volume, issue, and date are much more likely to be helpful than an issue title. Further, it is the duty and obligation of the cs1|2 templates to render the correct style for each parameter. The only parameters that should use wiki markup are |title= and |chapter= (and their aliases) because titles often mix upright and italic fonts for good reason (scientific names, for example).

—Trappist the monk (talk) 12:09, 6 February 2018 (UTC)

Quote formatting

Currently, the quotes parameter can make the reference section hard to read, especially if quotes are long, or numerous (see example in this article). What do people think of having the quoted text be formatted with either a smaller font, or a dark grey colour so as to better delineate what is the reference and what is the quoted text? T.Shafee(Evo&Evo)^talk 12:32, 9 February 2018 (UTC)

The suggested styling can be mimicked by adding this line to your personal css:

cite q {color:gray; font-size:85%;}

—Trappist the monk (talk) 12:55, 9 February 2018 (UTC)

Broadly would not support this, as the text inside of the references group is already small text. Per WP:ACCESS we should not make it (much) smaller. The same goes for the text color, which would decrease contrast. As TTM notes, there is an alternative for yourself. --Izno (talk) 13:02, 9 February 2018 (UTC)

Oppose for reasons stated by Inzo. Also, I oppose grey fonts in nearly all situations, and have unfriendly thoughts to all those stylists who have been making so much of the web text I encounter grey. There's a reason laser printer manufacturers give you a warning when your toner is running low. Jc3s5h (talk) 13:59, 9 February 2018 (UTC)

@Evolution and evolvability: we should only be quoting the specific text necessary for verification purposes, and even then in many cases, we don't need a quotation at all. If a reference list is turning into a quotation farm, then perhaps the better solution is to audit the quotation usages to see if we really need all of that text. If it's really excessive, it could turn into a copyright-related issue as well. Imzadi 1979 → 14:19, 9 February 2018 (UTC)

Long quotes like these should typically be trimmed, placed in a Notes section, or incorporated into the article's body. – Jonesey95 (talk) 15:46, 9 February 2018 (UTC)

Update to the live cs1|2 modules weekend of 17–18 February 2018

I intend to update the live sc1|2 modules over the weekend of 17–18 February 2018. These changes are included:

to Module:Citation/CS1:

• test categorization for Julian/Gregorian date uncertainty; discussion
• fix title separator removal; discussion
• proper language name output for code bh; discussion

to Module:Citation/CS1/Configuration:

• date validation internationalization; discussion
• these parameters no longer supported: |doi_brokendate=, |doi_inactivedate=, |template doc demo=, |trans_chapter=, |trans_title=
• added script code mn;
• test categorization for Julian/Gregorian date uncertainty
• added Sinhala 0D80-0DFF characters to invisible character exclusion; discussion

to Module:Citation/CS1/Whitelist:

• these parameters no longer supported: |doi_brokendate=, |doi_inactivedate=, |template doc demo=, |trans_chapter=, |trans_title=

to Module:Citation/CS1/Date validation:

• internationalization support for non-Western digits in access-date timestamps; discussion
• COinS season and proper-name date index fix;
• test categorization for Julian/Gregorian date uncertainty

—Trappist the monk (talk) 12:53, 11 February 2018 (UTC)

Trappist: just dropping an extra mention here to make sure it didn't get lost in the noise: there are valid cases for ZWJ in Burmese and Emoji too (in addition to Sinhalese etc.). See the referenced thread above for details (such as they are). --Xover (talk) 14:06, 11 February 2018 (UTC)

I have added the unicode blocks for Burmese: Myanmar, Myanmar extended A, Myanmar extended B. Emoji I've left for some other time because, if one is to believe the table here, they are spread unevenly across multiple code blocks and are sometimes isolated codes which makes for a mess.

—Trappist the monk (talk) 15:28, 11 February 2018 (UTC)

Ugh! You're right. I see no sane way to detect this that doesn't involve importing and using the Unicode Emoji test table as a lookup table. Independently tracking all the code blocks and ranges that contain Emoji looks impractical, to the point that the Unicode consortium itself seems to have given up. --Xover (talk) 15:50, 11 February 2018 (UTC)

@Trappist the monk: Forgot about Manchu language, cf. Fuk'anggan. --Xover (talk) 17:57, 17 February 2018 (UTC)

I don't think that support for the Manchu alphabet is something that will be added soon, if ever. In your example, the Manchu text requires the use of {{MongolUnicode}} which emits a rather large amount of html & css to render that text. All of that html and css ends up in the metadata where it does not belong. Citing sources that have Manchu-alphabet titles is, I think, not something for which cs1|2 are the appropriate tools. Citing such sources should be hand-crafted or should use a custom citation template (if there is sufficient need).

—Trappist the monk (talk) 20:19, 17 February 2018 (UTC)

Trapppist, I don't see any link above to any discussion about the removal of "trans-title" and "trans-chapter", which is surprising, as I think they are useful parms to have. Could you provide a link, please? --NSH001 (talk) 00:02, 12 February 2018 (UTC)

Help talk:Citation Style 1/Archive 38#yet more parameters to deprecate.

—Trappist the monk (talk) 00:58, 12 February 2018 (UTC)

To be clear, |trans-chapter= and |trans-title= are remaining. All of our recommended multi-word parameters are separated by hyphens. – Jonesey95 (talk) 01:32, 12 February 2018 (UTC)

Ah, good, that's fine, thanks. (Must get my eyesight tested...) --NSH001 (talk) 07:11, 12 February 2018 (UTC)

Date range over year boundary

I get date check errors for |date=December 2004–January 2005 (regardless of whether I space the en-dash or leave it unspaced) in Annalisa Crannell. This is the publication date of one of the references, as given to me by JSTOR. How am I supposed to write this date? As far as I can tell from MOS:DATERANGE this format (at least with the spaced dashes) is supposed to be valid. —David Eppstein (talk) 22:23, 15 February 2018 (UTC)

{{Cite book |title=Title |date=December 2004 – January 2005}} → Title. December 2004 – January 2005.

This works correctly, right?

—Trappist the monk (talk) 22:42, 15 February 2018 (UTC)

It does now. For some reason it wasn't before. I'm suspicious that my software (Chrome on OS X) is inserting invisible characters when I type an en-dash, as sometimes I see later edits that remove them. Maybe that's what it was? —David Eppstein (talk) 22:49, 15 February 2018 (UTC)

(edit conflict) I have tried December 2004{{snd}}January 2005 and December 2004 – January 2005 with the same error being produced. Emir of Wikipedia (talk) 22:51, 15 February 2018 (UTC)

Correct usage of dead URL?

In the past I used the dead-url parameter (I think) to indicate that the URL for the citation no longer worked, and someone needed to look at it, i.e. find an archived version or a new version of the page. However, from reading the documentation and using it again now, it looks like this is no longer the intended usage of dead-url. It doesn't show up anywhere, there is no hidden category, etc. What is the correct usage of dead-url and what parameter can I use to indicate dead links? Or should it be in a separate {{dead link}} template? —Ynhockey ^(Talk) 12:33, 17 February 2018 (UTC)

I'm pretty sure that the use you describe was never the intended purpose of |dead-url= nor has that functionality ever been implemented. The parameter is ignored except when the cs1|2 template uses both |archive-url= and |archive-date=. There is no cs1|2-specific parameter to indicate that a url is dead so the {{dead link}} template should be used to do that (outside of the cs1|2 template).

—Trappist the monk (talk) 12:55, 17 February 2018 (UTC)

At one time it was a simple yes/no binary parameter, but nowadays has at least two more recognised values, see Help:Citation Style 1#Web archives and Template:Cite web#csdoc_deadurl. --Redrose64 🌹 (talk) 12:59, 17 February 2018 (UTC)

Thank you for this topic. This thread fixed my misunderstanding of that parameter too. This is a terribly misleading parameter name. If |dead-url= is intended to be used in conjunction with archived urls, the name should have reflected that to avoid obvious confusion by users. Jason Quinn (talk) 13:58, 17 February 2018 (UTC)

I agree and I think that I have argued elsewhere in these pages that it is a bad name because all other |<name>-url= parameters take urls as their assigned values. I have never gotten sufficient traction to deprecate |dead-url= and replace it with with something more appropriate. This morning I was thinking that |use-archive= might work. Anyone have a better name?

—Trappist the monk (talk) 14:10, 17 February 2018 (UTC)

I have privately supported your suggestion of url-state/url-status before. (Russian Wikipedia allows HTTP codes in the field as well, which might be an interesting addition here, especially for IABot.) --Izno (talk) 15:33, 17 February 2018 (UTC)

Suggest |archive-state= (or |archive-status= or |archive-display=) so that the three |archive-*= arguments are easier to remember and kept together as a set. It's also more clear referring to the state of the archive, and not the url, which is the main source of confusion. Should the archive come first or second in display is the underlying question. -- GreenC 19:46, 17 February 2018 (UTC)

Any of those would be preferable and it'd be splitting hairs to chose among them. I have a slight preference for |archive-display= among the three. In each case the association is much clearer. The problem with |dead-url= is that it looks self-explanatory (seeming to answer the question "does the url work?") but it is not. Jason Quinn (talk) 02:26, 18 February 2018 (UTC)

Previous conversations:

Help talk:Citation Style 1/Archive 11#Suppressing unnecessary archive-urls

Help talk:Citation Style 1/Archive 19#deprecate |dead-url=?

I don't think that the issue is the state of the archive but rather it's the state of the url which can be: live, dead, unfit, usurped, or unknown. This suggests that the parameter name must refer to the url somehow so parameter names like |url-state= or |url-status= (credit an IP editor for those names, not me) should be preferred over an |archive-*= name.

|dead-url= accepts yes, true, y, no, unfit, usurped, bot: unknown. If we shift to use |url-state=, then the accepted parameter values become: dead, live (the default), unfit, usurped, bot: unknown.

—Trappist the monk (talk) 12:56, 18 February 2018 (UTC)

The only problem is the same confusion factor comes into play. I don't see |url-state=dead as being more clear than |dead-url=yes in terms of clearing up the confusion what the argument is meant for. -- GreenC 19:56, 18 February 2018 (UTC)

So give us a better name. Here's another: |url-is= (dead, live, ...) Got anything better?

—Trappist the monk (talk) 14:34, 19 February 2018 (UTC)

I don't have a better name using "url" because the focus is on the url, and that will always lead to the same confusion (eg. "url is dead, marking it so"). When the focus is on the archiveurl it's more clear. I understand this leads to conceptual problems related to option-switches, they can be modified: |archive-disp=url-unfit, |archive-disp=url-dead, |archive-disp=url-live etc.. or drop the "url" part altogether. What the option-switches do is described in the docs, but the argument name makes it clear it is mainly being used for archive display, what most people use it for. -- GreenC 17:03, 19 February 2018 (UTC)

Also this kind of change will break a lot of third party tools that work on citations. In my experience how quickly and easily those tools get fixed (if at all) is an open question. I'm of the opinion keep it the same because it's not a huge problem if a stray |deadurl= gets added - my bot WaybackMedic removes strays, and Cyberpower678's IABot marks links dead regardless. -- GreenC 19:55, 17 February 2018 (UTC)

Certainly an abrupt change will break iabot and wayback medic but we don't do abrupt here. |dead-url= would be deprecated when the new parameter is implemented, and the two would operate in parallel (but not simultaneously) through the transition period – which could be quite long. A bot task could be developed to convert existing |dead-url= to the new parameter (iabot and wayback medic might implement that as well). At some point in the future when the count of articles using |dead-url= drops below an acceptable number, support for it is removed. This is, more-or-less, how we handle all deprecated parameters (which all have had the possibility of breaking external tools).

—Trappist the monk (talk) 12:56, 18 February 2018 (UTC)

I wasn't thinking too much of Medic and IABot as we are pretty responsive to changes but there are many other tools including proprietary ones from research institutions etc. Also, what would you think about keeping the argument as-is, and IABOt and/or Medic then act upon it when they see a |dead-url= with a missing or empty |archive-url=. They could assume the url is dead act accordingly (add an archive) - probably a safe bet in most cases since how else would a stray |deadurl= with a "yes" value get added unless a human thought the URL was dead. -- GreenC 19:56, 18 February 2018 (UTC)

I don't think that it is our responsibility to limit what we do here because of some external tool's dependency unless we have specifically committed to support that tool (as we have done for the metadata). It is entirely possible that we have no knowledge of these many other tools ... so it is the tool maintainers' responsibility to keep up with us and to join in these conversations to say why we should or should not do what we propose to do.

—Trappist the monk (talk) 14:34, 19 February 2018 (UTC)

Ok well the offer is still open to automate fixing this particular problem (stray |dead-url=) which I don't think is too common. I haven't been logging this, but just added logs so the next time it runs it will record how common it is within a set of articles (probably 100k to 200k articles will get processed). Granted, bot maintenance is not ideal as long-term is not guaranteed. -- GreenC 17:03, 19 February 2018 (UTC)

more language tweaks

There is an ISO 639-2/-3 code for Montenegrin language: cnr. This code is not, at present, supported by MediaWiki:

{{#language:cnr|en}} → Montenegrin

the above should return the language name.

I have tweaked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox so that cs1|2 do the right thing when |language=cnr and when |language=Montenegrin:

Cite book comparison

Wikitext	{{cite book|language=cnr|title=Title}}
Live	Title (in Montenegrin).
Sandbox	Title (in Montenegrin).

Cite book comparison

Wikitext	{{cite book|language=Montenegrin|title=Title}}
Live	Title (in Montenegrin).
Sandbox	Title (in Montenegrin).

Because {{#language:bn|en}} → Bangla, the language endonym (should be the exonym: Bengali), an oversight on my part results in a mismatch between |language=bn and |script-title=bn in that the former categorizes into Category:CS1 Bengali-language sources (bn) but the latter categorizes into Category:CS1 uses Bangla-language script (bn). I have fixed that so that script-titles using Bengali script will categorize into Category:CS1 uses Bengali-language script (bn).

—Trappist the monk (talk) 13:05, 24 February 2018 (UTC)

Cross check year/date with the arxiv/bibcode

This is a follow up to Help talk:Citation Style 1/Archive 16#Cross check date/year with arxiv and bibcode?

I've done a lot of cleanup related to bad arxiv/bibcodes, but a thing that would greatly help is we had some sort of validation / verification that the date is consistent with the date part of identifiers.

For arxiv identifier, the date info is encoded in this format

New style YYMM.#### or YYMM.#### (e.g. arXiv:1301.2341: January 2013, submission #2341)

Old style foobar/YYMM### (e.g. arXiv:alg-geom/9712032: December 1997, submission #032)

Because arxivs are normally preprints, we should have a silent maintenance category Category:CS1: arXiv date mismatch whenever |date= is younger than what you can infer from the arxiv identifier.

For bibcodes, the format is the leading 4 digits refer to the year. Since bibcodes are normally for the version of record, we should have a silent maintenance category Category:CS1: bibcode date mismatch whenever the date doesn't match what you can infer from the bibcode.

This is fine

• Perlmutter, S.; et al. (1 January 1998). "Discovery of a supernova explosion at half the age of the universe". Nature. 391: 51. arXiv:astro-ph/9712212. Bibcode:1998Natur.391...51P. doi:10.1038/34124.

This would throw the bibcode date mismatch error

• Perlmutter, S.; et al. (1 January 2000). "Discovery of a supernova explosion at half the age of the universe". Nature. 391: 51. arXiv:astro-ph/9712212. Bibcode:1998Natur.391...51P. doi:10.1038/34124.

This would throw both the arxiv and bibcode date mismatch errors

• Perlmutter, S.; et al. (1 January 1994). "Discovery of a supernova explosion at half the age of the universe". Nature. 391: 51. arXiv:astro-ph/9712212. Bibcode:1998Natur.391...51P. doi:10.1038/34124.

With a |ignore-date-mismatch=yes to suppress the categories when the mismatch is legit for a variety of reasons. Headbomb {t · c · p · b} 16:14, 24 February 2018 (UTC)

Enable error tracking in draft space

This is a follow up to Help talk:Citation Style 1/Archive 31#Enable error tracking in draft space?

There's no reason why errors shouldn't be flagged and tracked in draft space. It's time to enable this. Headbomb {t · c · p · b} 16:27, 24 February 2018 (UTC)

Consensus was not obvious in that discussion. --Izno (talk) 17:32, 24 February 2018 (UTC)

No one gave any objection save "there would be a lot of errors", which is a rather silly objection given this is one of the main reasons for enabling the reasons tracking, and the initial exclusion was done for no given reason. Headbomb {t · c · p · b} 18:55, 24 February 2018 (UTC)

You entirely mischaracterize my comments there. Please go and review. --Izno (talk) 20:27, 24 February 2018 (UTC)

I've reread them multiple times, and that's still my reading of what you wrote. If that's not what you mean, feel free to clarify. Headbomb {t · c · p · b} 01:27, 25 February 2018 (UTC)

Well, most of the things in draft space generally get deleted in 6 months so it seems a waste to fix them..maybe a separate cat for non-mainspace errors? Galobtter (pingó mió) 19:11, 24 February 2018 (UTC)

But a lot of those are also moved to mainspace, and those aren't a waste. Especially since a lot of the stuff can be fixed relatively mindlessly by bots / AWB. Headbomb {t · c · p · b} 19:13, 24 February 2018 (UTC)

Embedded templates

What is the policy or best practice on embedded templates eg:

|accessdate={{date|2018-01-23}}

The docs say Use of templates within the citation template is discouraged because many of these templates will add extraneous HTML or CSS that will be included raw in the metadata. Is this true for any embedded template? If it generally acceptable to convert things like {{date}} to a plain string when needed? -- GreenC 00:49, 25 February 2018 (UTC)

I don't think {{date}} outputs anything extraneous, but it also says that This template should only be used internally in other templates... Galobtter (pingó mió) 06:17, 25 February 2018 (UTC)

The proscription against using templates in cs1|2 parameters arises because everything that the template emits as its output will end up in the metadata for that parameter (metadata-producing parameters). Consider {{aut}}:

|last={{aut|Green}} → |last='"`UNIQ--templatestyles-00000067-QINU`"'<span class="smallcaps">Green</span> → |last=Green

It is improper to mix presentation with data in the data value of a metadata key/value pair.

You can, if you want, write:

|access-date={{date|2018-01-23}} → |access-date=23 January 2018 → |access-date=23 January 2018

because there is no presentation in the data (|access-date= itself is not part of the metadata but, editors will use that as justification to use other templates in parameters that are made part of the metadata). Isn't it just as easy to write:

| |df=dmy-all

which allows the cs1|2 templates to handle date formatting and presentation?

Also, templates like {{date}} are problematic because, without {{{1}}}, it produces the current date:

{{date}} → 8 June 2024

and that would be wrong.

—Trappist the monk (talk) 11:18, 25 February 2018 (UTC)

Ok that's good info. The reason I posted is embedded templates are very problematic for bots. They are difficult to parse, and difficult to expand. I've seen stuff like this:

|url=http://site.com/path/{{RockStarURL|id=34}}

(imaginary template {{RockStarURL}}). The curly bracket is a reserved character in templates, it should be urlencoded when in a URL, the RFC for urlencoding states there shouldn't be a mix of encoding styles in a URL (the whole purpose of urlcoding to have a unified predictable coding), and it's impossible to expand what the template means without looking at the HTML. So bots either end up breaking them (if they don't have detection first) or skip them. I've written some code to pull embedded templates out of CS1 templates and log them so I can see what's out there and decide what should be done on a template basis. The idea of using |df= instead of {{date}} is a good one for that case. I may post again in the future with questions about specific templates. -- GreenC 15:00, 25 February 2018 (UTC)

I ran a sample of 1000 articles and uncovered this list of embedded templates. Looking at the |url= examples: {{BillboardURLbyName}} says "This template is normally used within citations" which contradicts COINS Metdata. {{Allmusic}} same, but it has a |pure_url= option which may or may not resolve the COINS issue(?) I'm not sure how to proceed. The link rot bots (most bots) are unable to properly deal with templates in the |url= field. CS1 says not to use them. The templates themselves encourage using them in CS1. -- GreenC 17:32, 26 February 2018 (UTC)

I think that you are reading a prohibition into Use of templates within the citation template is discouraged ... and CS1 says not to use them that doesn't actually exist. There is no prohibition.

I know that two of the url templates in your list ({{NHLS url}} and {{NRHP url}}) plus a couple of others not on your list ({{NVR url}}, {{NHC TCR url}}) were written to combat another kind of link rot: wholesale website re-writes that break all existing incoming links. Why do they do that? (yeah, I know, rhetorical question ...). I would guess that {{BillboardURLbyName}} and {{Allmusic}} were written for a similar purpose.

I can imagine that a link-rot-bot might maintain a page in its own user space where it could write the value assigned to |url=, save that page which would cause MediaWiki to render the templates and then fetch the 'url' for doing whatever link-rot-bots do

a template in a page in article space:

{{cite web |title=USS Zumwalt |website=Naval Vessel Register |url={{NVR url|DDG-1000}} |accessdate=1 October 2016}}

extract |url= value

{{NVR url|DDG-1000}}

write that to the private user space page and save; that page now has

{{NVR url|DDG-1000}},http://www.nvr.navy.mil/SHIPDETAILS/SHIPSDETAIL_DDG_1000.HTML

bot uses that url as for its normal link-rot processing

not pretty but it might work

—Trappist the monk (talk) 12:28, 27 February 2018 (UTC)

Ahh discouraged for one reason (COIN data), and would be encouraged for another (link rot) :) .. I guess this would spin wheels to make changes. For parsing, I've followed up here to see what the options might be. -- GreenC 14:57, 27 February 2018 (UTC)

Protected edit request on 25 February 2018

Can you add a parameter such as "trans-quote" so that I can add a translation of a quote from an article that is not in English? A145029 (talk) 05:21, 25 February 2018 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit protected}} template. — JJMC89 (T·C) 06:05, 25 February 2018 (UTC)

This has been discussed before. See Help talk:Citation Style 1/Archive 9#Proposal for trans-quote= parameter. --Izno (talk) 14:02, 25 February 2018 (UTC)

TemplateData

Tracked in Phabricator
Task T101075

Continuing a conversation started at Wikipedia:VisualEditor/Feedback#Archiveurl, archivedate, deadurl fields have gone missing in the Cite web pop-up as it initially appeared to be change in the Visual Editor. @Risker, Salix alba, Jdforrester (WMF), and Xover:

The fields archiveurl, archivedate and deadurl are no longer appearing in the Cite web popup in the Visual Editor. As someone who uses the Visual Editor and pre-emptively archives URLs as I write citations, the loss of these fields is a major annoyance as it takes quite a number of clicks to add those fields back in using the Visual Editor. I have been told that the problem has been created by changes to the Template Data here for the the Cite Web Template. Could we please restore these parameters?

We have a tsunanmi of problems with dead link URLs and pre-emptive archiving is the easiest defence against it. And, while I am experimenting with IAB, I find that it often will not archive links that I can successfully archive myself with Internet Archive. Also IAB does rescuing (a service I don't need for what am doing) and there can be errors in this too, which I don't want to incur.

I write a lot of articles and I use a lot of citations. I use the VE because it more productive for content editing (less so for template work) so I will usually be in VE when I create citations. So significantly adding to the creation of a citation by requiring these three fields to individually added is a signficant time delay. Please change the Template Data back to include these fields by default. Thanks Kerry (talk) 04:57, 26 February 2018 (UTC)

As I wrote at WP:VE/Feedback, this is really an issue with the Visual Editor. It decides which parameters to display by default based on whether that parameter is marked as required or suggested in a template's TemplataData block; but then always inserts the parameters in the generated wikimarkup regardless of whether those parameters were used or not. To fix this, VE either needs to stop inserting suggested parameters in generated markup when they are empty, or it needs a new class of parameters that are "easy to access" but not included by default, or probably both. Or, of course, it could remember each user's favorite params and provide easy access to those, but I don't think VE's current architecture makes that feasible.

Note that right now it's editors who both use VE for new citations, use mainly web citations with {{cite web}}, and like to preemptively archive them (so |dead-url=, |archive-url=, and |archive-date= would get inserted, usually empty, into every single citation). But the problem is the same for any subset of editors with a preference for various fields. For instance, I most often use {{cite book}} and {{cite journal}}, and very often want |doi=, |hdl=, |via=, |ref=, |editor-last=, |editor-first=, |editor-link=, |author-link=, |chapter=, etc. Given the status quo, in order for me to get easy access to these, they would have to be set as suggested and would get inserted into the generated markup of every single citation both created with and edited with VE (VE adds them even when modifying an existing citation, not just when creating a new one). --Xover (talk) 06:35, 26 February 2018 (UTC)

User:Xover, you chose to be bold and make this change to the Template Data without discussion. When you were reverted (not by me), you ignored WP:BRD and reverted back to your version (i.e. edit warring). Please revert to the state before your bold change, then discuss please. The issue I raised is to do with cite web (you should raise your issue about cite book etc separately instead of using it as a distraction here). Citation URLs go dead very frequently, which impacts on key principles like WP:Verifiability which forms part of the five pillars. We are here to build an encyclopedia. You say your objection to their inclusion relates to Visual Editor including empty template fields when values are not supplied for these fields. If so, why aren't you having the conversation at Visual Editor Feedback instead of modifying the template data for one specific set of fields in this particular Template Data? Your objection to these empty fields appears to be that you don't like seeing them (despite there is no actual harm done by them) and they are not visible to the readers whom we serve. I cannot see how your dislike for them justifies working against the interests of people who want to make their web-based citations more persistent through the use of archive URLs. Kerry (talk) 07:21, 26 February 2018 (UTC)

@Kerry Raymond: I would appreciate it if you stop avoid personalising the discussion and casting aspersions. The mere fact of disagreeing with you does not ipso facto constitute edit warring, introducing vicarious arguments to distract from the main issue, not being here to build an encyclopedia, working against our readers, or refusing to get the point; all of which you accuse me of above. Please strike those parts of your message.

And just for the record, I changed the TemplateData back because the revert was made with an invalid rationale: a weak local consensus (made without all relevant information being available) elsewhere does not bear on if or how to change things here. This is fundamentally a problem with the Visual Editor, and should be addressed by changes to VE, but if a consensus forms here to make the parameters in question suggested in {{cite web}} I certainly won't object, and would be happy to make the necessary changes to the TemplateData.

Which, incidentally, means I would very much like the regulars on this page to chime in with their view (even the ones philosophically opposed to VE and TemplateData as currently implemented: broader discussion will contribute to a clearer and stronger consensus and avoid needless disagreements over similar issues in the future). --Xover (talk) 08:07, 26 February 2018 (UTC) [edited to correct clumsy phrasing. --Xover (talk) 10:24, 26 February 2018 (UTC)]

I think that this squabble is a good demonstration that template data, which simultaneously attempts to be "template documentation" (hah!) and a ve control mechanism, does neither well.

If I understand the issue here, Editor Xover's complaint is that "suggested": true in the template data causes ve to insert the associated parameter into the wiki source even when the editor does not provide a value for that parameter so that what source editors see after a ve edit is:

{{cite web |url=//example.com |title=Example |archive-url= |archive-date= |dead-url=}}

If this is the complaint, then I'm fully sympathetic because, to me, adding empty parameters that serve no function (because empty cs1|2 parameters convey no meaning) is just clutter in the wiki source that makes it harder to read.

However, if this is the complaint, this forum is not necessarily the best forum because editors here can do nothing to resolve the underlying problem. All that we can do is serve as a forum to decide if |archive-url=, |archive-date=, and |dead-url= should be marked "suggested": true in the template data. My !vote is no, they should not. Editor Kerry Raymond may diligently and laudably archive web sources but I expect that most others do not.

—Trappist the monk (talk) 11:59, 26 February 2018 (UTC)

• Hmm. Leaving a blank parameter is not a big deal; templates have been doing this for eternity, and in fact in many cases the removal of "suggested" parameters is considered poor form. I would not have an objection to removing the "dead-url" parameter, though, as it would be only very infrequently used when the references are being created. The entire point of "suggesting" the "archive-url;" and "archive-date" parameters is to encourage editors to consider immediate archiving of URLs, which is a good thing. Bots are nowhere as efficient as humans who do the archiving when they have the URL open, and can make the exact match. As I said, I'm okay with dropping the dead-url parameter from the suggested ones, but there is good reason to leave the other two.

  I am very disappointed to see an experienced editor completely ignoring BRD in order to press the advantage in this discussion, though. Risker (talk) 22:23, 26 February 2018 (UTC)

I've created a Phabricator task for this asking that the Visual Editor does not include template parameters which have no value specified.

I can see the two sides, its nice to have clean wikitext, its also nice that the UI encourages good behaviour. Of the two it seems like there is greater net benefit to the encylopedia if use of archive-url is encouraged. --Salix alba (talk): 22:45, 26 February 2018 (UTC)

I highly support removal of blank |archiveurl= and associated parameters for a couple reasons. 1. We have automated systems to deal with WP:link rot, namely IABot (accessible from the history tab "Fix dead links"), a sophisticated system currently in production with support from WMF and Interet Archive. 2. The scale is off the charts, 10s of millions of links on enwiki alone. In the first 15 years of Wikipedia only about 600k archives were added manually and by other bots. In the past 24 months of IABot running, this has increased to over 3 million with 2500-5000 new adds every day. User input is appreciated, but it makes little difference in the end. I would guess manual additions are 1/10th or less of what IABot is doing. And those manual adds are error prone. My bot WaybackMedic has removed or fixed 100s of thousands of bad archive links added by users and old bots. Manual input is appreciated, but we don't need to burden users with doing something that is automated. -- GreenC 00:40, 27 February 2018 (UTC)

@GreenC: Note that the issue of removing blank/empty params is strictly speaking a VE issue (i.e. belongs in the Phab Salix alba linked above and not here). The core issue here is: while VE behaves that way, should cite web's TemplateData mark these parameters as "suggested" leading to empty params being inserted in articles as a side effect; or should the parameters not be marked "suggested", causing inconvenience to those editors who frequently need them in VE's citation template editor. If VE is changed to no longer insert spurious empty parameters even if they are marked "suggested", then the issue here becomes moot. If you have an opinion on the cite web-related issue (including "Don't care", if that is the case), it would be helpful if you could indicate it to aid in determining consensus. --Xover (talk) 18:12, 27 February 2018 (UTC)

"suggested" should be no, to prevent blank entries for archiveurl/archivedate/deadurl. In terms of VE behavior, that's up to VE but it seems reasonable that the configuration is determined via the "suggested" mechanism so the community can decide easily and openly on-site. -- GreenC 18:55, 27 February 2018 (UTC)

Attempted summary (semi-arbitrary break)

Ok, since there appears to be no further editors chiming in, nor any ongoing discussion, I'm going to attempt to summarise. If you were pinged below, please verify and indicate whether I have accurately and fairly reflected your arguments. I've tried to be as neutral (and brief) as possible, but I can't preclude the possibility that I've messed it up (if so, I apologise and will correct as best I'm able). Note also that Risker has not edited since their initial post here and may thus currently be unable to participate (i.e. busy IRL), so please do not rely on my summary of their position until they have had a chance to verify it.

• Kerry Raymond is in favor of marking |dead-url=, |archive-url=, and |archive-date= as suggested in the TemplateData. They point to the inconvenience for editors of having to manually add the parameters under discussion to the Visual Editor's template editing dialog when using the Visual Editor to edit citations. They also point out the significant problem of dead links in citations and the consequent value of preemptive archiving, and that this makes WP:V an applicable policy. They do not consider empty parameters inserted in articles' wikicode to be a problem.
• Xover (me) is against marking them suggested because it causes VE to insert spurious and useless parameters into articles' wikicode, also for editors who do not routinely practice preemptive archiving. They (I) believe this is an issue that should be addressed in VE rather than in TemplateData. They (yes, I) also argue that leaving the parameters optional only negatively affects a relatively small number of editors, while setting them to be suggested would negatively affect both a relatively larger number of editors as well as all articles edited with VE in this manner.
• Trappist the monk is against marking them suggested, and argues that the current disagreement reflects the general problems with TemplateData as a system. They point to useless parameters being inserted into articles and the resultant clutter in articles' wikicode. They further argue that the underlying problem must be addressed in VE, and that leaving the parameters optional affects a relatively small number of editors.
• Risker is in favor of marking them suggested, considering the addition of empty parameters to be "no big deal". They also point out that including them by default has an educational effect by encouraging editors to include archives, and that manual addition by a human editor is more efficient and provides a better match between cited URL and archive than an equivalent bot addition. They also add that |dead-url= does not need to be marked suggested as it is relatively less frequently used.
• Salix alba sees both perspectives on the issue, pointing to clutter in the wikicode on one hand and user interface that encourages good behaviour on the other, but concludes that there will be "greater net benefit to the encylopedia if use of archive-url is encouraged".
• GreenC is against marking them suggested, pointing to clutter in wikimarkup. They further argue that manual addition of archives is both error prone and of relatively little utility given the scope of the link rot problem. They argue that the solution based on IABot and WaybackMedic (etc.) is both more efficient, with a lower error rate, and with less needless burden placed on human editors.

By my assessment this leaves us with no clear policy guidance for either option, and no numerical !vote advantage in either direction. I also see no ongoing discussions that might lead to a consensus, nor any sign that anyone is open to being persuaded by others' arguments. That is, I believe, the very definition of "no consensus".

In light of this, and of a request by one of the participants to that effect elsewhere, I am therefore going to self-revert the removal of the suggested properties for |dead-url=, |archive-url=, and |archive-date= until such time as we make some kind of progress toward a consensus, or until a possible future VE change makes the issue moot. --Xover (talk) 09:50, 3 March 2018 (UTC)

PS. Since several editors expressed various disappointments above, allow me to express one of my own: A willingness to discuss (not just !vote) and to be persuaded is pretty fundamental for a consensus-oriented project. If one merely focusses on one's own immediate goals and how to achieve them, then actual consensus will forever stay elusive. Or put another way, absent a willingness to both discuss and be persuaded, the process devolves to wikilawyering and exploiting (gaming) first-mover advantage and lack of consensus as a "de facto consensus". While actual consensus may always have been impossible to achieve in this specific case (there is genuine and valid disagreement on the issue), I had very much hoped the efforts to achieve it had been more vigorous and constructive. Oh well. --Xover (talk) 10:07, 3 March 2018 (UTC)

I think it is difficult to achieve consensus when we discuss the problem and the solution as a single issue. The root problem was the presence of unused parameters visible to source editor users, which is an issue of how VE renders source text and affects many templates. The proposed solution was to change just one template in a way that adversely affected VE users who were not leaving those particular fields empty. My objection was to the proposed solution. I have no objection to a solution that directly address the problem in the VE's rendering and I think your proposal of a new "type" of field might be such a solution. I suspect that the VE may be constrained to behave as it currently does because [3] appears to say that a template can interpret the absence of a field differently to the presence of that field without a value. If so, the VE should not suppress fields without values. I can't think of an example of a template that actually does behave differently in those circumstances, but templates would appear to be allowed to do so. If that possibility was to be ruled out (that is, a template should not behave differently in those circumstances), the VE could safely omit the fields without values. But I think the question has to be put to the VE developers. Kerry (talk) 06:38, 5 March 2018 (UTC)

@Kerry Raymond: Thanks for responding, and for your cogent analysis of the situation. Provided I've understood you correctly, we appear to be in agreement on both the underlying problem and the proper long term fix for it. And thus the only place we disagree is in the relative weighting of the downsides of the two possible status quos until a permanent fix is implemented. But in any case, since there is an absense of a consensus either way, the previous status quo (i.e. the one that coincides with your preference AIUI) stands until a consensus emerges. In the mean time, the Phabricator link at the top of the section is to a task tracking the request to the VE developers to address this. --Xover (talk) 08:48, 6 March 2018 (UTC)

Cite Arxiv should support DOI

Some arXiv's have DOI's too. AManWithNoPlan (talk) 01:58, 28 February 2018 (UTC)

If it has a doi, use {{cite journal}} or {{cite paper}}. {{cite arxiv}} is for citing the preprints/non-official version specifically.Headbomb {t · c · p · b} 02:02, 28 February 2018 (UTC)

And just to clarify/build on what Headbomb said, arXiv preprints don't have dois. The dois you see on arXiv will direct you to the version of record which has been published. If it has been published you shoudn't use {{cite arxiv}}. You can, however, use |arxiv= to provide a convenience arXiv link to the reader while using {{cite journal}}. Umimmak (talk) 06:01, 28 February 2018 (UTC)

Protected edit request on 2 March 2018

Hello.

The template {{Cite press release}} is nominated for being merged into the {{Cite news}} template.

Please add:

{{subst:tfm|type=tiny|Cite news}}

... to the top of Template:Cite press release, and ...

{{subst:tfm|type=tiny|Cite press release|heading=Template:Cite press release}}

... to the top of Template:Cite news.

Of course, because of situational syntax, I need to preview the edits to find out if the request above is aboslutely okay, but I cannot. So, please preview for me.

Best regards,
Codename Lisa (talk) 09:11, 2 March 2018 (UTC)

In this case, it should probably be noincluded (atleast and definitely for cite news - seems like that generally happens after someone complains about it) Galobtter (pingó mió) 09:14, 2 March 2018 (UTC)

I've added the notices and noincluded them on "cite news" but not on "cite press release" with the understanding that while "cite news" is unlikely to change much people who used "cite press release" in articles may be interested in knowing that it's under discussion. Jo-Jo Eumerus (talk, contributions) 10:03, 2 March 2018 (UTC)

@Jo-Jo Eumerus: the merge proposal has been withdrawn. Can you or another admin remove the notice? Thanks, Pi.1415926535 (talk) 18:45, 3 March 2018 (UTC)

Removed from both. Jo-Jo Eumerus (talk, contributions) 19:19, 3 March 2018 (UTC)

Purpose of Cite web

Codename Lisa and I have been discussing the use of {{cite web}} on Lisa's talk page after my edit and its subsequent reversion. This centers on a contradiction between {{Cite web}}'s template documentation, which states: "This Citation Style 1 template is used to create citations for web sources that are not characterized by another CS1 template," and a template summarizing general CS1 use, which states "{{Cite web}} [is used for] any resource accessible through a URL". I think my original edit is valid for consistent documentation, but this depends on the community's consensus on the use of {{Cite web}}. --E to the Pi times i (talk) 15:04, 4 March 2018 (UTC)

I believe cite web should be limited to sources that are not described by one of the other CS1 templates. If one of the other templates is suitable, it probably means the source is available both on the web and in another form (paper, microfilm, DVD, etc.). Cite web does not have the parameters needed to clearly identify the non-web form of the source (and the exact location within the source), which will make it difficult to find the source if the reader prefers not to use the web, or if the website goes dead. Jc3s5h (talk) 15:31, 4 March 2018 (UTC)

Editors can use whatever template, or none, that they choose; but in terms of intended use, {{cite web}} is a more generic fallback when no more specific template is available that produces the desired result. However, in terms of your discussion, I see a lot off assertions about requirements at FAC and no links to back up those assertions. FAC requires consistent formatting of references, but that means consistently using the same citation template for all citations of a given category; not that all citations have too look exactly the same regardless of type. For instance, if you mix use of {{cite news}} and {{cite web}} for online news sites you should expect to get dinged for it. Choosing one and sticking to it fulfills the consistency requirement. Of course, I really don't recommend using {{cite web}} for books and journal articles just because they're available online somewhere. --Xover (talk) 15:36, 4 March 2018 (UTC)

FWIW, the lead on the cite web documentation was changed to its current form on 27 November 2012. I looked in this talk page's archives for a discussion, and I found this possibly relevant note, with no responses. – Jonesey95 (talk) 16:02, 4 March 2018 (UTC)

Hello, everyone

You know the policy here: What contributors actually do, unless contested, is taken to have consensus. Well, here is what contributors actually use:

Transclusion count for citation templates

Template	Count
{{Cite web}}	2,769,486
{{Cite book}}	954,539
{{Cite news}}	839,585
{{Cite journal}}	498,386
{{Cite encyclopedia}}	95,337
{{Cite magazine}}	45,908
{{Cite press release}}	33,297
{{Cite map}}	24,485
{{Cite AV media}}	21,142
{{Cite AV media notes}}	13,772
{{Cite episode}}	12,398
{{Cite report}}	10,164
{{Cite conference}}	8,458
{{Cite thesis}}	6,464
{{Cite interview}}	3,544
{{Cite arXiv}}	2,146
{{Cite podcast}}	1,095
{{Cite techreport}}	829
{{Cite speech}}	707
{{Cite mailing list}}	547
{{Cite newsgroup}}	545
{{Cite sign}}	374
{{Cite serial}}	259
{{Cite bioRxiv}}	159

As you can see our contributors are using {{Cite web}} vastly greater than any other template. Clearly, this is not their last resort; it is used 2.9× that of the second most popular entry, {{Cite book}}.

As for the intended use, it was a bad idea that failed. CS2 style has no more than three templates. ({{Citation}}, which can also generate CS1 refs, and two others that I don't remember.) CS1 has 24 templates (not counting {{Citation}} and the ) that are almost identical, to the point that their nuances only serve to irritate instead of helping.

If it was me, I'd merge them all into one {{Cite CS1}}. (Or into {{Citation}}.) Or maybe just deprecate the current 24 in favor of {{Citation}}.

Best regards,
Codename Lisa (talk) 20:48, 4 March 2018 (UTC)

The statistics are not useful, because they do not indicate how many of the cite web instances are only available on the web, versus how many of those instances could have used one of the other templates. Also, edits that display an ignorance of how to create anything that even vaguely resembles a good citation dominate, but that doesn't mean we should give all citations the heave-ho. We should not use templates that hid information about the not-web version of a source.

As for CS2, that is off-topic. You could, of course, create a proposal that we campaign to make CS2 preferred over CS1; I personally would support that (although CS1 would have to be held in reserve for the rare cases that CS2 can't decipher). But that's a different discussion. Jc3s5h (talk) 21:07, 4 March 2018 (UTC)

"they do not indicate how many of the cite web instances are only available on the web, versus how many of those instances could have used one of the other templates." Why do you care? Do you have a paying job to see other templates flourish? Or are those templates objects of worship? They way I see it, they are failed utility items that could not justify themselves to be adopted.

Also, the fact remains that the majority uses {{Cite web}}. As long as it is true, writing otherwise is unwarranted.

Update: Wait. Actually, I do know how many percent of {{Cite web}} templates can be replaced with something else. 100%! {{Cite news}} is a superset of {{Cite web}}, and its output is identical. Don't you see that we have nothing but redundancy here?

—Codename Lisa (talk) 21:16, 4 March 2018 (UTC)

Because as Jc3s5h writes above Cite web does not have the parameters needed to clearly identify the non-web form of the source (and the exact location within the source), which will make it difficult to find the source if the reader prefers not to use the web, or if the website goes dead. I've seen a lot of people use {{Cite web}} but they put in something like a JSTOR link there saying |work=JSTOR -- the {{Cite journal}} (with |jstor=) is much more appropriate, provides more information, and allows the reader to see all the relevant information. People use {{Cite web}} because they think any source with a URL is appropriate there and it's conveniently located first on the drop-down citation menu. Umimmak (talk) 21:24, 4 March 2018 (UTC)

Oh, I do agree with that. People indeed make this mistake. But I also see three more things:

1. Over the course of 15 years, proponents of the lots-of-templates approach failed to persuade them to do otherwise. Clearly, continuing that mistake is no warranted. The same mentality that caused the problem cannot solve it.
2. Putting aside all mistakes, 24 templates are still too much. There is much redundancy here, to the extent that we are using a single module to implement all these 24. We can have one template to rule them all.
3. I see that you guys are not sympathetic to the mistakes of the totally uneducated. I also see that neither of you guys have any WP:FA articles on record and are therefore totally unsympathetic to the plight of the experts who need consistent citation styles. So, what's your purpose here at all?

—Codename Lisa (talk) 21:35, 4 March 2018 (UTC)

I don't know what you mean by my not sympathetic to the mistakes of the totally uneducated -- having clearer documentation for {{Cite web}} such as saying it's not for any source that has an associated URL makes it clearer for newcomers. And for the record I have written a FA (although I'm sure that doesn't change your opinion), and do understand the desire to have consistent referencing, What's as important, though, is thorough citations -- with all of the relevant information in them to allow the reader to access the source -- the different citation templates can be useful as they allow for/prompt an editor user to include all the relevant parameters. Saying {{Cite web}} is for any resource accessible through a URL means people will chose this template when another template would better allow/guide the editor to include information for all the relevant parameters. Umimmak (talk) 22:03, 4 March 2018 (UTC)

(edit conflict)Category:Citation Style 2 templates only includes {{Citation}}, so that is off topic with regards to {{Cite news}} and {{Cite web}}. The documentation at Template:Cite news in the section "Choosing between {{Cite web}} and {{Cite news}}" explains that cite news has the ability to accept offline news which is pretty obvious but also to use |issue= and |volume= parameters. If those two features are not in use then it is better to use cite web as it shorter than cite news by a character, and every character adds up. Emir of Wikipedia (talk) 21:28, 4 March 2018 (UTC)

To answer User:Codename Lisa's question about whether I see the difference between cite web and cite news, it is conveniently provided in the cite web documentation:

• {{Cite news}} accepts |issue= and |volume= parameters while {{Cite web}} does not (See Help talk:Citation Style 1/Archive 10 § |volume=, |issue=, |page(s)= and cite magazine.)

So every instance of cite web could be replaced with cite news. But that would go against the principle that the name of the template is a description of the source. There are (or were) plenty of names that are/were just redirects to another template that supports the same parameters and formats the results exactly the same way. But the fact remains that there is no one template in the CS1 family that supports all the information that could be useful for a source that is available on both the web and another form. Jc3s5h (talk) 21:37, 4 March 2018 (UTC)

Well, I am sure I need not give you the obvious answer. This certain line of inquiry seems to have runs its course and proven inconsequential. The fact is: The consensus is to use {{Cite web}} as the first resort, not the last resort.

—Codename Lisa (talk) 21:46, 4 March 2018 (UTC)

My purpose is to prevent the suppression of useful information by folks who are more concerned with pretty citations than actually being able to look up the information that the citation is supposed to provide a path to. Jc3s5h (talk) 21:51, 4 March 2018 (UTC)

• Both versions show the same information except in the two small exceptions mentioned above, one of which would result in cite web not being used for that source anyway. No information is being suppressed and the citations look equally "pretty". Emir of Wikipedia (talk) 22:02, 4 March 2018 (UTC)

Emir of Wikipedia:The dispute is not between cite web and cite news. The dispute is between the two versions of illustrated by this edit and the edits that follow. The dispute applies just as much to cite book, cite journal, cite video, as to cite news. Even if a way could be found to manipulate all the parameters in those other templates into cite news, the differences in how the documentation describes them would make it very difficult for an editor to figure out how to use cite news to do a complicated book citation, and just as hard for later editors to figure out what had been done. Jc3s5h (talk) 22:13, 4 March 2018 (UTC)

• (edit conflict)I respect that.

I myself have tried to do that; I spent a lot of time and energy teaching people to use |work= and |publisher= correctly. Even I made User:Codename Lisa/Websites and their publishers.

And yet, your method does not serve your purpose, as it ignores status quo and WP:FAC requirements. Hence, what you do resembles fighting a river.

You must come up with a recommendation that demonstrates its own merit. Why not write the truth? {{Cite web}} the simplest of all, has the least specialized metadata fields and can only be used for sources that have a URL. So, write that!

Think about it. The greatest moment of everyone's life is the moment of positive thinking. FleetCommand used to say that.

Best regards,
Codename Lisa (talk) 22:08, 4 March 2018 (UTC)

Since the passage is meant to be a short summary, how about "Web sources (but if available in other media, consider other CS1 templates)"? Jc3s5h (talk) 22:21, 4 March 2018 (UTC)

I agree with the general principle that, if you are using the cite X templates, you should use the most specific one that accurately describes your source. Cite web is far overused, and I also see a lot of incorrect cite journal templates that should really be cite book or cite conference. Or, if you insist on having a single catch-all template for Citation Style 1, the only reasonable choice is {{citation | mode=cs1}}. —David Eppstein (talk) 22:49, 4 March 2018 (UTC)

I won't read the whole thing, because it's rather pointless to do so, but as Jc3s5h and David Eppstein have correctly pointed out, {{cite web}} is a generic template to cite online sources when you have nothing more specific to do so. FAC does not mandate the use of the same citation template, only the use of the same citation style. Headbomb {t · c · p · b} 23:04, 4 March 2018 (UTC)

If you won't read the whole discussion, then you have no right to revert to the contested diff either. If you had read it, you'd understood that everyone here agrees with David Eppstein. Our concern is additional complications.

Actually, I seem to have been overly polite so far, letting some of you people insult the rest of Wikipedians without proving that you actually know better, and we are talking 2.7 million articles. Before trying to regulate someone's business you must understand that business.

—Codename Lisa (talk) 06:58, 5 March 2018 (UTC)

There are no 'additional complications', and there are no insults anywhere, from anyone. Headbomb {t · c · p · b} 12:11, 5 March 2018 (UTC)

I have reverted {{Citation Style documentation/cs1}} back to the version as it existed prior E to the Pi times i's initial edit and protected the template for a week's time. This discussion is the place to settle the content dispute.

—Trappist the monk (talk) 10:52, 5 March 2018 (UTC)

So far, everyone is for "web sources not covered by the above" but Codename Lisa, whose 'compromise' version is "web sources only (too generic, consider other templates)" which doesn't differ in substance to "web sources not covered by the above". That looks like consensus to me. Headbomb {t · c · p · b} 12:09, 5 March 2018 (UTC)

I prefer that the description match that given by the template's documentation, which has been stable for over five years. Given that the two descriptions immediately above are functionally equivalent, I prefer the former one, since it is more concise and more closely matches the template's documentation. – Jonesey95 (talk) 15:25, 5 March 2018 (UTC)

I agree with Jonesey95. While some of the previous discussion has focused on how editors are using {{Cite web}}, this is a recommendation which attempts to make sources maximally retrievable and maximally consistent (Like Umimmak's example: I've seen a lot of people use {{Cite web}}... [where] the {{Cite journal}} (with |jstor=) is much more appropriate.) We're not insulting how editors use {{Cite web}}; we're simply trying to create recommendations which will encourage the use of high quality citations. --E to the Pi times i (talk) (contribs) 18:02, 5 March 2018 (UTC)

I've been to busy to follow all this, but would like to know what the emerging consensus might be. Would someone care to summarize it? ~ J. Johnson (JJ) (talk) 22:54, 5 March 2018 (UTC)

Sure, I can summarize it. Just give me a moment. (I'm posting before the actual summary because I don't want to make waste the time of myself or others by composing a summary when others may be doing the same thing.) --E to the Pi times i (talk) (contribs) 23:33, 5 March 2018 (UTC)

Summary (00:37, 6 March 2018 (UTC)):

by E to the Pi times i (talk) (contribs)

If I misrepresented your views, please tell me and I will correct it.

The discussion is over how to summarize {{Cite web}}'s usage on Template:Citation Style documentation/cs1.

Xover, Jc3s5h, Umimmak, David Eppstein, Jonesey95, Headbomb and myself all agree that {{Cite web}}'s recommended use should be when the source type is not covered by other CS1 templates. This is mainly because cite web is missing specialized fields which allow more information to be included about more specific sources hosted on websites. This use requires clearer documentation which guides editors to use the most appropriate template for the type of source they are citing. Headbomb has suggested this phrasing: "web sources not covered by the above", which Jonesey95 and myself think is functionally identical to Lisa's phrasing (below), but more concise.

Codename Lisa has said that this change violates consensus, because most uses of cite web are for sources covered by other CS1 templates. Lisa has also said that the number of citation templates is too high, creating redundancy, which is why {{Cite web}} is used in lieu of more specific templates. Lisa has proposed the following compromise phrasing: "web sources only (too generic, consider other templates)"

Purpose of Cite web – continuation

I thank 'E to the Pi times i' for the summary.

I agree with E^Pii's statement on Lisa's talk page here, at 15:05, 4 March that editors are using {cite web} because they lack awareness of other templates (or the fine points of citaiton), "not because they think it's a superior or more appropriate template." Also, that "inconsistencies can still accumulate on a mass scale without them being correct."

Agree with Jc3s5h (15:31, 4 Mar) that "cite web should be limited to sources that are not described by one of the other CS1 templates." And again (21:07), that though "edits that display an ignorance of how to create anything that even vaguely resembles a good citation dominate", such numbers indicate only the extent of ignorance, not any weight of superior authority. I strongly disagree with Lisa's view (21:16) that "majority use" requires we must teach the gospel of cite web.

I particularly agree with Umimmak (21:24) that: "People use {{Cite web}} because they think any source with a URL is appropriate there and it's conveniently located first on the drop-down citation menu."

(Part of the problem here is how many editors – especially the newbies – that think merely pointing to some place on the web suffices for purposes of citation. A related discussion.)

I say that Lisa is mistaken to conflate massive usage as representative of good usage, let alone any kind of consensus, where such usage is not the result of any considered or deliberate choice, but results largely from ignorance or carelessness.

As to having too many citation templates: sorry, but I just created two more. These are specialized single-source templates, which probably apply only to a mere thousand or so articles. But using them saves scores (possibly hundreds) of editors from the perplexity of trying to figure out how to write a suitable citation, let alone getting everyone to do so in a consistent format. And perhaps get less grabage like this: "Search Results". USDS. Which, by the way, was done with cite web, error and "all" (what little there is). ~ J. Johnson (JJ) (talk) 23:16, 7 March 2018 (UTC)

@Trappist the monk: Would you consider this consensus? Since Codename Lisa hasn't replied, and everyone else agrees, can I change it to "web sources not covered by the above"? E to the Pi times i (talk | contribs) 13:55, 12 March 2018 (UTC)

• I'd say so. Headbomb {t · c · p · b} 13:59, 12 March 2018 (UTC)
• My only interest in this discussion was to stop the disruptive edit-war-like modifications of {{citation Style documentation/cs1}} until such time as you amongst yourselves arrived at consensus.

—Trappist the monk (talk) 14:06, 12 March 2018 (UTC)

• Hello everyone. I didn't reply because I thought Headbomb's comment from 12:09, 5 March 2018 (UTC) has resolved our dispute wholesale. My compromise version even resolves J. Johnson's concern that massive usage is not a representative of good usage. You know what the funny things? I offered two compromises so far, toning down a lot of my concerns in process. You guys, however, are looking for an excuse to not to budge an inch. Consensus involves an effort to incorporate all editors' legitimate concerns, while respecting Wikipedia's policies and guidelines. But I have a feeling that you guys are not factoring my concerns at all. I'll summarize them:

• The description "web sources not covered by the above" is outdated; it predates the introduction of Lua. It is nowadays possible to use {{Cite web}} almost exclusively and at the same time correctly to generate valid citations for entire articles. Bring all the bad examples you want. (And you haven't brought much.) The fault is not inherently with not wanting to use {{Cite web}} as the last resort and is not fixed by that.
• The description "web sources not covered by the above" does alleviate the problamtic examples shown by K. Johnson. As he said, "such usage is not the result of any considered or deliberate choice, but results largely from ignorance or carelessness".
• Using too many different templates in article causes citation style inconsistencies.

—Best regards, Codename Lisa (talk) 15:40, 12 March 2018 (UTC)

Stop edit warring, consensus, as shown above, is for "web sources not covered by the above". If you want to use {{cite web}}, you can, in the sense that it's technically feasible, but using {{cite web}} instead of the more appropriate {{cite journal}} for citing journal articles is not what the documentation should recommend, neither is it best practice, and existing cite webs should be converted to cite journals in those instances. HOWEVER {{cite web}} is still the most appropriate template for general web sources, not the other templates.Headbomb {t · c · p · b} 16:08, 12 March 2018 (UTC)

Your blindly reverted my other changes without so much as verifying them. It appears their merit, or lack thereof, was not your primary concern when you reverted. So, am I edit warring or you?

Your statement about consensus is as fallacious as your edit summaries. Voting is not the equivalent of consensus.

Seems to me the person who needs to chill down a little is not me. —Codename Lisa (talk) 16:30, 12 March 2018 (UTC)

Codename Lisa, please stop making undiscussed changes to Template:Citation Style documentation/cs1. – Jonesey95 (talk) 16:40, 12 March 2018 (UTC)

Sigh. So apparently the disputation is not settled so again reverted to last stable version and protected. Please settle the dispute here wherein you-all arrive at acceptable phrasing rather than waiting for the reestablished page protection to lapse.

—Trappist the monk (talk) 16:41, 12 March 2018 (UTC)

@Trappist the monk: Note that Codename Lisa did not revert the {{Cite web}} phrasing, which was the contested issue. We just need to discuss further changes. Headbomb was trigger-happy in reverting Codename Lisa's edits. E to the Pi times i (talk | contribs) 16:51, 12 March 2018 (UTC)

@Trappist the monk: With all due respect, what the hell is wrong with you? Do you admins no longer see the difference between harassment and dispute? Headbomb was a clearly reverting reflexively. I made three completely different changes today and, at least in two cases he reverted them with edit summaries that were patently false. And you revert plausible changes before protecting the template? I call it administrative power abuse.—Codename Lisa (talk) 17:11, 12 March 2018 (UTC)

@Codename Lisa: Trappist's protection on the page was to prevent what looks like the beginning of another edit war. However, I do not think this protection is warranted either, Trappist the monk. You've made backwards progress by reverting the changes Lisa and I have made. The template is now stable; we will have further discussion on future changes. I'm already drafting a discussion about it. E to the Pi times i (talk | contribs) 17:27, 12 March 2018 (UTC)

Alas, it is not clear to me that agreement of the wording has been reached. You preferred web sources not covered by the above but Editor Codename Lisa objected (writing against it here) and preferred web sources only (too generic, consider other templates). Editor Codename Lisa may have accepted your version; a definitive statement would seem appropriate.

—Trappist the monk (talk) 18:18, 12 March 2018 (UTC)

When the previous protection expired:

1. Editor E to the Pi times i modified the template to read: web sources not covered by the above
2. Editor Codename Lisa disagreed and modified the template to read web sources only (too generic, consider other templates) and also changed the text for {{cite news}}
3. Editor Headbomb disagreed and reverted the template to read: web sources not covered by the above
4. Editor Codename Lisa appears to accept the current wording and reinstates {{cite news}} change: Alright. Moving on to other, better changes, of than ones related to {{Cite web}}
5. Editor Headbomb reverts: press releases are covered by cite press, not cite news
6. Editor Codename Lisa restores and adds text for {{citation}} (two sequential edits): Added {{Citation}} and Damn edit conflict
7. Editor Headbomb reverts: citation is CS2, not CS1)
8. Editor Codename Lisa reverts: Reverted mistake. Yes, {{Citation}} does CS1 too. Please look before reverting.
9. Editor Trappist the monk reverts to last stable version because of content dispute.
10. Editor Trappist the monk protects so that editors here will stop disruptively editing the template and settle their differences here.

Clearly editors here are in dispute with regards to the content of the template. The details of the dispute then should be settled here and not by a series of reverts. If Editor Codename Lisa believes that harassment is the root cause of the dispute, then the issue should be raised in an appropriate forum; perhaps WP:ANI.

—Trappist the monk (talk) 18:18, 12 March 2018 (UTC)

@Trappist the monk: That was true when you made this comment, but see this diff (particularly the edit summary). That is definitive. Lisa is done with the discussion, so there's no reason to keep the template protected on a revision which everyone agreed should be changed (though Lisa did not agree on what the changed wording should be). E to the Pi times i (talk | contribs) 18:49, 12 March 2018 (UTC)

If that is the case then I'll undo the protection.

—Trappist the monk (talk) 22:58, 12 March 2018 (UTC)

@Trappist the monk: I notice you've changed the protection level to a week instead of removing protection. Was that intentional? E to the Pi times i (talk | contribs) 01:44, 13 March 2018 (UTC)

That was yesterday's re-protection now lifted. Please do not edit war that template.

—Trappist the monk (talk) 10:37, 13 March 2018 (UTC)

(edit conflict)@Trappist the monk: A closer examination of your ten-item list shows interesting things. In step 4, I have clearly left an HTML comment that says {{Cite news}} has a special parameter for addressing press releases (you taught me that, so you know it is true), and in step 6, I have clearly wrote {{Citation|mode=cs1}}. Yet, Headbomb ignores them and reverts them anyway, falsely claiming that "press releases are covered by cite press, not cite news" and "citation is CS2, not CS1". Either he didn't check the truth of what I write, as WP:REVERT requires, in which case he is combative and incompetent; or he did check and discovered that I am right, but reverted anyway. In step 9, you endorsed actions done through combativeness and incompetence (or the other worse case that violates a very fundamental policy); "stable version" is a lame excuse for it. Administrators are supposed to foster healthy editing, not bringing the editing to a halt at the cost of fundamental policies.

ANI is where we notify admins. An admin is already attending the matter. (You.) Where I need to go a venue that provides oversight on admins. This venue does not exist. Lamentable.

— Codename Lisa (talk) 19:10, 12 March 2018 (UTC)

Here and at the related discussion, you have expressed opinions that appear to suggest that I might have a dog in this fight and, as a consequence, might be misusing the mop to preferentially direct the outcomes of these discussions. Because of these expressions of distrust, and because you raised the issue of harassment, I suggested WP:ANI so that you might bring these discussions to the attention of other admins.

—Trappist the monk (talk) 22:58, 12 March 2018 (UTC)

• ANI is not a venue; it is an abattoir. I find it the hard way that no admin in Wikipedia has any interest of looking at another decision made by another admin. —Codename Lisa (talk) 08:00, 13 March 2018 (UTC)
• When it's 7 support for one wording, with 1 support for another, with the arguments for the minority wording having both been debunked and lacking support for anyone other than the proposer, that's consensus. Concerning the other changes, the template for press release is {{cite press}}, not {{cite news}}. Those are not 'reflexive changes', simply restoring the status quo because no consensus has been established that press releases should be cited through cite news. I also object to citation been listed as a CS1 template, because it's primary purpose is to be a CS2 template, and the template does not play nice with several types of citation. For instance, putting an arXiv preprint citation in {{citation}} will cause many bots to fill the template incorrectly. But if consensus is to list {{citation}} has a CS1 template, I won't throw a brick in the water. It just needs to be discussed first because the advice we give to editors matter. Headbomb {t · c · p · b} 23:29, 12 March 2018 (UTC)

I was the one who brought the majority discussion first by showing that {{Cite web}} is used 2.9× that of the second most popular entry, {{Cite book}}. You guys dumped the majority discussion out of the window by saying "they majority could be wrong", never proving whether they are.

And now you are back to the majority argument? Clearly, you invoke the argument whenever it suits you and dismiss it whenever it suits you. Merit has never been a concern of yours.

Also, in all those rounds of reverts, neither majority, nor technical accuracy, nor consensus, nor policies, nor guidelines were any of your concern; if anything you betrayed them all, yet you continue to flatter yourself.

—Codename Lisa (talk) 08:00, 13 March 2018 (UTC)

Poor template usage isn't consensus that poor usage is best practice. People use {{cite journal}} to cite books, websites, press releases and so on. That doesn't make {{cite journal}} acceptable for a book citation, or a press release. The reason why {{cite web}} misuse is so prevalent is that editors use is as catch-all thing for stuff with URLs, both out of ignorance, and out of convenience (through things like the wp:RefToolbar which only supports 4 templates (web, news, book, journal... and many people don't bother beyond "i found this on the web, therefore cite web"). Proper citation formatting isn't a skill most people are born with. Even when you tell them how to do it, they'll screw it up unless they've got years of practice with a particular style. Headbomb {t · c · p · b} 12:17, 13 March 2018 (UTC)

@E to the Pi times i: I'll let you make the changes, otherwise Codename Lisa will probably try to claim this is edit warring and take me to ANI, despite having consensus for the "web sources not covered by the above" wording you proposed a few weeks ago. Headbomb {t · c · p · b} 12:55, 13 March 2018 (UTC)

@Headbomb: I will make the changes. For the record, I did not propose the specific phrasing we're discussing now; I simply brought up that the vague phrasing was inadequete, and the proposed phrasing came out of the discussion that followed. E to the Pi times i (talk | contribs) 14:08, 13 March 2018 (UTC)

@Codename Lisa:

To begin with, a majority of editing behavior and a majority of discussion are not equivalent. Editing is bold, while discussion is where the merits and downsides general editing practice are discussed. Here's an example: WP:NPOV. Just because many editors use an impartial tone when they add information to articles doesn't mean we should just stop recommending an impartial tone. This is not a perfect analogy; obviously the importance of NPOV is greater than the contents of a citation template. But the same principle still applies.

I agree that the majority should not solely determine consensus. We have not ignored all of your arguments. We have responded to and supported the reasons why we support a specific recommended use of {{Cite web}} over a more general use. Editors more experienced than I have brought up concerns where Cite web presents disorganized information which could be properly encoded in other templates. One cannot "prove" the majority is wrong. One can simply provide well-reasoned arguments for and against a specific phrasing.

For your view to be respected, you have to continue the discussion. On 7 March, J. Johnson left a reply to my summary, outlining why he also disagreed with your characterization of templates. 5 days later, the protection wore off, and you hadn't replied to his statements. Once you leave the discussion, yes, the decision will revert to the majority.

You are still welcome to continue below, or if you think we are not considering your views, you can begin an RfC. But antagonizing Headbomb by telling him he's "[betrayed] majority, technical accuracy, consensus, policies, and guidelines" is not productive. From what I read of his comment, I saw one questionable sentence concerning how we had "debunked" your arguments ("debunked" is an inaccurate description of how the conversation went, in my opinion), but the rest of the comment explained why he reverted your changes. E to the Pi times i (talk | contribs) 14:08, 13 March 2018 (UTC)

CS1 template diversity/divergence

We need to address the actual issue that Codename Lisa is pointing out (which is larger than the use of {{Cite web}}). In Lisa's last comment, they made the following points (abbreviated, please inform me if I left out an important detail):

1. It is nowadays possible to use {{Cite web}} almost exclusively and at the same time correctly to generate valid citations for entire articles.
2. The description "web sources not covered by the above" does alleviate the problamtic examples... [that result] from ignorance or carelessness..
3. Using too many different templates in article causes citation style inconsistencies.

And my responses to the points:

1. That is true in most cases, but as Jonesey95 pointed out, it's missing parameters for periodicals, so for periodical publications, {{Cite news}} or {{Cite journal}} should be used. We could add periodical parameters to {{Cite web}}, but {{Cite web}} is intended as a template for sources that don't fit other CS1 templates. That is the reason for the phrase change for {{Cite web}}.
2. This is the main reason for the phrase change.
3. You will have to show an example of these inconsistencies. As you've already pointed out, {{Cite web}} has the capacity to imitate other templates to a certain degree. The advantage of using the other templates is they add other parameters which aren't supported by cite web, and are especially named based on the source type to signify what their purpose is.

We could try to advocate combining all the citation styles into {{Citation}}; the only potential problem I can see with that is if there are identically named parameters which diverge in function in different templates. If we merged everything into citation, then we could just adapt what was previously citation templates into citation guidance for different kind of source. But that also sidesteps the issue of the already-existing templates. I guess there could be a bot which goes around and adds |type=cs1 to every template before the change. But if this seems like an optimal course of action, we probably need to have an RfC. E to the Pi times i (talk | contribs) 17:52, 12 March 2018 (UTC)

(Sigh!) I admire your zeal, but sometimes, discussions die and reach a natural end. One must not revive them. I discovered it when an administrator (one of the people whom I used to worship) sided with a person who reverted reflexively. We must not discuss it for a very long time.

Best regards,
Codename Lisa (talk) 18:23, 12 March 2018 (UTC)

Regarding point #3, that "using too many different templates ... causes citation style inconsistencies", I say: not true. Leaving aside Vancouver style and pseudo-Bluebook, the many templates we have for creating full citations sort out into just two "styles": cs1 and cs2. These differ mainly in the use of periods or commas to separate elements, and whether certain elements are quoted, corresponding to what CMS calls "style A" and "style B". The "cite" family of templates default to cs1 style, and the {{citation}} template defaults to cs2. But both can be set to use the other style with |mode=, so it is quite feasible to mix use of "cs1 defaulting" and "cs2 defaulting" templates without any inconsistency in display, provided only that |mode= be set where needed.

As to using different cs1 templates: I suspect Lisa has in mind the inconsistent use of {{cite web}} and {{cite news}} for on-line news sites (for which, as Xover has said, "you should expect to get dinged"). Which is not a matter of "too many different templates". It is one tip of a larger problem: the use of {cite web} for anything found on the web, regardless of the nature and origin of the source.

The underlying issue here is not "too many" or "diversity" of templates, it is the misuse {cite web}. ~ J. Johnson (JJ) (talk) 20:40, 12 March 2018 (UTC)

I'm in full agreement with E to the Pi times i (talk · contribs) and J. Johnson (talk · contribs) here. Headbomb {t · c · p · b} 23:32, 12 March 2018 (UTC)

Late to the discussions, but I'm in substantial agreement with the majority here regarding the wording of the guidance in the documentation. Yes, if anyone manually inserts |type=Press release into {{cite news}} or {{cite web}}, et al., the template will display "(Press release)", but the metadata may not come out right. That's why we have {{cite press release}}.

Someone could also use {{cite web}} to cite an online copy of a map, like this one, but then that editor wouldn't have the ability to note the scale of the map (because {{cite web}} lacks |scale=, and a scale is an important attribute to cite) and that editor would not have the ability to easily cite an on-map location like an |inset= or a map grid |section= or |sections=. But of course, if someone just blindly inserts that URL into a citation tool that can only output {{cite web}}, well it's still better than nothing even if the result is a very malformed citation. (I'd even say that someone using cs2 should use {{cite map}} with |mode=cs2 because {{citation}} doesn't handle the map-specific details. Imzadi 1979 → 02:13, 13 March 2018 (UTC)

Cite chapter number

There seems to be no convenient way within the Cite book template to cite a chapter that is only numbered. chapter=4 yields "4", which doesn't look like a chapter number, instead of Chapter 4. I'm adding the {{rp}} template, which is fine but less tidy. Clean Copy^talk 00:43, 6 March 2018 (UTC)

If {{rp|Chapter4}} works for you, why wouldn't this:

{{cite book |last1=Keneally |first1=Thomas |chapter=Chapter 4 |title=Abraham Lincoln: A Life |date=2002 |publisher=Penguin |isbn=978-0670031757}}

Keneally, Thomas (2002). "Chapter 4". Abraham Lincoln: A Life. Penguin. ISBN 978-0670031757.

—Trappist the monk (talk) 00:51, 6 March 2018 (UTC)

I am probably overly fussy, but the quotation marks annoy me. No citation style would use them for a chapter number. Clean Copy^talk 11:28, 6 March 2018 (UTC)

No citation style would use them for a chapter number. Can you show examples of chapter number handling from published style guides? I don't know that this particular topic has been raised before so if there are published style guides that show numerical chapter headings in a form distinct from alpha chapter headings then we might want to adopt a similar styling.

—Trappist the monk (talk) 19:09, 6 March 2018 (UTC)

The 6th edition of the Publication Manual of the American Psychological Association offers "(Shimamura, 1989, Chapter 3)" as an example of citing a specific chapter (p. 179). I don't have other style manuals at hand, but a citation generator (Zotero) gives "Aspray and Kitcher, History and Philosophy of Modern Mathematics, chap. 4." in Chicago style and "(Aspray and Kitcher, 1988, chap. 4) in Harvard style. I hope these are helpful. Clean Copy^talk 22:55, 7 March 2018 (UTC)

The book by Keneally is the work being cited, and the chapter is a specific location in that book, so |at= seems appropriate:

{{cite book |last1=Keneally |first1=Thomas |title=Abraham Lincoln: A Life |date=2002 |publisher=Penguin |isbn=978-0-670-03175-7 |at=Chapter 4}}

Keneally, Thomas (2002). Abraham Lincoln: A Life. Penguin. Chapter 4. ISBN 978-0-670-03175-7.

Kanguole 12:42, 6 March 2018 (UTC)

I agree; |at= is underused in my experience of citation templates. |contribution=, an alias of |chapter=, works best for titled contributions, including in edited publications.

The only problem with |at= is that although you can use an external link as the value, you can't then include an access date, because this is only accepted without an error when |url= or |contribution-url= are present. @Trappist the monk: I think |at-url= would be useful, which would then allow |access-date=. Peter coxhead (talk) 13:43, 6 March 2018 (UTC)

FWIW, |access-date= is not needed for a book. From the documentation: "Not required for linked documents that do not change. ... Access dates are not required for links to published research papers, published books, ...." – Jonesey95 (talk) 14:02, 6 March 2018 (UTC)

@Jonesey95: the documentation isn't quite complete, in my view. It's not only a question of whether the linked document will change, but whether the link will change. Research papers, chapters in published books, etc. that are available at the author's own web pages, or the web pages of the institutions at which they work, have a habit of disappearing. It's useful to know when the link worked when trying to recover an archived copy. It's different for a paper with a doi, for example. Peter coxhead (talk) 17:49, 6 March 2018 (UTC)

I'm not convinced that use of |at= is appropriate for a chapter title. In this example, the chapter 'title' is just a number (see 'chapter' 2) so we should render this chapter title just like we render chapter titles that are composed of words. The use of |chapter=Chapter 4 in my previous example is an editorial liberty taken for the benefit of those who are reading the rendered citation though I suppose that it could be omitted:

{{cite book |last1=Keneally |first1=Thomas |chapter=2 |title=Abraham Lincoln: A Life |chapter-url=https://books.google.com/books?id=E28G6JSPqz8C&pg=PT12 |date=2002 |publisher=Penguin |isbn=978-0670031757}}

Keneally, Thomas (2002). "2". Abraham Lincoln: A Life. Penguin. ISBN 978-0670031757.

And then there are the metadata issues:

|chapter=Chapter 4 → &rft.atitle=Chapter+4 + &rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DE28G6JSPqz8C%26pg%3DPT12

|at=Chapter 4 → &rft.pages=Chapter+4 (url is not available in the metadata)

—Trappist the monk (talk) 15:39, 6 March 2018 (UTC)

I would not consider "4" to be the title of the chapter; chapters may be numbered and titled, titled only, or numbered only. Here they are numbered but untitled. Clean Copy^talk 18:03, 6 March 2018 (UTC)

We use |chapter= when the work we are referencing is a separately-authored part of a book, but in this case the work is the whole book.

The same thing is seen with the metadata: the OpenURL genre for this source (to assist in finding it in libraries) should be book, not bookitem, so it should have rft.btitle, but not rft.atitle. Kanguole 17:11, 6 March 2018 (UTC)

It's not the only reason |contribution= is used; it's often desirable to link directly to part of an old scanned book with no OCR, for example, using |contribution= and |contribution-url=. Peter coxhead (talk) 17:49, 6 March 2018 (UTC)

I'm not clear on the point you are making here. |contribution= is an alias of |chapter= as long as |contributor= (aliases and enumerations) is not set.

—Trappist the monk (talk) 19:09, 6 March 2018 (UTC)

@Trappist the monk: I was making exactly the point you have below, namely that we don't only use |contribution= or its aliases when it is separately authored, but also when it's useful to specify |contribution-url= or its aliases. Peter coxhead (talk) 18:48, 7 March 2018 (UTC)

Not true. cs1|2 does not constrain the use of |chapter= to referencing ... separately-authored [parts] of a book.

—Trappist the monk (talk) 19:09, 6 March 2018 (UTC)

Short of a new parameter "Chapternumber", there seems no perfect solution. For my purposes, however the "at" parameter appears well-suited. Thank you all! Clean Copy^talk 18:03, 6 March 2018 (UTC)

For the purposes of the reader, "chapter" is an in-source location (the source being the book). Any info to identify this location uniquely and unambiguously would do. How much of such info you use is up to you I guess. A chapter with a unique title and number may be cited with either or both. A chapter without a title could be cited as "ch. [number]" (cf. "p. [number]" when citing a different type of in-source location). A chapter with a title but no number could use just the title. A chapter with neither could be cited as just "Chapter" as long as the pages containing it are also cited with |page=. Or it could be assigned a number depending on its order of appearance or proximity to a significant element in the source, as long as this is expressly stated (eg "chs. 3-5 [not numbered]", or "Chapter [follows map on p. 12]"). 108.182.15.90 (talk) 16:32, 7 March 2018 (UTC)

Chapter=

I've been working on reducing the count at Category:CS1 errors: chapter ignored but I've reached the point where it seems that having both title= and chapter= can be useful to the reader. Can someone explain why having both is automatically bad?--Georgia Army Vet Contribs Talk 22:47, 8 March 2018 (UTC)

Examples of citations that are stumping you would be helpful. I just picked one at random and fixed it; it was very broken and was using |chapter= incorrectly. – Jonesey95 (talk) 22:55, 8 March 2018 (UTC)

Here's another fix. And here's how to fix a cite news citation with section=. It helps to have access to the source document to see what the editor intended to reference. Thanks for fixing these errors! Let us know how we can help you. – Jonesey95 (talk) 23:01, 8 March 2018 (UTC)

Thanks for the response. Here's one (I haven't done all that many) that I fixed earlier today: Dacian Draco. I picked this one because it's heavily referenced and I'm out of my subject-matter depth on these type of articles.--Georgia Army Vet Contribs Talk 02:15, 9 March 2018 (UTC)

@Gaarmyvet: You didn't really "fix" it; you just removed the article's title, which was in |chapter=. The actual way to have fixed it is to put the journal title in |journal= and the article title in |title=. I went ahead and took care of that one, but a lot of your "fixes" it seems just seem to be removing parameters/information instead of retaining the information but making sure they're in the appropriate fields. Umimmak (talk) 02:22, 9 March 2018 (UTC)

I think I should pick another category.<sigh>--Georgia Army Vet Contribs Talk 02:27, 9 March 2018 (UTC)

Gaarmyvet Yeah I've taken a look at some of these pages and they're pretty tricky to fix and turn into complete, accurate, non-buggy citations! Most of them are very broken as Jonesey95 has put it, so one would almost need to check the source itself to confirm what kind of material the source even is and what the |title=, |journal=, |chapter= etc are, since from what I can tell there is often a domino effect of mistakes where multiple parameters are off. I hope my edit summary/past comment wasn't too brusque; I didn't mean to discourage you. Umimmak (talk) 09:43, 13 March 2018 (UTC)

Umimmak, no problem, I went over to ISBNs (interesting glitches there, as well), but I'll be back. Still unanswered, I think, is my question about why having both title= and chapter= is prohibited. Unless having both "breaks" Wikipedia, are we solving a non-existent problem?--Georgia Army Vet Contribs Talk 12:59, 13 March 2018 (UTC)

@Gaarmyvet: the issue isn't having both |title= and |chapter= -- if you're citing a chapter from a book both should be present. The error happens flagged when people use |chapter= with something like {{Cite journal}}. So to pick a random example from the error category (in Bunda people):

{{cite journal |title=Rapport sur les travaux de la mission médicale antitrypanosomique du Kwango-Kasaï 1920-1923|chapter=Le territoire de la Kamtsha-Lubue (district du Kasai) |last=Schwetz |first=J |volume=4 |journal=Annales de la Société Belge de Médecine Tropicale}}

Schwetz, J (1924). "Rapport sur les travaux de la mission médicale antitrypanosomique du Kwango-Kasaï 1920-1923". Annales de la Société Belge de Médecine Tropicale. 4. {{cite journal}}: |chapter= ignored (help)

This was flagged since journal articles aren't expected to have chapters. One way to create a valid citation would be if this were a chapter in a book in a series, that is:

{{cite book |year=1924 |title=Rapport sur les travaux de la mission médicale antitrypanosomique du Kwango-Kasaï 1920-1923 |chapter=Le territoire de la Kamtsha-Lubue (district du Kasai) |last=Schwetz |first=J |volume=4 |series=Annales de la Société Belge de Médecine Tropicale}}

Schwetz, J (1924). "Le territoire de la Kamtsha-Lubue (district du Kasai)". Rapport sur les travaux de la mission médicale antitrypanosomique du Kwango-Kasaï 1920-1923. Annales de la Société Belge de Médecine Tropicale. Vol. 4.

changing {{cite journal}} to {{cite book}} and |journal= to |series=. However I'm hesitant to make the change myself since I don't know if this is accurate for this particular source, and Annales de la Société Belge de Médecine Tropicale looks more like a journal than a book series. Like I said, they can be tricky to fix properly. Umimmak (talk) 13:36, 13 March 2018 (UTC)

Journals (and magazines) can have |department= though; regular and named parts of the journal that are somewhat chapter-like. For instance, in literature related journals, that publish book reviews, "Works received" may be a pseudo-chapter. Or perhaps "Notices". Shakespeare Quarterly separates original articles (a scholar publishing their research, in the department "Essays") from book reviews (someone reviewing a book published by a scholar in the field, in the department "Book Reviews") in this manner. In some instances the distinction may be worth making (i.e. include in our citation).

• Manley, Lawrence (2012). "Divinity and State by David Womersley". Book Reviews. Shakespeare Quarterly. 63 (4). Folger Shakespeare Library: 590–594. eISSN 1538-3555. ISSN 0037-3222. JSTOR 41819772 – via JSTOR. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

Which is, I presume, also why |chapter= is ignored: it's effectively an alias for |department=. --Xover (talk) 13:56, 13 March 2018 (UTC)

Sure, but for this particular example, the "chapter" Le territoire de la Kamtsha-Lubue (district du Kasai) seems to be a subset of the article Rapport sur les travaux de la mission médicale antitrypanosomique du Kwango-Kasaï 1920-1923, and neither is like |department=s "Obituaries", or "Book Reviews" or "Letters to the Editor" or whatever. Umimmak (talk) 14:05, 13 March 2018 (UTC)

I recommend fixing the easy error first, and then asking for help with the hard ones when the easy ones are done. Fixing ISBNs can be done the same way. There are still a lot of easy chapter= fixes left. The "help" text in the error message explains how to fix the easy ones. – Jonesey95 (talk) 14:18, 13 March 2018 (UTC)

Inconsistency in linking title translations

In {{cite book}} (and anything else using the same underlying implementation), when an external link is added to the title of a book, the translation of the title remains unlinked. But when an external link is added to the title of a chapter, the link is also added to the translation of the chapter title. I'm not sure which of these two behaviors is preferable, but shouldn't this be made more consistent?

• {{cite book | title=Book title | trans-title=Translated book title | url=https://book.url | chapter=Chapter title | trans-chapter=Translated chapter title | chapter-url=https://chapter.url}}
• "Chapter title" [Translated chapter title]. Book title [Translated book title].

—David Eppstein (talk) 23:21, 10 March 2018 (UTC)

This conversation did not discuss |trans-chapter= so it did not get changed. Sandbox:

{{cite book/new |title=Title |trans-title=Trans title |url=http://example.com |chapter=Chapter |trans-chapter=Trans chapter |chapter-url=http://example.com}}

"Chapter" [Trans chapter]. Title [Trans title].

—Trappist the monk (talk) 00:14, 11 March 2018 (UTC)

format parameter in Cite AV Media

What does the |format= parameter in {{Cite AV media}} do? The documentation doesn't say (I could check talk page archives, but I didn't particularly feel like digging currently.) E to the Pi times i (talk | contribs) 22:11, 11 March 2018 (UTC)

Never mind, I just need to read more carefully. E to the Pi times i (talk | contribs) 22:15, 11 March 2018 (UTC)

Really?

—Trappist the monk (talk) 22:25, 11 March 2018 (UTC)

You know, one of these days edit conflicts will be correctly detected and reported.

—Trappist the monk (talk) 22:28, 11 March 2018 (UTC)

Manually inserted error categories

While working on Category:CS1 errors: ISBN, I came across the pages below that had no errors but had had the categories (ISBN and one other) manually added to the page. I don't know why that had been done but... once I deleted the manual insertions, the pages dropped out of Category:CS1 errors: ISBN. It strikes that if it happened on those three, it could have happened elsewhere. Are such manual insertions searchable and removable by a bot?

• The pages
  • Defence Act of 2000 (Sweden)
  • Defence Act of 1936 (Sweden)
  • Defence Act of 1925 (Sweden)

--Georgia Army Vet Contribs Talk 23:21, 11 March 2018 (UTC)

It might be reasonable to have a WP:DBR for all pages in a category tagged with {{Maintenance category}}. --Izno (talk) 23:35, 11 March 2018 (UTC)

I suspect that there aren't enough to worry about a bot fix. insource: searches should be adequate. For example this search.

—Trappist the monk (talk) 23:46, 11 March 2018 (UTC)

Illegitimate removal of contents by Headbomb

Hello, everyone

Hello, Headbomb

We all know that illegitimate removal of contents is vandalism. That includes unjustified deletion, deletion under false pretenses and deletion with ex post facto explanation. Headbomb has reverted my good-faith and technically accurate contributions to Template:Citation Style documentation/cs1 with false explanations, especially ones that I went an extra mile to prevent in advance of the reversion. More specifically:

• I added that {{Cite news}} can be used for press releases as well. A HTML comment said that there is a special parameter in it. Headbomb reverted, claiming the opposite: "press releases are covered by cite press, not cite news", which is not true.
• I added {{Citation}}, because its |mode=cs1 enables it to be used for CS1. Headbomb just reverted, claiming the opposite: "citation is CS2, not CS1".

Of course, if he had checked /doc pages, he'd find out that they are not true. (Or there is a possibility that he did check and went the WP:IDHT way?) It is however, customary not to call registered editors "vandals" without giving them a chance to justify themselves. But, in my communication with him in his talk page, he didn't insist on his previous denial and instead resorted to a more questionable approach: "That a template supports something does not mean it is the recommendation for that something." That beckons the question: How did non-recommended stuff that have no consensus made their way into fully protected templates? If they are indeed not recommended, where is the proof?

Alright, Headbomb, I am giving you one last chance to justify your reverts, which as of now, match the description of illegitimate removal of contents (vandalism). You had a lot of chances to justify yourself; but here is another one.

Best regards,
Codename Lisa (talk) 12:34, 13 March 2018 (UTC)

Gain support for your changes or go away. I explained my reverts above, I won't repeat myself because you can't listen. Headbomb {t · c · p · b} 12:36, 13 March 2018 (UTC)

Indeed? A diff please. By the way, if you do go to a fifth RFA, this might come up. —Codename Lisa (talk) 12:37, 13 March 2018 (UTC)

[4] (edit: or [5]), amongst others. I'm now the third or fourth editor to explain this to you. Headbomb {t · c · p · b} 12:39, 13 March 2018 (UTC)

This diff is about the original dispute that I have abandoned. Are you paying any attention? Please study my message carefully. —Codename Lisa (talk) 12:41, 13 March 2018 (UTC)

Ok, in simpler form, because apparently you can't distill the essence of how things work here: gain consensus for your changes. No one here and elsewhere has remotely supported any of the changes you've proposed yet. Headbomb {t · c · p · b} 12:45, 13 March 2018 (UTC)

I case you didn't notice, we are in the venue where people support or oppose. You yourself haven't opposed yet; you reverted, but not opposed.

So, do me a favor and oppose. With a reason of course.

—Codename Lisa (talk) 13:10, 13 March 2018 (UTC)

As has been said before, {{cite news}} and {{cite press release}} are distinct templates; there is not consensus to merge them. Your proposal to merge them was withdrawn and within the discussion there was massive opposition for the merger. Editor Headbomb has opposed; see above; the template for press release is {{cite press}}, not {{cite news}}. [...] no consensus has been established that press releases should be cited through cite news. Restoring a page to the status quo when there is no consensus to make a change is not vandalism. Umimmak (talk) 13:50, 13 March 2018 (UTC)

@Umimmak: This discussion is not about merging anything. Please read the opening post before commenting and refrain from off-topic comments. —Codename Lisa (talk) 14:21, 13 March 2018 (UTC)