Help talk:Citation Style 1/Archive 91

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

Archive 85

←

Archive 89

→

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

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

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)

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 [de; fr]. 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 [de; fr] (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)

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)

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)

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)

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)

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 (22,905).

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 (22,905) 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)

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

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:

Have the template strip anything in parentheses from the COinS data. (eg. "James (host)" becomes "James ")
Add parameters for specific roles, eg. |host-last=, |host-first=, |guest-last=
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" 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&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)

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)

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

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)

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)

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)

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

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:

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

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)

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)