Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

Request to expand checks for bad URLs

Could you please consider expanding the checks for bad URLs to also catch hhttp and hhttps? I stumbled across one of these today, and was surprised it didn't have an error message.

{{cite web |title=Title |url=http://foobar.com |website=Good example}}

"Title". Good example.

{{cite web |title=Title |url=http//foobar.com |website=Error displays}}

[http//foobar.com "Title"]. Error displays. {{cite web}}: Check |url= value (help)

{{cite web |title=Title |url=hhttp://foobar.com |website=No error displayed}}

[hhttp://foobar.com "Title"]. No error displayed.

If you were to do add these so they are included in Category:CS1 errors: URL, I'll periodically run my bot to fix them. Thanks! GoingBatty (talk) 00:17, 23 September 2023 (UTC)

60 uses. Izno (talk) 16:57, 25 September 2023 (UTC)

Also this:

• insource:"%7" insource:/%7[Cc](%20)*(url|archive|title|access|work|website|last|first|author|date|quote|publisher|isbn|editor|agency|location|page|language|trans|type|format|doi|jstor|)/] (697)

Not all are errors, most are. This is for Cite Web. There are still some arguments missing, I didn't want to overload regex search. -- GreenC 18:33, 25 September 2023 (UTC)

Oh no! What process causes | to be escaped as %7c? Folly Mox (talk) 06:12, 28 September 2023 (UTC)

Automated editing that doesn't parse things correctly which can be a GIGO situation [input], tool bug [output], or some series of both. If someone wanted to try and determine a prolific culprit it would be helpful, assuming they exist and it hasn't been fixed yet. But I think this sort of thing is par for the course and new ones will keep showing up indefinitely. -- GreenC 07:36, 28 September 2023 (UTC)

Well, it seems like a common-ish and easy to detect case. Same with the copy-paste errors "ttps://" and "ttp://". Maybe, though, it would make more sense to have a list of URL prefix strings that are legit, and flag anything that doesn't match, instead of targeting specific things that match a list of non-valids. That is, go with a whitelist instead of a blacklist.  — SMcCandlish ☏ ¢ 😼  08:39, 28 October 2023 (UTC)

|url-status=

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:

• url-status: A control parameter to select one of |url= or |archive-url= to link |title=; requires url and archive-url. Use {{dead link}} to mark dead |url= when there is no |archive-url=.

  Accepts multiple keywords:

  • dead – (default when |url-status= omitted or empty) selects |archive-url=
  • live – selects |url=; used when |url= is preemptively archived
  • deviated – selects |archive-url=; used when |url= is still 'live' but no-longer supports the text in a Wikipedia article
  • unfit – selects |archive-url=; used when |url= links to porn, spam, advertising, or other unsuitable sites; links to |url= are suppressed in the rendering
  • usurped – selects |archive-url=; used when |url= links to information unrelated to the original link; links to |url= are suppressed in the rendering

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.

Opinions?

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

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)

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)

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)

Per Mike at Citation bot talk, archiveurl should not be required. Nikkimaria (talk) 03:11, 30 September 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 10:23, 30 September 2023 (UTC)

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

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 12:23, 30 September 2023 (UTC)

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 philsp.com, 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)

Any fix would be to stop it's misuse, but as I said renaming the parameter at this point is unlikely. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:13, 30 September 2023 (UTC)

I have updated the documentation.

—Trappist the monk (talk) 13:19, 7 October 2023 (UTC)

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)

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)

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)

Done with a bit of copy editing: diff.

—Trappist the monk (talk) 16:30, 7 October 2023 (UTC)

Thank you. Some more changes. -- GreenC 03:16, 8 October 2023 (UTC)

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:

• live – selects |url= and shows link to |archive-url=; used when |url= is pre-emptively archived with |archive-url=
• dead and deviated – (default condition when |url-status= omitted or empty) select |archive-url= and show link to |url=. dead is used as an indication to editors when a link no longer exists, and deviated when |url= is still 'live' but no-longer supports the article text.
• unfit and usurped – select |archive-url= and do not link to |url=. unfit is used for a |url= that now links to porn, spam, advertising, or other unsuitable sites.usurped is used when |url= links to information unrelated to the original link

Best wishes, Pol098 (talk) 12:29, 8 October 2023 (UTC)

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)

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 archive.today 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 archive.today until I found that Wayback only saved versions with the paywall. Thanks for all you do! KarenJoyce (talk) 02:24, 26 November 2023 (UTC)

The {{cbignore}} was added by User:Frabrikator Special:Diff/1001248446/1001281991. Possibly IABot at the time was occasionally converting archive.today links to Wayback due to a bug now fixed - it no longer does that. I removed it. -- GreenC 02:41, 26 November 2023 (UTC)

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)

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)

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)

"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 term —DocWatson42 (talk) 12:14, 24 October 2023 (UTC)

You need to change |title= to |entry=
{{Cite encyclopedia |last=Horsburgh |first=James |year=1836 |entry=Fernando de Noronha |entry-url=https://archive.org/details/bub_gb_GuY2AQAAMAAJ/page/31/mode/1up |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=https://archive.org/details/bub_gb_GuY2AQAAMAAJ/mode/1up |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 ActivelyDisinterested ∆transmissions∆ °co-ords° 12:25, 24 October 2023 (UTC)

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)

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)

You realize this will just cause people to abuse |author= to list multiple authors, right? —David Eppstein (talk) 14:48, 24 October 2023 (UTC)

What is the consequence of a deprecated parameter? eg. it works but displays a warning message? -- GreenC 14:55, 24 October 2023 (UTC)

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)

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)

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}}: Unknown parameter |authors= ignored (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)

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:

• |contributors= never supported
• |editors= deprecated at this edit; unsupported at this edit
• |interviewers= replaced |cointerviewers= at this edit; unsupported at this edit
• |translators= never supported

—Trappist the monk (talk) 16:32, 24 October 2023 (UTC)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 17:58, 24 October 2023 (UTC)

Agree with David: the proposal is not an improvement. I have reverted the documentation change. Nikkimaria (talk) 18:33, 24 October 2023 (UTC)

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)

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)

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)

Since I began replacing |authors= the only 'complaints' were related to these articles:

• Battle of the Hatpins
• Christine Egan
• Francis Godon
• Phoenix Sinclair
• The Forks, Winnipeg

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)

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)

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)

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)

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)

"an alternative easy / freeform mode for editors who don't want to type editor7-last" Don't the vcite templates already offer this? Rjjⁱⁱⁱ (talk) 06:34, 25 October 2023 (UTC)

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)

There's also |vauthors= which does the same as authors, but in an established style. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:50, 25 October 2023 (UTC)

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)

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)

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)

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)

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 $rft.au 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 13:49, 25 October 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 17:12, 25 October 2023 (UTC)

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)

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)

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)

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)

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)

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. [Maybe with the exception of |vauthors=, though I think that should be deprecated too, since Vancouver style conflicts with other guidance like MOS:INITIALS, and produces confusing output in many cases, e.g. where jammed-together initials coincide with conventional biographical acronyms like MD. Even if we keep |vauthors=, it should be replaced with first/last params in any article that is not consistently using Vancouver style; normalize to a consistent citation style per WP:CITEVAR, and normalize to the more sensible one used by 99+% of our editors.] 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)

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

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)

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)

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)

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)

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,

• "use of this parameter used to be discouraged at some point, but we thought better of it, so we've struck it out, and it is no longer discouraged."

Combined with the lead-off "deprecated" term, that appears to be self-contradictory. Mathglot (talk) 02:01, 23 November 2023 (UTC)

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)

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)

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

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

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

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

@Srich32977: Glad we agree! How about this edit? GoingBatty (talk) 01:54, 27 October 2023 (UTC)

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

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

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)

@Srich32977: Coding... GoingBatty (talk) 02:27, 12 November 2023 (UTC)

@Srich32977 BRFA filed GoingBatty (talk) 04:21, 12 November 2023 (UTC)

What to do with non-free URLs that go dead

Meaning well, GoingBatty made this tweak to the docs [1], 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:

