Help talk:Citation Style 1

module suite update 17–18 January 2026

I propose to update the cs1|2 module suite over the weekend 17–18 January 2026. Here are the changes:

Module:Citation/CS1:

• i18n fixes; discussion
• revised preview warning system; discussion
• catch malformed {{citation}} book cites; discussion

Module:Citation/CS1/Configuration:

• Added free DOI prefix recognition for:

  AACE Endocrinology and Diabetes

  AI Open

  Acta Crystallographica E

  Acta Pharmaceutica Sinica B

  Addiction Neuroscience

  Addictive Behaviors Reports

  Animal

  Genomics, Proteomics & Bioinformatics

  IEEE Open Access...

  IEEE Open Journal...

  IUCrData

  IUCrJ

  Journal of Synchrotron Radiation

  PNAS Nexus

  Radiopedia

  VideoGIE

• i18n fixes
• added 'as' and 'kaa' to script_lang_codes
• revised preview warning system
• catch malformed {{citation}} book cites

Module:Citation/CS1/Identifiers:

• increased 5-digit doi registrant discussion
• added new biorxiv and medrxiv 'doi' prefix; discussion

Module:Citation/CS1/Utilities:

• tweaked hyphen_to_dash(); discussion

Module:Citation/CS1/styles.css:

• shift fallback red of error per upstream

—Trappist the monk (talk) 20:42, 10 January 2026 (UTC) 16:01, 11 January 2026 (UTC) (add catch malformed {{citation}} book cites to lists)

Sounds good. I posted a notice on the Village Pump at: Wikipedia:Village pump (technical) § Discussion at Help talk:Citation Style 1 § module suite update 17–18 January 2026. Rjjⁱⁱⁱ (talk) 21:21, 10 January 2026 (UTC)

And also:

Module:Citation/CS1/sandbox

• accept-as-written markup doesn't suppress err_extra_text_volume; discussion
• avoid script error when bad timestamp is in |archive-url=; discussion

Module:Citation/CS1/Date validation

• avoid script error when bad timestamp is in |archive-url=
• fix bug about initializing variable

Citation comparison

Wikitext	{{citation|archive-date=c. 2000|archive-url=https://example.net|date=2000|title=title|url=https://example.com}}
Live	title, 2000, archived from the original on c. 2000 {{citation}}: Check date values in: |archive-date= (help)
Sandbox	title, 2000, archived from the original on c. 2000 {{citation}}: Check date values in: |archive-date= (help)

--FlatLanguage (talk) 09:16, 11 January 2026 (UTC)

jstor expansion?

I know the old cite jstor template had a bot that would generate a different (probably cite journal) template to replace it with all of the expanded info (journal, date, etc.). cite jstor is now depreciated in favor of cite journal. Is there still a bot that would extend a cite journal with just the jstor field filled in?Naraht (talk) 16:15, 14 January 2026 (UTC)

I usually just use the url to auto generate the cite, and then modify the source to replace |url= with |jstor= (the jstor number is the last part of the url). -- LCU ActivelyDisinterested «@» °∆t° 16:55, 14 January 2026 (UTC)

I would appreciate more guidance here. For example, let's say I'd like to cite the following jstor. https://www.jstor.org/stable/382433 (Its in Phi Delta Phi's magazine, being used as a reference for the defunct organization Beta Pi Theta.)Naraht (talk) 17:38, 14 January 2026 (UTC)

User:Citation bot will do that for you. See this diff for an example. I have the Citation bot script loaded in my .js file, and I click on a link called "Expand citations" in my right-side sidebar, under "General" (in Vector 2022, the default skin). You can also feed a page to the bot via its web interface so that you don't have to figure out how to load a script. If that sounds like a lot of mumbo-jumbo, I can slow down and explain it again. (And no, I haven't forgotten about your Bairds templates.) – Jonesey95 (talk) 18:06, 14 January 2026 (UTC)

If you're using the source editor there's a video in WP:REFB#RefToolbar that shows how easy it is to automatically create a formated cite. Anything in the cite template with a magnifying glass next to it can be used to autofill the fields. If you're using the visual editor you suggest need to press the cite button in the top bar and input the url (I think, I don't use it so can't be certain). -- LCU ActivelyDisinterested «@» °∆t° 20:04, 14 January 2026 (UTC)

OK, changed my preferences to include the editing bar (the 2010 wikitext editor). I'll see if that helps. (the 2017 changes are just too bizarre for me). I'm not sure what to add to my .js file for citation bot.Naraht (talk) 17:38, 15 January 2026 (UTC)

Automatic title linking when open access link is provided

It would be nice if the CS1 templates consistently link the title across all of the parameters specified in § Access indicator for named identifiers. Compare (from Neapolitan ragù, with |jstor-access=free)

Branco, Patrícia; Mohr, Richard (2023). "Odore di Napoli: Normativity from Objects and Smells". In Philippopoulos-Mihalopoulos, Andreas; Mandic, Danilo; Nirta, Caterina; Pavoni, Andrea (eds.). SMELL. Law and the Senses. London: University of Westminster Press. ISBN 978-1-915445-13-1. JSTOR jj.9474307.4.

{{Cite book |last=Branco |first=Patrícia |title=SMELL |last2=Mohr |first2=Richard |publisher=[[University of Westminster Press]] |year=2023 |isbn=978-1-915445-13-1 |editor-last=Philippopoulos-Mihalopoulos |editor-first=Andreas |series=Law and the Senses |location=London |chapter=''Odore di Napoli'': Normativity from Objects and Smells |jstor=jj.9474307.4 |editor-last2=Mandic |editor-first2=Danilo |editor-last3=Nirta |editor-first3=Caterina |editor-last4=Pavoni |editor-first4=Andrea |jstor-access=free}}

with (from Princess Mononoke, with |doi-access=free)

Napier, Susan J. (2011-01-25). "The garden and the sky: gender and space in the films of Miyazaki Hayao". Proceedings of the Association for Japanese Literary Studies. 11. doi:10.26812/pajls.v11i.1305. ISSN 1531-5533.

{{cite journal |last=Napier |first=Susan J. |author-link=Susan J. Napier |title=The garden and the sky: gender and space in the films of Miyazaki Hayao |journal=[[Proceedings of the Association for Japanese Literary Studies]] |volume=11 |date=2011-01-25 |issn=1531-5533 |doi=10.26812/pajls.v11i.1305 |doi-access=free}}.

—TechnoSquirrel69 (sigh) 05:08, 16 January 2026 (UTC)

I've requesting that feature for years. Built a hierarchy of free identifiers of records to automatically link. Currently we have PMC > DOI (when doi-access=free is set). This should be expanded to PMC > DOI* > Bibcode* > HDL* > JSTOR* > RFC* > OL* > OSTI* > S2CID* (I went alphabetical for simplicity's sake). And have an override e.g. |auto-url=JSTOR for when the JSTOR link is preferred over others.

