Help talk:Citation Style 1/Archive 44

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

{{Cite book}} includes an ASIN parameter. The documentation says not to use this when other identifiers are available, but this is widely abused. Example: [1] - 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)

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 261894, PMID 14624257, the alignment of the icon with the text really isn't great: (see [2]).

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	PMC1	PMC1	PMC1	PMC1	PMC1
new	PMC1	PMC1	PMC1	PMC1	PMC1	PMC1

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. [] (monobook, see [3]), or PMC1 [] (vector, see [4]). 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>]

[[5]]

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

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)

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:

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

—Trappist the monk (talk) 15:06, 10 June 2018 (UTC)

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. {{cite book}}: Text "something" ignored (help)

{{Cite book/new |title=Title |something |author1=Brown |author2=Red |author3=Orange}}

Brown; Red; Orange. Title. {{cite book}}: 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)

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) (lecture). Valedictory Lecture as Montague Burton Professor of International Relations. 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)

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)

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)

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)

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)

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)

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! -- SzMithrandir ❈ Ered 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" ? -- SzMithrandir ❈ Ered 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)

See

• Chase D. Brownstein (2018). "Trace fossils on dinosaur bones reveal ecosystem dynamics along the coast of eastern North America during the latest Cretaceous". PeerJ. 6: e4973. doi:10.7717/peerj.4973. PMC 6001717. PMID 29910985.

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

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)

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)

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)

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)

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)

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:

• Template:Citation Style documentation/id2
• Template:Citation Style documentation/id1
• Template:Citation Style documentation/display

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)

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. ISBN 0471936235.

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" (PDF). Paleobiology. 29 (2): 243–255. doi:10.1666/0094-8373(2003)029<0243:vpasat>2.0.co;2. JSTOR 4096832. S2CID 46619244.

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

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)

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

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)

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

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)

This edit request to Template:Cite magazine has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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)

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

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.15em;">&#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)

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)

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 [6]? 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)

Cleared what I could. Category now has around ~400 cases, down from ~1400. Headbomb {t · c · p · b} 13:25, 25 July 2018 (UTC)

{{Cite magazine}} does not include rft.volume or rft.issue as promised in its doumentation. I ran into this issue at Moonrise, Hernandez, New Mexico with refs 17 and 15. Simplified, they are

• di Cicco, Dennis (November 1991). "Dating Ansel Adams' Moonrise". Sky & Telescope. Vol. 82, no. 5. pp. 529–33. ISSN 0037-6604.
• Callahan, Sean (January 1981). "Short Takes: Countdown to Moonrise". American Photographer. Vol. 6. pp. 30–31. ISSN 0161-6854.

They produce

• title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Dating+Ansel+Adams%27+Moonrise&rft.pages=529-33&rft.date=1991-11&rft.issn=0037-6604&rft.aulast=di+Cicco&rft.aufirst=Dennis&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMoonrise%2C+Hernandez%2C+New+Mexico"
• title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Short+Takes%3A+Countdown+to+Moonrise&rft.pages=30-31&rft.date=1981-01&rft.issn=0161-6854&rft.aulast=Callahan&rft.aufirst=Sean&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMoonrise%2C+Hernandez%2C+New+Mexico"

Both are mtx%3abook rather than mtx%3ajournal (rft.btitle versus rft.jtitle). The first has wikimarkup in |magazine=, so maybe it could mess up, but the second example does not (it did have a |url= parameter that I removed). Glrx (talk) 21:22, 25 July 2018 (UTC)

Fixed in the sandbox I think:

• '"`UNIQ--templatestyles-0000007D-QINU`"'<cite id="CITEREFdi_Cicco1991" class="citation magazine cs1">di Cicco, Dennis (November 1991). "Dating Ansel Adams' Moonrise". ''[[Sky & Telescope]]''. Vol.&nbsp;82, no.&nbsp;5. pp.&nbsp;<span class="nowrap">529–</span>33. [[ISSN (identifier)|ISSN]]&nbsp;[https://search.worldcat.org/issn/0037-6604 0037-6604].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Sky+%26+Telescope&rft.atitle=Dating+Ansel+Adams%27+Moonrise&rft.volume=82&rft.issue=5&rft.pages=%3Cspan+class%3D%22nowrap%22%3E529-%3C%2Fspan%3E33&rft.date=1991-11&rft.issn=0037-6604&rft.aulast=di+Cicco&rft.aufirst=Dennis&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+44" class="Z3988"></span>
• '"`UNIQ--templatestyles-0000007F-QINU`"'<cite id="CITEREFCallahan1981" class="citation magazine cs1">Callahan, Sean (January 1981). "Short Takes: Countdown to Moonrise". ''American Photographer''. Vol.&nbsp;6. pp.&nbsp;<span class="nowrap">30–</span>31. [[ISSN (identifier)|ISSN]]&nbsp;[https://search.worldcat.org/issn/0161-6854 0161-6854].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=American+Photographer&rft.atitle=Short+Takes%3A+Countdown+to+Moonrise&rft.volume=6&rft.pages=%3Cspan+class%3D%22nowrap%22%3E30-%3C%2Fspan%3E31&rft.date=1981-01&rft.issn=0161-6854&rft.aulast=Callahan&rft.aufirst=Sean&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+44" class="Z3988"></span>

—Trappist the monk (talk) 21:47, 25 July 2018 (UTC)

Thanks. Glrx (talk) 22:43, 25 July 2018 (UTC)

Incidentally, are there any user scripts or tools that parses and displays COinS here? It would be useful as a visual/manual sanity check when editing, and it might make user scripts that flag citation problems able to flag more issues intelligently. --Xover (talk) 08:13, 26 July 2018 (UTC)

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)

No interest in this then? Not even anyone opposed to the idea? What if I tried to mock up an implementation in the sandbox? --Xover (talk) 08:01, 26 July 2018 (UTC)

According to this search, |ref=none isn't much used. This might explain the lack of interest in a change that would benefit one or only a handful of editors.

—Trappist the monk (talk) 11:12, 26 July 2018 (UTC)

Oh certainly. Why would anyone use |ref=none now? It's just extra wikicode to no apparent effect. It's a chicken and egg thing. But I was kinda hoping that the editors who hang out here might see the value of being able to distinguish the absence of |ref= from an explicit |ref=none, in a way that lets user scripts like User:Ucucha/HarvErrors.js (or my fork of it at User:Xover/HarvErrors.js, or the ref checker someone over at FAC is working on, name escapes me at the moment and I'm too lazy to check) detect it. --Xover (talk) 15:48, 26 July 2018 (UTC)