• The URL is no longer of any direct use.
• |url-access=[registration/limited/subscription] will no longer be true.
• |url-status=dead will need to be added.
• |archive-url= and |archive-date= will almost never be applicable, because the material was paywalled away from the archiver bots.

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=[whatever], 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)

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)

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

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 15:35, 27 October 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 11:08, 28 October 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 11:51, 28 October 2023 (UTC)

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)

Abuse of the "last"/"author" parameter for last-first name pairs

|last= and its alias |author= are not for full lastname-firstname[s] sets. They are the last name (surname, family name), or can be used for an organizational editor (e.g. a committee), or a mononymic author (like Madonna or James I). Putting full "First Last" or "Last, First" human name sets in there is directly polluting (blatantly lying about) the nature of the data in the parameter, and undermines the whole point of providing COinS metadata in the first place. (In particular, we are emitting rft.aulast metadata for this parameter, which claims that the data in the parameter is the author's last name. When the author only has one name, being mononymic or an organizational entity, this is not misleading, but when it's somethinge like "Chen, Jaime C." it is a patent falsehood, for no defensible reason, and it harms WP:REUSE of our material as well as parsing, e.g. by bibliographic software, by our more technically/academically inclined readers.)

What we have now in Template:Citation Style documentation/author is:

author: this parameter is used to hold the complete name of a single author (first and last) or to hold the name of a corporate author. This parameter should never hold the names of more than one author.

I sensibly changed this to:

author: this parameter is used to hold the complete name of an organizational author (e.g. a committee). This parameter should never hold the names of more than one author. Use to hold first and last names of an individual author is deprecated.

But I got reverted by Nikkimaria. (Reglardless of the rest of this discussion, "corporate" should be changed, since this doesn't have anything to do with corporations in particular, and people keep mistaking this for an instruction to repeat the |publisher= as the |author=, or even put the company name in |author= instead of in |publisher=, both of which practices are obviously incorrect; I've had a to fix about a dozen instances of this stuff today alone).

I think this change (or functionally equivalent wording) should be put back in, because it actually reflects best practices, both in theory and in action. The parameters is this template are for rather specialized/specific purposes, and abusing them (out of, frankly, laziness about using multiple parameters properly) does harm to the data they emit, makes for confusing markup for editors, does nothing whatsoever to help readers, and is simply not how these templates in practice are used by the vast majority of our editors. For over a decade, I have been correcting such misuses of these template parameters for full human names. I've done this many thousands of instances (mostly very old ones dating from before the templates were so well-developed, and in some cases injected by tools that have since been re-coded to do better markup, though there is a small handful of editors who manually keep abusing the template parameters out of bad habit), and I've never been reverted on one these corrections, ever, even once. It's time that the documentation made better sense, and stopped including misguiding wording that results in a massive waste of editorial cleanup time.

I have faith that this can be accomplished, since we've made substantial progress already on the confusion between |publisher= and |work= (or its aliases like |website=, |newspaper=, |magazine=, etc.). Mike Novikoff and I tried to resolve that issue back in May of last year only to be reverted by Nikkimaria again, but the wording of the |publisher= entry at Template:Citation Style documentation/publisher today now does in fact address the issue very clearly, and I don't see anything at entries like |website= in Template:Citation Style documentation/web, or |work= at Template:Citation Style documentation/work, that any longer work against this clarity. If we can fix that problem, we can fix this one, too.
 — SMcCandlish ☏ ¢ 😼  01:30, 26 October 2023 (UTC)

I'm not doing that. If I'm fixing up citations with no author attributed at all, copypasting author names from dozens of websites over and over, of course I'm not going to take the wholly unnecessary step of editing each into |first= |last= format. There are probably five orders of magnitude of citations using |author= to hold the name of an author. Folly Mox (talk) 01:35, 26 October 2023 (UTC)

When you're copy-pasting author names, I have found it's much easier to let Parsoid or another of our current tools to have a first go at things. They're not perfect, but they can reduce the tediousness sometimes of getting good first/last pairs. Izno (talk) 03:21, 28 October 2023 (UTC)

And how is it parameter abuse to use the |author= parameter to hold the name of an author? That's silly. Folly Mox (talk) 01:45, 26 October 2023 (UTC)

I agree that this should have been reverted. Your assertion at are not for full lastname-firstname[s] sets has for a long time been false. And, the text deprecated has a specific meaning in CS1 (that I think you have been educated on elsewhere?).

But I do think there is room to move this one liner more toward the actual status, which is that we very much prefer to use |first= and |last= for persons and that |author= is generally discouraged. I feel comfortable saying the former, so let's at least say that. I also agree that this should refer to organizational authors instead, and that an example is probably merited. Here is a shot:

author: this parameter is used to hold the complete name of a single author (first and last) or to hold the name of an organizational corporate author (e.g. a committee). For a person, you should prefer to use |last= and |first=. This parameter should never hold the names of more than one author.

I do not know how I feel about saying the parameter is discouraged. It has valid use for the organization case as you recognize, and it has valid use for gnomes who are working through categories like Category:CS1 maint: multiple names: authors list which from my perspective cannot be easily dealt with by saying "you must correct these to use first|last only". And lastly, I doubt discouragement is needed if we add the suggested alternative. There are many other trees to bark at than the effort it would take to eliminate all uses of commas in |author= (we could make up a category for that trivially and it would probably be half the wiki), though no doubt small-ly valuable to move a first name from the last name key in the metadata. Izno (talk) 08:58, 27 October 2023 (UTC)

Less snarkily, there are plenty of articles with referencing styles where authors are presented with their names in "first last" order rather than "last, first", and there's no way consensus could be reached to standardise every article to use the "last, first" order. Folly Mox (talk) 11:00, 27 October 2023 (UTC)

I don't think that particular case is one to support above and beyond "here's a parameter for a single author". We should state our preference for using the split parameters and leave it at that. Izno (talk) 19:42, 27 October 2023 (UTC)

Izno's wording is an improvement. I would prefer it even more as something like

author: this parameter is used to hold the complete name of a single organizational author (e.g. a committee). For a person, prefer |last= and |first=. This parameter should never hold the names of more than one author.

As for Folly Mox's "I'm not doing that": We don't need to shape our documentation and templating behavior around a single editor who bucks the flow and refuses to use |last= |first=. Nor do we need to care about some old-time WP:LOCALCONSENSUS at a particular article that somehow insisted on "First Last" name order. In both cases, they can just use untemplated citations or just stubbornly abuse template parameters, and someone will clean it up later in the first case, and consensus will change eventually in the latter case. The idea that some handful of editors deciding many years ago to use a name ordering format that doesn't work properly with our modern templating system means that it can never change is a misunderstanding of how WP:CONSENSUS operates. Consensus changes all the time when given a good reason to do so, and citations that emit proper bibliographic information about author names is a good reason (and there are several others). If we still wanted to enable randomly varying name order on an article-by-article basis, the way to do that would be to add a |name-order=FL parameter and value for First Last name ordering. But the number of articles that are using First Last order consistently and have a declared consensus to do so, and are actively maintained to keep this order, are a vanishingly small number. What is vastly more common is an article in which a few old citations are in that order and all the rest are not; WP:CITEVAR instructs us to normalize them to a single, consistent format. The one to choose is obviously the one that matches our current templating best practices with |last[N]= and |first[N]=. I do it routinely, and no one ever objects, because editors generally recognize the utility of consistent and metadata-rich citations (versus the rather-less-than-utility of picking a fight to retain some unhelpful citation style that was used in the article 13 years ago, which no one has since obeyed anyway when adding new cites that now dwarf those of the old format [i.e. the alleged consensus for First Last is not real], and which no one actually cares to retain).  — SMcCandlish ☏ ¢ 😼  01:12, 28 October 2023 (UTC)

Yes, this suggestion returns us to what you want to do, which is to remove the documentation that allows its use for a single person. That isn't going to get consensus for a whole variety of reasons already documented in this section (and touching on reasons documented in others on this page right now). That's why I suggested the "prefer" language while retaining the majority of the previous structure ("use for a person or for an organizational author; for a person, prefer first/last"), which I think does move the documentation closer to current consensus understanding of the parameters, for the benefits described related to use of first/last, namely style consistency and slightly better metadata output (instead of both first and last landing in the last key, the first name ends up in the first key). (NB, |authors= emits no metadata.) Izno (talk) 03:19, 28 October 2023 (UTC)