Likewise, the preprint cites should also autolink, e.g.

• {{cite arxiv}}
• {{cite biorxiv}}
• {{cite medrxiv}}
• And {{cite SSRN}} when |ssrn-access=free is set.

Headbomb {t · c · p · b} 12:44, 17 January 2026 (UTC)

Bad title: Bot Verification

E.g. "Bot Verification". wbacs.in. Retrieved 2026-01-18. {{cite web}}: Cite uses generic title (help) Headbomb {t · c · p · b} 19:49, 18 January 2026 (UTC)

Local 'suffix' nil

I noticed a couple of "attempt to index local 'suffix' (a nil value)" problems. I fixed one but when I saw the same strange wikitext in the second I thought I should report it here for someone with a clue to investigate. At Terminal lucidity a citation included doi=((10.17514/JNDS-2009-28-2-p87-106.)). Removing the double parens fixed the error. However, ref 132 at Out-of-body experience#Awareness during Resuscitation Study (just after text "no visual targets had been placed") has the same issue. Also, ref 15 at the end of the lead at Economy of Cameroon. Johnuniq (talk) 08:45, 19 January 2026 (UTC)

Fixed I think, Thank you.

—Trappist the monk (talk) 15:43, 19 January 2026 (UTC)

Series translated

Greetings, all. There are cited, non-English books that are part of a series. Shouldn't there be a "trans-series" parameter in the template? -The Gnome (talk) 17:40, 19 January 2026 (UTC)

Redundant ustring.gsub calls for digits

I'm a volunteer sysadmin and performance engineer, and I noticed something interesting while profiling the parse of Barack Obama on enwiki: out of nearly 90k Lua calls to gsub generated during the parse, about 17% are redundant replacements where Western digits are being swapped for themselves (e.g. replacing '1' with '1', '2' with '2', etc.). They originate in Module:Citation/CS1.

I'm not 100% sure, but I think the culprit is around line 4653 (as of revision 1333436042), where mw.ustring.gsub is used to translate local digits for enumerated parameters:

k = mw.ustring.gsub (k, '%d', cfg.date_names.local_digits);	-- for enumerated parameters, translate 'local' digits to Western 0-9

If I'm right about the source, adding a guard clause to skip this when cfg.date_names.local_digits is already using Western digits could be a meaningful performance improvement. Lua gsub calls are >0.50% of all index.php wall-clock time, and presumably substantially more on fresh parses.

The fix might be to change the if-guard in the line above to: if cfg.date_digit_auto_xlate_enable and 'string' == type(k) then

I'm also not entirely sure how changes to this module propagate across different wikis, so if this is the right fix, do you have any suggestions on the best way to ensure it reaches other projects?

Thanks! ATDT (talk) 03:31, 20 January 2026 (UTC)

Lua in the Scribunto extension only understands digits in the set [0-9]. For that reason, parameter enumerators written using digits not in that set must be translated. I agree that the current method is not best for performance but it is (relatively) simple and has worked without complaint for a long time.

If we are to limit the number of translations to those cases that actually need translation, we must somehow determine that the parameter is enumerated with digits from the [0-9] set. date_digit_auto_xlate_enable is used to translate [0-9] digits used in dates to the local language's digits (for example, Bengali: [0-9] → [০১২৩৪৫৬৭৮৯]) so that is not an appropriate setting to test.

We might write:

if 'string' == type(k) and k:find ('%d$') then

or perhaps:

if 'string' == type(k) and k:find ('%d', -1) then

mayhaps both are equivalent; mayhaps there are better ways to do this, I don't know.

So here's a task for you: create a sandbox in Module:Sandbox/ATDT with a sufficiently large data set and figure out the best way accomplish the required translations without translating [0-9] to [0-9].

—Trappist the monk (talk) 14:16, 20 January 2026 (UTC)

Thanks, Trappist. You're right that date_digit_auto_xlate_enable is the wrong flag to use here, I was conflating input parsing and output formatting.

I want to explain why k:find('%d') doesn't solve the redundancy issue on enwiki. If we have a parameter like k = "Volume 1", k:find('%d') returns true. The code then enters the block and runs gsub. Because enwiki's config maps ['1'] = '1', gsub performs a replacement of '1' with '1'. Even if the text remains exactly the same, gsub still has to build a new string object to return it. It's doing all the work of a replacement just to give us back the exact same text.

I propose the following:

Add this to Module:Citation/CS1/Configuration:

-- Helper: Checks if a table maps every key to itself (or is empty).
local function is_identity_map(t)
  for k, v in pairs(t) do
    if k ~= v then
      return false
    end
  end
  return true
end

Then in the < E X P O R T S > section, add a property:

return 	{
  ...
  skip_digit_translate = is_identity_map(date_names.local_digits),
  ...
}

Then the relevant code in Module:CS1 becomes:

if not cfg.skip_digit_translate and 'string' == type (k) then
    k = mw.ustring.gsub (k, '%d', cfg.date_names.local_digits);		-- for enumerated parameters, translate 'local' digits to Western 0-9
end

I put up some test code in Module:Sandbox/ATDT. Let me know if this works for you. ~~~~ ATDT (talk) 03:59, 21 January 2026 (UTC)

Yeah, as written above, my code won't work; this is what I meant to write:

if 'string' == type(k) and not k:find ('%d$') then

But in retrospect, that isn't much of an improvement. At en.wiki there are 80+ parameter names that can be enumerated and about 180 other parameter names that cannot be enumerated. So, k:find ('%d$') will return nil for those other 180 parameters which will force a call to mw.ustring.gsub() to look for non-ascii enumerators that aren't there.

We might adopt a variant of your suggested code. We already have a pairs() iterator that makes a reversed version of date_names.local_digits (Module:Citation/CS1/Configuration line 732):

for ld, ed in pairs (date_names.local_digits) do
	date_names.xlate_digits [ed] = ld;
end

so we might modify it:

local enum_needs_xlation = false;				-- assume that we do not need to translate parameter enumerators
for ld, ed in pairs (date_names.local_digits) do
	date_names.xlate_digits [ed] = ld;
	if ed ~= ld then
		enum_needs_xlation = true;				-- true when local digits are not western digits; must translate enumerators
	end
end

