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.
It's a periodical that doesn't have a |title=, maybe it could be renamed "periodical with the title parameter set to none" but it seems unnecessary. -- LCU ActivelyDisinterested«@» °∆t°19:47, 11 February 2025 (UTC)
If that's the intent of the category, that would be a much clearer name. And it should be a tracking category, not a maintenance one. Headbomb {t · c · p · b}20:29, 11 February 2025 (UTC)
Where these no title in a "Book review" section it vod be useful to have it suppressible, but references are for ten aid of verification having no title isnt helpful to the majority of Wikipedia's readers. -- LCU ActivelyDisinterested«@» °∆t°22:49, 11 February 2025 (UTC)
A bit of history: |title=none and Category:CS1 maint: untitled periodical came about as a result of discussion at Help talk:Citation Style 1/Archive 7 § cite journal without |title. The issue to be 'solved' at the time was the apparently legitimate citation style adopted by some academic traditions wherein the article/paper title is omitted from references. I suppose that such a style is valid so long as the en.wiki article that uses that style is internally consistent. The maintenance message is/was intended to identify those cs1|2 templates that employ |title=none to achieve that style so that editors can add valid titles and thereby make an en.wiki article internally consistent. Use of |title=none to suppress the Missing or empty |title= error message when citing reviews was not part of that discussion.
These sound like good ideas. In an era when we have more different social media platforms than ever before, many items that we might cite for uncontroversial self-descriptions and subject-matter expert opinion might not have titles at all. When an actual title is unavailable, or an editor makes a deliberate choice not to include one, it makes sense to default to displaying the URL with an "Available at". Conceptually, there's no actual error here, so there shouldn't be an error message. XOR'easter (talk) 19:45, 11 February 2025 (UTC)
That's an improvement. "Available at" might not be necessary. APA, MLA, and Chicago just give the URL on its own. More obscure CS1 identifiers use the name plus a colon (doi:, Bibcode:, and so on). Rjjiii (talk) 20:18, 11 February 2025 (UTC)
Canadian Journal of Physics used 'Available from' (e.g. J. Njock-Libii. In Proceedings of the 2012 ASEE Annual Conference, San Antonio, Texas 10–13 June 2012. Available from https://www.asee.org/public/conferences/8/papers/2947/view [accessed 2015-06-02].) 'Available at' might not be strictly necessarry, but it is much more reader friendly/less blunt. And it would match the 'Retrieved [accessdate]'. Headbomb {t · c · p · b}20:35, 11 February 2025 (UTC)
How would this handle the situation where someone provides nothing but a URL. If that just produces "Available at" and then the URL that wouldn't be helpful. -- LCU ActivelyDisinterested«@» °∆t°22:51, 11 February 2025 (UTC)
A bare url would remain a bare url. If you're using a template and only provide a url, nothing would change from current behaviour. Headbomb {t · c · p · b}23:24, 11 February 2025 (UTC)
Appending a naked url to a cs1|2 template rendering is ugly (MOS:URL). Ugly, naked, urls can run on for lines and lines in a reference list; especially those that percent encode non-Latin text. If we are to fix this issue, some sort of better, more attractive, and less user-hostile mechanism should be found.
The only other alternative would be appending "Available here." or "Available online.", but I prefer the raw url in this case, since that matches what most citation style guides recommend. Headbomb {t · c · p · b}03:13, 12 February 2025 (UTC)
"doi:10.1080/10724117.2005.12021805" looks pretty "ugly" too, but we allow that. A guideline about what is generally true doesn't dictate every course of action in all the edge cases. XOR'easter (talk) 04:12, 12 February 2025 (UTC)
I would like this if only to handle posts to microblogging sites like the former Twitter, which do not have a title. Better to say where it can be found by using the url than to pretend falsely that there is a title when there is not one. And the workaround of repeating the url in the title is blocked for us because the templates detect the url-like title and throw an error. Instead, more and more these days, my workaround for overly restrictive citation templates is to manually format more and more of my citations and not use the templates at all. Is that what you want to be pushing us to do? —David Eppstein (talk) 01:31, 12 February 2025 (UTC)
Many style guide say to use the content of a tweet as the title, or a truncated version of the tweet as the title. That's actually an old practice; see incipit. Imzadi 1979→03:22, 12 February 2025 (UTC)
The example for A news article released by a news agency and having no credited author is no longer live and just redirects to The Seattle Times. Seeing as the next example is one that has an archive, I assume this isn't meant to be an archived example, so should it be swapped for a news article that is still live? orangesclub🍊06:04, 13 February 2025 (UTC)
It doesn't really seem there is a title for this issue of the Oxford University Gazette inasmuch as it is just a statement of things done. Is there some better place where the |url= can be put? (See also previous discussion here.) Ifly6 (talk) 04:02, 6 February 2025 (UTC)
Not a scholarly journal. Oxford University Gazette is a weekly newspaper so {{cite news}}. The Gazette is used to support "awarded the First Craven scholarship in 1993" so perhaps this:
{{cite news|url=http://www.ox.ac.uk/gazette/9394/041193 |title=Ireland And Craven Scholarships 1993 |newspaper=Oxford University Gazette |date=4 November 1993 |issue=4305 |volume=124 |publisher=Oxford University |access-date=2015-05-22 |archive-url= https://web.archive.org/web/20150616080531/http://www.ox.ac.uk/gazette/9394/041193 |archive-date=16 June 2015}}
Discrepancy between template data and citation bot
I'm posting about {{cite book}}, but I wouldn't be surprised if this question applies to other citation templates in this family. VE uses the parameter names defined in cite book's template data -- "last" and "first". Per this example edit, it appears that Citation bot prefers "last1" and "first1" to "last" and "first". If there's really a preference for one of these forms of the name over the other, should one of these be changed so that these edits aren't needed? That is, should we change the template data to use "last1" and "first1", or change Citation bot to use "last" and "first"? Or if there's no need for consistency, should Citation bot be changed to stop altering the parameter name? Mike Christie (talk - contribs - library) 11:44, 16 February 2025 (UTC)
That example has a second author, so last1/first1 seem appropriate. In cases where there is only one author, I have seen Citation bot change last1/first1 to last/first. However, Wikipedia:ProveIt changes these parameters to last1/first1 in all cases, regardless of the number of authors. Kanguole14:35, 16 February 2025 (UTC)
That particular edit looks like a violation of WP:COSMETICBOT because the edit did not change the article's appearance nor the html rendering.
Two templates were changed. In the first, Citation bot changed |pages=40-42 (with a hyphen-minus character) to |pages=40–42 (with an unspaced endash). cs1|2 templates automatically render page ranges with unspaced endash separators:
Pages with hyphen. pp. 40–42. ← {{cite book|title=Pages with hyphen |pages=40-42}}
Pages with endash. pp. 40–42. ← {{cite book|title=Pages with endash |pages=40–42}}
In the second, Citation bot changed |last= to |last1= and |first= to |first1=. |last1= and |first1= are exact aliases of |last= and |first= so cs1|2 renders them in exactly the same way:
Charlesworth, G. not enumerated. ← {{cite book|last=Charlesworth |first=G. |title=not enumerated}}
Charlesworth, G. enumerated. ← {{cite book|last1=Charlesworth |first1=G. |title=enumerated}}
These are the sorts of edits that Citation bot should not be making without there is some other substantive change being made to the article at the same time. The proper venue to discuss Citation bot's actions is at User talk:Citation bot; not here.
Trappist, I agree and will post a note at the bot's talk page about this edit. However, if it had been a non-cosmetic edit, it seems to me this page is the right place to ask my original question -- is there a preference between the enumerated and unenumerated forms of the first/last parameters? It seems the bot and the template data are not in agreement, and I don't want to change either without knowing if there is a preference. This seems the right page to ask that question. Mike Christie (talk - contribs - library) 04:33, 17 February 2025 (UTC)
My impression is that most editors would use numbered parameters if there is more than one author and unnumbered ones if there is only one author. I believe that is what Citation bot does too. It might be too complicated for template data, though. Kanguole09:29, 17 February 2025 (UTC)
"if there is more than one author and unnumbered ones if there is only one author"
I don't believe it changes |last1/first1= to |last/first= when there's only one author (maybe it should?), but it does change |last/first= to |last1/first1= when |last2/first2= are present for consistancy. Headbomb {t · c · p · b}09:38, 17 February 2025 (UTC)
What, in particular, is problematic with that edit? It adds missing dates, websites, publishers, authors, etc... All are correct. Headbomb {t · c · p · b}10:53, 17 February 2025 (UTC)
@Mike Christie and Kanguole: The parameters |last=|first= are exact aliases of |last1=|first1=. Changing either form to the other one is usually pointless, since the rendered page - and the emitted metadata - are absolutely identical. However, if there are multiple authors, in which case the parameters |last2=|first2= etc. will also be used, it's conventional (but not required) that the first author goes in |last1=|first1=. But nothing breaks if |last=|first= are used instead, it's just that a few wikignomes (some armed with scripts and bots) might get interested. --Redrose64 🌹 (talk) 19:46, 17 February 2025 (UTC)
Hello, I'm going to use this template on articles, but I can't find what "access-date" means. It doesn't seem to mean 'publish date', then what date should it be? Camilasdandelions (talk!) 10:51, 17 February 2025 (UTC)
It's the date you accessed the source, so if you read a news report today it would be today's date. It's only needed if the source material is changeable. So it's useful on a website that may get updated, but pointless on a printed book. -- LCU ActivelyDisinterested«@» °∆t°14:47, 17 February 2025 (UTC)
Both of the above produce an ID of cite id="CITEREFlast2024" which places the page in Special:LintErrors/duplicate-ids. This is currently making the lint category pretty much unfixable as it has 4,000,368 errors in it. Is it possible to modify make_citeref_id() to add suffix of a long random number to the ID so there won't be duplicate IDs on the same page? Gonnym (talk) 20:02, 17 February 2025 (UTC)
Sure, we could do that, but... CITEREF ids are targets for wikilinks created by Module:Footnotes for {{sfn}}, {{harvnb}}, etc. Appending any sort of random suffix to CITEREF ids would break all of those wikilinks because there is no way for Module:Footnotes to know what suffix Module:Citation/CS1 appended to each CITEREF id.
It should be possible to scan for pages that have duplicate citerefs, and add ref=none to those citations. That would be the correct thing to do on pages that don't use harv/sfn links to the citerefs. On pages that do use harv/sfn links, it would trade one error (duplicate citeref) for another (broken harv/sfn link) but in those cases the harv/sfn links were broken already and the broken harv link is more visible and easier to fix. —David Eppstein (talk) 22:04, 17 February 2025 (UTC)
You could use a letter suffix, as in {{sfn|last|2024a|p=123}}
It would be replacing one error, a mutlti-target, with a different one, a no target. There are only 74 current multi-target errors, the other 190,000+ pages in this report have nothing to do with harv/sfn references they are just pages where normal citation templates are used. Adding |ref=none to so many pages would likely run afoul of WP:COSMETICBOT. -- LCU ActivelyDisinterested«@» °∆t°22:37, 17 February 2025 (UTC)
This is the result of the decision to remove the requirement for cs1 to use |ref=harv and so make cs1 act like cs2. That decision came about because of these discussions:
Occasionally this particular lint error points to genuinely duplicate citations, so it's not completely silly. But excising ids that start with CITEREF from this "error" category seems to be a good idea. -- Michael Bednarek (talk) 01:26, 18 February 2025 (UTC)
Web-based "magazine" sources
For example: Forbes is a magazine. When a news-like source on forbes.com is used, do we assume an identical article appeared in the paper version of the magazine? Do we assume that for all magazines? Is this {{cite magazine}}, {{cite news}}, or cite something else? ―Mandruss☎ IMO. 14:21, 18 February 2025 (UTC)
Frequently a physical magazine has some online-only articles; or an "online magazine" with no physical copy; or used to have a physical copy but then migrated to online only. IMO it doesn't really matter, what is a "magazine", what is an "encyclopedia", etc.. I might use cite magazine when the source itself calls itself one, or need options like volume and issue. -- GreenC18:52, 18 February 2025 (UTC)
Online magazines are magazines. No different than online journals are journal, and online encyclopedia are encyclopedia. Headbomb {t · c · p · b}00:19, 19 February 2025 (UTC)
Agreed. I generally use {{cite magazine}} for online periodicals that are not journals or newspapers, and (although this might be more debatable) for sites like Boing Boing that do not publish on the sort of weekly or monthly schedule you might expect of a magazine but otherwise resemble magazines in editorial process and content. Physical form is irrelevant. {{cite web}} is for personal blogs and non-recurring content. —David Eppstein (talk) 00:42, 19 February 2025 (UTC)
What ultimately matters in Wikipedia is what readers see; the distinction between the various citation templates is largely seen only by editors (except for press releases, interviews, journal articles, etc.) Best wishes, Pol098 (talk) 12:54, 19 February 2025 (UTC)
websites that are not the websites of printed matter isn't quite precise enough. There are websites that were based on printed matter, but are updated independently – for example, the online Flora of North America has corrections and changes from the print version, as explained here. If I were using a print volume as a source, I would use {{Cite book}}, but for the online version, I think {{Cite web}} is appropriate, particularly since it can include an access date in case further changes are made. Peter coxhead (talk) 16:11, 20 February 2025 (UTC)
It is not actually true that only editors and not readers see "the distinction between the various citation templates". Possibly because I have checked the "enable reference previews" reading preference, when I hover my mouse over a reference footnote, the popup that I see has the header "Book reference", "Journal reference", etc. When I view not-logged-in, I get the popups but without the header lines, but this may be subject to change. —David Eppstein (talk) 18:48, 20 February 2025 (UTC)
Errors for third-party users of mediawiki
I got an error while trying to set up citations on a third-party mediawiki. "Lua error in Module:Citation/CS1/Configuration at line 2088: attempt to index field '?' (a nil value). " Was fixed by removing the need to query "CS1/Identifier limits.tab" on Commons:Data. It would be good to handle such errors better for external users. Shyamal (talk) 11:30, 21 February 2025 (UTC)
The documentation at Template:Cite conference has impenetrable "word salad" in the explanation of the |title= parameter: This parameter is required. Note that if the parameter book-title is defined, these parameters get shown in italics instead of "quotation marks", and except for script-title, replace chapter-related parameters, except for script-chapter, and chapter-related parameters, except for script-chapter, won't display. I'm not sure what this is actually supposed to mean, or I would have just fixed it. — SMcCandlish☏¢ 😼 14:12, 19 February 2025 (UTC)
That text was added to the documentation at this edit by Editor PK2 who can perhaps clarify it.
A double // causes an error in any field other than url=. Could the CS1 error external link in ... be changed so it only sees an error if it preceeded by htttp(s)? Lyndaship (talk) 07:29, 24 February 2025 (UTC)
{{Cite journal/new|last1=Shohat |first1=M. |last2=Musch |first2=J. |year=2003 |title=Online auctions as a research tool: A field experiment on ethnic discrimination |journal=[[Swiss Journal of Psychology]]|volume=62 |issue=2 |pages=139–145 |doi=10.1024//1421-0185.62.2.139}}
'"`UNIQ--templatestyles-00000025-QINU`"'<citeclass="citation book cs1">''Title''. pp. <spanclass="nowrap">100–</span>200.</cite><spantitle="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.pages=100-200&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+98"class="Z3988"></span>
That mess that is &rft.pages=%3Cspan+class%3D%22nowrap%22%3E100-%3C%2Fspan%3E200 is a percent encoding of:
&rft.pages=<spanclass="nowrap">100-</span>200
but should be:
&rft.pages=100-200
Fixed in the sandbox:
{{cite book/new|title=Title |pages=100–200}}
'"`UNIQ--templatestyles-0000002A-QINU`"'<citeclass="citation book cs1">''Title''. pp. <spanclass="nowrap">100–</span>200.</cite><spantitle="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.pages=100-200&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+98"class="Z3988"></span>
Boost it to 280000000 at minumum, otherwise we'll be here again next week. Or better, 300000000 and give us several months of leeway. Headbomb {t · c · p · b}05:14, 27 February 2025 (UTC)
As a general rule with citations, if I find that a template has something missing that I think matters, I add it after the template and before the closing /ref. In the example given this isn't needed; "publisher=Religion of Sports, Skydance Sports, NFL Films" as there today, seems fine; alternatively why not "publisher=Co-published by Religion of Sports, Skydance Sports, and NFL Films"? HTH, Pol098 (talk) 12:11, 4 March 2025 (UTC)
I strongly support the use of the quote parameter when adding a citation to an article. I recently noticed that some of the citation templates have a field:
|quote-page=
I am intrigued by this option, and thought I would begin using it.
In my typical usage I often cite a single page as support for the claim, so the cited page(s) will be identical to the page number for the quote, but I can imagine a situation where I want to cite a source for the claim as a range of pages, then identify the single specific page for the specific quote.
Rabinowitz, Harold; Vogel, Suzanne (2009). The manual of scientific style: a guide for authors, editors, and researchers (1st ed.). Amsterdam Burlington, MA: Elsevier/Academic Press. p. 363. ISBN 978-0-12-373980-3. p. 363: The primary designation system for bright stars, called Bayer designations… The Greek letters are assigned in order (α,ß,γ,δ etc.) according to brightness.
Simply has "p. 363" in two different places. If I saw this in another article I think it was a malformed citation. I don't know exactly what I was expecting but I thought there would be some indication that one of the page rangesinstances of page or pages would be related to the overall reference and the other would be related to the specific quote.
and similarly, you did not mean to wrap the block quote in <nowiki>...</nowiki> tags:
Rabinowitz, Harold; Vogel, Suzanne (2009). The manual of scientific style: a guide for authors, editors, and researchers (1st ed.). Amsterdam Burlington, MA: Elsevier/Academic Press. p. 363. ISBN 978-0-12-373980-3. p. 363: The primary designation system for bright stars, called Bayer designations… The Greek letters are assigned in order (α,ß,γ,δ etc.) according to brightness.
Pagination is indicated twice because you used |pages=363 (should be singular |page=363) and |quote-page=363. So, yeah, a malformed citation. If you are citing a single page use |page= and omit |quote-page=.
You refer to page ranges but there are no 'page ranges' in your example template. What did you mean by that?
Sorry, I posted this in another location, was told I was in the wrong place, and copy pasted here not realizing that it wouldn't copy paste exactly. My bad for not checking. Am puzzled that the system decided to insert bold quotes and add no wiki markers. I need to know why nor care – I'll try to pay more attention when doing what I thought was a copy paste. S Philbrick(Talk)19:17, 24 February 2025 (UTC)
I usually try to take care to make sure to use page when citing a single "page" and "pages" when citing a range, but If clearly failed in this case. I change the example to use "page" in both cases and it appears to me that it renders identical to the earlier version of the example. S Philbrick(Talk)19:26, 24 February 2025 (UTC)
If you feel that you need to supply a quote from the source, that tells me that the source is weak and that you are trying to justify its use. --Redrose64 🌹 (talk) 23:05, 24 February 2025 (UTC)
I see it differently. A common situation for me is coming across an article of interest, seeing a claim that is unsourced, then searching for a source. I'll illustrate with a hypothetical but could probably dig up a real example. Imagine an article about a basketball player makes the statement that "player X won award A and award B". I have a number of basketball books in my bookshelf and I might look through and find evidence that player X won award A. If I simply add a reference to the sentence it's imperfect. After all the assertion is a compound assertion and the reference supports one part of it. I'm not going to remove the assertion that the player also won award B, as it could be true but just not mentioned in the reference I consulted. My solution is to add the reference, and add a quote such as "in 2004 Sue won such and such an award". This helps the reader understand what has been supported and what hasn't. If it happens to be an online source they could read for themselves but it's asking a lot for the reader to track down the book, find a library that carries it and go to the library to read it and see exactly what it says. I wouldn't interpret this as saying the source is weak. It may well be a solid source.
In the context of my question, imagine that my book has a chapter on the player and I want to use the Pages parameter to identify the range of pages discussing this player, but I'd also like to use the Quote Page parameter to identify the exact page where the quote is found. I know how to fill in the values, but it appears to me that the generated citation is going to have two entries for page(s) with no indication that one covers the general reference to the subject while the other one covers the specific reference to the quote. It appears to me we have two different parameters, which I support, but no way to tell by looking at the citation which is which. S Philbrick(Talk)18:29, 25 February 2025 (UTC)
It would be useful in cases like:
Author (2025). "Chapter". Title. Location: Publisher. pp. 11–20. ISBN978-92-95055-02-5. p. 14: Quote
I don't see why we would even have a |quote-page= when |at=pp. 11–20 (quote on p. 15) will work fine (I think most or all of these templates treat |at= as overriding |p= and |pp=, so they are not used in the same citation.) I guess if it just intuitively worked better in someone's head it wouldn't be harmful to have (if it worked properly), but we already have too many parameters for practical use except by the hardest-core WP citation experts at this point. — SMcCandlish☏¢ 😼 12:34, 26 February 2025 (UTC)
A relevant quote may sometimes appear outside the page range that verifies the central assertions of the article. This may occur, for example, in pull quotes in college textbooks, say, that might appear on a subsequent page, or might appear earlier in a chapter-opening double page spread. When the page quote occurs within the page range, the param is still useful if the page range is broad, in order to help the user find the quote. As for suggestions like |pages=11–20 [15], not opposed, but it's just one more thing to either have the user remember, or explain to them: (was it brackets or parens, again? do I mention 'quote on page' or just use the parens?). If we decide that rendering it with brackets or whatever is a good idea, then the module should do that, but we shouldn't need to push that off onto the user. All citation params disappear in the end, and what is rendered in the Appendix is plain text; the params are there to guide the article editor and produce a consistent rendering so they don't have to remember the order of params or whether to use brackets or parens or what punctuation to use and where. I say keep quote-page, discuss how we want it to look, and then render it that way. Mathglot (talk) 18:18, 2 March 2025 (UTC)
What is the effect of adding extra details into |pages= on the metadata? Maybe it's better from that perspective to move the extra into a separate parameter so we aren't polluting the metadata we emit in our citations. Imzadi 1979→19:07, 2 March 2025 (UTC)
For the most part, whatever you put in |pages= ends up in the &rft.pages= metadata. URL's are stripped and en dashes are converted to hyphen-minus.
For |quote-pages= and metadata:
when both |pages= and |quote-pages= are present, only |pages= is included in the &rft.pages= metadata
when only |pages= is present, it is included in the &rft.pages= metadata
when only |quote-pages= is present, it is included in the &rft.pages= metadata; |quote= is required for |quote-pages= to render visibly but |quote-pages= still appears in the &rft.pages= metadata; this is a bug that needs fixing.
In the sandbox I have fixed the metadata bug described above. Here the live version, note &rft.pages=%3Cspan+class%3D%22nowrap%22%3E12-%3C%2Fspan%3E34:
'"`UNIQ--templatestyles-00000038-QINU`"'<citeclass="citation book cs1">''Title''.</cite><spantitle="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+98"class="Z3988"></span>
'"`UNIQ--templatestyles-0000003C-QINU`"'<citeclass="citation book cs1">''Title''.</cite><spantitle="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+98"class="Z3988"></span>
I've been marvelling (or marveling if you prefer) at the chaotic trainwreckage I find in the citations in the average article (though following some common wreckage patterns, especially the |url= parameter being in mid-citation, away from the rest of the access-method metadata parameters and away from other even more directly related parameters). People frequently just copy-paste the sample empty template blocks in the template docs, paste them in, and fill in the blanks.
We should normalize all these templates' documentation to consistently group related parameters together (e.g. |access-date=, |url-access=, and |url-status= are all properties of |url= and belong immediately after it, not appended after |achive-url= and |archive-date= which are unrelated to them (but are also dependent on |url= or sometimes on a more specific alternative like |chapter-url=). Similarly, |via= and |agency= belong together, being pretty much variants of the same concept (as with |p= or |pp= and |at=). Having them scattered all over the place makes no more sense than putting |last= at the start of the citation and |first= at the end. But a senseless mess is what we're encouraging by listing the parameters in jumbled order.
I started doing cleanup of this sort on the randomly selected Template:Cite press release/doc, but realized at the end of it that I'd messed it up by failing to account for table columns in one section, so will have to start over at some point (I just closed that tab in a huff because I'm tired and it's "dark:30" in my time zone). But I can volunteer to start doing this programmatically unless someone else wants to tackle it. — SMcCandlish☏¢ 😼 12:52, 26 February 2025 (UTC)
Concur good idea. After years of going and thinking about this, and observing others, my current best practice is something like: {{cite web |last= |first= |date= |title= |work= |url= |archive-url= |access-date=}} .. it mirrors how the data is rendered, and puts the technical stuff at the end. Having |last= first is also useful with <ref name="Last"> makes it easier to visually locate citations in blocks of ref strings running together. GreenC03:21, 27 February 2025 (UTC)
I could go along with that date placement, especially since in shortened footnotes, generally the names and dates are the only data used. My actual habit is to put dates after titles, following a style I was more familiar with, but I see the reasoning in putting it immediately after author(s), and this isn't about "what SMcCandlish likes best", but about what's most editorially helpful for the project. I can easily enough shift my default behavior on such a matter. With regard to |access-date=, this is only a property of the original/live URL; if that's dead, then we just use |archive-date= and remove |access-date= (unless it's a dead link with no archive). It seems unhelpful to sever the connection (in the sense of parameter grouping) between the original URL and its access-date just in the name of imitating the display, especially since the latter could change at some point, and also because in absence of archival, these parameters will be back-to-back, meaning the archival parameters are being injected between them, an unnecessary complexity. — SMcCandlish☏¢ 😼 14:55, 28 February 2025 (UTC)
@GreenC: There's a latent question for you in that, namely what the rationale would be for putting |access-date= at the very end, even after |archive-url= and |archive-date=, "divorcing" the |access-date= from the |url= to which it pertains. I've been holding off on the planned cleanup, pending resolution of any arguments about what order to actually use as the default in the template doc examples/samples. — SMcCandlish☏¢ 😼 00:19, 10 March 2025 (UTC)
User:SMcCandlish: That's a good question. There is a symmetry with url followed by a date (access-date), then archive-url followed by a date (archive-date). Followed by url-status. Keeping these 5 close together would be logical. For |date=, that's often included in the named reference string, or shortened references, along with the last name eg. "ref name=Smith 2020" or "Smith (2020)". It seemed logical closer to the name as an important key to the reference thus near the start. As for deleting |access-date= when there is a working archive URL and the URL is dead .. that is a matter of debate, though I can't remember why. It is mentioned at Wikipedia:Link_rot#Internet_archives (last bullet point) but no insight why. -- GreenC01:53, 10 March 2025 (UTC)
@GreenC: To clarify, I meant, basically, "Is there a compelling reason to always move |access-date= to be last?" I agreed with you already on keeping |date= toward the front as key/central/necessary citation data, even for shortened footnotes. On the side question of removal of |access-date= in the presence of |archive-date= + |url-status=dead (explicit or as the default), I think the argument is that |access-date= in that circumstance is redundant and no longer serves a purpose, because the (consensus-chosen) purpose of that date is indicating when the content being relied upon did say what it said; that is something that cannot change when archived, versus a live webpage which might later be revised. Several years ago, I repeatedly and perhaps over-strenuously argued that |access-date= could serve an equally important (in my view) purpose – and should work in all citation templates, even in absence of a URL: namely, that it would indicate the last time an editor had checked that the content in the source being cited actually supports the claim(s) made in our content in the article for which we are citing that source. But this did not appear to gain consensus, despite my stridency on the issue for a year or longer, so I have given up getting involved in debate about |access-date= being present or removed under various circumstances, and I go with flow of removing it in the archived dead-link situation. The "other use" idea is one we could perhaps revisit some day, but I don't want it to cloud my impending cleanup operation on the /doc pages. :-) — SMcCandlish☏¢ 😼 03:13, 10 March 2025 (UTC)
More consistent examples would be nice. It should also probably apply to the TemplateData parameter order as this will be automatically ordered for everybody using the VisualEditor. I hope it's not obnoxious if I ping in some editors who were offering opinions about parameter order albeit in an entirely different context about bots below.
Thanks for the ping! My views remain the same as in the linked discussion — having a considered best practice default seems like a good idea (and would not mean widespread bot edits creating watchlist spam), so glad to see this. Sdkbtalk03:55, 27 February 2025 (UTC)
Replace |work= with |website= in cite web for default parameters. Omit |archive-url= by default. When |archive-url= is present, so must be |archive-date=. Headbomb {t · c · p · b}05:10, 27 February 2025 (UTC)
What's the point of the first of those? They are synonymous, |work= is more concise, using |website= makes conversion harder, and semantically it's entirely redundant (we already know from the opening {{cite web|...}} template name that it's a website). TBH, I had not planned as part of this /doc cleanup to change things from |website=, |newspaper=, |journal=, and other aliases to |work=. I think we should, to discourage use of pointless aliases, but it's really an out-of-band matter for this. When I say I want to do an order cleanup, or a merge, or some other content-neutral operation, I actually do mean it (it's why I've been successful with so many MoS and other P&G section and page merges; I can do them without injecting my own subjective preferences, or at least I think I can and the results get accepted without drama :-). — SMcCandlish☏¢ 😼 14:18, 28 February 2025 (UTC)
We should distinguish the order of parameters in documentation and in live citations. In documentation it makes sense to document them by grouping related parameters together.
In live citations, some articles have a bibliography where works are listed in order. Usually, they are alphabetical by authors, with ties being broken by publication date. To facilitate ordering the citations, it makes sense to put the parameters in an order something like last1, first1, last2, first2... date....
Naturally, if there are no authors, then editors, and if no editors, the title would go first.
Another consideration is that a citation in an article without a bibliography might be copied to one that does, or the non-bibliography article might be converted to have one. So I like to order my parameters as if the citation was going in a bibliography whether it is or not. Jc3s5h (talk) 11:38, 27 February 2025 (UTC)
Sure, but to be extra-clear in case anyone's alarm bell starts going off, this isn't in any way about dictating to editors an order that they must use; it's just about having the documentation provide examples and fill-in-the-blank samples that are in a logically and practically sensible order that will work well as defaults. If someone feels like using another order because it suits their input methods, that's fine. (Sometimes I do this myself, e.g. when copy-pasting a bunch of citation data from a single place that is using a particular order, I may just add |whatever= parameter code in front of each piece of the original non-WP citation's content, in-place, as much more expedient than moving all the original cite content around to fit a parameter order.) The most important thing is getting material cited (and secondarily in a style that produces consistent output). The much less important thing is having our template /doc pages stop suggesting and causing the use of a default parameter order that is downright nuts, with effects that range from irritating through unhelpful to outright confusing. — SMcCandlish☏¢ 😼 14:18, 28 February 2025 (UTC)
Cite episode tweak
Please make |work= operate in {{cite episode}} as an alias of |series=, which serves the same function (it's the italicized major work, while |episode= is the quotation-marked minor work, like a book chapter/contribution, or a website or periodical article). This would make it easier to "translate" between templates. If |title= doesn't work as an alias of |episode= then it should. — SMcCandlish☏¢ 😼 00:08, 10 March 2025 (UTC)
isbn and pre-isbn publication dates
There is a bug report at User talk:Citation bot § Don't insert bogus ISBNs for books from the 1930s. The issue is that Citation bot added an isbn for a 1994 edition of a book to a {{cite book}} template with a publication date of 1935. ISBN came into being c. 1965 – 1970 so any book with a publication date before that time cannot possibly have an isbn. Should we be highlighting cs1|2 templates where the publication date precedes the ISBN inception date?
Here are a couple of crude searches for {{cite book}} templates where |date= / |year= is listed before |isbn= in the wikitext:
~4900 articles (times out) where |date= or |year= is in the range 1900–1959
~1800 articles (times out) where |date= or |year= is in the range 1600–1899
Yes. It's an unambiguous high quality signal. Of course similar problems can exist for books published after 1959. An ISBN for a book published in 1985 has a |date=1967. I believe this is a very common problem. How do you know which one is correct? Without access to the book, it's very difficult. -- GreenC03:30, 27 February 2025 (UTC)
The module can't do anything about your example 1985 edition template that has a bogus |date=1967. That does not mean that we shouldn't flag templates with |isbn= that have |date= or |year= values earlier than 1965.
Or it could the other way around, the |date=1967 is correct and the ISBN is wrong. Which is correct: citation metadata or ISBN metadata. There is need for a bot to check for ambiguous metadata and flag it somehow, preferably using the same system you are proposing for the pre-1965, so it's all in the same tracking category. -- GreenC17:16, 27 February 2025 (UTC)
Of course. But, if we declare 1965 as the isbn incept date, Module:Citation/CS1 would not find anything wrong with |date=1967 and whatever isbn is present except for the isbn format and checksum errors that it already detects. Modules do not have access to the world outside of MediaWiki.
We'll probably need a template so bots can tag citations with ISBN ambiguity, it's main purpose to add it to a tracking category and a warning message of some kind, that aligns with how CS1|2 displays for the pre-1965 cases. -- GreenC21:07, 27 February 2025 (UTC)
I don't see why a book published before 1965 shouldn't have an ISBN. The original print run won't have had one, true; but reprints do occur from time to time. Example from my bookshelf:
It shows on the imprint page as "Published in Puffin Books 1962" also "Reprinted 1963, 1964, 1965, 1967, 1968, 1969, 1970 (twice), 1971, 1972, 1973 (three times), 1974". I expect that the original had no ISBN, probably not an SBN either, but instead would have had Puffin's own catalogue code, which would have been PS173. So an ISBN for a pre-1965 book is not unfeasible. But we do need to be wary of variation between editions (a reprint is not a new edition). --Redrose64 🌹 (talk) 14:34, 27 February 2025 (UTC)
In your example, the cited edition has a |year=1974 publication date so would not be flagged. Had you cited the 1951 edition and you included (or someone else added) |isbn=0-14-030173-9:
{{cite book|last=Lewis |first=C. S. |authorlink=C. S. Lewis |editor-last=Webb |editor-first=Kaye |editor-link=Kaye Webb |title=Prince Caspian: The Return to Narnia |year=1951 |publisher=[[Puffin Books]]|location=Harmondsworth |isbn=0-14-030173-9 |others=illus. Pauline Baynes }}
then that template would be flagged because the stated 1951 publication date precedes the ISBN inception date.
This 1951 MacMillan edition (12th? printing) does not have an ISBN so citing this edition with an ISBN would be flagged as an error.
Chicago Manual of Style 18th edition has related advice. ¶ 14.41 states "Publication date—general. For books only the year, not the month or day is included in the publication date. The date is found on the title page or, more commonly, on the copyright page."
¶14.42 "New impressions and renewal of copyright. The publication date must not be confused with the date of a subsequent printing or a renewal of copyright. Such statements on the copyright page as '53rd impression' or 'Copyright renewed 1980' should be disregarded." So, according to Chicago, the correct publication date for Redrose64's book would be 1962. Jc3s5h (talk) 17:32, 27 February 2025 (UTC)
This book says "reprinted", but that doesn't always mean the page numbers will align exactly the same. This is significant because if a bot adds a book link to page 50 of the 1962 edition, but the editor really meant the 1974 edition, where the cited content is now on page 55, then it creates an unverfiable link. It's safer to assume each years are different editions with different page number alignments ie. "say where you got it". -- GreenC17:48, 27 February 2025 (UTC)
in paperback, with the same ISBN but different reprint dates, that had different pagination - I think because of a font size change. I only have one of them now - I lent one to Yellowrose63 (talk·contribs), who seems to have mislaid it. --Redrose64 🌹 (talk) 20:10, 27 February 2025 (UTC)
User:Redrose64: "a reprint is not a new edition" .. this is true, even over a long time span, and even when the reprint adds an ISBN. But, unless you have access to both the original and reprint, it can be difficult to determine reprint vs. new edition. It's usually safer for Wikipedia purposes to assume new edition. I don't think we have mechanisms to differentiate reprint vs new edition. Possibly we should, but given how haphazard things are citing books, it properly would end up creating more errors due to confusion of what counts as a reprint vs. edition (I just looked it up on AI, it can be messy). -- GreenC17:36, 27 February 2025 (UTC)
Sandboxed using 1965 as the incept date:
Cite book comparison
Wikitext
{{cite book|authorlink=C. S. Lewis|editor-first=Kaye|editor-last=Webb|editor-link=Kaye Webb|first=C. S.|isbn=0-14-030173-9|last=Lewis|location=Harmondsworth|others=illus. Pauline Baynes|publisher=[[Puffin Books]]|title=Prince Caspian: The Return to Narnia|year=1951}}
{{cite book|authorlink=C. S. Lewis|date=1974a|editor-first=Kaye|editor-last=Webb|editor-link=Kaye Webb|first=C. S.|isbn=0-14-030173-9|last=Lewis|location=Harmondsworth|others=illus. Pauline Baynes|publisher=[[Puffin Books]]|title=Prince Caspian: The Return to Narnia}}
The test only applies to valid dates. The anchor_year variable in Module:Citation/CS1 is a convenient way to get a validated year value (same value used to create CITEREF anchor dates). This example shows that a disambiguated year doesn't disrupt the test.
Cite book comparison
Wikitext
{{cite book|authorlink=C. S. Lewis|editor-first=Kaye|editor-last=Webb|editor-link=Kaye Webb|first=C. S.|isbn=((0-14-030173-9))|last=Lewis|location=Harmondsworth|others=illus. Pauline Baynes|publisher=[[Puffin Books]]|title=Prince Caspian: The Return to Narnia|year=1951}}
No doubt there will be cases where a pre-1965 publication date actually applies. The error message that would normally be emitted can be suppressed with the accept-as-written markup.
Looks good. At some point it might be helpful to differentiate, like "Date / ISBN incompatible: predates 1965" vs. "Date / ISBN incompatible: mismatched dates", for the post-1965 problems (generated by a separate template). -- GreenC01:15, 28 February 2025 (UTC)
"Date / ISBN incompatible: mismatched dates" What does that mean? cs1|2 can only react to publication |date= or publication |year= relative to the ISBN incept date (currently set at 1965). mismatched dates implies more than one date. What are the 'other' dates that don't match?
We discussed all this, further up thread. "There is need for a bot to check for ambiguous metadata and flag it somehow, preferably using the same system you are proposing for the pre-1965, so it's all in the same tracking category." Thus both the bot added flag (for post-1965 problems), and the CS1|2 generated errors (for pre-1965 problems) are ending up at the same tracking category with compatible messaging. By "bot added flag" this would probably be a template that follows directly after the CS1|2 template. -- GreenC00:42, 4 March 2025 (UTC)
Regarding "mismatched date", there are indeed two dates. When you look up the ISBN in a database, it returns the date of publication associated with that ISBN. Thus the ISBN date and the |date= are mismatched. This is what the bot would do, look up the ISBN in a database, tag the citation when it finds is a mismatch. -- GreenC00:47, 4 March 2025 (UTC)
While augmenting an article (which I know is a mess), I found a couple of mildly interesting tidbits via "NewspaperArchive" (thanks to the Wikipedia Library (TWL)) and added each, using Template:Cite news, complete with the usual fields, including url-access=, url=, and via=. My mis-specification of url-access=registration (no, subscription) shows that I was sleepy at the time -- which may explain why I unthinkingly copy/pasted the URL from my browser. I now realize that the domain name for each isn't newspaperarchive.com but instead access-newspaperarchive-com.wikipedialibrary.idm.oclc.org
One might guess that for people that don't have TWL access, such a link would lead to (i) a greyed-out version of the desired page paired with (ii) an invitation to log in (somehow) in order to see it; but no, one only gets (ii). So for now I've commented out url= and url-access= (which requires url=) but left in via=.
By contrast, if I replace (as an example) "https://access-newspaperarchive-com.wikipedialibrary.idm.oclc.org/us/florida/sarasota/sarasota-herald-tribune/1957/05-05/page-21" with "https://newspaperarchive.com/us/florida/sarasota/sarasota-herald-tribune/1957/05-05/page-21", link-clickers get:
We found your results!
05 May 1957
Page 21
Sarasota Herald Tribune in Sarasota, Florida
We have 3,622,829 pages in Florida
This is just the beginning! Our collection holds over 300 years of history, including rare newspapers, obituaries, marriage records, birth records, and so much more—most of which you won’t find anywhere else!
-- with a bucketload of boldface; I've spared you. And if they happen to have access (as I do, via TWL), they're not told this, let alone sent to the fully-visible version of the page.
Hmm. What's the best (most helpful, least horrid) way of citing something that's at NewspaperArchive? -- Hoary (talk) 23:36, 7 March 2025 (UTC)
Perhaps that question is better asked at Wikipedia talk:Newspapers.com because what you want is a link to a clipping, right?
Changing the topic, I have sometimes wondered if we should be error messaging TWL urls because they are inaccessible to the general public. Or failing that, automatically marking them with |url-access=subscription. This search finds about 140 articles that have |url= with some sort of TWL url.
I think having an error message would be helpful, these links should always be replaced. Readers may have access to the source themselves without needing TWL, and for other readers paying for access would be more likely than meeting the requirements for TWL access. Active extended confirmed Wikipedia editors are a tiny, tiny fraction of the readership. -- LCU ActivelyDisinterested«@» °∆t°10:12, 8 March 2025 (UTC)
WP:Newspaperarchive.com says, "Both Newspaperarchive.com and The Wikipedia Library would prefer that articles citing Newspaperarchive.com link to clippings." Does the clipping link require any kind of subscription? I know Newspapers.com doesn't. For example:
Oh, gotcha, and yes an error message sounds good. I have done this kind of link a couple of times, and both times it was an error. Rjjiii (talk) 01:59, 9 March 2025 (UTC)
Sandbox now looks for .wikipedialibrary.idm.oclc.org in any of the parameters where we allow a url as an assigned value. When detected, the module emits an error message, unconditionally sets |url-access=subscription and categorizes the article in Category:CS1 errors: URL:
Re, "I have sometimes wondered if we should be error messaging TWL urls because they are inaccessible to the general public.": Yes, we should, because TWL resources are not even available to all WP editors, much less to our readers; the URL's formatting isn't guaranteed to be/remain consistent (they already seem to vary between back-end providers of the content); and many of them are ephemeral to a particular login session. As citation data, they are worse than useless. — SMcCandlish☏¢ 😼 00:12, 10 March 2025 (UTC)
Just chiming in to say that we agree the original (non-proxied/TWL) links seem preferable to have as citations in Wikipedia articles, and the error message seems helpful! At one time there was a bot which went around replacing these URLs with their un-proxied versions, but I can't recall which one now. Perhaps User:Citation bot? There's a Phab task at T277655 about having Citoid automatically un-proxy URLs when it has been used to cite something, but it's not completely straightforward as the proxying process is lossy - dashes in the proxied URL could have originally been a dash or a dot. Samwalton9 (WMF) (talk) 09:41, 10 March 2025 (UTC)
If you had to cite a highly specific release (e.g. because it has a particular track exclusive to it), you could simply be more specific, e.g. with something like |type=Japanese fan club ltd. ed. 10-inch vinyl picture-disc EP |id=Cat. no. Ryk-J29349-00P or whatever. PS: I was afeared that |type= would barf on input with punctuation and require ((...)) markup, but it does not. — SMcCandlish☏¢ 😼 12:28, 26 February 2025 (UTC)
I did rediscover after I posted here that the entry for that field can be typed in, it doesn't have to be one of those on the list. Still, I think vinyl and cassette should be suggested options. Thanks--3family6 (Talk to me|See what I have done) 12:49, 26 February 2025 (UTC)
@3family6 You're welcome! I was just about to ping you to see if it looked right. Even when a template supports something, it has to be manually added to the TemplateData for it to appear in the Visual Editor. Any editor can update it, but sometimes the changes don't show up until the next day. Rjjiii (talk) 03:00, 27 February 2025 (UTC)
Revising HELP:CS1
HELP:CS1 duplicates material covered by template documentation and can offer contradictory advice. When I began editing, I expected an introduction to the popular citation templates, but HELP:CS1 is incredibly dense and technical in places. We could revise it to offer an overview of the templates. Some technical details on the page are covered by linked documentation, and others could be moved to more appropriate pages. I've done a draft in a sandbox that is revised to be less technical and more of an overview:
In general, this is probably good idea, especially if it reduces the number of places where more technical detailia needs to be kept in synch. — SMcCandlish☏¢ 😼 21:08, 17 March 2025 (UTC)
Allow URL in via?
error is thrown when a url is in the via parameter. I think url should be allowed here. Here are several discussions on the the topic. Maybe this is RFC worthy? Page I was working on that brought me here 2025 South Korean by-elections
You appear to want to cite two sources with one template. cs1|2 templates are not designed to do that. If you want to cite both sources, use two templates.
|via= is not to be used for adding lists of urls; it is to be used to name the delivery source if different from the publisher.
These are not two sources. This an editor giving a link to where they got access to a source. The point of things like WP:Say where you got it is so other editors can access the source. If the via was, for example, Google Books then why not link to the Google Books page where the material is found? Czarking0 (talk) 15:24, 11 March 2025 (UTC)
It is two sources. While the bibliographic details are largely similar, they are different:
The point of WP:SAYWHEREYOUREADIT is to ensure that you identify the source that you read that supports the text in an en.wiki article. There is no requirement for you to identify every possible source that can support our text.
With regard to your Google books question, editors routinely include both |isbn= (which links to Special:BookSources which links to Google books) and |url= with a Google books link. There is no need to add the Google books link to |via= though it is acceptable to write |via=Google books which identifies Google books as the deliverer because different from the publisher.
(edit conflict) I would strongly disagree with this as it would only be frequently misused as an expedient way to include multiple different URLs for the same citation. For example if you find a source at Yahoo! News that was originally published in Rolling Stone you would correctly have: |work=Rolling Stone and |via=Yahoo! News and |url=https://yahoo.com... But, if you allow a URL into the via then it becomes |url=https://yahoo.com.. and |via=https://rollingstone.com.. .. well which one is authoritative? And if we add an |archive-url= which one is it for? And which one is |access-date= for? And |url-access=? It creates all sorts of complications and ambiguities. -- GreenC16:02, 10 March 2025 (UTC)
I concur with Trappist and GreenC. The purpose of |via= seems to have been sorely misunderstood by Czarking0. It literally means what it's name says: via, i.e. 'by way of', 'by means of', 'through the channel of'. It is not an original content identifier/retriever of any kind like an ISBN or URL, simply a "WP:Say where you got it" enabler, a piece of "how this source came to be examined" metadata. It also can serve an incidental secondary function of providing credit for the provisioning of the preservation of historical publications and access to more current ones, though many of us do not make much use of it for that purpose (especially if it involves paywalled access, i.e. involves profiting). — SMcCandlish☏¢ 😼 16:17, 10 March 2025 (UTC)
This isn't about what I understand the purpose to currently be, but what the purpose should be. I am saying it should serve the role of content retriever and there are many examples of people trying to use it for that purpose. Citations styles were not a gift from God in the holy book but a normative process. Part of why putting urls in the via is not more comon is because there is warning against doing that when you save the page. Czarking0 (talk) 15:34, 11 March 2025 (UTC)
Your not really hearing what we are saying, rather incorrectly framing it as an arbitrary holy precept without reason. OK, we do what you say. Now, both the url and the via URL are dead links. Someone adds an archive-url. Which URL is it for? Which URL is access-date for? Or url-access? Or all the other URL-specific fields. Do you propose we entirely rewrite the CS1|2 system? The current system is designed for 1 citation = 1 source ..it's not an arbitrary precept. Yes, some people are lazy and add multiple URLs in the same cite, rather than create 2 cites, and they will find any loophole to make "work", leaving a mess for others to clean up (or not). Your asking us to make the loophole bigger and to ignore the core framework of how the templates were designed and written. The solution is very simple: 2 citations, one for each source link. -- GreenC21:33, 11 March 2025 (UTC)
You keep pretending these are two sources. A google books link to a book and an internet archive link to the same book is not two sources that is one source with two ways to access it. Czarking0 (talk) 21:39, 11 March 2025 (UTC)
And we don't need "two ways to access it" when "it" is a scan of the same book. Except for old public domain materials, Google Books doesn't provide full-text access anyway, so we have no reason to drive traffic to that increasingly awful corporation. If Internet Archive has a copy, either right up front or though the digital lending with its "Borrow" button, then link to that instead. If neither site provides access to the text, then we have no reason for our citation to confusingly redirect our readers to either site. Somewhere around 70% of the GBooks URLs I encounter on citations in this site do not go to usable text, and are simply Google spam that needs to be deleted, since it doesn't do anything but link to basic information about the book with "buy it here ..." links, and our readers can get a better array of such information and access/acquisition possibility through linked ISBNs. — SMcCandlish☏¢ 😼 20:59, 17 March 2025 (UTC)
The most important part of a citation is that others can access the material used to make the claims. Your example is a good one for highlighting this point. Under the status quo, if Yahoo is blocked in my country or I don't have access for some other reason then your url would not work for me. If I have access to Rolling Stone I could potentially find the source but if the material is years old and potentially titled differently the original url would be helpful to have. The ambiguities are of secondary consideration if people can't access the material. Czarking0 (talk) 15:31, 11 March 2025 (UTC)
Not everything has to be contained in the cite. If an alternative source exist you can always include details after the cite, but before the closes ref tag. <ref>{{cite web|title=title |url=https://www.example.com}} Also available from [https://www.secondexample.comSecondExample].</ref> -- LCU ActivelyDisinterested«@» °∆t°19:33, 11 March 2025 (UTC)
You may have noticed that Category:CS1 errors: PMC is beginning to populate. Usually it's a simple matter of updating the value at c:Data:CS1/Identifier limits.tab. Alas, not this time. Something at commons or at MediaWiki has broken. If you click on the Identifier limits.tab link you end up waiting for more than a minute before MediaWiki gives up and shows the Service Temporarily Unavailable screen. Module:Citation/CS1 can still read the limit values by way of the lua library mw.ext.data.get() function call.
Not sure what the above is about because I checked member of that category and from a random sampling of 5-6 of them, they all work here. Headbomb {t · c · p · b}23:24, 20 March 2025 (UTC)
The error message is Check |pmc= value and is showing because those templates have |pmc= values that exceed the configured limit of 11900000. The usual and intended fix is to edit c:Data:CS1/Identifier limits.tab at commons to update the parameter's limit.
Something at commons is broken and access to the identifier limits data table by way of that link does not work. That link is the only way to update the limit for PMC (and for all of the other identifiers that have limits). If the breakage remains for long enough, |oclc=, |osti=, |pmid=, |rfc=, |ssrn=, and |s2cid= will also start showing this same error message.
I am wondering, if I want to cite (for example) an explanatory note added by Mr X to a book written by (say) Charles Dickens, how should this be cited using the template? It doesn't feel like putting Dickens as the editor would be correct per se. McPhail (talk) 20:56, 20 March 2025 (UTC)
{{cite|contributor-last=X |contributor-first=|contribution=Title of X's whatever |last=Dickens |first=Charles |title=Title of Dickens' book}}
X, "Title of X's whatever", Title of Dickens' book, by Dickens, Charles,
@216.58.25.209: Forgive me if I'm misinterpreting this, but doesn't [1] say the exact opposite? Nigel Ish said That applies if you are citing the original, non-translated work, in which case the original title goes in |title= and an Enlish [sic] translation can (if necessary) go in |trans-title=. If you are citing a translation of the work into English, which has an English language title, then the English-language title goes in the title field. I interpret this to mean that the trans-title parameter is supposed to be used if the source that is cited is not in English, but you should not use it if you are citing a professional translation of the work. To clarify, do you have an issue with machine translation itself? If so, we've already a template, {{Rough translation}}, for badly machine translated content in general. Grumpylawnchair (talk)01:28, 19 March 2025 (UTC)
Yes, the problem is that I had to fix 2 obvious errors in a giant machine-translated edit today. Even if I can read Cyrillic, I don't speak Macedonian, so I don't know how many non-obvious errors are left. The absence of |trans-title= behaves like a redlink to attract human translators, but too many editors are using Google Translate so a template solution is needed.
I don't think we should allow purely machine-translated titles. If you don't have the fluency to get it right and don't have a proper source for the translation then leave it untranslated. If we shouldn't allow it we shouldn't have parameters that, by their existence, encourage it. —David Eppstein (talk) 03:57, 19 March 2025 (UTC)
Support. Inline or ambox?Btw, I currently detect machine translations by pasting them into Google Translate and looking for exact matches; I make my translations slightly different in word order and synonyms to mark them as human. Thus, if desired, a bot could apply that template. 216.58.25.209 (talk) 22:28, 19 March 2025 (UTC)
Probably inline, like we've got for dead links and unreliable sources. My concerns are on how to access Google's API in the first place and about the failure rate for such automated activity. Let's take a three word title in Polish, "Ja jako lesbijka" (source), most people would (humanly) translate that as "Me as a lesbian" ("I as a lesbian" doesn't feel grammatically correct, at least to me), so it would be inaccurate to flag that as bot-generated. I feel like such a bot would be more trouble than it is worth, and would conflate somewhat literal human editors with machine translation. Also, people who speak a language fluently sometimes use Google translate to save time, but check the results afterward. IMO Google Translate ≠ automatically bad, as long as you have enough skill in the language to check the results. Grumpylawnchair (talk) 22:37, 19 March 2025 (UTC)
My parameter creation proposal was intended to just mark the machine translations people are already adding. I was about to go to WP:EF/R next to ask for a warning when adding that parameter, but both editors are extended-confirmed.I have an idea that wouldn't encourage machine translation: How about we edit the TemplateData of each {{cite xxx}} so that |trans-title= clearly indicates "do not use machine-translation" in the description and "Human-translated title" in the label? 216.58.25.209 (talk) 21:54, 19 March 2025 (UTC)
No proposal except an inline tag template was supported by others. People were opposed to both machine-translating titles and flagging of those by bots.
{{demo inline|<nowiki>{{Not English inline}}}}</nowiki>
I would like to know why the first two templates have two last and first name parts to them. It should just have 1 last and first name part and it having both doesn’t really seem necessary. ErickTheMerrick (talk) 15:35, 20 March 2025 (UTC)
I guess you are referring to the first example in the "Authors" section. We could have the first example only have one author to make it a little easier to understand. But in an actual article, the editor will need to cite the names of all the authors, unless the list of authors is overly long. So editors will have to learn to do this early in their editing careers. Jc3s5h (talk) 15:51, 20 March 2025 (UTC)
I know, it’s more a convenience thing I guess. I know that some journals will have multiple authors, but the majority of them only need to cite one author and having two be there is kind of annoying to have to delete the “last2=, first2=” and the 1 and 2 from the “last1=, first2=”. It’s nots too big a problem, just wanted to bring it up. ErickTheMerrick (talk) 18:12, 21 March 2025 (UTC)
The easiest way to cite a journal is to write {{cite journal |doi=<DOI>}} (or {{cite journal |jstor=<JSTOR>}}, etc) and get citation bot to expand it for you. It'll take care of 99%+ of all that stuff. Headbomb {t · c · p · b}21:02, 21 March 2025 (UTC)
Simply, get the article's DOI (or some other identifier), like doi:10.1016/S0262-4079(18)30281-1, then you just write <ref>{{cite journal |doi=10.1016/S0262-4079(18)30281-1}}</ref>, and when you click on ✔ Citations, it will automatically expand it to <ref>{{cite journal |last1=Aron |first1=Jacob |year=2018 |title=Deflector Selector says nuke asteroids |journal=New Scientist |volume=237 |issue=3165 |pages=6 |bibcode=2018NewSc.237....6A |doi=10.1016/S0262-4079(18)30281-1}}</ref>Headbomb {t · c · p · b}03:37, 25 March 2025 (UTC)
See the definitive documentation for Vancouver style author (and other) names. cs1|2 does not want you to terminate the |vauthors= namelist with a dot. Terminal punctuation is dependant on cs1 or cs2 style so the cs1|2 template will apply the appropriate terminator.
Interestingly, PMC and PMID example cites often ignore the two-initial rule. Don't know why they can't be bothered to follow their own rules.
We do not. Here are some quick and dirty searches for |vauthors= and |veditors= with accept-as-written markup:
~2800 articles use |vauthors= that have accept-as-written markup
~85 articles use |veditors= that have accept-as-written markup
~570 articles use |vauthors= where three or more uppercase letters preceding the accept-as-written markup closing ))
~20 articles use |veditors= where three or more uppercase letters preceding the accept-as-written markup closing ))
So, I guess the question is: should we track these? If we are to track accept-as-written markup in the Vancouver-style name-list parameters, which of the above should we track? Any using accept-as-written markup? Any where three or more uppercase letters precede the closing accept-as-written markup? Some other that I haven't thought of?
Tracking all cases would be good, IMO. Then as we work through them, maybe the logic could be refined. Headbomb {t · c · p · b}16:04, 26 March 2025 (UTC)
'"`UNIQ--templatestyles-000000A1-QINU`"'<citeid="CITEREFGreen_ABC"class="citation book cs1 cs1-prop-vanc-accept">Green ABC (ed.). ''Title''.</cite><spantitle="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+98"class="Z3988"></span>
Use of accept-as-written markup in |vauthors= and |veditors= will be tracked in Category:CS1:Vancouver names with accept markup; a properties category. When live, templates using the accept-as-written markup in Vancouver name-list parameters will have the class= attribute cs1-prop-vanc-accept in the <cite> tag. These templates can be highlighted using personal css; see Help:CS1 errors § Properties category highlighting.
The template {{cite news}} throws up a CS1 maint: numeric names error when the |title= parameter contains numbers as well as letters. According to this page, the error report can be suppressed using ((value)). But how, exactly, it doesn't say... Fortuna,ImperatrixMundi15:28, 26 March 2025 (UTC)
That maintnance message (not an error message) does not come from |title=. I presume that you mean |author= or a related parameter. Real live examples with links to articles where you are experiencing problems are always helpful.
First check the name. Names with digits are comparatively rare. Is the name really supposed to have digits in it? If the name is not supposed to have digits, replace it with the appropriate name. If the name really is supposed to have digits then write:
I more-or-less agree except for the |author=Anon. bit. Anon. is nowhere credited in the source as the author so we should not be inventing such a credit.
A work without a credited author is by Anon., no? Avoiding |author=Anon. requires a clumsy construct with {{harvid}} which will lead to an unclear chain of shortened footnotes:[1]
where the location of the publisher and the name of the publisher are both shoehorned into |publisher=. Doing this corrupts the template's publisher metadata:
&rft.pub=London%3A+Thomas+Telford+Ltd
when it should be:
&rft.place=London&rft.pub=Thomas+Telford+Ltd
This search (times out) finds about 6100 articles where {{cite book}} has |publisher=<some text>:<some other text>. That isn't a perfect search; it finds stuff like |publisher=[[:ja:講談社現代新書]] but Lua code can do better.
Should we catch these and put them in a maintenance category?
Maintenance to start, yes. After a few AWB runs, we'll have a better idea of what sort of crap is left in it. Headbomb {t · c · p · b}14:50, 14 March 2025 (UTC)
Sounds good to me, too. Some botly cleanup of this might be possible to an extent, but I see junk entries in conflicting formats sometimes, e.g. not just "London: Penguin" but "Penguin: London", "Penguin (London)", "London, Penguin", "Penguin London", etc. It would probably eliminate a large blob of them, though, to look for "publisher=" (with extraneous spacing collapsed), followed by major publishing cities (like London, Edinburgh, Paris, Leiden, Milan, Barcelona, New York, Chicago, Boston, etc.) followed by colon-space or space-colon-space, followed by alphanumerics that indicate the actual publisher. — SMcCandlish☏¢ 😼 21:07, 17 March 2025 (UTC)
In the sandbox. The test is constrained to {{cite book}}, {{cite encyclopedia}}, and {{citation}} without a periodical parameter. The text strings on either side of the colon may be wikilinked:
Note that if the book is a collection of separately-authored chapters, you'll probably be citing a chapter rather than the book. Kanguole10:15, 29 March 2025 (UTC)
Proposal: add doi=, pmc=, and pmid= parameters to Template:Cite bioRxiv and other templates for preprint repositories
Since 2023, the National Library of Medicine has been indexing preprints on bioRxiv, medRxiv, arXiv, and Research Square that receive NIH funding on PubMed and PMC and is assigning a DOI to them that is the same as the preprint ID.[2] An example of this is this paper. Note that since it is on PMC, there is a free full version of the text on PMC, so maybe including pmc= should make title= link to the PMC page like the cite journal template does. For doi=, maybe make it so that either bioRxiv=/etc. or doi= can be used, but not both, since they link to the same page. The DOI/bioRxiv/etc., PMCID, and PMID should display in the same order as what the cite journal template displays. I have used the preprint I linked on the article "1993 Four Corners hantavirus outbreak" (it is ref 17) but the citation is incomplete given the current restrictions, so I think it would be good to fix this. Velayinosu (talk) 01:09, 31 March 2025 (UTC)
It is common for textbooks to be published under the auspices of a university but printed by an external publisher.An example[1] is a textbook written at the Department of Mathematics, Harvard University but published by Jones and Bartlett. The obvious parameter, |institution=Department of Mathematics, [[Harvard University]] won't work because |institution= is an alias of |publisher=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:47, 2 April 2025 (UTC)
That's because "affiliation" is bibliographically irrelevant and is not information that needs to be included. Headbomb {t · c · p · b}18:57, 2 April 2025 (UTC)
The OCLC value limit needs to be increased. Per Help:CS1 errors, it is currently set at 10450000000, and I have inputted a correct OCLC value that surpasses the current limit and thus it is telling me there is an error.
How should CS1 and the harv/sfn templates handle author-date citations where there are multiple sources with the same author and no date? CS1 (and major citation methods) append a letter to YYYY years, so two 1997 dates become 1997a & 1997b. For citations with no date, CS1 accepts n.d. (or nd). For multiple citations with no date, CS1 only accepts n.d.a. An editor at Module talk:Footnotes explains, 'But I don't think most people would write "n.d.a", which looks like the a is part of an acronym.' This is probably true. Only 45 articles use {{cite web}} and "n.d.a". A spaced format was suggested: '"n.d. a" is much clearer. I would suggest that both should be allowed, as should "nd a" in contrast to "nda"' Looking into major citation styles, they suggest "n.d.-a".APACMOS[3] Whatever solution would be implemented for the short citations should match the solution for the full citations. I would prefer a single method to a bunch of methods, personally. Whatever method is expected for CS1 should probably be spelled out somewhere in the documentation, but I don't see it. Rjjiii (talk) 03:28, 12 April 2025 (UTC)
Host (10 May 2025). "Title". website (Podcast). Publisher. Retrieved 10 May 2025.
I believe the issue is "(Podcast)" which appears after the name of the website, which in the example is website. Since that used neither curly nor square brackets, I don't understand what Rjjiii's comment is about. Jc3s5h (talk) 18:37, 16 April 2025 (UTC)
@Jc3s5h, oof, my bad, curved brackets (parentheses). Also, I'm not saying you used them; the CS1 templates use them. The CS1 example above uses the capitalized "Podcast" and APA advises the capitalized "Audio podcast". Harvard citation style has also influenced CS1 and capitalizes "Podcast". IEEE also capitalizes "Podcast". Vancouver uses the generic "Internet" but still capitalized.
If you want to hide "Podcast", you could use |type=none like this:
Host (10 May 2025). "Title". website. Publisher. Retrieved 10 May 2025.
Also, since type could take pretty much anything, you could just type the default in lowercase, but I think this would become a huge hassle to do on every citation in an article:
Since Wikipedia has depricated parenthetical referencing, I'm inclined to disregard APA, since that uses parenthetical referencing. Also, Harvard referencing doesn't seem to be a specific style manual, just a general approach. Chicago Manual of Style 18th ed., ¶ 14.169 gives one example with "...The Loudest Girl in the World, podcast,..." and another that doesn't include the word "podcast" at all. Jc3s5h (talk) 19:56, 16 April 2025 (UTC)
CS1 was based on APA's general full citation format though. Unlike CMOS, APA and CS1 put the publication date/year in parentheses after the author names, for instance. Yes, there are various deviations between APA and CS1, but the influence is there for the full citation, even if parenthetical referencing was deprecated in favor of footnotes. Imzadi 1979→22:44, 16 April 2025 (UTC)
|publication-date= and |publication-place= (again)
Because of discussion at Help talk:Citation Style 1 § ISBN / Date incompatibility I am reminded of the confusion caused by |publication-date= and |publication-place=. We have had previous discussion about making |publication-date= an equal alias of |date= and similarly, about making |publication-place= an equal alias of |location= and |place=:
Do we really need these parameters (and the attending confusion)? Would we not be better served by making them equal aliases? As currently implemented, do these parameters, when used in parallel with their pseudo-aliases, aid readers in locating a copy of the source?
I suggest this thread be put on hold until the ISBN / Date incompatibility problem is dealt with, since people are complaining about it in multiple talk pages. Jc3s5h (talk) 15:17, 17 April 2025 (UTC)
|publication-place= seems to have a very restricted use, for news articles with a localised byline, presumably for correspondants or local bureaus. |publication-date= is however in many situations useful, as many works have a history much more complicated than just being published once and for all. In theory, no less than three dates could be displayed, if |orig-date= is used as well. And I would argue it clarifies rather than confuses. Keriluamox (talk) 15:54, 17 April 2025 (UTC)
As I understand it, the |publication-date= is the date when the item first became available for retail sale, but the |date= is the cover date. The difference becomes clearer when one realises that many magazines are published with a cover date that is in the future, which for magazines published six or fewer times a year may well be several weeks after the publication date. In Asimov, Isaac (1982) [1973]. The Early Asimov: Volume 1. St Albans: Granada. p. 34. ISBN0-586-03806-X., Asimov wrote concerning "Marooned off Vesta", his first story to be published: The story appeared in the March 1939 issue of Amazing Stories, which reached the newsstands on January 10, 1939 which is a clear difference of seven weeks between publication date and cover date. It was explained to me somewhere that magazines published in the United States use the cover date as a kind of expiry date: the March 1939 issue would be on sale until some point in that month, although by that time, the April 1939 issue would have been on sale for some weeks, and possibly the May 1939 issue would have appeared as well. --Redrose64 🌹 (talk) 16:15, 17 April 2025 (UTC)
Chicago Manual of Style 18th ed. 14.41, "Publication date—general", in the Source Citations part of the manual, indicates the publication date for a book is found on the title page or copyright page. So the publication date is whatever the publisher considers it to be. If some kind of information about when the work was actually made available is relevant, that should probably be described in the running text of the Wikipedia article, or an explanatory footnote. The publication date is included in a citation primarily to help locate a copy of the work; giving an idea of the age of the work is secondary. Jc3s5h (talk) 16:39, 17 April 2025 (UTC)
If the sole purpose of a citation is to locate a copy of the work, an ISBN and a page number would suffice… Possibly an author name and a year in order to enable Harvard-style references, and that’s it. Keriluamox (talk) 17:10, 17 April 2025 (UTC)
It is customary to provide other details. Maybe the ISBN was only printed on the dust cover, and the dust cover was lost; now I want to know if the book I have is the same one that was cited in Wikipedia. Maybe the ISBN in Wikipedia is for the hardcover, and I have a softcover with the same content and page numbering, but a different ISBN. Jc3s5h (talk) 10:41, 18 April 2025 (UTC)
'Cite journal' style
I'm probably wrong here, but this weirded me out enough to report it. When using the 'Cite journal' template and the fields 'journal=Foo', 'volume=15', 'issue=4', and 'pages=300–350', it displays correctly as "Foo15 (4): 300–350". This seems obviously intuitive because you go from the most significant part to the least significant like a decimal number, YMD, etc. However, if I add 'publisher=Bar', suddenly it renders as "Foo15 (4). Bar: 300–350". This seems... Really wrong? We interrupt the obvious procession from greatest to least with a publisher. If anything, it seems it should be something like "Foo. Bar. 15 (4): 300–350". Thoughts? TheTechnician27(Talk page)21:13, 17 April 2025 (UTC)
I don't know why it does this, but I suspect the root of the problem is it isn't normal to mention the publisher of a journal in a citation, so whoever implemented this either had no credible examples to guide them, or it never occurred to the developer this could happen, and the case was never tested. The solution given in the tread pointed to by Headbomb, written by Trappist the monk, is to omit the publisher. Jc3s5h (talk) 10:51, 18 April 2025 (UTC)
I agree that it is indeed neither usual nor apparently relevant to mention the company that publishes the journal. However, if the journal is published by a specific institution (research centre etc.), and is essentially identified as a production of this particular institution, including it makes sense.
@Kerilaumox: can you tell us of a printed style manual that gives an example of how to format a citation of a journal that includes the publisher? The normal approach to doing something weird is to not support it in the citation templates and write a short phrase between the end of the citation and the closing </ref> tag, like <ref> {{cite journal |...}} Published by Royal Society.</ref> Jc3s5h (talk) 00:17, 19 April 2025 (UTC)