As I said, your version is an improvement, and I can live with it. In the long run (maybe years), I think it's ultimately going to reflect the narrow change I proposed. The tiny walled garden of regulars on this page do not represent site-wide consensus, which is reflected primarily in how our citations are used by the majority of experienced editors today. To the extent that a very small number of them continue to do unhelpful things like |author=McNab, Janet S. they are doing it primarily out of a combination of confusion induced by the current poor state of the documentation itself, laziness about using multiple parameters, and dependence on scripts and other tools that are obsolete and doing poor markup as its default or only behavior. There is no site-wide consensus at all that what they are doing is a best practice, or we would find |author=McNab, Janet S. everywhere and hardly any use of |last=McNab|first=Janet S. I really have no idea what is the source of the particular mania, when it comes to citations, for assuming that everything anyone ever wants to do, no matter how daft, is something that we must actively support. There was a lot of that going around in the camp at WT:CITE about a decade ago, but it has largely died out with the disappearance of several particular afficiodos of that strange mindset. And it is strange. We don't entertain it in any other way, and routinely merge away and delete redundant and unhelpful template code, normalize conflicting procedures to a single workflow, close inclarities and loopholes in guidance that were leading to repetitive strife, etc. As I've indicated in related comments over at WT:CITE, the sotto voce argument here, that the fact that our current template coding that makes use of CITEREF geekery to produce a particular uncommon output, dictates to us forever that that a redundant parameter will be kept and unhelpful use of it permitted until the end of time, is just tail-wagging-the-dog stuff. It is the job of these templates and CITEREF code to make our work easier and produce better and more useful output. It is absolutely not our job to bend over backwards indefinitely and inject confusing code with confusing and polluted output, just because the tools need further improvement to make them more practical. The ultimate solution is to fix the problem, not continue doing bletcherous and bagbiting things to work around the problem and avoid fixing it.  — SMcCandlish ☏ ¢ 😼  05:57, 28 October 2023 (UTC)

We don't have any sitewide consensus to enforce any particular citation style, or even what to title the back matter subheadings.

If people feel super strongly that authors always need to be presented in "last, first" order and are cleaning up after my cleaning up after Citoid, of course I'm not going to revert them, or even notice, since I don't watchlist those articles and only check back in on them if I have way more free time than I currently do.

No one reverts my pointless stylistic edits either, and I don't revert stylistic choices because it's lame and timewastey.

I'm fine with Izno's wording to prefer |last= |first=. I do follow best practices when I'm doing content creation work, but usually focus on incremental improvement when doing gnoming work. Folly Mox (talk) 08:15, 28 October 2023 (UTC)

This isn't substantively responsive to my point at all. But to reply anyway: What order the names are in is basically irrelevant to this discussion; if there was a strong desire (there isn't) to put author names in "First Last" order at a bunch of articles, e.g. because some widely acceptable citation style required it (there isn't one that does), then this template would long ago have supported a parameter switch to do that, without any effect on the |first=|last= data entry. But in reality, there is not demand for it at all. These parameters are separte for a reason and emit distinct metadata. When you do |last=Garcia, J. B. (or |author=Garcia, J. B. which resolves to the same thing because |author= is an alias of |last=), you are producing false and confusing metadata that claims the author's surname (not full name) is "Garcia, J. B." The reason this keeps happening is primarily because our poor documentation wrongly encourages people to do it (the other reasons being "I just can't be arsed to use two parameters" and "I just paste in what this broken old tool from 2009 generates, and I'm not going to use anything newer and more functional, just because").  — SMcCandlish ☏ ¢ 😼  08:35, 28 October 2023 (UTC)

It was intended as a general reply to your OP at the top of the thread moreso than the post ReplyTool indented it as replying to, but I think in this most recent reply of yours I'm not really finding anything I disagree with. Maybe there's an unexplored route to solution here where the CS1 templates are altered such that |authorn= no longer aliases to |lastn=, but instead generates an error when they're both included. (As an aside, APA does specify that authors after the first author are presented in "first last" name order, but that's not an argument for anything really, and can be fixed with |author2-mask= etc if people are concerned about APA style for some reason). Folly Mox (talk) 16:57, 28 October 2023 (UTC)

Trappist mentions above a COinS key called $rft.au, which I presume holds the full name of an author (examples at WP:COINS and other sites reinforce this presumption). Is there a reason that the CS templates' |author= parameter can't be remapped onto this key instead of aliasing |last= in mapping onto $rft.aulast? Then people could use the |author= parameter while still producing clean metadata, unless I'm misunderstanding something. Folly Mox (talk) 04:33, 29 October 2023 (UTC)

Already does that:

{{cite book |title=Title |author=Green, EB}}

'"`UNIQ--templatestyles-0000004E-QINU`"'<cite id="CITEREFGreen,_EB" class="citation book cs1">Green, EB. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.au=Green%2C+EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Green, EB. Title.

—Trappist the monk (talk) 12:13, 29 October 2023 (UTC)

Thanks, Trappist. I definitely must be misunderstanding something then, because it seems like the |author= parameter does produce correct metadata, which isn't the impression I came away with from reading SMcCandlish's concerns in this thread. Folly Mox (talk) 15:54, 29 October 2023 (UTC)

Just to cover that other condition (|last=):

{{cite book |title=Title |last=Green, EB}}

'"`UNIQ--templatestyles-00000052-QINU`"'<cite id="CITEREFGreen,_EB" class="citation book cs1">Green, EB. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.au=Green%2C+EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Green, EB. Title.

The module won't use rft.aulast= and rft.aufirst= if there isn't a |first= or |first1=. rft.aulast= and rft.aufirst= are only used by the first author; all other |lastn= / |firstn= pairs are individually concatenated, <last><comma><space><first>, and assigned to individual rft.au= keys.

—Trappist the monk (talk) 16:15, 29 October 2023 (UTC)

Ok, we've got a few for this change, so I've made it. Izno (talk) 16:23, 28 October 2023 (UTC)

You might have changed it, but it can't be forced on the community with just a few for this change. The original documentation has a longstanding community consensus.👻 Isaidnoway (talk) 01:17, 29 October 2023 (UTC)

If you are here to say "no way" for sport, forgive me for failing to get the joke; I can be, at times, impervious to subtlety and humor. Taking your post 100% seriously though, I believe you are mistaken. I think if you were to modify any of the citations with the full name in the author parameter, to use separate |last= and |first= parameters, there would be no issue. I've done this before as cleanup, and nobody has complained. Rjjⁱⁱⁱ (talk) 02:22, 29 October 2023 (UTC)

What I was referring to is the instruction creep in the new documentation language based on a "few for this change", rather than a wider input from the community that actually reflects community consensus. Hope this clears up your confusion. ⋆｡°✩🎃✩°｡⋆ Isaidnoway (talk) 22:47, 29 October 2023 (UTC)

It is not instruction creep to state our preference in the documentation. Do you have an issue with the preference itself? You should discuss that if so. Izno (talk) 00:42, 30 October 2023 (UTC)

When you changed the language to prefer the use of |last= |first=, based on "a few for this change", there is now a stated preference there for |last= |first=, that wasn't previously there in the original language. That is indeed instruction creep, because of a stated preference. And since the change has already been implemented, what is left to discuss, the new guidance has already been decided by a "select few". Isaidnoway (talk) 04:48, 30 October 2023 (UTC)

When a change to a gudieline actually better reflects site-wide practice (as that one does), then the number of discussants really isn't relevant; it is necessarily an improvement anyway. The number of editors still running around doing |author=Smith, James B. is very small, and their continued impact on the formatting of our citaions is smaller still. I do a lot of cite cleanup, and this is decreasingly a type that I need to do (and it's almost always in material that was added many years ago, or was done by an anon or noob who has not read the template documentation and is doing other bad-idea things in the same cite).  — SMcCandlish ☏ ¢ 😼  05:28, 30 October 2023 (UTC)

You still do not appear to have stated whether you have an issue with the preference. Do you? Why, if so? I am asking these questions because those can help decide whether I was ultimately right to make this change (quickly). :) Izno (talk) 06:04, 30 October 2023 (UTC)