Or, do we really need to repeatedly do the test in the iteration? Can't we just presume that when date_names.xlate_digits['1'] is '1' (or some other index equals itself...) we don't need to translate parameter enumerators? so then this just export this from Module:Citation/CS1/Configuration:

enum_needs_xlation = '1' ~= date_names.xlate_digits['1'];			-- true when local digits are not western digits; must translate enumerators

and in the main module this:

if cfg.enum_needs_xlation and 'string' == type (k) then				-- for wikis that set date_names['local_digits'] to non-western digits
    k = mw.ustring.gsub (k, '%d', cfg.date_names.local_digits);		-- for enumerated parameters, translate 'local' digits to Western 0-9
end

Is it not true that none of this benefits wikis that do not use western digits? You wrote: Lua gsub calls are >0.50% of all index.php wall-clock time. Do we really care about a half percent?

—Trappist the monk (talk) 01:35, 22 January 2026 (UTC)

I am a former lead of the Wikimedia Foundation's Performance Team. We really do care about half a percent. Keeping Wikipedia fast is a constant battle for fractional improvements. They add up.

The half percent figure is also misleading by itself: it is drawn from statistical (sample-based) profiles of page requests served by MediaWiki. Most logged-out traffic is served from edge caches that serve static HTML and don't involve MediaWiki at all. Of the fraction of page requests that are served by MediaWiki, many are served from the parser cache and don't involve Lua at all. Other page requests are for articles that contain few or no citations or complex templates. Those too will not be sped up by this change. The impact will be disproportionately concentrated in page requests for citation-heavy articles that miss in the cache. This includes, for example, every single edit to such articles. (Edits invalidate the parser cache and require a new parse.) As a fraction of total traffic to the sites, these requests are small contributors: most people never log in or edit pages. But they are critical to the experience of active Wikipedians, and it is a sad irony that these requests are the ones that are hit with the worst performance problems.

A fresh parse of the Barack Obama article on enwiki takes ~7 seconds currently, of which over 4 seconds are spent executing Lua. I can't predict exactly what speed-up we would see from this change, but I would guesstimate something in the order of hundreds of milliseconds, which is a very meaningful figure. I've spent many days chasing smaller gains than that.

The change you propose looks reasonable to me. I am not an expert on languages. As far as I know, no language uses a mix of Western and non-Western digits, but I took a conservative approach. enum_needs_xlation = '1' ~= date_names.xlate_digits['1']; is probably sufficient. Thanks. ATDT (talk) 06:12, 22 January 2026 (UTC)

Implemented in the sandbox.

—Trappist the monk (talk) 15:25, 22 January 2026 (UTC)

Thank you so much. I take it this is a qualification step prior to porting it to the main modules. One thing to consider is that if and when this change is propagated to other wikis, the change to the configuration module would need to be imported first before the change to the main module. Otherwise there is a race condition: cfg.enum_needs_xlation would evaluate to nil, which is falsey, so the check if cfg.enum_needs_xlation and 'string' == type (k) would be false and digits will not be translated until the configuration module is updated. An easy way to prevent this is to explicitly check for a false value: if cfg.enum_needs_xlation == false and 'string' == type (k). This way the change to the two modules can be safely imported in any order.

One other thought occurred to me. Both date_names.xlate_digits and date_names.local_digits define a mapping between two sets of digits. For code readability, might it make sense to name them something like local_digits_to_western and western_digits_to_local? However, I can also appreciate that you might prefer to avoid cosmetic changes since this code is so critical. It's your decision.

Thanks again for your efforts here :) Looking forward to seeing it roll out. ATDT (talk) 19:40, 22 January 2026 (UTC)

The cs1|2 modules at en.wiki are updated from their sandboxen at roughly quarterly intervals. When I do the updates, I open a new browser window and then update each module that needs updating in its own tab and then publish the submodules one after the other as quicky as I can with Module:Citation/CS1 as the last to be published. Usually only a handful of articles get refreshed while the module suite is out of sync. I have an AWB script that can rapidly null edit those pages so the disruption is minimized.

We have no control over what other wikis do. What they should do is import the whole suite of modules into sandboxen at their wiki, modify (usually ~/Configuration) as needed, test, and then sync their live module from their modified sandboxen. They don't always do that...

I'll look into changing those table names. Thanks for that.

—Trappist the monk (talk) 20:02, 22 January 2026 (UTC)

Error with origin_date for archive.today

I think there's an unhandled case in local function archive_url_check (url, date). According to line 2486 of Module:Citation/CS1, -- <origin_date> is 1996 for archive.org; 2012 for archive.today. However, archive.today can copy archive.org snapshots with the original timestamp.

I came across this while looking at a citation with an error claiming archive-url= is malformed: timestamp. The timestamp is correctly 14 digits.

References

In this example, the archive.today listing says it was

archived via http://web.archive.org/20070812121105/www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html

Either the starting year for both archives should be the same, or else the guidance at Category:CS1_errors:_archive-url should explain why pre-2012 archive.today links are discouraged. Blepbob (talk) 03:59, 20 January 2026 (UTC)

The error only occurs if you use the archive of an archive, the simple solution would be not to do that as it serves no purpose. The setup is expecting the date that the archiving happened, which in the case of archive.today was 'Decemeber 4, 2013' not 'August 12, 2007'. That latter date was the date archive.org archived the page, if you want to use that date use the archive.org link.
Using the archive.today link is completely redundant. -- LCU ActivelyDisinterested «@» °∆t° 14:19, 20 January 2026 (UTC)

Doing a few spots checks of the roughly 7000 articles with this error[1] they're all appear to be redundantly using archives of archives. I wonder if this is something that could be mass corrected. -- LCU ActivelyDisinterested «@» °∆t° 15:03, 20 January 2026 (UTC)

IMO mass correction isn't as simple as making the start year the same across archives.

• It's not clear to me what the benefit is in replacing pre-2012 archive.today citations. Redundant hosting does serve a purpose. Archives are subject to separate legal requirements based on activity, e.g. country-level blocks or takedown requests. Archives aren't immune to downtime or link rot.
• The error message and help guidance should still be updated because the timestamp is not malformed (i.e. it is 14 characters). This is confusing.
• The archive.today check doesn't handle the alternate domains, so https://archive.is/20070812121105/http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html doesn't get flagged.
• I imagine the typical chain of events is that a human editor adds a (shortened) archive.ph URL, which a bot replaces with a timestamped archive.today URL, and produces this parameter error without any human oversight. Blepbob (talk) 02:35, 21 January 2026 (UTC)

I have tweaked the error message help text some.

