Help talk:Citation Style 1


Of late there has been a bit of churn at Template:Citation Style documentation/url, likely due to discussion at User talk:Citation bot § Removing url-status = live.

To minimize the documentation churn, we should discuss here and then change the documentation.

You will note from the Citation bot discussion that there are those who believe that |url-status=<any legit value> should be allowed anytime and others who disagree (I am firmly in this latter camp).

The recent churn at the documentation template caused me to take a hard look at the documentation for |url-status= which, to me, has become a rather confusing mishmash so I propose to replace it with something like this:

The current version doesn't clearly state the purpose of the parameter so I started there and then rewrote, as a list, the various keyword definitions. I removed mention of maintenance messaging because that just adds to the mess (and if we discuss maint messages here, we'll end up discussing them everywhere... so more mess elsewhere.


Trappist the monk (talk) 14:49, 29 September 2023 (UTC)Reply

If we're going to require |archive-url= can we say requires |url= and |archive-url=? |archive-url= already requires |url=. I will say I don't really like the {{dead link}} alternate (no idea how common this is), since it requires navigating to the end of the template call, and typing in a date, rather than just adding a parameter wherever. I understand this is probably easier on a keyboard. Folly Mox (talk) 14:59, 29 September 2023 (UTC)Reply We could. I think that including |url= in the requirements more tightly binds the three parameters together as a unit and by doing so (perhaps) editors might be less likely to add stand-alone |url-status= to a citation (or not). It is not in the cs1|2 remit to assume the duties and infrastructure of inline citation cleanup templates. Adding |url-status=dead to a cs1|2 template that doesn't have |archive-url= with value does not now add the article to an Articles with dead external links category and should not do so in the future; that is not the purpose of |url-status=dead (and wasn't the purpose of its predecessor |dead-url=yes). And you don't have to type the date... AnomieBOT will do that for you. —Trappist the monk (talk) 17:52, 29 September 2023 (UTC)Reply All right, I can manage a little extra effort if it's for best practices. Your explanation for the wording makes sense as well. Thanks. Folly Mox (talk) 19:10, 29 September 2023 (UTC)Reply Per Mike at Citation bot talk, archiveurl should not be required. Nikkimaria (talk) 03:11, 30 September 2023 (UTC)Reply

Agree with everything Trappist the Monk said. It makes no sense for the CS1|2 template to mark dead links, and then other non-CS1|2 templates use {{dead link}}, plus square and bare URLs - it's a confusing mismatch of systems that will be prone to error eg. people using one system, or another system, or both systems. Then there is all the legacy issues. 100s of bots, reports, tools, etc.. are configured to do things as they are. It will lead to breakages, errors, that will take years to resolve and cause a lot of damage upstream eg. reFill will take decades to fix at current pace, and VE who knows. Then there is the user-base, literally millions of brains which have been hard-wired by 15+ years of doing things this way that need change, it's unnecessarily disruptive. Once you know how its done, it's not hard to follow or understand. -- GreenC 04:16, 30 September 2023 (UTC)Reply

The only problem here is that |url-status= name causes confusion, which inturn leads to it being misused. The solution to that is not continued misuse. Clarification of how it should be used is definitely a step in the right direction. So inagre definitely agree with Trappist. Using {{dead links}} is a separate template the same as any other maintenance tag, citation needed, clarify, dubious for instance. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 10:23, 30 September 2023 (UTC)Reply

Per Nikki's comment above, here's a version of what I posted at the bot's talk. I have two use cases, one for |url-status=dead and one for |url-status=live. This URL will quite possibly go out of date in months; a quarterly update at that website causes pages like this to be regenerated and the URL may change (it's difficult to predict whether or not it will change, for reasons I can explain if anyone cares). When I create a link to that URL, it's live and not deviated, but I know it's possibly going to go out of date so I always add the archiveURL when I can. I have also been putting in |url-status=dead, because otherwise someone reviewing the links is likely to mark it as live. (At a recent FAC source review a reviewer suggested marking one of these as live, not dead, for example.)

The use case for |url-status=live without archive-URL is when is down or refusing to archive, which happens fairly often. I try to always archive links when adding the citation; I think that's best practice. If I can't do the archive, then for the links I know are going to be stable long-term I add |url-status=live so that if someone else comes along and adds an archive URL it won't default to the archive link in the citation.

I understand that neither use case exactly fits the intended use of these parameters, but they are natural ways to use them. My main complaint about the bot having removed them is that they are not inaccurate (they don't lead to erroneous output HTML) and they don't incorrectly represent reality. A response at the other conversation was that they do lead to maintenance message output, but if these use cases are a natural way to interpret the parameters I don't think these parameter states should generate maintenance messages. What is the harm in allowing this usage? Mike Christie (talk - contribs - library) 12:03, 30 September 2023 (UTC)Reply

I believe a lot of this comes from the fact that the parameter is named url-status, if it was renamed archive-url-switch or some other name this wouldn't be an issue (but that would require updating lots of other tools, so is a waste of resources).
Using url-status to mark dead links seems like a bad idea, as it doesn't generate any visible output, unlike {{dead links}} which creates a proper maintenance message. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 12:23, 30 September 2023 (UTC)Reply I agree that the name is what led me to use the parameters in this way. Why do you feel it needs correction, though? The negative outcome you give -- using url-status to mark dead links doesn't cause visible output -- doesn't apply here, as far as I can see, since I only set the parameter to dead when the archive-url is there, which means no further action is necessary. And dead-link would be wrong anyway -- this situation doesn't require a user to come along fix a link, which would be a hopelessly repetitive task for, the website in question. (There are 771 cites to the website per an insource search I just did.) Mike Christie (talk - contribs - library) 12:30, 30 September 2023 (UTC)Reply Any fix would be to stop it's misuse, but as I said renaming the parameter at this point is unlikely. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 19:13, 30 September 2023 (UTC)Reply I have updated the documentation. —Trappist the monk (talk) 13:19, 7 October 2023 (UTC)Reply Excellent clarification. I have added additional dead and deviated display and function identically, with a live link to the URL; usurped and unfit display and function identically, with no link to the URL. While the relevant paragraphs do say links to url= are suppressed in the rendering, I think it helps to point out that dead and deviated are the same, as are usurped and unfit. Best wishes, Pol098 (talk) 14:25, 7 October 2023 (UTC)Reply And I reverted that because I think that your addition is redundant but we can discuss if you'd like. Maybe there is a better way of writing what I proposed above. —Trappist the monk (talk) 14:28, 7 October 2023 (UTC)Reply usurped says used when url links to information unrelated to the original link. The term usurped in this context is best understood as a misappropriation ie. someone other than the original owner of the domain has taken it over at the registar level and redirecting traffic to a new website, typically of a vice nature; or a domain reseller. This is why we sanction display. But it's not the same as merely unrelated content, for example many websites redirect dead links to their home page. Those we mark as dead links. Suggest the documentation for usurped take a higher level and say used when the domain in url no long serves it's original intent such as (mis)appropriation by other entities. Is it possible individual url's could be usurped? I suppose like a Facebook page that is hijacked. Usurpation most of the time is at a domain-level. I think for individual URLs, which are rare, we could rely on unfit. Thus the distinction between them is domain vs. url. GreenC 15:48, 7 October 2023 (UTC)Reply Done with a bit of copy editing: diff. —Trappist the monk (talk) 16:30, 7 October 2023 (UTC)Reply Thank you. Some more changes. -- GreenC 03:16, 8 October 2023 (UTC)Reply I spent a fair amount of time editing articles trying to use "deviated" and wondering why it seemed the same as "dead". While the recent rewrite adds clarity and, if read carefully, does imply that they work the same, I do recommend some explicit statements that dead and deviated are identical, as are usurped and unfit, with no difference for the reader, just for editors. I'm not going to change again, but if this is thought useful please modify. Maybe just that: "dead and deviated display and function identically, as do "usurped and unfit", shorter than my original comment. Alternatively a rewrite of the list: Best wishes, Pol098 (talk) 12:29, 8 October 2023 (UTC)Reply Thanks for that. dead and deviated cannot both be the default condition. The definitions for unfit and usurped have been refined to distinguish one from the other since your writing. —Trappist the monk (talk) 14:06, 8 October 2023 (UTC)Reply Thanks for these documentation updates. I've just edited Usury to change the Financial Times citation (currently # 35) from |url-status=unfit to live and to add |url-access=subscription. I believe this is correct as the live URL has a paywall and the URL does not. I don't believe FT's addition of the paywall is "unfit" advertising. If I'm interpreting the documentation incorrectly, a reply would be helpful. As an afterthought, I was initially suspicious of the cbignore for Wayback in favor of until I found that Wayback only saved versions with the paywall. Thanks for all you do! KarenJoyce (talk) 02:24, 26 November 2023 (UTC)Reply The {{cbignore}} was added by User:Frabrikator Special:Diff/1001248446/1001281991. Possibly IABot at the time was occasionally converting links to Wayback due to a bug now fixed - it no longer does that. I removed it. -- GreenC 02:41, 26 November 2023 (UTC)Reply Since we are on the topic of url-status, another question is with "deviated". In the worlds of computer and library science, the phenomenon is "content drift": Example, Example, Example, Example. It would be canonical and accurate to call it |url-status=drift or |url-status=drifted or |url-status=drifting. Most likely "drifted". I doubt there are so many we can't easily modify via bot. As a bonus they both start with "d", and drifted is fewer letter and syllables. (IMO deviated sounds vaguely sinister, like deviant, which is the purpose of unfit and usurped.) It would help get everyone on the same page inside and outside Wikipedia with the same terminology of content drift. -- GreenC 17:25, 8 October 2023 (UTC)Reply

Requesting a new parameter value: |url-status=paywall would mean that the link works only if the user is paying to access it. Commenter8 (talk) 16:09, 5 November 2023 (UTC)Reply

The current documentation for |url-status= is at Template:Cite book § Subscription or registration required. There, the term 'paywall' is used as part of the definition of the keyword subscription. Is that not sufficient? If not, how is it not sufficient? —Trappist the monk (talk) 16:22, 5 November 2023 (UTC)Reply

"Ulr=" not working in the presence of "chapter-url="

Greetings and felicitations. In this citation I have both "chapter-url=" and "url=", but the latter is not working:

Horsburgh, James (1836). "Fernando de Noronha". India Directory, or, Directions for Sailing to and from the East Indies, China, Australia, Cape of Good Hope, Brazil and the Interjacent Ports... London: W. H. Allen. p. 31.

Horsburgh, James (1836). "Fernando de Noronha". India Directory, or, Directions for Sailing to and from the East Indies, China, Australia, Cape of Good Hope, Brazil and the Interjacent Ports... London: W. H. Allen. p. 31.

Have I done something wrong, or is there a problem with the code?

Edit: From Horse latitudes#Origin of the termDocWatson42 (talk) 12:14, 24 October 2023 (UTC)Reply

You need to change |title= to |entry=
{{Cite encyclopedia |last=Horsburgh |first=James |year=1836 |entry=Fernando de Noronha |entry-url= |encyclopedia=India Directory, or, Directions for Sailing to and from the East Indies, China, Australia, Cape of Good Hope, Brazil and the Interjacent Ports... |url= |location=London |publisher=W. H. Allen |page=31}}
Will display as:
Horsburgh, James (1836). "Fernando de Noronha". India Directory, or, Directions for Sailing to and from the East Indies, China, Australia, Cape of Good Hope, Brazil and the Interjacent Ports... London: W. H. Allen. p. 31.
-- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 12:25, 24 October 2023 (UTC)Reply Thank you. ^_^ I suggest (please) adding "entry=" as an alternative to "title=" at the top of the documentation of {{Cite encyclopedia}}, as one has to dig a bit to find that information. —DocWatson42 (talk) 10:32, 25 October 2023 (UTC)Reply

deprecate |authors=

Since May I have been picking away at Category:CS1 maint: uses authors parameter. Today that category is more-or-less empty. |authors= has been 'discouraged' in the documentation since June 2016. I have marked |authors= as deprecated in Module:Citation/CS1/Whitelist/sandbox and will tweak the template documentation to show that the parameter is deprecated.

|authors= has two aliases: |people= and |credits=; these parameters are not deprecated.

Trappist the monk (talk) 14:21, 24 October 2023 (UTC)Reply

You realize this will just cause people to abuse |author= to list multiple authors, right? —David Eppstein (talk) 14:48, 24 October 2023 (UTC)Reply What is the consequence of a deprecated parameter? eg. it works but displays a warning message? -- GreenC 14:55, 24 October 2023 (UTC)Reply And then later on Trappist removes it from the template and makes its use even more inflexible and human-unfriendly. —David Eppstein (talk) 15:19, 24 October 2023 (UTC)Reply It's a false dichotomy of human-friendly *versus* unfriendly for the sake of the machine. There's a lot more to it. There is human friendliness dimension to both sides depending which aspect you want to emphasize ie. the simple one-time input process, or the infinite re-use of the data by end-users, which benefits from greater precision and fewer ambiguities in the names. -- GreenC 18:05, 24 October 2023 (UTC)Reply At present, templates using |authors= render with a maintenance message: {{cite book |title=Title |authors=Red Brown, EB Green}} Title. {{cite book}}: Cite uses deprecated parameter |authors= (help) After the next module suite update, templates using |authors= will render with an error message: {{cite book/new |title=Title |authors=Red Brown, EB Green}} Title. {{cite book}}: Cite uses deprecated parameter |authors= (help) Instances where a deprecated parameter is used in mainspace will be categorized in Category:CS1 errors: deprecated parameters. —Trappist the monk (talk) 16:32, 24 October 2023 (UTC)Reply You think that editors don't already do that? I invite you to inspect the articles listed at Category:CS1 maint: multiple names: authors list. Deprecating |authors= makes the author name-list parameters consistent with the other name-list parameters. For the other name lists: Trappist the monk (talk) 16:32, 24 October 2023 (UTC)Reply I don't see this making a lot of difference, it's very uncommon to see |authors= used anymore, and it's been nearly seven years since the process was started. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:58, 24 October 2023 (UTC)Reply Agree with David: the proposal is not an improvement. I have reverted the documentation change. Nikkimaria (talk) 18:33, 24 October 2023 (UTC)Reply Improvement for who? There is more to it than convenience of 1-time data input. Can you explain your rationale for saying "not an improvement" that includes all stake holders? Other processes, people, databases, tools. etc downstream. TTM is doing what is the best for the most people, big picture. In interface design, best practice is to "nudge" users towards greater accuracy and fewer errors. Use of CS1|2 is optional, if you really prefer complete free-form data entry, don't use CS1|2. This just-so nightmare: |authors=Elizabeth, Middleton Maria, Baroness, Susan, Amy Maria, invented by me, demonstrates ambiguities in parsing by humans and machines (it's Middleton Maria Elizabeth, Susan Baroness, and Amy Maria .. or, Baroness Middleton Maria Elizabeth and Amy Maria Susan). The solution to use ";" between names is nice in theory but in reality free form gives expected results: names that are not consistently parsable. -- GreenC 19:45, 24 October 2023 (UTC)Reply The proposed change may improve matters for data reusers, but David has raised a reason why it may not - as for that matter have you, in promoting abandonment of templates altogether. That's the bigger picture: if user-unfriendly changes discourage people from using templates, or adding citations at all, it impacts every other potential stakeholder. Nikkimaria (talk) 20:08, 24 October 2023 (UTC)Reply What do you may? It clearly would and does for reusers. David's point had nothing do with reusers. I'm not promoting anything, only observing what has always been true we have two systems. I can't imagine anyone abandoning CS1 over this one parameter which has been actively deleted for years. There is no evidence this is a user unfriendly change that would discourage use of templates, otherwise show me the complaints when this parameter has been deleted from templates. -- GreenC 22:14, 24 October 2023 (UTC)Reply Since I began replacing |authors= the only 'complaints' were related to these articles: I started clearing Category:CS1 maint: uses authors parameter when it had ~14,150 articles (the first edit that I can find was this one). I started from the top of the category (article names beginning with digits and then alphabetically) so whenever an article re-appeared in the category it was obvious. There weren't many reappearances and those that did re-appear did so because of new additions to an article, other copy editing, or unrelated mistakes on my part. All of these five articles reappeared when Editor Nikkimaria silently reverted my edits. Many of the edits to replace |authors= were done using various AWB scripts. After a time I tweaked the scripts so that they would skip Editor Nikkimaria's articles. I did not do that for any other articles because no other editor complained either directly or indirectly. —Trappist the monk (talk) 23:46, 24 October 2023 (UTC)Reply Complaints about cleaning up the metadata in existing templated references are uninformative about how rigid and difficult-to-use you are making the citation templates for human editors attempting to create new references. —David Eppstein (talk) 00:04, 25 October 2023 (UTC)Reply If it was really a problem, we'd be seeing more complaints about its removal in over 14k cases. This is an objective data point. "Ridged and difficult to use" is by contrast a subjective opinion by a couple users. And this opinion does not take into account all the stake holders and their needs, it prioritizes one set of stakeholders. Considering how complex Wikipedia is (tables, other templates, etc..) replacements for this parameter are not very complex, have been in place for years, and many people use them already without complaint. -- GreenC 00:24, 25 October 2023 (UTC)Reply The proposed change also attempts to prioritize one set of stakeholders. To answer your question above about why I say "attempts" and "may": your assertion above that it "clearly would" is based on the assumption that removing the intuitive, convenient option will lead editors to the "preferred" option instead - but that is not the only possible outcome. David has proposed one alternative: editors will instead switch to piling multiple authors into |author=. You have named another: editors will switch to using free-text citations. I have given a third: editors will simply not provide the data. The first case would necessitate additional work to provide any improvement for data reusers; the other two would worsen the situation for reusers (which is why reuser-focused "improvements" that worsen the editor experience are problematic). Nikkimaria (talk) 02:59, 25 October 2023 (UTC)Reply What about some sort of compromise solution? Where all the specific citation wrappers ({{cite book}}, {{cite web}}, etc.) can be optimised for data reusers, and {{citation}} can just retain all the parameters people want to deprecate, and not do sanity checks on what parameters should and shouldn't be there, apart from disallowing multiple parameters that are aliases of each other?That would let the downstream people get their metadata all nice and fastidious so no human ever has to look at it to guarantee a computer will understand it properly, and have an alternative easy / freeform mode for editors who don't want to type |editor7-last= etc., or who want to cite something in a way that doesn't vibe with whatever the metadata standard is (location without publisher, book that is part of a larger work, "chapter" of a website, or whatever). Folly Mox (talk) 03:28, 25 October 2023 (UTC)Reply "an alternative easy / freeform mode for editors who don't want to type editor7-last" Don't the vcite templates already offer this? Rjjiii (talk) 06:34, 25 October 2023 (UTC)Reply Wow I don't think I'd ever before heard of or seen in the field any of the vcite templates, and reading the documentation for {{vcite book}} gave me some idea what it must feel like for a new editor to encounter CS1 for the first time. Folly Mox (talk) 11:20, 25 October 2023 (UTC)Reply There's also |vauthors= which does the same as authors, but in an established style. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 11:50, 25 October 2023 (UTC)Reply That parameter I did know about, but I find it too limiting. The |authors= thing that is the immediate discussion here isn't my fight, but it seems true that in general, the CS1 templates – which are essentially equivalent to house style at this point – have been in the recent past moving towards clean metadata for reusers and away from usability for Wikipedia editors.I don't know if the solution is training everyone to produce citation data that can be cleanly reused by downstream people, forking the citation system so there's alternatives for editors who don't want to deal with all the nuances of best practice, subjecting major changes in the citation templates to broader community consensus, or what. But it's evident that we're coming to, at, or beyond the point where there's conflicting interests.I'm really deeply appreciative for all of Trappist's work on these templates, which I use all the time, every day, and frequently convert plaintext citations into. I'm not trying to invalidate any of that, and maybe I'd have a different perspective if I had any idea who "reuses" citation metadata from Wikipedia, how they reuse it, and for what. Folly Mox (talk) 12:32, 25 October 2023 (UTC)Reply For the avoidance of doubt, I also really deeply respect Nikkimaria, GreenC, and David Eppstein for all the work they've done for the project as well. I wish we could all agree on things and I'm not sure how. Folly Mox (talk) 12:49, 25 October 2023 (UTC)Reply It is not true that the proposed change ... attempts to prioritize one set of stakeholders (emphasis added). Three of the stakeholder sets that benefit from this proposed change are our readers-set, the everyday-editor-set, and the gnome-editor-set. The intent is to make all name-list parameters consistent across all of the name lists. Deprecating |authors= helps our readers because free-form name-lists are just that; there are as many ways to write a free-form name-list as there are editors who write those lists. Yeah, we can say in the documentation that the names of individual authors in the list shall be separated by semicolons not commas but don't hold your breath for editors to do that (the vast majority of names in |authors= that I have fixed over the past months were separated with commas (Name, Name, Name, Name, ... – is that a list of Last, First names or a list of Last names only? Sometimes it's not possible to tell without consulting the source). Deprecating |authors= helps the everyday-editor-set by making name-list entry of any stripe (author, contributor, editor, interviewer, translator) use similarly named parameters; supporting one-off parameters just causes confusion. Deprecating |authors= helps the gnome-editor-set by reducing the amount of work that must be done to fix citations written by conscientious editors who used |authors= because it is listed in the documentation as a valid parameter. It is the duty and obligation of the cs1|2 templates to render name-lists that use a consistent format citation-to-citation in both human- and machine-readable forms. cs1|2 cannot format free-form name-lists because it cannot accurately parse a free-form list of alphabetic character groups (names) into human-readable author names (if anyone reading this knows how to do that reliably, don't be shy). It is for this reason that cs1|2 does not include authors listed in |authors= in a template's COinS metadata. Readers who use reference management software to consume our citations do not get that critical author metadata. All readers, whether they are reading with their own eyes or by the eyes of a machine, are entitled to complete and accurately rendered citations. —Trappist the monk (talk) 14:45, 25 October 2023 (UTC)Reply The assumptions put forward above warrant further examination. The average reader doesn't care in the slightest what parameters or templates we use; as far as they care about citation formatting at all, it is only whether there is sufficient information provided to identify and ideally access the source. So for the bulk of the readers-set, the proposed change is neutral, assuming no negative impact on editors. However, for everyday editors who are not intimately familiar with templates, "authors" is an intuitive and convenient choice for adding multiple authors. As for gnomes, as with data reusers, it helps them only if the change results in the desired behaviour from everyday editors - see above. If that's not the result, it may even increase their workload. The primary purpose of citation templates is to support editors in conveying the sources of information they add to Wikipedia. If they fulfill some other obligation, great - but if they fail in that primary purpose, it doesn't matter how perfectly they meet other goals. I echo Folly Mox's excellent argument above: this specific issue may be the straw that breaks the camel's back for some users to move away from using templates, or it may not - but this discussion is certainly highlighting some fundamental, as-yet-unresolved conflicts between the needs and perspectives of users and reusers. Nikkimaria (talk) 00:28, 26 October 2023 (UTC)Reply The average reader does care when the content of a free-form citation parameter is difficult to decipher because the editor who created that parameter's value did it in such a way that surnames are indistinguishable from given names because name separators are the same as author separators or are omitted entirely. Readers who consume these citation templates using reference management software like Zotero care because they don't get the author data; cs1|2 cannot parse a free-form author-name list so it cannot fill the $rft.aulast, $rft.aufirst, and $ k/v pairs in the COinS metadata. All readers are entitled to the best citation rendering that we can provide; continuing to support |authors= because most readers don't care about properly rendered citations deprives those readers who do care. Editors who don't care will continue to abuse |authorn= and |lastn= to do the same as they do with |authors= – if we are to believe this archive snapshot from 2023-08-05, editors abuse |author= and |last= more often than they use |authors=. These days, most editors, even those who don't care, don't have to be intimately familiar with cs1|2 templates because we have VisualEditor and RefToolbar which will do the grunt work for them. These tools don't need and should not use |authors=. Gnomes have enough stuff to fix across the encyclopedia. We can take one item off of the stuff-to-fix-list by deprecating and removing support for |authors= – Category:CS1 maint: multiple names: authors list will still be there for those who enjoy cleaning up after inexperienced or lazy editors. The primary purpose of citation templates is not for editors but for readers because the templates provide consistent rendering of citation information. Editors are now and always must be secondary to the needs of the readers. —Trappist the monk (talk) 15:08, 26 October 2023 (UTC)Reply If you want the readers to get the benefit of citation templates, the citation templates must remain usable by human editors. The alternative is templates only usable by machines and article references constructed by humans that avoid the templates and deny robot access to those articles because the robots make everything so difficult to edit. I have already seen articles with blanket bot denial tags because of the persistent habit of the bots of adding useless junk ids (which fail to benefit readers in any way) to citation templates, and I have already noticed in my own content creation that I have been formatting a greater fraction of citations manually without templates because I just can't justify the effort of fitting them into a citation template shaped box. With usability-reducing changes like this I only expect that sort of thing to become more widespread. On the other hand, if the citation templates remain usable by humans and cleanable by bots, you get the best of all worlds: the readers get the consistency benefits of templated citations, the humans get to use citation templates to help format their references more-or-less consistently, and then the bots and gnomes can clean them up. But there will be nothing for the bots and gnomes to clean up if you make the templates usable only by bots and gnomes, because actual content creators won't use them. —David Eppstein (talk) 15:24, 26 October 2023 (UTC)Reply Clearly you dislike bots. This talk page is not the place to rant about bots. For that, discuss at the bot operators' talk pages or WP:BOTN. This discussion is about deprecating |authors=. Yes, I want readers to get the benefit of citation templates. cs1|2 cannot consistently, accurately, reliably, pick your own qualifier, format human and organizational names when given a free-form string of characters written using Latin and non-Latin scripts (Cyrillic, Greek, Arabic, Hebrew, CJK, Devanagari, ...). So, editors must help by providing individual names in individual name-holding parameters. Alas, some editors never will. If they don't want to provide individual names in individual parameters, they can use |author= or |last= (they already do) and someone, someday, will cleanup after them. We don't need |authors= it should be deprecated and then support for it should be withdrawn. —Trappist the monk (talk) 15:39, 27 October 2023 (UTC)Reply Editor Nikkimaria has also silently reverted my edits to Module:Citation/CS1/sandbox, Module:Citation/CS1/Configuration/sandbox, and Module:Citation/CS1/Whitelist/sandbox which explains why the examples above don't match the text in my 16:32, 24 October 2023 post. All of my edits should be restored. —Trappist the monk (talk) 23:46, 24 October 2023 (UTC)Reply That's unprecedented, never seen that before. Sandboxes are made for this, it's why we have them. They need to restore the sandbox while consensus discussions continue. Or provide a really good explanation why they are interfering in the consensus process. -- GreenC 00:32, 25 October 2023 (UTC)Reply These sandboxes are not simply used for demonstration purposes as is typical elsewhere, but instead to accumulate changes for bulk implementation. Since this change doesn't have consensus at this point, it ought not to be added to the accumulation. Nikkimaria (talk) 02:59, 25 October 2023 (UTC)Reply Consensus is determined on this talk page, or similar, and not by what is contained in the sandbox. It's true the sandbox is a staging area for proposed changes, but a lot happens between now and the final push to production. Ultimately what goes into production is determined by consensus. In fact before the sandbox goes live, there is an announcement with a waiting period and link to this discussion; and clearly everyone knows at this point this change is controversial, so it would be nearly impossible to go by unnoticed, even assuming someone tried to keep it in slyly. Furthermore given your past history with this forum, I seriously doubt anyone is going to try and slip it by when there is no consensus. The purpose of the sandbox is so we can see the proposal and then comment on it, but your interference is disrupting that process. -- GreenC 05:27, 25 October 2023 (UTC)Reply Unfortunately what my past history with this forum has shown me is that the ideal you describe doesn't match reality. Nikkimaria (talk) 13:04, 25 October 2023 (UTC)Reply I don't know what you refer to - are you saying there was consensus not to do something, yet it was done anyway? Most likely you opposed something but it went through anyway due to a plurality of opinions per WP:DISCUSSCONSENSUS. All I know is your bad faith in the process is interfering in consensus building, and with maintaining the template. Any wrong you feel you were the victim of in the past doesn't excuse bad behavior in the present. All it does is perpetuate bad faith, further bad behavior, more disruption. -- GreenC 15:45, 25 October 2023 (UTC)Reply If you don't know, wouldn't it be best to not jump right off on a bad explanation? But in the interests of not perpetuating bad faith etc further, let's refocus on the proposal. Nikkimaria (talk) 00:28, 26 October 2023 (UTC)Reply Right, I'd like to focus on the issue, by restoring the sandbox, so we can see the code in action, but which you have removed from public view, based on an assumption of bad faith in this 'forum'. -- GreenC 03:52, 26 October 2023 (UTC)Reply It would be a good option to separate the testing function of a "traditional" sandbox from the staging function of this implementation, rather than having the two combined. This would allow you to see the code in action while also avoiding having changes being added/left to staging prematurely in future, addressing both of our concerns. What is the best way to accomplish this? Nikkimaria (talk) 04:29, 26 October 2023 (UTC)Reply What difference would it make? It's not like we have a problem with things accidentally being left in the sandbox. Rather, you believe people intentionally do things on the sly. New staging versions won't help. At some point, the staging versions need to be staged for review. Which anyone can edit. It's just another sandbox. 9 of them currently full of complex changes and code. It would be the same "problem" but worse, a new set of files to watch and maintain. Rather, the current process is to post in this forum all the proposed changes with a link to the discussions that brought them about and a waiting period for anyone to object. Again, what's the problem? I have not seen anyone but you complain about bad faith in this process, and you have only cast aspersions ie. with no evidence. -- GreenC 14:42, 26 October 2023 (UTC)Reply Nowhere in this discussion have I expressed a belief that "people intentionally do things on the sly" - as above, it would be best to not jump off on a bad explanation. The problem is that, as noted here, "anything that makes it into the sandbox eventually makes it into the main module": changes can get added to and remain in staging, and after that get pushed to production, without consensus being reached for them. Here's an example: a change was proposed, there was opposition to it, the discussion did not achieve a clear consensus in favour of implementation, and yet the change ended up in the next module update. This was not addressed by the update post (perhaps because of the issues noted here? It certainly wasn't the only update in that set with concerns.) This comment from a subsequent discussion is also worth reading. Nikkimaria (talk) 02:24, 27 October 2023 (UTC)Reply

