Help talk:Citation Style 1

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)

Wait, so what is the expectation from the editors, we are supposed to now start taking all of these "Saved from" URLs from archive.today headings, and copying them into the citations instead?

Surely a bot should be doing such a mundane change, not bothering readers and editors? --Joy (talk) 11:42, 12 February 2026 (UTC)

And there is no guarantee that the "saved from" is still live. All the best: Rich Farmbrough 12:00, 12 February 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)

The above example confused me. Change {{cite web}} to {{cite web/new}} and it is fine. Only waiting for the sandbox to update. -- GreenC 17:45, 7 February 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)

OK I'm clearly confused. We are only waiting for the sandbox to update. -- GreenC 17:46, 7 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)

[some original discussion commented out...] note injected by — JohnFromPinckney (talk / edits) 06:43, 13 February 2026 (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)

[more original discussion commented out...] note injected by — JohnFromPinckney (talk / edits) 06:43, 13 February 2026 (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 — Preceding undated comment added 06:24, 31 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)

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)

Rule of thumb: nowiki is a sign of ineptitude. The goal is to cite the death of Gerald Calabrese. This does the job simple enough:

Associated Press (April 13, 2015). "Gerald Calabrese, New Jersey's Longest-Serving Mayor, Dies at 90". The New York Times. Retrieved 2026-02-08.

If you specifically need to cite the AP wire report rather than a newspaper reprint:

"Man believed to be New Jersey's longest-serving mayor dies". Cliffside Park, N.J. Associated Press. April 13, 2015. Retrieved 2026-02-08.

Use the actual headline instead of the wire service transmission code. If you really must use Factiva wire transmission code use this

"Man believed to be New Jersey's longest-serving mayor dies". Associated Press. April 13, 2015. Factiva: APRS000020150413eb4d0056r. Retrieved 2026-02-08.

The IPC (Item Primary Code) and IPD (Item Primary Descriptor) in a public Wikipedia caption is like a chef printing the inventory SKU numbers for the flour and eggs on a restaurant menu. It's maybe useful for the kitchen's internal record-keeping, but it clutters the public citation, nobody wants or needs it. It's like someone went out of their way to make a citation as unnecessarily complicated as possible. -- GreenC 06:53, 8 February 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-00000077-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)

the comment directly below added here from duplicated discussion. @Rich Farmbrough: if not correct, please fix this discussion page.—Trappist the monk (talk) 20:28, 9 February 2026 (UTC)

The difference is that firstly most people have some idea of what ISBN means, secondly when you click the number you go to a page which has a link to our article at the top. Thirdly the magic word, before it was disabled because our software team couldn't make RTL work (so everyone else has to suffer) only linked to the book-sources page. Fourthly people will click on the ISBN instead of the number, as it's by no means clear these are two separate links. Fifthly it adds millions of unnecessary links, probably over 8 million, based on a sample of 10,000 articles. It was a mistake to start linking to ISBN, and it can be simply fixed now. All the best: Rich Farmbrough 20:13, 9 February 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)

Now 697, even counting thee one I fixed. All the best: Rich Farmbrough 17:30, 8 February 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)

@Pppery: The date in the archive URL, 2006, is earlier than the date archive.today was founded. There's a long thread about this at Help talk:Citation Style 1#Error with origin date for archive.today, above. -- John of Reading (talk) 07:33, 6 February 2026 (UTC)

auto link conflicts link in title

PMC and free doi makes auto link in {{cite journal}}, but it conflicts when |title= has internal-link. I edited sandbox and avoid this conflicting:

Cite journal comparison

Wikitext	{{cite journal|journal=The Journal of Clinical Investigation|pmc=151837|title=The [[AMP]]-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity}}
Live	"The [[AMP]]-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. PMC 151837. {{cite journal}}: URL–wikilink conflict (help)
Sandbox	"The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. PMC 151837.

Cite journal comparison

Wikitext	{{cite journal|journal=The Journal of Clinical Investigation|pmc=151837|title-link=pmc|title=The [[AMP]]-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity}}
Live	"The [[AMP]]-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. PMC 151837. {{cite journal}}: URL–wikilink conflict (help)
Sandbox	"The [[AMP]]-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. PMC 151837. {{cite journal}}: URL–wikilink conflict (help)

Cite journal comparison