I have also tweaked the module sandboxen to recognize the alternate archive.today top level domains .ph, .is, .md, .li, .fo, .vn (most-commonly to least-commonly used order – as of a couple of days ago). Additional tweaks change the pre-origin date limit error message to a maintenance message (archive.today family only):

{{Cite web/new |title=Rock Salt Plum Welcomes Artist Mikey Welsh |url=http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html |website=Rock Salt Plum Review |archive-date=August 12, 2007 |archive-url=https://archive.today/20070812121105/http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html}}

"Rock Salt Plum Welcomes Artist Mikey Welsh". Rock Salt Plum Review. Archived from the original on August 12, 2007.{{cite web}}: CS1 maint: archive origin (link)

But, when the year portion of the timestamp is earlier than 1996 (the archive.org origin) the module returns an error message:

{{Cite web/new |title=Rock Salt Plum Welcomes Artist Mikey Welsh |url=http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html |website=Rock Salt Plum Review |archive-date=August 12, 2007 |archive-url=https://archive.today/19950812121105/http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html}}

"Rock Salt Plum Welcomes Artist Mikey Welsh". Rock Salt Plum Review. {{cite web}}: |archive-url= is malformed: timestamp (help)

I have expanded the archive.today family testing to check |archive-date= against the |archive-url= timestamp:

{{Cite web/new |title=Rock Salt Plum Welcomes Artist Mikey Welsh |url=http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html |website=Rock Salt Plum Review |archive-date=August 21, 2007 |archive-url=https://archive.today/20070812121105/http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html}}

"Rock Salt Plum Welcomes Artist Mikey Welsh". Rock Salt Plum Review. Archived from the original on August 21, 2007. {{cite web}}: |archive-date= / |archive-url= timestamp mismatch; August 12, 2007 suggested (help)CS1 maint: archive origin (link)

It is my understanding that use of url-shortening is discouraged so I have added a test to identify those archive.today family urls that use the five-character shortening. When detected, the module adds a maintenance category:

{{cite news/new |author=Motamayor, Rafael |title=The Major Avatar Role That Josh Brolin Is Glad He Turned Down |url=https://www.slashfilm.com/1938932/josh-brolin-turned-down-avatar-stephen-lang-quaritch-role/ |website=slashfilm.com |date=August 25, 2025 |url-status=live |archive-url=https://archive.ph/HhnMr |archive-date=December 30, 2025}}

Motamayor, Rafael (August 25, 2025). "The Major Avatar Role That Josh Brolin Is Glad He Turned Down". slashfilm.com. Archived from the original on December 30, 2025.{{cite news}}: CS1 maint: shortened archive url (link)

—Trappist the monk (talk) 16:22, 25 January 2026 (UTC)

"the simple solution would be not to do that as it serves no purpose"

I won't say that's completely true; I find in a few cases, archive.today is still able to preserve the archived web page as "frozen" without all the dynamic json stuff which otherwise would take longer for an archive.org webpage to load. And also in some cases, the website was long gone, and to "preserve" it and load it better, the archived link would go through archive.today.

I did so for some archived websites such as this case (from Web Archive Singapore), because also the archived website did some encoding or smth that made accessing the archived site a bit more difficult to access.--ZKang123 (talk · contribs) 01:50, 27 January 2026 (UTC)

Archive error error

Moved from Help talk:CS1 errors § Archive error error

The template is claiming that https://archive.today/20081012124828/http://www.thefa.com/TheFACup/TheFACommunityShield/NewsAndFeatures/Postings/2003/08/60753.htm is an archive url error, the help page does not describe the format for archive.today urls, but this url certainly works. There are three such error messages in 2003 FA Community Shield. All the best: Rich Farmbrough 20:28, 18 January 2026 (UTC).

@Rich Farmbrough: This is the same issue at Help talk:Citation Style 1#Error with origin_date for archive.today. It's because archive.today was founded in 2013 so cannot have archived a page in 2008. They must have copied it from archive.org: https://web.archive.org/web/20081012124828/http://www.thefa.com/TheFACup/TheFACommunityShield/NewsAndFeatures/Postings/2003/08/60753.htm. No doubt someone could write a bot to go through changing all instances of *archive.today/200* to *web.archive.org/web/200* point at the original archive rather than a copy. DrKay (talk) 22:47, 21 January 2026 (UTC) Amended. 13:50, 23 January 2026 (UTC)

But the archive link to archive.today redirects to archive.md – and when that URL is substituted in the template, all is fine. So why should a working URL cause an error message, and worse, suppress the archive link? -- Michael Bednarek (talk) 13:05, 23 January 2026 (UTC)

If you're asking about the technical point, because, as explained at Help talk:Citation Style 1#Error with origin_date for archive.today, "According to line 2486 of Module:Citation/CS1, -- <origin_date> is 1996 for archive.org; 2012 for archive.today". There's no error tracking for archive.md. This is all in lines 2486 ff. of the module. If you're asking about the policy or wisdom of setting up such error tracking, then I make no comment and have made no comment. DrKay (talk) 13:40, 23 January 2026 (UTC)

As archive.today is forwarded (redirected) to archive.md, a datecheck for the former seems unnecessary when a replacement in the citations with the latter is accepted. -- Michael Bednarek (talk) 15:44, 23 January 2026 (UTC)

PS: Surely, >11,000 entries in Category:CS1 errors: archive-url indicate a diagnostic problem. -- Michael Bednarek (talk) 13:12, 23 January 2026 (UTC)

Another issue is that where the original is from webcitation.org there is no date-checking we can do in those webcitation urls. I see no reason we should not support proleptic archive.today dates. An inappropriate range check is still a range check but it also still inappropriate. All the best: Rich Farmbrough 14:04, 23 January 2026 (UTC).

@Trappist the monk: can we fix this by setting an earlier or no origin date for archive.today please. All the best: Rich Farmbrough 14:10, 23 January 2026 (UTC).

Agreed, e.g. there is nothing wrong with "1, Aney Marg: Rabri gets second eviction notice". 17 December 2005. Retrieved 2009-05-26. {{cite web}}: |archive-url= is malformed: timestamp (help)CS1 maint: url-status (link) based on a prior webcitation.org snapshot. Headbomb {t · c · p · b} 18:44, 24 January 2026 (UTC)

So an archive link with a correctly formatted date and a URL that works gets suppressed because the system believes that archive, archive.today, cannot possibly hold that page – but it does. If a normal user would remove en masse working links to archived pages from our articles, they would correctly be accused of disruptive editing and vandalism and would quickly be censured. But here we have a system wickedly behaving with impunity. I don't know whether the obvious solution, a bot replacing archive.to with archive.md, is feasible, but these unfounded and erroneous action must stop immediately. -- Michael Bednarek (talk) 23:51, 24 January 2026 (UTC)

|archive-url= is malformed: timestamp

I dont see anything wrong in archive url of the following citation:

{{cite web |url=http://www.uefa.com/uefaeuropaleague/clubs/club=52806/profile/index.html |title=Rosenborg BK |publisher=[[UEFA|Union of European Football Associations]] |access-date=20 April 2011 |archive-date=21 April 2011 |archive-url=https://archive.today/20110421131034/http://www.uefa.com/uefaeuropaleague/clubs/club=52806/profile/index.html |url-status=dead }}

Which is creating:
"Rosenborg BK". Union of European Football Associations. Retrieved 20 April 2011. {{cite web}}: |archive-url= is malformed: timestamp (help)CS1 maint: url-status (link)
––KEmel49(📝,📋) 12:45, 25 January 2026 (UTC)

This seems to be an instance covered by a previous comment, #Archive error error. archive.today didn't exist as such in 2011 (see previous comprehensive discussion for details). Pol098 (talk) 12:58, 25 January 2026 (UTC)

• Yes undo this change - it has no consensus and is spamming the site with over 16,000 error messages and going up daily. There is no requirement to use the Wayback Machine. They often removes archives - Archive.today is the only option available. It's usually why we use archive.today they still have what Wayback removed. It's an unfixable red-error messages in many cases. -- GreenC 06:34, 31 January 2026 (UTC)
• I have this problem too, in Pop screamo fn 9. The archive link is valid and the error report is completely erroneous. The accept-this-as-written markup is not working for |archive-url=. This should be fixed. Hawkeye7 (discuss) 20:58, 3 February 2026 (UTC)

Inconsistent bugs in CS1

Three examples:

1995

{{Cite web/new |title=Rock Salt Plum Welcomes Artist Mikey Welsh |url=http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html |website=Rock Salt Plum Review |archive-date=August 12, 2007 |archive-url=https://archive.today/19950812121105/http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html}}

"Rock Salt Plum Welcomes Artist Mikey Welsh". Rock Salt Plum Review. {{cite web}}: |archive-url= is malformed: timestamp (help)

2006

{{Cite web/new |title=Rock Salt Plum Welcomes Artist Mikey Welsh |url=http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html |website=Rock Salt Plum Review |archive-date=August 12, 2010 |archive-url=https://archive.today/20060812121105/http://www.rocksaltplum.com/RSPSpring2007/ARTMikeyWelsh.html}}

"Rock Salt Plum Welcomes Artist Mikey Welsh". Rock Salt Plum Review. Archived from the original on August 12, 2006.{{cite web}}: CS1 maint: archive origin (link)

2007

{{cite magazine |url=http://www.rollingstone.com/artists/thegobetweens/albums/album/90247/review/5943988/16_lovers_lane |title=The Go-Betweens: 16 Lovers Lane |magazine=[[Rolling Stone]] |location=New York |date=9 February 1989 |access-date=14 December 2021 |last=Azerrad |first=Michael |author-link=Michael Azerrad |archive-url=https://archive.today/20070518205122/http://www.rollingstone.com/artists/thegobetweens/albums/album/90247/review/5943988/16_lovers_lane |archive-date=18 May 2007 |url-status=dead}}

Azerrad, Michael (9 February 1989). "The Go-Betweens: 16 Lovers Lane". Rolling Stone. New York. Retrieved 14 December 2021. {{cite magazine}}: |archive-url= is malformed: timestamp (help)CS1 maint: url-status (link)

• 1995 - Right. Because it predates web archiving.
• 2006 - Right. Because it's normal for Archive.today to have old captures saved from elsewhere. These captures often no longer exist where they originally came from.
• 2007 - Makes no sense. Why is 2006 clear, but 2007 is error? How are users supposed to fix the error message or clear the tracking category? -- GreenC 22:33, 3 February 2026 (UTC)

You used live version. In sandbox:

{{cite magazine/new |url=http://www.rollingstone.com/artists/thegobetweens/albums/album/90247/review/5943988/16_lovers_lane |title=The Go-Betweens: 16 Lovers Lane |magazine=[[Rolling Stone]] |location=New York |date=9 February 1989 |access-date=14 December 2021 |last=Azerrad |first=Michael |author-link=Michael Azerrad |archive-url=https://archive.today/20070518205122/http://www.rollingstone.com/artists/thegobetweens/albums/album/90247/review/5943988/16_lovers_lane |archive-date=18 May 2007 |url-status=dead}}

Azerrad, Michael (9 February 1989). "The Go-Betweens: 16 Lovers Lane". Rolling Stone. New York. Archived from the original on 18 May 2007. Retrieved 14 December 2021.{{cite magazine}}: CS1 maint: archive origin (link)

--FlatLanguage (talk) 13:51, 4 February 2026 (UTC)

archive-url links

I just found a discussion I had with Snowman304 in September 2024, I wanted to post here, because my concerns weren't solved or put at ease by him. His responses (and a resulting concern) are hidden behind <!->.

https://en.wikipedia.org/wiki/User_talk:Snowman304#c-MenkinAlRire-20240917160000-Snowman304-20240917141900

Hi. Your bot archived links on Helen Levitt. I don't see the advantage of the redundancy, when the web pages are fresh or obviously made to stay, like the MoMA pages. The reference just looks awful and unnecessarily technical. There is a link that works fine, the redundant archive-url is just irritating and disturbing. I certainly see the purpose, but the bot produces -beside the already described redundancies- also the illusion of good maintenance. I found several links (in this lemma) the bot added an archive-url to that were already dead or just a search box (instead of a find).

Would you be at least able to make the archive-urls invisible as long as the original urls are live? This would be a good compromise, I think. (The wording "rescued" is pretentious anyway, if the link was visited the day before) MenkinAlRire 13:56, 17 September 2024 (UTC)

My point was, if there wasn't a way to design it more discreet. It makes no sense to show an archive-url as long as the original link works. As a reader I really don't want to see a technicality, it's unnerving to read and try to understand why there has to be two or even three or four links for one reference, especially when they are unchecked.

It seems to me, that technical principles, the bureaucratic aspect rules over the actual experience to read and work with WP. The design is everything else but elegant. This is certainly true for all the formulas urls are archived with, they usually result in redundancies that make no sense and hurt the eye (and the brain). It's not a bug, but it looks like one, and in the cases I meant it isn't a feature either. I would expect the NYT and the MoMA as well would announce such a move beforehand. But I expect too, that it's (more) complicated, and the vast WP has to use all bots it can get. MenkinAlRire 16:00, 17 September 2024 (UTC)

Well, here are some good examples of not-much-sense. On Helen Levitt again the short form s2cid=192186702 was added. When you follow the link, there is nothing really concerning Levitt but another link which leads to the article (https://www.journals.uchicago.edu/doi/10.1086/649790 I don't know if there is a template for it) Why not link the article directly?

In another ref there are both doi and jstor given, but their links are identical, so it makes no sense. Anothertime there is a doi, just to be followed by "doi-broken". Really, noone wants to read that stuff, it belongs in the kitchen, not on the diner table.

MenkinAlRire 16:02, 21 January 2026 (UTC)

The web itself is a mess. There is no way to know if a "live" link is actually live or a soft-404 (extremely common). We make the archive URL available for readers who are having trouble accessing the supposed live link for whatever reason (soft-404, geo-block, temp outage etc). Giving readers both options is better than hiding the archive URL in the source code where they have to hunt for it. It might seem "technical" but that is how the web is. -- GreenC

This is a mess. We shouldn't have to edit source code to see what you're talking about. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:47, 22 January 2026 (UTC)

I agree with Andy that this way of quoting information is nonsensical. I thought you were replying to yourself before I looked more closely. I for one think preemptively adding an archive link (alongside url status live) is a good practice; links die (or get usurped or deviate so that they no longer support an assertion) all the time without anyone immediately realizing. An archive provided with the initial referencing even when the link is live provides a data point that this url definitely did used to say what it was cited as saying even if it no longer does, something that makes verification easier when a link dies (or especially when it's still the same website but now has less information present than it used to--without an archive someone may be more likely to assume that the page never supported the citation and remove the link). Having it always visible also makes sure anyone can see that the archive link exists even if the citation hasn't been directly marked dead yet. - Purplewowies (talk) 20:49, 25 January 2026 (UTC)

Another field order request

Greetings and felicitations. Whenever cleaning up the underlying citation code is done, please place the "series" field after the "edition" (and "language") fields. —DocWatson42 (talk) 18:41, 21 January 2026 (UTC)

And I hope that someone is keeping a list of all the proposed and needed changes to the code. —DocWatson42 (talk) 18:42, 21 January 2026 (UTC)

Question about a citation using Factiva as an ID value

I've encountered at List of longest-serving United States mayors the following citation:

<ref>{{Cite news |date=13 April 2015 <!-- 19:37 --> |title=Man believed to be New Jersey's longest-serving mayor dies / BC-US--Obit-Longtime Mayor, US<!-- note: the article with HD "BC-US--Obit-Longtime Mayor, US" has LP "BC-US--Obit-Longtime Mayor,115 [line break] Man believed to be New Jersey's longest-serving mayor dies" and TD starting with "Eds: APNewsNow. [line break] CLIFFSIDE PARK, N.J. (AP) — [...]" --> |publication-place=CLIFFSIDE PARK, N.J. |id={{Factiva|APRS000020150413eb4d0056r}} (IPC: "a", IPD: "{{small|<nowiki>US | Obit | Longtime Mayor | AP-US-Obit-Longtime-Mayor | General news | Sports | College basketball | Obituaries | Men's basketball | Municipal governments | Basketball | College sports | Men's sports | Local governments | Government and politics | Obituary | AP Online Other Sports News | AP Online</nowiki>}}"), {{Factiva|APRS000020150413eb4d0057z}} (IPC: "z", IPD: "{{small|<nowiki>US | Obit | Longtime Mayor | BC-US--Obit-Longtime Mayor | State | College basketball | Men's basketball | Obituaries | Municipal governments | Basketball | Sports | College sports | Men's sports | Local governments | Government and politics | AP Regional State Report - New Jersey | AP Regional State News</nowiki>}}") |agency=Associated Press |mode=cs2}}.</ref>

I have no idea how the Factiva site looks like as I don't have an account, but is this how the ID parameter should work? Gonnym (talk) 20:37, 21 January 2026 (UTC)

Problem of lang

 Done: no need to fix

Talking on template:Cite web.

This is not a big problem but should be fixed. lang can be inputted by anything, not just the name of language. It should avoid because editors may misspell without notice.

Noordpunt (talk) 13:17, 22 January 2026 (UTC)

I see this citation accompanied with "{{cite web}}: CS1 maint: unrecognized language (link)". What more do you expect? -- Michael Bednarek (talk) 13:31, 22 January 2026 (UTC)

But this is not intuitive. Editors cannot see it directly after they enter. See,

{{Cite web |title=TEST |url=https://www.wikipedia.org/ |language=And@NOTHING!!!}} will give out "TEST" (in And@NOTHING!!!).{{cite web}}: CS1 maint: unrecognized language (link). It will not show the red key like [www.wikipedia.org/ "TEST"]. {{cite web}}: Check |url= value (help). I think this should be fixed. Noordpunt (talk) 13:41, 22 January 2026 (UTC)

There is a message related to this, but you have add

.mw-parser-output .cs1-maint {display: inline;} /* display Citation Style 1 maintenance messages */

to User:Noordpunt/common.css to be able to see it. -- LCU ActivelyDisinterested «@» °∆t° 15:15, 22 January 2026 (UTC)

@Noordpunt: I presume that this is displayed as a green maintenance message and not a red error because there are many instances where there is a correct value in the field that can't be confirmed (e.g. see Bade language). I wish all issues went to one category, and there was a way to indicate if the parameter has a valid but unsupported value to move it to a separate category. GoingBatty (talk) 02:59, 26 January 2026 (UTC)

Understood. You meant that this is acceptable because some languages do not have a code or difficult to be identified? Then you could ignore this. Noordpunt (talk) 16:05, 26 January 2026 (UTC)

Accessibility of adjacent links

To improve accessibility, it's best to have non-linking characters between adjacent links.

Instead of, for example:

OCLC 171312798

could we output, say:

OCLC: 171312798

and likewise for other IDs?

If space is an issue, a thin space ( ) could be used:

OCLC: 171312798

after the colon. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:43, 22 January 2026 (UTC)

cs1|2 inserts an unlinked no-break-space ( ) character between the label wikilink and the OCLC external link:

{{cite book |title=Title |oclc=171312798}}

'"`UNIQ--templatestyles-0000009F-QINU`"'<cite class="citation book cs1">''Title''. [[OCLC (identifier)|OCLC]]&nbsp;[https://search.worldcat.org/oclc/171312798 171312798].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft_id=info%3Aoclcnum%2F171312798&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Title. OCLC 171312798.

This is true for all cs1|2 identifiers except |arxiv=, |bibcode=, |doi=, and |hdl= which use an unlinked, unspaced, colon separator character. If you are seeing otherwise, show us where you are seeing that. I seem to recall that we had some discussions about label/identifier separators when we migrated to Lua. You might find those discussions in the archives.

—Trappist the monk (talk) 16:20, 22 January 2026 (UTC)

The point is to have a non-linked visible ("printing") character, not white space. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:42, 22 January 2026 (UTC)

We shouldn't have stray 'printing' characters, like "ISBN: 978-0-513-49", because the presentation format for all those identifiers is "ISBN 978-0-513-49", unlike URIs which have the presentation format URI:identifier. Headbomb {t · c · p · b} 01:07, 23 January 2026 (UTC)

They would not be "stray", and we should have then for the reason I gave in my OP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 23 January 2026 (UTC)

Indeed. Though we should not be linking to ISBN at all, it's completely unnecessary overlinking. All the best: Rich Farmbrough 17:21, 23 January 2026 (UTC).

They would be as they are completely non-standard to present with stray punctuation, e.g. [2] which very clearly shows —, ISBN 978-0-486-85264-5, LCCN 2023052679. And all identifiers link to their articles, because not everyone knows what those acronyms mean. Headbomb {t · c · p · b} 04:31, 24 January 2026 (UTC)

To which standard, specifying such things, do you refer? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 24 January 2026 (UTC)

Output of {{cite mailing list}} is typographically broken

(And I can’t figure out how to fix it.) Template output includes the always-invalid string ⟨ - ⟩ (space, hyphen-minus, space). Example: In MediaWiki#cite note-wikidata-8acca0d486515eeb7a169476d3cb7fd85be0c42b-v20-1, the rendered output is “Sam Reed. "Security and maintenance release: 1.39.16 / 1.43.6 / 1.44.3 / 1.45.1 - MediaWiki-announce - lists.wikimedia.org". Retrieved December 10, 2025.”, containing ⟨ - ⟩ twice.

Would someone point me to documentation on how to fix this (or fix it if you wish)? Stephan Leeds (talk) 01:29, 24 January 2026 (UTC)

No templates in section headings.

The reference you point to supports the claim that the stable release is 1.45.1. This claim in the infobox comes from wikidata via {{MediaWiki version}}. If you go there, you will see that {{MediaWiki version}} has this:

{{wikidata|property|reference|edit|P548=Q2804309|Q83|P348}}

That fetches the stable version and the reference that you are apparently complaining about. You can see the raw parameter data at wikidata: d:Q83#P348 (scroll down to 1.45.1 – near the bottom of the version list – it may be highlighted for you). Open the reference dropdown to see the raw reference title, url, access date, and author.

The citation is rendered by {{cite web}} not {{cite mailing list}}.

—Trappist the monk (talk) 02:14, 24 January 2026 (UTC)

preview warning messages tweak

In page-preview mode, the live Module:Citation/CS1 creates a temporary CITEREF anchor id for every template that does not create an id from contributor/author/editor and year. This works but, doing that is not necessary. The only time that the module should create a temporary CITEREF anchor id is when the template it is rendering emits an error or maintenance message. For those who employ a user script to locate cs1|2 templates that are not linked from a short-form reference ({{sfn}} etc), creating temporary CITEREF anchor id for templates without error or maintenance messages hides those templates that legitimately aren't linked.

I have tweaked the sandbox so that temporary CITEREF anchor ids are created only for those templates with error or maintenance messages.

—Trappist the monk (talk) 17:02, 25 January 2026 (UTC)

Currently, it appears that identical preview warnings are bundled together, as in the previous specification. FlatLanguage (talk) 04:05, 30 January 2026 (UTC)

The preview warnings are unique as much as CITEREF anchor IDs are unique; which is to say that they aren't guaranteed to be unique. So two (or more) templates with the same or different cs1|2 errors but which generate the same CITEREF anchor ID will have an identical preview warning message. When you preview this section, these two templates, despite different error messages, create identical preview warning messages. MediaWiki displays only one preview warning message:

{{cite book/new |title= |date=1994 |last=Green |first=EB}}

Green, EB (1994). {{cite book}}: Missing or empty |title= (help)

{{cite book/new |title=No url error |date=1994 |last=Green |first=EB |url-access=subscription}}

Green, EB (1994). No url error. {{cite book}}: |url-access= requires |url= (help)

I wonder if tagging each warning message with a pseudo random number hidden inside a <span style="display:none">XXXXXX</span> tag might fix, or at the least substantially reduce this identical warning messages problem? But maybe not... An individually tagged warning message will be more unique, but the target template linked from the warning message will always be the first target with the duplicated CITEREF anchor ID.

We could, but probably should not, alter a CITEREF anchor ID created from author/contributor/editor name(s) and year to make them unique. We should not because doing so will break the links from {{sfn}} and {{harv}}-family templates.

—Trappist the monk (talk) 16:06, 30 January 2026 (UTC)

This just adds yet another reason to the list why multiple editors have requested that the cite module be fixed. It is currently the number one lint error generator with MW:Help:Lint errors/duplicate-ids being the millions. Gonnym (talk) 16:47, 3 February 2026 (UTC)

Are you sure? If you edit this talk page section and then Show preview, you will see the warning that Module:Citation/CS1 adds to the preview message box. The warning message html looks like this:

<span style="color:#d33"><code style="color: inherit; background: inherit; border: none; padding: inherit;">{{<a href="/wiki/Template:Cite_book" title="Template:Cite book">cite book</a>}}</code>: this <a href="#CITEREFGreen1994">reference</a> has errors</span>; messages may be hidden (<a href="/wiki/Help:CS1_errors#Controlling_error_message_display" title="Help:CS1 errors">help</a>).

That html does not set any id= attributes.

This section does have duplicate-id lint errors but they are not caused by adding a warning message to the preview message box.

—Trappist the monk (talk) 17:43, 3 February 2026 (UTC)

Request for new Cite thesis error checking

Hi there! Could you please consider adding a new error category for {{cite thesis}} with |degree=Thesis or |degree=thesis

• {{cite thesis|title=Title|degree=Thesis}} generates Title (Thesis thesis).

I found 695 instances of this issue in mainspace. Thanks! GoingBatty (talk) 02:41, 26 January 2026 (UTC)

Formatting change ?

I've noticed that when I use the automatic citation tool in mobile on Safari it now renders a citation template with no spaces. Less concerning is the order in which fields are constructed. This might be specific to the cite web template but I'm not sure.

PRIORITY 1

old: |year=1967 |title=Big Sur is beautiful |url=https://catalog.hathitrust.org/Record/100735497 |publisher=Coca-Cola Publishing Co.

new: |year=1967|title=Big Sur is beautiful|url=https://catalog.hathitrust.org/Record/100735497|publisher=Coca-Cola Publishing Co.

the line breaks end up being crazy and it's also a little harder to read and parse as a human

PRIORITY 2

the cites I'm getting have the date and name of the author at the very end?

{{Cite web|title=Springsteen leads musical revolt against ICE raids with 'Streets of Minneapolis' |url=https://www.bostonglobe.com/2026/01/29/arts/springsteen-protest-song-minneapolis/ |website=[[The Boston Globe]]|access-date=2026-01-29|language=en-US|date=2026-01-29|last=Shanahan|first=Mark}}</ref>

this alarms me in a very hard-to-explain way, but I suppose it bothers me bc it conflicts w standard bibliographic formats?

if I was queen goddess of the world it would be ordered

|last= |date or year= |title=

Just bc those are my personal key fields but of course I am not queen goddess of the world this is a nice egalitarian project but author and date last seems bananas to me just the same

just wanted to mention. Thanks for all you do.

jengod (talk) 04:27, 31 January 2026 (UTC)

Did you first notice this from WP:THURSDAY (2026-01-29)?

I don't know what you mean by the automatic citation tool. Whatever that tool is, it is not within the cs1|2 bailiwick.

If the tool is that abomination that is the visual editor, it would appear that it is no longer obeying (at least in part) the order and formatting specified by Template:Cite web § TemplateData. If you look inside the TemplateData at the JSON formatted structure you will find the parameters used in Shannon in this order:

"paramOrder": [
	"last",
	"first",
	...
	"date",
	...
	"title",
	...
	"url",
	...
	"access-date",
	"website",
	...
	"language",
	...
],
"format": "{{_ |_=_}}"

The documentation for paramOrder says that it causes the parameters of a template to be displayed in a specific order when added in the template editor. The documentation does not say that paramOrder controls the order of the parameters in the rendered wikitext.

The format keyword is supposed to tell tools that obey TemplateData that spacing within the rendered wikitext for {{cite web}} is supposed to be like this:

{{Cite web |title=Springsteen leads musical revolt against ICE raids with 'Streets of Minneapolis' |url=https://www.bostonglobe.com/2026/01/29/arts/springsteen-protest-song-minneapolis/ |website=[[The Boston Globe]] |access-date=2026-01-29 |language=en-US |date=2026-01-29 |last=Shanahan |first=Mark}}

If your tool is supposed to be obeying TemplateData, clearly it is not.

Beyond this, I can be no help. I would suggest that your next stop should be WP:PHAB. If this issue is not already reported, be very specific in the detail you provide when you create a bug report. If you can, provide diffs of cs1|2 templates that you created using your tool where the rendered wikitext has correctly ordered and spaced parameters. Similarly provide diffs of newly created but malformed cs1|2 templates. Explicitly identify the tool that you are using; state when you first noticed this problem, and identify your browser and OS.

As an alternate to WP:PHAB, you might post a note at WP:VPT pointing to this discussion. Perhaps someone there can be more helpful.

—Trappist the monk (talk) 16:42, 31 January 2026 (UTC)

You are lovely. I will visit the recommended resources and confer with those folks. Thank you @Trappist the monk jengod (talk) 17:51, 31 January 2026 (UTC)

Just in case anyone cares they are working on it here:

phabricator ticket T416080

thanks again jengod (talk) 04:58, 2 February 2026 (UTC)

False "error": "|contributor= requires |contribution=" even though "|script-contribution=" is already present

There seems to be a false error where "|contributor= requires |contribution=" even though "|script-contribution=" is already present. Compare to "|title=" which is always required except when "|script-title=" is already present. There seems to be a lack of consistency as to what is required and what isn't here. Also, "|script-chapter=" can exist on its own without "|chapter=", so if "|contribution=" is supposed to be an alias to "|chapter=", as explicitly claimed by the documentation, it should be replaceable by "|script-contribution=". Mazamadao (talk) 02:41, 3 February 2026 (UTC)

Fixed in the sandbox I think:

{{cite book/new|lang=ja|url=https://dl.ndl.go.jp/pid/1064330/1/190|p=342|script-contribution=ja:ローベルト・コッホ先生と北里柴三郞博士<!--Faulty template. Looks like it requires specifically 'contribution' but misses out on 'script-contribution'. Better fix the template than alter content here-->|trans-contribution=[[Medical doctor|Dr]] [[Robert Koch]] and [[Doctor (title)|Dr]] [[Kitasato Shibasaburō]]|script-title=ja:ローベルト・コッホ　偉大なる生涯の物語|trans-title=Robert Koch: Story of a Great Life|title=Robert Koch. Roman eines großen Lebens|first=Friedrich Hermann Hellmuth|last=Unger|contributor-first=Mikinosuke|contributor-last=Miyajima|contributor-first2=Renji|contributor-last2=Ishikawa|publisher=Fuzambo|date=8 June 1943|location=[[Kanda, Tokyo]]}}

Miyajima, Mikinosuke; Ishikawa, Renji (8 June 1943). ローベルト・コッホ先生と北里柴三郞博士 [Dr Robert Koch and Dr Kitasato Shibasaburō]. Robert Koch. Roman eines großen Lebens ローベルト・コッホ　偉大なる生涯の物語 [Robert Koch: Story of a Great Life]. By Unger, Friedrich Hermann Hellmuth (in Japanese). Kanda, Tokyo: Fuzambo. p. 342.

—Trappist the monk (talk) 18:25, 3 February 2026 (UTC)

Suggestion for generic name error: Foundation

Please consider adding "Foundation" as an incorrect value to be included Category:CS1 errors: generic name. I see 1,082 examples in articlespace in these search results. Thanks! GoingBatty (talk) 02:42, 3 February 2026 (UTC)

archive.today deprecation

Page watchers may be interested in Wikipedia:Village pump (technical) § Deprecating and blacklisting archive.today. Izno (talk) 01:18, 5 February 2026 (UTC)

Bad archive URL

Can someone please work out why Bear_Camp_Road#cite_note-5 is complaining about a bad archive URL? The archive URL seems valid to me. * Pppery * _{it has begun...} 19:08, 5 February 2026 (UTC)