Help talk:Citation Style 1

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

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

Contents

Cross check year/date with the arxiv/bibcode[edit]

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

This would throw the bibcode date mismatch error

This would throw both the arxiv and bibcode date mismatch errors

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)

@Trappist the monk and Jonesey95: can you offer any help here? Headbomb {t · c · p · b} 14:35, 22 March 2018 (UTC)
I don't have the coding chops for this work. I think it's a reasonable idea, as long as arXiv and Bibcode IDs all come in a consistent format. I seem to remember some oddball identifiers, but those might have been something other than arXiv and Bibcode.
Parameter names are difficult. |ignore-date-mismatch= is too ambiguous for my taste; the parameter name should indicate what it applies to, ideally, and this one is just for arXiv and Bibcode, not dates in general. See other discussions on this page about the difficulty of naming parameters and the confusion that it causes when editors misinterpret the names. – Jonesey95 (talk) 16:31, 22 March 2018 (UTC)
@Jonesey95: how about |arxiv-date-mismatch=ignore/|bibcode-date-mismatch=ignore? Headbomb {t · c · p · b} 17:22, 26 April 2018 (UTC)
@Trappist the monk: can you help here? Headbomb {t · c · p · b} 13:25, 30 April 2018 (UTC)
@Trappist the monk: can you help here? Headbomb {t · c · p · b} 21:27, 11 June 2018 (UTC)

Markup for named collections[edit]

Sometimes a publishers lists a set of distinct books or manuals under a series name, e.g., IBM Redbooks. The obvious way to mark up citations is something like


but the usage of the version= parameter in {{cite}} is very different from the usage of the word by publishers, and the above example gets an error message:

Alvaro Salla; Patrick Oughton (4 May 2018). ABCs of z/OS System Programming. Redbooks. Volume 10 (Sixth ed.). IBM International Technical Support Organization. SG24-6990-05{{[[Template:cite manual |cite manual ]]| publisher = IBM International Technical Support Organization| series = Redbooks| title = ABCs of z/OS System Programming| volume = Volume 10| id = SG24-6990-05| author1 = Alvaro Salla| author2 = Patrick Oughton| edition = Sixth| date = 4 May 2018| version = 1up}}.  line feed character in |id= at position 75 (help); More than one of |version= and |series= specified (help)

I don't want to arbitrarily concatenate the name of the publisher with the name of the series. Is there a supported way to do this, and if not, would this be something useful to add? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:53, 14 May 2018 (UTC)

I'm not at all sure that I understand your question. In your examples you include |version=1up. Where does that come from? When I looked at ABCs of z/OS System Programming, at the ABCs of z/OS System Programming, and at the Google books facsimile ABCs of z/OS System Programming, I cannot find the text 1up. What am I not understanding?
Trappist the monk (talk) 21:57, 14 May 2018 (UTC)
Just guessing based on the string used here, but back when dinosaurs walked the earth and IBM was a big player, digital texts were often published in multiple variants to account for printing preferences: 1up (single-sided), 2up (print on both sides of the sheet), and variants for paper size like A4 vs. Letter. I haven't actually seen that since the days when actual PostScript files were a plausible option (i.e. pre-PDF), but I can well imagine that IBM might still be doing that from old habit. Perhaps Chatul would like to elaborate on his meaning? --Xover (talk) 05:06, 18 May 2018 (UTC)
It doesn't apply to that particular document, but some manuals on [bitsavers] are available in separate files with one column per page (1up) and two columns per page (2up). I'd like a supported way to indicate that in the {{cite}} tag. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:16, 23 May 2018 (UTC)
Related, working (or not) examples are always appropriate here. If the Redbook examples don't apply, why did you give them as examples? And your bitsavers link doesn't work (http://bitsavers.org/pdf/ibm does). But, I'm not interested in chasing though that list of 120-ish subfolders looking for 1up / 2up examples. If Editor Xover is correct, whether the source is printed 1up or 2up is immaterial. The purpose of the cs1|2 templates is to identify the source for readers; 1up and 2up indicators don't aid a reader in locating a copy of the source.
I'm not sure that I agree with your definition of 1up/2up. Archive.org uses those terms in urls. For example, On the Origin of Species 2up:
https://archive.org/stream/onoriginofspeci00darw#page/n7/mode/2up
and 1up:
https://archive.org/stream/onoriginofspeci00darw#page/n8/mode/1up
Here the terms clearly mean: display 1 page at a time, or display two pages at a time. HathiTrust uses the terms for the same purpose.
Trappist the monk (talk) 16:52, 23 May 2018 (UTC)
I gave it as an example to illustrate what I was trying to do; the Redbooks are a series in the publishing, but not the {{cite}}, sense.
Here are bitsaver examples, but those aren't part of a series.
{{[[Template:cite manual
|cite manual
]]| publisher = IBM
| title = IBM System/360 Reference Data
| id = GX20-1703-9
| edition = Tenth
| series = illustrative only
| version = 1up
| url = http://bitsavers.org/pdf/ibm/360/referenceCard/GX20-1703-9_System360_Reference_Data.pdf
| mode = cs2}}
{{[[Template:cite manual
|cite manual
]]| publisher = IBM
| title = IBM System/360 Reference Data
| id = GX20-1703-9
| edition = Tenth
| series = illustrative only
| version = 1up
| url = http://bitsavers.org/pdf/ibm/360/referenceCard/GX20-1703-9_System360_Reference_Data.pdf
| mode = cs2}}
IBM System/360 Reference Data (PDF), illustrative only (Tenth ed.), IBM, GX20-1703-9  More than one of |version= and |series= specified (help)
IBM System/360 Reference Data (PDF), illustrative only (Tenth ed.), IBM, GX20-1703-9  More than one of |version= and |series= specified (help)
-Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:35, 23 May 2018 (UTC)
I guess I see no significant difference. In these examples, Machine Instructions begins on page 1 and concludes on page 2 so the rendering isn't columnar but is single page vs two pages side-by-side. Pick one as your source and cite that one because the 1up or 2up rendering is immaterial. If there are material differences beyond the simple 1up/2up rendering then, perhaps if it is necessary, cite both in separate cs1|2 templates because then they are two different sources.
Trappist the monk (talk) 00:02, 24 May 2018 (UTC)
To me this information seems more like a different edition than a different series. An edition distinguishes between minor variations of the same book; a series is a named collection of books on similar topics. Editions are normally numbered sequentially but they don't have to be sequential and their descriptors don't have to be numbers. So you could use |edition=Tenth (1up) etc., if you really wanted to distinguish these. —David Eppstein (talk) 00:59, 24 May 2018 (UTC)
New additions have changes in the text. The 1up and 2up documents have identical text. It's more analogous to the difference between a hardbound and a softbound printing of the same edition. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:22, 25 May 2018 (UTC)
@Chatul: In publishing and bibliography, the difference between the "hardback", "paperback" and "ebook" is usually termed an "edition". An edition may have multiple print runs, between which there is usually presumed to be no differences, and no need to differentiate between runs. The term "edition" also covers translations (e.g. "the French edition") and other substantial changes (e.g. "this updated edition has a new foreword by the author, and substantial rewrites to chapter X, Y, and Z"). I agree with David, above, that differences like one column vs. multi column layout, and 1up vs. 2up print layout, and similar do most naturally fit the "edition" concept. Note that the purpose of the citation is to enable verification: so long as it lets the reader locate the relevant information, the citation has no need of endless bibliographic detail. If your "1up" and "2up" variants both have information X on page Y there is no need to specify which edition it is. If the citation includes a link to the specific file that contains the information there is even less need. In other words, I think you're overthinking this. --Xover (talk) 07:38, 26 May 2018 (UTC)
They might plausibly have different pagination, though, in which case the edition would be important to allow readers to find the right page. —David Eppstein (talk) 07:48, 26 May 2018 (UTC)
I've never seen a case where the edition number wasn't the same in the hardbound and paperback version of the same text. I could use {{cite book | title = foo| edition = pb 10th}} to produce foo (pb 10th ed.). , but it seems unnatural. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:34, 29 May 2018 (UTC)
@Chatul: Inside the physical book (or the specific digital file) there is no need to specify hardback/paperback/etc. with the edition number, since that's implicit in context. However, I believe, at least with traditional books, the colophon will usually specify such things (along with the numbered print run of the same edition), just not alongside the edition number. In any case, you can think of the overall citation as referring to an abstract work, and |edition= specifying which particular edition of that work is referenced. --Xover (talk) 08:10, 30 May 2018 (UTC)

Template wrapper for book chapters[edit]

Just FYI that Template:Cite chapter was created by User:Mvolz (WMF). She thinks it would help produce cleaner, more specific citations by the mw:citoid service. Whatamidoing (WMF) (talk) 16:48, 18 May 2018 (UTC)

This does not seem like a good solution to me – if I understand the problem. This 'solution' would seem to suggest that every one of the various language wikipedias that use ve and citoid would need to have this template as a host for a special fork of the {{cite book}} templatedata to 'fix' a problem that exists elsewhere. There are two changes in the {{cite chapter}} templatedata fork:
cite book cite chapter
"description": "This template formats a citation to a book using the provided bibliographic information (such as author and title) as well as various formatting options.", "description": "This template formats a citation to a book chapter, or other type of book section",
"citoid": {
	"edition": "edition",
	"title": "title",
	"bookTitle": "title",
	...
"citoid": {
	"edition": "edition",
	"title": "chapter",
	"bookTitle": "title",
	...
While {{cite chapter}} is still unused, it should be deleted or, at the very least, prominently marked as experimental, and the problem fix where it is broken.
Trappist the monk (talk) 19:24, 18 May 2018 (UTC)
Okay - I think it will work just to switch it over from Cite book to Citation instead. Mvolz (WMF) (talk) 11:10, 7 June 2018 (UTC)
@Mvolz (WMF): As we discussed with RexxS (talk · contribs) on 20 May, there is no need for this template: you can use {{cite encyclopedia}}. If the word "encyclopedia" is a problem, you can always use one of its redirects, such as {{cite contribution}}. --Redrose64 🌹 (talk) 11:29, 7 June 2018 (UTC)
@Redrose64: - Yes, credit where credit is due :). I opted to do Citation instead of the Cite encyclopedia because as you say, the name is a bit off, but you can invoke the encyclopedia citation style by using the 'encyclopedia' parameter from Template:Citation as well and I think that solves that issue nicely. Mvolz (WMF) (talk) 11:35, 7 June 2018 (UTC)

Script-title with URL[edit]

Specifying a title via script-title results in the link being placed as a [1] in front of the title. Is this the desired behaviour? I'm not sure if it's just my memory, but I don't recall seeing this before. --Paul_012 (talk) 09:38, 22 May 2018 (UTC)

See this discussion.
Trappist the monk (talk) 09:52, 22 May 2018 (UTC)
If you put a romanized title in |title= (which corresponds to the recommendation of style guides), then the link will be attached to that. Kanguole 10:25, 22 May 2018 (UTC)
Ah, I see. Thanks for the explanation. --Paul_012 (talk) 13:08, 22 May 2018 (UTC)

Tidy has been replaced with Remex so this problem should now be 'fixed'. Article pages may require a purge or null edit to restore correct rendering.

Trappist the monk (talk) 14:19, 5 July 2018 (UTC)

"Redundant" doi with JSTOR id?[edit]

Not sure if this is the best place to ask this question, but I wasn't sure where else to ask. Is there a benefit to including a |doi= if that DOI takes someone to JSTOR and there is already a |jstor=? I would think the |doi= should only be used in the case where it takes the reader to a different website where the article can be found (e.g., the article on the publisher's site), as different websites might have different paywalls or subscriptions or information available to the reader. It seems redundant to have both and maybe a bit inconvenient if the reader is expecting them to be different, but I've noticed some editors add these "redundant" DOIs so maybe I'm missing something. Thanks Umimmak (talk) 21:09, 24 May 2018 (UTC)

To give explicit (shortened) examples, I think Cornyn (1944). "Outline of Burmese Grammar". JSTOR 522027.  is preferable to Cornyn (1944). "Outline of Burmese Grammar". doi:10.2307/522027. JSTOR 522027.  as both DOI and JSTOR links to go https://www.jstor.org/stable/522027. I think it's only beneficial to make use of both parameters when they go to different sites as in Brown (1925). "Books on Burma and Siam". doi:10.1017/S0035869X00169060. JSTOR 25220835. , where the DOI goes to the article on the Cambridge UP website, not to JSTOR. Umimmak (talk) 21:14, 24 May 2018 (UTC)
I find this annoying too. If we can't agree to avoid these duplicates, could the templates suppress display of doi's of the form 10.2307/jstor-id when the same id is supplied to |jstor=? Kanguole 21:18, 24 May 2018 (UTC)
Yeah you'd need to make sure they're actually the same since I think there are some DOIs starting with 10.2307 which don't just go to JSTOR. To give an example, it would be useful to have both doi:10.2307/2713499 and JSTOR 2713499. Umimmak (talk) 21:29, 24 May 2018 (UTC)
Ah, we can't expect the template to check those. Kanguole 22:29, 24 May 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Umimmak and Kanguole: Additionally, DOIs and JSTOR numbers have orthogonal semantics. The JSTOR number, which is our proxy for what JSTOR itself terms a "Stable URL", is really just one archive provider's direct link that happens to have some "API"-like stability guarantees. It is owned, and can only be owned, by the archive provider. The DOI, on the other hand, is a proper de-coupled identifier that is resolved through a resolver: it is explicitly and deliberately not a stable URL. The identifier is notionally owned by the publisher, not by the archive, and can be changed to point at new archive providers or the publisher's own website (in practice the archive providers often own the DOI too, but...). That is, the one is an address while the other is an identifier. |url=, on the other hand, is entirely redundant with |jstor=. --Xover (talk) 07:53, 26 May 2018 (UTC)

URL and JSTOR access parameters[edit]

After reading the Nov 2016 Signpost article I began adding |url-access= when referencing subscription-limited sources, including those via JSTOR. Recently I noticed a a follow-up CitationCleanerBot edit replaced a url=https://www.jstor.org/stable/ with a more concise jstor= but with the side-effect of leaving a red "|url-access= requires |url=" warning on the article. Can a |jstor-access= be introduced to enable detail equivalent to similar to |url-access= to be retained? A corresponding CitationCleanerBot enhancement could then be requested as a follow-up. AllyD (talk) 09:50, 31 May 2018 (UTC)

The bot correctly replaced |url=https://www.jstor.org/stable/ with |jstor= (should have deleted |url-access=subscription at the same time). In general, titles linked by |url= are considered to be free-to-read (this is why |url-access=free is not allowed) and, similarly, identifier links (doi, jstor, etc) are generally not free-to-read (this is why |id-access=free is allowed but |id-access=subscription is not). See Help:Citation Style 1#Registration or subscription required.
Trappist the monk (talk) 10:26, 31 May 2018 (UTC)
  • Ah, thanks for that; makes sense. I'll follow up the matter of the Bot edit scope. AllyD (talk) 10:38, 31 May 2018 (UTC)

The dead-url=usurped mechanism seems to be broken[edit]

Apparently, it does not actually suppress the display of the link.The same applies to dead-url=unfit

It is my understanding from the help page that it should do that. So either the template or its documentation is wrong here. Wefa (talk) 20:23, 31 May 2018 (UTC)

Are you sure? Can you provide a real-life example of a cs1|2 template where |dead-url=usurped does not work? In this example, there should be a link to archive.org but the rendered citation should not link to the 'original' example.com:
{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2018-05-31 |dead-url=usurped}}
Title. Archived from the original on 2018-05-31. 
Trappist the monk (talk) 20:43, 31 May 2018 (UTC)
well.... Title nobody bothered to archive. 
-Wefa (talk) 21:11, 31 May 2018 (UTC)
That is as it is supposed to be. Without |archive-url=, Module:Citation/CS1 ignores |dead-url=. You must provide |archive-url= (and |archive-date=) for |dead-url=usurped to have any meaning.
Trappist the monk (talk) 21:57, 31 May 2018 (UTC)
Hmm. But when an editor is adding |dead-url=usurped to a citation, their intent will invariably be "Supress this link because it now points to something inappropriate" with the "Use the archive link instead" bit being only a corollary. It is also generally desireable to be able to supress usurped links even for citations where no one has yet added an archive (which may or may not exist), without removing the link entirely (in order to enable actually locating any archive in the future). Without reopening the previous discussion on the conceptual semantics of |dead-url=, perhaps this particular case (usurped) makes practical sense to special-case? --Xover (talk) 04:33, 1 June 2018 (UTC)