I would think after everything I've said here that my position on this could not be clearer (and probably no one wants to hear me repeat it in any detail). Why on earth would I be defending the documentation making it clear |first=Firstname|last=Lastname is preferable over doing |author=Firstname Lastname or |author=Lastname, Firstname if I didn't actually agree with that (especially when I'm the one who opened this thread about asking us to do this in first place)? Why are you asking such a strange question and acting as if I've somehow been hiding my position on the matter, when the heading of this thread says it all?  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

@SMcCandlish, my indentation clearly indicates a response to Isaidnoway. Izno (talk) 17:35, 30 October 2023 (UTC)

Derp. I'll have to smoke less crack.  — SMcCandlish ☏ ¢ 😼  02:58, 31 October 2023 (UTC)

I have an issue with the process, since this instruction creep was implemented on the basis of a "select few". But, if an issue does ever arise over the "stated preference", I can point to this discussion for the changes made being based on a "select few". As Molly Fox points out - because it seems like the |author= parameter does produce correct metadata, which isn't the impression I came away with from reading SMcCandlish's concerns in this thread. Isaidnoway (talk) 07:42, 30 October 2023 (UTC)

The output of something like |author=Maria Garcia or |author=Garcia, Maria has gotten to be less poor than I thought (and mea culpa for not checking in rendered browser source first to see what it's doing today), but it is still inferior to that of |last=Garcia|first=Maria. The first pair of cases treat the entire name as if it's a mononym, which it is not: rft.au=Maria+Garcia or rft.au=Garcia%2C+Maria (%2C is the comma); the latter case properly separates the two name parts: rft.aulast=Garcia&rft.aufirst=Maria. They are not equivalent output. And the |author=Garcia, Maria case (rft.au=Garcia%2C+Maria) is worst of all, for wrongly stating that the comma is part of the name string, when it is a separator between discrete pieces of metadata; this is a separation of content and presentation failure, and does in fact amount to polluted/invalid/false/counterfactual/whatever-critical-label-you-prefer metadata, which has been my main concern all along. So, as far as I'm concerned we should clarify further that if you insist on using |author= for a full human name for some reason (a valid one might be a full name that is not a first-last pair, like an Icelandic or Mongolian patronymic) that it is never for "Lastname, Firstname" patterns.  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

@Isaidnoway, you should remember that we aren't a bureaucracy: if you can't find anything wrong with the substantive change, your words then aren't going to mean a lot. If you don't like it, revert it, but expect that you will need to discuss it as well. Which you don't seem to want to do for whatever reason, so it will likely be reinstated over your non-actual-objection. Izno (talk) 17:38, 30 October 2023 (UTC)

The doc still says - this parameter [author] is used to hold the the complete name (first and last) of a single person, so apparently it is still an acceptable use of the parameter. I will remember that the instruction creep was a result of a select few. Have a safe and Happy Halloween my friend. ✦•┈๑⋅⋯ 👻 ⋯⋅๑┈•✦ Isaidnoway (talk) 22:29, 30 October 2023 (UTC)

Isaidnoway: While you are remembering things, it may be useful to remember that this page, along with the documentation pages, are watched by many editors who will quickly revert changes that are unreasonable or to which they object and know that others will object to. You would do well to remember that such a revert has not happened in this case. Silent consensus is a real thing. – Jonesey95 (talk) 23:27, 30 October 2023 (UTC)

What are you talking about? A revert did quickly happen to changes that were unreasonable and were objected to. That's how this whole discussion got started in the first place. And I never explicitly stated or even implied that I was going to revert anything. So your comment seems a little odd, and off base, to say the least. Anyway, have a safe and Happy Halloween. ⋆｡°✩🎃✩°｡⋆ Isaidnoway (talk) 23:47, 30 October 2023 (UTC)

History of author documentation at Help:Citation Style 1:

• 11 October 2011 – first version; prefers |lastn= and |firstn=; |authorn= is 'generally discouraged' (with exceptions);
• 12 October 2011 – first mention of using |author= for corporate authors
• 13 October 2011 – |authorn= no longer 'generally discouraged'
• 16 December 2011 – expanded discussion of |author= for organizational authors
• 16 October 2013 – copy editing; heading name change; the discussion mentioned in the edit summary is now archived
• 28 November 2014 – use of |author= for some name styles removed; edit summary says per Talk, perhaps that discussion is Help talk:Citation Style 1/Archive 6 § COinS: surname? first?
• 18 June 2016 – note about one author name per |authorn= parameter

And since I'm poking around in histories, here is the history of {{Citation Style documentation/author}}:

• 12 January 2012 – first version; no mention of |author=; includes recommendation to use |last= for Asian or corporate names
• 12 January 2012 – |author= mentioned as an alias
• 28 November 2014 – recommendation to use |last= for Asian names removed
• 18 June 2016 – advice for using both individual and corporate names
• 18 June 2016 – |author= gets its own definition
• 28 October 2023 – |lastn= and |firstn= explicitly preferred over |authorn=

From the above histories I take it that the preference for |lastn= and |firstn= is nothing new and that the preference has existed for a rather long time.

—Trappist the monk (talk) 15:45, 30 October 2023 (UTC)

Thought I'd mention Chinese names here. Chinese name order is usually Surname first, followed by 2 personal names - eg the (fictional) Fu Ling Yu would be a a girl born to the Fu family. The fun comes when she is listed in Western sources. She might be listed in her natural order as "Fu Ling Yu" or more helpfully as "Fu Ling-Yu" (the hyphen is nearly always between the personal parts of the name, leaving the surname separate). Or it might be re-arranged as "Fu, Ling Yu", "Ling Yu Fu" or "Ling-Yu Fu". Sometimes a helpful sole mis-translates "Ling Yu Fu" a second time into "Yu Fu Ling". Which is a long-winded way to say that sometimes we do not know which part is the surname. In which case we cannot use |first= and |last= but have to fall back on |author=. Although I vastly prefer using |first= and |last= when they are known. There are probably other languages with similar issues. If I saw a name in an Arabic source I would have little confidence in choosing which is their surname.  Stepho  talk  05:04, 29 October 2023 (UTC)

If you don't know and can't find out which is the family name, then |author=Fu Ling Yu would be reasonable, just as it is reasonable for |author=Pliny the Elder. I don't think anyone's arguing to get rid of |author=. Instances where we just don't have a way of knowing are actually pretty rare. If it is already known or easily find-out-able by Googling for the author, then |last=Fu|. Same as any journal publisher would do. It is not up to us (or, from journal editors' perspective, them) to try to solve the cultural name-order preferences matter that some people somewhere might care about while others would not. It's sufficient for our citation needs that a reader understand that |last=Fu is the family name; the same author in different publications (or even different journal databases listing the exact same publication) might be rendered |last=Fu|first=L. Y. or awful Vancouver style |vauthors=Fu LY, or in the confusing style someone else mentioned where only the first author is given surname-first, then something like "Smith, C. B.; L. Y. Fu; H. D. Jones". And we don't really have any control over that, or need to care about it. Nor about the fact that the same author might be "Ling Yu Fu" or "Ling-yu Fu" on a book they published in English, but be their native-language characters for "Fu Ling Yu" on the Chinese edition of the same book. It just doesn't have any implications for how we cite a source at en.wikipedia.  — SMcCandlish ☏ ¢ 😼  06:55, 29 October 2023 (UTC)

There are plenty of people who can be authors of references and have names in formats where there is no surname at all. S. Muthukrishnan, for example, linked as an author in about a dozen articles. "Muthukrishnan" is the personal name (the one that would be a first name in western name order). "S." is not a surname (it is not a name that would be inherited through a family); it is the initial of his father's personal name. If you haven't seen Falsehoods Programmers Believe About Names, you should. —David Eppstein (talk) 06:50, 29 October 2023 (UTC)

Makes me wonder also if there's any conventional way to treat Icelandic patronymics. Do we just treat them as if they are surnames, or as if the entire name is a unit?  — SMcCandlish ☏ ¢ 😼  07:10, 29 October 2023 (UTC)

User:Stepho-wrs, I brought this up last month at Help talk:Citation Style 1/Archive 90#East Asian name order, where we discussed a few ideas. I do still typically use the |author= parameter when I'm citing works by Chinese authors, but if I find them in |last= |first=, I no longer recast them into |author= and have started using |author-mask= instead to fix the display of their names. Folly Mox (talk) 07:50, 29 October 2023 (UTC)

Also, if anyone is having trouble determining a Chinese author's name (like which bit is the surname), feel free to drop a {{csni}} near the citation. That places the article in Category:Articles needing Chinese script or text (13), which is pretty well-patrolled.

Another convention that is gaining popularity in Western language publications is setting the author's surname in Smallcaps, which we also have a template for, but is, like many conventions, discouraged on Wikipedia. Folly Mox (talk) 08:00, 29 October 2023 (UTC)

What is the evidence for "gaining popularity"? I used to have a collection of almost every style guide (for English) published in the last century, and saw no shift over time toward favoring that format. While I offloaded thousands of books (including most of the style guides) several years ago, I'm not aware of any established style guide that has switched to this format recently, only the same ones that have used it for a long time continuing to use it.  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

I have no evidence for setting East Asian surnames in Smallcaps gaining popularity other than I see it more often than I used to, including recently in a whole chapter of a book rather than just in the credits of a paper.

I haven't done any sort of empirical sampling, but in general the sort of sources I'm looking at these days are newer than the ones I was looking at decades ago in my academic days.

My communication here was pretty unclear, and appears to have been written in the middle of the night, but this is a practice I don't see frequently in citations: it's usually the credits at the head / cover sheet of a published article. I don't know of any citation style guide that recommends this, and my vague impression is that it's an authorial or publisher choice. Folly Mox (talk) 11:31, 30 October 2023 (UTC)

Ah, I have also anecdotally noticed a few publications do this with East Asian names in particular, because of potential "what is the family name?" ambiguity. But that is not a problem for us or our readers often. We typically know already one way or another, and can thus use |last=Li|first=Cheng Po (perhaps with a mask if you really want to mess around with it). Unless someone has gone out of their way to prevent the "Li, Chen Po" rendering, the reader will get that. Essentially the same with |vauthors=; they're going to get "Li CP" and not be confused. In order to use a smallcaps "convention" (I don't agree with applying that term to things that are not broadly conventionalized/standardized) we would already have to know what the family name is anyway. And the purpose of our citations is not "making authors, or some prescriptive sliver of our readers, especially pleased about how this name is rendered". It is only helping people find sources to verify our content, and "Li, Chen Po" does that just as well as "Li Chen Po". Another issue is that this smallcaps thing is a feature of a handful of citation styles, and not permitted in other citation styles, so we could never actually enforce it as a norm site-wide, even if we built it into CS1 (it's not required to use CS1, and editors can use, and at a particular article effectively enforce, any consistent citation style they choose. Which is completely daft and we never should have permitted it, but we're stuck with it at least for the forseeable future.)  — SMcCandlish ☏ ¢ 😼  12:02, 30 October 2023 (UTC)

