To helpcentralize discussions and keep related topics together, the talk pages for all Citation Style 1 and Citation Style 2 templates and modules redirect here. A list of those talk pages and their historical archives can be foundhere.
This help page does not require a rating on Wikipedia'scontent assessment scale. It is of interest to multipleWikiProjects.
This page is within the scope of theWikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visitthe project page, where you can join thediscussion and see a list of open tasks. To browse help related resources see theHelp Menu orHelp Directory. Orask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp
This page is within the scope ofWikiProject Academic Journals, a collaborative effort to improve the coverage ofAcademic Journals on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.Academic JournalsWikipedia:WikiProject Academic JournalsTemplate:WikiProject Academic JournalsAcademic Journal
This page is within the scope ofWikiProject Magazines, a collaborative effort to improve the coverage ofmagazines on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.MagazinesWikipedia:WikiProject MagazinesTemplate:WikiProject Magazinesmagazine
Module:Citation/CS1/Configuration needs the10.xxxx/... part of the DOI associated with the publisher.All the publications of the publisher must be free-to read. Once that is done, thexxxx part can be added to the list underlocal function build_free_doi_registrants_table(). Also leave a note atUser talk:Citation bot.
Module:Citation/CS1/Configuration needs the10.xxxx/yyyy part of the DOI associated with the journal.All the articles associated with that DOI pattern must be free-to read. Once that is done, thexxxx/yyyy parts can be added to the list underlocal extended_registrants_t = { with the format['XXXX'] = {'YYYY'},. If there are multiple journals with the same DOI prefix, they can be grouped together with the format['XXXX'] = {'YYYY', 'ZZZZ', '...'},. Also leave a note atUser talk:Citation bot.
I would like to add a geo-dead/geo-access URL keyword
Previous discussions have come to the conclusion that this is not workable. Websites change which regions can access them regularly, and these websites are regardless not fundamentally dead.
I would like support for PDF page numbers
The specific page of a specific PDF may change between clients with the same file or files with the same client. Consider using a|chapter= or|quote= instead.
I would like my change done now
Local consensus is that these modules sync from their sandboxes approximately once every 3–6 months. This is due to complexity of changes, the number of transclusions these modules have, and to be sure sufficient consensus exists for a change.
I don't like(identifier) in the links to identifier pages
I think there's an unhandled case inlocalfunctionarchive_url_check(url,date). According to line 2486 ofModule: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 withan error claimingarchive-url= is malformed: timestamp. The timestamp is correctly 14 digits.
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. --LCUActivelyDisinterested«@» °∆t°14:19, 20 January 2026 (UTC)[reply]
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. --LCUActivelyDisinterested«@» °∆t°15:03, 20 January 2026 (UTC)[reply]
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-2012archive.today citations. Redundant hosting does serve a purpose. Archives are subject to separate legal requirements based on activity, e.g.country-level blocks ortakedown 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.
I imagine the typical chain of events is that a human editor adds a (shortened)archive.ph URL, which a bot replaces with a timestampedarchive.today URL, and produces this parameter error without any human oversight.Blepbob (talk)02:35, 21 January 2026 (UTC)[reply]
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}}
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}}
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}}
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}}
"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.
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)[reply]
If you're asking about the technical point, because, as explained atHelp 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)[reply]
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)[reply]
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:RichFarmbrough14:04, 23 January 2026 (UTC).[reply]
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 erroneousError: |archive-url= is malformed: timestamp action must stop immediately. --Michael Bednarek (talk)23:51, 24 January 2026 (UTC)[reply]
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?
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}}
The above example confused me. Change{{cite web}} to{{cite web/new}} and it is fine. Only waiting for the sandbox to update. --GreenC17:45, 7 February 2026 (UTC)[reply]
Yes undo this change - it has no consensus and is spamming the site with over16,000 error messages and going up daily. There is no requirement to use the Wayback Machine. They often removes archives - Archive.today isthe 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. --GreenC06:34, 31 January 2026 (UTC)[reply]
{{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}}
{{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}}
{{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}}
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? --GreenC22:33, 3 February 2026 (UTC)[reply]
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}}
I just found a discussion I had withSnowman304 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 <!->.
Hi. Your bot archived links onHelen 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)MenkinAlRire13:56, 17 September 2024 (UTC)[reply]
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.MenkinAlRire16:00, 17 September 2024 (UTC)[reply]
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.
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— Precedingundated comment added06:24, 31 January 2026 (UTC)[reply]
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 pagenever 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)[reply]
Question about a citation using Factiva as an ID value
<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>
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. --GreenC06:53, 8 February 2026 (UTC)[reply]
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.
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)[reply]
There is a message related to this, but you have add
@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. seeBade 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)[reply]
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)[reply]
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.
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", unlikeURIs which have the presentation formatURI:identifier.Headbomb {t ·c ·p ·b}01:07, 23 January 2026 (UTC)[reply]
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:RichFarmbrough20:13, 9 February 2026 (UTC).[reply]
Output of{{cite mailing list}} is typographically broken
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:
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.
In page-preview mode, the liveModule:Citation/CS1 creates a temporaryCITEREF 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 temporaryCITEREF 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 temporaryCITEREF anchor id for templates without error or maintenance messages hides those templates that legitimately aren't linked.
I have tweaked the sandbox so that temporaryCITEREF anchor ids are created only for those templates with error or maintenance messages.
The preview warnings are unique as much asCITEREF 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 sameCITEREF 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:
I wonder if tagging each warning message with a pseudo random number hidden inside a<span>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 duplicatedCITEREF anchor ID.
We could, but probably should not, alter aCITEREF 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.
Are you sure? If you edit this talk page section and thenShow preview, you will see the warning thatModule:Citation/CS1 adds to the preview message box. The warning message html looks like this:
<spanstyle="color:#d33"><codestyle="color: inherit; background: inherit; border: none; padding: inherit;">{{<ahref="/wiki/Template:Cite_book"title="Template:Cite book">cite book</a>}}</code>: this<ahref="#CITEREFGreen1994">reference</a> has errors</span>; messages may be hidden (<ahref="/wiki/Help:CS1_errors#Controlling_error_message_display"title="Help:CS1 errors">help</a>).
That html does not set anyid= attributes.
This section does have duplicate-id lint errors but they are not caused by adding a warning message to the preview message box.
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
Did you first notice this fromWP:THURSDAY (2026-01-29)?
I don't know what you mean bythe 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 byTemplate: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:
The documentation forparamOrder says that itcauses the parameters of a template to be displayed in a specific order when added in the template editor. The documentation does not say thatparamOrder controls the order of the parameters in the rendered wikitext.
Theformat 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 beWP: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 atWP:VPT pointing to this discussion. Perhaps someone there can be more helpful.
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)[reply]
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]]}}
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)[reply]
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 becauseAMP is a disambiguation page... If an editor absolutelymust 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}}
"TheAMP-activated protein kinase α2 catalytic subunit controls whole-body insulin sensitivity".The Journal of Clinical Investigation.PMC151837.
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):
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-0000025D-QINU`"'<citeclass="citation web cs1">[http://www.bartleby.com/61/5c.html "Regional Patterns of American Speech"]. [[Bartleby.com|Bartleby]]<spanclass="reference-accessdate">. Retrieved<spanclass="nowrap">2007-10-29</span></span>.<q>La la la</q></cite><spantitle="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:
If I understand it correctly, en.wiki and cs1|2 override the browser/OS default styling for<q>...</q> in Common.css (atlines 11–14) and in Citation/CS1/styles.css (atlines 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 isWP:VPT orWP:RD/C.
Firefox 147 in Windows 10: the w3schools link gives me curly quotes, the geeksforgeeks one gives straight. Safari iniPadOS 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)[reply]
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)[reply]
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)[reply]
Done: no need to fix