I can't see the utility in maintaining a variant parameter because one editor objected over five articles. Splitting out multiple authors to use first and last names is desirable on metadata grounds and furthermore is not hard. Seven years of a deprecation warning is more than enough time. Mackensen (talk) 12:14, 25 October 2023 (UTC)Reply

Another point here is that most new citations will have been generated automatically. I create a lot of cites and a negligible fraction are hand written. Also new editors are pointed to tools that allow for the auto-creation of cites. None of the tools will generate a cite that contains this parameter. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 13:49, 25 October 2023 (UTC)Reply

Your experience does not match mine. I regularly manually-format some citations, or in many cases manually format them and then pass them through some automated cleanup before saving. Most tools you describe are useless to me because I do most of my Wikipedia draft creation offline, because the Wikipedia draft process has been taken over as a honeypot for spammers instead of as a useful way to create new content. In addition, although I do have scripts that can create properly formatted citations from doi's, they usually require manual cleanup (because the publisher metadata is bad) and I do not have such script for other common aggregators of reference content like jstor, proquest, and NASA/ads. Additionally, some of the software I still use is legacy from long-obsolete OS and compiler versions, and I'm not entirely sure I can recompile it. This means that ongoing changes to parameter formats, and especially, removal of older parameter synonyms, are likely to cause it to stop working. This particular change won't do that but others of similar nature easily could. —David Eppstein (talk) 15:47, 25 October 2023 (UTC)Reply I know well the annoyance of changes scuppering well setup work flows, but the citation formats can't remain set in stone because they break your personal setup. As an aside have you thought about migrating your draft creation to user space? It avoids any of the problems associated with draft space, and a history of the original authors working can be incredibly useful years later when trying to understand issue with the article. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:12, 25 October 2023 (UTC)Reply On the contrary, there is absolutely no reason to break backward compatibility and plenty of reason not to. Along with people stuck with legacy software, another good reason is that broken backward compatibility makes old versions of our articles unreadable. —David Eppstein (talk) 17:50, 25 October 2023 (UTC)Reply I create a lot of cites and the only time I generate them algorithmically is if it's a scientific paper with like six or more authors. The generation scripts frequently miss out on publisher, and always don't generate en.wp specific parameters like |author-link=, |script-title=, etc. But you bring up a good point that many new cites do come from scripts, and it makes a lot more sense to direct energies towards improving Citoid and the things that call it, than it does to twiddle uncommon bespoke parameters that it doesn't deal with. Folly Mox (talk) 16:17, 25 October 2023 (UTC)Reply It seems the vast majority of citations are produced using modern tools then cleaned for issues manually (Citoid regularly has issues). It is simply not that burdensome. As to those papers with hundreds of authors – eg B P Abbot, R Abbot, T D Abbot, F Acernese, K Ackley, C Adams, T Adams, P Addesso, R X Adhikari, V B Adya, C Affeldt ... O M Smirnov, R P Fender, and P A Woudt, "Multi-messenger observations of a binary neutron star merger" Astrophysical Journal Letters 848 (2017) (with over 3,500 authors and 1,000 affiliations; or consider the Physical Review Letters article with 5,154 authors) – just don't name all of them. Use |display-authors=etal. Regardless, corrections should be propagated: doing so will require machine-readable parameters to get it right. Ifly6 (talk) 18:16, 25 October 2023 (UTC)Reply display-authors is intended to be used to change the display only. Simply not adding all of the authors in the first place is an example of a problem, not a solution. Nikkimaria (talk) 00:28, 26 October 2023 (UTC)Reply The idea that we have to include all 100+ authors, though, would not be correct; we're all volunteers here and there is no policy against specifying sufficient authors to identify the paper clearly. Yes, doing something like |display-authors=4 and then just not entering more than 4 names out of the 100 is not the way elide them. The way to do it properly is |display-authors=etal after the fourth (or whatever) author you do want to specify. That's the reason that special etal parameter value exists. (The way-old method of doing something like {{|para|author5|et al.}} and stopping with author entry thereafter is deprecated and has probably already been replaced system-wide (I haven't seen an instance of it in a long time), since it produces blatantly false metadata that claims an author's name literally is "et al."PS: We also need to update the |display-authors= parameter doc to make it clear that this is only for suppressing reader-unhelpfully large lists of authors (dozens or more), not for forcibly conforming all citations in a page to an artificially short list like 3 names. I've run into a case of a guy doing this robotically at articles he has an interest in, and even after it is explained to him that suppressing data we have already entered on 4 or 6 or whatever authors and hiding it from the reader on purpose is utterly pointless and defeats the purpose of entering the author information, and he has no consensus to do it, he just editwars to do it again anyway. I've not made it a noticeboard matter yet, but we're probably going there.
 — SMcCandlish ¢ 😼  02:02, 26 October 2023 (UTC)Reply

Agree with the deprecation of |authors=. For reference, what we have now is:

authors: Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

Trappist the monk changed this to:

authors: deprecated Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

but was reverted by Nikkimaria.

Arguably it should have been:

authors: deprecated Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

since that provides one of the deprecation reasons, and the closing statement remains correct.

Regardless, the idea that people should be using any "free-form list of author names" at all when we have |first=|last= and |firstn=|lastn= is rather nonsensical. Yes, we will have some lazy or confused people abuse |author= or |last= for multiple authors (which already happens all the time anyway), but it would be better to have primarily one form of parameter abuse to look for and clean up after than multiple conflicting ones. For someone who simply cannot wrap their head around CS1 templating, or who has text-entry mobility issues and can't deal with it, or whatever, they can just do <ref>Freeform text here</ref>, and someone will clean up after it later. It is much easier to see and clean up after that than to catch template-buried misuses of parameters. We have no reason whatsoever to have a CS1 parameter that effectively not just replicates freeform ref text but encourages people to do freeform input (and even |vauthors= isn't freeform, but a prescribed, if very unhelpful, format). Either use the templates properly or don't use the templates. There is no point of any kind in a template parameter that basically resolves to "didn't use the template properly", which is exactly what |authors= is, as presently documented and non-deprecated.  — SMcCandlish ¢ 😼  02:02, 26 October 2023 (UTC)Reply

|vauthors= was something of a compromise in 2015 to get people off of one of the alternatives mentioned above. The structure of the format is the predominant reason why it was accepted into this series of templates. To me this is the wrong tree to be barking up. Izno (talk) 08:41, 27 October 2023 (UTC)Reply

I also agree with deprecating the parameter for the reasons already stated. As one of the gnomes who has also picked at the authors category, and one of the primary gnomes responsible for cleaning out the 5000 someodd uses of |editors= before that too was removed, Trappist's examples of garbage citations don't even cover the spectrum of misuses of this parameter (and its now-removed cousins like |editors=). His and SMC's commentary on this are fully in alignment with my views. I'm glad he got this parameter to the point where we can finally be entertaining this discussion.

As stated above, for the users who really do not want to or even cannot take the time to add citations in a structured or even consistent manner, |author= remains with its own category capturing misuses which gnomes work on at whatever pace suits. That parameter won't be going anywhere and certainly neither will the category catching those misuses, but "I can't be assed to input my dozen authors correctly right now" is not a sufficient or even good excuse to continue supporting what is a duplicate parameter. Izno (talk) 08:41, 27 October 2023 (UTC)Reply

Hard agree with Izno, SMC, Trappist, et al. Re Nikkimaria's Simply not adding all of the authors in the first place is an example of a problem, not a solution: Absolutely nobody – and I mean absolutely nobody – is best served by listing all 5,154 authors of G Aad et al, Phys Rev Lett 114, 191803 (2015). Ifly6 (talk) 00:16, 29 October 2023 (UTC)Reply Not withstanding the "hard cases make bad law" principle, there really are a pretty large number of academic works with 100+ authors, and they are almost certainly best treated by listing the first few authors (enough to be certain of identifying the source correctly) followed by |display-authors=etal. But another thing we absolutely don't need is, after we've gone to the trouble of specifying 7 authors here and a dozen there and 4 on that one, and 9 on this other one, as complete author lists, having some rando later editwar to force them all to |display-authors=3 just to be a bonehead who likes suppressing information. Whether 15 authors, or 20, or 40 is "too many" to list seems really up to editorial judgment at an article, but if we already have the information in the citation, it is hard to think of a rational reason to hide the data from the readers. If someone is absolutely certain that 30 authors is too many, they should get consensus to trim the actual included list of them to a shorter number and elide the rest with |display-authors=etal. But keeping them all in the code then using trickery to suppress readers' ability to see them, like |display-authors=10 when there are 30 already coded, is just ridiculous.  — SMcCandlish ¢ 😼  02:55, 29 October 2023 (UTC)Reply A fortnight and more since the last post on this topic suggests that those editors who watch this page and who wished to express an opinion, have done so. I get the sense from the preceding discussion that there is more support than there is opposition for/to deprecating |authors=. I have restored the reverted edits to the module suite and the documentation. —Trappist the monk (talk) 20:10, 14 November 2023 (UTC)Reply I agree; however, it currently reads:

*authors: deprecated Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

and when I see "use of this parameter is discouraged" in strikeout type, that means to me, Combined with the lead-off "deprecated" term, that appears to be self-contradictory. Mathglot (talk) 02:01, 23 November 2023 (UTC)Reply Agreed, and I pointed this out before myself. Th fix is to stop the strike-through at "author names;". It's also still true that "not an alias of last.", so that shouldn't be struck either.  — SMcCandlish ¢ 😼  02:14, 23 November 2023 (UTC)Reply

Subscriptions and archived URLs – recommendation for added guidance

Question: Is it appropriate to add "(subscription required)" or the parameter "url-access=subscription" when the source is an archived-URL? Specifically, we have numerous archived HighBeam URLs on Wikipedia, but they do not require registration or subscription to access. In this example the "url-access" parameter was used, producing the red padlock icon next to the dead HighBeam url. (But how does this information help the reader?) I suggest we add guidance that says "Subscription templates should not be used in connection with dead or archived links and URLs, especially when the archive-URL is freely accessible." – S. Rich (talk) 23:05, 24 October 2023 (UTC)Reply

@Srich32977: I'd meet you halfway with "Subscription templates should not be used in connection with dead URLs where there is no subscription to be paid to access the source." However, if there is a way to access the article with a valid subscription, then go ahead and use the template/parameter, even if a free archive-URL is also accessible. GoingBatty (talk) 02:55, 25 October 2023 (UTC)Reply @GoingBatty: How about this? – "Subscription templates or citation parameters should not be used when citing an online source when there is no subscription or registration required to access the source. This also applies to archived URLs that are freely accessible." This would apply to any online source, archived or not. – S. Rich (talk) 18:34, 26 October 2023 (UTC)Reply @Srich32977: My suggestion is that if the URL is dead, don't use "(subscription required)" or the parameter "url-access=subscription", and if the URL is live but needs a subscription, then add "(subscription required)" or the parameter "url-access=subscription". All that should be independent of whether an archive-URL is available. GoingBatty (talk) 19:16, 26 October 2023 (UTC)Reply @GoingBatty: I agree. My question is, how do we express this guidance on the Citation Style 1 page or any of the citation template pages? I want to add a sentence that makes the guidance clear in each of these help pages. – S. Rich (talk) 19:35, 26 October 2023 (UTC)Reply @Srich32977: Glad we agree! How about this edit? GoingBatty (talk) 01:54, 27 October 2023 (UTC)Reply @GoingBatty: This is a good addition to the guidance. (Thank you!) Here are my concerns for followup. 1. I assume we can apply or add this sentence to other Citation Style 1 related pages – such as {{Cite book}} or {{Cite news}}. Am I correct? 2. Would you, as a bot developer/maintainer modify the GoingBatty bot to cleanup the various HighBeam-related archive urls in order to remove the subscription parameters|templates? (Less than 2,000 such WP articles with these indicators remain.) – S. Rich (talk) 04:27, 27 October 2023 (UTC)Reply @Srich32977: 1. Editing Template:Citation Style documentation/registration means that you'll see the change at Template:Cite book and Template:Cite news. 2. I can submit a BRFA to remove |url-access=subscription or {{Subscription}} from citations with Highbeam URLs. In the example you kindly provided, but I don't understand the value of adding "(archived article)". GoingBatty (talk) 16:21, 27 October 2023 (UTC)Reply Yes please don't add "(archived article)". If that's what we want it should be done via the software automatically not require users to manual type in meta information. These types of free-floating random notes are difficult to maintain. If later we add a feature where the software creates this message or something else, there will end up with two messages, confusing readers and a mess to cleanup. -- GreenC 13:29, 28 October 2023 (UTC)Reply @Srich32977: Coding... GoingBatty (talk) 02:27, 12 November 2023 (UTC)Reply @Srich32977 BRFA filed GoingBatty (talk) 04:21, 12 November 2023 (UTC)Reply

What to do with non-free URLs that go dead

Meaning well, GoingBatty made this tweak to the docs , adding the the following to the documentation of |url=: "If the registration/limited/subscription access to the source goes dead and is no longer available, then remove this parameter (and add |archive-url= and |archive-date= values if possible)". But I just tested that in a sandbox, and the result was a red error message reading "{{cite web}}: |archive-url= requires |url= (help); Missing or empty |url= (help)".

So what do we want to actually be done in such a case? The issues I see:

I think if I ran across this situation right now (and checked for a usable archive-url and found none), I would remove |url-access=, add |url-status=dead, and append a {{dead link|{{subst:DATE}}|fix-attempted=yes}} after the </ref>. Pretty much, the citation needs to be replaced with an equivalent source, since the one cited is no longer verifiable. But maybe someone else has another idea.  — SMcCandlish ¢ 😼  05:39, 27 October 2023 (UTC)Reply

My feeling is that if a link goes dead but has an archived copy, we should keep the link, and add archive-url and url-status=dead. If a link goes dead and has no copy, and is part of a citation only to web content, we should tag it with {{dead link}} but leave it in place until someone either finds a better replacement reference or an updated url, because the link is useful information in the search for either of those things. If the link goes dead with no copy, but is merely a courtesy link on a citation to a printed reference, we should remove it. None of those choices depend on the subscription-access status of the link, which in any case could have changed and will be unverifiable. —David Eppstein (talk) 05:49, 27 October 2023 (UTC)Reply @SMcCandlish: I didn't mean to remove the |url= parameter. I meant remove the |url-access= parameter (or other matching access-indicator parameter). I've revised my edit to make this more clear. GoingBatty (talk) 15:10, 27 October 2023 (UTC)Reply

This thread was started to discuss the guidance about tagging citations with "subscription" parameters and templates. E.g., when we have a source that does not require a subscription should the citation have "subscription" notations? This occurs when sources such as Questia and HighBeam go dead. (When they were alive readers were required to subscribe or register to access them.) As Questia and HighBeam are defunct, we only have archived copies of their material. I want to make clear that those archived urls do NOT need a subscription or registration to access. Removing "subscription" notations is helpful in that regard. In the HighBeam cases, is a "{{dead link}}" helpful? I don't think so. 1. If there is no archive url then nothing can be done. (I've run the "fix dead link" tool on dozens of these links and there are no repairs.) 2. If there is an archive url for the HighBeam link, then a "{{dead link}}" tag is not needed or helpful. (Such a tag only clutters the citation.) So, I think the guidance should stand as is. E.g., we tell editors that they should remove "subscription required" notations when the urls do not require a subscription. – S. Rich (talk) 15:06, 27 October 2023 (UTC)Reply

It might be possible to find whatever was being referenced through Highbeam from a different source, and the archive of Highbeam is never going to be useful. So using {{dead link}} is appropriate. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 15:35, 27 October 2023 (UTC)Reply Well, I can also see "If the link goes dead with no copy, but is merely a courtesy link on a citation to a printed reference, we should remove it." A typical Highbeam or Questia case is going to a printed source, so the cite is not actually unverifiable without a working URL, it's just tediously verifiable without a working URL to an online version.  — SMcCandlish ¢ 😼  00:48, 28 October 2023 (UTC)Reply But given there are editors who will go find a different source, and it wasn't difficult for the one I saw, why not give a highlight that the current link is dead. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 11:08, 28 October 2023 (UTC)Reply How would that be more helpful that removing the dead link for which there is no archive-url? It still results in a cite to a valid source that someone has to find on paper or via some other means, just with less code bloat. The old dead link doesn't seem to make that easier in any way, nor signal in any way that "this cite doesn't have a URL link you can use" that isn't also signalled by no link being present at all. But maybe I'm misunderstanding something about what you're saying.  — SMcCandlish ¢ 😼  11:29, 28 October 2023 (UTC)Reply This is different from the general sense of reference not needing links, as they are just there to be helpful. Because of the nature of Highbeam it's quite likely that a different link could be found, giving a signal that this is the case to any editor who wants to go find one would only help anyother editor who wants to verify the information. Highlighting a way that someone might help isn't bloat. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 11:51, 28 October 2023 (UTC)Reply I want to make clear that those archived urls do NOT need a subscription or registration to access. Web archive links (please read web archive to fully understand what this term means), are not source links. They are mirrors, a proxy of the source link. The "subscription" refers to the original source link and its proxies. You are right that a literal subscription is not required, because the source site is dead. However a number of editors have said we should still keep this metadata information because it might help to better understand how the original source was accessed. Personally, I think if you are manually refactoring a citation ie. verify what is being cited, verifying sources, looking for new sources, etc.. you have the right to change the citation, like you were citing it brand new. Citations are not written in stone, they can be redone. The problem arises when doing things quickly at scale, then it looks like something else, like you are blindly removing "subscription" as a rule. -- GreenC 13:43, 28 October 2023 (UTC)Reply

First and last names

The instructions do not appear to say anywhere what "first name" and "last name" mean. Someone just edited Chōchin'obake to use the Roman form of a name, "Mizuki Shigeru" (水木しげる), writing "first=Mizuki" and "last=Shigeru". Looks ok, except that Mizuki is his family name, and Shigeru is his given name. Something is wrong here: personally I think using "first" and "last" to distinguish parts of a person's name is one of the stupidest ideas in WP, against some tough opposition, but it would be OK if at least the instructions explained what they meant. Imaginatorium (talk) 13:06, 30 October 2023 (UTC)Reply

You might find the aliases |given= and |surname= less confusing in cases like this. Kanguole 13:09, 30 October 2023 (UTC)Reply Thanks. Yes, but if other people are allowed to use the (fundamentally meaningless) "first" and "last", the confusion will persist. Imaginatorium (talk) 13:28, 30 October 2023 (UTC)Reply There's not a mechanism to prevent them from doing it.  — SMcCandlish ¢ 😼  13:33, 30 October 2023 (UTC)Reply Yep. It is not intended to do |first=Mizuki just because Mikuki comes first in Japanese order.  — SMcCandlish ¢ 😼  13:31, 30 October 2023 (UTC)Reply Especially because our citation templates reverse the meaning of last and first, and generally put the one they call "first" last and the one they call "last" first. So putting first=Mizuki would have the effect of avoiding Japanese name order (because it really means the reverse, put that part last) rather than of respecting it. —David Eppstein (talk) 18:04, 30 October 2023 (UTC)Reply I think the horse has long-left the barn on our use of first/last to mean given and family/surname. As for whether the documentation should say something, maybe it's western bias but I would expect the two to be basically the same use everywhere. It's how every form someone in a western nation has been conditioned to fill in, like since a century or more ago (otherwise we probably would not have had that Asian naming confusion pop up ever I would guess). Anyway, which specific part of the documentation is an issue (i.e., provide the lines at issue)? I have no issue adding links to the relevant pages on Wikipedia. First name goes where you expect, as does last name, but we can link directly to the intended meanings if desired. Izno (talk) 17:45, 30 October 2023 (UTC)Reply Just a comment - I spent the first half of my life in England, um, an English-speaking country, and there I do not think I have ever seen a form ask for "first name" and "last name". (Nor any obvious equivalent in any other European country. It's 'Surname', 'Christian/Fore/given' in England, nom, prenom in France, etc.) Of course we know about the Americans, but when we have to use what comes over as a (globally) stupid idea, it should at least be made explicit. Imaginatorium (talk) 08:11, 5 November 2023 (UTC)Reply It probably wouldn't hurt to have additional aliases. And maybe to favor clearer ones in the documentation, like |surname=|forename=, or |family=|given=. Though of course we wouldn't want WP:MEATBOT or WP:COSMETICBOT activity triggering every watchlist in existence by substituting equivalent parameter names that the reader doesn't see and which don't practically matter for editors.  — SMcCandlish ¢ 😼  12:47, 5 November 2023 (UTC)Reply As an American I'm used to the terms first and last, but I must concede that they are confusing, and can not quarrel with Imaginatorium's characterization of them as stupid.. Parsing names correctly is hard and, IMHO, you should never presume to validate or "correct" someone else's parsing unless you are thoroughly familiar with the cultural milieu of the name, and even then it is dicey. I agree that |familyn= and |givenn= are less confusing. I'd also like to see more explanatory text in the documentation for |first= and |last=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:01, 5 November 2023 (UTC)Reply

inter-language wikilinks for author names

English Wikipedia has a nice {{ill}} template which will put small wikilinked 2-letter language IDs in brackets after a red link – linking to Wikipedia articles in one or more other languages concerning the subject of the red link – to possibly inspire readers who come across the red link to try translating them into English, and to give readers a way to find out about the subject (possibly via Google translate or the like) we don't currently have a page about, in a way that is clear but doesn't waste space. For example, Giuseppe Cesàro. However, there's no way to get similar behavior in CS1 or CS2 citation templates. We're stuck with either (a) a red link, e.g.

Cesàro, Giuseppe (1905), "Nouvelle méthode pour l'établissement des formules de la trigonométrie sphérique" , Académie royale de Belgique: Bulletins de la Classe des sciences, ser. 4 (in French), 7 (9–10): 434–454

Or (b) a single inter-language wikipedia link which puts a full language name in brackets:

Cesàro, Giuseppe (1905), "Nouvelle méthode pour l'établissement des formules de la trigonométrie sphérique" , Académie royale de Belgique: Bulletins de la Classe des sciences, ser. 4 (in French), 7 (9–10): 434–454

Or (c) in these cases I'm tempted to just leave the citation templates out and use {{ill}}, optionally with {{wikicite}} if I need a parenthetical reference somewhere else:

Cesàro, Giuseppe (1905), "Nouvelle méthode pour l'établissement des formules de la trigonométrie sphérique" , Académie royale de Belgique: Bulletins de la Classe des sciences, ser. 4 (in French), 7 (9–10): 434–454

The two citation template outputs seem significantly inferior to the {{ill}} template output. The red link version gives the necessary red link, but doesn't provide link(s) to the possibly multiple other-language wiki pages about the subject. The inter-language wikilink version does not include a red link (in my opinion an unacceptable compromise), wastes space by spelling out the full language name, somewhat confuses readers by appearing in the normal position for a link to English Wikipedia but then pointing off-site to a page in another language, does not allow for multiple inter-language wikilinks, and finally is gratuitously inconsistent with the output of {{ill}} which is in moderately wide use and therefore likely to be familiar in format to regular Wikipedia readers.

Is there any technically feasible way we could extend the citation templates to instead support output of the style of the {{ill}} template? It would probably be best to make the specification of inter-language wikilinks a separate parameter instead of trying to reuse the author-link parameter for this. –jacobolus (t) 18:16, 30 October 2023 (UTC)Reply