Burmese names are another example; there is no separate surname to distinguish |first= from |last= per se, so the whole thing (sans any honorifics) should go in |author=. Umimmak (talk) 16:12, 29 October 2023 (UTC)

If we think |author=Full Name Here is the best way to treat anything like that, then I guess I'll also apply it to the Icelandic patronymic cases. However, I do see various journals treat them as if they're surnames, so I have some lingering doubts. Should we mimic what the journals are doing (people who over-apply "follow the sources" to every imaginable circumstance will probably like that idea), or aim for consistent treatment of a general class of names that aren't really first-last pairs?  — SMcCandlish ☏ ¢ 😼  10:29, 30 October 2023 (UTC)

CMoS specifically calls out how to cite and index Burmese names but doesn't seem to specifically mention Icelandic patronymics which is unfortunate. MLA says to treat patronymics as surnames for the purposes of indexing and citation in nonspecialist contexts (so on Wikipedia |last=Karlsson & |first=Gunnar), but if the reader is likely to be familiar with Icelandic names to not invert the name in the bibliography and use the given name for the purposes of short citations (on Wikipedia: |author=Gunnar Karlsson with |ref={{harvid|Gunnar|YYYY}}. It would be nice if Wikipedia:WikiProject Iceland/Style advice were more specific, but I think per WP:CITEVAR either option could be used on Wikipedia so long as it were consistent in a single article and ideally what a majority of sources in that field used for citing Icelandic names. For that matter it would be nice if Wikipedia:Naming conventions (Burmese) were explicit on citation as well, too.

I'm hesitant to trust random citations to always do the correct thing; one could imagine a journal incorrectly citing (English-language publications of) Katalin É. Kiss with |last=Kiss and |first=Katalin É. if they didn't know the specifics of her name but that doesn't mean Wikipedia should do that. Ideally see how the author cites themself in English-language works, or what is common across the most relevant discipline vs one source you happened to have off hand. Umimmak (talk) 23:11, 30 October 2023 (UTC)

Another generic title

Hello, can you add "Page cannot be found" as part of the title as a generic title. Currently, 17 instances. Keith D (talk) 17:07, 26 October 2023 (UTC)

This should be fixed at the source, by sanity checking in Citoid, but probably won't be. Folly Mox (talk) 04:43, 29 October 2023 (UTC)

Parameter first= with comma in it

I get error messages "cite book CS1 maint multiple names authors list (link)" for citations in which the first argument of the first parameter contains a comma. These are usually aristocrats, for example "|first=Winifred Anne Henrietta Christina Herbert Gardner, Baroness", "|first=Hervey Redmond Morres, Viscount", "|first=Philippe de Courcillon, marquis de", "|first=Patrick Theobald Tower Butler, Baron", "|first1=Desmond, Knight of Glin" etc. Is it incorrect to add such titles to better identify the person? Best regards Johannes Schade (talk) 15:26, 29 October 2023 (UTC)

The discussions that caused us to add that maintenance message are:

• Wikipedia:Village pump (technical)/Archive 206 § Can I get a list of cite web templates that probably have excessive numbers of authors in the fields?
• Help talk:Citation Style 1/Archive 88 § multiple names in |first=

—Trappist the monk (talk) 16:31, 29 October 2023 (UTC)

I noticed this error/warning message, too, and have been removing the titles and stuff to avoid it. That seems to be largely in keeping with MOS:HONORIFICS and such, but people are probably apt to have some disagreements about this. The solution is often to do something like |last=Graham|first=James Angus|author-link=James Angus Graham, 7th Duke of Montrose, but of course that only works for someone with an article (or at least a list entry to link to). If one really insisted on including the arguably extraneous titles, I guess try |first=Marquess James or |first=Dame Anne or whatever. But other editors might remove the titles later, as not literally/exactly part of the name. I've been writing in a topic area with a lot of sirs and other titles and just omitting them (completely in citations, and in the main prose when the title doesn't seem especially pertinent to why the person is mentioned, e.g. as a book author not as a socio-political figure). No one has seemed to care. But maybe they would if it were some "hot" topic of current British affairs or something.  — SMcCandlish ☏ ¢ 😼  17:25, 29 October 2023 (UTC)

User:Johannes Schade, you could always cut the title bits from the |first= parameter and use |author-mask= to display the author's full name and title in whatever format feels most appropriate to the context. Folly Mox (talk) 18:13, 29 October 2023 (UTC)

Yeah, that does work. I just tested {{cite book |last=Sinclair-Smythe |first=Janet Hortence |author-link=Janet Sinclair-Smythe, 2nd Baroness Wolverhampton |author-mask=J. H. Sinclair-Smythe, Baroness |title=Some Title Here |date=2023}} and it had the expected effect. I don't see a use-case for it though, except where there's a burning desire to precisely match the name-string on the book cover, maybe because there are several authors with the name base name, and our article on the subject is something rather different or the article doesn't exist. Even then, if there's a DOI, ISBN, or other identifier, or even a work title that leads to info on the correct source at the top of a Google/Bing/Yandex search, this seems unnecessary. Is it only to appease editors who really want to add titles onto authors?  — SMcCandlish ☏ ¢ 😼  18:39, 29 October 2023 (UTC)

The original use of author-mask was primarily for its numerical input rendering a dash for bibliographies and other lists of works. Support for non-numerical masks was added likely as part of the shift to Lua enabled more complicated processing of parameters.