Update to the live cs1|2 modules weekend of 9–10 June 2018[edit]

I intend to update the live cs1|2 modules over the weekend of 9–10 June 2018. These changes are included:

to Module:Citation/CS1:

  • support for lang code cnr; fix script-title to use override names when making categories; discussion
  • unlink trans-chapter rendering; discussion
  • make pagination work better in cite interview with |journal=; discussion
  • i18n: sep & ps chars to /Configuration; translate non-western enumerators; discussion
  • i18n: support date digit translation; discussion
  • duplicate-dot bug fix for |others=, |interviewer=, |translator=; discussion
  • i18n: multi-byte terminal character support related to duplicate-dot bug fix; discussion

to Module:Citation/CS1/Configuration

  • support for lang code cnr; fix script-title to use override names when making categories;
  • "interview with" changed to "interviewed by"; discussion
  • Enable error tracking in Draft namespace; discussion
  • Add |lang=lang as a |language= alias; discussion
  • i18n: support date digit translation;
  • remove extraneous closing code tag; discussion
  • add parameters for |chapter-xx= alias consistency; discussion

to Module:Citation/CS1/Whitelist

  • Add |lang=lang as a Language alias; deprecate |in=

to Module:Citation/CS1/Date validation

  • move misplaced local_digit translation to proper place; discovered debugging this module at bn.wiki;
  • i18n: support date digit translation;
  • prevent ymd hyphen-to-dash conversion when digits are not western digits;

Trappist the monk (talk) 16:31, 3 June 2018 (UTC)

Semi-relatedly, I updated the red access lock to display the dial. It is now much more recognizable as a lock. See new vs old. Headbomb {t · c · p · b} 22:18, 5 June 2018 (UTC)
Not related at all; rather, it appears that you are ignoring the decisions taken with this RFC dated 29 October 2016. The red lock that was approved by the RFC can be seen at File:Lock-red-alt.svg#filehistory (the 3 October 2016 version). It seems to me that a decision taken by the community via the formal RFC process must not be unilaterally overridden by an individual editor. Please revert the lock back to the 3 October 2016 version. If you desire a different lock shape/color/etc, the proper course is to pursue a community consensus via RFC.
Trappist the monk (talk) 00:12, 6 June 2018 (UTC)
The RFC supported a red lock, with a full shackle, and full body. This is still exactly what this is, except with enhanced recognizability. We don't need full RFCs for minor changes like this. Headbomb {t · c · p · b} 00:21, 6 June 2018 (UTC)
Precisely: The RFC supported a red lock, with a full shackle, and full body. The community did not support a full-body lock with a transparent center dial thing. Please revert the lock back to the 3 October 2016 version.
Trappist the monk (talk) 11:39, 6 June 2018 (UTC)
 Done --Redrose64 🌹 (talk) 19:59, 6 June 2018 (UTC)
Sigh, this template is by far the worse WP:BURO quagmire there is on Wikipedia. Still, see this RFC on the issue. Headbomb {t · c · p · b} 02:53, 7 June 2018 (UTC)

Some AWBable changes for extra text: author list[edit]

This search can trivially take care of some of the 24k pages with extra text, if there is an interested AWB-runner watching. --Izno (talk) 17:02, 5 June 2018 (UTC)

It would seem to me that the correct person to fix those templates is the same person who created them: Editor DISEman.
Trappist the monk (talk) 17:30, 5 June 2018 (UTC)

I would be happy to if someone could explain what needs to happen DISEman (talk) 07:10, 13 June 2018 (UTC)

@DISEman: Right now, the articles identified in that search link are emitting a trivial error to correct. The error is that they have extraneous text in the editor field, which is because the templates are using |last= to represent an editor rather than |editor-last=. The correction you would need to make is this one across 2000 articles or so. Are you familiar with how AWB works (do you have permission to use the tool--you can probably get it trivially)? With regular expressions? --Izno (talk) 13:41, 14 June 2018 (UTC)

Question about format parameter[edit]

Is this meant to be linkable, like |format=[[Audio Video Interleave|AVI]], and whether it is or not, is it doing something special with a short list of common format names/acronyms like "PDF"? We should document this parameter better, e.g. to suggest that the format be linked.  — SMcCandlish ¢ 😼  01:01, 7 June 2018 (UTC)

Meant to be linkable? I don't think so. May it be linked? Sure, why not? Module:Citation/CS1 applies css styling (style="font-size:85%;") to the value provided by |format= and the |name-format= parameters, but otherwise does nothing special with those parameters.
Of course, documentation can always be made better. I don't know that the parameter value should always be linked lest we run afoul of WP:OVERLINK (do we really need to link PDF?) Linking obscure file formats seems sensible.
Trappist the monk (talk) 14:43, 7 June 2018 (UTC)

Access locks vertical alignment[edit]

In DeRisi, S; Kennison, R; Twyman, N (November 2003), "The what and whys of DOIs", PLoS Biology, 1 (2): E57, doi:10.1371/journal.pbio.0000057, PMC 261894Freely accessible, PMID 14624257 , the alignment of the icon with the text really isn't great: (see [1]).

This should be tweaked so that the icon and text are aligned. Headbomb {t · c · p · b} 15:39, 8 June 2018 (UTC)

See this discussion. Module:Citation/CS1 does not manipulate the access signal vertical positioning.
Trappist the monk (talk) 16:00, 8 June 2018 (UTC)

I'm going test the following on several skins, see where that gets us.

Code for things to be aligned in different skins
Version Cologne MinervaNeue Modern Monobook Timeless Vector
old PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg
new PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg PMC1 Lock-green.svg

I came up with the above. Testing on all skins on desktop on Firefox. The alignment isn't 100% perfect in all cases, but it's always an improvement. Headbomb {t · c · p · b} 17:03, 8 June 2018 (UTC)

