Help talk:Citation Style 1

Multivolume "parts" of a work

"In rare cases, publications carry both an ongoing volume and a year-related value; if so, provide them both". Yes, but there are also other complexities. Molmenti's Venice (over a century old) has a number of what publishers in the 21st century would normally and straightforwardly call volumes, but it's in "parts", and I'd like to cite page 176 of what it labels volume 1 of "Part 3. The decadence". What's the best (or least undesirable) way of specifying this? -- Hoary (talk) 05:58, 9 January 2026 (UTC)

The |at= parameter is flexible, so if all else fails, you can write something like Molmenti. Venice. Part 3. The Decadence. Volume 1. p. 176. Remember that the main point of the citation templates is to help readers find the cited material. That goal appears to be achieved here. – Jonesey95 (talk) 16:39, 9 January 2026 (UTC)

Template:Replyto Some 95-100 years ago a man called MacDermot (for whom we don't have an article) was commissioned to produce an official history of the Great Western Railway. It was published in two volumes four years apart, vol. I in 1927 and vol. II in 1931. But Volume I was so large that it was bound as two parts, with pages 1-456 being in Volume I Part I, and pages 457-902 being in Volume I Part II. They were sold as a pair. Volume II has its own page numbers, 1-654. Since the page numbering in the two parts of Vol. I do not duplicate, I simply omit the part and cite it as

• MacDermot, E.T. (1927). History of the Great Western Railway, vol. I: 1833–1863. Paddington: Great Western Railway. p. 789.

or whatever page number applies. --Redrose64 🌹 (talk) 22:01, 9 January 2026 (UTC)

Template:Replyto Yes of course, "at=". I'd previously used that, in at least one other article ... and then forgot all about it. (Not yesterday's only failure. I'm embarrassed to find that I also perpetrated {{Citation needed|date=February 2026}}.) Yes, this English translation of Molmenti isn't the first example I've dealt with of the use of both "volume" and "part": there's also Jespersen-and-assistants' seven-"part" A Modern English Grammar on Historical Principles, the naming system of whose -- how shall I word this? -- tomes is different from either Molmenti's work or MacDermot's. -- Hoary (talk) 23:14, 9 January 2026 (UTC)

That's a nice example, Template:U. Again, the point is to provide enough information so that a reader can find the cited material. As long as you don't egregiously misuse any of the parameters, focus on that goal. If all else fails, omit the citation template entirely and use normal wikitext formatting to get what you want, maybe leaving a hidden comment for CITEVAR nerds explaining why there is no template. – Jonesey95 (talk) 00:16, 10 January 2026 (UTC)

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

Template:Cite compare

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

catching malformed ve/citoid-created {{citation}} book cites

At User talk:Citation bot § bot breaks citation templates I wrote that I would tweak the cs1|2 module suite to catch ve/citoid-created template that look summat like this:

<syntaxhighlight lang="wikitext" inline="1">Chuku, Gloria (2013), Chuku, Gloria (ed.), "Kenneth Dike: The Father of Modern African Historiography", The Igbo Intellectual Tradition: Creative Conflict in African and African Diasporic Thought, New York: Palgrave Macmillan US, pp. 137–164, doi:10.1057/9781137311290_6, ISBN 978-1-137-31129-0, retrieved 2024-11-18{{citation}}: CS1 maint: work parameter with ISBN (link)</syntaxhighlight>

Chuku, Gloria (2013), Chuku, Gloria (ed.), "Kenneth Dike: The Father of Modern African Historiography", The Igbo Intellectual Tradition: Creative Conflict in African and African Diasporic Thought, New York: Palgrave Macmillan US, pp. 137–164, doi:10.1057/9781137311290_6, ISBN 978-1-137-31129-0, retrieved 2024-11-18{{citation}}: CS1 maint: work parameter with ISBN (link)

Outwardly that rendering looks to be correct. It is not. {{citation}} uses |work= and its aliases to switch the citation's metadata from book format to periodical format. The Igbo Intellectual Tradition: Creative Conflict in African and African Diasporic Thought is not a periodical. The editor namelist and associated static text also render differently. This sort of malformed template is all too common. Because ISBNs do not apply to periodicals, the combination of a |work= alias with |isbn= should not occur. If we are to believe this search, there are at least 19,000 articles that use {{citation}} with |work= followed by |isbn=.

I have tweaked the cs1|2 module suite to catch {{citation}} templates that have both a |work= parameter (or alias) and an |isbn= parameter. When such templates are found, cs1|2 emits a maintenance message and adds the article to a new maintenance category Category:CS1 maint: work parameter with ISBN. Is there a better category name?

<syntaxhighlight lang="wikitext" inline="1">Template:Citation/new</syntaxhighlight>

Template:Citation/new

Compare to a properly written template (using the sandbox version to show that this new test doesn't break properly formatted templates):

<syntaxhighlight lang="wikitext" inline="1">Template:Citation/new</syntaxhighlight>

Template:Citation/new

—Trappist the monk (talk) 15:55, 11 January 2026 (UTC)

ISBNs are also asigned to Mook. I sometimes teeter between |chapter= |title and |title= |magazine= FlatLanguage (talk) 05:41, 12 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 Template:Slinkno. Compare (from Neapolitan ragù, with |jstor-access=free)

with (from Princess Mononoke, with |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 Template:Oldid), where mw.ustring.gsub is used to translate local digits for enumerated parameters:

<syntaxhighlight lang="lua"> k = mw.ustring.gsub (k, '%d', cfg.date_names.local_digits); -- for enumerated parameters, translate 'local' digits to Western 0-9 </syntaxhighlight>

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:

<syntaxhighlight lang="lua" inline="1">if 'string' == type(k) and k:find ('%d$') then</syntaxhighlight>

or perhaps:

<syntaxhighlight lang="lua" inline="1">if 'string' == type(k) and k:find ('%d', -1) then</syntaxhighlight>

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:

<syntaxhighlight lang="lua">

-- 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 </syntaxhighlight>

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

<syntaxhighlight lang="lua">

return {

 ...
 skip_digit_translate = is_identity_map(date_names.local_digits),
 ...

} </syntaxhighlight>

Then the relevant code in Module:CS1 becomes:

<syntaxhighlight lang="lua">

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 </syntaxhighlight>

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:

<syntaxhighlight lang="lua" inline="1">if 'string' == type(k) and not k:find ('%d$') then</syntaxhighlight>

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

<syntaxhighlight lang="lua">for ld, ed in pairs (date_names.local_digits) do

date_names.xlate_digits [ed] = ld; end</syntaxhighlight>

so we might modify it:

<syntaxhighlight lang="lua">

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</syntaxhighlight>

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:

<syntaxhighlight lang="lua">enum_needs_xlation = '1' ~= date_names.xlate_digits['1']; -- true when local digits are not western digits; must translate enumerators</syntaxhighlight>

and in the main module this:

<syntaxhighlight lang="lua">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</syntaxhighlight>

Is it not true that none of this benefits wikis that do not use western digits? You wrote: Template:Tq. 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: <syntaxhighlight lang="lua" class="" style="" inline="1">cfg.enum_needs_xlation</syntaxhighlight> 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 <syntaxhighlight lang="lua" class="" style="" inline="1">local function archive_url_check (url, date)</syntaxhighlight>. According to line 2486 of Module:Citation/CS1, <syntaxhighlight lang="lua" inline="1">-- <origin_date> is 1996 for archive.org; 2012 for archive.today</syntaxhighlight>. 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 Template:Talk quote inline. The timestamp is correctly 14 digits.

In this example, the archive.today listing says it was Template:Talk quote

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 <syntaxhighlight lang="text" class="" style="" inline="1">archive.today</syntaxhighlight> 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) <syntaxhighlight lang="text" class="" style="" inline="1">archive.ph</syntaxhighlight> URL, which a bot replaces with a timestamped <syntaxhighlight lang="text" class="" style="" inline="1">archive.today</syntaxhighlight> 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):

