Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

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

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

Re the language parameter, I doubt this is people adding it, more not removing it. The citation tool adds the parameter automatically if it finds the relevant information on the source page. Nthep (talk) 14:51, 31 October 2023 (UTC)

Hmm. So, how to get that to stop happening when (on this site) the value returned in en or en-*? It's annoying, and resulting in an unbelievable amount of pointless code bloat.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC)

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

Any translator taking material from en.wikipedia.org already knows that the default language is en, and 99%+ of our cites to en sources do not have this parameter, so it is not helping with translation efforts. Even if it was, somehow, some way, it is not worth the amount of code bloat in our live articles.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC)

It's very little code bloat, especially as the reader doesn't even see it. Also a lot of non-technical editors translate articles and rely on automatic trasnlation of cites. The mass removal has been previously discussed on one of the village pump pages, and gained no traction. I was initially for removing it, but came to see the other sides point. It's 12 characters, it hurts no-one and helps some. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:02, 31 October 2023 (UTC)

No readers ever see any code bloat, because it's in the code, by definition. It's an editing and maintenance issue, not an end-user readability matter. It's 12 (often 15) characters over and over and over again on page after page after page. Not trivial. Mass removal of anything generally gets opposed on "I don't want my watchlist going nuts" grounds, especially when the change does not affect the reader's view. So that's not a principled position against deprecating this usage and getting tools to stop automatically doing it. If there's an actual use case for this, I have yet to see it, and I've been here 17 years. I guess I will go see if I can find some arguments for it that I missed, since you suggest there are some, but these vague hints are not promising. If the user already knows by default that the material will be English (and besides, the entire page already has lang="en" for its entire content except were explicitly overridden), there doesn't seem to be an auto-translation-tools reason for this.  — SMcCandlish ☏ ¢ 😼  17:22, 31 October 2023 (UTC)

That's how the auto-translation tools work and usually they are translating the cite once they have reached the target wiki, so no lang="en" is not set. You've missed that {{Ouvrage}} is a redirect to {{Cite book/French}} for instance, and what AnomieBOT does when it's used. So there is a explicit reason to have it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 31 October 2023 (UTC)

Can you explain what you mean in more detail? If the tools are translating some other wiki's content, then that wiki will be providing its own lang information already. I don't see what the {{Ouvrage}} redirect has to do with anything, or {{Cite book/French}} for that matter, since if it's translating a template imported with French-language parameters from fr.wikipedia, that template will already either be for a French source (by default) or come with a |language=en (or I suppose |langue=en) if it's an English-language source being cited, and not need a |language=en parameter newly added, plus will get substituted out by a bot anyway and no longer need that parameter after the work is done. Am I missing something still? The fact that there are special and short-term use cases for |language=en doesn't seem to translate (pun intended) into a stick-them-in-every-English-citation-redundantly rationale.  — SMcCandlish ☏ ¢ 😼  18:06, 31 October 2023 (UTC)

Just because {{Ouvrage}} was imported from fr.wiki does not mean that the source is written in French – likely it is, but there is no guarantee. fr.wiki doesn't use cs1|2 but they do have |langue=. At fr.wiki, when |langue=fr, the language output is suppressed; that's where we got the idea to suppress the output here when |language=en.

—Trappist the monk (talk) 18:34, 31 October 2023 (UTC)

1. An editor translates the article text.
2. The editor directly copies the cites without any translation.
3. Anomiebot substitutes the cites using Cite book/French as direction of how to correctly rename the fields.

All this happens on enwiki, so unless the frwiki cites have |language=fr set the cites on enwiki don't have it either. All of this makes it easier for editors to translate articles without having learn the technical details of how the templates work.

It is a real and specific reason to include |language=en. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:58, 31 October 2023 (UTC)

"makes it easier for editors to translate articles" is an almost entirely theoretical idea, since nearly none of our citations to English-language sources have |language=en. There is surely a better way to do this than dumping enormous amounts of redundant code into our articles. The fact "this could work to make translation easier" doesn't make this the best, or even a reasonable, idea in furtherance of that goal. (If I need to move my car over by one foot, I could do it by hitting it with sledgehammer and over and over on one side, moving it a milimeter at a time, but this would not be a good idea.) Fr.wikipedia should be presuming by default that a copy-pasted citation off of en.wikipedia that they are using a local tool to translate into an equivalent French cite template is by default an English-language source. There is no reasonable other assumption to make. I'm not convinced in any way that whatever need is being flagged here can only, or even best, or even practically, be solved by jamming in literally millions of |language=en instances. I think we are more clever than this and can build better, cleaner-running tools. Same with "unless the frwiki cites have |language=fr set the cites on enwiki don't have it either"; if our template-translation tool knows the template is from fr.wikipedia (and it would have to, to properly parse the parameters) then we already know that the default thing to do, absent something like a |langue=zh in their template, is to add |language=fr in our version.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

As I said earlier I was convinced of it in another discussion, because people are actively using it this way so no it's not theoretical in anyway. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:26, 1 November 2023 (UTC)

This is more vague "I saw something somewhere once" hearsay. We need specifics, and an examination of whether their alleged need for this can be met some other way that doesn't entail adding millions of blobs of otherwise unneeded code all over the 'pedia.  — SMcCandlish ☏ ¢ 😼  18:09, 1 November 2023 (UTC)

I'm not going to go and dig around every VP archive to find the discussion, and it's obvious even that would not change your mind so I'll drop it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:13, 1 November 2023 (UTC)

My mind actually frequently changes, especially on matters like this, in response to evidence that can't be easily dispelled (like some of the translation-related arguments made so far can be, but there may be stronger ones). I don't think it's unreasonable to respond with "show me" when someone says "I've seen the proof".  — SMcCandlish ☏ ¢ 😼  21:05, 1 November 2023 (UTC)

The problem is not that no people ever could be using it this way. The problem is that (a) only vanishingly few current citations include this, so it can't be relied on, (b) that most citations are in English is obviously implicit here, and describing that explicitly adds a lot of boilerplate noise to the template, (c) the harm of Wikipedians translating English articles to their own language and accidentally not tagging all of the citations as being in English is temporary and pretty trivial, (d) large-scale automated edits adding it to existing citations are a big distraction not justified by the trivial benefit. This problem would be much better addressed by fixing whatever automatic translation tool people are using. –jacobolus (t) 18:16, 1 November 2023 (UTC)

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

The citation templates are already a lot of noisy boilerplate, even in the best case, and a magnet for relatively useless redundant metadata. The longer and more annoying filling out the templates gets, and the more often bot-like editors come and pointlessly twiddle the parameters for little or no benefit to readers, the more I'm tempted to just use plain wikitext for citations, optionally with {{wikicite}}. Every new hoop the templates make human editors jump through is another step in the wrong direction. –jacobolus (t) 22:50, 1 November 2023 (UTC)

No new hoops are being added as I said no-one has suggested mass adding it, or the need for editors to add this parameter when setting up cites, or for any editors to go adding this parameter to already existing cites. Many cites that are created automatically using lookups include this parameter, this is not something that is controlled by the editors maintaining these templates. You have the whole discussion back to front. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:59, 1 November 2023 (UTC)

I thought the problem was with people making edits adding language=en to existing citations? If not, what's the complaint? –jacobolus (t) 23:04, 1 November 2023 (UTC)

The discussion is that it should be removed from cites that already have it, which I feel is a waste of time and could negatively impact some editors is niche situations. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:10, 1 November 2023 (UTC)

If someone wants to incidentally remove language=en in a citation or two as part of reformatting them, fine. Automatic removal of language=en on a wide scale seems like a big waste of attention. –jacobolus (t) 23:36, 1 November 2023 (UTC)

(edit conflict)

|language=en has nothing to do with the html attribute lang="en". The |language= parameter is there so that readers can know the language of the cited source; see the template doc. cs1|2 suppresses rendering of the source language when the source language is the same as the local wiki's language. If a cs1|2 template is never, ever, going to be copied to another language wikipedia, then |language=en is obviously superfluous. If the cs1|2 template may be copied to another language wikipedia, then |language=en renders the source's language in the local language without the copying editor having to do anything: at sq.wiki, for example, |language=en renders as '(në anglisht)'. Leaving |language=en aids editors who copy en.wiki articles to their home wiki and does no harm to editors here. Translation is aided by editors here using the ISO 639 language tag instead of the language name because MediaWiki will provide the name in the local language without the editor there having to translate 'English' to the local language or to the ISO 639 tag.

—Trappist the monk (talk) 18:25, 31 October 2023 (UTC)

If our only or primary rationale for injecting |language=en eventually millions of times into our content is to save someone the trouble at another wiki of adding their local equivalent of |language=en to citations they copied from us, then my opposition to this idea is now more solidified than it was to begin with, especially since a template translation tool can be configured to just add that parameter by default any time it is working with a template that it recognizes as having come from en.wikipedia and which doesn't say something like |language=ja (and the tool would have to be able to do that recognition or it would not be able to convert the highly particular template parameters to the local version in the first place).  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

I entirely agree. Please everyone let's not start havings bots or humans-pretending-to-be-bots add language=en to every citation. What a massive waste of time and attention. And please don't start randomly adding language=en to a hodgepodge subset of citations either. This is an unnecessary and unhelpful thing to include. –jacobolus (t) 06:43, 1 November 2023 (UTC)

No-one is suggesting any such thing, this discussion is actually about the opposite - the exclusion of |language=en not adding it. Many tools will automatically add this when editors use auto-creation, if you disagree with that this is the wrong talk page as those tools are not maintained here. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:23, 1 November 2023 (UTC)

The direct implication of al these "it's so useful for translating" claims (which have so far been unevidenced or easily dispelled, but maybe there is a better one yet to be made) is that eventually they will be imposed everywhere. It's a natural consequence of the argument that they're useful. They're only useful if they're imposed consistently. So raising this concern is in no way out-of-bounds.  — SMcCandlish ☏ ¢ 😼  21:05, 1 November 2023 (UTC)

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

"They have not" what? That has no clear referent, either as to what comes after "not" or what/who "they" is.  — SMcCandlish ☏ ¢ 😼  06:44, 2 November 2023 (UTC)

I know that I also have seen comments here and there also that the use for translation happens. Take it on faith that we're not spouting complete bullshit. :) You can still make your other points ad arguendum regardless.

As for mass-addition of |language=en, that is definitely a strawman. The only system that does anything remotely like that is Citoid (and other systems that use Citoid's output these days) when a website puts a language into its HTML. And like all such citations, I clean the ones that have totally garbage output that often get caught in our category dragnets and allow someone else to state a preference on whether |language=en actually should exist in the article or not. Following the principles of WP:CITEVAR even if this case is one ultimately of wikitext formatting (where we have already established the requirements of CITEVAR don't apply besides to the distinction between using CS1/2 and a hand-input style) and annoyance with what some see as clutter to-be-removed rather than clutter to tolerate for the health of the movement rather than our specific wiki. Izno (talk) 21:06, 4 November 2023 (UTC)

Yes, |url-status=dead in the presence of |url= and |archive-url= is meaningless. When given |archive-url= with an assigned value, Module:Citation/CS1 assumes that |url= is dead. It has been ever thus:

Cite book comparison

Wikitext	{{cite book|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com}}
Old	Title. Archived from the original on 2023-10-21. https://archive.org.
Live	Title. Archived from the original on 2023-10-21.

I don't know where that extra archive.org url is coming from

{{cite book/old}} does not know about |url-status=. Rewriting the example template to use |deadurl=yes returns the exact same result

{{cite book/old|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com|deadurl=yes}}

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

Rewriting the example template to use |url-status=dead returns the exact same result with the live template:

{{cite book|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com|url-status=dead}}

Title. Archived from the original on 2023-10-21.

|url-status=dead is not a substitute for {{dead link}}. |url-status=dead is never needed and is always redundant. Perhaps the dead keyword should be deprecated and support for it withdrawn.

—Trappist the monk (talk) 15:11, 31 October 2023 (UTC)

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

Okay, if it's really useless, and it's causing confusion with {{dead link}}, then I'm all for the deprecation, will stop using this parameter, and will remove it (and the old |deadurl=yes) when doing cite cleanup. Update: Now not sure sure of that, given the disputation below.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC); revised: 18:16, 1 November 2023 (UTC)

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

If |url= is live when InternetArchiveBot adds |archive-url= to a cs1|2 template, it should set |url-status=live. If IABot is not doing that, you should take up the issue with its maintainer either at User talk:InternetArchiveBot or at User talk:Cyberpower678.

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

I strongly agree with @David Eppstein. @Trappist the monk removing these parameters en masse without community consensus is disruptive. Please immediately desist until you have broad support. –jacobolus (t) 22:48, 31 October 2023 (UTC)

Here's what I said at user talk:Trappist the monk: Including "url-status=dead" is much more explicit communication to human editors than just leaving url-status out entirely. It's important because the internet archive's bot (and various human editors) keep adding archive URLs to still-living pages, so the mere presence of an archive URL is not sufficient to communicate that the original page is dead, but instead what it communicates is "whoever added the archive URL was too lazy to check", which then wastes follow-up effort by other editors manually checking all of these.

conveys no meaningful information – this is not true. url-status=dead clearly communicates that the link is dead. The complete absence of such a parameter does not communicate the same thing. You should not be removing these en masse without community consensus. –jacobolus (t) 22:50, 31 October 2023 (UTC)

Agreed - the parameter is useful. There are several news sites where current live url requires subscription for full text access, but the Internet Archived version from the first day the article was live allows the user to access the full text; when I use this cludge, I do typically include some note to the reader indicating this in the citation. Regards. User:Ceyockey (talk to me) 00:28, 1 November 2023 (UTC)