I'm viewing this table using the monobook skin. Under it, the "new" MinervaNeue and Monobook columns have much larger lock icons, out of proportion to the text font, and worse aligned. It doesn't look like an improvement to me. —David Eppstein (talk) 17:56, 8 June 2018 (UTC)
@David Eppstein: that's because you're using the Monobook skin. You need to look at the Monobook column. If you had MinervaNeue, then the MinervaNeue column would look best. The idea here is that maybe we can implement something that changes with the skin (either in the template, or in the skin directly). Headbomb {t · c · p · b} 23:04, 8 June 2018 (UTC)
Actually, I uploaded the wrong version from my sandbox. Things should be fixed now, although again you need to look in the column for the relevant skin. Headbomb {t · c · p · b} 23:15, 8 June 2018 (UTC)
Perhaps you didn't notice, but my initial comment did include looking at the matching column to the skin I was using, and that that specific combination did not look good. In any case, after your update the monobook column (in monobook view) now looks the right size, and better aligned than before (still maybe 1 pixel below the baseline, but it was more like 3 before). —David Eppstein (talk) 00:02, 9 June 2018 (UTC)
Yes, I uploaded the wrong version initially, and I skipped over the second 'monobook'. Thought you were complaining about mostly MinervaNeue under Monobook, which didn't make a whole lot of sense. Things are fixed now though. Headbomb {t · c · p · b} 00:10, 9 June 2018 (UTC)
I don't think that there is much to be done here about this issue. Module:Citation/CS1 cannot know the user's preferences so cannot adjust the display to suit the user's preferred skin. This is because the wikisource is rendered into html and then cached. The cached html is the page that gets served to readers. For logged-in readers, preferences appear to be added to the base html before the page is served to them. Presuming that is the case, we might create a css class for the access-signal images to be added to the appropriate skin css pages so that the locks will have appropriate size and vertical positioning. Failing that, we could do the same and publish appropriate css so that users could tweak their own user custom.css or skin.css pages.
For vertical positioning, the square bracket characters and the pipe character ([|]) illustrate, I think, the descender height to cap height limits of a font. The access-signal image should fit within those bounds. The 9px size was chosen because the image fits more-or-less correctly when using the default skin, Vector. I have added brackets to the table above to facilitate this comparison.
Trappist the monk (talk) 12:27, 9 June 2018 (UTC)
CSS classes are likely the way to go. Also I removed the brackets, because alignment isn't based on how they fit into [], but rather with the line height in general (which can be seen when you highlight the text + image together), e.g. [Lock-green.svg] (monobook, see [2]), or PMC1 [Lock-green.svg] (vector, see [3]). Headbomb {t · c · p · b} 13:39, 9 June 2018 (UTC)
Perhaps the defining vertical height and position should be the PDF icon. On my browser (latest Chrome, win 7), this looked the same in vector and monobook:
<nowiki>[</nowiki>[http://example.com/doc.pdf]<span style="margin-left:0.1em; position:relative;top:-1px">[[File:Lock-green.svg|9px]]</span>]
[[4]Lock-green.svg]
Trappist the monk (talk) 15:16, 9 June 2018 (UTC)
Guess I'll re-enable external link icons just to look at that. Headbomb {t · c · p · b} 15:25, 9 June 2018 (UTC)
Tried a few skins and the PDF icon always looks the right size/alignment. I wonder how it's done? Headbomb {t · c · p · b} 15:31, 9 June 2018 (UTC)
It's a background image. That is something that we can consider when/if Extension:TemplateStyles (help) is enabled on enough wikis.
Trappist the monk (talk) 15:44, 9 June 2018 (UTC)

script-title and no title[edit]

There probably should be some tracking category for cites, where is |script-title=, but isn't |title=. See Sergei Ignashevich, for example. --Edgars2007 (talk/contribs) 06:21, 9 June 2018 (UTC)

See this discussion.
Trappist the monk (talk) 08:20, 9 June 2018 (UTC)

ASIN[edit]

{{Cite book}} includes an ASIN parameter. The documentation says not to use this when other identifiers are available, but this is widely abused. Example: [5] - all three instances here also had an ISBN. I think the ASIN parameter should be deprecated - it is a single-vendor ID and including it is an implicit promotion of Amazon. I have no problem with Amazon, but Wikipedia is not here to drive traffic to their sales pages. This parameter should be deprecated. Guy (Help!) 08:27, 9 June 2018 (UTC)

@JzG: I don't disagree, but I think that's probably the kind of change that would require an RfC to decide. --Xover (talk) 08:32, 9 June 2018 (UTC)
I don't actually see why, as parameters that encourage linking to single-vendor sales pages are actually antithetical to Wikipedia's core values. Guy (Help!) 08:34, 9 June 2018 (UTC)
That's an argument against newly adding such a parameter, not for removing a long-standing supported parameter that's in wide use (whether we like it or not) from a template that's currently in use on over 3 million articles (whose editors therefor have a legitimate interest in this issue). There are also valid arguments for keeping the parameter (that I don't find them persuasive does not make them invalid), so it's by no means a foregone conclusion which way the community will fall on this. --Xover (talk) 08:54, 9 June 2018 (UTC)
The current wording is sufficient to justify removing an ASIN value if other identifiers are present. If no other identifiers are present, just removing it would make the reference harder to identify. Of course one could add a different identifier and then remove the ASIN value. Kanguole 08:57, 9 June 2018 (UTC)
Periodically I wonder if the maintenance category Category:CS1 maint: ASIN uses ISBN should be changed to an active error message. With this topic, I now wonder if we should disable |asin= display when the cs1|2 template also has a valid |isbn= assignment because amazon.com can be reached through Special:BookSources. At the same time we could categorize such templates into a new category Category:CS1 maint: ASIN ignored or even, perhaps, Category:‎CS1 errors: ASIN ignored‎.
Trappist the monk (talk) 11:34, 9 June 2018 (UTC)
That certainly seems eminently sensible and practical to me. I predict vocal minorities appearing for an active error message for this though. --Xover (talk) 11:54, 9 June 2018 (UTC)
Category:CS1 maint: ASIN uses ISBN should be made into an error message, but only when ASINs with correct ISBN checksums that aren't ISBNs can be filtered out. There's too many of those right now to make the error visible. Headbomb {t · c · p · b} 12:28, 9 June 2018 (UTC)

Update problem[edit]

Hello, since the update we are getting "Unknown parameter |1= ignored (help)" messages for cites that call {{cite web}} via Module:Template wrapper.

As an example

{{NHLE|num=1190147|desc=Snape Castle|accessdate=9 June 2018}}

Historic England. "Snape Castle (1190147)". National Heritage List for England. Retrieved 9 June 2018. 

Any ideas where the problem lies?

Keith D (talk) 22:08, 9 June 2018 (UTC)

Fixed. I don't recall seeing that error when I converted the template to use the module. — JJMC89(T·C) 22:28, 9 June 2018 (UTC)
Thanks. It has only appeared since the change to the cite modules today. Keith D (talk) 23:25, 9 June 2018 (UTC)

Part of the internationalization changes applied to the module suite at this last update, included code that translates parameter enumerators from the local language digits, which Lua may not understand, to western digits that Lua does understand. What I didn't see is that the translation changes the implicit positional parameter 'name' from a number type to a string type. So ...|something|... gets translated to ...|1=something|... where the 1 is treated as a parameter name just like title is the parameter name in |title=something.

{{Cite book |title=Title |something |author1=Brown |author2=Red |author3=Orange}}
Brown; Red; Orange. Title.  Text "something " ignored (help)
{{Cite book/new |title=Title |something |author1=Brown |author2=Red |author3=Orange}}
Brown; Red; Orange. Title.  Text "something " ignored (help)

Fixed in the sandbox. Without objection, I'll update the live modules later today.

Trappist the monk (talk) 16:14, 10 June 2018 (UTC)

Thanks for finding that. This weekend I have edited most pages in unnamed-parameter category for Unknown "|1=" but will be much easier to pinpoint again as: Text "volume34" ignored. I hadn't realized how seeing the ignored Text is much, much easier when fixing long cites. -Wikid77 (talk) 17:56, 10 June 2018 (UTC)

Why[edit]

Why is the following error happening?

"Home - John F. Kennedy Presidential Library & Museum". Archived from the original on 29 April 2009. Retrieved 20 October 2009. 

Source code:

{{cite web
|url=http://jfklibrary.org/
|title=Home - John F. Kennedy Presidential Library & Museum
|accessdate=20 October 2009
|deadurl=yes
|archive-url=https://web.archive.org/web/20090429042056/http://jfklibrary.org/
|archive-date=29 April 2009
|df=dmy}}

(Previous version)

If |df (date format) is removed, then it works. But why? --YellowCakeUranium (talk) 12:35, 10 June 2018 (UTC)

Fixed, I think:
Cite book compare
{{cite book |df=dmy |title=Title |archive-date=2018-06-10 |url=//example.com |archive-url=//archive.org}}
Live Title. Archived from the original on 2018-06-10. 
Sandbox Title. Archived from the original on 2018-06-10. 
Cite book compare
{{cite book |archive-date=2018-06-10 |df=dmy |title=Title |url=//example.com |date=2018-06-10 |archive-url=//archive.org}}
Live Title. 10 June 2018. Archived from the original on 2018-06-10. 
Sandbox Title. 10 June 2018. Archived from the original on 2018-06-10. 
Cite book compare
{{cite book |archive-date=2018-06-10 |df=dmy-all |title=Title |url=//example.com |date=2018-06-10 |archive-url=//archive.org}}
Live Title. 10 June 2018. Archived from the original on 10 June 2018. 
Sandbox Title. 10 June 2018. Archived from the original on 10 June 2018. 
Cite book compare
{{cite book |archive-date=2018-06-10 |df=mdy |title=Title |url=//example.com |date=2018-06-10 |archive-url=//archive.org}}
Live Title. June 10, 2018. Archived from the original on 2018-06-10. 
Sandbox Title. June 10, 2018. Archived from the original on 2018-06-10. 
Cite book compare
{{cite book |archive-date=2018-06-10 |df=mdy-all |title=Title |url=//example.com |date=2018-06-10 |archive-url=//archive.org}}
Live Title. June 10, 2018. Archived from the original on June 10, 2018. 
Sandbox Title. June 10, 2018. Archived from the original on June 10, 2018. 
Cite web compare
{{cite web |archive-date=29 April 2009 |df=dmy |title=Home - John F. Kennedy Presidential Library & Museum |url=http://jfklibrary.org/ |accessdate=20 October 2009 |archive-url=https://web.archive.org/web/20090429042056/http://jfklibrary.org/}}
Live "Home - John F. Kennedy Presidential Library & Museum". Archived from the original on 29 April 2009. Retrieved 20 October 2009. 
Sandbox "Home - John F. Kennedy Presidential Library & Museum". Archived from the original on 29 April 2009. Retrieved 20 October 2009. 
Without objection, I'll update the live modules later today.
Trappist the monk (talk) 15:06, 10 June 2018 (UTC)

Value of ISSNs[edit]

Editors following this page may be interested in WP:VPPOL#Including ISSNs in citations. Consider commenting there. --Izno (talk) 14:51, 10 June 2018 (UTC)

Speech[edit]

The documentation for {{cite speech}} provides the following for the type parameter: "Provides additional information about the media type of the source; format in sentence case. Displays in parentheses following the title. Defaults to Speech." This doesn't appear to be the case, however:

Halliday, Fred (2008). International Relations in a Post-Hegemonic Age (PDF) (Speech). Valedictory Lecture as Montague Burton Professor of International Relations (lecture). London: London School of Economics and Political Science. Retrieved 10 June 2018. 

Is this in error? 142.160.89.97 (talk) 18:49, 10 June 2018 (UTC)

The '(Speech)' annotation no longer uses the |type= parameter (it did in the past when {{cite speech}} used {{citation/core}}).
Trappist the monk (talk) 19:05, 10 June 2018 (UTC)

CS1 error categories show as having subcategories, but I don't see them[edit]

I am seeing five of the CS1 error categories as having subcategories in their short listings on the Category:CS1 errors page, but when I click the triangle to fold down the category list, I see "nothing found". When I open the category page, I do not see any subcategories. This has been happening for at least a few weeks now; I was hoping it would resolve itself. I have tried purging both pages, to no avail.

Example: "CS1 errors: dates‎ (2 C, 28,984 P)". – Jonesey95 (talk) 15:46, 11 June 2018 (UTC)

I don't think that this problem can be laid at the feet of cs1|2. The only categories that have 'official' subcategories are those that belong to Category:CS1 maint: Extra text (each of the subcategories declare themselves to be a member of CS1 maint: Extra text). I recall seeing categories listed as you describe (don't remember if their triangle was active or not) but regardless the included category was properly listed and, on the category page, sure enough, there was a cs1|2 citation with an error. Perhaps raise the issue at WP:VPT?
Trappist the monk (talk) 16:56, 11 June 2018 (UTC)
Re-asked at VPT. – Jonesey95 (talk) 21:25, 11 June 2018 (UTC)

Sfn for AV media template[edit]

As the title suggests, I want to know what would the SFN style be for Cite AV media? Is there even an SFN option for that temptlate? Armegon (talk) 05:59, 13 June 2018 (UTC)

Perhaps this:
{{sfn|Ryfle|Song-ho|2016|loc=11:39}}[1]
Ryfle, Steve; Song-ho, Kim (2016). Yongary, Monster from the Deep Audio Commentary (Blu-ray/DVD). Kino Lorber. 

Trappist the monk (talk) 11:00, 13 June 2018 (UTC)

References

THANK YOU SO MUCH!!! IT WORKS!! But I tried that before and it didn't work but now it's working? Any idea what I was doing wrong? Armegon (talk) 20:37, 13 June 2018 (UTC)
Do you mean in edits like this one? You used |time= (which is not recognised) instead of |loc= --Redrose64 🌹 (talk) 22:04, 13 June 2018 (UTC)

Definition of archive-date[edit]

From Template:cite web --

This sentence sounds to me like referring to: (a) the date on which a webpage was cached on way-back-machine, etc; or (b) the date on which the archive-url was added (i.e. date of the User's edit). I feel it is (a) meaning, but I think it necessary to clarify. Let me know what; thank you! -- SzMithrandirEred Luin 05:02, 14 June 2018 (UTC)

It is indeed (a). --Redrose64 🌹 (talk) 07:46, 14 June 2018 (UTC)
OK then; maybe revise the verse? "Date when the original URL was archived (as recorded by the archiving website); do not wikilink" ? -- SzMithrandirEred Luin 18:52, 14 June 2018 (UTC)
That's rather pointless. When else would that be archived? Headbomb {t · c · p · b} 03:13, 18 June 2018 (UTC)

Ered Luin - The sentence your quoting above is from the TemplateData section, and it is indeed ambiguous. This came up recently, and the main documentation was changed to read "Archive-service snapshot-date" to clarify it's the service snapshot-date not the user-entry date. The TemplateData documentation should be changed to say archive-service snapshot-date. -- GreenC 04:40, 18 June 2018 (UTC)

Missing an h in http[edit]

This revision should probably have a URL error at cite 22, as it is missing an h in the scheme. I'm not sure if it's detectable though. --Izno (talk) 13:37, 14 June 2018 (UTC)

Wouldn't it be fairly easy to check that urls start with appropriate protocols? http(s)://, ftp://, etc... ? Headbomb {t · c · p · b} 13:43, 14 June 2018 (UTC)
We would presumably need to support the full list of registered URI schemes explicitly. Right now, it looks like Module:Citation/CS1 limits its validation to the general form "xxxx://" or "//" for protocols. – Jonesey95 (talk) 14:30, 14 June 2018 (UTC)

(edit conflict)

Module:Citation/CS1 function is_scheme() returns true for |url=ttp://www.racialjusticeproject.com/wp-content/uploads/sites/30/2012/06/NYLS-Food-Deserts-Report.pdf because ttp complies with Uniform Resource Identifier (URI): Generic Syntax (std66) §3.1, which defines the sequence of characters that form a scheme name. I chose to do it this way because standards are less likely to change than the list of registered schemes at IANA so maintenance would be easier. Were there thousands of these kinds of errors, it might be worth changing the code to use the list of schemes from IANA but, I've just fixed 25 of the 27 found by this search (the two that I didn't fix are on the spam blacklist)
Trappist the monk (talk) 14:32, 14 June 2018 (UTC)
I agree with @Jonesey95: above that whitelisting is the way to go. Headbomb {t · c · p · b} 18:05, 14 June 2018 (UTC)
I thought this was the rationale. It's reasonable that it was implemented like so to begin with. I wouldn't be against at least adding the permanent registered schemes and subsequently providing a suggested (like our "saw autor; suggest author" suggestions) change when the scheme looks like but is not one of those on list. Or we can just do all of them. Or leave it as is. I have no strong feeling on the matter--just seems like it might be a reasonable check for validity. --Izno (talk) 19:09, 14 June 2018 (UTC)
For the record, I was not suggesting that we create and maintain a list of acceptable prefixes; I was merely suggesting a sort of layperson's specification that would guide changes to the module. Given that there were only 27 such errors (I find only 53 in all namespaces combined), this might be a better job for something like Wikipedia:WikiProject Check Wikipedia. – Jonesey95 (talk) 01:59, 15 June 2018 (UTC)
WP:CHECKWIKI is slow to update. Tracking categories + error messages lets errors be fixed when they arise, so I prefer that option. (Not that a new CHECKWIKI thing couldn't be created, parallel efforts are good.) Headbomb {t · c · p · b} 01:23, 18 June 2018 (UTC)

PMC now above 600000[edit]

See

for example. The limit should be increased to 7000000. Headbomb {t · c · p · b} 20:06, 19 June 2018 (UTC)

Unknown parameter month ignored?[edit]

The template docs say that it's possible to use a combination of month= and year=, but I tried this and it said that the month is an unknown parameter. Example:

{{cite report|url=https://www.gov.il/BlobFolder/news/bus_competition_program/he/Competition%20program%20buses.pdf|title=תכנית תחרות ענף התחבורה הציבורית באוטובוסים 2030-2018 שנים|trans-title=Competition Plan for Bus Public Transportation for Years 2018–2030|publisher=[[Israel Ministry of Transport]]|year=2018|month=June|accessdate=June 21, 2018|language=he}}

Ynhockey (Talk) 20:06, 21 June 2018 (UTC)

Yeah, documentation was wrong; |month= was deprecated and support for that parameter removed long ago.
Trappist the monk (talk) 20:14, 21 June 2018 (UTC)


Illustrators[edit]

Many books, especially identification guides, are illustrated. Is there anyway to credit the illustrator in the citation? Quetzal1964 (talk) 17:19, 23 June 2018 (UTC)

|others=Illustrated by Audubon, J.J.
Trappist the monk (talk) 17:45, 23 June 2018 (UTC)
But the purpose of a citation is to help readers find the resource being cited. So I think it's only appropriate to credit the illustrator in the citation if the illustrations are relevant to the citation. —David Eppstein (talk) 18:11, 23 June 2018 (UTC)
I've done it like this. --Redrose64 🌹 (talk) 18:50, 23 June 2018 (UTC)
Yes, when listing an author's books on an article about the author, credits for the illustrator seem appropriate, because in that case it's someone the author worked with to produce the book (rather than an irrelevant detail about a source for a claim in an unrelated article). —David Eppstein (talk) 19:21, 23 June 2018 (UTC)

Further DOI checking[edit]

Per the DOI standard, the approved character set for DOI suffixes is: "a-z", "A-Z", "0-9" and "-._;()/" since 2008. A "check DOI" error should be thrown if a doi with an non-approved character is found in a publication dated 2009 or later. It would help find these sort of errors [6]. Headbomb {t · c · p · b} 18:57, 23 June 2018 (UTC)

Problematic. That particular (dead) doi (doi:10.7249/mg702wf.9#page_scan_tab_contents) is 'allowed' by the current standard: "An expanded set of characters was supported prior to 2008, so you may see DOIs with now-banned characters (such as #, +, <, and >). DOIs created before the character set was restricted are still supported..." If we tighten the doi validity test to accept only dois compliant with the post-2k8 standard, we risk falsely catching pre-2k8 dois that use the previously allowed character set (which the current standard does not clearly define).
Trappist the monk (talk) 19:33, 23 June 2018 (UTC)
I agree. I don't recall seeing # but I've definitely seen some with < and >, e.g. doi:<61::AID-NME923>3.0.CO;2-Y 10.1002/1097-0207(20000910/20)49:1/2<61::AID-NME923>3.0.CO;2-Y. We need to continue allowing those. —David Eppstein (talk) 20:02, 23 June 2018 (UTC)
@David Eppstein: That DOI dates from 2000, which is before 2008. @Trappist the monk:, the point isn't to catch all such errors, but to catch those we can, e.g. if date/year is >=2009, then have the template flag those errors. If the date is before that, don't flag the errors. Headbomb {t · c · p · b} 20:20, 23 June 2018 (UTC)

RFC on use of via[edit]

Wikipedia:Village pump (policy)#Should WP:TWL be allowed to acknowledge the services they have partnership with in our articles? Headbomb {t · c · p · b} 15:42, 28 June 2018 (UTC)

misc |chapter-xxx= alias consistency (cont)[edit]

Extending this discussion, I failed to add these parameter names to Module:Citation/CS1/Whitelist/sandbox:

|article-format=, |article-url=, |article-url-access=
|entry-format=, |entry-url=, |entry-url-access=
|section-url-access=

That is now done so these work:

{{cite book/new |title=Encyclopedia |article=Article |article-url=//example.com/article.pdf |article-format=pdf |article-url-access=subscription}}
"Article" (pdf). Encyclopedia. 
{{cite book/new |title=Encyclopedia |entry=Entry |entry-url=//example.com/article.pdf |entry-format=pdf |entry-url-access=subscription}}
"Entry" (pdf). Encyclopedia. 
{{cite book/new |title=Encyclopedia |section=Article |section-url=//example.com/article.pdf |section-format=pdf |section-url-access=subscription}}
"Section" (pdf). Encyclopedia. 

Without objection, I shall probably go ahead and update the live module.

Trappist the monk (talk) 16:04, 28 June 2018 (UTC)

Can we also update the access locks per this discussion while we're at it? new2 has most support for it, with very few arguments against it. Headbomb {t · c · p · b} 19:33, 28 June 2018 (UTC)

Requested move 29 June 2018[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: no consensus to move the modules to the proposed titles at this time, per the discussion below. Dekimasuよ! 17:48, 12 July 2018 (UTC)


– Given that {{citation}}, the template for CS2, also uses this module, the subpage name "CS1" is both unnecessarily verbose and imprecise. {{3x|p}}ery (talk) 01:55, 29 June 2018 (UTC) --Relisting. {{3x|p}}ery (talk) 16:03, 1 July 2018 (UTC)

For some reason, the bot is calling this request malformed. Not sure why. {{3x|p}}ery (talk) 02:17, 29 June 2018 (UTC)
This seems like a good idea in theory, but this move may have unintended consequences. Let's make sure to think it through. Is there a reason that you have not proposed moving the associated sandbox pages, which are an integral part of these modules? – Jonesey95 (talk) 04:10, 29 June 2018 (UTC)
No, I just didn't feel like listing every single page. Of course the /sandbox, /doc, and talk pages will be moved -- that's usually assumed. The only reason I listed the subpages at all was to work around a bug in the RM template infastructure. {{3x|p}}ery (talk) 13:36, 29 June 2018 (UTC)
  • Oppose. The suffix "/CS1" is short, not verbose as compared to "/CiteStyle1" or such. I chose the naming as "Citation/CS1" to allow separation of cite styles, as "wp:Citation Style 1" separate from other potential styles, specifically at that time CS2, but now could allow a future "CS3" etc. For example, I have pondered automatic parsing for simple cites, where a user enters {cite_text} "John Doe, May 3, 2015, My Book, Chapter 7: Later Events, page 132, link http..." and a Lua "module:Citation/CS3" could parse that into a cite similar to CS1 {cite_book} to allow free-form cites for simple citations, such as new users or young children learning to use source citations. As a separate module /CS3, it could be expanded every few days to better parse free-form cites, without triggering the reformat of 3 million pages using /CS1. -Wikid77 (talk) 13:08, 1 July 2018 (UTC)
Wikid77 please do get consensus for the free-form as I believe it would be a recipe for disaster. Working daily with citations with my bot, the amount of garbage created even with strict key=value pairs is amazing. A free-form system would likely create even more garbage and be impossible to fix via bot in many cases, creating an ever growing backlog that exceed manual efforts ie. degrade the project over time. -- GreenC 13:43, 1 July 2018 (UTC)
  • Oppose. I agree with Wikid77 that editors are free to introduce a different system of citation templates in the future, and retaining the "/CS1" makes that a bit easier from a practical point of view, and also serves as a symbol, reminding everyone that CS1 has never been anointed as the one true Wikipedia citation style (see WP:CITEVAR).
In the same vein I take exception to Wikid77's post, which seems to imply that those who don't use citation templates of any sort are "new users or young children learning to use source citations". I would also caution that applying any sort of template to articles that currently have consistent citations that don't use templates, without seeking consensus on the article talk page, is contrary to WP:CITEVAR. Jc3s5h (talk) 13:27, 1 July 2018 (UTC)
  • I'm relisting this so its gets a full seven days listed properly in the bot-generated list, rather than spending the first few of those days as "malformed". {{3x|p}}ery (talk) 16:02, 1 July 2018 (UTC)
  • Weak Oppose I also think it's fine where it is. If anyone ever gets around to making a "CS2" we won't need to rename anything to accommodate it. Also, there may be other things besides the cite template family calling this module that may break. I'm not really against the move, just not convinced of the utility of it. — AfroThundr (u · t · c) 13:45, 6 July 2018 (UTC)
    CS2 already exists in the form of {{citation}}--we just don't cover it on a separate page because it is almost exactly the same as CS1 (and in fact uses this module for formatting). --Izno (talk) 14:25, 6 July 2018 (UTC)
    There is a third style of citations using templates: {{Harvard citation}} in conjunction with CS1 or CS2 templates. There is no cute three character symbol for this style yet, but maybe someday there will be. Jc3s5h (talk) 14:52, 6 July 2018 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Cite book from Commons[edit]

I see no obvious way that isn't ugly to link a book that was uploaded to Commons when using {{cite book}}. Alexis Jazz (talk) 09:43, 29 June 2018 (UTC)

Examples of what you mean are almost always appropriate else we don't know what it is that you consider ugly.
Trappist the monk (talk) 11:11, 29 June 2018 (UTC)
How about something like:
{{cite book |author = [[Federal Highway Administration]] |year = 1977 |title = America's Highways 1776–1976 |url = https://commons.wikimedia.org/wiki/File:America%27s_Highways_1776%E2%80%931976.djvu |format = [[DjVu]] |location = Washington, DC |publisher = Government Printing Office |oclc = 631826513 |via = [[Wikimedia Commons]] }} to produce:
Federal Highway Administration (1977). America's Highways 1776–1976 (DjVu). Washington, DC: Government Printing Office. OCLC 631826513 – via Wikimedia Commons. 
I think it works really well, to be honest. Imzadi 1979  12:42, 29 June 2018 (UTC)
@Trappist the monk and Imzadi1979: It works, but that's what I meant by ugly. https://commons.wikimedia.org/wiki/File:America%27s_Highways_1776%E2%80%931976.djvu is not pretty, File:America's Highways 1776–1976.djvu is. Commons has quite some old documents and books that are in the public domain and it would be very nice if it were possible to cite from them using a citation template with wikilink rather than url. Alexis Jazz (talk) 13:16, 29 June 2018 (UTC)
So use interwikilinking:
{{cite book |author = [[Federal Highway Administration]] |year = 1977 |title = America's Highways 1776–1976 |title-link=:c:File:America's Highways 1776–1976.djvu |location = Washington, DC |publisher = Government Printing Office |oclc = 631826513 |via = [[Wikimedia Commons]] }} to produce:
Federal Highway Administration (1977). America's Highways 1776–1976. Washington, DC: Government Printing Office. OCLC 631826513 – via Wikimedia Commons. 
Trappist the monk (talk) 13:21, 29 June 2018 (UTC)
As an aside, were it me and were I linking to this source, I'd link to the facsimile at archive.org which has a much more intuitive user interface.
Trappist the monk (talk) 13:30, 29 June 2018 (UTC)

|df= -- what does it do?[edit]

This is an undocumented parameter. Doesn't seem to be doing much either. Somehow related to date format? Headbomb {t · c · p · b} 13:15, 29 June 2018 (UTC)

What do you mean undocumented? See, for example, here. And it does work:
{{cite book |title=Title |date=2018-06-29 |df=dmy}}Title. 29 June 2018. 
Trappist the monk (talk) 13:26, 29 June 2018 (UTC)
Well it's not documented on Help:CS1. And I suppose I mostly saw that usage on date formats that already matched the |df= output. Headbomb {t · c · p · b} 16:06, 1 July 2018 (UTC)
Of course not, and it shouldn't be. If you want template parameter documentation, see the template documentation. H:CS1 should hold documentation about the style and supplementary explanatory text; it should not contain exact copies of the template documentation.
Yeah, I've seen a lot of cs1|2 templates where all dates in the template source match the |df= setting. When that's the case, I remove |df=.
Trappist the monk (talk) 16:52, 1 July 2018 (UTC)
H:CS1 should hold documentation about the style and supplementary explanatory text; it should not contain exact copies of the template documentation. Huh? I've always used this page for exactly that, especially since this templates were consolidated to the module... --Izno (talk) 17:24, 1 July 2018 (UTC)
Then, I would guess that you haven't needed H:CS1 for much template parameter documentation. There are, I think, three transclusions of parameter documentation from {{Citation Style documentation}} (csdoc) into H:CS1:
If you look at csdoc, which is the master documentation template for all of the cs1|2 parameters, you will see that it holds a lot more information than the three transclusions in H:CS1. Because there are quite a few differences in parameter operation that are dependent on the template of interest, the best place for template parameter documentation is the template's own documentation.
Trappist the monk (talk) 18:10, 1 July 2018 (UTC)

Broken doi links[edit]

I examined a report at Wikipedia:Help desk#DOI's not connecting? For example, {{cite encyclopedia|title=Calcium–Ammonia|author=Edwin M. Kaiser|encyclopedia=Encyclopedia of Reagents for Organic Synthesis|year=2001|doi=10.1002/047084289X.rc003}} produces:

Edwin M. Kaiser (2001). "Calcium–Ammonia". Encyclopedia of Reagents for Organic Synthesis. doi:10.1002/047084289X.rc003. 

The doi link goes to https://doi.org/10.1002%2F047084289X.rc003 and currently gives a 404 not found. This link works: https://doi.org/10.1002/047084289X.rc003. The only difference from the broken link is replacing %2F by /. %2F is the percent-encoding of /. It's the same with other doi links I tested. Should we stop encoding / as %2F, or is doi.org likely to soon accept %2F? PrimeHunter (talk) 01:40, 3 July 2018 (UTC)

I don't think anything has changed on the CS1 template end, but I could be wrong. {{doi}} appears to be broken as well. I sent an e-mail to the doi.org people. – Jonesey95 (talk) 04:27, 3 July 2018 (UTC)
Is it all DOIs, or just this one? Headbomb {t · c · p · b} 04:34, 3 July 2018 (UTC)
I haven't found any that work. I tried Brontosaurus#References, Stephen Hawking#References, and Science#References. Every DOI I clicked on was 404. – Jonesey95 (talk) 04:46, 3 July 2018 (UTC)
Live and sandbox modules tweaked so that they don't url encode doi identifiers. Same change to {{doi}}.
Trappist the monk (talk) 10:06, 3 July 2018 (UTC)
@Trappist the monk: It's only / which shouldn't be encoded. Many other special characters can appear in a doi and require percent-encoding per https://www.doi.org/doi_handbook/2_Numbering.html#2.5. For example, Brontosaurus#cite_note-Wedel_2003-43 says:
Wedel, M. J. (2003). "Vertebral Pneumaticity, Air Sacs, and the Physiology of Sauropod Dinosaurs". Paleobiology. 29 (2): 243–255. doi:10.1666/0094-8373(2003)029<0243:vpasat>2.0.co;2. JSTOR 4096832. 
It's badly broken now and also displays wrong visibly so it cannot be copy-pasted. Before it produced 10.1666/0094-8373(2003)029<0243:vpasat>2.0.co;2. which is fixed by changing %2F to /: 10.1666/0094-8373(2003)029<0243:vpasat>2.0.co;2. I guess we could first use normal percent-encoding like before and then use string replacement to change %2F back to /. PrimeHunter (talk) 11:40, 3 July 2018 (UTC)
Argh. Why did they do this? So now, doi urls are fully url encoded and then, the %2F is unencoded back to / (in the sandbox):
Cite journal compare
{{cite journal |doi=10.1666/0094-8373(2003)029<0243:vpasat>2.0.co;2 |title=Title}}
Live "Title". doi:10.1666/0094-8373(2003)029<0243:vpasat>2.0.co;2. 
Sandbox "Title". doi:10.1666/0094-8373(2003)029<0243:vpasat>2.0.co;2. 
Cite journal compare
{{cite journal |doi=10.1088/0004-637X/707/2/916 |title=Title}}
Live "Title". doi:10.1088/0004-637X/707/2/916. 
Sandbox "Title". doi:10.1088/0004-637X/707/2/916. 
Unless there are objections, or improvements to be made, I'll implement this in the next hour or so.
Trappist the monk (talk) 12:32, 3 July 2018 (UTC)
This is a deploy ASAP sort of fix. Headbomb {t · c · p · b} 12:40, 3 July 2018 (UTC)
This is reader impacting, so yes should be done rapidly then monitored. The hour wait for comments should be fine. — xaosflux Talk 13:06, 3 July 2018 (UTC)
Implemented. Remember that articles are cached so any dois that appear 'broken' may not actually be broken; null edits should fix those dois.
Trappist the monk (talk) 13:51, 3 July 2018 (UTC)
It appears to have been a temporary issue at doi.org. The links with %2F are now working again, e.g. https://doi.org/10.1002%2F047084289X.rc003 from my first post which was broken at the time. The modules are used in four million pages and the current versions seem to work so maybe we should just leave them as they are in case doi.org stops supporting %2F again. PrimeHunter (talk) 16:31, 3 July 2018 (UTC)
I have removed the special case code from the sandbox because special case code is a bad thing, but will leave the live version alone unless there is an indication that it is causing problems. At the next update, the special case code will be removed from the live module.
Trappist the monk (talk) 18:09, 3 July 2018 (UTC)

RfC: Ease switching of citations between citation templates or no citation templates[edit]

Please see Wikipedia talk:Citing sources#RfC: Remove the bullet point that starts "adding citation templates..." Jc3s5h (talk) 14:42, 4 July 2018 (UTC)

Is there any interest...[edit]

...in adding a "last-author-and" option, modeled on the "last-author-amp" option, for those who think that the use of an ampersand instead of "and" is too informal for an encyclopedia? Beyond My Ken (talk) 06:58, 5 July 2018 (UTC)

Sure, in that I don't like the lazy "&" either. But I think it would be preferable just to eliminate |last-author-amp=, and have a consistent format.  — SMcCandlish ¢ 😼  07:42, 5 July 2018 (UTC)
But what to do about all those cites which currently use last-author-amp? Beyond My Ken (talk) 01:07, 6 July 2018 (UTC)
Something to remember is that the shortened citations use the ampersand, and for consistency, I use |last-author-amp=. To wit:
  • Doe, John & Roe, Jane (2017). Title. Location: Publisher. p. 1. 
  • Doe & Roe (2017), p. 2.
Additionally, APA Style uses the ampersand, and CS1 is roughly based upon APA style originally. Imzadi 1979  02:48, 6 July 2018 (UTC)

Phase out |vauthors=[edit]

We need to ditch this. All it's doing is producing shite metadata, and people are abusing it to destroy good metadata we already have. I keep having to revert this all the time. |vauthors= is a pointless drain on other editors' time. If someone wants Vancouver-style names, they can do |last1=Ceesdale|first1=AB |last2=Effly|first2=DE ....
 — SMcCandlish ¢ 😼  07:40, 5 July 2018 (UTC)

Do you have evidence that the metadata that derives from |vauthors= is not the same as that produced by |last= |first=?
{{cite book |title=Title |last1=Ceesdale |first1=AB |last2=Effly |first2=DE}}
<cite class="citation book">Ceesdale, AB; Effly, DE. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Ceesdale&rft.aufirst=AB&rft.au=Effly%2C+DE&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"><span style="display:none;">&nbsp;</span></span>
{{cite book |title=Title |vauthors=Ceesdale AB, Effly DE}}
<cite class="citation book">Ceesdale AB, Effly DE. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Ceesdale&rft.aufirst=AB&rft.au=Effly%2C+DE&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"><span style="display:none;">&nbsp;</span></span>
With the exception that Vancouver system style renders name lists slightly differently from cs1|2 style, the metadata for the above examples are exactly the same.
Trappist the monk (talk) 09:09, 5 July 2018 (UTC)
|vauthors= has advanced logic because it expects a very specific format and will throw errors if things are not declared in that format. That's why it can produce the correct metadata. Headbomb {t · c · p · b} 14:33, 5 July 2018 (UTC)
And there's more than one kind of metadata. The template coding itself is meta-data for editors and source-aware readers. Keeping sur- and given names separate is future-proof, and also directly operable upon by tools.

|vauthors= should just be deprecated and replaced with a |vanc= parameter that applies visual output munging to data submitted as parameter information – without loss of actual data; i.e. render |last1=Samuels|first1=Diana R.|vanc=y as Samuels DR, without costing us the full name, which may be the only way to tell one author apart from another without digging around in journal sites that maybe, if you're lucky, will give you the full name.

Any time people convert other citation formats to Vancouver, they cost us information (not just metadata). This makes it pointlessly onerous to convert back (either re-research the sources, or dig back in page history) even when there's a WP:CITEVAR consensus to do so. For this reason, I revert on sight every attempt to convert a cite to Vancouver, unless there's a consensus on the talk page that this article uses Vancouver citation format (which is rare, and I would be prone to challenge it if the article didn't begin in that format). The issue is important enough, I've considered a WP:VPPOL RfC to ban the Vancouver format as antithetical to our goals.

The input needs to be cite-format-neutral or it breaks cross-format compatibility of the raw information. — SMcCandlish ¢ 😼  21:55, 5 July 2018 (UTC)

Maybe this is actually essentially the same proposal as the |af= one below.  — SMcCandlish ¢ 😼  21:58, 5 July 2018 (UTC)

Citations exist to verify the material provided, not to provide full author information every time one cites something. Good metadata benefits is a bonus, not a goal, and this is no different than converting things to "Smith, J." or "J. Smith". That said, see my proposal below. Headbomb {t · c · p · b} 22:00, 5 July 2018 (UTC)
Truncating the author names for no legitimate reason makes that citation verification more difficult. It also makes our metadata work more difficult (e.g. determining whether someone qualifies for an |authorn-link=).  — SMcCandlish ¢ 😼  22:13, 5 July 2018 (UTC)
I like having a |vanc= parameter, provided it's smart enough to extract the proper initials from several forms of input. Also a similar |initials= parameter that displays as "Samuels, D. R." Given both of those then we could push for always encoding the full personal names even where an article's consistent displayed style is initials. And then we could push for phasing out vauthors= and requiring "no loss of data".
Hmmm, could something similar be done for the extremely small number of editors that like small caps ("bluebook" style)? ♦ J. Johnson (JJ) (talk) 23:38, 5 July 2018 (UTC)
I would certainly hope note. That style should just be nuked as a readability problem (and another loss of data: it won't distinguish between the name Devine, which is Irish, and DeVine which is French, or Flemish or something).  — SMcCandlish ¢ 😼  06:37, 16 July 2018 (UTC)
It does? Devine vs DeVine. Headbomb {t · c · p · b} 10:40, 16 July 2018 (UTC)
There is |name-list-format=vanc which has been in place for years. For consistency, all name-lists, author, editor, translator, interviewer are rendered in Vancouver style when |name-list-format=vanc:
{{cite book |title=Title |chapter=Chapter |last=Brown |first=Ralph B. |editor-last=Green |editor-first=A. Gardner |name-list-format=vanc}}
Brown RB. "Chapter". In van Green AG. Title. 
Trappist the monk (talk) 10:40, 6 July 2018 (UTC)
Oh, so the functionality is already present, right? The name is bit putting-offish, though. (I reckon especially for editors that find the templates challenging as it is.) Could we have |vanc=y as a synonym? ♦ J. Johnson (JJ) (talk) 22:37, 6 July 2018 (UTC)
Or |af=vanc so that it scales to other systems if we end up supporting them. Headbomb {t · c · p · b} 22:41, 6 July 2018 (UTC)
That might be better. And, in having the same value as the long-form, easier to implement. ♦ J. Johnson (JJ) (talk) 23:16, 6 July 2018 (UTC)
If I recall correctly the reason for naming |name-list-format= as such was that it includes editors as well as authors, as noted above…or were you considering also having |ef=vanc, |tf=vanc, |if=vanc, etc.? —Phil | Talk 15:06, 9 July 2018 (UTC)
I've commented for a week+ in the mutating thread below, and have to come back to this one: We need a short |vanc=y, even if it just resolves to |name-list-format=vanc (which pretty much no one is ever going to remember or use), the deprecated |vauthors=.  — SMcCandlish ¢ 😼  06:37, 16 July 2018 (UTC)

New parameter: af[edit]

Similar to |df=, it would be immensely useful to have a |af=, covering author format. Right now we have |name-list-format= (which accepts vanc), but that's just awful to remember.

You could have

|last#=Smith |first#=John Howard (or |editor#-last=Smith |editor#-first=John Howard)
Core proposal[1]
Last, First[2] Last First[3] First Last MOS:INITIALS-compliant[4]
|af=Last, First Smith, John Howard
|af=Last First Smith John Howard
|af=First Last John Howard Smith
Any of
|af=MOS Smith, John Howard
Smith, John H.
Smith, J. H.
Extended[5]
Last, First Last First First Last Specific style
|af=Last, F. M. Smith, J. H.
|af=Last, F.M. Smith, J.H.
|af=Last, F M Smith, J H
|af=Last, FM Smith, JH
|af=Last F. M. Smith J. H.
|af=Last F.M. Smith J.H.
|af=Last F M Smith J H
|af=Last FM Smith JH
|af=F. M. Last J. H. Smith
|af=F.M. Last J.H. Smith
|af=F M Last J H Smith
|af=FM Last JH Smith
|af=AMA AMA
|af=APA APA
|af=Bluebook Bluebook
|af=Vancouver Vancouver
Overide
|af#=ignore would ignore validation for |last#=/|first#=/|author#= specifically.[6] This would allow for single-name authors (e.g. |author1=Riazuddin |author2=Fayyazuddin |last3=Rashid |first3=M. A.) and corporate names (e.g. |author=RAND Corporation) without losing the benefits of specific formats (e.g. |af=F. M. Last).
  1. ^ WYSIWYG, but flags errors for mis-abbreviations (|first#=J. H, |first#=J H., |first#=J.H, |first#=JH., |first=J. O.., |first=J. .O, ...), , mis-hyphenations (|first=J. -H., |first=J.- H., |last=Smith -Pelly, ...), mis-punctutions (e.g. |first=Devonte,, |last=Jones.) and mis-capitalizations (|first#=J. h., |first#=j. H., |first#=john Howard, |first#=John h., |last#=smith, ...). It would also report parameter abuse (|last#=Smith, John H., |first#=et al., |first#=Smith, John J.; Jones, M.C.)
  2. ^ Default style, leaving |af= blank is equivalent to this. However, if |af=Last, First is explicitely set, then it will report the use of |author#= instead of |last#= |first#=.
  3. ^ For Asian name order, mostly
  4. ^ Ensures MOS:INITIALS-compliance when initials are used, but does not force initials to be used.
  5. ^ Reports errors for anything not in that style
  6. ^ With |ef#=ignore to ignore validation for |editor#-last=/|editor#-first=/|editor#=.

Those would kick in for authors/editors and format them in the specified manner, e.g.

  • |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=Last, F.M. → Dickinson, E.; Fitzgerald, F.S.K.
  • |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=Last, FM → Dickinson, E; Fitzgerald, FSK
  • |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=F. M. Last → E. Dickinson; F. S. K. Fitzgerald
  • |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=Vanc → Dickinson E, Fitzgerald FS

and throw in error messages when the conversion to the specified format couldn't work.

  • |author1=Emily Dickinson |last2=Fitzgerald |first2=Francis Scott Key |af=F. M. Last → Emily Dickinson; F. S. K. Fitzgerald (Error: |af=F. M. Last requires |lastn=/|firstn= to be used consistently, convert |author1= to |last1=/|first1=.)

or have other issues

  • |last1=Dickinson |first1=E., |last2=Fitzgerald |first2=F. S.K. |af=af → Dickinson, E.; F. S.K. Fitzgerald (Error: |first2= has spacing issues)
  • |last1=Languillat |first1=J. -C → Languillat, J. -C (Error: |first1=J. -C is mis-abbreviated.)
  • |last1=Howard |first1=J. B.C → Languillat, J. B.C (Error: |first1=J. B.C is mis-abbreviated.)

And then we could deprecate the god-awful |name-list-format=. Headbomb {t · c · p · b} 14:30, 5 July 2018 (UTC)

A more flexible solution would be a new parameter, |ao=, or the long version, |author-order=, with the allowable values being
lf
Last name first, last name separated from first name by a comma
ff
First name first
lnf
Last normally first. The author comes from a culture where the family name is normally written first, so no comma is added between the family name and the rest of the name.
Jc3s5h (talk) 15:53, 5 July 2018 (UTC)
The cultural name order, if we need it at all, should be on individual authors not the whole author list. —David Eppstein (talk) 16:06, 5 July 2018 (UTC)
lf/ff and the like are partial solutions at best, and will still produce inconsistent abbreviations. However, I've updated the proposal to include 'cultural' names and use codes to simplify. If something needs to be bypassed for some reason you could have |af3=AF1 to display |last3=Liu |first3=Jianguo one as the Chinese order Liu Jianguo, rather than Western order Jianguo Liu. Headbomb {t · c · p · b} 16:31, 5 July 2018 (UTC)
The only real reason we have |df= is because Citoid, and its engineers, didn't want to fight with date formatting. I would oppose a spread of "X-format" parameters, since no need has been demonstrated here and adds a significant deviation in formatting. (We have the Vancouver formatting to draw Vancouverites trivially into the fold from using |authors=, so I don't see an analog there, either.) --Izno (talk) 17:18, 5 July 2018 (UTC)
@Izno: Here's a typical case where this would be useful. CitationBot adds authors (or the WP:REFTOOLBAR), then editors need to clean them up to bring them in line with the style used. That means hunting down every |first#= manually, and then manually editing everything to use initials, as well as converting |author= to |last=/|first= in the proper format. This also reduces the value of metadata a bit. Applying |af=LF4 to all citations would be so much easier and quicker to bring everything in a consistent format, find errors, and future proof the article's existing citation. User:Citation Bot could then see that |af=LF4 is used in the article, and whenever it adds citations, it could then use |af=LF4 too. (Likewise for Citoid.)Headbomb {t · c · p · b} 18:07, 5 July 2018 (UTC)
You're arguing that a barely-maintained-as-it-is bot could use this? Forgive me if I might be a bit skeptical of that suggested use. :) --Izno (talk) 19:29, 5 July 2018 (UTC)
@Izno: Citation Bot has resumed a normal maintenance cycle for a few while now. Same idea for the WP:REFTOOLBAR and WP:CITOID in general. Either way, even if the bot doesn't use it, adding |af=LF4 (or whichever style) afterwards make cleanup a million times quicker. Headbomb {t · c · p · b} 20:23, 5 July 2018 (UTC)
A maintenance cycle. Not a new-features cycle (this is a new feature). (You'll note that the talk page there says exactly this.) And as for the maintenance, the code developed 6 months ago still has yet to be deployed. Making Citoid aware of the rest of the text on the page isn't in its scope. Nor is reftoolbar's. It might be reasonable to have a {{use author citation style}} and have a script to enforce that, but your point wasn't about that. ;) --Izno (talk) 16:21, 8 July 2018 (UTC)
Why should citoid or the ref toolbar not be updated to make use of the new features? Headbomb {t · c · p · b} 16:39, 8 July 2018 (UTC)
An interesting idea. Supporting all of these variants may result in excessively complex template code and may confuse editors. However I think |name-list-format=CS1 or |af=LF4 would be useful to render |vauthors= in standard CS1 author format in cases where CS1 is the predominate/first established style. Boghog (talk) 19:45, 5 July 2018 (UTC)
Per my thread above this one, I support a simple way to turn on Vancouver formatting without losing underlying data, so we can deprecate (and eventually convert then disable) |vauthors=. However, we don't need this many citation formats. We should be moving toward consistency, not chaos. No one would remember that table of codes, nor use them consistently. We shouldn't have a name output formatting option that isn't either CS1/CS2 as defaults, depending on the template used, or output that is required (not just optional) by a particular major off-site citation style – one that can be reliably sourced in detail and as in current use, e.g. listed in Turabian, or as the mandatory style of some major journal publisher, or otherwise neither WP:NFT nor obsolete. That is, if the citation style permits either "Chung, Margaret T." or "Chung, M. T." then we need no option to truncate to the latter (unless that abbreviated form is a hard requirement in some other cite style ). We have no editorial or reader interest in truncating the name data if not forced to do so. We likewise have no reason for any MOS:INITIALS-defying formats (without the dots and/or spaces), absent a hard requirement like Vancouver's "Chung MT".  — SMcCandlish ¢ 😼  22:10, 5 July 2018 (UTC)
I'm not saying all the above absolutely need to be supported natively, but all those styles are used somewhere and we could support them per WP:CITEVAR. The cost of not supporting them will be: they'll still be used, you still won't be able to change them per WP:CITEVAR, and you won't be able to get the full benefits of error checking / metadata that comes with supporting them. Headbomb {t · c · p · b} 22:24, 5 July 2018 (UTC)
Re "you still won't be able to change them per WP:CITEVAR": bullshit. CITEVAR says only to first seek consensus. It doesn't even require consensus, only to first seek it. Having |af= is a good idea, but invoking CITEVAR drama to argue a piddling detail is not helpful. ♦ J. Johnson (JJ) (talk) 19:44, 8 July 2018 (UTC)
I meant on a mass scale, not individual articles. Headbomb {t · c · p · b} 19:59, 8 July 2018 (UTC)
There are a variety of reason why some editors support CITEVAR, one of those reasons is that if you're familiar with a particular citation style, such as APA, it's easier to type it than to type a template. It also makes the wikitext shorter, and thus easier to edit. I don't know anything about Vancouver, but for most of the time that citation templates have existed, they did not produce the same appearance as any external style guide. Thus, the question of whether it would be acceptable to change an article that didn't use citation templates and consistently followed an external style to templates that produced the same appearance never arose. It isn't at all clear that such a switch would be accepted. Jc3s5h (talk) 23:07, 5 July 2018 (UTC)
Well, you can still do it all by hand manually if you want. But that means lots of manual cleanup after bots whenever someone adds something. Headbomb {t · c · p · b} 00:44, 6 July 2018 (UTC)

Refined proposal[edit]

I took the feedback from above, and refined the proposal. I've separated the outputs into those that are MOS:INITIALS-compliant and those that aren't, and got rid of the obscure 'codes' in favor of obvious things people don't need to remember or look up. The ideal solution (maybe this would be possible with WP:TemplateStyles) would be to declare one what the author format is once (e.g. {{reflist|af=Last, F. M.}}), and have citations inherit the style from there, but failing that a (non-mandatory, of course) |af= in the citation themselves would allow to have much of the same effect. Headbomb {t · c · p · b} 00:49, 6 July 2018 (UTC)

I hope that this is not done. It would considerably complicate the templates, for no gain in expressiveness. It would also give people a whole new set of knobs to fiddle with and argue over. Kanguole 22:41, 7 July 2018 (UTC)
@Kanguole: Not really no. The current situation is a huge mess which is incredibly hard to cleanup. In the same article you'll have a mix of |last=Smith/|first=J.F., |author=John Smith, |last=Smith/|first=JF and |last=Smith/|first=John. Often in the same citation. This isn't a proposal to deploy those by bots, but to allow humans to more easily standardize citation articles and clean them up when they need to be, and help bots respect an existing style. Headbomb {t · c · p · b} 22:51, 7 July 2018 (UTC)
For example, compare Special:Permalink/842230702#References with Sex_manual#Modern_sex_manuals. This is the diff required to make that happen, and involves reviewing every citation. Now if someone uses the ref toolbar to add doi:10.1080/00224490509552267, you'll have DeLamater, John D.; Sill, Morgan (May 2005). "Sexual desire in later life". Journal of Sex Research. 42 (2): 138–149. doi:10.1080/00224490509552267. , which again breaks the style, and needs a cleanup edit. This could be made much, much easier by simply adding |af=Last, F. M., rather than changing |last1=DeLamater |first1=John D. |last2=Sill |first2=Morgan to |last1=DeLamater |first1=J. D. |last2=Sill |first2=M. manually. Headbomb {t · c · p · b} 23:17, 7 July 2018 (UTC)
If this can be mostly automated, but a human needs to decide which correction to apply to which citation, maybe someone could write some sort of script or app where the wikitext is parsed, the correction possibilities put next to each citation, and the editor checks which correction to apply to each citation. Then a new version of the wikitext, compatible with the existing citation module, is saved. Jc3s5h (talk) 23:06, 7 July 2018 (UTC)
I think we should not provide more options for last/first ordering. Having the name of the lead author in "last-first" order is pretty much the standard for lexicographical ordering; the variance among styles has been whether coauthors should be first-last or last-first (inverted). In that we have a predominant "last-first" style we should lean towards having that a consistent standard.
To the argument that providing a "first-last" option will encourage some number of (probably extremely few) editors to use templates: I think it is more likely to enable expanded use of "first-last" ordering, and make citations less consistent. Other options are available to persuade (or simply coerce) use of templates; this option would create other problems.
On the otherhand, dealing with initialization would, indeed, be immensely useful. Inconsistent use (within an article) of first names versus initials only is annoying. But while I favor having first names, on some topics I have so many sources (usually journals) that supply only initials that the work digging out complete names dissuades me from providing first names even where I do have them. With something like |af=initials I could supply what I have, and the article could be consistent using just initials.
Anyway, supplying a pattern is too complex. Let the parameter values (options) be:
  • default: |firstX= displayed as specified (first name, middle initials, "Jr.", etc.).
  • |af=initials: initial (with period) of first name, with middle initials.
  • |af=vanc: displayed in Vancouver style.
  • |af=bluebook (or |af=caps): last name in small-caps.
With due respect to AMA style, I think we should consistently use a comma following the surname. That is an aid to the reader in showing that the ordinary (in English) first-last order has been inverted, and also distinguishes compound surnames. ♦ J. Johnson (JJ) (talk) 19:51, 8 July 2018 (UTC)
Regarding |af=initials, it is indeed untidy to have full names for some authors and only initials for others, and, as you say, sometimes that's all that is available. But tidying that up by uniformly displaying only initials would be hiding information that could be useful to readers. Kanguole 09:29, 9 July 2018 (UTC)
The underlying question is: how important is consistency in using initials (in lieu of first names) or not? If consistency is important, then is it better to merely "hide" (not display) information? Or not include it at all? Having this option means that consistency can be readily arranged if someone insists on it, without real loss of information. Which the s/w can still access, and allows incremental augmentation. ♦ J. Johnson (JJ) (talk) 21:56, 9 July 2018 (UTC)
The point is to accommodate all the valid styles (or at least the MOS-compliant ones), and help achieve those consistently, not to force an artificial preference for one style over the other. We should not force people to use full first names when they don't want to. If you want to supply them, that's allowed. If you want to initialize, that's allowed too. No one needs full names to find a citation, unless the information provided is grossly incomplete. Headbomb {t · c · p · b} 13:46, 9 July 2018 (UTC)
A reader might well be interested in knowing which "A. Jones" is being cited as an authority for a particular statement. If the full name is already in the wikisource, it is unhelpful to hide it. Kanguole 14:21, 9 July 2018 (UTC)
That's a matter for prose, distinct from referencing matters. Again, "Jones, Alphonso" is allowed in references but so is "Jones, A." and if that's the style the article uses, there is no reason not to support it, and WP:CITEVAR applies. Headbomb {t · c · p · b} 16:25, 9 July 2018 (UTC)
@Kanguole: added a "MOS style". Headbomb {t · c · p · b} 17:48, 9 July 2018 (UTC)

Further refined proposal[edit]

I took the feedback from both sections above, and I realize this was turning into something way more complicated than it needed to be. So instead, I've refocused this into something more straightforward, focusing on flagging downright errors at 99% case use, rather than minor style variations (but still allowing them).

  • The default case (|af= left empty) would simply verify that |last#=/|first#=/|author#= are not wrong. It would report a variety of issues like bad hyphenation (|first=J.- H., bad abbreviations (|first=J. H, bad capitalizations |first=J. h., or bad punctuation (|first=John,. No error messages are thrown if you have a mixture of "Smith, John H." and "Jones, A. F.".
  • Using a specific order (|af=First Last simply displays the first/last names in that order, checks that the parameters themselves are not wrong, and makes sures that |last#=/|first#= is not mixed with |author#=. This can be overridden by |af#=ignore so single names / corporate names can still be used.
  • For the MOS:INITIALS-centric, |af=MOS would ensure that initials, if used, would be in the MOS-format. This can help catch inconsistent abbreviations, when used (e.g. |first1=J.H. + |first2=A F), but does not force abbreviations to be used.
  • For those with a specific abbreviation style in mind, they can use |af=Last, F. M. or |af=F.M. Last or whatever to present things in that specific format. If |af=F.M. Last is used, both |last=Smith |first=John H. / |last=Smith |first=J. H. are presented as J.H. Smith. Errors are only reported when the parameters themselves are wrong or the output cannot be presented in the specified format.

Headbomb {t · c · p · b} 19:17, 9 July 2018 (UTC)

@David Eppstein, Izno, Boghog, SMcCandlish, Jc3s5h, J. Johnson, Kanguole, and Trappist the Monk: Headbomb {t · c · p · b} 19:30, 9 July 2018 (UTC)
When you say "report a variety of issues" do you mean that the template would not properly function for names with those issues, or merely that the article would be thrown into a maintenance category? Not working for single-letter-but-unpunctuated names would be bad for people like U Thant. —David Eppstein (talk) 20:19, 9 July 2018 (UTC)
Or J Harlan Bretz. ♦ J. Johnson (JJ) (talk) 22:00, 9 July 2018 (UTC)
@David Eppstein: I mean that the template would keep displayed things as best it could and throw error messages when things were wrong or couldn't display them in the specified format. For single name authors like Thant, |author#=Thant is all that's needed (or possibly |author#=U Thant if the honorific is needed, although we don't usually include those). But let's say there's someone out there with the first name O and a last name of Johnson, well there's nothing wrong with |last=Johnson |first=O, so there wouldn't be any errors shown there. You would get an error if you specified |af=MOS, but it's something you could overide with |af#=ignore. Headbomb {t · c · p · b} 20:36, 9 July 2018 (UTC)
This seems over-complicated (and don't forget cases like Jennifer 8. Lee). For one thing |af=MOS should be a default not an option; MoS applies to citation material except when a citation style requires (not just optionally permits) a variance from it, and that citation style is used consistently in the article (and even then we might have a consensus discussion to change it). Second, we don't need to throw errors for trivial problems, except maybe in preview mode. Better to have a cleanup category and may be WP:GENFIXES deal with it.  — SMcCandlish ¢ 😼  22:05, 9 July 2018 (UTC)
|af=MOS being the default would lead to hundreds of thousands of errors for perfectly valid styles. So no, we can't make that default. And cases like Jennifer 8. Lee are not forgotten, that's what |af#=ignore is for. Headbomb {t · c · p · b} 22:08, 9 July 2018 (UTC)
Which brings me right back to "This seems over-complicated". I.e., I don't think anyone's going want to try to learn and remember all this stuff. The more unnecessary complications we add to cite templates the more we drive people away from them. This is one of the reasons I started thread above this one; vauthors is an unnecessary divergence from how to enter author data, so it needs to go away (even aside from metadata loss problem).  — SMcCandlish ¢ 😼  06:41, 16 July 2018 (UTC)
As I said above: I think we should not provide more options for last/first ordering (or what it boils down to: inverting, or not, co-author names). As an inducement for using templates it is very slight, and likely quite unnecessary, and it opens a prospect of greater inconsistency.
As a general rule: option codes in the nature of patterns would be too complicated, and way too intimidating for most editors. Also, "FirstLast" would be better than "First Last" (because the included space makes it look like two values). But like I said, name order should not be a formatting option. ♦ J. Johnson (JJ) (talk) 22:03, 9 July 2018 (UTC)
"Option codes in the nature of patterns would be too complicated, and way too intimidating" quite the opposite. They make it crystal clear what the pattern is, and are completely optional. Don't what to deal with them? Don't use them. They won't be used in the majority of cases but will make gnome life much, much easier. Headbomb {t · c · p · b} 22:13, 9 July 2018 (UTC)
Some of the resistance to citation templates is based on a perception of complexity, which this proposal would exacerbate.
Not using these features would not avoid their costs. Editors need to read wikitext added by others. Watchlists will be full of fiddling with these display parameters, and talk pages full of arguments about the best settings for them, all irrelevant to content. Kanguole 22:39, 9 July 2018 (UTC)
I tend to agree with Kanguola that the templates are already too confusing to use manually (and if you can't use the templates without having additional software to help, something is wrong). The cryptic abbreviated parameter names do not help. But, taking a step back to look at the bigger picture: we already have too much variation in allowed reference formatting. We should be working to reduce that variation. Instead, this proposal encourages us to vary even more. —David Eppstein (talk) 22:56, 9 July 2018 (UTC)
Yes. Aside from supporting major "styles" with significant usage on Wikipedia, we should be reducing variation that does not serve a useful purpose. Particularly: as the standard order of author names here is last-first (inverted), we should not enable a variant usage of no significant value.
The complexity problem is not entirely the template options themseles, but the documentation. Those of a gnomish bent won't know of the options unless they are documented, and then everyone else gets lost in all the arcane detail. ♦ J. Johnson (JJ) (talk) 19:23, 10 July 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── You can wish the templates/people worked in a way until you're blue in the face, the fact remain that people use them and errors creep in. For instance, in Jyoti Bhusan Chatterjea you have the following

  • A, K, Basu (2017). "Obituary". Calcutta School of Tropical Medicine. 

Should we do nothing? Or should we tell people "Hey, this is not how you should use |last="? This way the error can be fixed and the citation turned into a proper:

  • Basu, A. K. (2017). "Obituary". Calcutta School of Tropical Medicine. 

This sort of error checking would lead to vast amounts of citation improvements and fixes. For instance, the very basic error of the type |last=J. are so numerous you cannot find them all with straightfoward searches (Search for insource:/last *= *[A-Z]\./).

Also the parameters values are not cryptic, they are explicit in what the format should be. If you've got better names for parameter values, put them forward, but I don't feel you could be clearer. Headbomb {t · c · p · b} 23:16, 9 July 2018 (UTC)

You are mixing together error checking of parameter values and tweaking formatting of the displayed output. Surely these should be orthogonal issues. Kanguole 23:39, 9 July 2018 (UTC)
@Kanguole: Sure, but both are related. Quark uses "F.M. Last" format. Why should we forgo error checking and full name metadata simply because the author format isn't the default one? Or require that editors spend more time than needed reviewing every new citation added to ensure this format is respected? Headbomb {t · c · p · b} 00:00, 10 July 2018 (UTC)

Add parameter archive-chapter-url or suitable synonym[edit]

In cases where we have values for both |url= and |chapter-url= but we need to use an archived copy—particularly of the latter—there is no current way to indicate that the archive link relates to the Chapter not the Book as a whole. I have just seen a case where the Book url is still active but the Chapter url is not, which might complicate things somewhat, I don't know. What should be my recourse in such a situation and would it help to have this extra parameter? TIA HAND —Phil | Talk 15:23, 9 July 2018 (UTC)

When it is appropriate for Module:Citation/CS1 to apply the url held by |archive-url= to a title, it is applied to the most specific title in the cs1|2 template. So, for your example when the template has both |url= with |title= and |chapter-url= with |chapter= (or any of the several aliases of these), Module:Citation/CS1 applies |archive-url= to the title held by |chapter= (or alias). I think that this is a relatively rare case (someone might do some research and prove me wrong). We might, if there is sufficient call to do so, reword the archive static text so that it names the chapter-alias parameter when both |url= and |chapter-url= (or alias) is 'dead'.
Trappist the monk (talk) 15:59, 9 July 2018 (UTC)

Protected edit request on 10 July 2018[edit]

Change the word "forth" to "fourth" in the 3 instances where "forth" is used instead of "fourth". These three instances are found in the "last name 4", "first name 4", and "author link 4" sections in the template parameters chart under the TemplateData header Mc mccullough (talk) 18:28, 10 July 2018 (UTC)

 Done Imzadi 1979  18:39, 10 July 2018 (UTC)

Fix the date formatting[edit]

Can you fix the date formatting please? It's been this way for years:

  • If Source Date is "2017", it's fine.
  • If Source Date is "2017-09-15", it's fine
  • If Source Date is "September 2017", it's fine
  • If Source Date is "2017-09" (which is generated automatically by the citation tool!) then it complains "Check date values...".

This is broken; it should accept any ISO 8601 date (especially if it's generating them itself from the DOI!) — Omegatron (talk) 13:14, 14 July 2018 (UTC)

See MOS:BADDATE, where "2001-07" is listed as one of the unacceptable date formats because it is ambiguous. It could mean "July 2001", or it could mean "2001–2007", so you need to use a different format.
I encourage you to report this bug in the citation tool at the tool's talk page. – Jonesey95 (talk) 13:27, 14 July 2018 (UTC)
Yep.  — SMcCandlish ¢ 😼  06:30, 16 July 2018 (UTC)
It means "July 2001". The whole point of ISO 8601 is that it's not ambiguous. If you mean 2001–2007, then write "2001–2007" (but that doesn't make sense for a source date anyway) — Omegatron (talk) 21:43, 21 July 2018 (UTC)
cs1|2 accepts the date formats that are permitted by MOS:DATE. When MOS:DATE changes, so shall cs1|2; arguing the point here will do you no good. If you believe that MOS is in the wrong, I would recommend that you raise the issue at WT:DATE. But, this is not a new topic so a perusal of that talk page's archives would not go amiss.
Trappist the monk (talk) 21:54, 21 July 2018 (UTC)

Ordering of "publisher" parameter by 'cite news' template[edit]

@Doug butler: For some time, along with other Australian users, I've been using the {{cite news }} template for citing articles in the National Library of Australia's Trove collection of 100 million historic newspaper articles, e.g. for the article Blessing of the Fleet:

{{cite news |url=http://nla.gov.au/nla.news-article69884640 |title=Blessing the Fleet |newspaper=[[The Advocate (Tasmania)|The Advocate]] |location=Burnie, Tas. |date=2 February 1954 |accessdate=20 November 2012 |page=2 |publisher=National Library of Australia}}

At the time it worked fine. It used to give:

"Blessing the Fleet" The Advocate. Burnie, Tas. 2 February 1954. p. 2. National Library of Australia. Retrieved 20 November 2012.

Now I suddenly find that the order of the parameters in the output has changed, giving:

"Blessing the Fleet" The Advocate. Burnie, Tas.: National Library of Australia. 2 February 1954. p. 2. Retrieved 20 November 2012.

The "publisher" parameter now appears immediately after the newspaper title, instead of after the details of the original publication date and page number, and before the retrieval date. How can this be fixed? Cheers, Bahudhara (talk) 02:14, 16 July 2018 (UTC)

Unless the National Library of Australia is the organization that originally published that newspaper, it should not be listed as publisher. Use |via= instead:
{{cite news |url=http://nla.gov.au/nla.news-article69884640 |title=Blessing the Fleet |newspaper=[[The Advocate (Tasmania)|The Advocate]] |location=Burnie, Tas. |date=2 February 1954 |accessdate=20 November 2012 |page=2 |via=National Library of Australia}}
"Blessing the Fleet". The Advocate. Burnie, Tas. 2 February 1954. p. 2. Retrieved 20 November 2012 – via National Library of Australia. 
(Also, Tasmania should probably be spelled out.) —David Eppstein (talk) 03:03, 16 July 2018 (UTC)
THanks! Cheers, Bahudhara (talk) 03:10, 16 July 2018 (UTC)

(edit conflict)

Are you sure? I am highly skeptical that publication |date= would ever have been placed between |location= and |publisher= (as illustrated by your first example) because these latter two are intended to be paired (the colon separator is unique to these two parameters). To see what the historic renderings actually looked like, I went to archive.org and looked at a handful of archives of Blessing of the Fleet. I have copied here the raw text of your example citation from those archived pages at these dates:
  • 2014-07-11:
    Stanley, Tasmania 1950's "BLESSING THE FLEET.". Advocate (Burnie, Tas. : 1890 - 1954) (Burnie, Tas.: National Library of Australia). 2 February 1954. p. 2. Retrieved 20 November 2012.
  • 2015-03-20:
    Stanley, Tasmania 1950's "BLESSING THE FLEET.". The Advocate (Burnie, Tas.: National Library of Australia). 2 February 1954. p. 2. Retrieved 20 November 2012.
  • 2016-09-11:
    Stanley, Tasmania 1950's "BLESSING THE FLEET.". The Advocate. Burnie, Tas.: National Library of Australia. 2 February 1954. p. 2. Retrieved 20 November 2012.
  • 2017-05-12:
    Stanley, Tasmania 1950's "BLESSING THE FLEET.". The Advocate. Burnie, Tas.: National Library of Australia. 2 February 1954. p. 2. Retrieved 20 November 2012.
  • current article (at the time of this writing):
    Stanley, Tasmania, 1950s "Blessing the Fleet". The Advocate. Burnie, Tas.: National Library of Australia. 2 February 1954. p. 2. Retrieved 20 November 2012.
For this citation, it looks to me like the date has always followed publisher. As it should.
Trappist the monk (talk) 03:21, 16 July 2018 (UTC)

Quotation mark spacing templates[edit]

I've seen (extensively) at The Hunger Games (film) and (rarely) at other articles some markup lile this: |title={{-'}}The Hunger Games' Review. Is this okay or not okay for the resultant COinS metadata? It seems like a lame idea anyway; it should just be converted to italics per MOS:CONFORM: |title=''The Hunger Games'' Review. (The purpose of the {{-'}} template is to kern the single quote away from the surrounding double quote for legibility.)  — SMcCandlish ¢ 😼  06:27, 16 July 2018 (UTC)

cs1|2 does kerning internally without the need for those templates:
{{cite news |title='The hunger Games' Review}}
"'The hunger Games' Review". 
{{-'}} renders to:
<span style="padding-left:0.2em;">&#39;</span>
When {{-'}} is part of |title=, it ends up in the metadata as:
&rft.atitle=%3Cspan+style%3D%22padding-left%3A0.2em%3B%22%3E%26%2339%3B%3C%2Fspan%3EThe+hunger+Games%27+Review
which should be:
&rft.atitle=%27The+hunger+Games%27+Review
Trappist the monk (talk) 09:34, 16 July 2018 (UTC)

Clearing out ASIN when ISBN is present by bot[edit]

It would be pretty straightforward to use User:CitationCleanerBot to remove |asin= when |isbn= is already set, per Help:CS1#Identifiers (guidance for |asin=). Any objection to this [7]? Headbomb {t · c · p · b} 14:51, 18 July 2018 (UTC)

I don't object to the task, but CitationCleanerBot has been making a lot of some mistakes. I recommend a new BRFA and a release of the source code so that the community can help you find and fix these bugs. – Jonesey95 (talk) 15:07, 18 July 2018 (UTC)
Code is too variable to be useful for review, I tweak it on a per-run basis. Most (if not all) of the errors happen when encountering entirely new scenarios, or leaving on a setting that was meant to be disabled by accident, or T159958. But it's pretty easy to file a BRFA for this one though, since it's a bit different than simply cleaning up what is already there. Headbomb {t · c · p · b} 15:17, 18 July 2018 (UTC)
Filed. Headbomb {t · c · p · b} 15:38, 18 July 2018 (UTC)

CSS for citation templates[edit]

Template styles has been enabled on en.wiki so I've begun experimenting with it. I have created Module:Citation/CS1/style.css and added rules that apply the access indicator icons in place to the normal external link icon. The distinct advantage to this is that the wrapping issue that has plagued us (url on one line and the icon on the next) is solved.

Cite book compare
{{cite book |title=Title |pmc=12345 |url-access=subscription |url=//example.com}}
Live TitlePaid subscription required. PMC 12345Freely accessible. 
Sandbox Title. PMC 12345. 

We should think about this and spend some time getting the rules right. I don't know how many other wikis have template styles. If only a few have it, then perhaps we should not use this here because these modules are used on a lot of other wikis.

Trappist the monk (talk) 12:13, 20 July 2018 (UTC)

Apparently, TemplateStyles will be enabled on all wikis 9 August 2018; see phab:T199909.
Trappist the monk (talk) 11:35, 21 July 2018 (UTC)

Could you have a way of having those icons display if we suppress external link icons normally? I can only see them if I disable this. Maybe this could be done via a different class, like external-access, or some other way that would let us suppress the normal external link icons, but keep the access ones? Headbomb {t · c · p · b} 00:23, 20 July 2018 (UTC)

I am not a css expert so I don't know if what you want can be accomplished. I don't even know if the rules in Module:Citation/CS1/style.css are properly formed. As I understand it, rules marked by !important override any other applicable rules regardless of when those rules occur.
The rendered html for the title link of this template:
{{cite book/new |title=Title |url=//example.com |url-access=subscription}}Title. 
looks like this:
<span class="cs1_lock_subscription"><a rel="nofollow" class="external text" href="//example.com"><i>Title</i></a></span>
Your rule:
a.external { background:none !important; padding:0 !important;}
unconditionally overrides the template style css because !important. I don't know where class external is defined (it isn't in MediaWiki:Common.css) perhaps it is possible to override something there?
When your rule is enabled, do you see the pdf icon here: [8]
Trappist the monk (talk) 12:13, 20 July 2018 (UTC)
Nope, PDF icon is hidden, and that's the way I like it, since it's redundant with (PDF) that's automatically appended. Headbomb {t · c · p · b} 20:22, 20 July 2018 (UTC)
Avoid the use of important. It basically defeats the purpose of Template Styles. As for external, that class is applied by MediaWiki core to any external link (when not provided for by an inter-site link like [[example:example]]--I am not sure what class those links get). --Izno (talk) 14:51, 20 July 2018 (UTC)
Indeed, !important is a cop-out - usually it's better to increase the specificity of the selector. Imagine if all rules used !important and you needed to override one - there are no levels of importance, nothing that is treated as "more important than !important". --Redrose64 🌹 (talk) 18:39, 20 July 2018 (UTC)
Well !important works. You're free to suggest alternatives that also work, because I have no idea what "increasing the specificity" means, or would look like. Headbomb {t · c · p · b} 20:22, 20 July 2018 (UTC)
In a rule like
a.external {
  background: none !important;
  padding: 0 !important;
}
the part before the opening brace is the selector. A selector like a matches all <a>...</a> elements; a selector like .external matches all elements belonging to the class external, and the selector a.external matches all <a>...</a> elements belonging to the class external. Since this third one matches on two conditions which must both succeed, this is more specific than either of the selectors a or .external used alone. See Calculating a selector's specificity. The !important annotation artificially boosts the specificity in a manner that is difficult to override. See Cascading. --Redrose64 🌹 (talk) 22:41, 20 July 2018 (UTC)
Seems like this is pretty much what [9] this rule was. Specifically matching a.external. What I'm asking for here is a way of not matching the access locks, while still matching the other useless icons. If !important gets in the way of that, it's easy enough to remove I suppose, but that still leaves the problem of matching (or not matching) the locks. 03:12, 21 July 2018 (UTC)
Perhaps someone with a better grasp of the intricacies of css can see how this sort of works and can tweak it so that it does:
a.external:not(.cs1_lock_free) {
  background: none;
/*  padding: 0;
*/
}
For me, and my browser, the above hid the normal external link icon but showed all of the access icons; I would have expected only the green access icon to be displayed. Without padding: 0;, there is a significant gap between the link and the next text character where the default external link icon would be were it displayed. If background: none; why the space? If I uncommented padding: 0;, the lock icons moved left to overlap the text. Text adjacent to the blank external link icon also moved left to fill the blank space so that the text renders nicely.
Trappist the monk (talk) 12:21, 21 July 2018 (UTC)
@Trappist the monk: Wouldn't ".cs1_lock_free" only apply to the free lock? If not, that should probably be renamed to .cs1_access_locks or just cs1_locks. Headbomb {t · c · p · b} 14:21, 21 July 2018 (UTC)
The
a.external:not(.cs1_lock_free)
was an experiment. I expected that the only visible icon would be the green; all others I expected to be hidden. That expectation was not met because, for me, only the normal external link icon was hidden; subscription and free icons were displayed.
Trappist the monk (talk) 14:52, 21 July 2018 (UTC)

CSS class for ref=none[edit]

The above foray into TemplateStyles and CSS reminded me of something I've been meaning to bring up here.

I have user script (User:Xover/HarvErrors.js, forked from User:Ucucha/HarvErrors.js; feel free to use it, but it reflects my personal ideosyncrasies so you may prefer the original even though it's unmaintained), to do some sanity checks on an article's citations: primarily by flagging short cites that point at a non-existant reference, and flagging full references that are not actually cited in the article. Like Ucucha's original it does this by looking at what ID's short cites link to, and then add a CSS class and an error message to the relevant short or full cite. Mostly works well, but falls down whenever the cite templates are used for non-ref purposes: typically in a list of works or Further reading section.

Would it be possible to make the CS1 templates output a unique CSS class for invokations with |ref=none? That would let me distinguish cites that are explicitly set to not have an ID from cites that merely omit |ref= and not flag these as errors. The class could of course be anything: cs1-ref-none for example.

Signalling various internal states and flags from the templates using CSS classes is also a good way to make them available to user scripts in general: every unique error or warning emitted today could beneficially be tagged with something like cs1-error-nnn. I'm sure there are other use cases, all boiling down to making it easy for user scripts (or Gadgets) to grab structured information about citation templates in an article).

Thoughts? Any interest? --Xover (talk) 09:12, 21 July 2018 (UTC)

While on the topic, why does only {{citation}} have |ref=harv built in them by default? This should be standard across all templates. Headbomb {t · c · p · b} 12:54, 21 July 2018 (UTC)