Wikitext	{{cite journal|journal=The Journal of Clinical Investigation|pmc=151837|title-link=pmc|title=The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity|url=https://www.jci.org/articles/view/16567}}
Live	"The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. PMC 151837.
Sandbox	"The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. PMC 151837.

If there are some problems, revert it. --FlatLanguage (talk) 06:10, 8 February 2026 (UTC)

There is indeed a problem, and the problem is that it should show an error in the first case. The live version is what's desired. Headbomb {t · c · p · b} 11:54, 8 February 2026 (UTC)

Concur. As I understand it, the sense from past discussion here is that the value in |title= should not be wikilinked, especially partial wikilinking as your examples use – made worse in these examples because AMP is a disambiguation page... If an editor absolutely must wikilink some term or phrase in |title= that would otherwise be autolinked, there is |title-link=none:

{{cite journal |title=The [[AMP]]-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity |journal=The Journal of Clinical Investigation |pmc=151837 |title-link=none}}

"The AMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity". The Journal of Clinical Investigation. PMC 151837.

—Trappist the monk (talk) 16:14, 8 February 2026 (UTC)

Recent change to the "Quote" parameter?

Greetings and felicitations. Was there a recent change to the "quote" parameter? I am in mobile using iOS and Safari, and the quotation marks are appearing to me to be extra small and halfway up the quoted text, as in this reference (to which I have added a quotation for test purposes):

• "Regional Patterns of American Speech". Bartleby. Retrieved 2007-10-29. La la la

The quotation marks around the title look normal. —DocWatson42 (talk) 13:34, 11 February 2026 (UTC)

There have been no changes to cs1|2 that would account for what you are seeing. cs1|2 uses <q>...</q> tags for |quote= and has for a long time:

'"`UNIQ--templatestyles-000000B8-QINU`"'<cite class="citation web cs1">[http://www.bartleby.com/61/5c.html "Regional Patterns of American Speech"]. [[Bartleby.com|Bartleby]]<span class="reference-accessdate">. Retrieved <span class="nowrap">2007-10-29</span></span>. <q>La la la</q></cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Regional+Patterns+of+American+Speech&rft.pub=Bartleby&rft_id=http%3A%2F%2Fwww.bartleby.com%2F61%2F5c.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

For me on desktop windows 11 chrome and on my iphone, the quote marks around the quotation look correct. Taking cs1|2 out of the picture, the quote marks in these examples also look the same:

"La la la" ← "La la la"

La la la ← <q>La la la</q>

—Trappist the monk (talk) 14:06, 11 February 2026 (UTC)

Doesn't <q>...</q> use quotation marks in the local language? Couldn't that account for differences? -- Michael Bednarek (talk) 14:12, 11 February 2026 (UTC)

I'm using American English, and the second example looks different in my browser. Give me a few minutes to upload the screenshot. —DocWatson42 (talk) 14:36, 11 February 2026 (UTC)

Screenshot. —DocWatson42 (talk) 15:04, 11 February 2026 (UTC)

Your browser determines how to treat <q>...</q>. What do you see when you visit https://www.w3schools.com/html/tryit.asp?filename=tryhtml_formatting_q or https://www.geeksforgeeks.org/html/html-q-tag/ ? -- Michael Bednarek (talk) 15:18, 11 February 2026 (UTC)

If I understand it correctly, en.wiki and cs1|2 override the browser/OS default styling for <q>...</q> in Common.css (at lines 11–14) and in Citation/CS1/styles.css (at lines 21–23). Both of those are identical. That suggests that summat in OP's browser/OS is overriding/ignoring the mediawiki/cs1|2 css for <q>...</q>.

I don't know anything about iOS and Safari so perhaps the next stop is WP:VPT or WP:RD/C.

—Trappist the monk (talk) 15:37, 11 February 2026 (UTC)

Firefox 147 in Windows 10: the w3schools link gives me curly quotes, the geeksforgeeks one gives straight. Safari in iPadOS 15.8.6: both are straight. I don't know how to find the Safari version, but I assume it's current, since iPadOS is current as of last update (two days ago). --Redrose64 🌹 (talk) 22:00, 11 February 2026 (UTC)

DocWatson42, if you go on your iOS device to Settings - General - Language & Region, what is set for your preferred language and your region? Also, if you log out of Wikipedia, is the display the same? – Jonesey95 (talk) 21:26, 12 February 2026 (UTC)

English and United States, and when I log out the size of the quotation marks changes (they get a bit bigger), the position does not—they are still too low. My software is current. I'll check my desktop view, and post a screenshot of the logged-out mobile version later —DocWatson42 (talk) 11:45, 13 February 2026 (UTC)

Done (see the second image). However, Trappist's two examples look the identical to me on desktop (Firefox 147.0.1 under macOS Sequoia 15.7.3). —DocWatson42 (talk) 13:35, 13 February 2026 (UTC)

Suggestion for generic name error: By

Please consider adding "By" as an incorrect value to be included Category:CS1 errors: generic name. I see 341 examples in articlespace in these search results before it times out. Thanks! GoingBatty (talk) 03:01, 14 February 2026 (UTC)