Well, if you're already manually including a note to this effect, using the parameter to also signify this in a really subtle way would seem to be redundant. For most use cases, we don't have a rationale to completely suppress the link to the original URL anyway, since a source that requires a subscription is not forbidden. I think the proper thing to do is this: {{cite news |title=Maps: Tracking the Attacks in Israel and Gaza |date=October 31, 2023 |work=The New York Times |url= https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |url-access=subscription |url-status=live |archive-url= https://web.archive.org/web/20231101004026/https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |archive-date=November 1, 2023 |access-date=November 1, 2023}} I just tested in a sandbox, and this has the original URL available and flagged with the subscription icon, and the archive-url available with no such flag. People with NYT subscriptions can use the former, everyone else the latter, and if a user clicks first on the former but has no subscription and just didn't pay attention to the icon, and has to backtrack and click the IA link instead, the sky has not fallen down. Especially if you're also adding a note along the lines of "Full text available free at the archive link." PS: This cite type definitely works for NYT, and Washington Post (e.g. [1]), but I don't know if IA's archival stuff manages to defeat other paywalls. Sometimes there might not be a useful archive-url with the full text, and we might be stuck with just |url=...|url-access=subscription. So it goes.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

Adding url-status=live is obviously helpful for a live link. But adding url-status=dead is also a helpful signal for a dead link, because it is explicit rather than implicit. A human reader of either of those can immediately tell what the person who added the parameter meant, instead of being forced to guess. –jacobolus (t) 06:46, 1 November 2023 (UTC)

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

Are we certain this claim about Internet Archive Bot is correct? Does someone have a recent diff of this or any other bot adding |archive-url= without |url-status=live when the original page is in fact live? If it is happening, wouldn't the solution be to fix the bot rather than add redundant |url-status=dead to zillions of citations? Is occasional human error sufficient reason to do it? Especially when the whole point of the archive-URL is that it is working copy of the source in question, so no reader is harmed by going to that version instead of the original anyway? I'm skeptical that we should be tolerant of longwinded code bloat on a massive scale as the solution to an alleged bot problem that should be easily fixable, and a human-error problem that is like unto an innumerable number of other trivial human errors we deal with without going to such extremes. I would think also that whether or not |access-date= is older than |archive-date= is already the functional system we have for determining whether the original URL has been checked for live status when adding the archive-url, or whether someone or something just tacked one of the latter on in drive-by fashion without checking whether the status is live.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

whether or not |access-date= is older than |archive-date= is already the functional system no this is by no means adequate. It's based on a chain of dubious inferences which are regularly violated. –jacobolus (t) 06:47, 1 November 2023 (UTC)

I spot checked the first 30 or so diffs at Special:Contributions/InternetArchiveBot. I found one instance of IABot adding |url-status=live(Special:Diff/1182963903) and one instance of the bot adding |url-status=bot: unknown (Special:Diff/1182966277). To every other cs1|2 template touched by the bot, it added the superfluous |url-status=dead.

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

The bot is generally using these parameters in a reasonable way. Having the bot be explicit about whether the URL is live or dead is a good thing.

Personally I'd prefer if people (or bots) never prophylactically added archive links to still-living pages except in special circumstances with some human intention involved (e.g. the "living" page is paywalled). –jacobolus (t) 14:04, 1 November 2023 (UTC)

The purpose of |url-status= is to tell Module:Citation/CS1 what to do when presented with both |url= and |archive-url=. In the absence of |url-status=, Module:Citation/CS1 defaults to linking |title= with |archive-url=; this is the module's default case. Setting |url-status=dead does not instruct the module to do anything different from its default (thus my conveys no meaningful information comment). The addition of |url-status=dead is therefor pointless, redundant, code bloat, clutter, pick your favorite term. Parameters that accomplish nothing have no value so should be removed.

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

The purpose of url-status is to communicate the status of the URL, both to the citation rendering template, and also to human editors. –jacobolus (t) 14:05, 1 November 2023 (UTC)

The purpose of |url-status= is to control the selection of the live URL or the archive URL, as the documentation has always shown. It does not and has never been for the url-status of the source, does that make it confusing named - yes - should it be used to show the status of the URL - no that's what {{dead links}} is for as that template actually shows the link is dead to the reader (url-status=dead give no display output to the reader). -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:20, 1 November 2023 (UTC)

The way you tell *readers* that the link is dead is by switching the order of the links and making the archive link primary. The way you tell markup-reading *editors* that the link is dead is with the "url-status" parameter. Leaving this parameter out entirely is not explicit enough to clearly communicate the status of the URL. When the parameter is left out, human editors will waste their time double checking all of the links, because the status is not communicated clearly and unambiguously. –jacobolus (t) 22:52, 1 November 2023 (UTC)

To be more concrete/explicit, it is confusing to have:

No archive URL → url-status is implicitly alive

Archive URL → url-status is implicitly dead

This is okay as a fallback interpretation, but it is much better still to have an explicit url-status included whenever there is an archive URL, because it is then entirely clear what was intended and what the most-recently-checked URL status is. An editor who checks the link can just change dead ↔ live as needed. –jacobolus (t) 23:01, 1 November 2023 (UTC)

I think we're just saying the same thing slightly differently and from different directions. I agree that url-status is used to select whether the URL or archive URL is used.

The problem is that editors use it when no archive URL is present. So the URL is dead, no archive link is present, and they set |url-status=dead rather than use {{dead link}}. It's that scenario I'm saying is wrong. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:09, 1 November 2023 (UTC)

The problem is that editors use it when no archive URL is present – this is different than the problem I am complaining about, which is semi-automated edits which do nothing but remove url-status=dead from links that have an archive link. –jacobolus (t) 23:39, 1 November 2023 (UTC)

Yeah I thought we were talking at cross purposes. I'm against editors mass removing these, it's just a pain that it gets misused a lot. Editors also incorrectly add |url-status=live to cites with no archive url, which does generally get removed. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 01:56, 2 November 2023 (UTC)

Though it might not be a bad idea to allow url-status=dead even without an archive link, and format the output the same as {{dead link}} in that case. –jacobolus (t) 23:42, 1 November 2023 (UTC)

Which guidance does it violate, when a link is dead, an archive exists, and no alternative url is found hosting the information, to set the |url=(archive page)? I'm pretty certain this is against some policy or another, but I'm not sure which one, and it seems like a natural shortcut when citing deadlinked sources. Folly Mox (talk) 00:41, 2 November 2023 (UTC)

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

I'd be happy with renaming the field |archive-req= with yes/no/usurped/deviated being the answers, but at this point that would probably break to many things. My point was that it's not a field to mark the URL status, it's for showing which URL to use. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:17, 1 November 2023 (UTC)

Yeah, that would lead to massive breakage. And it's not clear what it even means ("archive-req"?).  — SMcCandlish ☏ ¢ 😼  10:19, 4 November 2023 (UTC)

Well, someone's still removing |url-status=dead from random articles, but I don't get the sense that there's actually a consensus in favor of the idea. I like the notion of removing any parameter that is actually redundant, but in fairness I'm not certain this is seen to be reundant, regardless what the original idea for implementing the parameter was. But that kind of concern in and of itself has not always won the day (e.g., I and others were basically just overridden on the use of |access-date= as an indicator of when someone last actually looked at the source, of any type, to see whether it agreed with the content it was cited for, and it has been disabled for anything without |url= because the original idea of the parameter was supposedly just indicating when the URL was checked to be valid/loading at all). People can have different points of view about these things. I am fairly certain that MEATBOT-style removal of |url-status=dead should probably not be happening while this discussion is unsettled, though. (Just as I have stopped normalizing ISBNs to hyphenless form since there's a discussion open at VPPOL about what should be done).  — SMcCandlish ☏ ¢ 😼  10:19, 4 November 2023 (UTC)

I continue to remove the parameter when it appears in an article of interest, though it's not a category I focus on. I do so for the same reasons as presented by Trappist, and for the same rationale for the parameter's creation. Izno (talk) 21:13, 4 November 2023 (UTC)

To some degree, I find it ironic and/or hypocritical that in the very same section we have people arguing that |language=en is cruft and unnecessary and to be removed despite at least one valid use case, and |url-status=dead (for dead URLs) is not. Izno (talk) 21:15, 4 November 2023 (UTC)

In my opinion, language=en is by far the majority case, and very obviously implicit for every citation and not at all a point of confusion. Also even for non-English links, leaving out an explicit mention of which language the citation is in is a kind of trivial oversight of minimal harm to readers (because for example the title is usually written in that language; someone seeing a source with title in German or Latin is not going to be excessively surprised that they don't get an English page when they click). There really isn't any need to be explicit that every ordinary citation to a source with a title and other metadata written in English points to an English language source. So including that parameter redundantly is pointless cruft. I don't mind if someone copy/pastes a citation from another language wiki and happens to leave language=en; in that instance its presence isn't doing any harm and doesn't need to be immediately cleaned up or anything. But I definitely don't want us to have a bot crusade inserting language=en to every citation site-wide, which would be extremely obnoxious to say the least.

By contrast, citations to web pages which also include an archive link are not inherently obviously aimed at a dead link. An archive link might also be included because e.g. the original source has since been put behind a paywall, or because the IABot or some editor trying to be helpful has obnoxiously added a "prophylactic" archive link to a still living page. Interpreting the presence of an archive link without any explicit mention of the URL status to mean the archive link should be primary is an okay default fallback (we have to assume something in this case, and neither choice is a priori obviously correct). But having an explicit parameter is better, because it communicates clearly to human editors examining the source. This parameter is not pointless, even if its presence does not change the rendered output. Having a bot or meat bot remove url-status=dead at large scale based on personal preference of one editor is also super obnoxious. –jacobolus (t) 23:07, 4 November 2023 (UTC)

But having an explicit parameter is better, because it communicates clearly to human editors examining the source. Agreed and that parameter is |url-status=live; that parameter and value not present? Assume dead.

—Trappist the monk (talk) 23:24, 4 November 2023 (UTC)

You can't say exactly the opposite of my point and then summarize that as "agreed". Come on... –jacobolus (t) 23:32, 4 November 2023 (UTC)

Apologies for necroing this thread, and so deep in the indents no less, but I noticed that User:Citation bot is removing |url-status=live from live URLs, and I immediately thought of the exchange just above. Do we, ultimately, have any idea what the default / unset value for this parameter indicates? Folly Mox (talk) 09:56, 3 December 2023 (UTC)

It's not "ironic and/or hypocritical" to oppose inclusion of one parameter and support keeping another for completely unrelated reasons. The "valid use case" for |language=en has been quite thoroughly refuted by multiple editors, and when the other side is asked for a better use case (and they keep saying they've seen one), they wave their hands and walk away. When it comes to |url-status=dead, a very broad, works-for-everyone use case has been presented, and the response so far as been an argument that the original purpose of the parameter was something different, and that there are technical alternatives (I even suggested one myself). These situations are not even slightly parallel. But my point is a process and propriety one, not a keep/kill that parameter one: there is an active dispute about this particular parameter+value, |url-status=dead (a dispute in which I'm now neutral), but at least two of you are still going around removing it at will despite vociferous objections. I may disagree strongly (and I do) with the objections to removing |language=en, but I have still stopped removing it until that dispute resolves, whether that happens tomorrow or in ten years.  — SMcCandlish ☏ ¢ 😼  23:41, 4 November 2023 (UTC)

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

When I and at least one other editor point out that the "need", flagged as the reason to keep doing this stuff all over our articles, is better handled at the other end by the template-translation scripting, that is in fact a refutation. You can try to mount a rebuttal to that refutation, but a false claim that the original proposition was "willfully ignored" is simply untrue and does not consititute a rebuttal of any kind. It's just silly handwaving. I've asked at least 4 times now for vague and also handwavy claims that someone has seen (at some time, somewhere) some other, different translation-related use case to be substantiated with details, so that this alleged use case can be examined, and no one's done it. This is just blowing of smoke, and it's not going to fool anyone.  — SMcCandlish ☏ ¢ 😼  13:29, 5 November 2023 (UTC)

Everything I brought up you just handwaved away as not actually a problem, and swept it under the carpet. As I said above I'm not going into this again, but to say it's been refuted is not true. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:13, 5 November 2023 (UTC)

When someone complains of you engaging in a behavior like handwaving instead of producing evidence, you just using the playground game of "no I'm not, you are!" by using the term back at them reflexively is not a cogent argument, especially when they are not in fact doing it too. Nor is pretending that your evidence or concerns were ignored when they were actually addressed in considerable detail. The fact that the translation issue you want to solve has multiple technical solutions, and one of them is simple and clean (write a better translation script that does sensible things like assume English by default when translating from en.wikipedia) while the other is a total trainwreck (inject redundant code blather millions of times into en.Wikipedia articles) just is as it is. It doesn't make someone somehow in the wrong for pointing this out to you (even if takes multiple tries to get you to hear it). No one is doing you any form of injustice or eganging in bullshitty argumentation tactics with you, and no one is magically obligated to feel convinced by arguments you're impassioned about for some reason, when they don't actually align with the facts at hand and reasonable conclusions drawn from them.  — SMcCandlish ☏ ¢ 😼  15:39, 5 November 2023 (UTC)

I told you how it currently works in the real world and you completely ignored it, as you did any other argument made, at which point I have up trying to convince you as it's obvious you are unwilling to be convinced. You are the one handwaving away anything that doesn't align with your opinion and then saying I haven't produced any argument. I'm sorry if the way the real world works doesn't align with your opinion, but please stop trying to project that onto me. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:39, 5 November 2023 (UTC)

This is more bald-faced proof by repetitive re-assertion, and more childish and nonsensical "maybe I can WP:WIN by taking my opponent's words and just shuffle them around to refer to him instead of me" stuff, so I'm simply not going to respond to you any further.  — SMcCandlish ☏ ¢ 😼  16:55, 5 November 2023 (UTC)

FFS your entire argument against anything I've said has been that it doesn't apply. I already said I was done with this, but you started it up again. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:07, 5 November 2023 (UTC)

Let me try to paraphrase your argument in the various above posts, as best I understand it:

Some automatic tools for helping editors translate wiki pages from French -> English let them copy/paste citation templates unchanged, and a bot comes to clean up the citations. If those citations have language=fr explicitly set on them (is this common?), it will also be set in the English page, but if they don't, then the tools/bot doesn't add it and then the resulting English wiki page won't explicitly specify that citations are in French unless a human editor spends the trivial amount of extra manual effort adding it. You once saw a discussion somewhere which you now can no longer find, in which some editors on the English wikipedia said they want to provide the same service to foreign language translators, so have started adding language=en to their citations. Instead of removing those, we should follow their lead and add language=en widely, because it doesn't take up much space and would provide a nominal service to other language wikis.

Is the above fair, or do I entirely misunderstand what you are arguing for. I also have found it very vague and unconvincing overall. –jacobolus (t) 16:58, 5 November 2023 (UTC)

Fair enough, I don't mind if you disagree (WP:SATISFY), but that's a long way from saying that my arguments have been completely refuted.

As to the translation automation, that's just how it works. If anyone wants to change the real world situation, they should go talk with the people maintaining the translation tools. It's something way beyond the purpose of this talk page.

Also again this thread is not about, and I have not advocated for, the addition of |language= to any cites. I'm against mass removing ones that are already there. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:13, 5 November 2023 (UTC)

I also don't think language=en should be mass removed, because it's annoying churn for a triviality (cf. WP:COSMETICBOT). But often if I manually edit citations that have language=en set on them, I remove it.

Do you have a problem if language=en is removed alongside other more substantive edits? Or is your position that language=en should be left alone whenever it was set? –jacobolus (t) 17:23, 5 November 2023 (UTC)

I don't, as I believe it is useful for certain editors, but I have no great urge to restrict the actions of other editors. I am opposed to "it serves no purposes and should always be removed". -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 5 November 2023 (UTC)

I would still characterize it as serving no purpose. The claimed "purpose" is trivial and almost entirely hypothetical. In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally (which is fine; it does little harm to leave this as a no-op). –jacobolus (t) 18:03, 5 November 2023 (UTC)

In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally Where are you seeing errors? There should be no errors related to |language= but there is a maintenance message when |language= is assigned a value that cs1|2 (MediaWiki) does not recognize (see Category:CS1 maint: unrecognized language).

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

Yes, there are no errors. That's the point. It would be bad for language=en to throw an error, even though it doesn't do anything. Making this a no-op that people are free to remove at leisure is an appropriate behavior here. –jacobolus (t) 19:10, 5 November 2023 (UTC)

If you feel it's trivial fair enough, but I'm sorry I really struggle to understand how the issue is hypothetical when it is how the translation of cites currently works. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:13, 5 November 2023 (UTC)

It's hypothetical insofar as something 99% of current citations on on this wiki to English language sources do not include this parameter, so anyone translating an arbitrary English wiki article to Russian or whatever is going to need to manually check every one anyway, so that this is not saving them any appreciable amount of effort.

If we care strongly about this particular group of users, it would be much more useful to fix the English -> X language tool to automatically fill missing language params with the implicit "en" instead of trying to expand the number of references here with language=en explicitly specified.

If that's the only purpose you can come up with for specifying 'language=en', then I say it should be fair game to eliminate them here. But bots and meat bots: please only make this kind of trivial change in a trickle alongside more substantive changes, instead of spamming everyone's watchlists with cosmetic changes. –jacobolus (t) 19:18, 5 November 2023 (UTC)

If you don't believe the use case is noteworthy I won't argue. But I believe we should be encouraging not discouraging the inclusion until someone bothers to change the translation tools. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:49, 5 November 2023 (UTC)

I concur with jocobolus, word-for-word. And as I predicted, the end goal of the other side on this matter is "encouraging ... the inclusion" of |language=en, spreading it to more and more citations, just as I said it was, but I was accused of straw-manning. Are we done now, or is there additional evidence and reasoning to present? This so far has been a complete rehash of the previous cycle.  — SMcCandlish ☏ ¢ 😼  19:55, 5 November 2023 (UTC)

That's what I believe, but as I've said repeatedly I don't support any official change to policy or documentation. Also your comments, particularly "of the other side", just shows the battleground mentality you've shown in this discussion. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:07, 5 November 2023 (UTC)

Every dispute has two sides (if not more). Using plain English is not a transgression. Casting "parting shot" aspersions at people's "mentality" and accusing them of battlelgrounding is not a good look. When I make a proposal (which happens all the time), if I find that is isn't going anywhere despite my efforts to outline my rationale (also happens all the time), I just walk away. There is no need to throw the rude gesture at those who didn't agree with you as if they're bad people for not taking your side (yes side – it's the completely normal term for this) in the discussion. All this personality stuff aside: What we have here is a conflict between a "Why can't we just do something nice for these folks doing hard work" sentiment running into facts that the proposed thing to do is not practical, there is a better solution immediately obvious, and doing it the proposed way will turn into a bigger and bigger mess, harder and harder to clean up later, the longer it operates. Not every well-intentioned idea is one we should go with.  — SMcCandlish ☏ ¢ 😼  20:57, 5 November 2023 (UTC)

I'm not going to read that I don't think it's going to get any better. I'm at a lose as to why a discussion about 12 characters in a cite has become so hostile. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:50, 5 November 2023 (UTC)

I don't think anyone's angry with you, doesn't like you, or is otherwise exhibiting hostility. People just disagree about things, including the weight of evidence and the solidity of reasoning given as rationales in discussions. No one enjoys being disagreed with (probably?), but disagreement happens, and it doesn't mean you're under attack or that people have a personal bone to pick with you. Hope that helps.  — SMcCandlish ☏ ¢ 😼  14:28, 6 November 2023 (UTC)

I'm sorry but I disagree you level of personalisation has been striking. I don't need any help I'm just confused by that level heat over something so unimportant. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:27, 6 November 2023 (UTC)

You keep saying things like "something so unimportant" and "only 12 characters", but two of us have repeatedly pointed out to you that 12 (often 15) characters repeated millions of times is not trivial, but you dodge this and keep re-asserting that it's just 12 characts and unimportant. You must understand that this is frustrating and comes across as refusal to engage meaningfully in the discussion.  — SMcCandlish ☏ ¢ 😼  17:05, 7 November 2023 (UTC)

Unless you believe I am lying I do not have to prove anything. You can accept my points or not, but everytime I have made a point you have attacked the comment not it's substance. So no, I have no more desire to continue this discussion with you.
And yes it is a minor thing. A million times 12 characters is a drop in the ocean of billions of markup characters. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:33, 7 November 2023 (UTC)

An assurance approximately equivalent in utility to |<citation verifies previous sentence>=y. My observance is that the real focus of all this arguing should really be pointed to ensuring that each and every live link that argues it's live (with or without an archive link) to be checked for liveness. I have spent quite some time in the general hitting ostensibly live citations that aren't (for which I have done the good duty of finding them appropriate archive URLs). Izno (talk) 21:17, 4 November 2023 (UTC)

Ah, but |<citation verifies previous sentence>=y gives us license to remove driveby {{cn}} tags slapped down in haste by editors with no time to check the source cited one sentence later. Folly Mox (talk) 23:29, 4 November 2023 (UTC)

Just a minor point - but language=en will have occasional use to the reader - when the title of a source isn't in the English language but the source is, or in the case of an English language article in a journal that is primarilary written in a non-English language. While these occasions may be rare they do occasionally happen.Nigel Ish (talk) 23:14, 26 December 2023 (UTC)

I read the entire thread about url-status-dead (minus the namecalling and tangential topic of language=en) and here is my analysis.

When you write for a computer, you have to give explicit directions such as "If A, then B, else C". For example: If url-status is live, then use the url, else use the archive-url.

But HUMANS don't think like that! They read "url-status=live" and they think "ah hah, that is the primary url". Or they read "url-status=dead" and they think "oh dear, original url is dead so I'll use the archived url". But when HUMAN reads "(blank)", they think "oh no, I'm not sure which one of the two urls is the correct one!" And that is because omissions are AMBIGUOUS, and a single-sentence inserted into the [very lengthy] written instructions of Template:Cite web simply isn't sufficient to turn the average wiki editor into a computer programming thinker (if they even notice that single sentence).

Those of you arguing for the machine-read version and removing url-status=dead as obsolete or null, are dealing only in computer programming concepts. Those of you arguing for the human editor to keep url-status=dead are recognizing the human mind's natural way of dealing with omitted information. Even the experienced long time wiki editors are arguing for keeping url-status=dead as the more natural and clear communication to editors. We write wiki policy for editors... not computer programs. We get consensus from editors, not the few programmers, because the website is used by the editors every single day.

Since programming is the province of computers, BOTs, and rendering software, and programming them need only involve the few techies on the website, and only involve programming the defaults once and done, I fail to understand why some of the tech-minded are arguing so hard to continue removing an explicitly written parameter that seems so helpful or valuable to human editors every single day, for every article, for every citation. The programmer may be done with their work, but the human editor has to deal with it over and over again. Removing url-status=dead just because "the computer program doesn't need it" or "we never thought the humans would misunderstand (or ever find useful) this parameter we created for our computer program" are not just lame arguments, but ones which ignore the real life consequences: ongoing confusion, misunderstanding, uncertainty, and extra effort (to name just a few).

Yes, I use url-status=dead and I like it. I tend to cut-and-paste urls directly from the CODE and paste them in a new browser window, rather than click on urls from the rendered wiki page. I'm sure I'm not alone in that practice.   ▶ I am Grorp ◀ 08:34, 21 January 2024 (UTC)

Allow setting doi-access to registration or limited

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

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

I could see adding |doi-access=registration as a valid access indicator (and I think this might help with some of OAbot's unaddressed misbehavior), but |doi-access=subscription is like |url-access=free. I would not want to see bots adding zillions of understood default access indicators, or their associated lock icons in reference lists, which would be the outcome of enabling the specification of the default value. Folly Mox (talk) 11:56, 30 November 2023 (UTC)

Good point, I mixed up. I meant it should be possible to explicitly set it to registration or limited, while "subscription" would be the default (still considered an error if added explicitly, as it is now). Nemo 11:59, 30 November 2023 (UTC)

The case I highlighted which started the discussion referred to by Nemo is doi:10.1001/jama.2009.405. There seems to be a difference of opinion whether this can be described as doi-access=free. My interpretation is that this source is indeed compliant: the webpage that is the target of the doi has the full text and that text can be downloaded by simple copy-paste, if the reader so desires. (To download a .pdf a user must provide their email address.) I don't see this as a grey area: citations are there in Wikipedia articles so that readers can verify that the source supports the text and using doi-access=free makes the title of the work a direct link to the place that the text is hosted and can be read by anyone. Mike Turnbull (talk) 12:03, 30 November 2023 (UTC)

To avoid more important work, I verified that the full article and all figures and tables present in the PDF are duplicated on the webpage. The only content lost is the page numbers. I think I'd characterise this as "free to read for anyone" and hence a poor example, but the problem described may actually exist: dois that offer only a preview for all viewers, but access to the full source for non-pay-for registered accounts. Folly Mox (talk) 12:33, 30 November 2023 (UTC)

I've seen OABOT removing many doi-access=free tags today from articles that appear to be completely free to read on the publisher's web page. I think we should leave those tags in place, because they are free to read. As you say this should only be for works where the full work is viewable, but I don't think freedom to reuse under an open license is relevant or necessary. —David Eppstein (talk) 23:14, 2 December 2023 (UTC)

Agreed. I just saw one of those, too.  — SMcCandlish ☏ ¢ 😼  11:32, 3 December 2023 (UTC)

And reverted it.  — SMcCandlish ☏ ¢ 😼  12:46, 3 December 2023 (UTC)

@Nemo bis Here's another removal that is perhaps understandable if you are a bot rather than a human. The relevant doi is doi:10.1016/0016-5085(92)91094-K. Click the link and it will open the actual article on the website. However, the URL is interesting: https://www.gastrojournal.org/article/0016-5085(92)91094-K/pdf?referrer=https%3A%2F%2Fen.wikipedia.org%2F includes the fact that this is has been a request from wikipedia! If you use the link https://www.gastrojournal.org/article/0016-5085(92)91094-K/ in a browser tab not associated with Wikipedia, you get to the publisher's web page, where there is a comment saying that the paper is only available as a .pdf. Humans can read that advice and do indeed get free access to the .pdf with one more click. Mike Turnbull (talk) 14:08, 3 December 2023 (UTC)

There was no excuse at all for this removal for doi:10.1139/v84-243 and I urge you to stop the bot immediately and revert all such removals. It might be better to permanently disable all free -> blank interventions and focus on the more useful blank -> free. Mike Turnbull (talk) 14:29, 3 December 2023 (UTC)

I'm not sure how this is relevant to this discussion. Anyway, the bot has already stopped removing doi-access=free. Can we go back to whether we can use doi-access=registration or doi-access=limited where the publisher requires login? JSTOR comes to mind, but I can find more examples if useful. Nemo 21:47, 3 December 2023 (UTC)

Here are some example DOIs from the JSTOR prefix, which are currently cited with doi-access=free but actually require registration: doi:10.2307/1378152, doi:10.2307/3632910, doi:10.2307/3496680, doi:10.2307/2324301, doi:10.2307/2371798. On phabricator:T344114#9392971 you can see how they're displayed to me. How are we supposed to mark these? Do I have to go through the entire registration process to check whether I will actually be able to read and download the file without paying? And how will I know that the requirements are the same in another country? Nemo 14:31, 8 December 2023 (UTC)

Please make the values of this |doi-access= be consistent with |url-access=. A |url-access=registration means a free registration while |url-access=subscription means a paid one. Needs to be the same for DOI. A JSTOR DOI is not free-registration but subscription-required.  — SMcCandlish ☏ ¢ 😼  22:10, 17 December 2023 (UTC)

I'm a bit confused here. The first two DOIs linked above don't even resolve to Jstor for me. They go to ucpress and oup. In my region, Jstor offers the option to sign up for a free personal account which will allow for reading "100 articles per month", and downloading zero. I have no idea how to determine whether any given article would be part of their "free reading" subset or still paywalled for institutional subscriptions only, or if such a stratification even exists. I note without additional relevant comment the |jstor-access= parameter, which I'm not sure I've ever seen used in the wild, although I've added it myself once or twice. Folly Mox (talk) 00:45, 18 December 2023 (UTC)

This is why we need to include the jstor= parameter even when we have a doi that looks like it comes from jstor. I see the same as you, UCP and OUP on the first two links. But (on my home IP address, at least) I don't have access to the OUP and UCP, and I do have access to jstor. So I would be able to read those references much more easily with a jstor= link than with a doi= link. —David Eppstein (talk) 00:53, 18 December 2023 (UTC)

Indeed "JSTOR prefix" is a simplification, as many of those DOIs belong to some publisher which presumably had an agreement with JSTOR. When the publisher is the destination of a 10.2307 DOI, usually that's because they're trying to sell access, and therefore JSTOR doesn't provide an open access copy. Restrictions on such works, even when one lands directly on the JSTOR side, are constantly changing. Therefore a doi-access=free is misleading. Nemo 14:38, 31 December 2023 (UTC)

Another example: a journal which requires you to register and remain subscribed to a newsletter in order to receive a PDF copy by email (phabricator:F41641477). Apparently the journal markets itself as open-access (and it used to be around 2022). Possibly a doi-access=registration would be warranted (but I've not checked whether registering actually provides access). Nemo 14:38, 31 December 2023 (UTC)

Successions of REF-plus-Rp pairs

Not a Cite template matter, but one to which Cite template experts might know an answer.

I have perpetrated a sentence, which, thanks to four reference+Rp pairs, ends, quote, ^{[5]: 128–131, 141–143 [11]: 46 [2]: 111–114 [3]: 301–302, 304–305}, unquote. (With some underlining and slightly different coloring.) Now, I know that this should be understood as something like ^{[5] 128–131 & 141–143; [11] 46; [2] 111–114; [3] 301–302 & 304–305}; but most readers may not. Any suggestions on how to make it easier to understand (and less horrid)? (And yes, I do realize (i) that having more than two references for a single assertion is usually poor practice and often is a doomed attempt to make up for the feebleness of each of those cited sources; and (ii) that 5, 11, 2, 3 is not the best order for them.) -- Hoary (talk) 09:10, 16 December 2023 (UTC)

This to me is a very clear case where WP:CITEVAR ("let a thousand flowers bloom") should be ignored and the citation style changed to Harvard (using {{sfn}} or {{sfnp}}). That would still give you six cite references (!) but at least they would be less obviously prolix.^{[51][52][110][31][32]} Mouse over on each would reveal the source and page number e.g. Livingstone (1871) 128–131. 𝕁𝕄𝔽 (talk) 16:53, 16 December 2023 (UTC)

It's not clear to me why you would want to use six {{sfnp}}s where four would suffice, with two including multiple page spans. There is of course the alternate solution {{sfnmp}}, which has slightly weird syntax, sounds like a noise your pet might make immediately prior to generating a cleanup task, and leaves the prose with a single reference. Another way to do that is stack a bunch of {{harvnb}}s inside a pair of ref tags, separated by semicolons or periods.

But yeah when your clicky numbers start looking like this, your citation style has been pushed beyond its capacity and it's time to toss in some shortened footnotes. Folly Mox (talk) 23:58, 16 December 2023 (UTC)

This is a perfect example of why {{rp}} is an abomination and should never be used. —David Eppstein (talk) 00:40, 17 December 2023 (UTC)

As the creator {{rp}} (back when it was actually necessary due to lack of alternatives for particular cases), I would agree that it is obsoleted by methods like those described here, and in more complex cases by |ref=, as I "tutorialized" over here. (Though some of that can also be pulled off by use of existing templates, there are so many, so unclearly named, that I sometimes prefer to just use |ref=Smith2023 and <ref name="Smith2023 p123">[[#Smith2023|Smith (2023)]], p. 123. Optional annotation here.</ref>.) I'm not really sure how to go about deprecating and replacing {{Rp}}. Probably would need really good documentation on alternatives, and how to do conversion from it to a variety of practical and in-use, modern citation approaches.  — SMcCandlish ☏ ¢ 😼  16:44, 17 December 2023 (UTC)

One thing that would facilitate deprecation of {{rp}} (59073 transclusions), that is actually relevant to this page, would be some general way for "entire span of pages" and "specific page(s) supporting cited claim" to coexist within a citation template without the inclusion of a quote. This functionality would obselete all uses of {{rp}} where the source is an article or chapter and only one place in the source is used to support any article prose. (Additionally, this would give the "total length of work" bibliographic detail often created by scripts for gbooks refs a parameter to live inside that doesn't make it look like the cited claim is sourced to the final page of the index.)

The ideal would require dev support, but being able to add a loc parameter to named ref tags would basically completely duplicate {{rp}}'s functionality, although where to display the value held in loc in the on.hover / on.tap popup might get a little bit messy if the named ref contains anything other than a single citation with no postscript. Folly Mox (talk) 17:21, 17 December 2023 (UTC)

Hmm, but {{rp}} doesn't relate to any distinction between "entire span of pages" and a specific page or page-range being cited; it is just like |page= or |pages= in being specific, and differs from them in living outside the cite template so that different pages in the same source can be cited, because {{cite book}} or whatever can have only one of |page= or |pages=. We have a whole pile of shortened-footnote templates that support page numbers down and do this without leaving ^:113–123 "droppings" all over the article text. Having a separate parameter for total pages in the work wouldn't affect this in any way. It's been proposed before to have such a parameter, but it's been rejected because that's not citation information but bibliographical catalog information of no use to finding and verifying the source, any more than a parameter for size or for paperback vs. hardback or for unrevised printing/impression of the same edition. If there are user scripts and other tools mistakenly putting total page count into |pages= they need to be fixed to stop doing it (chief among them being CitationBot, which has been doing this to journal article citations, even up to replacing specific-page citations with full-page ranges, which is doing outright violence to the citation). I think you're proposing to change |page[s]= to be for that total-pages purpose and a new |loc= (how would that differ from |at=?) to take over the specific-page-citation function, which would mean that all of millions of citations with a page cited would have to change. A |loc= would be confusable with publisher's |location=, too. Plus, if we try to depend on changes to <ref> coming, we'd be waiting many years. Now I sound like a just a very dedicated naysayer. [sigh]

Getting rid of {{rp}} is really a matter of replacing it and citations using it with other templates ({{sfn}} and {{harvp}} and all the too-many variants of these things); it's primarily a matter of documenting how to do it in really simple terms for each kind of case. A lot of work up-front for someone, but most of the conversion work could be done by AWB users, across large swath[e]s of articles, after it's documented (and well enough to account for weird cases).  — SMcCandlish ☏ ¢ 😼  22:05, 17 December 2023 (UTC)

Well, the idea of loc was for use inside ref tags, and I agree that it would not be an appropriate name for a parameter inside a citation template. Perhaps I should just drop that idea entirely since it's a phab task anyway, and unlikely to get buy-in, etc.

Briefly, there is one use case for {{rp}} that would be obseleted by a |total-page-span=: the case when a source is cited only once, but is identified in the full citation with a page span (like a book or chapter), and doesn't include a quote (which would allow for the use of |quote-page=, already implemented). This parameter could help protect citations against Citation bot and others that find it somehow beneficial to replace page citations with the full page span of the source (which is damaging). Anyway, this wouldn't help much, and it's probably not the way to go, so apologies for the digression. Folly Mox (talk) 00:56, 18 December 2023 (UTC)

No wories, and sorry I didn't get that you meant <ref loc="something"> Honestly, I've never actually encountered |quote-page= in real-article use, so I'm not sure it would factor much into the {{rp}} mess or its cleanup. Doing my part, I did eliminate an {{rp}} just now, though; like swatting a mosquito. I've been pondering how to document a "Getting rid of Template:Rp" process; I guess no one else is going to do it, and I'm ultimately the Frankenstein responsible for that monster in the first place.  — SMcCandlish ☏ ¢ 😼  02:33, 18 December 2023 (UTC)

Thank you for all the commentary, peeps. I've never liked either adding or digesting these alternatives to REF+Rp, but I should reconsider them afresh. -- Hoary (talk) 08:47, 17 December 2023 (UTC)

I ran into a problem like that while working on Newton's laws of motion. By the nature of the topic, a statement is likely to have many equally good and accessible references, most of which are books that are thick enough to make page numbers more than a convenience. Moreover, each book will be cited in multiple places, with different page ranges for each. I didn't want to abandon the existing reference style, so I ended up writing manual footnotes with {{refn}}. That let me break up the reference-{{rp}} pairs with author names and other information like quotes from the relevant pages.

The methods described above all have their virtues. Any one of them could probably work, as long as your passion for proper referencing shines through. :-) XOR'easter (talk) 16:09, 17 December 2023 (UTC)

IMHO, this is a perfect poster child for hierarchical references, e.g., an |under= parameter that makes a citation subordinate to another, named, citation, possibly with sorting of the subordinate citations at a given level. I'm not sure whether that's doable as an extension of the existing <ref>...</ref> and {{cite}} or whether it would require new templates (CS3?). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:19, 29 December 2023 (UTC)

@Chatul: This is something the WMF have been attempting to bake into the underlying technology for years. See [2] & [3]. They have some demos working but haven't implemented support for the Visual Editor, iOS app, Android app, or ProveIt yet. Rjjⁱⁱⁱ (talk) 20:00, 29 December 2023 (UTC)

Expanding exemptions to CS1 error categories

Can pages beginning Wikipedia:Articles for deletion not be placed into the CS1 error categories? This would affect around 281 pages, as well as preventing new AfDs and new error modes from populating. Editing closed AfDs to fix errors is considered annoying. Folly Mox (talk) 15:54, 25 December 2023 (UTC)

I would not support this change, if it were technically reasonable to do. Editors are welcome to leave such articles in error categories until the AFD is concluded, or fix the errors in order to improve the article while it still exists. One way to get articles out of AFD is to improve them, as long as the subject is notable. – Jonesey95 (talk) 21:53, 25 December 2023 (UTC)

I was thinking of the actual AfD discussion pages (prefix:"Wikipedia:Articles for deletion"), not the articles themselves that are under discussion (Category:Articles for deletion). Folly Mox (talk) 22:39, 25 December 2023 (UTC)

My mistake. I still would not support this exception. Just fix the error and move on. – Jonesey95 (talk) 19:43, 26 December 2023 (UTC)

Meh. I've 'fixed' lots of WP:AFD discussion pages and similar discussion-like pages in Wikipedia and other non-article namespaces with |no-tracking=yes with never a complaint. That 'fix' leaves the broken cs1|2 template broken but gets the offending page out of whatever category.

—Trappist the monk (talk) 23:18, 25 December 2023 (UTC)

Sounds like as long as I'm not blowing up watchlists with high volume fixes like MalnadachBot, this task is acceptable to perform. I work pretty slow, so not too concerned.  Request withdrawn. Folly Mox (talk) 21:46, 26 December 2023 (UTC)

Citing an "unpublished" MS

• Hayter, Keziah Elizabeth. "Diary of Kezia Elizabeth Hayter" – via Libraries Tasmania.

-- is of course published, thanks to Libraries Tasmania, even though not conventionally published. And while we should reject sources that lack editorial oversight (etc), this MS is, I presume, a decent reference for any claim that it says this or that (even though I find the damn thing near indecipherable). But I don't think its title is "Diary of Kezia Elizabeth Hayter"; it simply is her diary (or part(s) thereof); and the library's MS number NS202-1-1 ought I think to be easier to see. Yet there's no "Template:Cite manuscript", or, as far as I know, anything similar. Am I missing anything here? (If I stick with Cite web, can I improve on my use of it?) -- Hoary (talk) 23:55, 25 December 2023 (UTC)

I don't think that I would use that source as a source (perhaps further reading...) because Wikipedia does not care what the subject says or wants to say about itself, no editorial oversight, etc. But were I to use that source, I'd stick with {{cite web}} but instead of |via=, |website=; I'd reduce the title so as not to be redundant; include |date=:

{{Cite web |last=Hayter |first=Keziah Elizabeth |date=1842 |title=Diary |website=Libraries Tasmania |url=https://stors.tas.gov.au/AI/NS202-1-1}}

Hayter, Keziah Elizabeth (1842). "Diary". Libraries Tasmania.

—Trappist the monk (talk) 00:30, 26 December 2023 (UTC)

Trappist the monk, I think the use of the diary (in Kezia Hayter) is OK. (Just don't ask me to ruin my eyesight and tire my brain attempting to read it.) But others are free to disagree and to act on their disagreement. Thank you for the formatting advice; I've adopted it, mostly. -- Hoary (talk) 01:16, 26 December 2023 (UTC)

(For my own edification, what does 'MS' expand to here?) Remsense留 01:20, 26 December 2023 (UTC)

Manuscript. isaacl (talk) 01:27, 26 December 2023 (UTC)

Thank you kindly. Remsense留 01:28, 26 December 2023 (UTC)

It is a WP:PRIMARY source, acceptable in moderation. There is also {{cite document}} which provides for the |type=file and link the URL in the |id= :

Hayter, Keziah Elizabeth (1842). "Diary of Kezia Elizabeth Hayter" (File). Hobart A 243 3: Libraries Tasmania. NS202/1/1.{{cite document}}: CS1 maint: location (link)

Probably best to use the full name of the file on location in the library. I also added the library location. -- GreenC 01:29, 26 December 2023 (UTC)

That seems very helpful, but I'd noticed Template:Cite document and had rejected it as intended for "short, stand-alone, off-line documents", which I took to mean individual letters, leaflets, posters and so on, rather than for anything with dozens of pages. -- Hoary (talk) 01:54, 26 December 2023 (UTC)

Could you also use |type= to hold "diary" and the title for the item number:

• Keziah Elizabeth, Hayter (31 December 1842). "NS202-1-1". Libraries Tasmania (Diary).
• {{cite web |last=Keziah Elizabeth |first=Hayter |type=Diary |title=NS202-1-1 |date=31 December 1842 |website=Libraries Tasmania |url=https://stors.tas.gov.au/AI/NS202-1-1}}

Rjjⁱⁱⁱ (talk) 03:58, 26 December 2023 (UTC)

Hoary if your concerned by the "short" qualifier in cite document, you should be even more concerned by "cite web", since the document is not available on the web. I'm not sure who wrote the documentation for "cite document" or why they added a "short" qualifier, but IMO that qualifier makes no sense for a couple reasons. More important is the "offline" factor and the template is better designed for unpublished documents held in library collections. -- GreenC 17:41, 28 December 2023 (UTC)

Short because of the way that the {{cite document}} template renders – title is rendered in a quoted upright font like a book chapter, a journal/magazine/newspaper article.

...IMO that qualifier [(short)] makes no sense for a couple reasons and then fails to enumerate those reasons. Sigh.

—Trappist the monk (talk) 20:11, 28 December 2023 (UTC)

For one, if/when there is a dispute, no one will agree what "short" means, it's a recipe for conflict - such as the wars over "short" categories.

Also, isn't the "title rendered in a quoted upright font" the same as the cite web template, like in the example above?

Bigger picture, we currently have no agreed on method for citing documents in archives eg. 1,000 documents in the The Ernest Hemingway Collection held at the JFK Presidential Library. How do we cite one particular document that is only accessible by an in-person visit, like a personal letter he wrote. If you say {{cite document}} then it really makes no sense to differentiate based on an arbitrary and subjective size of the document. Documents like that, regardless of length, are not usually in italics anyway, because they are unpublished. -- GreenC 20:57, 28 December 2023 (UTC)

Short as in 'article length' (upright quoted) v long as in 'book length' (italic); more-or-less in keeping with the minor/major works distinction described at MOS:TITLE. Documents cited with {{cite document}}, unlike unpublished holdings in an archive are expected to have been published hence the requirement for |publisher=.

For citing some document in some box on some shelf in some archival collection at some institution, we have {{cite archive}} (not a cs1|2 template but it renders more-or-less like a cs1|2 template). Such sources, of course, are likely not WP:RS.

—Trappist the monk (talk) 23:17, 28 December 2023 (UTC)

{{cite archive}} ok great I didn't know about that one. That is exactly what the diary is. It's a WP:PRIMARY source. The rule says it must be "reputably published", and WP:PUBLISHED (part of WP:RS) says it must have been made available to the public somewhere, which it has been at the Tasmanian library. It also depends how the source is used. In this case there is a quote from her diary that doesn't support any original conclusion by Wikipedia, rather she describes her upbringing, it is sort of like an old photograph, to demonstrate what a person looked like. Anyway User:Hoary, it's not too important but IMO {{cite archive}} is the way to go with this one, but your choice however you like. -- GreenC 18:48, 29 December 2023 (UTC)

GreenC, "short" did surprise me too. But I've just now downloaded the file, all 49 MiB and 173 pages of the intermittently decipherable thing. At the page whose address I specified, there's a "Download" link. (No, I do not intend to attempt to read the PDF. This is not "my" article.) -- Hoary (talk) 07:24, 29 December 2023 (UTC)

Automating conversion of REF-plus-Rp to Sfn((m)p)

A thread above, "Successions of REF-plus-Rp pairs", in which I asked about whether it was possible to make consecutive pairs (or threes, or fours....) less hideous, seemed to reach a general consensus that, now that it has better alternatives, Template:Rp is horrid and should almost never be used.

We all know that changing the citation styles of an article shouldn't be done without consensus, etc etc. In the article I'm primarily thinking of, it was me who first introduced Template:Rp; and since then the article has been very little edited by anyone other than me. So I'd have no qualms of conscience about doing away with this citation system and adopting an alternative. But I have massive qualms about the donkeywork needed. Is there perhaps some semi-automated conversion method? -- Hoary (talk) 02:01, 26 December 2023 (UTC)

I'm already working on a series of very complicated regexes to build into a user JavaScript, to normalize citation formatting well enough to then go through and search–replace {{rp}} (which is a monstrosity I created in 2007 when there wasn't an alternative) with replacements like {{sfnp}}. Because the community deprecated inline parenthetical referencing a few years ago, and {{rp}} is a form of inline parenthetical (albeit partial) referencing, it has to go; WP:CITEVAR is ultimately not going to be an issue, as long as the cleanup operation doesn't trample on otherwise legitimate citation styles. However, it is insanely difficult to parse XML (much less XML commingled with MediaWiki's novel {{...}} syntax), and developing and testing this scripting is going to take some time. Hoary, If you let me know what article in particular you want to de-{{rp}}-ize, I can use it as test data and thereby ensure it's one of the first pages cleaned up when the scripting is finished.  — SMcCandlish ☏ ¢ 😼  00:20, 29 December 2023 (UTC)

https://stackoverflow.com/a/1732454

I would use a mediawiki parser. Galobtter (talk) 00:25, 29 December 2023 (UTC)

I'm well aware of the difficulties and of that specific SO post, which has become a thought-terminating cliché at this point. It is about using regex to parse general-purpose XML/HTML broadly, while I need to account only for <ref>, and I do not even need to account for every imaginable possibility within its attribute values, just material that is likely in WP content, especially since editors are required to check the results before saving when using semi-automated tools; this is not a bot that will be doing things on its own. As for "use a mediawiki parser", like what?  — SMcCandlish ☏ ¢ 😼  00:40, 29 December 2023 (UTC)

mw:Alternative parsers might list one that is still maintained and suits your purpose. Folly Mox (talk) 01:12, 29 December 2023 (UTC)

Looks to be the sort of thing that, due to dependencies on particular languages (Python, etc.) or packages for them (node.js, etc.), would have to be built into a stand-alone web app, and couldn't be done as a script someone can just import into their common.js. Above my pay-grade. After I get something that generally works, someone else is free to re-develop it into something more fancy that maybe could handle any input no matter how mangled. I'm just testing for legit markup and likely error conditions, and will document known limitations, so people can do a round of pre-script cleanup to eliminate bad markup that is likely to cause a failure, like <ref name="foo"bar"> Can probably even build in some tests for such things. There's a thread on my user-talk page about this, for those who want to follow along.  — SMcCandlish ☏ ¢ 😼  03:43, 29 December 2023 (UTC)

Sure, but it really is much easier to make edits using a parser like https://github.com/earwig/mwparserfromhell (which I used for e.g. my lint error fixer bot). Life is easy when you can get every ref tag with two lines of code:

wikicode = mwparserfromhell.parse(text)
ref_tags = wikicode.ifilter_tags(matches = lambda node: node.tag == "ref")

And replacing all instances of a template is much more suited to a bot than an user script anyhow. Granted, a user script is easier to setup initially. Galobtter (talk) 18:11, 29 December 2023 (UTC)

SMcCandlish, the page I'd been primarily thinking of was/is English modal auxiliary verbs. Even for those who happen to like Rp it's a half-baked horrible mess: please don't tell me this; I know. ActivelyDisinterested guessed that the page I'd been muttering about above was that one and offered to do the conversion. I took AD up on the kind offer and explained why, in the short term, the converted version too really should be a mess. Eventually the article will be improved (I expect and hope) and then the messiness can be reduced. Another, similar article is English auxiliary verbs. If you'd like a guinea pig for alpha-testing a conversion technique, how about English auxiliary verbs? (NB If you have questions: Less than 20 hours from now I'll disappear from the internet; I'll be back two or three days later.) -- Hoary (talk) 07:43, 29 December 2023 (UTC)

That'll probably suffice as a test page. I've been refining the core regex stuff, and will start JS-chaining the regex operations probably tomorrow. (It certainly is impossible, even for a single multi-attribute element, to "munge" every possible configuration of it in a single regex; the StackOverflow post above is not wrong about that. Processing has to be done step-wise.)  — SMcCandlish ☏ ¢ 😼  07:57, 29 December 2023 (UTC)

Year

I have yearly periodicals, which the title is "World Air Forces 2024", published by FlightGlobal, and it was already published. That periodicals didnt explicitly states 'Date or Year of Publication', but there is a statement ©2023 FlightGlobal, part of DVV Media International Ltd in that periodicals. Which 'year' should I put on |year= parameter, 2023 or 2024? Ckfasdf (talk) 16:54, 26 December 2023 (UTC)

I would use 2023. The date in the title is unrelated to publication date (this is generally true in such cases, but definitely true in this case as the publication date cannot be in the future). You could also use n.d. (not dated), but I think it's clear it was published in this year. -- LCU ActivelyDisinterested «@» °∆t° 17:08, 26 December 2023 (UTC)

Thank you for your comment, that's what I thought as well. Also, I just learned about US copyright notice, whereas the year after copyright symbol means the year of first publication of the copyrighted work. Ckfasdf (talk) 17:39, 26 December 2023 (UTC)

I've seen past examples as the year the directory is for, but I'll opt to leave it blank and let the title speak for itsself FOX 52 ^talk! 23:00, 26 December 2023 (UTC)

Leaving the year blank would give false metadata and would be misleading as it would give the impression that it was written in 2024 - state the correct year (2023) in the template and in cites. In fact, for some of the uses, it should probably be explicitly stated in the text as to when the data is dated to - while the report was published in December 2023, the report states that the data was collated earlier.Nigel Ish (talk) 23:09, 26 December 2023 (UTC)

Agree and it was actually mentioned in page 11 of the report that the data was collated in 19 October 2023. Ckfasdf (talk) 02:36, 27 December 2023 (UTC)

Yep, and it's also important to remember that if |date= (or if you really insist on using it, the partially equivalent but easily broken |year=) is missing entirely, then templates like {{sfnp}} and {{harvp}} will not work, not without a custom |ref={{harvid|...}}. A date parameter should not be left off even when it seems "redundant" with something in the title of the article or the containing work.  — SMcCandlish ☏ ¢ 😼  00:33, 29 December 2023 (UTC)

DOI erroring

• High, Holly; Reno, Joshua O., eds. (October 2023). As If Already Free: Anthropology and Activism After David Graeber. Pluto Press. doi:20.500.12657/77038. ISBN 978-0-7453-4845-2. {{cite book}}: Check |doi= value (help)

Why is the DOI erroring in this citation? It resolves correctly. czar 04:20, 27 December 2023 (UTC)

Are you sure it's really a doi? It looks more like a handle.

• High, Holly; Reno, Joshua O., eds. (October 2023). As If Already Free: Anthropology and Activism After David Graeber. Pluto Press. hdl:20.500.12657/77038. ISBN 978-0-7453-4845-2.

—David Eppstein (talk) 05:13, 27 December 2023 (UTC)

That looks right. Thank you! czar 05:15, 27 December 2023 (UTC)

in PDF doc citation, which page # to use?

If my citation reference is an online PDF document, which page # do I use? The page # that is printed on each page (could be i, ii, etc.) or the page # that my PDF viewer says I am reading. If the doc has an un-numbered title page & several i, ii pages, then the printed page could be 5 but the PDF page could be 10. I've tried to research this in WP but could not find the answer. Sunandshade (talk) 02:12, 28 December 2023 (UTC)

Printed on the page. Some (most) browsers recognize a page number added to the url as a fragment; see Wikipedia:Citing sources § Linking to pages in PDF files.

—Trappist the monk (talk) 02:28, 28 December 2023 (UTC)

Could you explain that a bit more? You say I should use the printed page #. But if I use <url>#page=n, that will be the PDF page #. I shouldn't use both, should I? Or maybe I should? Sunandshade (talk) 05:38, 28 December 2023 (UTC)

@Sunandshade: I see that you first asked this at Wikipedia:Teahouse#for PDF citation, which page # to use?. In the future, please don't post the same question in more than one place at the same time. GoingBatty (talk) 05:58, 28 December 2023 (UTC)

I'm new here & am learning the rules. Yes, I posted to Teahouse & was told there to post here so that's what I did. I was told the people here were experts in this area. In the future, if I'm told to ask in another place, what should I do? Can I somehow delete the original post so it's not in 2 places? Thanks for letting me know how things are done here. Sunandshade (talk) 06:36, 28 December 2023 (UTC)

@Sunandshade: Sorry, I missed the fact that someone at the Teahouse suggested you post here. My bad. Carry on... GoingBatty (talk) 06:38, 28 December 2023 (UTC)

This has been discussed before at Help talk:Citation Style 1/Archive 51#PDF page number different from document page number. I think the advice is to cite the printed page number, but if the citation includes a link, that should point to the PDF-internal page. -- Michael Bednarek (talk) 06:47, 28 December 2023 (UTC)

Right. To clarify: |page=[https://www.domain.com/document.pdf#page=5 4], rendering in the citation as p. 4. This technique is often needed for specific-page links to books on Internet Archive [other than the login-required "Borrow for 1 hour" ones, for which page-specific URLs are useless], because it uses a weird page-numbering system, e.g. p. iii of an introduction/foreword would be .../page/n3/... in the URL in many cases (but not consistently; I think it depends on who did the digitization).  — SMcCandlish ☏ ¢ 😼  03:50, 29 December 2023 (UTC)

I think I got it now. Looks like there are two (or more) ways of doing this. I think I'll use: |url=<addr>/fid.pdf#page=2|pages=906-907|title=Humans Using Pigment|website=Nature|access-date=2023-12-27

For the other option, I could use: |url=<addr>/fid.pdf|pages=[<addr>/fid.pdf#page=2 906-907]|title=Humans Using Pigment|website=Nature|access-date=2023-12-27

But that repeats the URL in the citation so clutters it up a bit. I tried to not use the 1st URL but it said I needed it since I had an access-date. Sunandshade (talk) 06:15, 30 December 2023 (UTC)

@Sunandshade: That sounds good. If I came across the citation I would have zero confusion about the explicit page number and the embedded page number. Good luck, Rjjⁱⁱⁱ (talk) 08:03, 30 December 2023 (UTC)

Vancouver style when citing hyphenated first names

Cite journal does not properly handle hyphenated first names when using |name-list-style=vanc. For example:

• Tsai HM (February 2006). "Current Concepts in Thrombotic Thrombocytopenic Purpura". Annual Review of Medicine. 57: 419–436. doi:10.1146/annurev.med.57.061804.084505. PMC 2426955. PMID 16409158.
  • The author's name is Han-Mou Tsai with a hyphenated first name, but when style is turned to vanc, his name is displayed as "Tsai H", treating his first name as one name. In published literature citing him, they usually cite him as "Tsai HM" or occasionally "Tsai H-M", but not "Tsai H".

The template's code should be updated to cite authors with hyphenated first names more accurately. BhamBoi (talk) 07:16, 28 December 2023 (UTC)

Fixed in sandbox. Also removed allowance for a comma separator between given name(s) and generation suffix.

Cite book comparison

Wikitext	{{cite book|first=Han-Mou|last=Tsai|name-list-style=vanc|title=Title}}
Live	Tsai HM. Title.
Sandbox	Tsai HM. Title.

Cite book comparison

Wikitext	{{cite book|first=Han-Mou Jr|last=Tsai|name-list-style=vanc|title=Title}}
Live	Tsai HM Jr. Title.
Sandbox	Tsai HM Jr. Title.

Cite book comparison

Wikitext	{{cite book|first=Han-Mou, Jr|last=Tsai|name-list-style=vanc|title=Title}}
Live	Tsai Han-Mou, Jr. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)
Sandbox	Tsai Han-Mou, Jr. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)

—Trappist the monk (talk) 15:06, 28 December 2023 (UTC)

Will this be going live? BhamBoi (talk) 00:34, 15 January 2024 (UTC)

Additionally, assuming the above changes go live (@Trappist the monk), would there be added support for 3 letter first names in Vancouver style? e.g. 'das Neves, Paulo Cesar Pereira' would become 'das Neves PCP' instead of 'das Neves PC' BhamBoi (talk) 08:17, 20 January 2024 (UTC)

The rule, as stated at Citing Medicine: The NLM Style Guide for Authors, Editors, and Publishers is:

Convert given (first) names and middle names to initials, for a maximum of two initials following each surname

When that rule changes, so shall cs1|2. Until then, two initials.

—Trappist the monk (talk) 15:16, 20 January 2024 (UTC)

Okay. I can live with that. But can the changes with the hyphenated first names get implemented? Thanks for all you do :) BhamBoi (talk) 17:25, 20 January 2024 (UTC)

cite encyclopedia

This works:

{{cite encyclopedia |title=Энциклопедия Республики Марий Эл |trans-title=Encyclopedia of the Republic of Mari El |language=Russian |page=99 |year=2009}}

Энциклопедия Республики Марий Эл [Encyclopedia of the Republic of Mari El] (in Russian). 2009. p. 99.

This does not:

{{cite encyclopedia |encyclopedia=Энциклопедия Республики Марий Эл |trans-title=Encyclopedia of the Republic of Mari El |language=Russian |page=99 |year=2009}}

[Encyclopedia of the Republic of Mari El]. Энциклопедия Республики Марий Эл (in Russian). 2009. p. 99. {{cite encyclopedia}}: |trans-title= requires |title= or |script-title= (help)

The difference is |title= vs. |encyclopedia=.

The docs say the paring of |encyclopedia= + |trans-title= should work (I think). -- GreenC 17:34, 28 December 2023 (UTC)

{{cite encyclopedia}} is a pain in the ass. {{cite encyclopedia}} templates can be written in a variety of ways:

{{cite encyclopedia |article=Article title |encyclopedia=Encyclopedia title}} → "Article title". Encyclopedia title.

{{cite encyclopedia |chapter=Chapter title |encyclopedia=Encyclopedia title}} → "Chapter title". Encyclopedia title.

{{cite encyclopedia |contribution=Contribution title |encyclopedia=Encyclopedia title}} → "Contribution title". Encyclopedia title.

{{cite encyclopedia |entry=Entry title |encyclopedia=Encyclopedia title}} → "Entry title". Encyclopedia title.

{{cite encyclopedia |section=Section title |encyclopedia=Encyclopedia title}} → "Section title". Encyclopedia title.

{{cite encyclopedia |title=Title title |encyclopedia=Encyclopedia title}} → "Title title". Encyclopedia title.

{{cite encyclopedia |article=Article title |title=Encyclopedia title}} → "Article title". Encyclopedia title.

{{cite encyclopedia |chapter=Chapter title |title=Encyclopedia title}} → "Chapter title". Encyclopedia title.

{{cite encyclopedia |contribution=Contribution title |title=Encyclopedia title}} → "Contribution title". Encyclopedia title.

{{cite encyclopedia |entry=Entry title |title=Encyclopedia title}} → "Entry title". Encyclopedia title.

{{cite encyclopedia |section=Section title |title=Encyclopedia title}} → "Section title". Encyclopedia title.

Do we really need all of these ways to write an encyclopedia citation? In general, it seems, editors prefer to write {{cite encyclopedia}} templates with |encyclopedia=<Encyclopedia Title> and |title=<article/entry title>. Here are some searches:

• number of articles that use some form of {{cite encyclopeida}}: ~62,100
• number of articles that use {{cite encyclopedia}} where |title= precedes |encyclopedia=: ~44,300
• number of articles that use {{cite encyclopedia}} where |encyclopedia= precedes |title=: ~10,500

The above do not include wrapper templates that wrap {{cite encyclopedia}} of which there are ~370.

Were it up to me, I would enforce that choice because it is more-or-less consistent with how {{cite journal}}, {{cite magazine}}, {{cite magazine}}, {{cite web}} are intended to work (yeah, you can write a {{cite journal}} template with |website= instead of |journal= which I think to be nonsensical...).

For your example the documentation (such as it is) is wrong. The correct parameter to match |encyclopedia= would be |trans-encyclopedia= which parameter does not exist (nor does |script-encyclopedia= which would be the correct parameter to use for Энциклопедия Республики Марий Эл).

—Trappist the monk (talk) 15:34, 29 December 2023 (UTC)

It's trouble for |title= to signify two different things - the title of the encyclopedia OR the title of the article in the encyclopedia. |title= should be an alias of chapter/section/entry/article - there would be only be one of those defined. The name of the encyclopedia would be |encyclopedia= or |work=. Or |title= is an alias of |encyclopedia=, one way or another, but not both at the same time. Is this controversial to repair? I would think most people would agree, an argument should have one meaning, not a double meaning, which is ambiguous. -- GreenC 19:31, 29 December 2023 (UTC)

I agree but don't agree. In {{cite journal}}, {{cite magazine}}, {{cite news}}, {{cite web}}, etc, |title= is the name of the article. Those templates don't support |article=, |chapter=, |contribution=, |entry=, or |section= so a rewritten {{cite encyclopedia}} template should not support them. Those parameters are all aliases of the {{cite book}} base-parameter |chapter= so if one of them is needed, the encyclopedia can be cited using {{cite book}} where |title= gets the name of the encyclopedia ({{cite book}} does not support |encyclopedia=).

If we rewrite {{cite encyclopedia}} we should:

• require |title= and |encyclopedia=
• add support for:
  • |script-encyclopeda=
  • |trans-encyclopedia=
• disallow |article=, |chapter=, |contribution=, |entry=, and |section=

Given that most implementations of {{cite encyclopedia}} use |title= and |encyclopedia=, I expect that a rewrite of the template will not be too controversial. But then, who knows, it is also possible that someone will get their panties in a bunch and call down the torches and pitchforks...

—Trappist the monk (talk) 16:56, 30 December 2023 (UTC)

I'm OK with all that. Encyclopedia's are books, they sometimes have areas that don't easily fall into 'title of an encyclopedia article'. Such as chapters or sections that need to be referenced, such as a preface. On the other hand, such a situation may be rare, and in those cases it might be best to use {{cite book}}, since the encyclopedia template is designed for citing encyclopedia article entries, and not other book-like things it might contain on the margins. -- GreenC 17:36, 30 December 2023 (UTC)

How would such a re-write deal with current uses of |entry=, |entry-url=, and other similar parameters? -- Michael Bednarek (talk) 02:04, 31 December 2023 (UTC)

It would be necessary to run a bot or awb script over the ~62100 - (~44300 + ~10500) = ~7300 articles that use {{cite encyclopedia}} with some combination of |article=, |chapter=, |contribution=, |entry=, or |section= with |encyclopedia= or |title= to convert those templates to use |title= and |encyclopedia= before the {{cite encyclopedia}} rewrite can go live.

—Trappist the monk (talk) 15:44, 31 December 2023 (UTC)

I suppose I'm in the minority as usual, but when I call {{cite encyclopedia}}, I use |entry= and |title=. One reason is that since |encyclopedia= isn't an alias of |work=, the |trans-work= and |script-work= parameters don't work on it, while |trans-chapter= and |script-chapter= work on |entry=. Another is that my keyboard suggests "encyclopaedia" and variants as string autocompletions, so I have to type the US spelling "encyclopedia" in full every time (unless |encyclopaedia= is now a valid alias; it hasn't always been).

I agree that it's confusing that |title= is polysemic within this template, depending on whether it's paired with |entry= or |encyclopedia=, and one of the two modes should be sunsetted.

Perhaps to ensure equal satisfaction by all users, implementation could split the baby by dropping support for |title=, and requiring |entry= alongside |encyclopedia=. Folly Mox (talk) 02:44, 31 December 2023 (UTC)

|encyclopaedia= has been in Module:Citation/CS1/Whitelist from its first implementation (4 April 2013). For the sake of historical completeness:

• |encyclopaedia= was present in the first implementation of Module:Citation/CS1 (19 February 2013)
• Module:Citation/CS1 derives from Module:Citation where |encyclopaedia= was added to the module at this edit (26 August 2012)
• the wikitext versions of {{cite encyclopedia}} did not support |encyclopaedia= so that parameter did not become available until the template was switched from wikitext to Lua at this edit (17 March 2013)

The ugliness of {{cite encyclopedia}} is already apparent in the first version of Module:Citation/CS1. At line 272 the Title metaparameter can get its value from |title=, |encyclopaedia=, |encyclopedia=, or |dictionary=. A few lines from there, at line 286, the Periodical metaparameter can get its value from |journal=, |newspaper=, |magazine=, |work=, |periodical=, |encyclopedia=, or |encyclopaedia=. Some of that has already been fixed: |encyclopedia= and |encyclopaedia= have their own Encyclopedia metaparameter and are only allowed in {{cite encyclopedia}} and {{citation}}.

—Trappist the monk (talk) 16:39, 31 December 2023 (UTC)

Given that an encyclopedia is a book, wouldn't the most sensible course of action be to use a bot to normalize all instances of it to be compliant with {{cite book}} parameters, and then just redirect {{cite encyclopedia}} to {{cite book}}? Seems like a sensible proposition to make at WP:TFD if you ask me. We have too many citation templates as it is. Same could be done with {{cite magazine}} → {{cite journal}}; we have no need of redundant periodical templates that are the same thing except having a different name for what sort of periodical it is.  — SMcCandlish ☏ ¢ 😼  00:55, 4 January 2024 (UTC)

SMcCandlish, perhaps it's marginal, but isn't a distinction here useful for categorization, since encyclopedias are tertiary sources and not as broadly appropriate as "books" in general? — Remsense留 02:06, 4 January 2024 (UTC)

Conceivably, though a lot of things with "Encyclopedia" in their titles are not actually encyclopedias and are secondary works. E.g. The New Illustrated Encyclopedia of Billiards is a work of predominantly secondary nature. And people use this template all the time for things that are dictionaries or other works, not encyclopedias. And lots and lots of tertiary works usually cited with {{cite book}} do not have "encyclopedia" (or "dictionary") in their titles. But what categorization would we be doing anyway? "Articles that contain citations to tertiary sources"? Is there an actual useful purpose to doing that? If there is, it would probably be better done with the {{Tertiary source}} template which is completely agnostic as to the title of the work or what {{cite foo}} template its details were shoehorned into. That add-on template already has some configuration parameters for various use cases, like tertiary sources that don't cite their own sources, tertiary sources that do provide a bibliography but don't cite individual sources specifically, and tertiary sources that are too weak for us to be using and should be replaced. It doesn't do any categorization yet, other than in the last case (too-weak tertiary source) "put the article in Category:All pages needing factual verification (or a dated subcat thereof), just like {{Primary source inline}} does". Adding more categorization to it would not be hard.  — SMcCandlish ☏ ¢ 😼  02:36, 4 January 2024 (UTC)

I had no idea about {{Tertiary source}}, thank you for the reply. Remsense留 03:09, 4 January 2024 (UTC)

This is not an objection but more a note for anyone cleaning up {{cite encyclopedia}} uses: I've used it before to cite online-only an encyclopedia like Wex (https://www.law.cornell.edu/wex). After reading this discussion, I tested {{cite book}} with |chapter-url= and {{cite web}} with |url=. Both render exactly the same, but cite web is much clearer in the wiki text. I don't know how cite book would affect the unseen data. Regards, Rjjⁱⁱⁱ (talk) 05:58, 4 January 2024 (UTC)

Which unseen data? Anyway, {{cite web}} could certainly be used as a replacement for {{cite encyclopedia}} cases that are Web-only publications. What this really comes down to is that {{cite encyclopedia}} is an odd-one-out, unnecessary template fork that has nothing to do with what medium/format the publication is, the way our most-used cite templates do, but is trying to address what "societal role" or "authorial purpose" the publication supposedly has. It's like forking a {{cite documentary}} from {{cite AV media}}, or forking a {{cite reality show}} template from {{cite AV media}}, or forking a cite {{cite festschrift}} from {{cite book}}, or {{cite space opera}} from {{cite AV media}}, or (surprise! someone did it!) forking {{cite magazine}} from {{cite journal}}. Even {{cite news}} should probably also be merged to the latter (which might need addition of |agency=). Several other templates listed in Category:Citation Style 1 templates are also pointless forks of this sort, though a few are arguably useful wrappers for addressing source types with particular ID formats, like {{cite arXiv}}. E.g. {{cite podcast}} is a pointless fork of {{cite AV media}} and could just be redirected to it (this would have the benefit of adding support for the "subscription or registration required" parameters which according to the documentation are lacked by {{cite podcast}}, though that may not actually be true in the code). {{Cite episode}} is likewise another unnecessary redundancy forked from {{cite AV media}}. It's noteworthy that various other things have already been merged/redirected, like {{cite film}} to {{cite AV media}}, {{cite e-book}} to {{cite book}}, etc.  — SMcCandlish ☏ ¢ 😼  08:35, 4 January 2024 (UTC)

The Wikipedia:COinS that CS1 templates make. I changed my Wex citation to {{cite web}} to make sure future updates don't make the online resource appear as a book somewhere. Rjjⁱⁱⁱ (talk) 18:50, 4 January 2024 (UTC)

Now I've gotten curious what the exact differences are. May have to go test this in a sandbox and find out.  — SMcCandlish ☏ ¢ 😼  04:45, 5 January 2024 (UTC)

new error-checking in "author"/"last" parameter?

Hi,

I get the impression someone's recently implemented checking for digits and other non-letter chracters in the |author= parameter... however, that seems to have missed or ignored the fact that {{cite tweet}} and {{cite Instagram}} (and possibly others) use it to hold usernames that do contain non-letters.

So basically you have a bunch of instances of those templates throwing errors. E.g.:

References

As a result, Category:CS1 maint: numeric names: authors list has many, many entries.

Could we maybe revert this new check? Or is there some way to tweak the two templates to not throw this newly defined "error"? —Joeyconnick (talk) 19:32, 30 December 2023 (UTC)

The sandbox version appears fixed though? @SWinxy, Nardog, and Joeyconnick: is there any issue with the sandbox code or can we move it to the live template? Rjjⁱⁱⁱ (talk) 20:34, 30 December 2023 (UTC)

*Sandbox version of {{cite twitter}}; {{cite instagram}} is different. Sandbox version of Twitter example:

• Rustad, John [@JohnRustad4BC] (December 25, 2023). "Merry Christmas from my family to yours. May the holidays be filled with love, peace and joy!" (Tweet). Retrieved December 30, 2023 – via Twitter.

Rjjⁱⁱⁱ (talk) 20:48, 30 December 2023 (UTC)

{{Cite instagram}} is a much simpler wrapper. Does just leaving the username out of the actual author parameter fix the error messages? Example from above:

• Plummer, James [@movielover927] (2023-05-24). "Happy birthday to the best big brother in the world. I love you so so much. I hope you have an amazing birthday". Retrieved 2023-10-30 – via Instagram.

And here's a bogus example with the date in the author field that should emit a message:

• James Plummer - 24 May 2023 [@movielover927] (2023-05-24). "Happy birthday to the best big brother in the world. I love you so so much. I hope you have an amazing birthday". Retrieved 2023-10-30 – via Instagram.{{cite web}}: CS1 maint: numeric names: authors list (link) ← That message should appear.

Rjjⁱⁱⁱ (talk) 21:31, 30 December 2023 (UTC)

Article titles

Am I correct in assuming the first letters of words in article titles other than conjunctions, prepositions, pronouns and similar words should be in upper case, so that in Visual Editor after a citation has been generated the title needs to be edited? I notice numerous citations where first letters are not in upper case. Mcljlm (talk) 21:25, 30 December 2023 (UTC)

Mcljlm, citations generated by the Visual Editor will often need editing from their initial state, not just because of improper capitalisation, but because it relies on the Citoid library, which has a tendency to produce citations to webpages that are total trash garbage, like:

{{cite web |last=Office |first=United Nations Press |date=[none given, despite prominent presence of the webpage] |title=United Nation Press Release – United Nations Press Office |website=press.un.org |access-date=[today]}} Folly Mox (talk) 22:36, 30 December 2023 (UTC)

More specifically about Mcljlm's question, no it is not necessary to rewrite an article title like "MP Jackson causes row over response to scandal accusations" or "Impacts and management of feral cats Felis catus in Australia" to read "MP Jackson Causes Row over Response to Scandal Accusations" or "Impacts and Management of Feral Cats Felis catus in Australia", unless a particular article is written in a WP:CITESTYLE that is imposing title case on all article/chapter titles (which is exceedingly unusual). Most journals and newspapers do not use title case for article names, so most such titles are in sentence case and it would take someone a lot of rather obsessive activity to "fix" all of them to be title case in a long WP article (and probably be met with reversion by other editors). The title cleanup to do is when someone has forced a book or journal's entire-work title to sentence case, e.g. The encyclopedia of scientific terms or Journal of cardiac surgery, since that is not the normal presentation of the title of such a work (even in citations that are consistently using sentence case for article/chapter titles).  — SMcCandlish ☏ ¢ 😼  00:47, 4 January 2024 (UTC)

Unflagged free DOI, add a time component to some DOIs

DOI prefix 10.1155's registrant is Hindawi, an open access publisher. However, Hindawi became open access in 2007, and some (rare) DOIs from prior to 2007 are not free, e.g.

• Booker, A. R.; Strombergsson, A.; Venkatesh, A. (2006). "Effective computation of Maass cusp forms". International Mathematics Research Notices. 2006: 71281. doi:10.1155/IMRN/2006/71281.{{cite journal}}: CS1 maint: unflagged free DOI (link)

There should be a way to specify that for 10.1155, the template should only flag those from year 2007 and up, and not all of them. Headbomb {t · c · p · b} 01:23, 31 December 2023 (UTC)

Adding "Deprecated" sources from Wikipedia:Reliable sources/Perennial sources to a maintenance category

Wikipedia:Reliable sources/Perennial sources has a list of sources that the community has deemed unreliable and has given it a "Deprecated" status. I think it would be helpful if the module detected citations using a site from that list and add to a maintenance category. Gonnym (talk) 16:12, 3 January 2024 (UTC)

Just because I was curious, I hacked my module sandbox and created Module:Sandbox/Trappist the monk/deprecated sources. That module reads Wikipedia:Reliable sources/Perennial sources and extracts the deprecated domains that are listed in the Uses column of the Perennial sources table. My sandbox module creates a lua k/v table so that should we decide that this is a good idea, Module:Citation/CS1 can compare the domain in any of the url-holding parameter to the list of deprecated sources.

The list of deprecated domains can be seen at this version of my sandbox (permalink).

So long as the Perennial sources table remains organized more-or-less as it is now (Uses column to the right of the Status column) the sandbox module code should continue to work.

You will notice (before it gets fixed), that the journal-neo.org entry in the list is prefixed with its html scheme (it shouldn't be). Also, the Perennial sources table lists twenty domains for Sputnik. There are actually twenty-two listed in the Sputnik {{/Uses}} template, all appear in the list at my sandbox.

I gotta wonder if this is functionality is at all useful to other-language wikis. According to Wikidata, there are only 14 wikis that have some sort of Perennial sources page; most appear to be distinctly different from ours.

—Trappist the monk (talk) 00:10, 4 January 2024 (UTC)

Seems more like a job for a bot, and one that can be told by template to ignore particular citations. Any source may be reliable for a claim about itself per WP:ABOUTSELF, or for a person's claim about themself published as, e.g., the author of the cited article or as the interview subject, in a source that is otherwise not generally reliable (due to a particular strong political slant or whatever), also per the same ABOUTSELF policy. For some works, that are on our blacklist, citation of such sources has to be done with a whitelisting entry for the exact URL of the page in question, but most of the sources at RSP are not blacklisted. That is to say, a new Lua routine, whether built into CS1 or more appropriately used by a bot, cannot become a means of invalidating our whitelist or serving as an "alternative" blacklist that the community didn't approve.  — SMcCandlish ☏ ¢ 😼  00:37, 4 January 2024 (UTC)

A category "Articles with deprecated sources" or such could be useful for tracking purposes, but I'm not sure of any automation. Automation and referencing has caused so many issues. If this was a maintenance or error messages good faith editors might feel the need to 'correct' valid uses. Separately I not sure if it already exists or not, but a tracking category for blacklisted URLs (that aren't whitelisted) would also be useful. -- LCU ActivelyDisinterested «@» °∆t° 00:49, 4 January 2024 (UTC)

Agreed. I uncommonly run into them accidentally, stuff that was added before the URL was blacklisted. I'm not certain what triggers what, but it seems to me so far that if you edit such a page or section, nothing happens, but if you modify the citation then it re-triggers the blacklist. Maybe only if you update the URL-related parameter in some way, e.g. because the https://foo.bar/baz/quux/whatever.html structure of the site changed to https://foo.bar/baz/whatever.asp, or something in |url= needs to move to |chapter-url=, or whatever. It doesn't come up often enough for me to have tested it out.  — SMcCandlish ☏ ¢ 😼  02:47, 4 January 2024 (UTC)

Undocumented url-status values

Some other features document the use of additional values for url-status that aren't documented here. Most notably, "bot: unknown". I've marked the documentation for this template with {{Improve documentation}} per the instructions at that template. -- Mikeblas (talk) 00:40, 7 January 2024 (UTC)

When I listified the keywords acceptable to |url-access=, I intentionally omitted bot: unknown because that keyword defined for bot use only. When a bot has set |url-access=bot: unknown, cs1|2 emits a maintenance message with a link to Category:CS1 maint: bot: original URL status unknown where that keyword's meaning is described.

—Trappist the monk (talk) 13:56, 7 January 2024 (UTC)

Humans can see it when it is left behind by bots, and aren't able to learn what it means. If it is useful, it should be documented, even if only to say "this can be ignored". Or should this value be removed when it is encountered by a human? SMcCandlish, I see you removed the documentation tag. Are you able to explain what editors should do when they encounter url-status=bots: on a citation they are maintaining? -- Mikeblas (talk) 21:51, 8 January 2024 (UTC)

Per WP:MENTION, looks like I have to ping SMcCandlish again. -- Mikeblas (talk) 22:08, 8 January 2024 (UTC)

Like Trappist said, it's covered at Category:CS1 maint: bot: original URL status unknown. Maybe we just cross-reference it? We don't need to duplicate documentation of it one place at another, surely. Or am I just missing something? (I am actually tired, so that's very possible.)  — SMcCandlish ☏ ¢ 😼  22:17, 8 January 2024 (UTC)

Linking it might be fine, but some description would be great because that category documents the category, not the parameter. I went to the {{cite web}} documentation to try to figure out what url-status=bot: something meant, and what I should do with it. Lots of url-status=bot: unknown is around, for example, but that's not explained in the documentation. The title of the category doesn't even match: "bot: original URL status unknown" is different than "bot: unknown". And the instructions there aren't specific: "Editors should review these URLs and adjust the value assigned to |url-status= accordingly." I guess that means review them for an appropriate choice of the documented url-status= values? So then these "bot:" values are not just for bots, but for humans to go and fix? -- Mikeblas (talk) 23:19, 8 January 2024 (UTC)

I know this probably isn't helpful to hear, but it makes sense to me. When I see a piece of non-rendered code that mentions a bot or a module, that indicates to me that it wants its work double checked. On the other hand, it's probably not helpful to have any bots stating they don't know what the status of a url is, since it's functionally equivalent to "default" (which people don't agree on anyway). Folly Mox (talk) 04:38, 9 January 2024 (UTC)

Feel free to counter-revert my revert; I was just going by the idea that what Trappist said above was sufficient, but if you feel it's not, I don't feel strongly about it.  — SMcCandlish ☏ ¢ 😼  15:46, 9 January 2024 (UTC)

I've added some clarifying text to the documentation. (That meant reverse-engineering a couple of layers. The change I made ended up being at Template:Citation Style documentation/url). -- Mikeblas (talk) 01:58, 10 January 2024 (UTC)

Author credentials

Adding ", Ph.D, D.Prof" at the end of |first= generates "CS1 maint: multiple names: authors list". Template doc shows a |degree= parameter that is not supported. ―Mandruss ☎ 13:39, 7 January 2024 (UTC)

I like this behaviour. |degree= seems to be an alias of |type= specific to {{cite thesis}}, but more importantly no one should care what level academic degree the author of a published work has gained: most people who publish academically are going to be PhD or an analogous medical degree, and when books published by non-academic presses include "PhD" in the authorial attribution, what this usually signals is "unable to get this quackery past peer review" or "completely outside academic field of competence". Folly Mox (talk) 14:09, 7 January 2024 (UTC)

Indeedy.  — SMcCandlish ☏ ¢ 😼  18:38, 7 January 2024 (UTC)

Also, if one really must include the "PhD" in the authorial contribution, when adding it to the |first= parameter, simply omit the comma, just like with Jr. or Sr., and this will avoid the maintenance categorisation. Folly Mox (talk) Folly Mox (talk) 14:13, 7 January 2024 (UTC)

My particular example is this in Psychology Today. I don't know, but I doubt such publications are routinely subject to peer review. And I think it does matter that the author has some credentials in the subject area, which wouldn't necessarily be a requirement to write such an article. It strengthens the support for the content citing it. One could argue that his PhD might be in astrophysics or something, but it seems unlikely. ―Mandruss ☎ 14:21, 7 January 2024 (UTC)

Yeah, I was overly harsh in my characterisation of why publishers include the author's degree status. I've just seen it misused so many times to add credibility to material without credibility.

I think the linked publication is peer reviewed. I don't think most citations for that source would include the author's degree status, even though it's included in the byline, kinda similar how citing a news story wouldn't include "Senior Correspondent". Folly Mox (talk) 14:48, 7 January 2024 (UTC)

Key words being "kinda similar". "Senior Correspondent" is a job title, not a credential. ―Mandruss ☎ 15:01, 7 January 2024 (UTC)

I would see "Ph.D, D.Prof" or similar as an appeal to authority, as it's often used to try and pump the credentials of an author. I don't think it adds anything useful to the cite. -- LCU ActivelyDisinterested «@» °∆t° 14:52, 7 January 2024 (UTC)

Aren't all citations "appeals to authority"? Particularly in areas of science? ―Mandruss ☎ 14:58, 7 January 2024 (UTC)

No their a source for the purposes of verification. -- LCU ActivelyDisinterested «@» °∆t° 15:01, 7 January 2024 (UTC)

Verification by an authority in the subject matter. ―Mandruss ☎ 15:05, 7 January 2024 (UTC)

I suppose I could disclose at this juncture that while I've never sought them out disruptively or en masse, if I happen across degrees attained in an authorial attribution in the course of unrelated citation repair, I'll silently remove them as unnecessary.

I don't think I've ever read a published source that, in its bibliography, included degree status of any author. Sometimes people publish without any advanced degree, and no one thinks to add "BA" or "never graduated high school". Publishers will include an author's degree to add credibility to the written material, but there's really no point to including them in citations. Folly Mox (talk) 15:17, 7 January 2024 (UTC)

Fair enough. In this specific case, I'll leave the credentials in and assume that few enough editors have the maintenance error messages turned on (the citation is being used solely on an article talk page). It's part of a controversial proposal that needs all the help it can get. Otherwise, I haven't seen a lot of need for credentials in cites. ―Mandruss ☎ 15:25, 7 January 2024 (UTC)

(edit conflict)

Yeah, |degree= is only supported by {{cite thesis}} where it aliases |type= with additional static text. Ranks, degrees, titles (scholarly and aristocratic), post-nominals, and anything else that isn't the author's/contributor's/editor's/interviewer's/translator's name is all unnecessary cruft in a citation (generational suffixes excepted). Let the source flout those things if they think it important to do so.

—Trappist the monk (talk) 15:32, 7 January 2024 (UTC)

Yep. See also MOS:CREDENTIAL, MOS:HONORIFIC, MOS:POSTNOMINAL, etc.: WP doesn't use these things, except some of them in the lead sentennce and infobox on WP's article on the writer. PS: as for 'if one really must include the "PhD" in the authorial contribution, when adding it to the |first= parameter ...', one really mustn't, and needs to be aware that other editors will remove it on sight. PPS: The only maybe-exception, that is anywhere near this general realm of stuff, that I make is that if someone is "Reverend General Sir Xerxes Youill of Zounds, KBE, FSA(Scot), PhD, Esq.", and uses the long-form surname with "of Zounds" when publishing and is commonly referred to that way, I'll cite them as |last=Youill of Zounds|first=Xerxes (because it's consistent with de/du/di/von/van/etc. constructions in other languages). Some editors will probably object even to that, though removing it may make them ambiguous with other writers named (in this silly example) Xerxes Youill. A real example is Sir Thomas Innes of Learney, former Lord Lyon (heraldic authority of Scotland). I mostly see him referred to as Thomas Innes of Learney, not as Thomas Innes (except in a biographical article's material that covered his early life). Our own article on him uses both the long and short forms inconsistently, and WP isn't a reliable source anyway; I just follow the source usage.  — SMcCandlish ☏ ¢ 😼  18:38, 7 January 2024 (UTC)

work parameter ignored

I keep seeing cases where the work parameter is ignored in {{cite encyclopedia}}, {{cite book}}, and {{cite journal}}. Latest example, there are two occurrences in List of music students by teacher: G to J: Hagen, S. A. E. (1900)... and MRS. ROBINSON-DUFF VOCAL TEACHER, DIES... (that citation needs other attention too). The documentation for cite encylopedia says that |work= is an alias for |encyclopedia=, so I guess either there is a coding problem or a deprecation has not been correctly handled. -- Mirokado (talk) 22:47, 7 January 2024 (UTC)

For Mrs Robinson, {{cite work}} is a redirect to {{cite book}} but the source is The New York Times so {{cite book}} is inappropriate; use {{cite news}}.

The template documentation for |encyclopedia= at {{cite encyclopedia}} does not say that |encyclopedia= is an alias of |work=. See Template:Cite encyclopedia § Title. That documentation has problems (mentions of |script-title= and |title=) but claims that |encyclopedia= is an alias of |work= is not one of them.

—Trappist the monk (talk) 23:09, 7 January 2024 (UTC)

Hello Trappist the monk: for {{cite book}}, the documentation indeed requires |title= and does not suggest |work= as an alias, so that is OK. I recently had to make this change which explains the confusion here. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

The encyclopedia line in the Template parameters table in the Templatedata section in the documentation for {{cite encyclopedia}} says "Encyclopedia ... Title of the source; may be wikilinked; displays in italics; alias of 'work' "

Here is an example of a recent correction for {{cite encyclopedia}}. The previous version had been working correctly with |work=. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

The template data is incredibly out of date, it also suggests setting |ref= to 'harv' to generate an anchor point for short form refs. -- LCU ActivelyDisinterested «@» °∆t° 10:44, 8 January 2024 (UTC)

I guess you know that the previous version had been working correctly with |work= because you switched those templates away from |encyclopedia= with this edit. Why did you do that? That would have been a pointless edit except that you also changed a {{cite web}} to {{cite encyclopedia}}.

Some of us have gotten our asses chewed enough that we are gun-shy when it comes to touching TemplateData. I don't use the abomination that is Visual Editor so I don't bother looking at TemplateData. The TemplateData are not protected so if they are out of sync with the real template documentation (such as it is), feel free to apply the necessary fixes.

—Trappist the monk (talk) 14:38, 8 January 2024 (UTC)

I've come to prefer |work= to the alternatives, it is shorter and one name for the equivalent information.

I can try to bring the template data more up to date...

There really is a problem with cite encyclopedia as shown in the following expansions:

using |encyclopedia=: "Gerbils". Too Much Information.

using |work=: Gerbils. {{cite encyclopedia}}: |work= ignored (help)

in the latter case, citations which used to be correct are now missing the work/encyclopedia information in the display. -- Mirokado (talk) 08:06, 11 January 2024 (UTC)

A search for the error text "{{cite encyclopedia}}: |work= ignored" (with the quotes) currently shows 759 matches.

The corresponding search for cite book "{{cite book}}: |work= ignored" shows 17790 matches. -- Mirokado (talk) 10:15, 11 January 2024 (UTC)

Unfortunately the cite book errors have no easy fix, it's been stuffed with all kinds of things other time. Having an error message to show that something is wrong is definitely a good thing. Whether it's title, series, or even the website used in the courtesy url, they all need to be corrected. Gnomes will do so over time, as with other error messages. -- LCU ActivelyDisinterested «@» °∆t° 12:32, 11 January 2024 (UTC)

Taking a quick look at the cite encyclopedia errors it appears editors have been misusing {{cite contribution}} (a redirect of cite encyclopedia) to cite chapters in a book. But with so few errors it won't take long to clear them. -- LCU ActivelyDisinterested «@» °∆t° 12:53, 11 January 2024 (UTC)

Mirokado, this problem in general was discussed on this page a few months ago at Help talk:Citation Style 1/Archive 91 § Enabling |work= as a |title= alias in Template:Cite book, where I was the editor arguing most similarly to your current position. Following that thread, I actually undertook to start fixing errors in Category:CS1 errors: periodical ignored (23,500).

It turns out that – although I share your fondness for the |work= parameter for ease of entry – nobody knows what |work= is for. In addition to the "name of broader work" the source appears in, I've seen |work= hold the value of – I think – literally every other parameter: publisher, author, editor, translator, date, volume, chapter, page, quote, location, series, edition, via, and probably some I've forgotten. Maybe not url or doi.

About half of the errors in the linked maintenance category seem to have been introduced by Citation bot changing template type without changing parameter names.

Anyway now I'm broadly in agreement with the thread somewhere above about deprecating {{cite encyclopedia}} entirely, converting them all to {{cite book}} or {{cite web}} as appropriate, and would further support deprecating the |work= alias in every template once the maintenance categories are a bit more cleaned out. It's apparently too confusing. Folly Mox (talk) 13:33, 11 January 2024 (UTC)

Thank you Folly Mox for the detailed reply. I fully agree with your comments in the linked section. Clearly, as usual, things are more complicated than I expected. I've started looking through these errors (currently 681 left): this is not a completely futile exercise as some of the articles have other more substantial problems, and I learn about all sorts of things as I go. -- Mirokado (talk) 12:12, 24 January 2024 (UTC)

Mirokado: If |work= is being ignored in {{cite journal}}, please link to an example. It's working for me: "Title". Work.. – Jonesey95 (talk) 23:51, 7 January 2024 (UTC)

Hello Jonesey95: you are right, sorry. The errors I have been seeing are all in {{cite encyclopedia}} and {{cite book}} and I have also confirmed that cite journal works in the sandbox. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

Yes, |work= is not valid in {{cite book}}. |title= or |series= is typically what is needed. If you link to a specific example in an article, I can help you fix it. {{Cite encyclopedia}} is sometimes above my pay grade, though; it's a strange little beast. – Jonesey95 (talk) 16:22, 8 January 2024 (UTC)

@Mirokado:  Fixed the references in the List of music students by teacher: G to J article in these edits. GoingBatty (talk) 01:39, 8 January 2024 (UTC)

Hello GoingBatty, thanks for those corrections. -- Mirokado (talk) 02:20, 8 January 2024 (UTC)

See also #cite encyclopedia thread, above; I think a good argument can be made to just get rid of {{cite encyclopedia}}. Every instance of it should be replaceable with {{cite book}} for an actual book-form encyclopedia or {{cite web}} for an online-only work. It's a strange and useless thing that isn't identifying a publication by medium/format but by what "societal purpose" or "editorial intent" its publishers declare it has.  — SMcCandlish ☏ ¢ 😼  22:26, 8 January 2024 (UTC)

I like that idea. Are there any substantial formatting differences in the visible output versus the output of the two more common template types? Folly Mox (talk) 04:26, 9 January 2024 (UTC)

Here's test data, using every parameter that is documented for {{cite encyclopedia}} (other than mutually exclusive ones like |page= and |pages= and |at= that can't all be used at once; and just enough authors to test the functionality): User:SMcCandlish/Cite encyclopedia test. If you "translate" the parameters correctly, the output from {{cite book}} is exactly identical. However {{cite web}} moves the editor name, for unknown reasons, and it also drops |volume= which is probably not desirable, since some online works can be released with volume numbers, even if it's not common. Until that were resolved, the way to preserve a volume number for an online-only encyclopedia that had such numbering (if there are any) would probably be to combine it with the |page[s]= data, as something like |at=Vol. 3, pp. 123–125, though it will not appear in exactly the same spot in the citation as it would with {{cite book}}. I was pleasantly surpised that if you do |chapter-url= in {{cite book}}, the |archive-url= automatically works with it, including for |url-status=dead (at least if there's not a competing |url=; didn't test what happens then, since the {{cite encyclopedia}} test doesn't involve multiple URLs; it possible that template can handle them somehow, but there's no documentation suggesting this).  — SMcCandlish ☏ ¢ 😼  15:32, 9 January 2024 (UTC)

PS: I have not pored over the COinS metadata in the output; it's possible there are one or more other differences that are not visible to human readers.  — SMcCandlish ☏ ¢ 😼  15:48, 9 January 2024 (UTC)

I was mistaken about changing to {{cite book}} affecting anything. I don't fully understand the COinS, but a text comparison tool shows both templates giving the same output (with some displayed parameters from {{cite web}} seeming to be absent in the COinS).

Regarding "However {{cite web}} moves the editor name, for unknown reasons", that's default rendering given by {{Citation}}, I think.

Regarding, "it also drops |volume= which is probably not desirable", I think {{cite web}} has never supported |volume= or |issue=. The documentation for it, says to use a different template.[4] I would guess a preference for |access-date= which is harder to get wrong?

Unrelated, but while trying to see why {{cite web}} doesn't support |volume=, I came across several discussions (like this one[5]) showing a strong consensus to have {{cite magazine}} as a separate template for how it renders page/volume/issue. Rjjⁱⁱⁱ (talk) 22:28, 11 January 2024 (UTC)

Added TemplateData for Template:Cite document

I've just added the TemplateData for {{Cite document}}. Whatever this is supposed to do {{#invoke:cs1 documentation support|template_data_validate|{{ROOTPAGENAME}}}} just gives an error message for that template. I copied most of the parameters straight from {{Citation}} which was kind of tedious; is there a better way for other CS1 templates lacking TemplateData? Rjjⁱⁱⁱ (talk) 03:56, 9 January 2024 (UTC)

That {{#invoke:}} is for error checking the TemplateData parameter list against the module suite. Restored and lua script error fixed.

—Trappist the monk (talk) 15:21, 9 January 2024 (UTC)

Thanks! That made parameter trimming much easier, Rjjiii (ii) (talk) 17:28, 9 January 2024 (UTC)

support for |script-encyclopedia= and |trans-encyclopedia=

I have added support for |script-encyclopedia= and |trans-encyclopedia= to the sandbox. This answers lack-of-same that I mentioned at Help talk:Citation Style 1 § cite encyclopedia. The parameters are only valid in {{cite encyclopedia}} and {{citation}}:

{{cite encyclopedia/new |title=Title |encyclopedia=Encyclopedia |script-encyclopedia=ru:ScriptEncyclopedia |trans-encyclopedia=Trans Encyclopedia}}

"Title". Encyclopedia ScriptEncyclopedia [Trans Encyclopedia].

{{citation/new |title=Title |encyclopedia=Encyclopedia |script-encyclopedia=ru:ScriptEncyclopedia |trans-encyclopedia=Trans Encyclopedia}}

"Title", Encyclopedia ScriptEncyclopedia [Trans Encyclopedia]

—Trappist the monk (talk) 16:39, 9 January 2024 (UTC)

Like. Will {{citation}} ever support |chapter= and pals? Or is that another thing that's actually supported and I'm the one doing something wrong? Folly Mox (talk) 17:08, 9 January 2024 (UTC)

You are either doing it wrong or I don't understand what you mean by that question. {{citation}} has supported |chapter= and its aliases since forever ago:

{{citation |chapter=Chapter |title=Title}}

"Chapter", Title

—Trappist the monk (talk) 17:19, 9 January 2024 (UTC)

Numeric vs. named HTML entities

At least one editor seems to be interpreting Template:Cite news#COinS to mean that named HTML entities like &nbsp; are unwanted, but that numeric HTML entities like &#160; are OK in fields that contribute to COinS metadata...I think because there are no numeric entities listed as examples? I was planning to add some numeric examples unless I'm missing something? -- Beland (talk) 22:23, 9 January 2024 (UTC)

That's a funny one.  — SMcCandlish ☏ ¢ 😼  22:33, 10 January 2024 (UTC)

Added proposed example. -- Beland (talk) 22:32, 11 January 2024 (UTC)

title-link

So, what exactly is the use case of |title-link= in {{cite book}}? Why would we do {{cite book |title=The Elements of Style |title-link=The Elements of Style |...}} instead of {{cite book |title=[[The Elements of Style]] |...}}? The latter seems to overwhelmingly dominate; I hardly ever see |title-link=.  — SMcCandlish ☏ ¢ 😼  22:45, 12 January 2024 (UTC)

My vague impression is that splitting them out in this way makes it easier for the template to generate the zotero structured metadata that nobody actually uses. Why we need to generate this metadata and why the template can't split the link from the text itself are obvious questions. —David Eppstein (talk) 23:29, 12 January 2024 (UTC)

|title-link= was apparently new with the lua version of cs1|2:

Cite book comparison

Wikitext	{{cite book|title-link=The Elements of Style|title=The Elements of Style}}
Old	The Elements of Style.
Live	The Elements of Style.

I found this (malformed) template in Global Positioning System which may (or may not) illustrate a reason that |title-link= exists:

{{cite book|title=The American Practical Navigator – Chapter 11 ''Satellite Navigation''|author=Nathaniel Bowditch|publisher=United States government|year=2002|title-link=s:The American Practical Navigator}}

'"`UNIQ--templatestyles-000000B9-QINU`"'<cite id="CITEREFNathaniel_Bowditch2002" class="citation book cs1">Nathaniel Bowditch (2002). <span class="cs1-ws-icon" title="s:The American Practical Navigator">[https://en.wikisource.org/wiki/The_American_Practical_Navigator ''The American Practical Navigator – Chapter 11 ''Satellite Navigation''<span></span>''&nbsp;]</span>. United States government.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=The+American+Practical+Navigator+%E2%80%93+Chapter+11+Satellite+Navigation&rft.pub=United+States+government&rft.date=2002&rft.au=Nathaniel+Bowditch&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Nathaniel Bowditch (2002). The American Practical Navigator – Chapter 11 Satellite Navigation . United States government.

Here, I have rewritten to omit |title-link= by including the link in |title=:

{{cite book|title=[[s:The American Practical Navigator|The American Practical Navigator – Chapter 11 ''Satellite Navigation'']]|author=Nathaniel Bowditch|publisher=United States government|year=2002}}

'"`UNIQ--templatestyles-000000BD-QINU`"'<cite id="CITEREFNathaniel_Bowditch2002" class="citation book cs1">Nathaniel Bowditch (2002). <span class="cs1-ws-icon" title="s:The American Practical Navigator">[https://en.wikisource.org/wiki/The_American_Practical_Navigator ''The American Practical Navigator – Chapter 11 ''Satellite Navigation''''&nbsp;]</span>. United States government.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=The+American+Practical+Navigator+%E2%80%93+Chapter+11+Satellite+Navigation&rft.pub=United+States+government&rft.date=2002&rft.au=Nathaniel+Bowditch&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Nathaniel Bowditch (2002). The American Practical Navigator – Chapter 11 Satellite Navigation. United States government.

The COinS metadata are the same for both of these templates. The visual renderings are not the same.

This search finds about 26,000 articles that use |title-link=.

—Trappist the monk (talk) 00:25, 13 January 2024 (UTC)

It's not like |author-link= which is required due to |first= and |last=. It opens Pandora's Box, do we also have |publisher-link=, |location-link=? It's added complexity, unless really needed like authors. -- GreenC 02:06, 13 January 2024 (UTC)

And I can't see any pratical purpose at all to including a cutesy icon. Is it pulling a favicon from the site or something? We shouldn't have any images in citation unless we really, really, really think we badly need them, e.g. to indicate paywalled resources.  — SMcCandlish ☏ ¢ 😼  09:22, 3 February 2024 (UTC)

Url with pipe

Hi, I want to add {{cite journal}} with url https://periodika.lndb.lv/periodika2-viewer/?lang=en#panel:pp%7Cissue:45046%7Carticle:DIVL1125 that has pipe characters in it. The template thinks that "issue:45046|article:DIVL1125" are random unrecognized text and not part of the url. What's the workaround here? Thanks, Renata•3 01:43, 13 January 2024 (UTC)

Actually, nevermind, just resolved my issue. Saving the url replaced pipes with %7C and that works. Renata•3 01:45, 13 January 2024 (UTC)

That's the best way %7C. Thank you. Some editors replace pipe in URLs with {{!}} but this monstrosity mixes percent-encoding and wiki-encoding in the same URL, which violates RFC 3986 and makes every tool and bot writer reach for garlic and crosses. MediaWiki software allows for the mixing of encoding types within a URL is an example of an Internet worst practice. -- GreenC 02:17, 13 January 2024 (UTC)

Semi-protected edit request on 15 January 2024

Change Cite journal/doc to Mary Foundation at TheHowMan (talk) 02:45, 15 January 2024 (UTC)CatholiCity.com TheHowMan (talk) 02:45, 15 January 2024 (UTC)

 Not done: why? --AntiDionysius (talk) 02:47, 15 January 2024 (UTC)

References

Visible nbsp entities

Why in the world is the use of   being recommended in Template:Citation Style documentation/doc#Full vertical style? This results in those entities being visible in the resulting tables, like this (from Template:Cite magazine/doc — of course, I've omitted most of the rows):

Full parameter set in vertical format

Vertical list	Prerequisites	Brief instructions / notes
{{cite magazine | last1 = | first1 = | author-link1 = | last2 = | first2 = }}	     last1    last1  last2	           

• If a field name is listed in the Prerequisites column, it is a prerequisite for the field to the left.

That looks really, really bad.

This is how it should look:

Full parameter set in vertical format

Vertical list	Prerequisites	Brief instructions / notes
{{cite magazine | last1 = | first1 = | author-link1 = | last2 = | first2 = }}	last1 last1 last2

• If a field name is listed in the Prerequisites column, it is a prerequisite for the field to the left.

And that can be accomplished by simply using normal space characters in place of the  s.

I assume something changed recently that caused the entities to become visible, when they weren't before. Can we please change this on all the relevant doc pages? (I can do some of that.) - dcljr (talk) 19:20, 16 January 2024 (UTC)

@Dcljr: They were broken in this edit[6] and fixed here.[7] Thanks for catching it. The table used by the documentation on {{cite book}} seems like a better way to handle this. After checking the other documentation pages, many of them that don't have this formatting error, could use other types of improvement. For example, the {{cite encyclopedia}} documentation has had only minor changes (to update parameter names) since 2006.[8] Less commonly used templates just omit a full list of parameters. Rjjⁱⁱⁱ (talk) 22:45, 16 January 2024 (UTC)

Note that the columns no longer line up properly after your edit to Template:Cite magazine/doc (e.g., it's not clear that "last1" is a prerequisite for "first1"). I'd say a totally different format is called for (like that of Template:Cite book/doc, as you pointed out). The approach that we are discussing seems easily broken (as demonstrated here) and unnecessarily difficult to maintain. - dcljr (talk) 23:38, 16 January 2024 (UTC)

@Dcljr: I switched the parameters back to the old format also now. {{cite news}} was the only other template with this issue on the documentation. Rjjⁱⁱⁱ (talk) 00:19, 17 January 2024 (UTC)

OK, obviously we are both trying to edit the page at the same time. I'm stopping. - dcljr (talk) 00:24, 17 January 2024 (UTC)

@Dcljr: I'm done now. Do the columns look lined up? Rjjⁱⁱⁱ (talk) 00:26, 17 January 2024 (UTC)

Looks like it. And verified that both columns have the same number of rows. I guess it's OK now, since there shouldn't be any need for syntax highlighting in the middle column. But as I pointed out, just replacing the  s by regular spaces also worked. Like I said, this is a terrible format to use on such a large table. I plan to convert it to the other format "soon", unless I can be persuaded not to. - dcljr (talk) 00:36, 17 January 2024 (UTC)

Oh… I just noticed you left it without syntax highlighting in either (/any) column. Whatever. - dcljr (talk) 00:40, 17 January 2024 (UTC)

Yes, that's how it was done before.[9] I don't have objections to a different format. Good luck! Rjjⁱⁱⁱ (talk) 00:42, 17 January 2024 (UTC)

Recommend getting rid of three-column format entirely

As a followup to the previous section (#Visible nbsp entities), I recommend removing the instructions about the "Three-columns format" entirely from Template:Citation Style documentation#Full vertical style. Even for short tables, if any row in either the "Prerequisites" or "Brief instructions" column is too long, the rows will no longer line up due to line-wrapping. (See this in the wild. Here's a more extreme example, with wrapping in every column.) And for long tables, it's a nightmare to maintain. (And, as seen above, the recommendation to use   in blank rows fails when using <syntaxhighlight>, which some people will be tempted to do, instead of <pre> or <code><nowiki>.) For so many reasons, this seems like a terrible way of doing the "Full parameter set in vertical format" table. Can I get consensus to remove it? - dcljr (talk) 02:01, 17 January 2024 (UTC)

Protected edit request on 17 January 2024

Remove the following line, Reuters is a perfectly legitimate news agency and hence a valid corporate author, not a "generic name":

{['en'] = {'reuters', true}, ['local'] = nil}, Coco (talk) 14:53, 17 January 2024 (UTC)

@Cocô53: Since Reuters is a news agency, we should use |agency=Reuters instead of |author=Reuters or |last=Reuters. GoingBatty (talk) 20:11, 17 January 2024 (UTC)

@GoingBatty: Ok, my bad, I think I thought |agency= was just an allias for |publisher= due to this being positioned in the same place, not where |author= is. On the French language Wikipedia there is a parameter "institutional author" that appears first, and I was looking to use "cite web" to produce a similar effect. --Coco (talk) 23:18, 17 January 2024 (UTC)

"trans-series" parameter

Is there a reason why the {{cite book}} template does not have a trans-series parameter? I noticed it for this book, cited in Lokrume helmet fragment and other articles; the name of the series is in Norwegian, but there is no way to translate it.

• Grieg, Sigurd (1947). Gjermundbufunnet: En høvdingegrav fra 900-årene fra Ringerike [The Gjermundbu Find: A Chieftain Grave from the 900s from Ringerike]. Norske Oldfunn (in Norwegian). Vol. VIII. Oslo: Bergen. OCLC 984069139.

--Usernameunique (talk) 19:01, 17 January 2024 (UTC)

Limits

Hello. Can I ask you, please, to move all the limits to the module:Citation/CS1/Configuration wikidata page, to prevent bumping the numbers again and again for every local wiki version? There is definitely some property that can be used for this. IKhitron (talk) 15:08, 18 January 2024 (UTC)

That might be a good idea. There is definitely some property that can be used for this. If you know what those properties are (if they exist), please add them or tell us what they are. If those properties do not exist, I don't hold any hope for them ever existing. The last time I tried suggesting new properties over there at wikidata (on an unrelated topic), I was shot down in flames so after that scorching I'm rather fire-shy.

—Trappist the monk (talk) 15:17, 18 January 2024 (UTC)

I don't know Wikidata well enough, I think somebody that do should be asked about this. I hope there are. But even if there are not, you can always use the Commons data tables. It's more work to create the system, but better then nothing, FMO. IKhitron (talk) 15:22, 18 January 2024 (UTC)

Have you got a link to documentation about Commons data tables? Avoiding the politics of wikidata seems like a win to me if commons data tables will work.

—Trappist the monk (talk) 15:28, 18 January 2024 (UTC)

mw:Help:Tabular Data. But I think better to check if these Wikidata properties already exist, before worring about politics if they don't. IKhitron (talk) 15:33, 18 January 2024 (UTC)

I have created c:Data:Sandbox/CS1/Identifier limits.tab which is a simple tabular-data page that holds the limit values for the seven identifiers that use limits. I have also hacked Module:Citation/CS1/Configuration/sandbox to use the limit values from that tabular data page. The current limit for PMC is 10900000:

Cite book comparison

Wikitext	{{cite book|pmc=10900000|title=Title}}
Live	Title. PMC 10900000.
Sandbox	Title. PMC 10900000.

Cite book comparison

Wikitext	{{cite book|pmc=10900001|title=Title}}
Live	Title. PMC 10900001.
Sandbox	Title. PMC 10900001.

A possible downside to this mechanism (and also to wikidata) is that the tabular data are available for anyone to edit so vandalism and incompetence (tabular data is in JSON format – same as TemplateData – so is inherently fragile). A simple experiment indicates that the omission of a comma (and perhaps one of the necessary brackets – [, ], {, or }) is detected and while broken, the file cannot be saved.

—Trappist the monk (talk) 20:51, 18 January 2024 (UTC)

Well, it's your choice. But there is always a possibility to protect the file, and for the special cases to put into the module some extremally large default values which will play if the file is temporarly broken. IKhitron (talk) 20:59, 18 January 2024 (UTC)

Find a wikidata property suitable for identifier limit values that is allowable by those who maintain wikidata, and we can certainly experiment with that.

I think that I would choose to go the other way: an extremely small default value (perhaps 0) so that it becomes immediately obvious that something has gone terribly wrong with the tabular data. With a very small value all cs1|2 templates using that broken identifier limit value will show an error message whereas with an extremely large value, there will be no indication of a problem; that is not helpful.

—Trappist the monk (talk) 23:19, 18 January 2024 (UTC)

Again, I don't understand enough in Wikidata, but I'll ask some people.
About the default value, it's your choice, once more. I suggested a large number from exactly the same reason, error message, to avoid millions of articles in tracking categories. IKhitron (talk) 23:23, 18 January 2024 (UTC)

The identifier tests that use the limit values from the tabular data are all, more-or-less, variants of the form: if identifier_value > id_limit_value then error end. If the default-because-broken id_limit_value is a very large number, there will be no error message because id_limit_value will always be greater than identifier_value. When that is the case, no one will know that a problem exists. That no one knows that a problem exists is, to me, a bigger problem than a lot of articles in tracking categories.

—Trappist the monk (talk) 23:58, 18 January 2024 (UTC)

Well, I've asked, and get three names to talk about this. One of them is you, so I can't use it. @Pigsonthewing and @Wittylama, is there a chance you know some Wikidata properties that fit to this cause? IKhitron (talk) 00:27, 19 January 2024 (UTC)

@Mike Peel? Wittylama 01:50, 20 January 2024 (UTC)

Request to expand CS1 errors: extra text: edition

Could you please consider expanding Category:CS1 errors: extra text: edition to capture values where "edition" is in a foreign language? For example this search finds 27 instances of "baskı", the Turkish word for "edition". Thanks! GoingBatty (talk) 23:07, 19 January 2024 (UTC)

Request to expand CS1 errors: extra text: volume

Could you please consider expanding Category:CS1 errors: extra text: volume to capture values that include the word "issue" or "Issue"? For example this search finds 53 instances of "issue", which doesn't include the 12 I fixed manually. Thanks! GoingBatty (talk) 01:52, 20 January 2024 (UTC)

Help talk:Citation Style 1/Archive 92 § Extra text in |volume= and |issue=

—Trappist the monk (talk) 01:58, 20 January 2024 (UTC)

@Trappist the monk: Thank you for the reminder about that conversation. I checked a few of the results, and they don't seem to be caught in either error category live or in the sandbox. What am I missing?

Cite book comparison

Wikitext	{{cite book|title=From [[Sigismund III Vasa]]|volume=6, Issues 13–18}}
Live	From Sigismund III Vasa. Vol. 6, Issues 13–18.
Sandbox	From Sigismund III Vasa. Vol. 6, Issues 13–18.

Cite book comparison

Wikitext	{{cite book|title=From [[List of Baháʼís]]|volume=17, Issue 1 / April–June 2005}}
Live	From List of Baháʼís. Vol. 17, Issue 1 / April–June 2005.
Sandbox	From List of Baháʼís. Vol. 17, Issue 1 / April–June 2005.

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|title=From [[Thucydides Trap]]|volume=14, Issue 2, Summer 2021}}
Live	"From Thucydides Trap". Journal. 14, Issue 2, Summer 2021.
Sandbox	"From Thucydides Trap". Journal. 14, Issue 2, Summer 2021.

GoingBatty (talk) 02:52, 20 January 2024 (UTC)

One more, just to confirm it's an issue (pun intended) with both "Issue" and "issue":

Cite journal comparison

Wikitext	{{cite journal|journal=Journal|title=From [[Anne de Pisseleu d'Heilly]]|volume=20 issue: January 1}}
Live	"From Anne de Pisseleu d'Heilly". Journal. 20 issue: January 1.
Sandbox	"From Anne de Pisseleu d'Heilly". Journal. 20 issue: January 1.

GoingBatty (talk) 02:56, 20 January 2024 (UTC)

The 'issue' tests expect that 'issue' and its variants will be the first element found in a parameter value. I don't recall why the tests are constrained like that. Anyone?

All of your examples begin with digits so we might write additional patterns:

^%d+[,;:%-]?%s*[Ii]ssues?

^%d+[,;:%-]?%s*[Nn]umbers?

etc

But, such patterns would catch stuff like |volume=1: Number of Inhabitants which we should not catch. Given that, I suspect that what you are asking is better suited to specialized searches.

—Trappist the monk (talk) 15:06, 20 January 2024 (UTC)

Do I have to do each entry manually or is there a simpler way.

Thanks. Doug Weller talk 14:37, 20 January 2024 (UTC)

You are going to have to be more explicit than that. If you are talking about citation filling tools, this venue is not the correct place. WP:RefToolbar and that abomination that is the visual editor can autofill template parameters (sometimes even correctly). Those tools are outside of the cs1|2 bailiwick.

—Trappist the monk (talk) 15:09, 20 January 2024 (UTC)

@Trappist the monk Sorry, remiss of me not to give an example. See Kenneth_Feder#Books. I hate the visual editor. I didn't think ref toolbar did this. Doug Weller talk 17:17, 20 January 2024 (UTC)

It ain't perfect. For example, giving toolbar ISBN 978-0-313-37918-5 and clicking the quizzing glass gets this:

{{cite book |last1=Feder |first1=Kenneth L. |title=Encyclopedia of dubious archaeology: from Atlantis to the Walam Olum |date=2011 |publisher=Greenwood |location=Santa Barbara, Calif. |isbn=978-0-313-37918-5}}

which is sort of similar to your version:

{{cite book |first=Kenneth |last=Feder |year=2010 |title=Encyclopedia of Dubious Archaeology: From Atlantis to the Walam Olum |url=https://archive.org/details/encyclopediaofdu0000fede |url-access=registration |publisher=[[Greenwood Publishing Group]] |isbn=978-0-313-37918-5}}

no |url=, no |url-access=; |date=, |first=, |publisher=, and |title= have different values; toolbar gives |location=.

But, giving toolbar ISBN 978-1-4422-6312-3 and clicking the quizzing glass gets nothing.

Do not trust what toolbar gives you. Sometimes you get a good cs1|2 template; sometimes you get junk.

—Trappist the monk (talk) 17:37, 20 January 2024 (UTC)

@Doug Weller: The ProveIt gadget offers the same feature beyond the top 4 citation templates. The RefToolbar, ProveIt, the Visual Editor, and so on all rely on Citoid. If you need a URL for {{cite book}}, you have to feed Citoid the URL (not the ISBN) and the output will depend on how well that URL formats the data. Rjjⁱⁱⁱ (talk) 18:20, 20 January 2024 (UTC)

Umm, what? URLs don't format data...

—Trappist the monk (talk) 18:27, 20 January 2024 (UTC)

@Trappist the monk: How well [the web page at] that URL formats the data.

On archive.org some uploads have really clear and accurate information where you may have a small error (location and publisher are combined on the example above) or even no errors. Other pages will provide no information. It's not uncommon when using a URL though to have Citoid provide seemingly random information, especially in the title and author parameters. Rjjⁱⁱⁱ (talk) 18:47, 20 January 2024 (UTC)

Using Google books for autofilling most of the fields usually works, searching "isbn:978-1-4422-6312-3" with the books filter gives you one work[10] using that URL (https://books.google.co.uk/books?id=t4fKjwEACAAJ) in reftool bar should autopopulate most fields. Obviously it may require some manual intervention, and you can always remove or replace the URL with another one afterwards. -- LCU ActivelyDisinterested «@» °∆t° 23:13, 20 January 2024 (UTC)

Tried to add Proveit, nothing happened. I clicked the "use Wikiedit' button on the right and n now on Chrome the screen is partially covered, on the left with the Logo etc menu, and I can't click on the right hand buttons because they are covered by the Search WIkipedia field. Not asking for help here, just saying what happened. I'll carry on working with other browsers, this is Chrome specific and has happened before, presumably an update. Doug Weller talk 14:40, 21 January 2024 (UTC)

@ActivelyDisinterested Thanks, that is exactly what I need. I get some of the details, add the others, delete the <ref> and <ref/> and as the cliche goes, Bob's your uncle. I just have to avoid Chrome for a while.:-) Doug Weller talk 15:55, 21 January 2024 (UTC)

How to mark an offline newspaper resource as unverifiable?

I'm currently working on Adventure Unlimited and there's a citation to a 1968 newspaper article with date and page number. However I have found the newspaper of that masthead from that date in the Google News archives and the named heading doesn't seem to appear in the newspaper at all on that date. Is it best to remove the citation, or otherwise what maintenance template would be best to use in this situation? The documentation at {{Failed verification}} says that the citation should still be somewhat relevant. Reader781 (talk) 01:22, 22 January 2024 (UTC)

Which citation in particular is this? And using e.g., Wikipedia:WikiBlame to find the editor who added that source, can you tag them in the talk page and figure out where the possible disconnect might arise from? It might be that Google News didn't digitize supplements, that there are different editions, that the date got mistyped, etc., so I wouldn't delete it outright but I'm not sure the best tag to use -- {{Citation not found}} sounds like it might be applicable but that also isn't right for this situation where you just are having trouble finding the source in the first place. Umimmak (talk) 01:32, 22 January 2024 (UTC)

I often just use {{clarify}} with an extensive description of the problem in |reason=.

—Trappist the monk (talk) 01:40, 22 January 2024 (UTC)

Oh that's a good start, @Trappist the monk. {{clarify}} mentions {{specify}} for use with sourcing issues too.

@Umimmak it's reference No. 23, "Magical Art of Acting and Eating", from The Age. I'll see what WikiBlame turns up and go from there, otherwise use either one of the above-mentioned templates. Thanks to the both of you. Reader781 (talk) 01:48, 22 January 2024 (UTC)

Well I was able to find the source in question -- seems to be an accurate citation? Wednesday January 29, 1969, The Age, "Magical Art of Acting and Eating" [11] [12] Umimmak (talk) 02:06, 22 January 2024 (UTC)

@Reader781: realized I forgot to ping Umimmak (talk) 02:08, 22 January 2024 (UTC)

A-ha! It was a date typo - 1969 not 1968. Thank you so much for finding this. Not sure why it didn't occur to me to search for it by name, but thanks again! I was just having a bite to eat before continuing, I'll add this to my edit in progress. Reader781 (talk) 02:13, 22 January 2024 (UTC)

Ah there we go! Not an accurate citation then, I mentally fixed it while reading I suppose, but that explains the discrepancy. :) Umimmak (talk) 02:15, 22 January 2024 (UTC)

Cite interview via field?

The documentation for {{Cite interview}} says it supports a via= field, but when I edit the template in the visual editor, there's no via listed. What's wrong? RoySmith (talk) 18:51, 22 January 2024 (UTC)

@RoySmith: Hi there! {{Cite interview}} does indeed support |via=

{{cite interview |title=Title |via=ViaTest}} generates "Title" (Interview) – via ViaTest.

Therefore, I added |via= to the Template data in this edit to Template:Cite interview/doc, so you should now see it when adding the template in the VisualEditor. I haven't checked, but there are probably additional opportunities to improve the documentation and/or TemplateData. GoingBatty (talk) 19:26, 22 January 2024 (UTC)

Yup, it now shows up as "Published Via", although calling it just plain "Via" would be more in line with the name used in other templates. Thanks for fixing this! RoySmith (talk) 21:48, 22 January 2024 (UTC)

@RoySmith: I attempted to make the Template data in Template:Cite interview/doc consistent with Template:Cite web/doc, which uses "Published via", but I see I got the capitalization wrong. Feel free to change Template:Cite interview/doc and/or Template:Cite web/doc to whatever you prefer. GoingBatty (talk) 22:43, 24 January 2024 (UTC)

Got it, thanks. I see now that the actual field name is indeed "via", it's just the display name in the UI, so that's no big deal. RoySmith (talk) 23:01, 24 January 2024 (UTC)

Cita web errors

This week I'm cleaning up dozens of edits like this one where User:AnomieBOT mangles a {{cita web}} reference that is missing (due to a previous human error) the title field and displaying a red error message that requires manual attention. This is difficult to recover from, because the edit often cannot be undone due to later edits, and I'm sure for most editors it's not obvious that they need to dig through the article history to recover the URL and find a title for it. I can see three fixes for this:

1. Edit the template so that when it experiences an error of this type it returns more suitable output that retains the original parameters but only displays the error message to readers. (Maybe adding "|nosubst=1" so bots don't keep trying to change it, if it's not converted to {{cite web}}?)
2. Add logic to AnomieBOT to detect red or orange error messages and refrain from subst-ing those instances.
3. Remove Template:Cite web/Italian or Spanish (to which Template:Cita web redirects) from Category:Wikipedia templates to be automatically substituted.

@Anomie: Do you have stats on how many times a month or whatever this particular template is subst'd? That would help decide if doing 3 would just make a ton of work for editors or if it would be better on balance. Also especially interested in your thoughts on 2. Thanks! -- Beland (talk) 20:27, 24 January 2024 (UTC)

This is not the fault of AnomieBOT. {{cita web}} calls Module:CS1 translator which attempts to translate what it expects is a more-or-less properly formatted template with Spanish- or Italian-language parameter names. The module uses |título= (Spanish) or |titolo= (Italian) to choose which language to use when translating the other parameters in the template. In this case, the editor apparently manually translated everything except the template name (or committed that most heinous of sins, a typo).

I'll think about how to fix this problem (which will also apply to {{cita news}} and {{cita libro}}).

As I write this, there are seven articles displaying the error message (search)

—Trappist the monk (talk) 21:04, 24 January 2024 (UTC)

Five a few hours later, 4 where from a cite webb with a typo and the last was unrelated to this issue (junk copied from itwiki without the editor doing any checks). -- LCU ActivelyDisinterested «@» °∆t° 02:36, 25 January 2024 (UTC)

AnomieBOT's logs for January so far show 135 mentions of substing that template, and the logs for December show 160. I don't keep logs further back than that. IMO the best solution would be to either turn off bot-substing for the template or fix it so its substed output in this situation is more useful. Note that adding |nosubst=1 to the output might eventually result in over 100 unsubsted transclusions, which would stop the bot from substing that template entirely until someone cleans it up. Anomie⚔ 23:40, 24 January 2024 (UTC)

Given the high likelihood of typos as the cause for {{cita web}} and {{cita news}}, wouldn't it be more prudent that bots not attempt to "fix" these? -- Michael Bednarek (talk) 01:14, 25 January 2024 (UTC)

This is not a bot issue. AnomieBOT just does substing that MediaWiki can't (apparently won't ever) do.

—Trappist the monk (talk) 15:51, 25 January 2024 (UTC)

Is there anyway for AnomieBOT to check for |title= before doing the substitution, and if it does just correct the typo (cita -> cite)? -- LCU ActivelyDisinterested «@» °∆t° 02:18, 25 January 2024 (UTC)

It is not AnomieBOT's responsibility to do such checks. AnomieBOT's purpose in all of this is to subst an English cs1|2 template in place of the original non-English template and nothing more.

—Trappist the monk (talk) 15:51, 25 January 2024 (UTC)

I have hacked Module:CS1 translator so that when {{cita libro}}, {{cita news}}, and {{cita web}} do not have either of |título= (Spanish) or |titolo= (Italian), the module translates the template name to {{cite book/subst}}, {{cite news/subst}}, or {{cite web/subst}} as appropriate. If, as in the example case, the template was properly translated by hand except for the template name, AnomieBOT will subst the template name to the canonical {{cite book}}, {{cite news}}, or {{cite web}} as appropriate.

This version of my sandbox has the originally offending template. The error message that the previous version of the module emitted is not present. A subsequent version of my sandbox shows the template after AnomieBOT has done the substing.

—Trappist the monk (talk) 15:51, 25 January 2024 (UTC)

Great work thanks Trappist the monk, and apologies for misunderstanding the technical situation. -- LCU ActivelyDisinterested «@» °∆t° 19:32, 25 January 2024 (UTC)

Woo, thanks for the quick fix! -- Beland (talk) 23:42, 30 January 2024 (UTC)

unflagged 'free' dois that aren't really 'free'

I just stumbled upon doi:10.3410/f.736364175.793573144 in List of biological databases. I had to fix this reference (missing |journal=) and discovered that the source requires 'free' registration. To my mind, any source that requires me to give over personally identifying information, is not 'free'. So, I think that doi registrant 3410 should be removed from Module:Citation/CS1/Configuration and any template with that registrant in article namespace should be edited to remove the |doi-access=free parameter (currently ~85 articles).

—Trappist the monk (talk) 14:56, 25 January 2024 (UTC)

I'm note sure about that link, but doi:10.1093/molbev/msz147 should be the DOI used. I'll investigate a bit. Headbomb {t · c · p · b} 16:42, 27 January 2024 (UTC)

Seems free registration is required to read free non-F1000 papers (e.g. doi:10.1093/molbev/msz147) with F1000 DOIs (doi:10.3410/f.736364175.793573144) – an abhorrent practice – and that actual F1000 papers with F1000 DOIs don't require registration (e.g. doi:10.3410/M2-49). The fix here seems to update the papers to use their legit DOI. Headbomb {t · c · p · b} 16:47, 27 January 2024 (UTC)

{{citation}} with |mode=cs1 and |postscript=none

{{citation}} should be able to accept |mode=cs1 and simultaneously |postscript=none without emitting a maintenance message. Alas, that is not what is happening now. I discovered this when attempting a fix at {{NDB}} because that template, when written with |mode=cs1, emits .; as the postscript separator.

I have hacked on the module sandbox so that {{citation}} with both |mode=cs1 and |postscript=none works properly:

Citation comparison

Wikitext	{{citation|mode=cs1|postscript=none|title=Title}}
Live	Title
Sandbox	Title

—Trappist the monk (talk) 16:36, 27 January 2024 (UTC)

Doi throws error

If this citation is included in an article

it gives the following message that can be seen in page preview mode: "Script warning: One or more {{cite journal}} templates have maintenance messages; messages may be hidden (help)."

I have determined (through the time-wasting process of commenting out citations individually to find the offending source) that it is the doi that creates the error; if the doi is left out of the citation, the warning message does not appear. The doi appears to be unremarkable and functional, so I have no idea what the issue is. This is not the only time I've had this problem, so I can dig up more examples if needed. The affected article for the above example is Cladoniaceae. Esculenta (talk) 18:54, 27 January 2024 (UTC)

The script warning message that you quote has a help link. When you click that link you end up at Help:CS1 errors § Controlling error message display. Normally hidden maintenance messages can be unhidden by following the instructions on that page.

—Trappist the monk (talk) 19:27, 27 January 2024 (UTC)

Next time it happens, check the categories for unusual behaviour; in this case you'd have seen Category:CS1 maint: unflagged free DOI, and the solution is to set the "doi-access=free" parameter. Esculenta (talk) 20:53, 27 January 2024 (UTC)

@Esculenta: The hidden maintenance message states "CS1 maint: unflagged free DOI". To remove it, try adding |doi-access=free, like this. GoingBatty (talk) 21:10, 27 January 2024 (UTC)

References

Generic name warning for organizational author value passed to param "last" and alias "author"

I think I'm seeing this same error on Impact factor (remoteref: ^[40], reproduced below for convenience)

The reference uses the author parameter, but I've found that using last results in the same error message. If I'm reading the docs correctly, author is supposed to be a valid alias for last, and the latter is the parameter one is supposed to use for e.g. "The PLoS Medicine Editors":

Authors

last: Surname of a single author. Do not wikilink—use author-link instead. For corporate authors or authors for whom only one name is listed by the source, use last or one of its aliases (e.g. |author=Bono). Aliases: surname, author, last1, surname1, author1.

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

Also, I checked the archives, but please let me know if I missed an existing thread about this (or if I can improve my post in general)!

Sources

– spida-tarbell ❀ (talk) (contribs) 23:17, 28 January 2024 (UTC)

Help:CS1 errors#generic name reads False positives are possible. When the name is valid, wrap the parameter value in the accept-this-as-written markup: :|author=((Super User)), so I guess you could just have:

• {{cite journal |author=((The PLoS Medicine Editors)) |title=The impact factor game |journal=PLoS Medicine}}
• The PLoS Medicine Editors. "The impact factor game". PLoS Medicine.

Umimmak (talk) 23:26, 28 January 2024 (UTC)

(edit conflict)

Kind of unclear what you want from us. Yes, |author= is an alias of |last=. Use |author= for corporate or 'group' names. The error message appears because |author=The PLoS Medicine Editors contains Editors which is considered to be a generic 'name'. When a generic name is actually legitimate, rewrite the parameter value to suppress the error message using the accept-this-as-written markup: |author=((The PLoS Medicine Editors)).

—Trappist the monk (talk) 23:33, 28 January 2024 (UTC)

The accept-as-written is relatively new - perhaps added when error checking became more aggressive. There is no mention at {{cite journal}} that this applies to the author or editor fields. What is the best way to update the individual citation templates involved? StarryGrandma (talk) 23:50, 28 January 2024 (UTC)

Not really 'new'. The markup was first proposed at Help talk:Citation Style 1/Archive 8 § Corporate authors and |vauthors= 10 May 2015 and implemented 25 July 2015.

Including a statement about what the ((..)) markup does for each parameter seems like documentation bloat. Perhaps for each affected parameter, we add a simple link to the documentation at Help:Citation Style 1:

Supports accept-this-as-written markup.

or somesuch. If you know of a better way, say it.

—Trappist the monk (talk) 00:21, 29 January 2024 (UTC)

 Added in this edit. Adjust as you see fit. GoingBatty (talk) 01:52, 29 January 2024 (UTC)

Ah, I hadn't recognized that was the trigger for the "generic name." And I had meant to ask why this is happening and what I should change to fix or head off the error. Thank you. – spida-tarbell ❀ (talk) (contribs) 01:59, 29 January 2024 (UTC)

@Spida-tarbell: Another option is to remove "The PLoS Medicine Editors" from the citation. I don't see what value it provides to the reader of the Wikipedia article. GoingBatty (talk) 23:40, 28 January 2024 (UTC)

Because it lets them know who wrote the article, and that it was specifically the PLoS Medical editors. Why would it ever be useful to the reader to remove information from a citation; that makes it ambiguous between an editor forgetting to add a parameter in the citation and having no credited author (which is not the case here; there is an explicit byline). Umimmak (talk) 23:48, 28 January 2024 (UTC)

It is the standard for citations in this area to include whatever the journal says the authors are. Part of what we do is attribution, crediting authors, even if they are a committee. StarryGrandma (talk) 23:53, 28 January 2024 (UTC)

Point taken. Then you'd want the formatting to be the same as whatever the journal says the authors are:

• {{cite journal |author=((The ''PLoS Medicine'' Editors)) |title=The impact factor game |journal=PLoS Medicine}}
• The PLoS Medicine Editors. "The impact factor game". PLoS Medicine.

GoingBatty (talk) 23:58, 28 January 2024 (UTC)

Except that doing so produces corrupt metadata:

&rft.au=The+%27%27PLoS+Medicine%27%27+Editors

We allow italic markup in |title= so no doubt, we can use the same or similar mechanism for name-list parameters. Is there sufficient need to do that? It ain't free; every name would have to be tested.

—Trappist the monk (talk) 00:21, 29 January 2024 (UTC)

@Trappist the monk: Thank you. I've updated the documentation according to the information you provided. GoingBatty (talk) 00:30, 29 January 2024 (UTC)

Thank you all! I've updated the reference and, in case it's helpful, added a comment noting that italics corrupt metadata. – spida-tarbell ❀ (talk) (contribs) 02:30, 29 January 2024 (UTC)

Citing original author of reprint

I want to cite the author of the Introduction to this reprint of an old book. I have this format, {{cite book |last1=Widmer |first1=Randolph J. |title=Exploration of Ancient Key-Dweller Remains on the Gulf Coast of Florida |year=2000 |publisher=The University Press of Florida |location=Gainesville, Florida |isbn=0-8130-1791-2 |pages=i-xxii |chapter-url=https://books.google.com/books?id=gRiwKU4ikkkC&q=van+beck+key+marco&pg=PR10 |author2=Frank Hamilton Cushing |author-link=Frank Hamilton Cushing |orig-date=1896 |chapter=Introduction}} in the article, but I cannot figure out how to show Cushing as the author of the original book without making it look like Widmer and Cushing are co-authors. My apologies if this has been covered before, but I haven't figured out a search term that finds such a discussion in the archives. Donald Albury 01:09, 30 January 2024 (UTC)

{{cite book |contributor-last1=Widmer |contributor-first1=Randolph J. |title=Exploration of Ancient Key-Dweller Remains on the Gulf Coast of Florida |year=2000 |publisher=The University Press of Florida |location=Gainesville, Florida |isbn=0-8130-1791-2 |pages=i-xxii |chapter-url=https://books.google.com/books?id=gRiwKU4ikkkC&q=van+beck+key+marco&pg=PR10 |first=Frank Hamilton |last=Cushing |author-link=Frank Hamilton Cushing |orig-date=1896 |contribution=Introduction}}

Widmer, Randolph J. (2000) [1896]. Introduction. Exploration of Ancient Key-Dweller Remains on the Gulf Coast of Florida. By Cushing, Frank Hamilton. Gainesville, Florida: The University Press of Florida. pp. i–xxii. ISBN 0-8130-1791-2.

—Trappist the monk (talk) 01:21, 30 January 2024 (UTC)

Really? Surely Widmer is the author, the only author. Cushing just wrote a new intro. So (unless the chapter cited is the intro, which it isn't) I see no reason to even mention Cushing unless it would be reasonable to declare him as an editor? --𝕁𝕄𝔽 (talk) 11:50, 30 January 2024 (UTC)

So (unless the chapter cited is the intro, which it isn't) Umm, are you sure? First sentence of OP's post (emphasis added):

I want to cite the author of the Introduction to this reprint of an old book.

In cs1|2, a separately authored contribution (the introduction) to the work of a primary author (Cushing) goes in |contribution=. The author of the contribution (Widmer) is named using |contributor= parameters. OP's template is a bit misleading in that it specifies a broader page range than it should: |pages=i-xxii when it should be |pages=ix-xxii (for the whole introduction) or perhaps better |page=x which agrees with the template's |url= value.

—Trappist the monk (talk) 13:23, 30 January 2024 (UTC)

That's it! Thank you. Donald Albury 13:28, 30 January 2024 (UTC)

Cite journal bibcode param

When you set the bibcode parameter as well as postcript, the bibcode does not display or link properly in the created citations: {{Cite journal |last=Bomford |first=G. |author-link=Guy Bomford |date=1967-09-01 |title=James de Graaff-Hunter (obituary) |journal=[[Quarterly Journal of the Royal Astronomical Society]] |volume=8 |pages=292–293 |bibcode=1967QJRAS...8..292. |postscript=;}} displays:

• Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.;

This is clearly not displaying correctly, and it gets even worse when you add text after the template; see {{Cite journal |last=Bomford |first=G. |author-link=Guy Bomford |date=1967-09-01 |title=James de Graaff-Hunter (obituary) |journal=[[Quarterly Journal of the Royal Astronomical Society]] |volume=8 |pages=292–293 |bibcode=1967QJRAS...8..292. |postscript=;}} also published in ''[[Survey Review]]''. ''' 19''' (144): 50–51. {{doi|10.1179/sre.1967.19.144.50}}.

• Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.; also published in Survey Review. 19 (144): 50–51. doi:10.1179/sre.1967.19.144.50.

Now the link works, but also adds the link to the following text. And the doi at the end of the following text does not link properly. BhamBoi (talk) 00:30, 1 February 2024 (UTC)

Some bugs just take a while to show themselves. This one has been a sleeper since March 2013 (diff).

What is happening is that when there is a postscript, following a bibcode identifier and the identifier's last character is a dot, the code indiscriminately removes the bibcode link's closing ]. That, of course, breaks the rendering. If the last character of the bibcode identifier is not a dot, the live code works as it should:

{{cite book |title=Title |bibcode=1967QJRAS...8..292a |postscript=;}}

Title. Bibcode:1967QJRAS...8..292a;

The code in the live module was supposed to remove the terminal separator character (for cs1, a dot). I have tweaked the sandbox so that the code will only remove a terminal dot:

Cite journal comparison

Wikitext	{{cite journal|author-link=Guy Bomford|bibcode=1967QJRAS...8..292.|date=1967-09-01|first=G.|journal=[[Quarterly Journal of the Royal Astronomical Society]]|last=Bomford|pages=292–293|postscript=;|title=James de Graaff-Hunter (obituary)|volume=8}}
Live	Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.;
Sandbox	Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.;

Citation comparison

Wikitext	{{citation|author-link=Guy Bomford|bibcode=1967QJRAS...8..292.|date=1967-09-01|first=G.|journal=[[Quarterly Journal of the Royal Astronomical Society]]|last=Bomford|pages=292–293|postscript=;|title=James de Graaff-Hunter (obituary)|volume=8}}
Live	Bomford, G. (1967-09-01), "James de Graaff-Hunter (obituary)", Quarterly Journal of the Royal Astronomical Society, 8: 292–293, Bibcode:1967QJRAS...8..292.;
Sandbox	Bomford, G. (1967-09-01), "James de Graaff-Hunter (obituary)", Quarterly Journal of the Royal Astronomical Society, 8: 292–293, Bibcode:1967QJRAS...8..292.;

{{citation}} comparison to show that I didn't break anything.

For i18n, the internal variable sepc can be something other than a dot. The module will remove that terminator when sepc is not defined as a dot in Module:Citation/CS1/Configuration.

—Trappist the monk (talk) 15:21, 1 February 2024 (UTC)

If I'm including the citation in an article, what should I do for now? BhamBoi (talk) 00:36, 2 February 2024 (UTC)

The obvious workaround is:

{{Cite journal |last=Bomford |first=G. |author-link=Guy Bomford |date=1967-09-01 |title=James de Graaff-Hunter (obituary) |journal=[[Quarterly Journal of the Royal Astronomical Society]] |volume=8 |pages=292–293 |bibcode=1967QJRAS...8..292. |postscript=none}};

Bomford, G. (1967-09-01). "James de Graaff-Hunter (obituary)". Quarterly Journal of the Royal Astronomical Society. 8: 292–293. Bibcode:1967QJRAS...8..292.;

—Trappist the monk (talk) 00:44, 2 February 2024 (UTC)

Thanks BhamBoi (talk) 00:47, 2 February 2024 (UTC)

Issue citation currently broken

* {{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |contribution=The Horoscope of the Foundation of Rome |title=Classical Philology |volume=81 |issue=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}.

and

* {{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |contribution=The Horoscope of the Foundation of Rome |title=Classical Philology |volume=81 |number=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}.

are both currently displaying as

• Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, vol. 81, Chicago: University of Chicago Press, pp. 148–153, JSTOR 269789.

instead of providing the issue number either "correctly" (no. 2) or in the uglier compact formatting in parentheses after the volume. Kindly fix it or undo whatever 'fix' told the base template to stop displaying the field. No, the vast majority of users do not want to bother with memorizing ever shifting subsets of templates when there's a single underlying citation format we can use (and should be able to use) for everything. — LlywelynII 18:44, 5 January 2024 (UTC)

I can't confirm if any change has happened recently but would this not work:
* {{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |title=The Horoscope of the Foundation of Rome |journal=Classical Philology |volume=81 |number=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}.
* Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, 81 (2), Chicago: University of Chicago Press: 148–153, JSTOR 269789.
As I understand it 'citation' dynamically formats depending on which fields you use. Contribution/Title cause it to beleive your cite is for a book rather than a journal. -- LCU ActivelyDisinterested «@» °∆t° 19:12, 5 January 2024 (UTC)

(edit conflict)

There is nothing new here. Here is how both of your examples actually render:

Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, vol. 81, Chicago: University of Chicago Press, pp. 148–153, JSTOR 269789

{{citation}} is and has been for a very long time sort of automatic in that it will render a correct citation if you, the editor, give it the correct parameters. Apparently, Classical Philology is a peer-reviewed academic journal. As such, when citing an article in that journal, it is incumbent upon you to tell {{citation}} that you are citing a journal by providing a value for |journal=. This is how {{citation}} knows to render |issue=. So, slight tweaks (|title= → |journal= and |contribution= → |title= gives this rendering:

{{citation |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |title=The Horoscope of the Foundation of Rome |journal=Classical Philology |volume=81 |issue=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}

Grafton, A.T.; et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, 81 (2), Chicago: University of Chicago Press: 148–153, JSTOR 269789

Without |journal=, {{citation}} assumes that the source being cited is a book so renders the citation accordingly.

—Trappist the monk (talk) 19:16, 5 January 2024 (UTC)

But none of this is correct. It's a contribution to a work with a title and what is the possible benefit of suppressing the issue fields when they are provided? It's not a misapplied syntax. It's just a badly formatted template that previously worked and now doesn't because the word "title" is being misparsed as "book" for no apparent reason. It is something to fix, not something to lecture on. — LlywelynII 15:03, 28 January 2024 (UTC)

Shouting and moving this discussion to the bottom of this talk page does not bolster your argument. TLDR: nothing needs fixing; feel free to ignore the following 'lecture'.

In all of en.wiki, Grafton & Swerdlow's article "The Horoscope of the Foundation of Rome" from Classical Philology (journal) is mentioned in this discussion and in three other places (this search):

• Founding of Rome added at this edit 5 January 2024 by you
• Talk:Founding of Rome § Plutarch added at this edit 5 January 2024 by you
• Sulcus primigenius added at its creation 9 January 2024 by you

Your claim that the Grafton & Swerdlow template previously worked is incorrect. Here is that template as rendered by {{citation/old}}, the wikitext (pre-Lua module) version:

{{citation/old |last=Grafton |first=A.T. |author2=N.M. Swerdlow |display-authors=1 |ref={{harvid|Grafton & al.|1986}} |date=April 1986 |jstor=269789 |contribution=The Horoscope of the Foundation of Rome |title=Classical Philology |volume=81 |issue=2 |pp=148-153 |publisher=University of Chicago Press |location=Chicago }}

Grafton, A.T. et al. (April 1986), "The Horoscope of the Foundation of Rome", Classical Philology, 81, Chicago: University of Chicago Press, JSTOR 269789 

For completeness, some history:

• We discussed limiting the use of |volume=, |issue=, |pages= in the cs1|2 templates at Help talk:Citation Style 1/Archive 10 § |volume=, |issue=, |page(s)= and cite magazine 18 November – 10 December 2015
• That discussion was implemented in the live cs1|2 module suite 5 December 2015.
• A table similar to the table in the above mentioned discussion, 'cs1|2 support for |volume=, |issue=, |page(s)=', was added to Help:Citation Style 1 § Pages at this edit 16 October 2016

There have been no recent changes that affect the suppression of |issue= in cs1|2 book citations (which includes {{citation}} without a periodical parameter).

—Trappist the monk (talk) 16:48, 28 January 2024 (UTC)

For journal articles, the OP might consider using {{cite journal}} with |mode=cs2 to achieve their desired output more easily. – Jonesey95 (talk) 01:47, 29 January 2024 (UTC)

OP would like a single template that works for all formats, which is what {{citation}} used to do, regardless of Trappist's claims. Title should handle all actual titles of complete works; contribution should handle all sectional titles within such works; and volumes and issues should display correctly when listed. OP specifically does not want to have to enter entirely separate templates for each separate form of work, which is needless bother.

All that needs to happen is that the code doesn't preemptively ignore the |issue= field. It's currently broken, easily fixed, and should be fixed. If it's been broken since 2015 without my noticing it, fine, but it's still needlessly broken and should still be corrected now. — LlywelynII 05:24, 3 February 2024 (UTC)

Here is a link to the very first version (permalink) of {{citation}} from 15 November 2005. {{{issue}}} (and its alias {{{number}}}) appear only where {{{journal}}} (and its alias {{{periodical}}}) appear. I can find no evidence that {{citation}} ever supported |issue= when the template did not include |journal= or other 'periodical' parameter.

Your claims to the contrary require evidence. So far all you have done is to make declarations about what {{citation}} used to do without supporting those declarations with evidence. Produce the evidence.

—Trappist the monk (talk) 14:52, 3 February 2024 (UTC)

Not shouting. Just highlighting the important bit in what's become a textwall post inside a textwall talk page. I get it that you're opposed and will either ignore me or revert changes if I implement them myself, since you seem to be the caretaker around here. (And thanks for that!) It's still important that this stand out for other posters when they come here for their own problems so they can add their +1 until you realize it's a template problem instead of a "rando schlub" problem and, y'know, actually fix it/allow it to be fixed. — LlywelynII 05:31, 3 February 2024 (UTC)

What you're shouting about has never existed as has been explained. {{citation}} has always auto-formated cites based on the fields it is supplied. If you don't supply the expected fields it won't format as you expect.
If you want something new maybe you should discuss the matter as a request for something new. -- LCU ActivelyDisinterested «@» °∆t° 16:51, 3 February 2024 (UTC)

Exporting Module:Citation/CS1 to my own wiki

Okay, I think this is where my technical expertise falls short, but I have been trying to export the Module:Citation/CS1 system to my own wiki. However, when I do, I get an error at https://nsindex.net/wiki/War, which states:

[6161720f6cfbf54ba3955ec6] /wiki/War MediaWiki\Storage\NameTableAccessException: Failed to access name from content_models using id = 4

The extensions and version info I am using are listed at: https://nsindex.net/wiki/Special:Version. I don't know changes I need to make to the modules, to make it work on an independent wiki. --Minoa (talk) 06:25, 3 February 2024 (UTC)

This appears to be a technical import issue that is outside the cs1|2 bailick. Having never done an import, I have only a passing knowledge of the process. Perhaps your best source of help is at WP:Village pump (technical). I would suggest that you describe, in full, the steps that you took that got you to where you are now. The cs1|2 module suite is routinely imported by other wikis so it would seem that the issue is in your particular wiki's setup.

—Trappist the monk (talk) 13:02, 3 February 2024 (UTC)

I would guess that you have misconfigured Scribunto or TemplateStyles or one of their dependencies, or lacking one of the latter (I note that you do not have LuaSandbox installed). Either way, this error is an issue for normal MediaWiki support channels like #mediawiki on mw:IRC or mw:Support. Izno (talk) 19:39, 3 February 2024 (UTC)

I'm sorry about choosing the wrong section. It's not like I am an expert at the nuts and bolts of MediaWiki and I had to rebuild the database since it appeared to be a database issue that caused the CS1 module to crash, thankfully I backed up everything but it's still annoying and frightening when an unforeseen error like that suddenly occurs. --Minoa (talk) 20:14, 3 February 2024 (UTC)

What does "vice" include?

Regarding: Template:Citation Style documentation/url

Firstly, this is not an issue for me, I just happened to be reading this section and wondered about this. But hopefully a clarification could be helpful for others in the future.

Under url-status, it says the values unfit or usurped are used when the URL/domain links to "vice", but it's not clear what that means. Is there a help page that could be linked there to clarify?

For me, when I hear "vice", I think, say, gambling, drugs, and pornography, but I'm not sure that's what it's referring to. (Funny enough, the reason I was reading this section was regarding a link to a liquor company, which could be considered "vice" under some definitions.)

An obvious case is a URL that used to point to a news article but now points to pornography; obviously we shouldn't keep that link to avoid any unpleasant surprises for people clicking the "original link", but I can imagine more complicated cases.

By the way, in the same section, I believe "reseller" refers to domain resellers specifically. That should maybe be clarified too.

— W.andrea (talk) 20:41, 3 February 2024 (UTC)

@W.andrea: I think that in this context "vice" does include gambling and pornography, as those are two common types of content we are redirected to when a web domain is no longer live. GoingBatty (talk) 21:55, 3 February 2024 (UTC)

I've boldly modified unfit and usurped in the doc; feel free to revert or edit. Actual change to guideline rather than just wording; the distinction between unfit and usurped wasn't clear (and they actually do exactly the same). Quicker to do it and if necessary revert than long discussion. Best wishes, Pol098 (talk) 23:55, 3 February 2024 (UTC)

Is vice not clear? It's just a 1 word label instead of having to write out "pornography, gambling, etc.." every time in the document. If the word vice is curious ("what does vice mean?"), then we can make a footnote listing some examples.

Secondly, the change made by Pol098 is not what we have agreed on. There is a difference between an entire domain being usurped. And individual URLs within a domain being inappropriate, but otherwise not usurped. For example, a news aggregator site might have lots of safe URLs. But one of its stories contains blatant pornography or gambling spam. So we individually suppress URLs from legitimate domains using |unfit=. Or we can suppress an entire domain that has been usurped. In effect both of these do the same thing, but they are operating at different levels and mean something different. In brief: usurpation occurs at the domain level. Unfit at the page level. -- GreenC 01:36, 4 February 2024 (UTC)

Is vice not clear? Vice is a culturally informed topic with differing interpretations; one prominent example is the Committee for the Promotion of Virtue and the Prevention of Vice. Another example is that my grandfather considers it a vice to go shopping on Sunday, but I do not. Please consider another word if brevity is the concern here. Orange Suede Sofa (talk) 03:16, 5 February 2024 (UTC)

Because this is yet another discussion about this topic, I'm beginning to wonder if we wouldn't be better off defining unfit and usurped as equal aliases. Editors can then choose the one that seems best to them. That might remove the apparent need to quibble over the individual meanings of the keywords. If we do that then, the definition might be rewritten like this:

• unfit or usurped – selects |archive-url=; used when |url= links to vice (gambling, pornography), advertising, a domain reseller or other unsuitable page; links to |url= are suppressed in the rendering. If an entire domain is unsuitable, consider instead usurpation or blacklist.

—Trappist the monk (talk) 01:56, 4 February 2024 (UTC)

The question still exists, when is it appropriate to use the word "unfit" vs "usurped". We can provide guidance as noted, the difference is between an entire domain being a problem, versus a page being a problem within an otherwise fine domain. -- GreenC 02:35, 4 February 2024 (UTC)

"the difference is between an entire domain being a problem, versus a page being a problem" - great, that makes sense, but the documentation needs to make that clear. Very much a storm in a teacup, the distinction has no effect on the reader, and the editor can see where the page now links. My edit doesn't make this point, but it doesn't make the guideline worse so I won't withdraw it, and hope it will be improved upon. Even the name is vague, unfit-page, usurped-domain is better. Best wishes, Pol098 (talk) 12:04, 4 February 2024 (UTC)

I thought the documentation does make that clear? One says page, the other says domain. -- GreenC 17:41, 4 February 2024 (UTC)

Agree with merging them and making one an alias of the other. They don't do anything distinct, and it's silly to argue about a distinction that doesn't matter for any practical purpose. Something that does matter would be to shop generating a warning message when these parameters are used. What good is it if it's interpreted as if an error? If I used that parameter, I did so on purpose, and I don't need a pseudo-warning to try to convince me something is broken every time I edit the page. Just inspires someone else later to think it is broke and mess with it.  — SMcCandlish ☏ ¢ 😼  03:03, 5 February 2024 (UTC)

Category:CS1 maint: location

|location=Honolulu, Hawai{{okina}}i adds the article to Category:CS1 maint: location and |location=Honolulu, Hawaiʻi does not. There is ~6,000 articles in the category.

I have obviously figured out a workaround. Personally, I think both forms should work. Also, this is probably one example of problems using character templates in location parameter values.

Is there a consensus solution for resolving this situation? Thanks in advance. User-duck (talk) 10:22, 4 February 2024 (UTC)

Fix {{okina}}? The category addition occurs because {{okina}} uses the html numeric entity ʻ. What cs1|2 sees is Honolulu, Hawaiʻi.

The related templates, {{'eta}} and {{fakau'a}} use the unicode characters U+02BC ʼ MODIFIER LETTER APOSTROPHE and U+02BB ʻ MODIFIER LETTER TURNED COMMA. This is the 21st century, I see no reason why {{okina}} can't use U+02BB ʻ MODIFIER LETTER TURNED COMMA instead of ʻ.

—Trappist the monk (talk) 13:15, 4 February 2024 (UTC)

Fixed [13]. We'll see if it sticks.  — SMcCandlish ☏ ¢ 😼  03:00, 5 February 2024 (UTC)