<syntaxhighlight lang="wikitext" inline="1">Template:Cite web/new</syntaxhighlight>

Template:Cite web/new

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

<syntaxhighlight lang="wikitext" inline="1">Template:Cite web/new</syntaxhighlight>

Template:Cite web/new

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

<syntaxhighlight lang="wikitext" inline="1">Template:Cite web/new</syntaxhighlight>

Template:Cite web/new

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:

<syntaxhighlight lang="wikitext" inline="1">Template:Cite news/new</syntaxhighlight>

Template:Cite news/new

—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

Template:Mdf 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, <syntaxhighlight lang="lua" inline="1">-- <origin_date> is 1996 for archive.org; 2012 for archive.today</syntaxhighlight>". 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 Template:Citation error 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:
<syntaxhighlight lang="wikitext">"Rosenborg BK". Union of European Football Associations. Retrieved 20 April 2011. {{cite web}}: |archive-url= is malformed: timestamp (help)CS1 maint: url-status (link)</syntaxhighlight>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)

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)

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: <syntaxhighlight lang="wikitext"> </syntaxhighlight>

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

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 "

Template:Color (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 <syntaxhighlight lang="css">.mw-parser-output .cs1-maint {display: inline;} /* display Citation Style 1 maintenance messages */</syntaxhighlight>

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:

<syntaxhighlight lang="wikitext" inline="1">Title. OCLC 171312798.</syntaxhighlight>

<syntaxhighlight lang="html" class="" style="" inline="1">Title. OCLC 171312798.</syntaxhighlight>

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:

<syntaxhighlight lang="wikitext" inline="1">Template:Wikidata</syntaxhighlight>

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:

<syntaxhighlight lang="wikitext" inline="1">Template:Cite book/new</syntaxhighlight>

Template:Cite book/new

<syntaxhighlight lang="wikitext" inline="1">Template:Cite book/new</syntaxhighlight>

Template:Cite book/new

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)

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 Template:Cite thesis

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