The originating discussion is at Help talk:Citation Style 1/Archive 86 § author-link=interlanguage. —Trappist the monk (talk) 18:42, 30 October 2023 (UTC)Reply I think linking to the Wikidata item here is the right approach on the general balance when you have multiple other wikis to point to. These links are ultimately convenience links and assist neither in metadata generation nor in assisting users in the specific effort of finding a specific cited work (see WP:CITE). I suspect a little nudge in the CS1/2 code base could make it so that when the citation module detects via Wikidata (only?) that an English article exists that a maintenance message be raised for someone to link the onwiki version, but calling out to Wikidata is in general an expensive operation and this module is already one of our heaviest invocations in any specific article (both by size of module set and by number of uses). Izno (talk) 21:27, 4 November 2023 (UTC)Reply In general links to Wikidata from article space are highly discouraged, much more so than links to other-language Wikipedias. There's some discussion of this at Wikipedia talk:Manual of Style/Archive 202#When (and how) SHOULD we link to Wikidata?. And we cannot rely on name-matching to correctly identify authors (grumbles about the two different physicists named Maria Longobardi I got confused about today). I think the only way to reconcile this with using Wikidata to detect missing authorlinks would be to have the Wikidata item present as a parameter to the citation template but never used to generate reference text, but that also means nobody could spot and fix the inevitable errors. —David Eppstein (talk) 22:03, 4 November 2023 (UTC)Reply Yeah, hence general balance. I don't want per se to endorse addition of it, but if an author really does exist on multiple other wikis but not here and someone citing that must have a link to multiple other wikis (ignoring the above about necessity even of our linkage), that Wikidata is the right place to point. My general thought ignoring that factor is that you probably don't actually need to link to multiple others, just link to the one where the article is least likely to be deleted because it's about an author who writes or who is native to that language. (I have a similar opinion about {{ill}}: I don't need 5 links to other wikis for a French author, just French Wikipedia.) Izno (talk) 22:25, 4 November 2023 (UTC)Reply My point above is that the "right place to point" is in my opinion always a red link on English Wikipedia. Wikidata is a poor alternative in my opinion. But it also often seems helpful to readers to supplement the red link with an inter-language link. 5 other-language links is obviously excessive in this kind of case (even 3 is really pushing it), but I've found some cases where two other-language wikipedia articles have distinct substantive content, where linking just one of them seems inferior to linking both (though in the context of a citation, just picking one could be fine). YMMV. –jacobolus (t) 22:38, 4 November 2023 (UTC)Reply

I've seen some removals of this at articles lately. Are we certain this is really redundant? There's a potential difference to me here between "someone has checked this and we know that it is dead" and "no one has checked this and the parameter is missing". It seems to me that removing it could just lead to unnecessary editorial time-waste checking to see if the non-archive original URL is actually live or not. If we're sure it's not needed, I'm okay with that; I'm in favor of reducing redundancy. (Like why oh why do people keep adding |language=en when that's the site-wide default when no other language has been explicitly specified? And doubleplus why do people keep doing |langauge=en-GB, etc., when the exact dialect of the source is irrelevant? No one competent to read American English is going to need a translator to read British English.)  — SMcCandlish ¢ 😼  14:07, 31 October 2023 (UTC)Reply

Re the language parameter, I doubt this is people adding it, more not removing it. The citation tool adds the parameter automatically if it finds the relevant information on the source page. Nthep (talk) 14:51, 31 October 2023 (UTC)Reply Hmm. So, how to get that to stop happening when (on this site) the value returned in en or en-*? It's annoying, and resulting in an unbelievable amount of pointless code bloat.  — SMcCandlish ¢ 😼  15:27, 31 October 2023 (UTC)Reply Having |language= set helps with translation efforts. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 15:18, 31 October 2023 (UTC)Reply Any translator taking material from already knows that the default language is en, and 99%+ of our cites to en sources do not have this parameter, so it is not helping with translation efforts. Even if it was, somehow, some way, it is not worth the amount of code bloat in our live articles.  — SMcCandlish ¢ 😼  15:27, 31 October 2023 (UTC)Reply It's very little code bloat, especially as the reader doesn't even see it. Also a lot of non-technical editors translate articles and rely on automatic trasnlation of cites. The mass removal has been previously discussed on one of the village pump pages, and gained no traction. I was initially for removing it, but came to see the other sides point. It's 12 characters, it hurts no-one and helps some. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:02, 31 October 2023 (UTC)Reply No readers ever see any code bloat, because it's in the code, by definition. It's an editing and maintenance issue, not an end-user readability matter. It's 12 (often 15) characters over and over and over again on page after page after page. Not trivial. Mass removal of anything generally gets opposed on "I don't want my watchlist going nuts" grounds, especially when the change does not affect the reader's view. So that's not a principled position against deprecating this usage and getting tools to stop automatically doing it. If there's an actual use case for this, I have yet to see it, and I've been here 17 years. I guess I will go see if I can find some arguments for it that I missed, since you suggest there are some, but these vague hints are not promising. If the user already knows by default that the material will be English (and besides, the entire page already has lang="en" for its entire content except were explicitly overridden), there doesn't seem to be an auto-translation-tools reason for this.  — SMcCandlish ¢ 😼  17:22, 31 October 2023 (UTC)Reply That's how the auto-translation tools work and usually they are translating the cite once they have reached the target wiki, so no lang="en" is not set. You've missed that {{Ouvrage}} is a redirect to {{Cite book/French}} for instance, and what AnomieBOT does when it's used. So there is a explicit reason to have it. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:54, 31 October 2023 (UTC)Reply Can you explain what you mean in more detail? If the tools are translating some other wiki's content, then that wiki will be providing its own lang information already. I don't see what the {{Ouvrage}} redirect has to do with anything, or {{Cite book/French}} for that matter, since if it's translating a template imported with French-language parameters from fr.wikipedia, that template will already either be for a French source (by default) or come with a |language=en (or I suppose |langue=en) if it's an English-language source being cited, and not need a |language=en parameter newly added, plus will get substituted out by a bot anyway and no longer need that parameter after the work is done. Am I missing something still? The fact that there are special and short-term use cases for |language=en doesn't seem to translate (pun intended) into a stick-them-in-every-English-citation-redundantly rationale.  — SMcCandlish ¢ 😼  18:06, 31 October 2023 (UTC)Reply Just because {{Ouvrage}} was imported from does not mean that the source is written in French – likely it is, but there is no guarantee. doesn't use cs1|2 but they do have |langue=. At, when |langue=fr, the language output is suppressed; that's where we got the idea to suppress the output here when |language=en. —Trappist the monk (talk) 18:34, 31 October 2023 (UTC)Reply
  1. An editor translates the article text.
  2. The editor directly copies the cites without any translation.
  3. Anomiebot substitutes the cites using Cite book/French as direction of how to correctly rename the fields.
All this happens on enwiki, so unless the frwiki cites have |language=fr set the cites on enwiki don't have it either. All of this makes it easier for editors to translate articles without having learn the technical details of how the templates work. It is a real and specific reason to include |language=en. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 19:58, 31 October 2023 (UTC)Reply "makes it easier for editors to translate articles" is an almost entirely theoretical idea, since nearly none of our citations to English-language sources have |language=en. There is surely a better way to do this than dumping enormous amounts of redundant code into our articles. The fact "this could work to make translation easier" doesn't make this the best, or even a reasonable, idea in furtherance of that goal. (If I need to move my car over by one foot, I could do it by hitting it with sledgehammer and over and over on one side, moving it a milimeter at a time, but this would not be a good idea.) Fr.wikipedia should be presuming by default that a copy-pasted citation off of en.wikipedia that they are using a local tool to translate into an equivalent French cite template is by default an English-language source. There is no reasonable other assumption to make. I'm not convinced in any way that whatever need is being flagged here can only, or even best, or even practically, be solved by jamming in literally millions of |language=en instances. I think we are more clever than this and can build better, cleaner-running tools. Same with "unless the frwiki cites have |language=fr set the cites on enwiki don't have it either"; if our template-translation tool knows the template is from fr.wikipedia (and it would have to, to properly parse the parameters) then we already know that the default thing to do, absent something like a |langue=zh in their template, is to add |language=fr in our version.  — SMcCandlish ¢ 😼  06:06, 1 November 2023 (UTC)Reply As I said earlier I was convinced of it in another discussion, because people are actively using it this way so no it's not theoretical in anyway. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 12:26, 1 November 2023 (UTC)Reply This is more vague "I saw something somewhere once" hearsay. We need specifics, and an examination of whether their alleged need for this can be met some other way that doesn't entail adding millions of blobs of otherwise unneeded code all over the 'pedia.  — SMcCandlish ¢ 😼  18:09, 1 November 2023 (UTC)Reply I'm not going to go and dig around every VP archive to find the discussion, and it's obvious even that would not change your mind so I'll drop it. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 20:13, 1 November 2023 (UTC)Reply My mind actually frequently changes, especially on matters like this, in response to evidence that can't be easily dispelled (like some of the translation-related arguments made so far can be, but there may be stronger ones). I don't think it's unreasonable to respond with "show me" when someone says "I've seen the proof".  — SMcCandlish ¢ 😼  21:05, 1 November 2023 (UTC)Reply The problem is not that no people ever could be using it this way. The problem is that (a) only vanishingly few current citations include this, so it can't be relied on, (b) that most citations are in English is obviously implicit here, and describing that explicitly adds a lot of boilerplate noise to the template, (c) the harm of Wikipedians translating English articles to their own language and accidentally not tagging all of the citations as being in English is temporary and pretty trivial, (d) large-scale automated edits adding it to existing citations are a big distraction not justified by the trivial benefit. This problem would be much better addressed by fixing whatever automatic translation tool people are using. –jacobolus (t) 18:16, 1 November 2023 (UTC)Reply And |language=en is 12 characters that hurts no-one , so what. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 20:15, 1 November 2023 (UTC)Reply The citation templates are already a lot of noisy boilerplate, even in the best case, and a magnet for relatively useless redundant metadata. The longer and more annoying filling out the templates gets, and the more often bot-like editors come and pointlessly twiddle the parameters for little or no benefit to readers, the more I'm tempted to just use plain wikitext for citations, optionally with {{wikicite}}. Every new hoop the templates make human editors jump through is another step in the wrong direction. –jacobolus (t) 22:50, 1 November 2023 (UTC)Reply No new hoops are being added as I said no-one has suggested mass adding it, or the need for editors to add this parameter when setting up cites, or for any editors to go adding this parameter to already existing cites. Many cites that are created automatically using lookups include this parameter, this is not something that is controlled by the editors maintaining these templates. You have the whole discussion back to front. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 22:59, 1 November 2023 (UTC)Reply I thought the problem was with people making edits adding language=en to existing citations? If not, what's the complaint? –jacobolus (t) 23:04, 1 November 2023 (UTC)Reply The discussion is that it should be removed from cites that already have it, which I feel is a waste of time and could negatively impact some editors is niche situations. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 23:10, 1 November 2023 (UTC)Reply If someone wants to incidentally remove language=en in a citation or two as part of reformatting them, fine. Automatic removal of language=en on a wide scale seems like a big waste of attention. –jacobolus (t) 23:36, 1 November 2023 (UTC)Reply (edit conflict) |language=en has nothing to do with the html attribute lang="en". The |language= parameter is there so that readers can know the language of the cited source; see the template doc. cs1|2 suppresses rendering of the source language when the source language is the same as the local wiki's language. If a cs1|2 template is never, ever, going to be copied to another language wikipedia, then |language=en is obviously superfluous. If the cs1|2 template may be copied to another language wikipedia, then |language=en renders the source's language in the local language without the copying editor having to do anything: at, for example, |language=en renders as '(në anglisht)'. Leaving |language=en aids editors who copy articles to their home wiki and does no harm to editors here. Translation is aided by editors here using the ISO 639 language tag instead of the language name because MediaWiki will provide the name in the local language without the editor there having to translate 'English' to the local language or to the ISO 639 tag. —Trappist the monk (talk) 18:25, 31 October 2023 (UTC)Reply If our only or primary rationale for injecting |language=en eventually millions of times into our content is to save someone the trouble at another wiki of adding their local equivalent of |language=en to citations they copied from us, then my opposition to this idea is now more solidified than it was to begin with, especially since a template translation tool can be configured to just add that parameter by default any time it is working with a template that it recognizes as having come from en.wikipedia and which doesn't say something like |language=ja (and the tool would have to be able to do that recognition or it would not be able to convert the highly particular template parameters to the local version in the first place).  — SMcCandlish ¢ 😼  06:06, 1 November 2023 (UTC)Reply I entirely agree. Please everyone let's not start havings bots or humans-pretending-to-be-bots add language=en to every citation. What a massive waste of time and attention. And please don't start randomly adding language=en to a hodgepodge subset of citations either. This is an unnecessary and unhelpful thing to include. –jacobolus (t) 06:43, 1 November 2023 (UTC)Reply No-one is suggesting any such thing, this discussion is actually about the opposite - the exclusion of |language=en not adding it. Many tools will automatically add this when editors use auto-creation, if you disagree with that this is the wrong talk page as those tools are not maintained here. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 20:23, 1 November 2023 (UTC)Reply The direct implication of al these "it's so useful for translating" claims (which have so far been unevidenced or easily dispelled, but maybe there is a better one yet to be made) is that eventually they will be imposed everywhere. It's a natural consequence of the argument that they're useful. They're only useful if they're imposed consistently. So raising this concern is in no way out-of-bounds.  — SMcCandlish ¢ 😼  21:05, 1 November 2023 (UTC)Reply They have not, and as above please don't try to restart this. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 22:30, 1 November 2023 (UTC)Reply "They have not" what? That has no clear referent, either as to what comes after "not" or what/who "they" is.  — SMcCandlish ¢ 😼  06:44, 2 November 2023 (UTC)Reply I know that I also have seen comments here and there also that the use for translation happens. Take it on faith that we're not spouting complete bullshit. :) You can still make your other points ad arguendum regardless. As for mass-addition of |language=en, that is definitely a strawman. The only system that does anything remotely like that is Citoid (and other systems that use Citoid's output these days) when a website puts a language into its HTML. And like all such citations, I clean the ones that have totally garbage output that often get caught in our category dragnets and allow someone else to state a preference on whether |language=en actually should exist in the article or not. Following the principles of WP:CITEVAR even if this case is one ultimately of wikitext formatting (where we have already established the requirements of CITEVAR don't apply besides to the distinction between using CS1/2 and a hand-input style) and annoyance with what some see as clutter to-be-removed rather than clutter to tolerate for the health of the movement rather than our specific wiki. Izno (talk) 21:06, 4 November 2023 (UTC)Reply Yes, |url-status=dead in the presence of |url= and |archive-url= is meaningless. When given |archive-url= with an assigned value, Module:Citation/CS1 assumes that |url= is dead. It has been ever thus: Cite book comparison
Wikitext {{cite book|archivedate=2023-10-21|archiveurl=|title=Title|url=}}
Old Title. Archived from the original on 2023-10-21.
Live Title. Archived from the original on 2023-10-21.
I don't know where that extra url is coming from {{cite book/old}} does not know about |url-status=. Rewriting the example template to use |deadurl=yes returns the exact same result {{cite book/old|archivedate=2023-10-21|archiveurl=|title=Title|url=|deadurl=yes}} Title. Archived from the original on 2023-10-21.  Rewriting the example template to use |url-status=dead returns the exact same result with the live template: {{cite book|archivedate=2023-10-21|archiveurl=|title=Title|url=|url-status=dead}} Title. Archived from the original on 2023-10-21. |url-status=dead is not a substitute for {{dead link}}. |url-status=dead is never needed and is always redundant. Perhaps the dead keyword should be deprecated and support for it withdrawn. —Trappist the monk (talk) 15:11, 31 October 2023 (UTC)Reply This would definitely help with editors misusing it to mark dead links. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 15:19, 31 October 2023 (UTC)Reply Okay, if it's really useless, and it's causing confusion with {{dead link}}, then I'm all for the deprecation, will stop using this parameter, and will remove it (and the old |deadurl=yes) when doing cite cleanup. Update: Now not sure sure of that, given the disputation below.  — SMcCandlish ¢ 😼  15:27, 31 October 2023 (UTC); revised: 18:16, 1 November 2023 (UTC)Reply

The behavior described here, of always treating urls that have an archive-url as being dead, is fucked up. In most cases when there is a live url, we want to send readers to the live url, because in most cases updates to the content are helpful to readers. When Internet Archive Bot or whoever adds an archive-url as a prophylactic measure rather than because the url has gone dead, that should not suddenly make that version of the url be the only one that readers ever see going forward. —David Eppstein (talk) 16:02, 31 October 2023 (UTC)Reply

If |url= is live when InternetArchiveBot adds |archive-url= to a cs1|2 template, it should set |url-status=live. If IABot is not doing that, you should take up the issue with its maintainer either at User talk:InternetArchiveBot or at User talk:Cyberpower678. —Trappist the monk (talk) 16:24, 31 October 2023 (UTC)Reply I strongly agree with @David Eppstein. @Trappist the monk removing these parameters en masse without community consensus is disruptive. Please immediately desist until you have broad support. –jacobolus (t) 22:48, 31 October 2023 (UTC)Reply Here's what I said at user talk:Trappist the monk: Including "url-status=dead" is much more explicit communication to human editors than just leaving url-status out entirely. It's important because the internet archive's bot (and various human editors) keep adding archive URLs to still-living pages, so the mere presence of an archive URL is not sufficient to communicate that the original page is dead, but instead what it communicates is "whoever added the archive URL was too lazy to check", which then wastes follow-up effort by other editors manually checking all of these. conveys no meaningful information – this is not true. url-status=dead clearly communicates that the link is dead. The complete absence of such a parameter does not communicate the same thing. You should not be removing these en masse without community consensus. –jacobolus (t) 22:50, 31 October 2023 (UTC)Reply Agreed - the parameter is useful. There are several news sites where current live url requires subscription for full text access, but the Internet Archived version from the first day the article was live allows the user to access the full text; when I use this cludge, I do typically include some note to the reader indicating this in the citation. Regards. User:Ceyockey (talk to me) 00:28, 1 November 2023 (UTC)Reply Well, if you're already manually including a note to this effect, using the parameter to also signify this in a really subtle way would seem to be redundant. For most use cases, we don't have a rationale to completely suppress the link to the original URL anyway, since a source that requires a subscription is not forbidden. I think the proper thing to do is this: {{cite news |title=Maps: Tracking the Attacks in Israel and Gaza |date=October 31, 2023 |work=The New York Times |url= |url-access=subscription |url-status=live |archive-url= |archive-date=November 1, 2023 |access-date=November 1, 2023}} I just tested in a sandbox, and this has the original URL available and flagged with the subscription icon, and the archive-url available with no such flag. People with NYT subscriptions can use the former, everyone else the latter, and if a user clicks first on the former but has no subscription and just didn't pay attention to the icon, and has to backtrack and click the IA link instead, the sky has not fallen down. Especially if you're also adding a note along the lines of "Full text available free at the archive link." PS: This cite type definitely works for NYT, and Washington Post (e.g. ), but I don't know if IA's archival stuff manages to defeat other paywalls. Sometimes there might not be a useful archive-url with the full text, and we might be stuck with just |url=...|url-access=subscription. So it goes.  — SMcCandlish ¢ 😼  06:06, 1 November 2023 (UTC)Reply Adding url-status=live is obviously helpful for a live link. But adding url-status=dead is also a helpful signal for a dead link, because it is explicit rather than implicit. A human reader of either of those can immediately tell what the person who added the parameter meant, instead of being forced to guess. –jacobolus (t) 06:46, 1 November 2023 (UTC)Reply Thanks for the advice. User:Ceyockey (talk to me) 00:01, 4 November 2023 (UTC)Reply Are we certain this claim about Internet Archive Bot is correct? Does someone have a recent diff of this or any other bot adding |archive-url= without |url-status=live when the original page is in fact live? If it is happening, wouldn't the solution be to fix the bot rather than add redundant |url-status=dead to zillions of citations? Is occasional human error sufficient reason to do it? Especially when the whole point of the archive-URL is that it is working copy of the source in question, so no reader is harmed by going to that version instead of the original anyway? I'm skeptical that we should be tolerant of longwinded code bloat on a massive scale as the solution to an alleged bot problem that should be easily fixable, and a human-error problem that is like unto an innumerable number of other trivial human errors we deal with without going to such extremes. I would think also that whether or not |access-date= is older than |archive-date= is already the functional system we have for determining whether the original URL has been checked for live status when adding the archive-url, or whether someone or something just tacked one of the latter on in drive-by fashion without checking whether the status is live.  — SMcCandlish ¢ 😼  06:06, 1 November 2023 (UTC)Reply whether or not |access-date= is older than |archive-date= is already the functional system no this is by no means adequate. It's based on a chain of dubious inferences which are regularly violated. –jacobolus (t) 06:47, 1 November 2023 (UTC)Reply I spot checked the first 30 or so diffs at Special:Contributions/InternetArchiveBot. I found one instance of IABot adding |url-status=live(Special:Diff/1182963903) and one instance of the bot adding |url-status=bot: unknown (Special:Diff/1182966277). To every other cs1|2 template touched by the bot, it added the superfluous |url-status=dead. —Trappist the monk (talk) 13:38, 1 November 2023 (UTC)Reply The bot is generally using these parameters in a reasonable way. Having the bot be explicit about whether the URL is live or dead is a good thing. Personally I'd prefer if people (or bots) never prophylactically added archive links to still-living pages except in special circumstances with some human intention involved (e.g. the "living" page is paywalled). –jacobolus (t) 14:04, 1 November 2023 (UTC)Reply The purpose of |url-status= is to tell Module:Citation/CS1 what to do when presented with both |url= and |archive-url=. In the absence of |url-status=, Module:Citation/CS1 defaults to linking |title= with |archive-url=; this is the module's default case. Setting |url-status=dead does not instruct the module to do anything different from its default (thus my conveys no meaningful information comment). The addition of |url-status=dead is therefor pointless, redundant, code bloat, clutter, pick your favorite term. Parameters that accomplish nothing have no value so should be removed. —Trappist the monk (talk) 13:38, 1 November 2023 (UTC)Reply The purpose of url-status is to communicate the status of the URL, both to the citation rendering template, and also to human editors. –jacobolus (t) 14:05, 1 November 2023 (UTC)Reply The purpose of |url-status= is to control the selection of the live URL or the archive URL, as the documentation has always shown. It does not and has never been for the url-status of the source, does that make it confusing named - yes - should it be used to show the status of the URL - no that's what {{dead links}} is for as that template actually shows the link is dead to the reader (url-status=dead give no display output to the reader). -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 20:20, 1 November 2023 (UTC)Reply The way you tell *readers* that the link is dead is by switching the order of the links and making the archive link primary. The way you tell markup-reading *editors* that the link is dead is with the "url-status" parameter. Leaving this parameter out entirely is not explicit enough to clearly communicate the status of the URL. When the parameter is left out, human editors will waste their time double checking all of the links, because the status is not communicated clearly and unambiguously. –jacobolus (t) 22:52, 1 November 2023 (UTC)Reply To be more concrete/explicit, it is confusing to have: No archive URL → url-status is implicitly alive Archive URL → url-status is implicitly dead This is okay as a fallback interpretation, but it is much better still to have an explicit url-status included whenever there is an archive URL, because it is then entirely clear what was intended and what the most-recently-checked URL status is. An editor who checks the link can just change dead ↔ live as needed. –jacobolus (t) 23:01, 1 November 2023 (UTC)Reply I think we're just saying the same thing slightly differently and from different directions. I agree that url-status is used to select whether the URL or archive URL is used. The problem is that editors use it when no archive URL is present. So the URL is dead, no archive link is present, and they set |url-status=dead rather than use {{dead link}}. It's that scenario I'm saying is wrong. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 23:09, 1 November 2023 (UTC)Reply The problem is that editors use it when no archive URL is present – this is different than the problem I am complaining about, which is semi-automated edits which do nothing but remove url-status=dead from links that have an archive link. –jacobolus (t) 23:39, 1 November 2023 (UTC)Reply Yeah I thought we were talking at cross purposes. I'm against editors mass removing these, it's just a pain that it gets misused a lot. Editors also incorrectly add |url-status=live to cites with no archive url, which does generally get removed. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 01:56, 2 November 2023 (UTC)Reply Though it might not be a bad idea to allow url-status=dead even without an archive link, and format the output the same as {{dead link}} in that case. –jacobolus (t) 23:42, 1 November 2023 (UTC)Reply Which guidance does it violate, when a link is dead, an archive exists, and no alternative url is found hosting the information, to set the |url=(archive page)? I'm pretty certain this is against some policy or another, but I'm not sure which one, and it seems like a natural shortcut when citing deadlinked sources. Folly Mox (talk) 00:41, 2 November 2023 (UTC)Reply

I concur with jacobolus. When there is no url-status there is a higher probability a mistake was made. The explicit url-status provides a greater degree of assurance what the last editor intended. It's not intuitive that a missing url-status is the same as dead, more like an expert editor's shortcut. -- GreenC 23:11, 1 November 2023 (UTC)Reply

I'd be happy with renaming the field |archive-req= with yes/no/usurped/deviated being the answers, but at this point that would probably break to many things. My point was that it's not a field to mark the URL status, it's for showing which URL to use. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 23:17, 1 November 2023 (UTC)Reply Yeah, that would lead to massive breakage. And it's not clear what it even means ("archive-req"?).  — SMcCandlish ¢ 😼  10:19, 4 November 2023 (UTC)Reply Well, someone's still removing |url-status=dead from random articles, but I don't get the sense that there's actually a consensus in favor of the idea. I like the notion of removing any parameter that is actually redundant, but in fairness I'm not certain this is seen to be reundant, regardless what the original idea for implementing the parameter was. But that kind of concern in and of itself has not always won the day (e.g., I and others were basically just overridden on the use of |access-date= as an indicator of when someone last actually looked at the source, of any type, to see whether it agreed with the content it was cited for, and it has been disabled for anything without |url= because the original idea of the parameter was supposedly just indicating when the URL was checked to be valid/loading at all). People can have different points of view about these things. I am fairly certain that MEATBOT-style removal of |url-status=dead should probably not be happening while this discussion is unsettled, though. (Just as I have stopped normalizing ISBNs to hyphenless form since there's a discussion open at VPPOL about what should be done).  — SMcCandlish ¢ 😼  10:19, 4 November 2023 (UTC)Reply I continue to remove the parameter when it appears in an article of interest, though it's not a category I focus on. I do so for the same reasons as presented by Trappist, and for the same rationale for the parameter's creation. Izno (talk) 21:13, 4 November 2023 (UTC)Reply To some degree, I find it ironic and/or hypocritical that in the very same section we have people arguing that |language=en is cruft and unnecessary and to be removed despite at least one valid use case, and |url-status=dead (for dead URLs) is not. Izno (talk) 21:15, 4 November 2023 (UTC)Reply In my opinion, language=en is by far the majority case, and very obviously implicit for every citation and not at all a point of confusion. Also even for non-English links, leaving out an explicit mention of which language the citation is in is a kind of trivial oversight of minimal harm to readers (because for example the title is usually written in that language; someone seeing a source with title in German or Latin is not going to be excessively surprised that they don't get an English page when they click). There really isn't any need to be explicit that every ordinary citation to a source with a title and other metadata written in English points to an English language source. So including that parameter redundantly is pointless cruft. I don't mind if someone copy/pastes a citation from another language wiki and happens to leave language=en; in that instance its presence isn't doing any harm and doesn't need to be immediately cleaned up or anything. But I definitely don't want us to have a bot crusade inserting language=en to every citation site-wide, which would be extremely obnoxious to say the least. By contrast, citations to web pages which also include an archive link are not inherently obviously aimed at a dead link. An archive link might also be included because e.g. the original source has since been put behind a paywall, or because the IABot or some editor trying to be helpful has obnoxiously added a "prophylactic" archive link to a still living page. Interpreting the presence of an archive link without any explicit mention of the URL status to mean the archive link should be primary is an okay default fallback (we have to assume something in this case, and neither choice is a priori obviously correct). But having an explicit parameter is better, because it communicates clearly to human editors examining the source. This parameter is not pointless, even if its presence does not change the rendered output. Having a bot or meat bot remove url-status=dead at large scale based on personal preference of one editor is also super obnoxious. –jacobolus (t) 23:07, 4 November 2023 (UTC)Reply But having an explicit parameter is better, because it communicates clearly to human editors examining the source. Agreed and that parameter is |url-status=live; that parameter and value not present? Assume dead. —Trappist the monk (talk) 23:24, 4 November 2023 (UTC)Reply You can't say exactly the opposite of my point and then summarize that as "agreed". Come on... –jacobolus (t) 23:32, 4 November 2023 (UTC)Reply It's not "ironic and/or hypocritical" to oppose inclusion of one parameter and support keeping another for completely unrelated reasons. The "valid use case" for |language=en has been quite thoroughly refuted by multiple editors, and when the other side is asked for a better use case (and they keep saying they've seen one), they wave their hands and walk away. When it comes to |url-status=dead, a very broad, works-for-everyone use case has been presented, and the response so far as been an argument that the original purpose of the parameter was something different, and that there are technical alternatives (I even suggested one myself). These situations are not even slightly parallel. But my point is a process and propriety one, not a keep/kill that parameter one: there is an active dispute about this particular parameter+value, |url-status=dead (a dispute in which I'm now neutral), but at least two of you are still going around removing it at will despite vociferous objections. I may disagree strongly (and I do) with the objections to removing |language=en, but I have still stopped removing it until that dispute resolves, whether that happens tomorrow or in ten years.  — SMcCandlish ¢ 😼  23:41, 4 November 2023 (UTC)Reply Not refuted at all by anyone, just willfully ihnored. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 12:35, 5 November 2023 (UTC)Reply When I and at least one other editor point out that the "need", flagged as the reason to keep doing this stuff all over our articles, is better handled at the other end by the template-translation scripting, that is in fact a refutation. You can try to mount a rebuttal to that refutation, but a false claim that the original proposition was "willfully ignored" is simply untrue and does not consititute a rebuttal of any kind. It's just silly handwaving. I've asked at least 4 times now for vague and also handwavy claims that someone has seen (at some time, somewhere) some other, different translation-related use case to be substantiated with details, so that this alleged use case can be examined, and no one's done it. This is just blowing of smoke, and it's not going to fool anyone.  — SMcCandlish ¢ 😼  13:29, 5 November 2023 (UTC)Reply Everything I brought up you just handwaved away as not actually a problem, and swept it under the carpet. As I said above I'm not going into this again, but to say it's been refuted is not true. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 15:13, 5 November 2023 (UTC)Reply When someone complains of you engaging in a behavior like handwaving instead of producing evidence, you just using the playground game of "no I'm not, you are!" by using the term back at them reflexively is not a cogent argument, especially when they are not in fact doing it too. Nor is pretending that your evidence or concerns were ignored when they were actually addressed in considerable detail. The fact that the translation issue you want to solve has multiple technical solutions, and one of them is simple and clean (write a better translation script that does sensible things like assume English by default when translating from en.wikipedia) while the other is a total trainwreck (inject redundant code blather millions of times into en.Wikipedia articles) just is as it is. It doesn't make someone somehow in the wrong for pointing this out to you (even if takes multiple tries to get you to hear it). No one is doing you any form of injustice or eganging in bullshitty argumentation tactics with you, and no one is magically obligated to feel convinced by arguments you're impassioned about for some reason, when they don't actually align with the facts at hand and reasonable conclusions drawn from them.  — SMcCandlish ¢ 😼  15:39, 5 November 2023 (UTC)Reply I told you how it currently works in the real world and you completely ignored it, as you did any other argument made, at which point I have up trying to convince you as it's obvious you are unwilling to be convinced. You are the one handwaving away anything that doesn't align with your opinion and then saying I haven't produced any argument. I'm sorry if the way the real world works doesn't align with your opinion, but please stop trying to project that onto me. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 16:39, 5 November 2023 (UTC)Reply This is more bald-faced proof by repetitive re-assertion, and more childish and nonsensical "maybe I can WP:WIN by taking my opponent's words and just shuffle them around to refer to him instead of me" stuff, so I'm simply not going to respond to you any further.  — SMcCandlish ¢ 😼  16:55, 5 November 2023 (UTC)Reply FFS your entire argument against anything I've said has been that it doesn't apply. I already said I was done with this, but you started it up again. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:07, 5 November 2023 (UTC)Reply Let me try to paraphrase your argument in the various above posts, as best I understand it: Some automatic tools for helping editors translate wiki pages from French -> English let them copy/paste citation templates unchanged, and a bot comes to clean up the citations. If those citations have language=fr explicitly set on them (is this common?), it will also be set in the English page, but if they don't, then the tools/bot doesn't add it and then the resulting English wiki page won't explicitly specify that citations are in French unless a human editor spends the trivial amount of extra manual effort adding it. You once saw a discussion somewhere which you now can no longer find, in which some editors on the English wikipedia said they want to provide the same service to foreign language translators, so have started adding language=en to their citations. Instead of removing those, we should follow their lead and add language=en widely, because it doesn't take up much space and would provide a nominal service to other language wikis. Is the above fair, or do I entirely misunderstand what you are arguing for. I also have found it very vague and unconvincing overall. –jacobolus (t) 16:58, 5 November 2023 (UTC)Reply Fair enough, I don't mind if you disagree (WP:SATISFY), but that's a long way from saying that my arguments have been completely refuted. As to the translation automation, that's just how it works. If anyone wants to change the real world situation, they should go talk with the people maintaining the translation tools. It's something way beyond the purpose of this talk page.
Also again this thread is not about, and I have not advocated for, the addition of |language= to any cites. I'm against mass removing ones that are already there. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:13, 5 November 2023 (UTC)Reply I also don't think language=en should be mass removed, because it's annoying churn for a triviality (cf. WP:COSMETICBOT). But often if I manually edit citations that have language=en set on them, I remove it. Do you have a problem if language=en is removed alongside other more substantive edits? Or is your position that language=en should be left alone whenever it was set? –jacobolus (t) 17:23, 5 November 2023 (UTC)Reply I don't, as I believe it is useful for certain editors, but I have no great urge to restrict the actions of other editors. I am opposed to "it serves no purposes and should always be removed". -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:54, 5 November 2023 (UTC)Reply I would still characterize it as serving no purpose. The claimed "purpose" is trivial and almost entirely hypothetical. In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally (which is fine; it does little harm to leave this as a no-op). –jacobolus (t) 18:03, 5 November 2023 (UTC)Reply In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally Where are you seeing errors? There should be no errors related to |language= but there is a maintenance message when |language= is assigned a value that cs1|2 (MediaWiki) does not recognize (see Category:CS1 maint: unrecognized language). —Trappist the monk (talk) 18:12, 5 November 2023 (UTC)Reply Yes, there are no errors. That's the point. It would be bad for language=en to throw an error, even though it doesn't do anything. Making this a no-op that people are free to remove at leisure is an appropriate behavior here. –jacobolus (t) 19:10, 5 November 2023 (UTC)Reply If you feel it's trivial fair enough, but I'm sorry I really struggle to understand how the issue is hypothetical when it is how the translation of cites currently works. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 18:13, 5 November 2023 (UTC)Reply It's hypothetical insofar as something 99% of current citations on on this wiki to English language sources do not include this parameter, so anyone translating an arbitrary English wiki article to Russian or whatever is going to need to manually check every one anyway, so that this is not saving them any appreciable amount of effort. If we care strongly about this particular group of users, it would be much more useful to fix the English -> X language tool to automatically fill missing language params with the implicit "en" instead of trying to expand the number of references here with language=en explicitly specified. If that's the only purpose you can come up with for specifying 'language=en', then I say it should be fair game to eliminate them here. But bots and meat bots: please only make this kind of trivial change in a trickle alongside more substantive changes, instead of spamming everyone's watchlists with cosmetic changes. –jacobolus (t) 19:18, 5 November 2023 (UTC)Reply If you don't believe the use case is noteworthy I won't argue. But I believe we should be encouraging not discouraging the inclusion until someone bothers to change the translation tools. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 19:49, 5 November 2023 (UTC)Reply I concur with jocobolus, word-for-word. And as I predicted, the end goal of the other side on this matter is "encouraging ... the inclusion" of |language=en, spreading it to more and more citations, just as I said it was, but I was accused of straw-manning. Are we done now, or is there additional evidence and reasoning to present? This so far has been a complete rehash of the previous cycle.  — SMcCandlish ¢ 😼  19:55, 5 November 2023 (UTC)Reply That's what I believe, but as I've said repeatedly I don't support any official change to policy or documentation. Also your comments, particularly "of the other side", just shows the battleground mentality you've shown in this discussion. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 20:07, 5 November 2023 (UTC)Reply Every dispute has two sides (if not more). Using plain English is not a transgression. Casting "parting shot" aspersions at people's "mentality" and accusing them of battlelgrounding is not a good look. When I make a proposal (which happens all the time), if I find that is isn't going anywhere despite my efforts to outline my rationale (also happens all the time), I just walk away. There is no need to throw the rude gesture at those who didn't agree with you as if they're bad people for not taking your side (yes side – it's the completely normal term for this) in the discussion. All this personality stuff aside: What we have here is a conflict between a "Why can't we just do something nice for these folks doing hard work" sentiment running into facts that the proposed thing to do is not practical, there is a better solution immediately obvious, and doing it the proposed way will turn into a bigger and bigger mess, harder and harder to clean up later, the longer it operates. Not every well-intentioned idea is one we should go with.  — SMcCandlish ¢ 😼  20:57, 5 November 2023 (UTC)Reply I'm not going to read that I don't think it's going to get any better. I'm at a lose as to why a discussion about 12 characters in a cite has become so hostile. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 21:50, 5 November 2023 (UTC)Reply I don't think anyone's angry with you, doesn't like you, or is otherwise exhibiting hostility. People just disagree about things, including the weight of evidence and the solidity of reasoning given as rationales in discussions. No one enjoys being disagreed with (probably?), but disagreement happens, and it doesn't mean you're under attack or that people have a personal bone to pick with you. Hope that helps.  — SMcCandlish ¢ 😼  14:28, 6 November 2023 (UTC)Reply I'm sorry but I disagree you level of personalisation has been striking. I don't need any help I'm just confused by that level heat over something so unimportant. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 15:27, 6 November 2023 (UTC)Reply You keep saying things like "something so unimportant" and "only 12 characters", but two of us have repeatedly pointed out to you that 12 (often 15) characters repeated millions of times is not trivial, but you dodge this and keep re-asserting that it's just 12 characts and unimportant. You must understand that this is frustrating and comes across as refusal to engage meaningfully in the discussion.  — SMcCandlish ¢ 😼  17:05, 7 November 2023 (UTC)Reply Unless you believe I am lying I do not have to prove anything. You can accept my points or not, but everytime I have made a point you have attacked the comment not it's substance. So no, I have no more desire to continue this discussion with you.
And yes it is a minor thing. A million times 12 characters is a drop in the ocean of billions of markup characters. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 18:33, 7 November 2023 (UTC)Reply An assurance approximately equivalent in utility to |<citation verifies previous sentence>=y. My observance is that the real focus of all this arguing should really be pointed to ensuring that each and every live link that argues it's live (with or without an archive link) to be checked for liveness. I have spent quite some time in the general hitting ostensibly live citations that aren't (for which I have done the good duty of finding them appropriate archive URLs). Izno (talk) 21:17, 4 November 2023 (UTC)Reply Ah, but |<citation verifies previous sentence>=y gives us license to remove driveby {{cn}} tags slapped down in haste by editors with no time to check the source cited one sentence later. Folly Mox (talk) 23:29, 4 November 2023 (UTC)Reply

ISBN formatting

Wikipedia:Village pump (policy) § RfC: Standardizing ISBN formatting (and an end to editwarring about it) is a discussion which watchers of this page may be interested in. Izno (talk) 02:12, 1 November 2023 (UTC)Reply

DOI and ISSN in a citation

After generating a citation for an article accessed via JSTOR in a journal which has its own WP article a Digital Object Identifier and an ISSN appeared in its preview. I'm wondering if either is necessary. Mcljlm (talk) 02:28, 1 November 2023 (UTC)Reply

Probably, since DOIs are identifiers of particular articles, not the entire periodical publication, and our citation content can be WP:REUSEd in contexts that don't guarantee a working (or any) link from the periodical name. E.g., someone might port our citation to the French Wikipedia (to continue with its excessive use as an example above :) and it may lack such an article on that journal.  — SMcCandlish ¢ 😼  06:50, 1 November 2023 (UTC)Reply I would always include a doi when we have it. Some publications require dois in their references, when available, so this is useful information for readers looking to re-use our references. The doi (except in the rare instances when it is broken) leads to the canonical copy of the paper. It is supposed to continue working even after a publication changes its url scheme, and often does, so it is more robust than other kinds of links including urls. And some dois lead to other copies than the jstor copy, which could be useful to readers who have access to that other copy and not jstor. For jstor articles that have them, I tend to include both doi and jstor identifiers, but if I were to keep only one it would be the doi. The issn, on the other hand, is almost entirely useless cruft, as far as I can tell. It identifies only the journal, not the paper, and the journal is usually better identified in other ways. And you should also not include a url parameter when it leads to the same place as the doi or jstor, because it is redundant and more fragile. —David Eppstein (talk) 07:26, 1 November 2023 (UTC)Reply I started adding issns because other language Wikipedias require them, and the article translators asked for them. I have had trouble with dois; they are sometimes broken. The jstor is more reliable, so for jstor articles, I include both, but if I have to include one only the jstor is best. Hawkeye7 (discuss) 09:57, 1 November 2023 (UTC)Reply WP:ISSN reads

On Wikipedia, an ISSN is an optional part of a citation to a particular article (adding it never hurts, but it is not strictly necessary when a direct URL or DOI is provided to the full text of the article).
An ISSN is particularly helpful in the following circumstances (especially when the ISSN is linked, using template or parameter detailed below):

I rarely include an ISSN in citations; my rule of thumb is only if it would truly be more difficult for a reader to locate a source without it will then I include it. So never for well-known or commonly-held journals and never in citations with any other identifier. But there have been times where I’ve seen the value of including it; factors include if the journal title is not in the Latin script, if the journal title is shared by other periodicals, if the journal title has been changed frequently, or if it’s so rarely held by libraries that the direct link to Worldcat via the parameter would be a convenience. I think you should always include a DOI if it works. Umimmak (talk) 10:13, 1 November 2023 (UTC)Reply My rule of thumb is to use all of the identifies that the template supports, when I know them. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:10, 1 November 2023 (UTC)Reply Same here. I can't predict what resources the reader has access to or what they are most accustomed to doing or able to make the most use of. Umimak's long series of ifs are a bunch of tests I'm not willing to do when adding a bunch of citations to articles; there are much better ways to spend my time.  — SMcCandlish ¢ 😼  18:14, 1 November 2023 (UTC)Reply I mean for the most part I agree with David Eppstein that The issn, on the other hand, is almost entirely useless cruft, as far as I can tell. No style guide to my knowledge suggests routinely adding ISSNs for citations, and one saves even more time by not needing to add or look-up |issn= parameters. I was just clarifying some of the exceptional examples of citations where its usefulness outweighs its status as status as possible clutter. Umimmak (talk) 20:25, 1 November 2023 (UTC)Reply If the DOI has an accessible copy of the paper, I'd recommend just including the DOI. If the DOI has the paper behind a paywall, then an alternative repository identifier (e.g. JSTOR) or a preprint (e.g. at Arxiv or the author's webpage) can be helpful. ISSN is very rarely of any value, unless e.g. the journal has no online presence at all and uses the same name as another journal. –jacobolus (t) 23:10, 1 November 2023 (UTC)Reply

Dates - "Summer, 1993"

According to JSTOR, the journal American Music uses dates in the format "Season, YYYY", so for example, "Summer, 1993" - (and more generally, Spring, Summer, Fall, Winter - ) How do we represent this using this template? --Tagishsimon (talk) 12:11, 1 November 2023 (UTC)Reply

|date=Summer 1993 —Trappist the monk (talk) 12:13, 1 November 2023 (UTC)Reply Oh. My mistake. I thought that was causing an error. Maybe not. It is preventing {{sfn}} from working, but maybe there's a cure for that. --Tagishsimon (talk) 13:45, 1 November 2023 (UTC)Reply @Tagishsimon: In Draft:Frederick Woodward Blanchard, try changing {{sfn|Parsons|1993|p=###}} to {{sfn|Smith|1993|p=###}}. GoingBatty (talk) 14:14, 1 November 2023 (UTC)Reply @GoingBatty: Thank you, yes. TtM has just pointed that out to me, too. Clearly having a brain fog morning; thank you for your patience. --Tagishsimon (talk) 14:18, 1 November 2023 (UTC)Reply If there's a volume number, I typically include the volume number and specify the date as year=1993. It's usually not that helpful to readers to see So-and-so (Summer 1993), "Paper", Journal, 5 (2): 1–10 vs. So-and-so (1993), "Paper", Journal, 5 (2): 1–10. If it's a magazine or something and there's no volume number, then specify the full date given. –jacobolus (t) 23:15, 1 November 2023 (UTC)Reply And I typically list the date on the issue as given. Neither approach is wrong, per se, but it looks best to be consistent. If other citations list the month in the date, then ones with a season should too. Imzadi 1979  01:16, 2 November 2023 (UTC)Reply Nobody else seems to have pointed this out yet, but the comma should be omitted: "Summer 1993" (as Trappist suggests), not "Summer, 1993" (as the original post gave). Also we would replace "Autumn" by "Fall", and similarly replace non-Engish-language seasons by their English equivalents. Fortunately, I haven't seen seasonal dates that don't translate into this form, unless you count the rare "Michaelmas" dates. —David Eppstein (talk) 01:31, 2 November 2023 (UTC)Reply Also we would replace "Autumn" by "Fall" Why? -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 01:49, 2 November 2023 (UTC)Reply Indeed; we should not. Mathglot (talk) 02:26, 2 November 2023 (UTC)Reply Agreed; the purpose of including these things at all is helping find and identify the source cited, so changing its issue designator from "Autumn" to "Fall" will thwart that goal.  — SMcCandlish ¢ 😼  06:55, 2 November 2023 (UTC)Reply So would changing "Printemps" to "Spring", or "band" to "volume", in exactly the same way. Are you arguing that we should not do that, either? —David Eppstein (talk) 07:17, 2 November 2023 (UTC)Reply Printemps is debatable (I think I would do |date=Spring 2023 if treating it as a date, but |issue=Printemps 2023 if treating it as an issue name because the publication used issue names instead of numbers, depending on the circumstances, e.g. if we also have something like |date=13 April 2023 to use more specifically for the date). But |volume= is a parameter not a search string like Printemps or Autumn might be in some cases, and databases of journal papers are already making that conversion themselves (JSTOR, etc., are not using Band in place of Vol. or Volume when the journal is in German . I've never seen any major journal indexing site do that). Regardless, going around robotically changing "Autumn" to "Fall" is a MOS:STYLEVAR fail, since there's nothing wrong with either word, and is probably a MOS:ENGVAR fail, since "Autumn" is much more common in British and several other forms of non-American English.  — SMcCandlish ¢ 😼  09:18, 2 November 2023 (UTC)Reply We don't even use issue names. —David Eppstein (talk) 15:19, 2 November 2023 (UTC)Reply Maybe you don't. I use whatever will help find the source and can be worked into a citation.  — SMcCandlish ¢ 😼  15:25, 2 November 2023 (UTC)Reply

Cite journal: "no journal name supplied" seems to be a common error, surely it can be identified

My heart sinks when I see "Script warning: One or more {{cite journal}} templates have errors; messages may be hidden (help)." because so often the message is hidden.

In my experience, the most common cause of this error is that the journal name has not been supplied (or doesn't do so using journal=). If there are many journal citations, it can take an unreasonable time to find the one in error and correct it. Surely the very first thing the syntax error checking algorithm should do when checking a {{cite journal}} call is that there is actually a named journal? 𝕁𝕄𝔽 (talk) 13:10, 2 November 2023 (UTC)Reply

@Trappist the monk: Maybe it's time to unhide this particular error. GoingBatty (talk) 14:05, 2 November 2023 (UTC)Reply (edit conflict) The Cite journal requires |journal= and Cite magazine requires |magazine= error messages were hidden because of this WP:AN discussion. Recently, we had another discussion. At the last module suite update, we created a {{cite document}} template. Creation of that template should be the last impediment to unhiding the missing periodical error message for {{cite journal}} and {{cite magazine}}. Are there any who object to unhiding these error messages? —Trappist the monk (talk) 14:18, 2 November 2023 (UTC)Reply I don't know of anyone who objected to those being errors. The objections were to flagging {{cite web}} without |website= and {{cite news}} without |newspaper=. Kanguole 14:41, 2 November 2023 (UTC)Reply They go hand in hand. Dis-use of the appropriate parameters in those templates is the same problem and the reason there were warnings for that as well (same exact spot in the code, etc etc). Cite journal just had the separate additional issue that it was being used as {{cite document}} which had no other alternative. Izno (talk) 20:51, 2 November 2023 (UTC)Reply They were all errors for a few weeks, but they've been treated differently for the last 4 years. I see that {{cite document}} is an additional issue, though. Kanguole 22:23, 2 November 2023 (UTC)Reply {{cite document}} no longer redirects to {{cite journal}} as it once did. What is the additional issue that you are complaining about? —Trappist the monk (talk) 23:21, 2 November 2023 (UTC)Reply In that case, none. Kanguole 23:38, 2 November 2023 (UTC)Reply Yes, I guessed that the root of the problem was the strange decision to redirect {{cite document}} to {{cite journal}}. To take another perspective, I've seen citations dressed up as journal articles but it appears that the papers concerned didn't make the cut. So IMO, we absolutely should expose this error. --𝕁𝕄𝔽 (talk) 15:24, 2 November 2023 (UTC)Reply FWIW, in my experience many of the affected citations are not journal articles and should use a different template. Maybe I'm just unlucky, but I have found fewer that are just missing the title of the journal or magazine. I support exposing the error messages for {{cite journal}}. – Jonesey95 (talk) 17:30, 2 November 2023 (UTC)Reply But not for {{cite magazine}}? Why not? —Trappist the monk (talk) 17:38, 2 November 2023 (UTC)Reply I didn't state a preference for {{cite magazine}}. It's probably fine to show error messages for it, but I don't see it often, so I don't have a sense of the ways in which editors are making errors with it. That template is causing at most 2,850 of the 48,000 pages in the error category, if my search-fu is working, so it's on the margin. – Jonesey95 (talk) 00:16, 3 November 2023 (UTC)Reply Yeah, you didn't, but since I asked about both, I read your positive support for journals as negative support for magazines. What is the margin? My experience with these {{cite magazine}} errors is that editors abuse the template in much the same way that they abuse {{cite journal}}. —Trappist the monk (talk) 00:57, 3 November 2023 (UTC)Reply As I understand it, that's also the error category that holds {{cite book}}s where |work= has been specified. Not sure how many of the member articles stem from that combination. Folly Mox (talk) 17:54, 3 November 2023 (UTC)Reply Category:CS1 errors: periodical ignored. —Trappist the monk (talk) 17:57, 3 November 2023 (UTC)Reply Thank you for the correction 🙏🏽 Folly Mox (talk) 20:05, 3 November 2023 (UTC)Reply

I conclude that the consensus is strongly in favour of unhiding Cite journal requires |journal= and Cite magazine requires |magazine= error messages. My reading of the WP:AN discussion is that the flame-out was over a sudden imposition of a demand for {{cite news}} to have a work= (which could be argued but that's another discussion) and {{cite web}} to have a website= (which has always seemed redundant to me). There were also many instances of {{cite document}} redirecting to cite journal and thus throwing up false positives: that problem has been fixed with the new template for documents.
@Trappist the monk:, make it so! (I've always wanted a good excuse to say that ). --𝕁𝕄𝔽 (talk) 17:15, 3 November 2023 (UTC)Reply

I've been watching but not commented and am strongly in favour of this if any more support was needed. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 17:17, 3 November 2023 (UTC)Reply Ditto.  — SMcCandlish ¢ 😼  08:07, 4 November 2023 (UTC)Reply Unhidden in the sandbox. —Trappist the monk (talk) 20:08, 14 November 2023 (UTC)Reply Because the missing-periodical error message is the last of the hidden error messages, when we update the module suite the preview message that says: One or more {{Cite ...}} templates have errors; messages may be hidden (help). will no-longer be true. The intent of that message is to link to instructions that will allow editors to show messages that are hidden. Should we rewrite the message to something like: One or more {{Cite ...}} templates have errors; (help). or perhaps something like this: One or more {{Cite ...}} templates have errors; (control error message display). or is there some better message that we can present? —Trappist the monk (talk) 20:20, 14 November 2023 (UTC)Reply How about something like: One or more {{Cite ...}} templates have errors; (general help) - see the help link next to each error for assistance specific to that error GoingBatty (talk) 22:31, 14 November 2023 (UTC)Reply Perhaps not? The link in the message does not link to 'general help' but rather, links to specific help about showing or hiding cs1|2 messaging. —Trappist the monk (talk) 17:34, 15 November 2023 (UTC)Reply OK. Since the link in the message goes to instructions that will allow editors to show messages that are hidden, and this change would allow all errors to be shown, then I think the link is no longer needed for errors. (It's still needed for maintenance messages that are hidden.) Therefore, I propose: One or more {{Cite ...}} templates have errors. Click the help link next to each error for assistance for that type of error. Thanks! GoingBatty (talk) 18:55, 15 November 2023 (UTC)Reply I guess I don't think that omitting the link is a good idea. Help:CS1 errors § Controlling error message display includes instruction for editors who wish to completely suppress cs1|2 error messaging so we should retain the link in the summary message. I want to update the module suite so, for the nonce, I'll leave the message as it is. —Trappist the monk (talk) 18:24, 18 November 2023 (UTC)Reply

Multiple ISBNs

Currently the {{ISBN}} template supports multiple numbers, e.g., {{ISBN|1449370829|978-1449370824}} displays both ISBNs, ISBN 1449370829, 978-1449370824, for "Java in a Nutshell: A Desktop Quick Reference", 6th edition. Should |ISBN= allow entering both rather than just the ISBN-13? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:03, 2 November 2023 (UTC)Reply

That is the same ISBN in its 10- and 13-digit forms (the difference is the 978 prefix and the check digit). There is no need to have both. The recommendation is to use the 13-digit form when you have both. —Trappist the monk (talk) 16:34, 2 November 2023 (UTC)Reply And I've seen people try to add several/every ISBN for the general work, which is wrong per WP:SAYWHEREYOUGOTIT; we should only support adding a single ISBN, to identify the source that the fact-claimant editing the article actually used, which is what the verification-interested other editor or end reader should be seeking to check our claims against our sources. As I said somewhere else in here, the possibility that the factual claim could be verified with some other source that was not used (even a different edition of the same work) is completely irrelelvant.  — SMcCandlish ¢ 😼  09:15, 3 November 2023 (UTC)Reply Please don't stick multiple ISBNs into citations. One is already more than enough clutter. –jacobolus (t) 15:21, 5 November 2023 (UTC)Reply

what to do about |df=?

In another discussion elsewhere (long and meandering) the question was asked: why do we have |df= when cs1|2 formats publication, archive, and access dates according whatever local {{use xxx dates}} is present in the article? It was pointed out that use of |df= is often merely redundant to {{use xxx dates}} or in conflict with that template.

My answer was to turn the question around and ask: Because no one has bothered to suggest that we no longer need it? So, the question on the table is: do we need to keep |df=?

Here are a couple of cirrus searches for articles that use |df= in cs1|2 templates:

These searches suggest that there are more than 76,000 articles with at least one use of |df=. That is too many to just suddenly deprecate. Sure a bot could be written to remove |df= but such a bot runs the risk of being declared WP:COSMETICBOT so removal of these parameters will likely need to be done some other way.

And then there are the articles that have neither of the {{use xxx dates}} templates:

What to do about those?

So: what to do about |df=? Is there ever a legitimate case for using a |df=mdy formatted publication date in an article that has {{use dmy dates}}?

Certainly we can mark the parameter as 'discouraged'. We can tweak Module:Citation/CS1 to maintenance category message when|df= is used in an article that has a {{use xxx template}}. With the category, gnomes can pick away at removing |df= until the count is sufficiently reduced to avoid torches and pitchforks. What to do with |df= is used in articles that don't have a {{use xxx dates}} template?

Trappist the monk (talk) 16:58, 2 November 2023 (UTC)Reply

This is a parameter we should retain for the next few years. I do not trust that the hack we currently employ to get the date format from elsewhere in the article will work indefinitely into the future, and certainly not in the same way that it does today. As part of the forthcoming Parsoid-in-read-mode, the WMF has some party or set of parties that are interested in parallel parsing of pages (which would speed up parsing). This template may break as a result of that discussion, since it relies on content elsewhere in the article (pre-parse, but still). A few extensions (external to the WMF fleet) are already on the chopping block as not fitting with this paradigm. I'm choosing to elide the relevant Phab task for now because it's not an issue yet here and when it shows up we can point and say "hey, this needs another way to be supported" (likely by some use of mw:Multi-content revisions). Izno (talk) 20:56, 2 November 2023 (UTC)Reply I'm in agreement with Trappist's "mark the paramenter as 'discouraged'" idea. "nomes can pick away" – so can bots, as long as they do something else more important in the same edit; that's the way around COSMETICBOT. And CitationBot, etc., are already doing a lot of this sort of minor tweaking the course of making more needful corrections . As for Izno's concern, maybe it's reasonable to wait a while and see how that pans out.  — SMcCandlish ¢ 😼  09:23, 3 November 2023 (UTC)Reply Citation bot also goes around changing the year in citations to the wrong versions and introducing referencing errors. That's really an aside, but I wanted to right it somewhere that isn't my reverts of its edits. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 13:25, 3 November 2023 (UTC)Reply If you have issues with Citation bot, this is not the venue. We cannot right whatever wrong is done by the bot. The correct venue is User talk:Citation bot. —Trappist the monk (talk) 13:55, 3 November 2023 (UTC)Reply

supplement element

What ever happened to the supplement element for cite newspaper? Govvy (talk) Govvy (talk) 15:49, 3 November 2023 (UTC)Reply

cs1|2 has never supported |supplement=. Are you thinking of that or something else? I have wondered, off and on, whether cs1|2 ought to support |part= and |supplement= because the COinS metadata format supports &rft.part=. Opinions? —Trappist the monk (talk) 15:57, 3 November 2023 (UTC)Reply Newspapers and old magazines have supplements, The Sunday Times which I just used as a cite has multiple supplements. It should be supported. Govvy (talk) 16:10, 3 November 2023 (UTC)Reply For this? {{cite newspaper |work=The Sunday Times |title=A dummy, a surge and then an unstoppable bullet of a shit (off either foot) |p=13 |supplement=Sport |date=22 October 2023}} "A dummy, a surge and then an unstoppable bullet of a shit (off either foot)". The Sunday Times. 22 October 2023. p. 13. {{cite news}}: Unknown parameter |supplement= ignored (help) Use |department=. {{cite news |newspaper=The Sunday Times |title=A dummy, a surge and then an unstoppable bullet of a shit (off either foot) |p=13 |department=Sport |date=22 October 2023}} "A dummy, a surge and then an unstoppable bullet of a shit (off either foot)". Sport. The Sunday Times. 22 October 2023. p. 13. The documentation for that parameter is here. Is the title really "unstoppable bullet of a shit"? —Trappist the monk (talk) 16:28, 3 November 2023 (UTC)Reply Would this be |department=? Kanguole 16:21, 3 November 2023 (UTC)Reply lol, I is next to O on the keyboard! But I don't get why you refer to a supplement part of a newspaper as a department. Historically, that wouldn't make sense if you wanted to cite an old newspaper. They say the medium is dead, but we still have it. It seems sensible to me to add |supplement= as an option. Govvy (talk) 16:51, 3 November 2023 (UTC)Reply At least as an alias of |department=. The fact that one publication puts some department in their own pull-out supplement is kind of irrelevant, except that not everyone trying to build a citation is going to think "|department= is what I'm looking for" when they don't find a |supplement=. Seems like an easy and helpful tweak to make.  — SMcCandlish ¢ 😼  08:12, 4 November 2023 (UTC)Reply PS: I find it reader-helpful to do things like |department="Sport" department or |department="Sport" supplement instead of just |department=Sport. Same with |series="History's Greatest Battles" series instead of |series=History's Greatest Battles, since the bare string "Sport" or "History's Greatest Battles" in the citation has a rather opaque and ambiguous meaning except to people who have really, really studied out citation templates and the order in which they put things, which is probably no one who isn't already on this page right now. Heh. (I make an exception when the name of the thing already indicates what it is, e.g. by including the word "Series" or "Department" or "Supplement"). I would rather like to see our documentation advocate this approach.  — SMcCandlish ¢ 😼  08:24, 4 November 2023 (UTC)Reply @Govvy: perhaps you were remembering {{comic strip reference}}, now merged into cite comic. Also, an alias makes sense for cite news. Rjjiii (ii) (talk) 23:17, 4 November 2023 (UTC)Reply

Enabling |work= as a |title= alias in Template:Cite_book

Is there some good reason that |work= if used in {{Cite book}} doesn't just alias to that template's version of |title=? It would resolve a lot of errors and make it easer to convert citations that are using the wrong template for the source type. Even if we wanted a bot to later substitute in |title=, it would be helpful. There would also be a few cases where the same template is trying to call |title= and |work= at the same time, with different (e.g. something in |work= that really belongs in |series=) or the redundantly same values, but this will surely be a smaller class of errors to resolve than every {{Cite book}} containing |work=. Just make that stop being an error-by-definition as it presently is.  — SMcCandlish ¢ 😼  08:17, 4 November 2023 (UTC)Reply

I'm not sure it's always possible to automatically fix {{Cite book}} when it uses |work= and |title=. I've been correcting a few dozens of those recently where |title= was meant to be |chapter= and |work= was meant to be |title=. This then needed a further correction of |url= to |chapter-url=. Those repairs seem quite mechanical, but I suspect they would be difficult to work into a rule. -- Michael Bednarek (talk) 10:48, 4 November 2023 (UTC)Reply Unfortunately work is misused for all sorts of things, websites, series titles, editions, publishers, and even authors. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 10:50, 4 November 2023 (UTC)Reply Yes, I know it gets misused and that there will be cases to fix manually, especially in the odd situation that both parameters are present. Such complications are always the case with everthing here. The fact remains that the vast majority of attempts to use |work= in {{cite book}} are in place of |title=, and having them be equated would make fixing many misapplications of other templates to books easier. And it's just weird and unintitive that |work= as an alias is functional as a parameter to specify the name of the "major work" (the italicized thing) in every citation template to which it could seem to apply, except for this one.  — SMcCandlish ¢ 😼  11:57, 4 November 2023 (UTC)Reply Note the comment above was changed after it had been replied to. I've had quite a different experience to you, I would say only 60% of the ones I've fixed have been a simple work -> title switch. -- LCU ActivelyDisinterestedtransmissions∆ °co-ords° 13:04, 4 November 2023 (UTC)Reply This would lose a lot of information and break a lot of citations. There are currently still thousands of {{cite book}}s which use |title= and |work=, which are not split out specifically from Category:CS1 errors: periodical ignored (32,766).0% of the ones I've fixed have been simply work→title. They've been a mixture like title→chapter, work→title; work→series; work→via; title→volume, work→title; and probably others I've forgotten. There have also been a few I've been unable to fix, because they cite a chapter of a named work collected in an anthology, where the pagination and publication information differ between the anthology and the original printing, and I'm not sure what other set of parameters would properly capture the information.I view the disabling of the |work= parameter in {{cite book}} as underdiscussed and disruptive, since it hid all of the information editors had added instead of just emitting an error message about it, and until we've cleared all the cases of this, we're continuing to suppress valid citation information in ways that are not clearly understood, as evidenced by our differing experiences cleaning up after this parameter change. Folly Mox (talk) 13:48, 4 November 2023 (UTC)Reply I think the actual solution here is to update {{cite book}} to display |work= as well as emitting the error message. Downgrade |work= from "unsupported" to "deprecated" until we can alter all of these templates so that when support for the parameter is disabled again in the future, we'll have the book citations all fixed up and ready for it, instead of just hiding this parameter, which is almost always a pretty important one. Folly Mox (talk) 13:53, 4 November 2023 (UTC)Reply With the information missing, there is a strong motivation to correct the citation. And, besides that, it's in general keeping with other errors: we show only an error or correct information, not both. (Generally; I think there's one or two where that doesn't hold.) Izno (talk) 21:05, 4 November 2023 (UTC)Reply I have pretty strong feelings about this, partly because a lot of the {{cite book}}s with |work= that I've fixed have been citations I added over the years, and if I had known about the discussion to remove support for this parameter, or understood that it wouldn't be displayed at all unlike parameters that are merely marked "deprecated", I would have argued the above at one or both of the prior conversations.So with that caveat, I don't think error and correct information are an apposite pair in the second sentence just above. What this error feels like to me is perfectly valid citation information that has been decided ex cathedra et post facto to be suppressed due to a technicality no one was adequately warned about or given opportunity to prepare for.(I could be entirely wrong about this: there may well have been a maintenance message for years, invisible to mobile editors, warning that |work= support for {{cite book}} would be withdrawn in 2023, or there may have been an update to the documentation mentioning that, which I missed because I don't watchlist the template documentation pages, and don't closely reread documentation for updates once I feel I understand it.)The information being missing does provide a strong incentive to reparameterise the affected calls to {{cite book}}, but the total category membership of Category:CS1 errors: periodical ignored (32,766) provides a stronger disincentive to embark on any sort of thorough cleanup. My take is that it's unfixable in its current state, but I'd welcome a narrower Category:CS1 errors: cite book ignores work to see if that's actually the case. Folly Mox (talk) 22:41, 4 November 2023 (UTC)Reply This search finds ~19,300 articles where {{cite book}} uses |work=. Template:Cite book/TemplateData lists |work= as a valid parameter; it should not. So far as I can tell, Template:Cite book/doc (the canonical documentation) has never listed |work= as a valid {{cite book}} parameter. —Trappist the monk (talk) 23:04, 4 November 2023 (UTC)Reply Ok, so the documentation was off in one instance, but it's more probable that editors didn't read closely enough or misunderstood how the individual wrappers differ. Maybe some of the 19,000 mistakes were initially citation templates that supported the parameter, and later converted to {{cite book}}.Whatever the cause might be, that's still 19,000 citations that are hiding whatever value is being held in |work=. Does it really serve the reader to continue not displaying that information while we clean out the category? It looks like it will take years. Folly Mox (talk) 13:58, 5 November 2023 (UTC)Reply I've just spent the past 4.5 hours working on this category, cleaning 17 articles (I did get sidetracked by other citation repair, including no-target errors, which can be time-consuming).I've noticed that hiding the |work= parameter for {{cite book}} also suppresses |publisher= and |edition= (at least at Special:Permalink/1183496933, under #Sources). Is this behaviour intended? Folly Mox (talk) 18:37, 5 November 2023 (UTC)Reply Thanks for pointing that out. Fixed in the sandbox: Cite book comparison
Wikitext {{cite book|edition=9th|first=Joel|isbn=978-0-8230-8554-5|last=Whitburn|publisher=Clarkson Potter/Ten Speed|title=The Billboard Book of Top 40 Hits|url=|work=Billboard Books|year=2010}}
Live Whitburn, Joel (2010). The Billboard Book of Top 40 Hits (9th ed.). Clarkson Potter/Ten Speed. ISBN 978-0-8230-8554-5. {{cite book}}: |work= ignored (help)
Sandbox Whitburn, Joel (2010). The Billboard Book of Top 40 Hits (9th ed.). Clarkson Potter/Ten Speed. ISBN 978-0-8230-8554-5. {{cite book}}: |work= ignored (help)
Trappist the monk (talk) 19:26, 5 November 2023 (UTC)Reply @Trappist the monk: What's the extra "o" at the end of the Sandbox line? Is that a typo in the actual sandbox template? Thanks! GoingBatty (talk) 16:24, 6 November 2023 (UTC)Reply Help talk:Citation Style 1/Archive 90 § Sorting drafts to back of categoriesTrappist the monk (talk) 16:31, 6 November 2023 (UTC)Reply I have no issue with aliasing these also, but only after the category above is at 0 + fluctuations count of articles. The issue in this regard, if there is one, is the semantics of |work= in {{citation}}. Previously that has been exclusively meaning a periodical. Izno (talk) 21:00, 4 November 2023 (UTC)Reply

s2cid limit update

s2cid limit needs updated, seen here, here and here. Several pages in that category. Numbers checked, they are correct. Thanks. Isaidnoway (talk) 🍁 01:48, 6 November 2023 (UTC)Reply

Do we need |access-date ?

I sometimes see something like this, where |access-date= is removed from various {{cite web}}, {{cite news}}, etc., that do have URLs. Is this desirable for some reason? Is is absolutely undesirable? Is it a "no one really cares"? matter? We seem to have this parameter because something like it is present in most citation styles in the "real world", and on WP gives some indication when was the last time someone actually looked at the source to see if it's still valid for what the article currently is claiming and seeming to rely on that source for.  — SMcCandlish ¢ 😼  16:36, 6 November 2023 (UTC)Reply

Looking at some examples from Chicago Manual of Style, the access date isn't given if the source is well known and the publication date is provided within the publication. It would be appropriate if the web site did not provide a publication date. It's probably useful if the web site is not all that permanent, and there aren't numerous well-known ways to find the content if the website goes down. Jc3s5h (talk) 16:52, 6 November 2023 (UTC)Reply I'll remove |access-date= from deadlinked web sources where an archive exists and the claim is not tagged in any way (which can necessitate finding a different archive). I also remove it from print sources, since it's always unnecessary in those cases.I only take these actions as part of constructive citation repair, never as the only action in a diff, and never en masse.I would love it if |access-date= would gracefully fail for print sources, and just not display anything for {{cite book}} and {{cite journal}}. All other use cases are too borderline or on balance beneficial, and removing support for the parameter is a def no go due to citation scripts always providing it. Folly Mox (talk) 17:13, 6 November 2023 (UTC)Reply gracefully fail for print sources What does that mean? —Trappist the monk (talk) 17:17, 6 November 2023 (UTC)Reply Apologies for the poor wording: gracefully fail for print sources by which I mean just not display anything for {{cite book}} and {{cite journal}}. Folly Mox (talk) 19:01, 6 November 2023 (UTC)Reply I find access-date to be pointless noise when there was also a publication date involved (ideally listing the date when the source was most recently updated). In my opinion access-date is only really useful for pages where the source changes; for example I'd use something like that if citing Wikipedia (when writing some external document), optionally linking to a specific version of the page. –jacobolus (t) 18:29, 6 November 2023 (UTC)Reply I think I was being too cagey in my original post. (Being misunderstood this way is why I'm often much more direct, though some people find it abrasive. I can't seem to have it both ways.) To be more blunt, I do not believe it is constructive or consensus-supported to go around removing |access-date= from citations that have URLs, since it does indicate to the editor when the material was last examined (at least by someone who remembered to update the parameter).If we come to the conclusion that for readers the parameter no longer serves a purpose when both |archive-url= is present and |url-status=dead (whether that parameter is literally present or not – don't want to re-open that worm-can), or when there is no URL at all, then the thing to do would be to have the template suppress display of the access date in the reader's output. But we need not lose the editor-facing functionality it provides. It's very significant sometimes, e.g. when a complex paragraph is entirely cited to one source, and that source has something like |access-date=30 June 2009 but the article has been substantively edited many, many times in the interim, this is a good sign that unsourced material has probably been injected into that paragraph and that it either needs to be removed, or a source found for it, and the already-present citation needs to be re-applied to the material that was actually taken from it, often as a split <ref name="Foo 2009">...</ref> and some <ref name="Foo 2009" /> instances for particular sentences or claims within sentences, depending on how complex the material got over time. As a side point, for this same reason I would like the see |access-date= also supported again as a parameter in every citation type, and stop being reported as an error in those without URLs. It should simply be display-suppressed when in such citations. Unlike some of the other parameterization discussed above that I think is of dubious use and ends up just being redundant cruft, this actually serves an encyclopedia-building purpose for all editors. PS: It seems particularly weird to me to have this parameter throw an error and get removed by people when a literal |url= parameter is replaced by a shortcut parameter like |jstor= that generates the same URL for the reader. I dont' see any point to that at all.  — SMcCandlish ¢ 😼  18:32, 6 November 2023 (UTC)Reply Whether it should be an error I don't care about, but documents on JSTOR definitely don't need to display an access-date to readers or include one in the source markup. These sources are static and in my experience always have a well-defined publication date. –jacobolus (t) 18:35, 6 November 2023 (UTC)Reply You appear not to have absorbed much of what I said above. Whether a journal article on JSTOR or anywhere else has a publication date (as do most web pages we cite) is completely irrelevant. That's what the |date= parameter is for. |access-date= tells us when an editor of our site examined that source, and this is meaningful not only for detecting linkrot, as Hawkeye7 discusses below, for also for alerting us to aging citation verification that needs to be revisited.  — SMcCandlish ¢ 😼  20:11, 6 November 2023 (UTC)Reply Adding access-date to a journal article on JSTOR serves no valuable purpose. These are resources which as a rule don't change, and for which I've never experienced 'link rot'. If for whatever reason JSTOR removes an article (I haven't seen this happen, but I suppose it's conceivable) then the JSTOR parameter should be removed. An access-date parameter isn't going to help with that one way or another. –jacobolus (t) 20:18, 6 November 2023 (UTC)Reply By the way, you don't have to throw hostile/insulting language into every conversation. –jacobolus (t) 20:25, 6 November 2023 (UTC)Reply I guess I'm just going to have to repeat this until you hear and acknowledge it: |access-date= tells us when an editor of our site last examined that source, and this is meaningful not only for detecting linkrot but also for alerting us to aging citation verification that needs to be revisited, because the material claimed to be cited to that source may have changed significantly in the interim by intervening edits. Whether the content in the source could have changed has nothing to do with that (though is also a relevant concern and a completely severable rationale for |access-date= usage, with various websites that aren't JSTOR).  — SMcCandlish ¢ 😼  20:37, 6 November 2023 (UTC)Reply No, I'm sorry but that's bullshit make-work, in typical situations unhelpful to both readers and other editors (speaking for myself, I've never once found this useful). Many articles here are based on source material that changes on the scale of centuries, and we do not need to keep detailed track of when every old book or research paper was last examined by some Wikipedian. Anyone who deeply cares about when sources were added or when text was modified can look at the page history. –jacobolus (t) 21:37, 6 November 2023 (UTC)Reply Assuming this reply threads correctly, I'll concede that using |access-date= as a heuristic for potential source–text integrity degradation due to intervening edits is a clever use case I hadn't considered, and will also concede that, given the relative infrequency of publication dates for web sources, using |access-date= as an approximation of |date= is something I do myself. It's certainly not always an unnecessary parameter, and sometimes it's deeply useful. Folly Mox (talk) 01:48, 7 November 2023 (UTC)Reply I would add that jacobolus not making use of this feature, and not taking time to ensure that the material claimed to be verified by a citation added a decade a go is still tied in any way to that citation (except perhaps by painstakingly digging around in a decade of page history) really has no implications for the rest of us taking a more sensible approach (at least when that approach has not been made unavailable by people removing access-dates). For some of us, making sure that the material claimed to be supported by a particular citation is actually supported by it is one of our most valuable activities here.  — SMcCandlish ¢ 😼  17:05, 7 November 2023 (UTC)Reply I think you're way too hung up on whether every word has enough attached metadata to satisfy bureaucratic requirements. Many if not most controversial non-technical claims involve enough nuance that figuring out whether they are fair, accurate, clearly stated, in scope, and helpful to readers involves a lot more thinking and care than just noting whether some Wikipedian most recently checked the cited 1950s journal paper in 2012 or 2018. To make sense of controversial claims requires carefully reading survey material, checking the sources, searching for alternative sources and comparing them, and then putting in direct thought. Trying to shortcut that with some facile date comparisons is a waste of time and effort. –jacobolus (t) 17:34, 7 November 2023 (UTC)Reply Of course doing the work requires a great deal of thking and care. What seem somehow unreasonably difficult to get across to you is that when this hasn't been done in a very long time, with material that has significantly changed in the interim, it needs to be done again, and the access-date is a strong signal to the editor how much time has passed since it was last done with regard to the citation and the text immediately in front of it.  — SMcCandlish ¢ 😼  18:06, 7 November 2023 (UTC)Reply I have never once found this to be even marginally useful in this context, and frankly can't imagine it; do you have a concrete example. From my perspective it's a pure-noise waste of space and attention when applied to static sources. The date of the source is obviously relevant though; depending on the subject matter an older source could certainly be obsolete and no longer reasonable in support of a particular claim, but that is going to be just as true whether someone last checked the source last week or 20 years ago. The intended purpose of access-date, for which it is probably sometimes handy, is in linking to changing sources such as personal web pages or recent newspaper articles. –jacobolus (t) 18:11, 7 November 2023 (UTC)Reply Using |access-date= as a way of telling when a particular claim was cited is parameter overloading unrelated to its original purpose. As we all know, it's to tell which version was consulted of a source whose content is changeable. Using it as |ref-added-date= is possible, sure, but a shaky claim cited in 2009 to a 2009 source is not less likely to be factual than a shaky claim cited in 2023 to a 1955 source. When the cite was added shouldn't affect our instinct of whether or not to verify it and see if newer information is available: that's |date=. Folly Mox (talk) 00:15, 7 November 2023 (UTC)Reply It is parameter overloading, and one is reasonable to question it, as I question the use of |year=2023a as a confusing disambiguation device, which comes also at the cost of "warring" date formatting (|year=1999, |date=1999), when there is probably a better way to do that disambiguation and elminate the parameter redundancy. But using |access-date= to signal "I checked this source on this date", as its name implies, comes at no confusion or redundancy cost. I've argued elsewhere that |language=en is not helpful because it's trying to aid a tiny class of users (at other wikis) in a way better done by improving their own import scripts; but |access-date= would be useful for all editors here doing WP:V / WP:NOR maintenance in articles, and we don't seem to have an alternative that is practical (digging through years of page history is not practical except at the simplest and most slowly-changing articles).  — SMcCandlish ¢ 😼  17:05, 7 November 2023 (UTC)Reply comes at no confusion or redundancy cost – this is self-evidently false. A vanishingly small proportion of Wiki editors have adopted your proposed idiosyncratic approach, and in practice the access-date parameter is nearly meaningless, or rather, making clear sense of it requires checking the page history anyway. –jacobolus (t) 17:36, 7 November 2023 (UTC)Reply I'm sorry that you have trouble "making clear sense" of a date in a citation added in 2012 and not access-date updated since then, but noting that a quick comparison of the material as it stood on that date versus what it says now shows signifcant changes but no new citation (without having to page through every intermediary edit). I don't think anyone else would have difficulty with this. I certainly do not.  — SMcCandlish ¢ 😼  18:10, 7 November 2023 (UTC)Reply I think what you are really looking for is some kind of better tool for determining the most recent update time for a particular chunk of text, analogous to the git blame command used by computer programmers. It would indeed be pretty useful to have a tool like that. But access-date on citations is an extremely poor and limited substitute. –jacobolus (t) 18:14, 7 November 2023 (UTC)Reply Agreed, but it is what we do have, and instituting a replacement feature isn't trivial, maybe not even practical (probably depends on MW devs), in contrast to the simple issue of, say, French Wikipedians tweaking their cite import scripts to attribute |langue=en by default to cites ripped from en.wikipedia. In the end, I've already "lost" the wider version of this argument, in that |access-date= got converted into an error condition on cites without |url=, but I still think that was a poor decision, and that removing more of them is a poorer one. I don't have an additional argument to bring about it, and think that the one already presented is worth consideration. It is an actual fact that if a bunch more access-dates get removed, then editors like me will end up doing less citation-to-claim verification and repair, because we will no longer be alerted by the presence of a really old access-date in material that is nevertheless being changed. That is a net loss to the encyclopedia for no gain other than citation concision.  — SMcCandlish ¢ 😼  18:29, 7 November 2023 (UTC)Reply |access-date= is absolutely required for web and news cites and should be reported as an error if it is missing. It enables bots and readers to locate the correct version of the page in an archive. Web sites and news articles are frequently updated. Link rot is ever present. |archive-url= and |url-status=dead are not good enough because the internet archive sometimes drops pages from its archive, requiring another archive retrieval. I would consider edits like the example above to be vandalism and a clear violation of WP:PRESERVE and treat them accordingly. Hawkeye7 (discuss) 18:46, 6 November 2023 (UTC)Reply Well, "vandalism" is a big of stretch; I think that the persons removing this parameter are not acting in bad faith, they're just engaging in what they believe to be "clean up" that is (according to some of us) actually detrimental to citation quality, and it's an WP:MEATBOT activity for which they don't have consensus.  — SMcCandlish ¢ 😼  20:11, 6 November 2023 (UTC)Reply Ok, so here's a situation I often find myself in: I'm verifying a deadlinked source's archive. The archive correctly supports the claim citing it. What do I update? I can't update the |access-date=, because I haven't accessed the source: only the archive. I can't update the |archive-date=, obviously, because that's intrinsic to the archive I consulted. There's no |archive-access-date= or {{verified source}}, thank goodness. (I understand I can take the null action, which seems to be what is being advised just above.)If I remove the |access-date=, I both reduce citation cruft and imply that the source that supports the claim is the archive. Whether the now inaccessible original source supported the text on the |access-date= is unknowable (unless it equals the |archive-date=, in which case it is even uselesser).Can I instead remove the original source altogether, and just cite the archive page? I've done this before, but then saw bots doing the reverse (extracting a source from a directly cited archive) and so I stopped. I asked a few threads up (the |url-status=dead one) whether directly citing an archive page is against any guidance, and which, but never got an answer. Folly Mox (talk) 01:36, 7 November 2023 (UTC)Reply When hunting an archive of a now dead web page, the access-date for the original source gives a hint for the date range to search. Removing |access-date= indiscriminately is not condoned by any guideline or policy; it serves no purpose, it's disruptive and borderline vandalism. -- Michael Bednarek (talk) 02:36, 7 November 2023 (UTC)Reply If there's a published date, the access-date is literally irrelevant for all practical purposes. Including for the search of archived versions. If the thing was published on 8 April 2013, then you search for the nearest time to that published date. Headbomb {t · c · p · b} 02:40, 7 November 2023 (UTC)Reply It's normal to include an access date in academic citations, like MLA. For example Encyclopedia Britannica here and click the "Cite" button and choose "MLA" from the drop-down menu. Since the web is changeable, it's useful for understanding when something was cited. Many links have no archive's available, and never will, so being able to say it existed at a certain date is more authoritative ie. you may not see it now, but we did on this particular date. Without a date, no one knows when it was seen, which makes understanding the citation more difficult in the future, say, 50 years from now. -- GreenC 01:22, 13 November 2023 (UTC)Reply Many links have no archive's available, and never will – if you add a citation to a web page, please consider explicitly telling the wayback machine to archive the page. There's no need to link the archived page from the citation on Wikipedia (which for still-living links in my opinion is somewhat spammy), but when the link eventually (probably) dies, there will be an archive available. Edit: I just clicked your username and see that you work for the Internet Archive and I'm not telling you anything new. A citation to a website without any kind of publication date involved should clearly have an access date if possible. But if the page cannot be archived, is not reproduced anywhere else, and does not have any kind of offline copy, then as a general rule the citation should probably expire when the website does. –jacobolus (t) 01:49, 13 November 2023 (UTC)Reply There is a bot that automates saving links to Wayback (nomore404) - and another bot that automates adding archives to Wikipedia (iabot). Two different bots, the former is largely invisible/unknown. Unfortunately, many websites can't be archived for various reasons eg. technical limitations, policy blocks, old link that died a long time ago. Even when they are archived, it could become unavailable in the future eg. policy blocks, technical errors, service provider goes offline. I do not disagree some citations can be deleted more frequently than we currently do. -- GreenC 02:27, 13 November 2023 (UTC)Reply Would you consider configuring the IABot to stop adding archive links to still living and accessible pages? The archive links are very visually heavy and (while the page lives) not useful to readers. –jacobolus (t) 02:37, 13 November 2023 (UTC)Reply I think disabling that tickbox should only come after IAbot learns the difference between a "live link" to a content page and a "live link" to a custom 404 page (a difference Citoid doesn't understand either). I've had cause to use the "add archives to live links" tickbox before, sadly, on an article with 140 citations to the same musuem which had done a complete website restructuring. I think I made it maybe 30 citations in before I gave up trying to find which pages were still live on the new museum site and what their new paths and filenames were, and called in IAbot to restore functionality to the whole situation at the cost of mega cruft. Folly Mox (talk) 02:48, 13 November 2023 (UTC)Reply Another issue is that there would hopefully be a way to distinguish and preserve archive-urls that were manually added instead of by bot runs, since some of us add Wayback links with |url-status= live on purpose for various news sites where the stories are paywalled at the live site but the IA crawler somehow manages to scrape them without to the paywalling.  — SMcCandlish ¢ 😼  05:54, 13 November 2023 (UTC)Reply Michael Bednarek, I've experienced some misindentations of my own in this thread, so I'm wondering if your comment here is in response to mine just above it, or in response to the diff linked in the OP. For clarity, in the scenario I brought up (the only time I remove |access-date= for a web source), I already have the archive. Folly Mox (talk) 02:53, 7 November 2023 (UTC)Reply Folly Mox, I almost always take the previous indent and add 1. Your comment started my thinking of how I use access-date sometimes, but I referred to the edits shown in the original post.Headbomb, archives might not be available for the web pages publication date, and instead of using the version closest to that date, I prefer the one closest to the last access date because the content might have changed. If wholesale removal of access dates is a valid edit, I suggest to change its documentation in all templates where it is used. -- Michael Bednarek (talk) 03:07, 7 November 2023 (UTC)Reply Honestly, I'd never remove this parameter if it were hidden by default for all sources except {{cite web}} where no |archive-url= is present. We had a big discussion about doing just that a few months ago either here or at Wikipedia talk:Citing sources or Wikipedia talk:Link rot or User talk:Citation bot or User talk:InternetArchiveBot, none of which I can ever keep straight. Obviously, nothing came of the discussion, but I just ran into an |access-date= to a print source that some previous editor had placed in an html comment that reminded me of that potential avenue to harmonious collaboration. Folly Mox (talk) 12:56, 7 November 2023 (UTC)Reply If nothing else, I find it useful for at-a-glance understanding when a citation was made. Last week? 20 years ago? It's useful in ways I find hard to explain. It might also be useful in the future in ways we might not (now) appreciate. For example searching for citations older than X years for targeted verification. Searching for the oldest citations. etc.. OTOH it's worth mentioning that access-date can be re-generated via automated means by crawling the article history to discover when the citation was added - IABot does this when a citation has no access-date. It's slow and pounds on the API, but we could add access-date when it is missing. -- GreenC 00:50, 13 November 2023 (UTC)Reply Oh, so that's what it's doing when it adds |access-date=s that match neither the |archive-date= nor today. I thought it was an error.It sounds like what people really want for most cases is |reference-added-date=. For the record, since participating in this thread, I've stopped removing |access-date= for print sources and archived dead links, instead placing them in html comments like some other editor inspired me to do. It upcrufts the wikicode a bit, but hides the dates in the displayed article. I still think doing this in the template rather than manually is the preferred solution. I've also once or twice just cited an archive snapshot directly, but usually forget and do it the regular way. Folly Mox (talk) 02:20, 13 November 2023 (UTC)Reply More than added date, access-date is also when it was last verified, so people are not continually re-verifying. Since verification is as common as the platypus, this may be wishful thinking. I do with articles I created. Every 5 years or so make sure everything is still working and verifiable. It's amazing how quickly stuff falls apart. -- GreenC 02:35, 13 November 2023 (UTC)Reply Definitely. I couldn't care less about a "reference-added-date". Why would that matter for any reason? What matters is when the ref was last checked against the claims it is being cited as the purported source for. I can only watchlist about 10,000 pages, but again and again and again I see someone (usually but not always an anon) adding a new claim right in front of an already-present source and in almost ever case that I take the time to investigate, the new claim is not in that source. This is a constant problem, site-wide, and we need tools to help address it. That means both that we probably need additional, better tools to address it, and we do not need "I know better than you" people going around removing the one tool we do have, the |access-date=, just because it somehow bugs them that in their personal reality tunnel it doesn't align with the cited source type or its other parameters, with what their favored off-line citation style does with the equivalent of access-date, or what someone says is the "real" reason the parameter exists. The actual real reasons, plural, that the parameter exists are the actual uses that we put it to. We, the editors working on the content, are the dog. The template coding "elegance" tail does not wag us (most expecially not in a template system that is built up in layers of cruft and kluges instead of having been designed comprehensively and elegantly from scratch).  — SMcCandlish ¢ 😼  06:05, 13 November 2023 (UTC)Reply

Citing a book excerpt

From Sam Bankman-Fried:

Lewis, Michael (November 2, 2023). "Sam Bankman-Fried: the rise and crash of a crypto billionaire". The Times. Archived from the original on November 2, 2023. Retrieved November 11, 2023.

(the archive URL gets past paywall). This is a book excerpt, according to the bottom of the article: "Extracted from Going Infinite". I'm confused what is the best way to cite it. The source material is the book, although I don't know if it is copy-pasted verbatim, copyedited, or pieced together. Regardless, the book is the source material. Should we instead cite the book? That works, but it is not available online, so is harder to verify, and there is no page number, and I don't own the book to find out. If The Times is cited, shouldn't it at least say somewhere it is extracted from the book, and how to do that? -- GreenC 04:25, 12 November 2023 (UTC)Reply

@GreenC: Hi there! If you've read the web page, then cite the web page. If you had read the book, then you would cite the book. However, you could do this: <ref>{{Cite web |last=Lewis |first=Michael |author-link=Michael Lewis |title=Sam Bankman-Fried: the rise and crash of a crypto billionaire |url= |website=The Times |date=November 2, 2023 |access-date=November 11, 2023 |archive-date=November 2, 2023 |archive-url= |url-status=live |url-access=subscription }} (Extracted from '']'')</ref> Happy editing! GoingBatty (talk) 05:59, 12 November 2023 (UTC)Reply That could work. I'm surprised CS1|2 doesn't have a generic |coda= for tacking on trailing strings to communicate what doesn't fit anywhere else. A few templates I have written included a coda argument, it's the very last thing rendered. It could result in misuse, but at least it would be machine-readable instead of floating outside the template where it is hard to maintain. -- GreenC 00:59, 13 November 2023 (UTC)Reply In practice it's not hard for humans to maintain text outside the template. If you really like you can include a whole separate template for the book. If you want the trailing material to also highlight when cited using a parenthetical reference in another footnote or the like, you can use the {{wikicite}} template wrapped around the whole lot, with ref=none set on any internal templates. –jacobolus (t) 02:30, 13 November 2023 (UTC)Reply

Add IMDb identifier for {{cite AV media}}

Doesn't need much of an explanation. IMDb is one of the most useful references for movies, documentaries, etc. so I suggest we add an |imdb= parameter. --bender235 (talk) 18:40, 12 November 2023 (UTC)Reply

Wikipedia:Reliable sources/Perennial sources § IMDbTrappist the monk (talk) 18:44, 12 November 2023 (UTC)Reply To repeat myself: not as a source for claims in the article, but as an identifier for a cited film, documentary etc. bender235 (talk) 21:39, 12 November 2023 (UTC)Reply But that would not be an identifier of the film, but an identifier of an unreliable website's page about the film. This would nothing like |doi= or |isbn=.  — SMcCandlish ¢ 😼  21:55, 12 November 2023 (UTC)Reply I'm pretty sure, if you're just trying to help readers navigate to more information about the film, you could follow the citation template, while still within the ref tags, with something like {{imdb title}}. As long as it's clear it's a navigational aid rather than being treated as a source of reliable information, I don't think it's against guidance, but I've never cited a film, and I'm out of my depth now. Folly Mox (talk) 22:06, 12 November 2023 (UTC)Reply Worldcat has films, so you could use |oclc= if it's a stable identifier you're wanting. Folly Mox (talk) 22:07, 12 November 2023 (UTC)Reply In this case, OCLC 1134530070. Kanguole 23:53, 12 November 2023 (UTC)Reply You could alternately put it in the "id" parameter of the template. –jacobolus (t) 02:33, 13 November 2023 (UTC)Reply An IMDB link outside of External links is likely to be removed. Kanguole 09:10, 13 November 2023 (UTC)Reply User:bender235, we have {{imdb name}} and {{imdb title}} (amongst other IMDb link templates) for external links to IMDb, where it is allowed. Folly Mox (talk) 20:52, 12 November 2023 (UTC)Reply in External links , metadata sites are usually listed thus: however, in order of usefulness and reliability they should be: can this be changed ? .... 0mtwb9gd5wx (talk) 21:20, 12 November 2023 (UTC)Reply MOS:FILM#External links doesn't seem to have any guidance about this, but Wikipedia talk:Manual of Style/Film would be the place to bring it up, not here. None of those strings reproduced from Devil's Cargo even uses a CS1|2 template in the article. Folly Mox (talk) 21:53, 12 November 2023 (UTC)Reply That is for the 'External links' section. I'm referring to footnotes. As an example, here I add the IMDb page in the |url= field when it should ideally by a |imdb= parameter. --bender235 (talk) 21:42, 12 November 2023 (UTC)Reply Right, that's the kind of citation to IMDb you shouldn't be making. Did you check out the links Trappist the monk and I dropped in the first two comments?Also, I'm not seeing anywhere on the IMDb page you cite in the linked diff any text supporting the assertion Glatzer has two granddaughters, Johanna Wechsler and Rina Redrup. If this information is in the film described by the IMDb page, just cite the film: no need for the URL. Folly Mox (talk) 21:50, 12 November 2023 (UTC)Reply Upon rereading my reply just above, it comes off as pretty condescending. My apologies. Folly Mox (talk) 22:12, 12 November 2023 (UTC)Reply I can't believe having to spell this out, but the source in this case is the documentary itself, not the IMDb page describing it. Just like the source for anytime anyone uses a footnote on Wikipedia including an ISBN number is the book itself, not the library catalogue entry about the book. As for "just cite the film". By that same logic: no need for ISBN/OCLC ever, "just cite the book". --bender235 (talk) 22:54, 12 November 2023 (UTC)Reply

Add new parameters for {{cite podcast}}

documented usage:

{{cite podcast | url= <!-- required --> | title= | website= | publisher= | host= | date= | time= | access-date= }}

also works:

{{cite podcast |url= |first1= |last1= |last2= |first2= |author1-link= |author2-link= |title= |website= |publisher= |date= |access-date= }}

Vertical integration of podcast companies and market evolution leads to the neglect of parameters:

|episode name= |podcast series name= |podcast distribution network=

add new parameters? .... 0mtwb9gd5wx (talk) 20:20, 12 November 2023 (UTC)Reply

Too long. If we added such parameters at all (and you've not laid out a clear use case for them), they'd be more like |episode=, |series=, |network=.  — SMcCandlish ¢ 😼  21:57, 12 November 2023 (UTC)Reply Does {{cite episode}} not work for your use cases? Folly Mox (talk) 22:02, 12 November 2023 (UTC)Reply

Author roles

Template:Cite episode/doc currently provides an example with which the current template implementation produces incorrect COinS data:

{{cite episode |title=Billy Crystal, 2nd Visit |series=Inside the Actors Studio |date=8 October 2007 |url= |network=Bravo |season=13 |number=1307 |last=Lipton |first=James (host)}} <cite id="CITEREFLipton2007" class="citation episode cs1">Lipton, James (host) (8 October 2007). <a rel="nofollow" class="external text" href="">"Billy Crystal, 2nd Visit"</a>. <i>Inside the Actors Studio</i>. Season 13. Episode 1307. Bravo.</cite><span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&amp;rft.genre=unknown&amp;rft.btitle=Inside+the+Actors+Studio&amp;rft.series=Season+13.+Episode+1307&amp;;rft.aulast=Lipton&amp;rft.aufirst=James+%28host%29&amp;;" class="Z3988"></span>

The relevant portion is rft.aufirst=James (host). "(host)" isn't part of a first name, so this is incorrect.

Options to resolve this issue:

  1. Have the template strip anything in parentheses from the COinS data. (eg. "James (host)" becomes "James ")
  2. Add parameters for specific roles, eg. |host-last=, |host-first=, |guest-last=
  3. Discourage Wikipedia editors from specifying roles, instead just using the usual author parameters like |last1=

Daask (talk) 20:43, 13 November 2023 (UTC)Reply

History: Help talk:Citation Style 1/Archive 86 § |people= parenthetical rolesTrappist the monk (talk) 20:55, 13 November 2023 (UTC)Reply The anon there, who provided a list of technical specs, said something interesting:

If such roles are to be codified, the role choices should be either instrumental or auxiliary in discovering the cited work. It makes no sense to include random roles just because Wikipedia editors are using them in citations 10 times or 10000 times, when they do not help in verification. Agreed-upon international cataloguing and metadata standards list a variety of usable roles (usable in the sense that catalogued works include the role nomenclature and its related person/entity in the item's description). These roles are used by all kinds of participating information repositories (trade organizations, publishers, libraries, accessible online databases etc) to list their works. Using these same roles works can be easily discovered.

I agree with the gist to not include ad hoc "role" designations editors make up on the fly and misuse to pollute the metadata and which don't aid in source hunting, but there may be something to the argument to implement role parameters based on those specs that use particular defined values. Then again it might be more trouble than it's worth. I also agree with their observation that the freeform |people= parameter seems to get at this "need" already anyway, though I'm not certain it's supported by the entire CS1 template family, and it has the deficit of not generating useful metadata. Lipton doesn't appear in the COinS output.  — SMcCandlish ¢ 😼  21:57, 13 November 2023 (UTC)Reply Lipton doesn't appear in the example metadata because |people= (also |credits=) is an equal alias of |authors= so doesn't contribute to the citation's metadata for the same reason. I don't think that the suggestion to strip parenthetical text from |authorn=, |lastn=, |firstn= is a good solution because Chinese (Japanese and Korean too?) names aren't necessarily bi-directionally transliterate-able between scripts so quite often you will see both the original zh-Hant or zh-Hans script parenthtically included with a latin transliteration. I am in favor of restricting the use of |people=, |credits=, |hostn= (this one is an equal alias of |authorn=) to {{cite av media}}, {{cite episode}}, {{cite serial}}. —Trappist the monk (talk) 22:49, 13 November 2023 (UTC)Reply

module suite update 25–26 November 2023

I propose to update cs1|2 module suite over the weekend 25–26 November 2023. Here are the changes:




Module:Citation/CS1/Date validation


Trappist the monk (talk) 23:34, 18 November 2023 (UTC) +last minute bug fix 15:27, 25 November 2023 (UTC)Reply

Right now the numeric maint is emitting when the numeric error emits. It would be good to emit only the error in such cases. Izno (talk) 18:57, 25 November 2023 (UTC)Reply True, but when that happens it doesn't happen for the same parameter. For example, this emits two messages, the error message for |author=1234 and then maint message for |author2=4D2 {{cite book |title=Title |author=1234 |author2=4D2}} 1234; 4D2. Title. {{cite book}}: |author= has numeric name (help)CS1 maint: numeric names: authors list (link) So not really redundant messaging. —Trappist the monk (talk) 19:46, 25 November 2023 (UTC)Reply The maintenance cats also need to be updated for the new use, which is some numbers in the name, and recommended disposition (or not). Izno (talk) 18:58, 25 November 2023 (UTC)Reply Did that while you were writing you message. —Trappist the monk (talk) 19:46, 25 November 2023 (UTC)Reply @Trappist the monk: Hi, I'm not sure if this issue was caused by this change or if I missed an earlier change that caused this, but 'CS1 maint: numeric names: authors list' is now being flagged for {{Cite tweet}} when there is a number in the |user= parameter even if there is no number in the |author=, |first=, or |last= parameters. I noticed this at Star Trek: Picard (season 1) which has a Twitter reference called "Culpepper3Split" where it is valid for the |user= parameter to have a number in it. I tested removing the number and it cleared the warning. - adamstom97 (talk) 01:13, 28 November 2023 (UTC)Reply That maintenance message is new with this update. {{cite tweet}} concatenates |last=Culpepper, |first=Hanelle, and |userHillview798= into |author=Culpepper, Hanelle which it hands off to {{cite web}} for rendering. This is not a {{cite web}} or Module:Citation/CS1 problem but is a problem of Module:Cite tweet – |user= value, the brackets, and the @ symbol do not belong in |author= as given to {{cite web}}. You should raise this issue at Template talk:Cite tweet. See Template talk:Cite tweet/Archive 2 § Template-protected edit request on 8 March 2023 which describes a different but related problem. A solution proposed for that would have addressed both problems but was not adopted. I don't know why. —Trappist the monk (talk) 02:07, 28 November 2023 (UTC)Reply Cool, thanks for the explanation. - adamstom97 (talk) 02:16, 28 November 2023 (UTC)Reply Which solution are you pointing to, the author-mask or the substitution? I'm having a hard time making sense of this :\ SWinxy (talk) 05:57, 28 November 2023 (UTC)Reply I don't know what you mean by the substitution. That term does not appear in the discussion I linked: Template talk:Cite tweet/Archive 2 § Template-protected edit request on 8 March 2023. —Trappist the monk (talk) 15:09, 28 November 2023 (UTC)Reply I mean gsubbing the author field, which is what you seem to have proposed. SWinxy (talk) 16:42, 28 November 2023 (UTC)Reply Do you mean lines 39–41? Please be explicit; don't make me pull out your teeth one by one... —Trappist the monk (talk) 16:53, 28 November 2023 (UTC)Reply Yes. Sorry, I'm trying to wrap my head around what was proposed to fix those problems. SWinxy (talk) 21:28, 29 November 2023 (UTC)Reply

Another render of the source template

Hello! The Russian Wikipedia uses this module, as well as other modules that display source templates differently, for example:

Aries, Myriam B. C. & Newsham, Guy R. (2008). "Effect of daylight saving time on lighting energy use: a literature review". Energy Policy. 36 (6): 1858–1866. doi:10.1016/j.enpol.2007.05.021. Retrieved October 18, 2013.

Aries, Myriam B. C. & Newsham, Guy R. Effect of daylight saving time on lighting energy use: a literature review (en.) // Energy Policy. — 2008. — Vol. 36, no. 6. — P. 1858–1866. — doi:10.1016/j.enpol.2007.05.021. Retrieved October 18, 2013.

Tell me, is it possible to use different styles for different templates? Are there render settings for each type? This module is very difficult to understand and I need help :) Iniquity (talk) 19:21, 20 November 2023 (UTC)Reply

I presume that by Our templates you mean's templates, not's templates. There are a lot of wikis that take a copy of's Module:Citation/CS1 suite of modules. Each wiki can, and many do, modify their copy to suit their particular needs. Because there are so many wikis that have copies of the module suite, it is impracticable to have simple settings to change the rendering. I created a {{cite journal}} template from the first of your two example renderings: {{cite journal |author=Aries, Myriam B. C. |author2=Newsham, Guy R. |name-list-style=amp |date=2008 |title=Effect of daylight saving time on lighting energy use: a literature review |journal=Energy Policy |volume=36 |issue=6 |pages=1858–1866 |doi=10.1016/j.enpol.2007.05.021 |access-date=October 18, 2013}} Aries, Myriam B. C. & Newsham, Guy R. (2008). "Effect of daylight saving time on lighting energy use: a literature review". Energy Policy. 36 (6): 1858–1866. doi:10.1016/j.enpol.2007.05.021. {{cite journal}}: |access-date= requires |url= (help) I then pasted that into my sandbox at and previewed which gave me a rendering that looks like this: Aries, Myriam B. C.; Newsham, Guy R. (2008). “Effect of daylight saving time on lighting energy use: a literature review”. Energy Policy. 36 (6): 1858—1866. DOI:10.1016/j.enpol.2007.05.021. Дата обращения October 18, 2013. The module is sufficiently old that it does not recognize |name-list-style= so the rendering does not have the ampersand between the author names and at emits a Неизвестный параметр error message. The rendering does not emit an error message for |access-date=-requires-|url=; uses curly quotes, an emdash separator between page numbers, and capitalizes the doi prefix. Certainly this experiment does not look anything like the Our templates example. So what is it that you really want to understand? —Trappist the monk (talk) 19:59, 20 November 2023 (UTC)Reply Yes, I know that the module is outdated and I'm currently trying to update it, thanks :)I would like to know if it is possible for the 'cite journal' to display the source as in our (ruwiki) templates, for example: ru:Template:Статья. Iniquity (talk) 20:41, 20 November 2023 (UTC)Reply Of course it is, if you're willing to put in the work and are willing to redo the work every time someone at decides to update the module suite. I guess I gotta wonder if it might be easier to write a translator module that maps non-Russian parameter names to their Russian counterparts and then calls the appropriate Russian template. We have done that here for a few languages that make extensive use of Module:Citation/CS1. See Module:CS1 translator. For example, at, ru:Template:Cite journal would call the translator module. The translator module might map the parameters to these parameters: |author= → |автор= – apparently |автор= cannot be enumerated so values from |author= and |author2= must be concatenated into a single value |date= → |год= |title= → |заглавие= |edition= → |издание= |volume= → |том= |issue=, |number= → |номер= |pages= → |страницы= It would then call {{Статья}} from the translator module: {{Статья |автор=Aries, Myriam B. C. & Newsham, Guy R. |год=2008 |заглавие=Effect of daylight saving time on lighting energy use: a literature review |издание=Energy Policy |том=36 |номер=6 |страницы=1858–1866 |doi=10.1016/j.enpol.2007.05.021}} Aries, Myriam B. C. & Newsham, Guy R. Effect of daylight saving time on lighting energy use: a literature review // Energy Policy. — 2008. — Т. 36, № 6. — С. 1858–1866. — doi:10.1016/j.enpol.2007.05.021. —Trappist the monk (talk) 23:29, 20 November 2023 (UTC)Reply We have done that here for a few languages that make extensive use of Module:Citation/CS1. See Module:CS1 translator.
Oh thank you for suggesting this module. This may help with some things.Of course it is, if you're willing to put in the work and are willing to redo the work every time someone at decides to update the module suite. I guess I gotta wonder if it might be easier to write a translator module that maps non-Russian parameter names to their Russian counterparts and then calls the appropriate Russian template.
I would like to transfer all of our source templates to one module because I want to remove the entire zoo of templates that currently exists in ruwiki. And given that this module exists in a huge number of Wikipedias, the right goal is to remake everything so that it works on this module, and not to create my own. Iniquity (talk) 00:26, 21 November 2023 (UTC)Reply @Trappist the monk, can you help me with my request? :) Where is the rendering order described? Iniquity (talk) 11:15, 25 November 2023 (UTC)Reply There is no such description. Some parts of a rendered citation are assembled in individual functions – format_chapter_title(), language_parameter(), format_pages_sheets(), etc – while other parts and the whole are assembled in citation0(). This is why I suggested that you create a translator module if you must produce a rendering that is so distinctly different from a cs1|2 rendering. Yeah, its a mess, and if I ever get up the courage to do it, I'll rewrite to make it more flexible. —Trappist the monk (talk) 15:09, 25 November 2023 (UTC)Reply I'm understood, thank you! Iniquity (talk) 03:20, 26 November 2023 (UTC)Reply

Consistency in parameter order

Is there a reason the various CS1 templates are inconsistent in their ordering of TemplateData parameters? They generally agree on author names being first, but then the order after that varies wildly. If there is no reason for this inconsistency, we should establish a standardized order — perhaps based on {{Cite web}}, since it's the most commonly used. InfiniteNexus (talk) 05:48, 21 November 2023 (UTC)Reply

Why? The order is irrelevant. If you really want to spend your limited volunteer time normalizing them, I doubt anyone would revert you, but it seems rather pointless.  — SMcCandlish ¢ 😼  06:13, 21 November 2023 (UTC)Reply For one, Wikipedia:ProveIt (and possibly other tools) uses the TemplateData order to normalize citations. But if you think no one would revert/object, I will go ahead and change it. The only reason I came here first was because Template:Cite web#TemplateData had a very serious-looking stop sign. InfiniteNexus (talk) 06:20, 21 November 2023 (UTC)Reply Maybe there is a reason for that; Trappist the Monk would probably know. If ProveIt is using it in some automated fashion maybe something else is also, and expecting a particular order? I dunno.  — SMcCandlish ¢ 😼  06:32, 21 November 2023 (UTC)Reply The {{warning}} template was added by Editor GreenC at this edit. I agree that fussing with the parameter order in template data is likely a waste of time because anyone can edit the template data to add, remove, rearrange, whatever as they please. If you normalize parameter order for all twenty-eight cs1 templates and {{citation}} (and all of their wrapper templates?) I suspect that you will forever be chasing after random edits restoring your preferred order. Seems like a lot of work for no real benefit. —Trappist the monk (talk) 13:54, 21 November 2023 (UTC)Reply ProveIt doesn't have bot approval for these automated cosmetic changes to citation markup, does it? Kanguole 14:27, 21 November 2023 (UTC)Reply I doubt it does, although I also don't think it edits as a bot (unsupervised). I agree that if all ProveIt has available on an article is reordering template parameters, it should decline the edit. Template parameter order is one of the few things on the project that truly doesn't matter at all. Folly Mox (talk) 00:13, 23 November 2023 (UTC)Reply

I would certainly object to gnomes or bots going around making edits that change the parameter order in articles. That sort of thing makes it very difficult for humans looking at watchlists to figure out which edits made actual changes and which are cosmetic. I would prefer that the order be left in place unless you are making significant other changes to the citations. For what it's worth, the order I often use is authors first and then alphabetical by parameter name. I'm not going to defend that as a good order, but it's what the software I use produces and so I'm very unlikely to change that habit. That said, I don't care what order they are listed in TemplateData, as long as people editing articles don't think that the order is meaningful. So if you think your time is well spent making meaningless changes to TemplateData, go ahead. —David Eppstein (talk) 00:47, 23 November 2023 (UTC)Reply

Completely agree it's another thing that should just be left unless you are overhauling the article. -- LCU ActivelyDisinterested «@» °∆t° 00:58, 23 November 2023 (UTC)Reply ProveIt is not a bot that makes automated cosmetic edits; it is a gadget currently used by 22,138 editors. When someone uses ProveIt to normalize citations on a page (which is a function provided by many other scripts that may not be as popular), they take full responsibility for such action, and this is usually done to maintain consistency within the article or clean it up in preparation for ease of readability when editing.Given these responses, does that mean no one objects to the TemplateData parameter order being adjusted? If so, I will go ahead and do so. InfiniteNexus (talk) 01:15, 24 November 2023 (UTC)Reply It is not the TemplateData order that I would object to. It sounds like, however the templates are ordered, ProveIt will do what it does. But if someone were running around using ProveIt to normalize citations on a page, and this led them only to make cosmetic modifications such as parameter reordering with no significant improvement to the references, I would definitely object, just as I objected today to CitationBot running around reordering templates in a way that separated authors from their authorlinks. —David Eppstein (talk) 01:36, 24 November 2023 (UTC)Reply If someone were doing that in a systematic matter, they would obviously be considered disruptive and be reported to ANI. And I definitely don't think someone should be going around normalizing random articles' references without doing anything else, and for no particular reason. InfiniteNexus (talk) 04:42, 24 November 2023 (UTC)Reply That's probably the correct outcome, but I'm not certain it would happen, especially if the editor were not hitting pages on the same people's watchlists. I think it's better to prevent this sort of non-constructive editing by controlling how the software functions, rather than try to fix it after it's become a problem. I'll remind people that it took several months before User:Philoserf was brought to AN for disruptive usage of the ReferenceExpander script, and a second thread a month later before he was blocked for it, and we still haven't finished cleaning up after that.It's safer to minimise the potential for disruption by script usage than it is to trust that editors won't use scripts disruptively, and trust that the process to stop disruptive script usage will function in a timely manner. Folly Mox (talk) 12:09, 24 November 2023 (UTC)Reply If you have a look at Wikipedia:Bot policy, you'll see that it covers what ProveIt is doing. Personally, I object to normalization even when combined with non-cosmetic edits. Kanguole 09:07, 24 November 2023 (UTC)Reply Also, as long as ProveIt is doing this, if you change the order of the parameters in TemplateData, we'll see a bunch of useless edits where ProveIt re-normalizes previously normalized citations. Kanguole 09:34, 24 November 2023 (UTC)Reply

Bookshelf NBK ID for the books of National Library of Medicine indexed via MEDLINE

I already requested that earlier at Help_talk:Citation_Style_1/Archive_72#Request_for_the_"nbk"_(NCBI_bookshelf)_attribute_for_"cite_book" but nobody replied, can you please consider this request again?

Please add the "nbk" attribute for the "cite book" template to specify the NCBI NBK number. You already have the "pmc" and "pmid" attributes, but the "nbk" is different. It refers to the NCBI bookshelf site that has different URL forman than PubMed Central. The URL to the bookshelf looks like (where 557634 is the NCBI NBK number). My idea is when you specify the "nbk" to the "cite book", the direct URL to the book at the NBI site will be generated. Currently, NCBI bookshelf books cannot be accessed directly from Wikipedia or other Wikimedia cites that allow the "cite book" template. Maxim Masiutin (talk) 01:20, 22 November 2023 (UTC)Reply

Is there some better example, of something we'd actually cite? The example given above is to an article/chapter of tertiary summary material (i.e. something like Wikipedia itself) from what appears to be an unreliable source named StatPearls, all about medical topics but certainly not a source that passes WP:MEDRS. If there is something, why wouldn't we just put the URL to it in |url=? Are we expecting cases where the full text is available at some other URL but also available by NCBI? If so, do we need to care?  — SMcCandlish ¢ 😼  02:51, 22 November 2023 (UTC)Reply If you go to this URL, you will see {{PMID:32491566}} at the bottom of this page. The NCBI NBK number is a link to the free content of a book. Whereas free journal article content on MEDLINE has a PMC identifier that Wikipedia links, the books do not have PMC number, they have NBK number instead. Therfore, Pubmed ID links to the information about this book but not actual content. While we can provide an identifier to a free content of an article via PMC, we lack the same oportunity to provide a direct link to free content of a book. The argument about the reliable source should be addressed by each editor on a case-by-case basis, we should give a technical oportunity to link to the content directly, as we do for PMC which are also not always reliable sources. See the following examples of NBK books: {{PMID:30860714}}, {{PMID:29262018}}, {{PMID:29262018}}, etc. Thank you very much for considering my request! I'm strugging with the lack of this NCBI NBK number ID for years literally! Maxim Masiutin (talk) 03:01, 22 November 2023 (UTC)Reply But |url= already "give a technical oportunity to link to the content directly". We shouldn't add custom linking parameters for source databases unless we're certain they have a lot of material we want to use as sources and the parameter would be frequently used by editors for reliable ones. The fact that you can find material that is reachable by |pmc= but which isn't good source material isn't an argument to add a new |nbk= parameter. PS: I checked the three PMIDs you gave above; one is a duplicate, and the other two just go to more of this StatPearls junk.  — SMcCandlish ¢ 😼  03:10, 22 November 2023 (UTC)Reply When we specify the |pmc=, we don't have to specify URL; the template generates URL automatically. However, for NBK we have to specify url which is always an uniform having an NBK parameter. So your reasoning on not adding it is because StatPearls is a low quality source? Maxim Masiutin (talk) 03:13, 22 November 2023 (UTC)Reply You can search "StatPearls" in pubmed or open URL and get many search results on the books I mentioned. Maxim Masiutin (talk) 03:15, 22 November 2023 (UTC)Reply Taking these points in order: Yes, but so what? Someone still has to copy-paste something from the URL bar or elsewhere on the source page into a citation template parameter, so |nbk= saves no work at all. Yes, and so what? It is not harmful or an imposition in any way to type |url= and paste a URL into it; this will actually be faster and easier that typing |nbk=, selecting a particular string perfectly from a URL, and pasting that in. No, my reasoning is that you haven't presented a valid use case for this, and when pressed for examples that might qualify as sources we would use you've just coughed up more links to the same poor source material. Finally, the fact that your poor source can be found via other searches is completely irrelevant to both whether it is a source we should use and whether we should have an |nbk= parameter.  — SMcCandlish ¢ 😼  03:22, 22 November 2023 (UTC)Reply Thank you for your reasoning. Still, I hope that the NBK parameter will appear in the future. Maxim Masiutin (talk) 03:32, 22 November 2023 (UTC)Reply Maybe StatPearls was not a good example, but there are books there which are not necessarily rubbsh, such as Maxim Masiutin (talk) 19:29, 25 November 2023 (UTC)Reply

Possible edge case to include: Titles and chapters that end with punctuation


I don't know if this has been discussed before and rejected, and I'm not even 100% sure it's a good idea myself given that the case is rare. Right now, it appears that a period unconditionally appears after a title or chapter param. This probably simplifies the logic and also might make parsing the text easier. That said, it is a little odd if the title ends with punctuation such as "?", "!", or "...". Is it worth sticking some logic in there to omit the period in those cases as unnecessary?

Examples (title first, then chapter):

It's also possible that maybe this change makes less sense for chapter titles specifically, as there's an additional layer of quotation marks wrapping it. It also might look okay if there's a url= parameter, as the title will be linked but the period won't be, separating it some. But the "?." looks kinda doofy if a url isn't set, and I suspect it would be outright confusing for titles that end in an ellipsis (Reader: did the author intentionally pick four periods, or is it three periods + a Wikipedia-placed period?). Any thoughts? SnowFire (talk) 19:15, 22 November 2023 (UTC)Reply

This is a known issue and has been known since at least July 2013. To do it right requires a rewrite of safe_join(). There is an existing hack that should correctly handle ellipses: {{cite book |title=Title...}} → Title... —Trappist the monk (talk) 23:16, 22 November 2023 (UTC)Reply

Volumes with their own subtitles

Resolved – Seems to have been PEBKAC on my part.  — SMcCandlish ¢ 😼  23:26, 22 November 2023 (UTC)Reply

Presently the templates are being "too smart for their own good" and throwing an error when they encounter something like |volume=VI: ''The Reformation'', and I am desirous that this misbehavior stop.  — SMcCandlish ¢ 😼  21:25, 22 November 2023 (UTC)Reply

@SMcCandlish: Which article? Which template? GoingBatty (talk) 21:36, 22 November 2023 (UTC)Reply Something from yesterday. I'm not sure I remember at this point. Will see if I can dig it up again.  — SMcCandlish ¢ 😼  21:41, 22 November 2023 (UTC)Reply The only thing that should show a cs1 message is the comma, and it should as otherwise you end up with "VI: The Reformation,.". You will get an error message if you include "|volume=Volume VI: .." as you then end up with the duplicated "Vol. Volume VI:..". -- LCU ActivelyDisinterested «@» °∆t° 21:45, 22 November 2023 (UTC)Reply Found it. This: {{Cite book |url= |title=Mammals of the Soviet Union |volume=2, Pt. 2: ''Carnivora (Hyenas and Cats)'' |isbn=9004088768 |last=Heptner |first=V. G. |date=1989}} now produces: Heptner, V. G. (1989). Mammals of the Soviet Union. Vol. 2, Pt. 2: Carnivora (Hyenas and Cats). ISBN 9004088768. But when I did this yesterday it threw an error that complained about something like extraneous/additional material in the volume parameter (I don't remember the exact red error wording), and I had to change it to |title=Mammals of the Soviet Union, Vol. 2, Pt. 2: Carnivora (Hyenas and Cats). I don't know why it's working now and didn't work yesterday.  — SMcCandlish ¢ 😼  21:51, 22 November 2023 (UTC)Reply Possibly either of these?
Heptner, V. G. (1989). Mammals of the Soviet Union. Vol. Volume 2, Pt. 2: Carnivora (Hyenas and Cats). ISBN 9004088768. {{cite book}}: |volume= has extra text (help)
Heptner, V. G. (1989). Mammals of the Soviet Union. Vol. 2, Pt. 2: Carnivora (Hyenas and Cats), . ISBN 9004088768.{{cite book}}: CS1 maint: extra punctuation (link)
Just having the volume title shouldn't cause any error messages. -- LCU ActivelyDisinterested «@» °∆t° 22:07, 22 November 2023 (UTC)Reply

Best practices for a full citation with no author, when linked by shortened footnotes

Resolved – The help page now transcludes the advice from Template:Harvard citation documentation and includes two examples informed by the discussions below. Many thanks for the assistance and happy Thanksgiving, Rjjiii (talk) 08:45, 23 November 2023 (UTC)Reply

I have a question about a help page which is directly giving advice about the CS1/CS2 templates. Are any of the no-author styles explained at H:SFN, misusing a parameter? The section at Help:Shortened footnotes#No author reads:

Some sources do not have a single author with a last name, such as a magazine article or a report from a government institution. Options include:
  1. ^ Setting the author parameter to something solves the problem of having to set the "ref=" parameter to something other than that which is automatically generated.

This seems to contradict the template documentation, but I have seen a lot of people create citations using the |author= field this way. Regards, Rjjiii (talk) 22:44, 22 November 2023 (UTC)Reply

You've gone to the trouble of quoting H:SFN which you then claim seems to contradict the template documentation but you fail to specify or quote that conflicting documentation. Which template? Which documentation? —Trappist the monk (talk) 23:03, 22 November 2023 (UTC)Reply @Trappist the monk: Valid point, Template:Cite book/doc gives this example: |author=<!--Staff writer(s); no by-line.--> and explains the author parameter as so: this parameter is used to hold the name of an organizational author (e.g. a committee) or the complete name (first and last) of a single person; for the latter, prefer the use of |first= and |last=. This parameter should never hold the names of more than one author. Template:Cite news/doc and Template:Cite journal/doc contain the same text. Rjjiii (talk) 23:16, 22 November 2023 (UTC)Reply I changed the example in Template:Cite book/doc § Usage to match the recommendation at Help:Citation Style 1 § Authors. Why do you think there is a contradiction? All that the cs1|2 template doc says is use real names, for humans prefer |last=/ |first= pairs for each human author. The |author=<!--Not stated--> is merely a recommendation to prevent future editors from wasting their time searching for author(s) who have not been named. I don't see any of that as a contradiction. I do think that making up names for any of the |author= aliases (|author=Anonymous etc) is wrong because that attributes the work to an author who appears to be named 'Anonymous'. Similarly, |author=publication name staff is just as bad. For periodicals, I think that the best solution for use with {{sfn}} is to set |ref={{sfnref|''<periodical name>''|<date> and {{sfn|''<periodical name>''|<date>}} —Trappist the monk (talk) 23:45, 22 November 2023 (UTC)Reply Surely the advice should be to setup the |ref= field appropriately rather than misusing |author=. Especially when it duplicates publisher, and doubly so when it comes to constructs such as title/year. -- LCU ActivelyDisinterested «@» °∆t° 23:34, 22 November 2023 (UTC)Reply Yes, and this poor documentation probably explains why I keep running into redundant junk like |author=NYT staff, or even worse |author=The New York Times|work=The New York Times or |author=Museum of Modern Art|publisher=Museum of Modern Art. The material at H:SFN is clearly wrong, or at least badly misleading. You might need to use a short footnote that read something like "Museum of Modern Art (2023)" when there is no specified author, but the way to template this is to use |ref={{harvid|Museum of Modern Art|2023}} in the main citation, not to do a bogus |author=Museum of Modern Art that is redundant with |publisher=Museum of Modern Art. This can probably be resolved by editing H:SFN and the docs of Template:Sfn to include specific examples of this sort, and to explicitly say not to abuse the |author= or |last= parameter to kluge this. PS: {{harvid}} has been moved to {{SfnRef}}, and it may be preferable to update the mentions of {{harvid}} to use the current actual name of the template.  — SMcCandlish ¢ 😼  23:42, 22 November 2023 (UTC)Reply +1 -- LCU ActivelyDisinterested «@» °∆t° 23:50, 22 November 2023 (UTC)Reply I copied the text by Charlie Gillingham from Template:sfn/doc to Help:Shortened footnotes, changing "harvid" to "sfnref", which already suggested using |ref=. And regarding the question of why I saw the language as contradictory, I was saying that advice to use the title of the work or a description of the author (at H:SFN) seemed to contradict the advice to use a person or organization's name (at Template:Cite book/doc). I was uncertain, so I asked. Rjjiii (ii) (talk) 00:53, 23 November 2023 (UTC)Reply Also, thanks all for the input, Rjjiii (ii) (talk) 00:54, 23 November 2023 (UTC)Reply Keeping in mind that {{sfn}} should be short, and this is all about convenience for editors (i.e., not users), I think the |ref= should be encouraged to be short as well, so rather than |ref={{harvid|Museum of Modern Art|2023}}, it should be |ref={{harvid|MMA|2023}} which will very likely be unique among refs on the page (and if not, there are alternatives). Mathglot (talk) 01:14, 23 November 2023 (UTC)Reply I disagree. Initialisms are inherently obscure so in general should be avoided. But, surely, if you are going to use an initialism, and the source has a commonly used initialism, use the source's initialism, not one that you made up or is used by some other organization. In your example, if you must use an initialism it should be 'MoMA' not 'MMA' (commonly used for Mixed Martial Arts}. For the avoidance of doubt, both long- and short-form citations should use the same name. —Trappist the monk (talk) 01:25, 23 November 2023 (UTC)Reply Yep.  — SMcCandlish ¢ 😼  02:16, 23 November 2023 (UTC)Reply The example from the {{sfn}} doc page includes a generic "BGI" initialization. I've replaced that on H:SFN with a "MoMA" shortened footnote. I haven't changed anything on the template documentation. Rjjiii (ii) (talk) 02:42, 23 November 2023 (UTC)Reply Unnecessary pile-on support for this statement. Anything used in the {{sfnref}} should either appear verbatim in the full citation or be listed in a "(Cited as Short Name)" parenthetical immediately following the full citation. Folly Mox (talk) 05:35, 23 November 2023 (UTC)Reply And by the way, for those who are talking about "modify the sfn doc" (which I generally agree would be a good thing) it's a little hard to find; it's at Template:Citation Style documentation/author. Mathglot (talk) 01:44, 23 November 2023 (UTC)Reply @Mathglot: Thanks for helping out. I see you've transcluded the text from Template:Harvard citation documentation#No author name in citation template. That seems easier to maintain. Would it be wise then, to transclude the whole thing, and use whichever example is best on that page? Rjjiii (talk) 04:03, 23 November 2023 (UTC)Reply Also, what do you mean about "the table column presentation is messed up in this one"? I see a 2x2 grid in both? Rjjiii (talk) 04:06, 23 November 2023 (UTC)Reply Yes, it's 2x2, but left col is 90% of page width on a computer monitor; are you using only mobile to view it? Maybe I should verify with some other browsers, in case it's just me? Mathglot (talk) 05:07, 23 November 2023 (UTC)Reply Works now; your "3rd time" fix did it. Must've been the url. I've seen that issue before, and I forget how I fixed it, but there's a way. In the meantime, the shorter url works fine. Mathglot (talk) 05:24, 23 November 2023 (UTC)Reply @Mathglot: thanks for the explanation! I tested the mobile skin and both desktop skins but only on Firefox. Chrome keeps the URLs as one line and Firefox breaks them at the slashes. As soon as I read your "left col is 90%", I realized how I goofed. I've run into this problem before and totally forgot about it. With a smaller URL and a space before the parameter, it now looks fine on desktop Chrome, mobile Chrome, mobile Safari, Edge, the android app, and some niche browsers. Thanks again, Rjjiii (talk) 05:47, 23 November 2023 (UTC)Reply Guess I'm a niche browser person; I use Vivaldi almost exclusively, others on mobile, or for testing or special purposes. Mathglot (talk) 06:35, 23 November 2023 (UTC)Reply As far as transcluding the example as well: excerpting from a Template that can have params is tricky, because {{Excerpt}} doesn't pass params; so I conservatively excerpted only the top part with the intro paragraph and bullet list, because I could easily see that there were no template params like {{{1|}}}; the markup code below it was denser, and I didn't want to risk a mistake by transcluding it if it used params. If it doesn't, that should be excerptable as well. Mathglot (talk) 05:11, 23 November 2023 (UTC)Reply

Ordering of full citations

If an article is using shortened references, that means a full list of sources appears in alphabetical order according to the first element; the only fields which can be first in a CS1 template are |author=/|last= or |editor-last= I believe. If there is a |ref={{harvid|MoMA|2023}} then a reader should be able to find MoMA accordingly amongst other M-names and so the first element should include whatever tag the reader will use to find the source in an alphabetic list.

For the curious, here's the CMoS:

If a publication issued by an organization, association, or corporation carries no personal author’s name on the title page, the organization may be listed as author in the reference list, even if it is also given as publisher. To facilitate shorter parenthetical text citations, the organization may be listed under an abbreviation, in which case the entry must be alphabetized under that abbreviation (rather than the spelled-out name) in the reference list.

Umimmak (talk) 06:37, 23 November 2023 (UTC)Reply

Wikipedia isn't bound by a single thing CMoS says. Our own material at WP:CITE (including WP:SFN) requires neither shortened footnotes (much less ones in CMoS style in particular) nor an alphabetical list of sources. It generally makes sense to provide one, if an article is using shortened footnotes, but putting a {{cite web |publisher=] |...}} in alphabetical order under "MoMA" is perfectly fine. If some reader's head would just explode upon encountering this, they are not competent to be reading our material in the first place. And no one reads lists of citations like a novel. They get to a citation by clicking on a link to it. If for some reason they did not but are manually hunting around for a MoMA source in a list of sources (why?), all they have to do is Ctrl-F MoMA Enter (or on a Mac Cmd-F MoMA Enter). If this still just somehow doesn't compute for someone on the editorial side, they can do the source list entry as * MoMA: {{cite web |publisher=] |...}} (though I think other editors would later remove the leading "MoMA: " as extraneous and silly, treating our readers as if they had brain damage). Nothing said above is any excuse for doing a bogus |author=MoMA.  — SMcCandlish ¢ 😼  07:18, 23 November 2023 (UTC)Reply The tone of your comment was needlessly rude… We aren’t bound by Chicago, obviously, but I think it’s worth seeing what other style guides do in similar situations. Why alphabetize anything if the links take an online reader directly to the source or they can use a search function? People sometimes print out articles, the Creative Commons license allows materials to be used elsewhere which might not have as robust links, links can also be be broken for a variety of reasons and having sources in an order which makes intuitive sense to the reader might be an asset that the editors of some articles might desire. If there is no author, the first part of the citation would be the title; MLA uses an abbreviated title in its parentheticals when there is no author, and this is another option if it’s really that bad to repeat information. That way sources can be still sorted alphabetically by their first element and by whatever appears in the shortened citation. Umimmak (talk) 08:02, 23 November 2023 (UTC)Reply I already said it was probably a good idea to alphabetize them. If you insist on having the first element on the line be the name by which it is alphabetized, I already provided you a way to do that without fudging citatation template parameters, though there is no reason in the first place to suppose that our readers are so dense they can't understand that an entry with no author which is alphabetized in the Ms between Michaels and Munster is under MoMA, the publisher name.  — SMcCandlish ¢ 😼  08:14, 23 November 2023 (UTC)Reply Way off topic: This ship may have sailed, but {{harvtxt|ref=none|Last|YYYY}}.  will create exactly the citation format for the bibliography when given the same parameters as {{sfnref}}. The citation templates could generate this when fed sfnrefs, but I don't know if it's worth the effort. It also won't be highlighted from the pinball links.


  1. ^ SSAC 2023.
Rjjiii (talk) 08:40, 23 November 2023 (UTC)Reply Simpler to just do plain text: if the goal of this stuff is just to ensure that the citation line-item begins with the string it is alphabetized by. Which, again, is not a requirement that we have; it's just something a few editors want to have happen for reasons I find non-compelling since it's obvious in an alpha-ordered list of such sources that this one is alphabetized under "SSAC Sports". If this is just for editorial benefit, Mathglot's approach below gets the job done, though would be simpler to type and easier to read as <!--Aron 1962--> than <!--{{sfn|Aron|1962|p=}}-->.  — SMcCandlish ¢ 😼  09:29, 23 November 2023 (UTC)Reply True, and maybe I'm taking ease of use to a fault, but what I want to do is kill two birds with one stone, demonstrating the alphabetization element first, as well as having a copy-paste element readily available that makes use of {{sfn}} as brainless as possible. There are *so* many errors with it (as ActivelyDisinterested can attest), that anything I can do to assure the correct {{sfn}} formulation is used, is a step in the right direction, and worth the (minimal) extra effort in typing out a few more characters. That said, SMcC's (how do you abbreviate a name like that, anyway?) version does the job. Mathglot (talk) 09:43, 23 November 2023 (UTC)Reply Fair enough. I guess the articles I'm shepherding that use one form or another of shortened references haven't had a problem of "drive-by" users making mucked up sfn instances with wrong author names or dates in them, so I'd never had a "show them how to do the citation right" need. PS: Yes, SMcC or S.McC. or S. McC. would be pretty typical. My pool team has two Johns, and we call them John McN. and John P. in texts. If the latter had been Irish, he might have ended up compressed to John O'P. :-)  — SMcCandlish ¢ 😼  09:55, 23 November 2023 (UTC)Reply Just to say there are so many errors with it because it doesn't appear that the error category has ever been cleared down before. New errors are generally caused by inexperienced editors not understanding how referencing should be done. -- LCU ActivelyDisinterested «@» °∆t° 12:07, 23 November 2023 (UTC)Reply

The alphabetization of sources in a "Works cited" or "Bibliography" section is mostly for the user, but has benefits for the editor wishing to expand the article and reuse the citations as well. Unfortunately, it's not always easy to find the "alphabetization item", which might be last1, last, author, surname, editor1-last or something from |ref=, and which might be placed anywhere in the template... tick, tock; .... tick, tock; ... tick, tock; ... Have you found it, yet? I finally got tired of this, and to make it easier for myself on subsequent edits, and for other editors, I hit upon the solution I used in Liberation of France#Works_cited (edit ). It makes it easier for editors, and has no effect on readers. Mathglot (talk) 09:12, 23 November 2023 (UTC)Reply

An easier solution is to include alphabetical breaks <!-- A --> etc. As can be seen in the Bibliography of Historiography of Christianization of the Roman Empire. Any editors can just search the correct string, and it's very simple and easy to understand for new editors. -- LCU ActivelyDisinterested «@» °∆t° 12:12, 23 November 2023 (UTC)Reply @ActivelyDisinterested Naively done as there causes a WP:LISTGAP. Please feel free to correct it as you see fit. Izno (talk) 19:07, 25 November 2023 (UTC)Reply They're not causing LISTGAP at Historiography of Christianization of the Roman Empire, maybe that only applies if you haven't used {{refbegin}}/{{refend}}. -- LCU ActivelyDisinterested «@» °∆t° 19:13, 25 November 2023 (UTC)Reply ActivelyDisinterested, yes, actually, the use there is a LISTGAP problem. A comment on its own line will break the lists, which is what LISTGAP concerns itself with. IznoPublic (talk) 03:10, 26 November 2023 (UTC)Reply Are you suggest that a screen read would want to read through the hundred+ cites in that article as if the where a list? Maybe as a sleep aid. And if they did the list would be sectioned alphabetically. This isn't four items in an infobox. -- LCU ActivelyDisinterested «@» °∆t° 12:14, 26 November 2023 (UTC)Reply @ActivelyDisinterested no, they don't, and that's the problem. What they will hear is "list of N/26 items, would you like to listen?" times 26 as they attempt to come to the end of the section. This is categorically worse for navigation. Moreover, they will have no idea that each is separated by a letter, the only information they get is "list of N/26 items" before diving into each. Izno (talk) 21:41, 26 November 2023 (UTC)Reply

Year parameter

Sometime ago I happened to read in this page that the use of year parameter was discouraged; but now I am unable to find that topic anymore. Do I have to assume that the year parameter is reinstated in full? Thanks. Carlotm (talk) 02:43, 24 November 2023 (UTC)Reply

Nah, use it when appropriate, like when that's all there is, often for books. -- GreenC 04:22, 24 November 2023 (UTC)Reply User:Carlotm, are you sure you're not remembering the thread at Wikipedia talk:Citing sources#Changing the "year" parameter documentation? I mix up that page and this one in my own head with some regularity. Folly Mox (talk) 12:17, 24 November 2023 (UTC)Reply The suggestion is the same as always, use |year= or |date= but not both as it's redundant (with one exception, but that's to much to get into). -- LCU ActivelyDisinterested «@» °∆t° 16:02, 24 November 2023 (UTC)Reply

Thanks to all.Carlotm (talk) 06:33, 25 November 2023 (UTC)Reply

Misspelling parameter

Page: Module:Citation/CS1. When I was worked at adaption some parameters from English Wiki to Ukrainian Wiki, I found out that at the line 2648 in module Citation/CS1: "if (utilities.in_array (config.CitationClass, {'book', 'encyclopaedia'}) and (utilities.is_set (Periodical) or utilities.is_set (ScriptPeriodical) or utilities.is_set (ScriptPeriodical))) then" there is mispelled parameter. Because there are two ScriptPeriodical and they are in if statement, so there in no to double check the same parameter twice. Therefore, I think one of the parameter needs to be changed to TransPeriodical. Repakr (talk) 15:02, 25 November 2023 (UTC)Reply

Just in the nick of time... Yep, you are correct, thank you. I have fixed that in the sandbox: Cite book comparison
Wikitext {{cite book|title=Title|trans-newspaper=Trans Newspaper}}
Live Title. {{cite book}}: |trans-newspaper= ignored (help)
Sandbox Title. {{cite book}}: |trans-newspaper= ignored (help)
Trappist the monk (talk) 15:21, 25 November 2023 (UTC)Reply

Proposed script-author parameter

I'd like to re-raise a proposal that was previously supported at

specifically that the value of |script-author= be rendered in parentheses following the author name, and similarly for other people.

This is particularly important for Chinese and Japanese names, for which the romanized form is lossy. Many editors are adding the original names to other parameters, which messes up the metadata and (if |author= is used) the refname used by the {{harv}}/{{sfn}} family. The solution is to give them somewhere else to put this name so that it will be displayed.

I am not proposing the more elaborate forms suggested here. Kanguole 23:23, 25 November 2023 (UTC)Reply

Outing myself as the editor who recently changed a related style guideline from recommending one wrong way to cite East Asian names (after the not-wrong way, ofc) to recommending a different wrong way.I'd also be glad to see a |script-author= parameter join the other |script-parameter= team. Yes, the use case is different (don't need to worry about italics), but it would keep the metadata clean and allow shortened footnotes to function intuitively without use of |ref= (this applies to only one wrong way of citing East Asian authors).Somewhere down the road, this could also help deal with the #Author roles problem discussed above, which current practice blocks. Lastly, |author-mask= is tedious, and fiddly when more than one author is attributed (since it suppresses commas, ampersands, and "and" between authors).I recognise this is a whole can of cans (superior to a can of worms, which tbh should be stored fresh or dried), because it opens the door not only to |script-editor= but also potentially to |script-author16= and pals. Folly Mox (talk) 00:40, 26 November 2023 (UTC)Reply It's unclear to me whether this is a proposal for usage like 1) |script-author=zh to indicate the language, or 2) |script-author=李四 to provide the name in some other script. If no. 1, I can see this potentially adding utility, if COinS would support metadata to generate indicating the script used for the author name. If no. 2, then I don't see a reason for this when we have |author-mask=.  — SMcCandlish ¢ 😼  08:23, 26 November 2023 (UTC)Reply Any |script-parameter= requires both a language code and a value, separated by a colon, like |script-author=zh:顧愷之. The point (as I see it) is to be able to display the native names without touching the metadata or having to fiddle with |author-mask=, which requires duplicating information as well as sometimes including punctuation, which is difficult to remember. Folly Mox (talk) 09:23, 26 November 2023 (UTC)Reply Ah, I see. I like the idea of not redundantly repeating strings, but it comes at the cost of adding a complicated parameter (actually set of parameters) with two-part syntax, which seems very error-prone to me. Especially if |author-maskn= actually does work fine, just at the cost of some repeated name strings. 06:17, 27 November 2023 (UTC) — SMcCandlish ¢ 😼  Not sure I understand why we need this. If the cited source provides both the native-script name and its transliteration then it seems to me that a concatenation of both can be included: |author=<native> (<transliteration>) or |author=<transliteration> (<native>). Is it common for sources to provide both? If not, then no need for |script-author=. If the majority of ja or zh sources provide names in native and transliterated forms then perhaps there is a need for |script-authorn=. If that is the case, how are we to order the native and transliterated forms in the rendering? Native first? Transliterated first? Which of them contributes to the template's CITEREF id? Only ja and zh or do we also include ko? —Trappist the monk (talk) 15:50, 26 November 2023 (UTC)Reply I would think we'd show Latin-script first, and emit that version in the metadata (both COinS and CITEREF), since this is en.wikipedia. And should probably be script-neutral, since it would be usable for Cyrillic languages, South Asian languages of various scripts, and so on.  — SMcCandlish ¢ 😼  06:17, 27 November 2023 (UTC)Reply "Need" is a strong word. It would be convenient for editors and not much more. I agree with SMcCandlish just above that transliterations would be displayed first, and the only version incorporated into the metadata.While it would certainly be nice to be able to include people's native names in any script (to facilitate learning more about them or finding other publications in their native language), to my knowledge the only scripts that have one-way transliterations into Latin that cannot be reverse engineered are Chinese and Japanese. Some scripts that have various transliteration styles, such as Korean, will present the same name differently depending on the age of the source and possibly other factors.|author-mask= works, and this idea would duplicate the (predominant?) use case that has grown up around it despite its original intent. It does seem cleaner and more intuitive to match the other |script-parameter= parameters for the "people" fields, and would flatten the learning curve a bit, be agnostic between punctuation and author attribution positioning, and reduce duplication of data, which makes it a more attractive best practice.Side bonuses would be the ability to create a maintenance category for parentheticals in people fields, as well as the ability when |script-name=zh: or ja: or ko: is present, to set the default name presentation to last first instead of last, first.I do understand that it would be non-trivial to implement, and isn't strictly necessary since the current system functions, albeit a bit hackily for this sort of information. Folly Mox (talk) 12:30, 27 November 2023 (UTC)Reply I'm a native Anglophone, and I sometimes have to look at the original Hebrew before I can parse a transliterated word. I suspect that transliterations of other Semitic languages are also problematicval -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:37, 27 November 2023 (UTC)Reply On the question of sources, it's not especially common to provide both native and transliterated names in the publication by the author, but it does happen. This is more common in books than journal papers, and mostly confined to the humanities while absent in the sciences. In bibliographies (which is basically what we're doing), the practice seems almost universal in the humanities.The major use case of knowing a person's real name, for me, is to be able to identify them in native language publications. This lets me locate the original source, find out if there's more by them on a subject, check their reputation and affiliation, and see if there's an interwiki article about them if en.wp lacks one.I don't recall ever seeing an English Wikipedia article where Chinese authors are credited solely by their native names, and the practice is already widespread of including both versions where |author-link= has no target.One final point is that this goes both directions, for example Sarah Allan is credited under the transliterated name 艾蘭 when publishing in Chinese language publications, Edward Shaughnessy writes under the name 夏含夷, etc. I'm not aware of any cases of English Wikipedia citing zh / ja language sources by authors who write predominantly in English and other Latin script languages, but we would want to have both versions of the name for these sources as well so they could be located for verification. Folly Mox (talk) 13:10, 27 November 2023 (UTC)Reply This crude search (times out) suggests that editors do write |authorn= parameters using only non-Latin characters. There are lots of results where |authorn= is empty or has languages other than CJK, but still there are plenty of CJK-only author names. This crude search (times out) attempts to find |authorn=<romanized> (<native>). This crude search (times out) attempts to find |authorn=<native> (<romanized>). The latter two searches suggest that editors do not commonly include both native and romanized versions of author names. I asked Is it common for sources to provide both? because somewhere around here there is some instruction that editors should not engage in translation of quoted text. I view romanization of non-English names as a form of translation. In much the same way that |trans-title= should not be used if the source itself does not provide an English translation, so too, if the source itself does not provide a romanization of a native name, editors should not attempt to romanize those native names. —Trappist the monk (talk) 16:00, 27 November 2023 (UTC)Reply Huh I've always followed the guidance at WP:RSUEQ: If you quote a non-English reliable source (whether in the main text or in a footnote), a translation into English should accompany the quote. Translations published by reliable sources are preferred over translations by Wikipedians, but translations by Wikipedians are preferred over machine translations.I consider citing a source as being in the same sphere as quotation, and almost always translate titles if I'm able. Transliteration of Chinese names is usually easy, to the point where most Chinese names could be transliterated by algorithm with very few errors.As an aside, on articles where only native names are used in the bibliography, are shortened footnotes of the form {{sfnp|劉|2010}}? Seems like it might be offputting for our target audience. Folly Mox (talk) 17:15, 27 November 2023 (UTC)Reply But RSUEQ is about inline and block quotations in the article body (or in the |quote= parameter of a citation), which are meant to be read and understood by our readers as prose. But our citations of source titles and authors are not article content in this sort of sense; the only reason we have them is for identifying and finding the sources to verify the content, so there is no need to make up or machine-generate a source title or author title transliteration or translation, since it won't match the actual title/author of the source as published and thus won't help find it, and may even mislead the reader into picking the wrong source that happens to have the same name in English. It is noteworthy that the "Citing" section, right above the "Quoting" section that is the target of the WP:RSUEQ shortcut, does not advise providing translations or transliterations. It is not an accident. As I noted earlier (below) someone might argue that there is still some kind of reader utility in providing such translations or transliterations anyway, but there are counters to this argument.  — SMcCandlish ¢ 😼  23:16, 28 November 2023 (UTC)Reply Wikipedians adding their own personal or tool-generated transliterations and translations for source titles and transliterations for authors probably is not a good idea; it leans toward WP:OR (though I guess it's not technicaly part of the "article content" in the strict sense), is potentially error-prone (or bias-prone, e.g. favoring an old "traditional" transliteration style that is no longer the one typically used), and doesn't do anything to help anyone find the source, which is what the citation is for (it's not to satisfy someone's idle curiosity about what 基 might look like transliterated into Latin text). On the other side of such an argument, there are AI-fuelled translators and transliterators and if they produce pretty consistent results, then a transliteration of an author name and a translation of an article title might actually be pretty accurate. Then a counterpoint to that is it might be downright unhelpful: e.g. the real source is "החיים שלי עם חתולים", which transliterates as "Hachaim shley am alett" which is basically usless, and translates into English as "My life with cats", but Googling around for that English pseudo-title will turn up all sorts of results , probably none of which will be the source cited. And then an argument in the other direction might be that at least the reader would be able to see something about what the source is about, from its title translation, and even editors might be better able to detect when a bogus source has been added, e.g. if the title translates to "Triumphs of the Soviet Space Program" but the article is about the Kievan Rus', there is probably an issue. So, I'm not entirely sure, but still lean toward "don't add your own transliteration or translation of citation details".  — SMcCandlish ¢ 😼  00:00, 28 November 2023 (UTC)Reply I mean, as far as I'm aware, MOS:CHINA has always said If a work is in an East Asian language, the original title should be romanized.... Names of publishing companies or presses are transliterated but not translated.... Sure, if someone only provides a translation of the title, you'll never find it to verify, but the guidance says to transliterate, which is hardly biased or error-prone. I like to provide translations of title in addition to the originals and usually transliterations, because it gives people an idea what the source is about (other than "an editor claims it verifies some content").Seems a little weird that people trust editors to read foreign language sources and summarise their contents, but not to provide a direct translation of the name of a published source (or even transliterate a name? which is like, how do you think we refer to things in article prose when they don't have an article here?).When writing about foreign language topics, editors translate all the time. It's part of the work. Something like translating the name of a source is the same basic level of competency as routine calculation. It's not OR to be able to read a second language. Folly Mox (talk) 00:29, 28 November 2023 (UTC)Reply Oops I shoulda scrolled up from my previous link. WP:TRANSCRIPTION says Faithfully translating sourced material into English, or transcribing spoken words from audio or video sources, is not considered original research. Folly Mox (talk) 00:33, 28 November 2023 (UTC)Reply I'm skeptical that the MOS:CHINA material on this actually represents a broad consensus. I strongly suspect that if an RfC were put up at WP:VPPOL asking "In citations, should source titles and author names in non-Latin script be transliterated by editors into the Latin alphabet (or translated into English) when the publication itself only provides the name(s) in the original non-Latin script and non-English language?" the answer would be "No (and no)", because it does not help the reader find the source, which is what citations are for. Aside from the uncommon |quote= parameter, our citations are not "content" in the usual sense, but serve a specific purpose. An argument can be made that the publication company being transliterated does help evaluate the source, since we (or someone else) may have information about the publisher that could help in evaluating reputability, especially when it comes to things like distingishing between a university or general book publisher versus a govermental organ or a game company that published the game our article is about, for example. I honestly don't really feel all that strongly about it, but I suspect that other editors do, and this is actually worth putting to a broad RfC audience somewhere like VPPOL.  — SMcCandlish ¢ 😼  23:16, 28 November 2023 (UTC)Reply I suspect the guidance is misaligned as well, but not in the same way. I suspect people would prefer, for titles, native and translations, with no transliterations. Transliterations of titles is common in academic publishing for some reason (possibly grandfathered in due to inability to print 漢字 until like the nineties), but adds nothing for the reader, except when both: accompanied by the native title, and the reader is a student of the language and doesn't know how to pronounce things.I know for me personally, when I see a citation in a script I can't read, it's deeply comforting to have the transliteration of the names and translation of the title. This doesn't assist in verification, but it gives me some idea, in my brain, who is being cited and what the work is about, in a broad sense. Folly Mox (talk) 19:06, 29 November 2023 (UTC)Reply But that's a personal whim you can satisfy in seconds of your own time using Google Translate. It doesn't "translate", if I may pun, into a need for Wikipedia editors do this work for you, in untold thousands of citations. I encounter Chinese, Russian, etc., citations all the time and am not perturbed by them. If I want to know what the title "宇多田ヒカル、11年ぶりシングルCD発売決定 Skrillexと『キングダムハーツIII』OP制作" translates to, I can take a few seconds to paste it into Google Translate.  — SMcCandlish ¢ 😼  08:04, 1 December 2023 (UTC)Reply Wikipedians should absolutely add both transliterations and translations of foreign text. This is an English encyclopedia and we don't expect readers to be able to handle random snippets of Urdu, Ancient Greek, Nahuatl, and Swahili interspersed with the English. –jacobolus (t) 17:30, 29 November 2023 (UTC)Reply Examples from Lexell's theorem: Schubert, Friedrich Theodor (1789) , "Problematis cuiusdam sphaerici solutio" , Nova Acta Academiae Scientiarum Imperialis Petropolitanae (in Latin), 4: 89–94 Shvartsman, Osip Vladimirovich (2007), "Kommentariy k stat'ye P. V. Bibikova i I. V. Tkachenko 'O trisektsii i bisektsii treugol'nika na ploskosti Lobachevskogo'" Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского» (PDF), Matematicheskoe Prosveschenie, ser. 3 (in Russian), 11: 127–130 Steiner, Jakob (1827), "Verwandlung und Theilung sphärischer Figuren durch Construction" , Journal für die reine und angewandte Mathematik (in German), 2 (1): 45–63, doi:10.1515/crll.1827.2.45, EuDML 183090 Chasles, Michel (1837), Aperçu historique sur l'origine et le développment des méthodes en géométrie (in French), Brussels: Hayez, Ch. 5, §§ 42–45, "Géométrie de la sphère" , pp. 235–240 Of course where available it's nice to use someone else's translation, e.g.: Lexell, Anders Johan (1784) , "Solutio problematis geometrici ex doctrina sphaericorum", Acta Academiae Scientarum Imperialis Petropolitinae (in Latin), 5: 1781 (1): 112–126, figures tab. 4, translated as "Solution of a geometrical problem from the theory of the sphere" (PDF),, translated by Stén, Johan Carl-Erik, 2009 –jacobolus (t) 17:42, 29 November 2023 (UTC)Reply Well, just expressing "absolutely should" without providing a rationale other than a tautological observation of what site this is, and providing some examples of you writing citations the way you like to write citations, isn't very convincing. :-) I'm dead certain that if this question is put to an RfC, as I suggested above, that the input will be broad in its responses. I'm skeptical there would be much support for doing this, except in cases where off-site sources provide them and they help actually find the citation. Transliterations are generally meaningless to much of anyone (except when commonly used in RS for the same referent), and translations are unlikely to help find a verify the source (except when it's also been published in an English version, in which case we should be citing that instead).  — SMcCandlish ¢ 😼  14:28, 30 November 2023 (UTC)Reply The rationale is that readers of English text are not expected to know what "verwandlung und theilung", "cuiusdam", "aperçu", or "трисекции и бисекции треугольника на плоскости Лобачевского" mean (and it's even harder to puzzle out if the text is written in Marathi or Cantonese). These labels are often treated by English readers are opaque or even unrecognizable symbols without internal meaning. If not only the title but also the author name, publication name, etc. are in a non-Latin script, then the whole thing just becomes a blob of meaningless scribbles. This makes it impossible for readers to evaluate what the source is about, what it has to do with the content of the article, whether/why it is important, whether they have seen it mentioned before, whether it's worth trying to find a copy of to examine (or e.g. get a machine translation of), and so on. I don't really care about a transliterated title if we have a script title and a translation, but let's compare with/without a transliterated author name/journal and translated title: Шварцман, Осип Владимирович (2007), Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского», Математическое Просвещение, Третья серия (in Russian), 11: 127–130 Shvartsman, Osip Vladimirovich (2007), Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского» , Matematicheskoe Prosveschenie, ser. 3 (in Russian), 11: 127–130 A recognizable author name and a legible title are the two single most important elements to include in a citation. The rest can be convenient but is mostly dispensable (motivated readers can find it if they need). –jacobolus (t) 15:24, 30 November 2023 (UTC)Reply But there is no point in "recognizing" that Шварцман transliterates to Shvartsman if this does not help the reader find the source. If the source is only available in Russian, then the strings to search for to find it are literally "Шварцман" and "Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского»" (, very first search hit, link toward bottom of short resulting page, then click the PDF button on the next page; took just a few seconds). If the source does exist in English then we should be citing that instead. Meanwhile, the translated strings "Shvartsman" and "Commentary on the article by P. V. Bibikov and I. V. Tkachenko 'On trisection and bisection of a triangle on the Lobachevsky plane'" don't help find the source at all (wild goose chase). Our citations do not exist to satisfy curiosity about how Cyrillic strings transliterate or translate into Latin script or English language, only to help the reader find the citation and verify the content. Any reader that cannot read the Cyrillic in the citation cannot read the Cyrillic in the source book/article, either, so cannot verify the citation and has to rely on someone else to do that work, so is not harmed by a transliteration not being provided. Meanwhile, the reader who is competent to read that material does not need that extra stuff. Any reader who is just really curious what a particular cited work's title translates to can just copy-paste it into Google Translate or an equivalent tool. It's not really the job of our templates and our editors to do that make-work for them, since it doesn't help with verifying our content. I used to think about this the way you do, and went to pains at articles like Utada Hikaru to provide translations of work titles, and it was a lot of work, but in the end it simply doesn't help anyone verify the content, and it just adds a lot of code bloat and a lot of visual cite bloat for the reader, without actually providing utility to them.  — SMcCandlish ¢ 😼  07:44, 1 December 2023 (UTC)Reply Transliterations are often provided and utilized haphazardly in journals and the like, providing a transliteration is rather likely to increase one's search results on a given individual. — Remsense 07:54, 1 December 2023 (UTC)Reply Perhaps for names of people, and when dealing with languages/scripts that have a consistent transliteration system. But several do not, and translations of titles aren't going to match someone else's translation, except in the simplest cases (which will also, in being so simple, have lots of false-positives in English anwyay, so still not a help in finding the source). I can maybe concede that transliteration of author/editor names could be of some use, for the same reason as with publisher names: doing some background research of one's own to get a sense of reputability. PS: I added some example search stuff, and so on, to my previous post just above this but edit conflicted with you.  — SMcCandlish ¢ 😼  08:10, 1 December 2023 (UTC)Reply only to help the reader find the citation and verify the content – to first approximation, precisely zero readers care about "verifying the content". What readers care about is making sense of the subject. For readers who speak English and have no experience with Russian or related languages, the Cyrillic alphabet is entirely nonsensical, and barfing blobs of Cyrillic at readers is unhelpful and snobbish. Anyone can click the hyperlink to find the paper in Russian (and if they don't read Russian but want to make sense of it, as I did, they can OCR the image-based PDF and then machine translate the resulting text so they can understand the proof contained in the paper and cited by the article). But as for your point about web searches, Osip Shvartsman returns a wide variety of relevant results in English. Осип Шварцман does not. Edit to add: The #1 result in your "wild goose chase" search is a highly relevant paper in English (translated from Russian) which cites the paper in question ("O. V. Shvartsman. Comment on the article by p. v. bibikov and i. v. tkachenko. Matematicheskoe Prosveschenie. Tret’ya Seriya., (11):127–130, 2007.") and the paper it was responding to ("P. V. Bibikov and I. V. Tkachenko. On trisection and bisection of a triangle in the hyperbolic plane. Matematicheskoe Prosveschenie. Tret’ya Seriya., (11):113–126, 2007."), probably the single most relevant possible English language search result. Good job Google! –jacobolus (t) 08:19, 1 December 2023 (UTC)Reply That view is completely inconsistent with our verifiability policy, which is crystal clear that our material is sourced with citations so that readers can verify it. The average reader is not going to do this, and they "make sense of the subject" by reading the article content that interests them, not by looking at citations. Most of our readers never look at any of the citations. The ones who do are mostly students, journalists, people experienced in the topic, and those intensely interested in the topic and being certain about the facts, and these are the people our citations are for. They are the people who go find the cited source (at least when easily available) and see what it says. But ultimately we all know by know that that primary (by orders of magnitude) actual users of our source are other editors doing V and OR checking work to make sure our article are not full of nonsense. All of these classes of users, however, are going to be using the citations the same way: to find the source and see that it backs up the content we cite to it. "Anyone can click the hyperlink to find the paper in Russian", sure when it's an online source that is not paywalled, but many source are not, and we provided all the source info we have that is helpful in finding the source (not in learning other factoids about the source that are not necessary for finding it) because we cannot guarantee that an online one will be online indefinitely, and we also have WP:RESUSE to consider, from programmatic repurposing of WP content to just users print out articles on paper, where links don't work. WP:NOT#DATABASE, including a bibliographic one. There are all sorts of details about a source that we could include but do not, such as how many total pages it has, whether is a paperback or a hardback, who illustated the cover, etc., etc., etc. We don't include it because it doesn't help find the source."a highly relevant paper in English (translated from Russian) which cites the paper in question" is irrelevant. ]. We are not citing some other paper that mentions the paper we are citing, we are citing the paper we are citing. That is the purpose the citation serves, to find that source. That doing something else might be entirely accidentally "interesting" for someone in some way is a moot point. We could make all our citations vaguely interesting and useful, in an off-topic sense for citations, in a myriad of ways (e.g. including images of book covers, linking directly to shopping sites to buy them, providing word-count and reading-level analyses of them, connecting author names to databases instead of WP articles, linking to book reviews as adjunct information, and so on), but we do not because it's not the point of the citation or of Wikipedia.  — SMcCandlish ¢ 😼  11:11, 1 December 2023 (UTC)Reply This discussion has already digressed pretty far from "should we have a |script-author= parameter to match the others instead of relying on |author-mask= hacks?", but I agree with jacobolus and Remsense here, while noting that the previous time this talkpage hosted a digression into the philosophical argument of "what citations are for" versus "how citations are used", (in the "Do we need |access-date ?" thread still live above), several of the protagonists came down on opposite sides to where we find ourselves this time round. Folly Mox (talk) 11:35, 1 December 2023 (UTC)Reply The example of transliterating החיים שלי עם חתולים as Hachaim shley am alett is useless not because it is a transliteration, but because it is not a correct transliteration. "Hachaim Sheli Im Chatulim" would be more helpful, although there are some dialect differences, especially for the consonants ח (Chet) and ע (Ayin). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:38, 30 November 2023 (UTC)Reply Re: "an English Wikipedia article where Chinese authors are credited solely by their native names" – I've run into this many times for both Chinese and Japanese, and it's almost always a non-English news/web source. So, maybe not something we encounter in journals, but for looser types of sourcing, it's pretty common (but also applies to South Asian languages, Cyrillic ones, Hebrew, Korean, and so on).  — SMcCandlish ¢ 😼  23:38, 27 November 2023 (UTC)Reply Oh right, of course people cite only native names when they're using a referencing script to handle all the work for them. I'm not sure why I didn't think of that. Folly Mox (talk) 01:03, 28 November 2023 (UTC)Reply I would like to endorse the proposal for the reasons Kanguole and Folly have already stated: as someone who spends a lot of time wrangling citations involving the Sinosphere, a new feature like this, consistent with those already existing in the CS1 template is very near the top of my wiki-wishlist. Remsense 01:27, 30 November 2023 (UTC)Reply

Date format for CITEREF

Hello! Need help again. In the Russian Wikipedia, we replace all dates with the ISO format (we display them in a human-readable way in the desired language through another module) so that those who copy articles and sources from us do not have to fool around with unreadable and unprocessable dates (English, Russian, Spanish or any other). But I now noticed that CITEREF cannot take the year from such a date (YYYY-MM-DD). It can be fixed? :) Iniquity (talk) 16:21, 27 November 2023 (UTC)Reply

Umm, not true: {{cite book |title=Title |last=Green |first=EB |date=2023-11-27}} Green, EB (2023-11-27). Title. '"`UNIQ--templatestyles-000000E9-QINU`"'<cite id="CITEREFGreen2023" class="citation book cs1">Green, EB (2023-11-27). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&" class="Z3988"></span> Show me an example of a cs1|2 template at that does not correctly include the year portion of |date= in the template's id= attribute. —Trappist the monk (talk) 16:34, 27 November 2023 (UTC)Reply Oh, thanks for the example. This turns out to be an error that the module does not support YYYY-MM. It seemed to me that the module supported the whole ISO :( Iniquity (talk) 16:41, 27 November 2023 (UTC)Reply This is not an error. The issue is that, at least in English, YYYY-MM can be ambiguous with YYYY-YY, indicating a range. Izno (talk) 16:59, 27 November 2023 (UTC)Reply Yes, I remembered that old discussion, thanks! I'll have to fix this locally somehow :( Iniquity (talk) 17:01, 27 November 2023 (UTC)Reply I have fixed YYYY-MM DATE for ruwiki, can you check plz, is it right way? :) Iniquity (talk) 21:35, 28 November 2023 (UTC)Reply Looks like the change is probably correct. You've tested your code, right? You might want to fix the comment at line 505 (remove reference to 'day'). —Trappist the monk (talk) 22:59, 28 November 2023 (UTC)Reply Thank you very much for checking! I will fix it :) Iniquity (talk) 01:42, 30 November 2023 (UTC)Reply

Maintenance category for redundant links

I've seen that people make good use of Category:CS1 maint: PMC format. It would be nice to have a maintenance category for citations which contain a PMC ID but also a link from the url parameter: such links are often subject to link rot and need updating or removing. This could later be extended to other green OA IDs if they auto-link. Nemo 07:08, 28 November 2023 (UTC)Reply

New CS1 error for "Cite journal"

{{Cite journal}} now shows a Cs1 error wherever a source is templated according to it but does not actually cite a journal title. Can this be fixed by editing the template or fixed en masse by a bot in all use cases? Æo (talk) 17:53, 28 November 2023 (UTC)Reply

No, a bot is not able to fix all of these cases. There may be some groups with similar patterns that can be fixed by editors using AWB. The help text explains how to fix each erroneous template transclusion. – Jonesey95 (talk) 18:42, 28 November 2023 (UTC)Reply

Aliase for 'Author'

Hello! I need to set an alias for the "author" parameter, but adding = 'автор', to the configuration not works. Iniquity (talk) 21:38, 28 November 2023 (UTC)Reply

In ~/Configuration, remove = 'автор' and add 'автор#' to = {...} (at about line 390). In ~/Whitelist, add = true to local limited_basic_arguments_t = {...}. Then add = true to local numbered_arguments_t = {...} and to local limited_numbered_arguments_t = {...} —Trappist the monk (talk) 23:16, 28 November 2023 (UTC)Reply Thanks a lot! :) Iniquity (talk) 01:42, 30 November 2023 (UTC)Reply

Redundant listings in Category:CS1 maint: unflagged free DOI

Nice tracking category! However, this currently comes up with citations which do not need doi-access=free because they already have an auto-linking PMC identifier (example). That makes it harder to find citations which would actually benefit from being turned green. Nemo 10:57, 30 November 2023 (UTC)Reply

|pmc= and |doi= point to different sources. |pmc= defaults to free-to-read; |doi= does not. |pmc='s free-to-read-ness does not apply to |doi=. Readers who would prefer to read the |doi= source are entitled to know if that source is free-to-read. All identifiers that are free-to-read should be marked with |<identifier>-access=free. I don't know what you mean by That makes it harder to find citations which would actually benefit from being turned green. —Trappist the monk (talk) 14:46, 30 November 2023 (UTC)Reply I mean that adding OA identifiers is most useful on citations which don't already have one. Once you have a PMC ID, the marginal utility of a doi-access=free parameter is significantly reduced. Nemo 15:06, 30 November 2023 (UTC)Reply cs1|2 does not support Open Access (OA) because open access implies that the source may be reused in some form or other. As far as cs1|2 is concerned, a source is free-to-read or it lies behind some sort of paywall or registration barrier. The free-to-read icon attached to a PMC identifier conveys no useful information about the paywall/registration/free-to-read status of the source pointed to by |doi= or any other identifier parameter. In fact, the omission of a free-to-read icon for |doi= when |pmc= has a value implies that the source pointed to by |doi= lies behind a paywall or registration barrier. —Trappist the monk (talk) 15:20, 30 November 2023 (UTC)Reply Alright, can we have a maintenance category for citations which don't have an OA identifier aka "free-to-read icon" then? Nemo 16:31, 30 November 2023 (UTC)Reply I guess I'm not sure how useful that would be. The cs1|2 module suite is used on more than 5.6 million articles so a list of all articles with cs1|2 templates that have identifiers but don't have a matching |<identifier>-access=free could number a million or more. It seems likely that many of those should never have a |<identifier>-access=free so those articles would live in the new category forever. How is that useful? —Trappist the monk (talk) 20:59, 30 November 2023 (UTC)Reply

Allow setting doi-access to registration or limited

It has come to my attention that some people have been using doi-access=free in citations for works which are not open access but which occasionally offer some gratis access method, such as an intermittent bronze OA (non-libre gratis OA) status or the possibility for some people to register or go through other authentication walls, without payment, to access the full text. Such use is clearly contrary to the documented definition of "free", which says "free to read for anyone" (emphasis added), and which is distinct from the value "registration" for the case where "a free registration with the provider is required".

However, I have sympathy for the argument that there's been some confusion so far, and that the absence of doi-access=free is sometimes misinterpreted as a positive statement of something it's not. The easiest way out would be to allow adding doi-access=limited and doi-access=registration as we do for url-access. That would allow users to manually set this value to indicate the gray area situations. It would also allow us to finally default a blank doi-access to mean "subscription", and to show the red lock by default. Nemo 11:20, 30 November 2023 (UTC)Reply

I could see adding |doi-access=registration as a valid access indicator (and I think this might help with some of OAbot's unaddressed misbehavior), but |doi-access=subscription is like |url-access=free. I would not want to see bots adding zillions of understood default access indicators, or their associated lock icons in reference lists, which would be the outcome of enabling the specification of the default value. Folly Mox (talk) 11:56, 30 November 2023 (UTC)Reply Good point, I mixed up. I meant it should be possible to explicitly set it to registration or limited, while "subscription" would be the default (still considered an error if added explicitly, as it is now). Nemo 11:59, 30 November 2023 (UTC)Reply The case I highlighted which started the discussion referred to by Nemo is doi:10.1001/jama.2009.405. There seems to be a difference of opinion whether this can be described as doi-access=free. My interpretation is that this source is indeed compliant: the webpage that is the target of the doi has the full text and that text can be downloaded by simple copy-paste, if the reader so desires. (To download a .pdf a user must provide their email address.) I don't see this as a grey area: citations are there in Wikipedia articles so that readers can verify that the source supports the text and using doi-access=free makes the title of the work a direct link to the place that the text is hosted and can be read by anyone. Mike Turnbull (talk) 12:03, 30 November 2023 (UTC)Reply To avoid more important work, I verified that the full article and all figures and tables present in the PDF are duplicated on the webpage. The only content lost is the page numbers. I think I'd characterise this as "free to read for anyone" and hence a poor example, but the problem described may actually exist: dois that offer only a preview for all viewers, but access to the full source for non-pay-for registered accounts. Folly Mox (talk) 12:33, 30 November 2023 (UTC)Reply

Category:CS1: Julian–Gregorian uncertainty

Hello 🙂 I was wondering how you would go about removing an article from the hidden category above. There are over 100,000 pages tagged with this category, and at least to me, it's a little unclear how to fix this. I also see that this might be a temporary category, so, is there still a need for this, or can it be deleted? Kind of a two parted question, but I hope you understand. Cheers! Johnson524 15:39, 30 November 2023 (UTC)Reply

You shouldn't bother; that category is a properties category not a maintenance or error category. It exists merely for the information it might contain. Here is some history: Help talk:Citation Style 1/Archive 39 § metadata dates rfc Help talk:Citation Style 1/Archive 41 § CS1: Julian–Gregorian uncertainty Help talk:Citation Style 1/Archive 54 § Julian and Gregorian dates Help talk:Citation Style 1/Archive 56 § Julian Gregorian uncertainty Help talk:Citation Style 1/Archive 88 § Julian vs. Gregorian Apparently no one cares about this anymore since those who do or did have never said anything here about it. That being the case, I'm going to remove the code that categorizes articles into Category:CS1: Julian–Gregorian uncertainty. —Trappist the monk (talk) 18:40, 30 November 2023 (UTC)Reply Sounds good, thanks for checking up on this 👍 I'll be sure to take a look at those history links, cheers! Johnson524 18:46, 30 November 2023 (UTC)Reply Categorization gone from the sandboxen. You can test in mainspace (because property cats do not include pages in the Help namespace) with this: {{cite book/new |title=Title |date=1 June 1815}} —Trappist the monk (talk) 20:22, 30 November 2023 (UTC)Reply