I think the majority reason is that burning desire. Asian names and other "what's the family name" cases are another ("the comma in the middle makes me twitch when we already have a good last-first ordering"). Asian names including the kanji for romanized listings, or the romanization for kanji listings, is a third (|first=A |last=B |author-mask=A B (kanji)). There's the fourth HONORIFIC bent to it, "gotta give due credit to people who are kings and generals" (the latter of which are in this category a lot as well, though not often ranked so highly). There's a fifth "with" case, as in |author-mask=with so-and-so.

I think (3) is highly motivating to me to have the parameter accept non-numerical input, and if the others exist, that's not going to ruffle my feathers. FAC might not like some specific use in an article, but that's a matter for consensus. Izno (talk) 20:50, 29 October 2023 (UTC)

I brought this up here to show that there are cases when one would like to use a comma in the argument of the first-parameter. It is importanct in may circumstances to identify the author as precisely as possible. The maintenance message has not always been there and nobody has said that it is now forbidden to use commas in this parameter. I hope the maintennce message will be removed once it has served its purposes and is not needed any more. With thanks and best regards, Johannes Schade (talk) 20:20, 29 October 2023 (UTC)

Trappist the monk pointed to the motivating discussions of interest regarding the use of commas in this parameter and the categorization now attendant. Izno (talk) 20:51, 29 October 2023 (UTC)

If someone must have this in the displayed citation, Folly Mox's solution is appropriate. I think it's just more noise in the vast majority of cases. Izno (talk) 20:26, 29 October 2023 (UTC)

Re removing the titles and stuff to avoid it: User:SMcCandlish, you are cutting off your feet to fit the too-short bed. Don't do that. Fix the bed, or find a different bed provider if the current provider remains insistent on keeping it so rigid. —David Eppstein (talk) 21:02, 29 October 2023 (UTC)

Maybe that would be the case if I were a title-booster, but I'm not, and we have MOS:HONORIFICS for a reason. These titles are almost always extraneous clutter in a citation, and are just added to puff up the author and make them seem more important than other authors, or done out of robotic adherence to the nomenclature of a dying class system that ultimately has nothing to do with finding and verifying sources. I've slept on it, and I regret offering even the suggestions above for making this easier.  — SMcCandlish ☏ ¢ 😼  03:03, 30 October 2023 (UTC)

Is any of this even correct? Take for instance Herbert Coulstoun Gardner, who was the 1st Baron of Burghclere. The construct "Burghclere, Herbert Coulstoun Gardner, Baron" would just be wrong, that's not his name. The same would be true of "Baron Herbert Coulstoun Gardner Burghclere".

"Herbert Coulstoun Gardner, the Baron Burghclere" maybe, but it's very formal. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:26, 29 October 2023 (UTC)

And just doesn't seem to relate to the purpose of a citation, which is identifying a source and its authorship well enough to enable verification of our claim(s) cited to that source.  — SMcCandlish ☏ ¢ 😼  03:03, 30 October 2023 (UTC)

Well if that's the purpose of a citation, what's the problem with using |author= to hold the full name of an author? Or using |authors= to list the authors? I'm not understanding how to hold in the one hand "our downstream metadata reusers require absolutely perfect information no matter the labour cost to Wikipedia editors" and in the other hand "making the author's credited name match up with what's printed in the published source isn't necessary as long as there's enough information to identify the source positively". Folly Mox (talk) 03:30, 30 October 2023 (UTC)

making the author's credited name match up with what's printed in the published source That is part of my point as well, if you look at the front matter of these works they'll say the author is "Lord Burghclere" or similar, never the name / title hybrids that are at issue. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:12, 30 October 2023 (UTC)

Not everyone was gung-ho about this metadata stuff to begin with, but if we're going to use it, it's important that it be accurate as to what it purports to be, parameter by parameter. They're severable concerns. There's a big difference between leaving something off, like a noble or other honorific title, and basically lying about the nature of the data contained in a particular parameter. I don't buy the idea that editors here care in the least about precisely mimicking the appearance of the author's name on the original published source. Otherwise we would immediately ban Vancouver citation style just for starters, and also prohibit otherwise reducing a full author name to initials (or expanding a notable author's name given on that paper/book as initials to a fuller name that we know is right because it's our article title about that person). And so on.  — SMcCandlish ☏ ¢ 😼  12:11, 30 October 2023 (UTC)

I just also want to add I've also had error messages for having |last=LAST |first=GIVEN, Jr./III/etc. and to avoid the error message I've simply removed the comma in |first= even though outside of Wikipedia this comma is de rigueur:

Strong, E. K., Jr., & Uhrbrock, R. S. (1923). Bibliography on job analysis. In L. Outhwaite (Series Ed.), Personnel Research Series: Vol. 1. Job analysis and the curriculum (pp. 140–146). doi:10.1037/10762-000

— APA

A suffix that is an essential part of the name—like Jr. or a roman numeral— appears after the given name, preceded by a comma.

• Rockefeller, John D., IV
• Rust, Arthur George, Jr.

— MLA

In an inverted name, however (as in an index; see 16.41), a comma is required before such an element, which comes last. [...]

• Doe, John, Sr.
• Deer, Jason, III

— CMoS

Umimmak (talk) 23:23, 30 October 2023 (UTC)

cs1|2 is not APA, is not MLS, is not CMoS. For generational suffixes, cs1|2 follows MOS:JR. Also, maintenance messages are not errors.

—Trappist the monk (talk) 23:35, 30 October 2023 (UTC)

Yes, though if a strong case were made to make an exception for "Surname, Givenname M. I., Jr." usage in citations (or other circumstances of surname-first listing), I can see the community probably going along with it. I suggested this myself back-when, but did not RfC it or anything. I think it would actually be a clearer formatting convention, especially since a few names (especially in French and some other languages) sometimes take multi-letter initials like "Th." If someone wanted to go that route, I would suggest making it a WP:VPPOL RfC, since MOS:JR's basic wording was decided there. This page here is probably too narrow a venue with too few watchers to achieve a "make an exception to a general guideline" consensus that would be respected.  — SMcCandlish ☏ ¢ 😼  08:48, 31 October 2023 (UTC)

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)

You might find the aliases |given= and |surname= less confusing in cases like this. Kanguole 13:09, 30 October 2023 (UTC)

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)

There's not a mechanism to prevent them from doing it.  — SMcCandlish ☏ ¢ 😼  13:33, 30 October 2023 (UTC)

Yep. It is not intended to do |first=Mizuki just because Mikuki comes first in Japanese order.  — SMcCandlish ☏ ¢ 😼  13:31, 30 October 2023 (UTC)

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)

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)

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)

It probably wouldn't hurt to have additional aliases. And maybe to favo[u]r 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)

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)

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" [New method for establishing the formulas of spherical trigonometry], 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 [in German] (1905), "Nouvelle méthode pour l'établissement des formules de la trigonométrie sphérique" [New method for establishing the formulas of spherical trigonometry], 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" [New method for establishing the formulas of spherical trigonometry], 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)

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)

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)

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)

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)

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)

Maximum PMID numerical value exceeded

Hello. It appears that the current upper limit for PMID numerical value of 37900000 has been exceeded as I tried to use 37902774 and it was not allowed. Thank you for increasing the MAX integer value for this field. User:Ceyockey (talk to me) 00:54, 31 October 2023 (UTC)

url-status=dead (and a side-topic about language=en)

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)

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)

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)

Having |language= set helps with translation efforts. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:18, 31 October 2023 (UTC)

Any translator taking material from en.wikipedia.org 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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 17:02, 31 October 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 31 October 2023 (UTC)

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)

Just because {{Ouvrage}} was imported from fr.wiki does not mean that the source is written in French – likely it is, but there is no guarantee. fr.wiki doesn't use cs1|2 but they do have |langue=. At fr.wiki, 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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 19:58, 31 October 2023 (UTC)

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

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 12:26, 1 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 20:13, 1 November 2023 (UTC)

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)

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)

And |language=en is 12 characters that hurts no-one , so what. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:15, 1 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 22:59, 1 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 23:10, 1 November 2023 (UTC)

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)

(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 sq.wiki, for example, |language=en renders as '(në anglisht)'. Leaving |language=en aids editors who copy en.wiki 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)

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)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 20:23, 1 November 2023 (UTC)

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)

They have not, and as above please don't try to restart this. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:30, 1 November 2023 (UTC)

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

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)

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=https://archive.org|title=Title|url=https://example.com}}
Old	Title. Archived from the original on 2023-10-21. https://archive.org.
Live	Title. Archived from the original on 2023-10-21.

I don't know where that extra archive.org 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=https://archive.org|title=Title|url=https://example.com|deadurl=yes}}

Title. Archived from the original on 2023-10-21. https://archive.org. 

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=https://archive.org|title=Title|url=https://example.com|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)

This would definitely help with editors misusing it to mark dead links. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:19, 31 October 2023 (UTC)

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)

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)

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)

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)

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)

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)

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= https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |url-access=subscription |url-status=live |archive-url= https://web.archive.org/web/20231101004026/https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |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. [2]), 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)

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)

Thanks for the advice. User:Ceyockey (talk to me) 00:01, 4 November 2023 (UTC)

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)

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)

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)

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)

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)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 20:20, 1 November 2023 (UTC)

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)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 23:09, 1 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 01:56, 2 November 2023 (UTC)

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)

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)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 23:17, 1 November 2023 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

Not refuted at all by anyone, just willfully ihnored. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:35, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 15:13, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 16:39, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 17:07, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 17:13, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 5 November 2023 (UTC)

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)

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)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 18:13, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 19:49, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 20:07, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 21:50, 5 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 15:27, 6 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 18:33, 7 November 2023 (UTC)

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)

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)

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)

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)

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)

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)

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)

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

• In a citation to a periodical that is relatively unknown, as the ISSN can help in verifying the existence and reliability of the journal and procuring a copy of one of its issues to verify the content.

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)

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)

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)

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)

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)

Dates - "Summer, 1993"

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

|date=Summer 1993

—Trappist the monk (talk) 12:13, 1 November 2023 (UTC)

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)

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

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

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)

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)

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)

Also we would replace "Autumn" by "Fall" Why? -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 01:49, 2 November 2023 (UTC)

Indeed; we should not. Mathglot (talk) 02:26, 2 November 2023 (UTC)

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)

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)

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 [3]. 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)

We don't even use issue names. —David Eppstein (talk) 15:19, 2 November 2023 (UTC)

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)

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)

@Trappist the monk: Maybe it's time to unhide this particular error. GoingBatty (talk) 14:05, 2 November 2023 (UTC)

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

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)

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)

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)

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

In that case, none. Kanguole 23:38, 2 November 2023 (UTC)

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)

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)

But not for {{cite magazine}}? Why not?

—Trappist the monk (talk) 17:38, 2 November 2023 (UTC)

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)

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)

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)

Category:CS1 errors: periodical ignored.

—Trappist the monk (talk) 17:57, 3 November 2023 (UTC)

Thank you for the correction 🙏🏽 Folly Mox (talk) 20:05, 3 November 2023 (UTC)

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)

I've been watching but not commented and am strongly in favour of this if any more support was needed. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:17, 3 November 2023 (UTC)

Ditto.  — SMcCandlish ☏ ¢ 😼  08:07, 4 November 2023 (UTC)

Unhidden in the sandbox.

—Trappist the monk (talk) 20:08, 14 November 2023 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

Please don't stick multiple ISBNs into citations. One is already more than enough clutter. –jacobolus (t) 15:21, 5 November 2023 (UTC)

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:

• for articles that have a {{use dmy dates}} template: ~42,000 articles (search times out)
• for articles that have a {{use mdy dates}} template: ~34,200 articles

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:

• ~30,700 articles (search times out)

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)

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)

I'm in agreement with Trappist's "mark the paramenter as 'discouraged'" idea. "[G]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 [though changing a specific page reference in a journal article into the entire span of the pages that the journal article covers is infuriating, "reader-hateful", and has to stop]. 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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 13:25, 3 November 2023 (UTC)

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)

supplement element

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

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)

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)

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)

Would this be |department=? Kanguole 16:21, 3 November 2023 (UTC)

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)

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)

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)

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

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)

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)

Unfortunately work is misused for all sorts of things, websites, series titles, editions, publishers, and even authors. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:50, 4 November 2023 (UTC)

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)

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 ActivelyDisinterested ∆transmissions∆ °co-ords° 13:04, 4 November 2023 (UTC)

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 (25,474).

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)

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)

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)

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 (25,474) 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)

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)

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)

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)

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=https://books.google.com/books?id=G5vUbBuk-Q0C|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)

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

Help talk:Citation Style 1/Archive 90 § Sorting drafts to back of categories

—Trappist the monk (talk) 16:31, 6 November 2023 (UTC)

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)

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)

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)

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)

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)

gracefully fail for print sources What does that mean?

—Trappist the monk (talk) 17:17, 6 November 2023 (UTC)

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)

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)

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)

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)

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)

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)

By the way, you don't have to throw hostile/insulting language into every conversation. –jacobolus (t) 20:25, 6 November 2023 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

@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=https://www.thetimes.co.uk/article/sam-bankman-fried-ftx-trial-collapse-crypto-bd90l2t2s |website=The Times |date=November 2, 2023 |access-date=November 11, 2023 |archive-date=November 2, 2023 |archive-url=https://archive.today/20231102155810/https://www.thetimes.co.uk/article/sam-bankman-fried-ftx-trial-collapse-crypto-bd90l2t2s |url-status=live |url-access=subscription }} (Extracted from ''[[Going Infinite]]'')</ref>

Happy editing! GoingBatty (talk) 05:59, 12 November 2023 (UTC)

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)

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)

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)

Wikipedia:Reliable sources/Perennial sources § IMDb

—Trappist the monk (talk) 18:44, 12 November 2023 (UTC)

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)

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)

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)

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)

In this case, OCLC 1134530070. Kanguole 23:53, 12 November 2023 (UTC)

You could alternately put it in the "id" parameter of the template. –jacobolus (t) 02:33, 13 November 2023 (UTC)

An IMDB link outside of External links is likely to be removed. Kanguole 09:10, 13 November 2023 (UTC)

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)

in External links , metadata sites are usually listed thus:

• Devil's Cargo at IMDb
• Devil's Cargo at AllMovie
• Devil's Cargo at the TCM Movie Database
• Devil's Cargo at the American Film Institute Catalog

however, in order of usefulness and reliability they should be:

• Devil's Cargo at the American Film Institute Catalog
• Devil's Cargo at the TCM Movie Database
• Devil's Cargo at AllMovie
• Devil's Cargo at IMDb

can this be changed ?

.... 0mtwb9gd5wx (talk) 21:20, 12 November 2023 (UTC)

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)

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)

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)

Upon rereading my reply just above, it comes off as pretty condescending. My apologies. Folly Mox (talk) 22:12, 12 November 2023 (UTC)

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)

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)

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)

Does {{cite episode}} not work for your use cases? Folly Mox (talk) 22:02, 12 November 2023 (UTC)

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=http://www.bravotv.com/Inside_the_Actors_Studio/guest/Billy_Crystal_-_2nd_Visit |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="http://www.bravotv.com/Inside_the_Actors_Studio/guest/Billy_Crystal_-_2nd_Visit">"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.date=2007-10-08&amp;rft.aulast=Lipton&amp;rft.aufirst=James+%28host%29&amp;rft_id=http%3A%2F%2Fwww.bravotv.com%2FInside_the_Actors_Studio%2Fguest%2FBilly_Crystal_-_2nd_Visit&amp;rfr_id=info%3Asid%2Fen.wikipedia.org%3ATemplate%3ACite+episode" 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)

History: Help talk:Citation Style 1/Archive 86 § |people= parenthetical roles

—Trappist the monk (talk) 20:55, 13 November 2023 (UTC)

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.

• {{cite episode |title=Billy Crystal, 2nd Visit |series=Inside the Actors Studio |date=8 October 2007 |url=http://www.bravotv.com/Inside_the_Actors_Studio/guest/Billy_Crystal_-_2nd_Visit |network=Bravo |season=13 |number=1307 |people=Lipton, James (host)}}
• Lipton, James (host) (8 October 2007). "Billy Crystal, 2nd Visit". Inside the Actors Studio. Season 13. Episode 1307. Bravo.
• <cite class="citation episode cs1">Lipton, James (host) (8 October 2007). <a rel="nofollow" class="external text">"Billy Crystal, 2nd Visit"</a>. <i>Inside the Actors Studio</i>. Season 13. Episode 1307. Bravo.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Inside+the+Actors+Studio&rft.series=Season+13.+Episode+1307&rft.date=2007-10-08&rft_id=http%3A%2F%2Fwww.bravotv.com%2FInside_the_Actors_Studio%2Fguest%2FBilly_Crystal_-_2nd_Visit&rfr_id=info%3Asid%2Fen.wikipedia.org%3AUser%3ASMcCandlish%2Fsandbox+22" class="Z3988"></span>

Lipton doesn't appear in the COinS output.  — SMcCandlish ☏ ¢ 😼  21:57, 13 November 2023 (UTC)

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)

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

• upgrade numeric names maintenance message to error; discussion
• add Greek character sort keys for error/maint messages in non-article namespaces; discussion
• improve global |display-<namelist>= handling; discussion
• for |language= look for tag first then name; discussion
• fix for phab:T117845; discussion
• bug fix when |work= and aliases in {{cite book}} ignored; discussion
• deprecate |authors=; discussion
• bug fix for {{cite book}} with |trans-<periodical>=; discussion

Module:Citation/CS1/Configuration

• Swiss German fix; discussion
• make extra text in volume non-hidden as it is kept clear these days
• upgrade numeric names maintenance message to error
• add Greek character sort keys for error/maint messages in non-article namespaces
• add maint cat for unflagged free-to-read dois; discussion
• update emoji_t to unicode v15.1; discussion
• remove no-longer-supported |chapterurl=;
• support single letter 2nd level domains for media TLD; discussion
• fix for phab:T117845
• deprecate |authors=
• unhide missing-periodical error messages; discussion

Module:Citation/CS1/Whitelist

• deprecate |authors=;

Module:Citation/CS1/Date validation

• |archive-date= / timestamp check to use internal reformatter for i18n; emit suggested date; discussion

Module:Citation/CS1/Identifiers

• add maint cat for unflagged free-to-read dois;

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

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)

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)

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)

Did that while you were writing you message.

—Trappist the monk (talk) 19:46, 25 November 2023 (UTC)

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:

• Cite journal:

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.

• Our templates:

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)

I presume that by Our templates you mean ru.wiki's templates, not en.wiki's templates. There are a lot of wikis that take a copy of en.wiki'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 en.wiki 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 ru.wiki 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 ru.wiki module is sufficiently old that it does not recognize |name-list-style= so the ru.wiki rendering does not have the ampersand between the author names and at ru.wiki emits a Неизвестный параметр error message. The ru.wiki 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)

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)

Of course it is, if you're willing to put in the work and are willing to redo the work every time someone at ru.wiki 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.wiki, ru:Template:Cite journal would call the translator module. The translator module might map the en.wiki parameters to these ru.wiki 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)

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

@Trappist the monk, can you help me with my request? :) Where is the rendering order described? Iniquity (talk) 11:15, 25 November 2023 (UTC)

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)

I'm understood, thank you! Iniquity (talk) 03:20, 26 November 2023 (UTC)

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)

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)

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)

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)

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)

ProveIt doesn't have bot approval for these automated cosmetic changes to citation markup, does it? Kanguole 14:27, 21 November 2023 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 https://www.ncbi.nlm.nih.gov/books/NBK557634/ (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)

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)

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)

But |url= already "give[s] 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)

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)

You can search "StatPearls" in pubmed or open URL https://pubmed.ncbi.nlm.nih.gov/?term=StatPearls and get many search results on the books I mentioned. Maxim Masiutin (talk) 03:15, 22 November 2023 (UTC)

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)

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)

Maybe StatPearls was not a good example, but there are books there which are not necessarily rubbsh, such as https://www.ncbi.nlm.nih.gov/books/NBK26830/ Maxim Masiutin (talk) 19:29, 25 November 2023 (UTC)

• You don't need a new field for this, you can just the the |id= field and the {{NCBIBook}} template.
  {{citation |last1=Kinter |first1=KJ |last2=Amraei |first2=R |last3=Anekar |first3=AA |title=Biochemistry, Dihydrotestosterone. |date=January 2023 |pmid=32491566 |id={{NCBIBook|NBK557634}}}}
  gives you:
  Kinter, KJ; Amraei, R; Anekar, AA (January 2023), Biochemistry, Dihydrotestosterone., PMID 32491566, NCBI NBK557634
  There are templates for most common identifiers. -- LCU ActivelyDisinterested «@» °∆t° 21:35, 22 November 2023 (UTC)

  Thank you very much! I didn't know that! You've made my day! Maxim Masiutin (talk) 21:39, 22 November 2023 (UTC)

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

Hello,

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

• Grabbe, Lester L. (2007). Ancient Israel: What Do We Know and How Do We Know It?. Bloomsbury. ISBN 978-0567110121.
• Berry, Helen (2017). "Gertrude Bell: Pioneer, Anti-Suffragist, Feminist Icon?". In Collins, Paul; Tripp, Charles (eds.). Gertrude Bell in Iraq: A Life and Legacy. Oxford University Press. pp. 127–151. ISBN 978-0-19-726607-6.

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)

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)

Volumes with their own subtitles

Resolved

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

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)

@SMcCandlish: Which article? Which template? GoingBatty (talk) 21:36, 22 November 2023 (UTC)

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)

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)

Found it. This:

{{Cite book |url=https://books.google.com/books?id=UxWZ-OmTqVoC |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)

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)

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, Rjjⁱⁱⁱ (talk) 08:45, 23 November 2023 (UTC)

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:

• For a newspaper or periodical, use the name of the publication and the date, or set the author parameter to "publication name staff".
• For a publication by an institution, use the name of the institution.
• Some style guides recommend using the title of the article (title-date).
• Other style guides recommend using "Anonymous" or "Anon."

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

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)

@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. Rjjⁱⁱⁱ (talk) 23:16, 22 November 2023 (UTC)

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

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)

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)

+1 -- LCU ActivelyDisinterested «@» °∆t° 23:50, 22 November 2023 (UTC)

I copied the text by Charlie Gillingham from Template:sfn/doc to Help:Shortened footnotes, changing "harvid" to "sfnref", which already suggested using |ref=.[4] 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)

Also, thanks all for the input, Rjjiii (ii) (talk) 00:54, 23 November 2023 (UTC)

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)

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)

Yep.  — SMcCandlish ☏ ¢ 😼  02:16, 23 November 2023 (UTC)

The example from the {{sfn}} doc page includes a generic "BGI" initialization. I've replaced that on H:SFN with a "MoMA" shortened footnote.[5] I haven't changed anything on the template documentation. Rjjiii (ii) (talk) 02:42, 23 November 2023 (UTC)

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)

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)

@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? Rjjⁱⁱⁱ (talk) 04:03, 23 November 2023 (UTC)

Also, what do you mean about "the table column presentation is messed up in this one"? I see a 2x2 grid in both? Rjjⁱⁱⁱ (talk) 04:06, 23 November 2023 (UTC)

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)

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)

@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, Rjjⁱⁱⁱ (talk) 05:47, 23 November 2023 (UTC)

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)

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)

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)

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=[[Museum of Modern Art|MoMA]] |...}} 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=[[Museum of Modern Art|MoMA]] |...}} (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)

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)

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)

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.

References

• SSAC (2023). "Black History Month Profile: Leroy Chollet (Loyola)". SSAC Sports. Montgomery, Alabama: Southern States Athletic Conference. February 27, 2023. Archived from the original on March 29, 2023. Retrieved March 29, 2023.

Rjjⁱⁱⁱ (talk) 08:40, 23 November 2023 (UTC)

Simpler to just do plain text:

• SSAC: "Black History Month Profile: Leroy Chollet (Loyola)". SSAC Sports. Montgomery, Alabama: Southern States Athletic Conference. February 27, 2023. Archived from the original on March 29, 2023. Retrieved March 29, 2023.

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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

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)

Nah, use it when appropriate, like when that's all there is, often for books. -- GreenC 04:22, 24 November 2023 (UTC)

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)

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)

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

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)

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)

Proposed script-author parameter

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

• Help talk:Citation Style 1/Archive 64#Citing native scripts of the author's name and/or title of a work in Citation Style 1

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)

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)

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)

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)

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)