Help talk:Citation Style 1

ADS is scheduled to be shutdown on 16 November 2026. It's replacement, SciX, has been available for some time. See Template talk:Bibcode § ADS to SciX migration for details.

This edit request to Module:Citation/CS1/Configuration has been answered. Set the |answered= parameter to no to reactivate your request.

In Module:Citation/CS1/Configuration, please replace the line:

prefix = 'https://ui.adsabs.harvard.edu/abs/',

with

prefix = 'https://scixplorer.org/abs/',
suffix = '/abstract',

Daask (talk) 17:30, 5 October 2026 (UTC)Reply

This should be done in the sandbox, and deployed with the rest of the changes. So long as it's live before Nov 16th or so. Headbomb {t · c · p · b} 19:26, 5 October 2026 (UTC)Reply

 Task complete. Implemented in sandbox in Diff/1378836392. Daask (talk) 11:37, 6 October 2026 (UTC)Reply

You should always provide evidence that the changes you make actually work.

—Trappist the monk (talk) 14:32, 7 October 2026 (UTC)Reply

The link seems to work fine, though there is no suffix as ostensibly intended. Tol (talk | contribs) @ 07:21, 17 October 2026 (UTC)Reply

I am removing the suffix = '/abstract' because:

1. It doesn't seem to actually produce a suffix (or for that matter any change in the output).
2. The link without the suffix works perfectly fine.
3. The current setup (classic ADS) also works similarly, e.g. linking to https://ui.adsabs.harvard.edu/abs/1998ApJ...508L..81K which redirects to https://ui.adsabs.harvard.edu/abs/1998ApJ...508L..81K/abstract, while the SciX setup links to https://scixplorer.org/abs/1998ApJ...508L..81K which redirects to https://scixplorer.org/abs/1998ApJ...508L..81K/abstract.

Please let me know and/or revert if this is undesirable. Tol (talk | contribs) @ 21:47, 5 November 2026 (UTC)Reply

I just updated the Wikidata ADS bibcode (P819) article property with this, but it doesn't look like Scixplorer does a look up for the 5-character ADS journal codes any more for use with the bibcode (P1300) journal property. — Jonathanischoice (talk) 01:52, 19 October 2026 (UTC)Reply

@Trappist the monk: There's two weeks before this is deployed on the NASA side. Could we get a template update next weekend? Headbomb {t · c · p · b} 20:27, 1 November 2026 (UTC)Reply

SSRN 7534918 is valid and found in Trump v. Slaughter. Thanks! Snowman304|talk 00:48, 10 October 2026 (UTC)Reply

I just stumbled upon SSRN 7671881, which is also valid but greater than the current CS1 limit. Daask (talk) 20:40, 2 November 2026 (UTC)Reply

The "ISBN / Date incompatibility" error is not always correct. There are books for which later printings of an edition originally from before 1965 were given an ISBN. Using the date of a specific later printing is misleading and unhelpful to readers, but the ISBN is also correct.

An example which recently came up is

Needham, Joseph (1959). Science and Civilisation in China. Volume 3: Mathematics and the Sciences of the Heavens and the Earth. With the collaboration of Wang Ling. Cambridge: University Press.

This edition was originally published in 1959, but had later printings in 1970, 1972, 1975, 1979, 1992, 1995, (...and others?), with no changes to the text. At some point it was given the ISBN 9780521058018 by Cambridge University Press, but if you look at the publisher's website, the publication date is still listed as 1959. –jacobolus (t) 17:12, 17 October 2026 (UTC)Reply

Also, the recommendation at Help:CS1 errors § ISBN / Date incompatibility is completely wrong:

If the cited edition or reissue of the book was published after 1965, ensure that |date= or |year= has the correct publication year. The reissue date is typically available by querying WorldCat with the reissue's ISBN. Adding |orig-date= may be appropriate in such cases; e.g., |orig-date=1929.

This is terrible advice which will cause editors to incorrectly use the data of a specific printing of a book rather than the publication date for the edition. –jacobolus (t) 17:22, 17 October 2026 (UTC)Reply

Reprintings of books often contain silently fixed errors. WP:SAYWHERE applies. – Jonesey95 (talk) 18:00, 20 October 2026 (UTC)Reply

I have never once encountered a case where there was such a change affecting the relevance or correctness of a citation made from Wikipedia. But regardless, the relevant "publication date" remains the date of the edition, and changing the date to a particular printing is confusing, misleading, and unconventional. The immediately following section of WP:CS (§ Dates and reprints) explains: "Date a book that is identically reprinted or printed-on-demand to the first date in which the edition became available. For example, if an edition of a book was first released in 2005 with an identical reprinting in 2007, date it to 2005." Anyway, I'll default to just leaving the ISBNs out. –jacobolus (t) 19:04, 20 October 2026 (UTC)Reply

I fixed Help:CS1 errors § ISBN / Date incompatibility so that it follows WP:CS. It can be changed again at such a time as the citation template gains the ability to suppress this error. –jacobolus (t) 19:18, 20 October 2026 (UTC)Reply

I have the same issue as jacobolus; a lot of e-books are assigned isbns but are merely scans of the original book and frequently do not have new dates issued. Could we allow for orig-date without date? Haven't thought it through fully as of yet, but it could work.  Mr.choppers | ✎  19:36, 20 October 2026 (UTC)Reply

Some of these "books" are garbage print-on-demand copies made from a mediocre scan, put out by no-name "publishers". In such a case I'd recommend skipping the ISBN, trying to find the best scan you can of the original (e.g. from the Internet Archive) to link as the 'url' parameter, and citing the original book.

If a facsimile was republished by a reputable publisher, then you can cite the new date, include orig-date with the original publication date, and make a note to readers that it was a republication of a facsimile. –jacobolus (t) 19:44, 20 October 2026 (UTC)Reply

@Jnestorius: as another interested editor; he created a whole dang table here. I still think allowing orig-date without date should be the simplest solution. I do not have any examples of reputable facsimiles published without new dates at the ready, but I am sure they are out there.  Mr.choppers | ✎  20:18, 20 October 2026 (UTC)Reply

One other option is to add a note like "Later printings {{isbn|...}}" after the citation template. –jacobolus (t) 20:37, 20 October 2026 (UTC)Reply

I have several books, mainly published by the Railway Correspondence and Travel Society (RCTS), that are reprints and which also have ISBNs, but the reprint date is not given. I am getting fed up of people removing these perfectly-valid ISBNs. Although the original date is required to establish copyright, the reprint doesn't extend the copyright, and so I expect that the publisher felt that it's not necessary. --Redrose64 🌹 (talk) 22:06, 20 October 2026 (UTC)Reply

I expect that he publisher is just reprinting old books to make money and doesn't care about much else. You should be able to find the year of publication from the ISBN if the publisher is reputable. All the best: Rich Farmbrough 18:34, 27 October 2026 (UTC).Reply

Coda: If the ISBN is so obscure that not information can be found, it is of very limited use. I'd still want to include it, provided, of course, that it is valid and legitimately issued. All the best: Rich Farmbrough 18:36, 27 October 2026 (UTC).Reply

I just add "Reprint: {{ISBN|}}." outside of the reference template and move the ISBN into it. —DocWatson42 (talk) 21:25, 4 November 2026 (UTC)Reply

We shouldn't need to do that. Wikipedia:Citing sources#Dates and reprints is clear: Date a book that is identically reprinted or printed-on-demand to the first date in which the edition became available. For example, if an edition of a book was first released in 2005 with an identical reprinting in 2007, date it to 2005. Over the last 40+ years I have bought a large number of books, some of which were reprints; and those that I bought new all had ISBNs, but not all had the reprint date. --Redrose64 🌹 (talk) 21:53, 4 November 2026 (UTC)Reply

This edit request to Template:Cite book/doc has been answered. Set the |answered= parameter to no to reactivate your request.

Whenever the surname Nostrand or Van Nostrand is cited, a good and definitive reference is Nostrand, Peter F., Assisted by Harry Macy, Jr., Are You a First Family of New York City, Connect Yourself Through the Nostrand Line from Jamaica, Queens, 1600-1900, Piffin Publishing, 2026, ISBN 979-8-234-15154-4, copyright Peter F. Nostrand, available on Amazon. Search “Nostrand genealogy”. Peterman1001 (talk) 13:24, 18 October 2026 (UTC)Reply

not done. No evidence of an actual problem. A search for Nostrand genealogy returns no results. An insource search likewise returns no results.

—Trappist the monk (talk) 14:39, 18 October 2026 (UTC)Reply

Why would I ever want this parameter? It is so irritating to click on a citation URL, find out it's dead, and then have to hunt down the citation in the article source to remove this parameter so that the archive version takes precedence. Even when the URL is still live, I want to be immediately directed to the stable archival version whenever it is available. Most of the time, the live version has just been filled with more ads and bloated scripts since the time the archival version was made. Einsof (talk) 03:33, 22 October 2026 (UTC)Reply

Just a comment to disagree. When reading articles, I prefer initially to go to the latest URL, though it may have become irrelevant or dead; it also may have useful updated information. Also, unnecessarily opening an archived URL is usually slow, and if many people do it adds stress to the Wayback Machine. If the live version is inappropriate I don't have trouble, now as an editor, to "hunt down" the citation by seeking the author's name or well-chosen title text (a hint for rapid searching: if a title contains "antidisestablishmentarianism pseudoscience", a search for "sm ps" will often work). What is stupid is adding the parameter to an article without an archived version. Best wishes, Pol098 (talk) 10:24, 23 October 2026 (UTC)Reply

In this article 2026 in paleomammalogy, one of the sources has PMID higher than 42900000 (which is 42901525) and it is a legit article. Please update the limit

https://pubmed.ncbi.nlm.nih.gov/42901525/ Lowyat Slyder (talk) 01:11, 24 October 2026 (UTC)Reply

I have encountered a reference with a url-status=usurped and archive-url pointing to archive.today. The reference is displayed unlinked (as it should be with both its url and archive-url pointing to bad places) but the error message, "|access-date= requires |url=", is far from informative about what the real problem here is and stumped me for several minutes before I figured it out. Can we get a better error message for such situations, maybe? —David Eppstein (talk) 06:07, 1 November 2026 (UTC)Reply

in the sandbox:

—Trappist the monk (talk) 19:25, 1 November 2026 (UTC)Reply

Better, thanks! Given the example title, maybe I need to clarify that I am not and never have been an advocate of flat-tax initiatives. —David Eppstein (talk) 22:30, 4 November 2026 (UTC)Reply

I propose to update the cs1|2 module suite over the weekend 7–8 November 2026. Here are the changes:

Module:Citation/CS1:

• ignore invalid character use in third level domain names; discussion
• don't emit error when a parameter has <templatestyles />; discussion
• {{cite mailing list}}: don't ignore |periodical= without |mailing-list=; no discussion
• {{cite encyclopedia}}, {{cite episode}}: URL–wikilink conflict; no discussion
• improve handling script-params; no discussion
• track ignored |page= and |article-number=; no discussion
• {{cite conference}}, {{cite episode}}, {{cite map}}: emit error for ignored chapter; no discussion
• {{cite map}}: redundant |section= and |sections=; no discussion
• emit error message when |url-status=usurped/unfit and |archive-url=<archive.today>; discussion
• make |date= and |publication-date= exact aliases; discussion
• make |location=, |place=, and |publication-place= exact aliases; discussion

Module:Citation/CS1/Configuration:

• removed 10.1002/wsb (Wildlife Society Bulletin), only free since 2023; no discussion
• added many free doi registrants; no discussion
• update emoji_t to unicode v18.0.0; no discussion
• update bibcode url components; discussion
• make |date= and |publication-date= exact aliases
• make |location=, |place=, and |publication-place= exact aliases

Module:Citation/CS1/COinS:

• don't emit error when a parameter has <templatestyles />; decode HTML entities; discussion

—Trappist the monk (talk) 00:12, 2 November 2026 (UTC)Reply

As noted above, I have made a few changes without prior discussion. You can review the test cases at Special:Permalink/1383357653. Please feel free to revert them if they are not needed. FlatLanguage (talk) 07:50, 2 November 2026 (UTC)Reply

In future, please don't make changes to the cs1|2 module suite without discussion here.

Looking at your testcases page, there are many tests that present apparently identical results. That suggests that whatever change is being tested is unnecessary or does not work. There is no explanatory text to describe the purpose of the tested changes. What are each of those tests demonstrating?

—Trappist the monk (talk) 14:13, 2 November 2026 (UTC)Reply

I added header: Special:Permalink/1383427839 --FlatLanguage (talk) 16:58, 2 November 2026 (UTC)Reply

Adding properties categories for ignored |article-number= and for |at=, |page=, and the other insource-locator parameters is inconsistent with how cs1|2 handles ignored parameters. I have changed the sandbox so that cs1|2 emits the standard Unknown parameter error message when these parameters are ignored.

—Trappist the monk (talk) 23:23, 2 November 2026 (UTC)Reply

Posted at the Village Pump. I don't know if this has resulted in any additional feedback, but several editors requested the CS1/CS2 updates to be advertised there, so I've been doing so. Rjjⁱⁱⁱ (talk) 21:31, 4 November 2026 (UTC)Reply

I'd like to add to the chorus of disagreement with merging |date= and |publication-date=. These are often different values on newspaper articles with datelines. What's the rationale for removing the option to include both? Nick Number (talk) 00:24, 8 November 2026 (UTC)Reply

Do you have an example? Headbomb {t · c · p · b} 00:59, 8 November 2026 (UTC)Reply

Here is an example of a wire service story containing the original dateline date and location. In this case it was also published on the same date, Nov. 18, in the local newspaper. But often the paper would publish the newswire story the next day or next week, keeping the original dateline date to indicate this vital citation information. PK-WIKI (talk) 05:58, 11 November 2026 (UTC)Reply

Major published style guides (APA, Chicago, MLA, and so on) use either the publication date, or if that is not available the access date. Are there any that cite the dateline? For CS1, I also feel confused on how you'd handle the location doing this; does the citation include the location as Knoxville (newspaper's location, and how I think most would cite it), or Chicago (from the dateline), or something else or nothing? Rjjⁱⁱⁱ (talk) 06:17, 11 November 2026 (UTC)Reply

I generally include both locations via |place= and |publication-place=, which is also now a red error due to this recent change. PK-WIKI (talk) 06:24, 11 November 2026 (UTC)Reply

Here is another example which contains different values for date, publication-date, place, and publication-place:

• The dateline shows 1915-12-17
• The news article was published 1915-12-18
• The dateline shows New York
• The newspaper is published in Raleigh, North Carolina, and the place is not part of its name

This is all valid information, yet Cite news currently shows two errors for duplicated values. It was all handled correctly before the latest change. Nick Number (talk) 15:43, 11 November 2026 (UTC)Reply

This is a big change to make with so little feedback. Did you check to see how many articles used both parameters? The template previously said that both |date and |publication-date, and |location and |publication-place, were relevant and had different meetings. --Golbez (talk) 21:27, 7 November 2026 (UTC)Reply

Or whatever, I can remove them. But it's annoying to have followed the documentation then have not only the documentation changed, but an error message all over my articles. PLease try to do better. --Golbez (talk) 22:05, 7 November 2026 (UTC)Reply

@Golbez: Counts are in the linked discussion above. Rjjⁱⁱⁱ (talk) 22:19, 7 November 2026 (UTC)Reply

fair. Still, is it possible to have edit warnings but not have it show up in the template? Give us a chance to clean it up before splotching red error text all over the sources. --Golbez (talk) 22:29, 7 November 2026 (UTC)Reply

Things that aren't known about don't get fixed. This case will be easy enough for a bot to correct. Izno (talk) 00:55, 8 November 2026 (UTC)Reply

And since I just apologized to Trappist, I'll do the same here. I saw a bunch of red text and thought it was a random change, then everything I asked was right there in black and white, so yep, I can't fault anything, this was discussed and tested and counted. :) I'll adjust. T'aint no thang. --02:42, 8 November 2026 (UTC) Golbez (talk) 02:42, 8 November 2026 (UTC)Reply

This change has caused a large number of red errors at College football national championships in NCAA Division I FBS and other articles where |place= and |publication-place= were both used in citations. This style is VERY COMMON in newspaper articles from a wire service that contain a dateline.
The location of the reporter/event is independent from the publication place of the newsprint.
Please revert this change or otherwise enable display of either/both the dateline and printing locations. (The previous implementation was not great; to set the dateline location you were required to also set the publishing location.) PK-WIKI (talk) 05:40, 11 November 2026 (UTC)Reply

Dateline is bibliographically irrelevant. Headbomb {t · c · p · b} 09:58, 11 November 2026 (UTC)Reply

There appears to be a fair amount of disagreement on that point. I'd suggest that the template change be rolled back until consensus is reached. Nick Number (talk) 15:57, 11 November 2026 (UTC)Reply

Template:Citation § COinS metadata is created for these parameters lists |book-title= as an alias of |title=, but {{cite book}} does not recognise this parameter. Does this parameter actually (still) exist, or is the documentation outdated? – Scyrme (talk/solidarity) 20:29, 5 November 2026 (UTC)Reply

Template:Citation § COinS metadata is created for these parameters is not list of aliases. |book-title= is unique to {{cite conference}} and still exists and still contributes to the citation's COinS metadata:

{{cite conference |title=Paper title |book-title=Proceedings title}}

{{#parsoidfragment:85}}<cite class="citation conference cs1">"Paper title". ''Proceedings title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.atitle=Paper+title&rft.btitle=Proceedings+title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

"Paper title". Proceedings title.

—Trappist the monk (talk) 22:27, 5 November 2026 (UTC)Reply

Good to know. Thanks for the correction! – Scyrme (talk/solidarity) 23:59, 5 November 2026 (UTC)Reply

Have I lost the plot, or is |agency= no longer displaying in this version (specifically impacting the citations in this revision)? Izno (talk) 00:54, 8 November 2026 (UTC)Reply

Fixed, I think; this from 2020s:

{{cite news/new |last=Carl |first=Traci |date=10 March 2009 |title=Progress in Mexico drug war is drenched in blood |url=https://www.google.com/hostednews/ap/article/ALeqM5ilIZ5du3hOOeN7yatYIRIhFY-MJAD96RBGO00 |archive-url=https://web.archive.org/web/20090315080309/https://www.google.com/hostednews/ap/article/ALeqM5ilIZ5du3hOOeN7yatYIRIhFY-MJAD96RBGO00 |archive-date=15 March 2009 |access-date=1 April 2009 |agency=Associated Press}}

Carl, Traci (10 March 2009). "Progress in Mexico drug war is drenched in blood". Associated Press. Archived from the original on 15 March 2009. Retrieved 1 April 2009.

—Trappist the monk (talk) 01:35, 8 November 2026 (UTC)Reply

Setting the |language= parameter in a cite template does not currently tag the |title= or |quote= parameters with that language in the way required by MOS:LANG, right? I'd like to suggest that it should, to save the need for {{lang}} templates within refs. Helpful Cat🐈 18:43, 8 November 2026 (UTC)Reply

@Helpful Cat: It's not that simple. Firstly. |language= is designed to take multiple languages as some sources are multilingual.

Secondly, it can't be assumed that the title isn't in English just because the source itself is non-English. The editor may have provided an English title instead of using |trans-title=. The title may be a descriptive title for a webpage that has no heading ("Data from..."). The source might be untitled with |title=[untitled] being set per the advice at Template:Title missing § How to fix the problem flagged by this template. I also vaguely recall having seen sources where the title actually is in English but the article itself isn't, though unfortunately I can't recall where I saw this so can't drop a link. The title also may not be in a single language (it may include loanwords or quotes) so tagging the whole thing in one language may be incorrect (eg. "Box Office: 'हनुमान अंश' ने 66वें दिन...").

Additionally, as far as I know, templates, including {{lang}}, should not be used in |title= (or in other parameters like |journal=. |publisher=, etc.). See Template:Citation § COinS: "Use of templates within the citation template is discouraged" (exceptions being for things like {{SfnRef}} for |ref=, and, as far as I know, it's fine to use {{lang}} in |quote=). – Scyrme (talk/solidarity) 19:15, 8 November 2026 (UTC)Reply

I see, thanks for the explanation. Regarding COinS, does adding |cat=no or |nocat=yes not allow {{lang}} to be used in |title= and other citation parameters without polluting COinS? {{lang}}'s documentation says To suppress this – e.g. when using {{lang}} within a wikilink or the title parameter of a citation – add the parameter |cat=no.

I also just saw that {{lang}} was recently removed from Category:Templates not safe for use in citation templates with a link to this discussion, in which editors disagreed with the need to avoid templates to preserve COinS. Even if the |nocat=yes fix doesn't work, if there is a tradeoff between COinS and screen reader accessibility for human readers, shouldn't the latter take priority? Thanks. Helpful Cat🐈 07:56, 9 November 2026 (UTC)Reply

As far as I know |cat=no makes no difference since the problem is that also inserts HTML not just a category. The initiator of that discussion you linked seemed to think this could be overcome, but it's not clear from that discussion if the proposed "rules" were ever implemented.

I feel like that discussion should probably have been an RfC to get a sitewide consensus, or followed up by an RfC to see if there's broad agreement with the views expressed there. If answer really is "we should not care about COinS metadata anymore" then maybe Category:Templates not safe for use in citation templates should be empty given the only criterion for inclusion listed is pollution of the metadata. If we don't mind polluting the metadata, the template documentation also needs to be updated. Probably some guidelines too. Allowing templates in citations also means that in some cases doing so will be de facto encouraged, since guidelines like MOS:LANG will now be seen to apply. – Scyrme (talk/solidarity) 12:51, 9 November 2026 (UTC)Reply

An RfC is a good idea, I'll think about how to phrase one. Another possible outcome is that we still care about COinS, but might agree that in some circumstances, other considerations should take priority (e.g. screen reader accessibility in the case of MOS:LANG). It would definitely be good to get the consensus of the community. Helpful Cat🐈 14:54, 9 November 2026 (UTC)Reply

@Andrybak has just said here that the |language=, |script-title= and |script-quote= parameters in citation templates already mark text for screen readers in the way MOS:LANG requires. In that case, {{lang}} templates within citation templates are not necessary for MOS:LANG after all (except in the specific cases described by Scyrme above)! Helpful Cat🐈 15:06, 9 November 2026 (UTC)Reply

I think that you will find that Editor Andrybak is a bit mistook. Yes, cs1|2 does support |language=, |script-title=, and various other |script-...= parameters. But, |language= is just a visual indication that the source is written in one or more non-English languages; it modifies nothing. The |script-...= parameters are constrained to a limited set of languages that are written using non-Latin scripts so writing summat like this:

{{cite book |script-title=de:Bundesrepublik Deutschland |trans-title=Federal Republic of Germany}}

causes cs1|2 to emit an error message:

Bundesrepublik Deutschland [Federal Republic of Germany]. {{cite book}}: Invalid |script-title=: unknown language code (help)

Still, even with the error message, the |script-...= parameters do cause cs1|2 to add some html markup that includes the lang= attribute:

{{#parsoidfragment:109}}<cite class="citation book cs1"> <bdi lang="de" >Bundesrepublik Deutschland</bdi> &#91;''Federal Republic of Germany''&#93;.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Bundesrepublik+Deutschland&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Invalid <code class="cs1-code">&#124;script-title=</code>: unknown language code ([[Help:CS1 errors#script_parameter|help]])</span>

—Trappist the monk (talk) 15:30, 9 November 2026 (UTC)Reply

A |title-lang= has been a longtime feature request (e.g. at the little-used subpage for it). It seems simple, but I am not really convinced of its general utility in our context (vice use in the context of |script-...=). Izno (talk) 19:46, 9 November 2026 (UTC)Reply

That discussion links to further discussion here; long-since archived at Help talk:Citation Style 1/Archive 11 § Language. No resolution there.

I've been wondering if we might not create a title-holding parameter that looks and acts much like |script-title= where the first characters assigned to the parameter are the language tag followed by a colon and then the non-English title. Perhaps summat like this:

{{cite book |special-title=de:Bundesrepublik Deutschland |trans-title=Federal Republic of Germany}}

where |special-title= is a place-holder name until I or someone else can find a better name. Whatever the name, |special-title= and |title= are mutually exclusive which if used at the same time would cause cs1|2 to emit a more than one of |title= and |special-title= error message.

Perhaps we reject |special-title= with a language tag that matches the local language and we reject any language tag that isn't known to MediaWiki. Of course, MediaWiki has language tags that aren't valid IETF language tags so we'd have to trap those. Regardless, |special-title= would cause cs1|2 to wrap the 'title' in <bdi>...</bdi> tags with the associated lang= attribute just as |script-title= does now.

For book citations, |special-title= would render its assigned value in italics. No doubt, editors will confuse |special-title= with |script-title= so a title written using Arab, Cyrl, Hebr, Jpan, etc script would be improperly italicized...

Better ideas solicited.

—Trappist the monk (talk) 22:44, 9 November 2026 (UTC)Reply

Could somebody deal with this category properly? Thanks. * Pppery * _{it has begun...} 22:56, 8 November 2026 (UTC)Reply

Empty and marked for speedy deletion. The category is misnamed. The error message:

Error: nl-be and Flemish are not a supported pair found at Template:Citation Style documentation/language/doc

{{CS1 language sources}} parses the category title into a language name (Flemish) and a language tag (nl-be). It then looks in Template:Citation Style documentation/language/doc for a language / name pair that agree with the category title. Not finding a match, we get the error message.

cs1|2 uses the language tags and names known to MediaWiki. For nl-be MediaWiki returns:

{{#language:nl-be|en}} → Belgian Dutch

which is not Flemish.

So, nothing to do except wait for the speedy deletor.

—Trappist the monk (talk) 01:25, 9 November 2026 (UTC)Reply

Flemish is part of Belgian Dutch, and its code is nl-be. See Flemish. Headbomb {t · c · p · b} 15:55, 9 November 2026 (UTC)Reply

(edit conflict) Er, see Flemish language - Belgian Dutch is Flemish. --Redrose64 🌹 (talk) 15:57, 9 November 2026 (UTC)Reply

Umm, I did not say that the 'Flemish language' is not the same as the 'Belgian Dutch language'; I have no opinion on whether those two languages are the same language. I did say that cs1|2 gets its language names from MediaWiki which does not define nl-be as 'Flemish'. So for that sense, 'Flemish' (the name) ≠ 'Belgian Dutch' (the name).

It turns out that MediaWiki has, in the past, defined nl-be as 'Flemish'. Sometime between archive.org snapshots 2026-09-10T06:24:07 and 2026-09-15T23-02-47, MediaWiki changed the definition of nl-be from 'Flemish' to 'Belgian Dutch' (Phab:T357351). During that same time they added:

• vgt: Flemish Sign Language (phab:T434343)
• vls-be: Belgian Flemish (phab:T418789)
• vls-fr: French Flemish
• vls-nl: Dutch Flemish

MediaWiki aren't obliged to tell us when they change stuff so the (at the time correct) category name Category:CS1 Flemish-language sources (nl-be) became instantly obsolete and was abandoned when cs1|2 started populating Category:CS1 Belgian Dutch-language sources (nl-be). The switchover probably occurred 2026-09-10 because that is when AnomieBot created the Belgian Dutch category.

—Trappist the monk (talk) 18:59, 9 November 2026 (UTC)Reply

[Moved from Template talk:Cite Q#Manual override of publication-date= with disambiguation letter strips the letter; discsussion was about entering values like |publication-date=2021a.]

Is 2021a a valid date? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 21:05, 10 November 2026 (UTC)Reply

Yes. Commonly used with {{sfn}} etc to disambiguate multiple sources by the same author in the same year; see Template:Sfn § More than one work in a year.

—Trappist the monk (talk) 00:06, 11 November 2026 (UTC)Reply

As an example for where it's used, see Lampi (2012a) through Lampi (2012i). Headbomb {t · c · p · b} 00:21, 11 November 2026 (UTC)Reply

I know it's used; it is certainly not valid as an ISO 8601 date (the example on the linked page, 9 November 2013b is even worse). Why, I wonder, isn't the appended letter held as a value in a separate parameter? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 11:27, 11 November 2026 (UTC)Reply

At more than 200 (not counting enumerated variants), doesn't cs1|2 have enough parameters? It seems that you just-don't-like-it when you say that 9 November 2013b is even worse. Not much of an argument, that.

If memory serves, we chose to append the disambiguation character to the year portion of the publication date (when possible) for technical reasons (javascript or css? I forget); also because some readers print off copies of an article so appending the disambiguation character does no harm and aids those who need it. Mayhaps, these days, en.wiki can't be read without javascript and no doubt, fewer readers are making paper copies of articles.

If you wish to change this behavior, Help talk:Citation Style 1 is the proper venue.

—Trappist the monk (talk) 14:50, 11 November 2026 (UTC)Reply

I don't like it; for good reason. There is no "just" to that.

Arguably, for n>200, having n+1 properties is proportionally little more trouble than n.

Are any of the other 200+ used to smash together two distinct pieces of data in this manner? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 15:15, 11 November 2026 (UTC)Reply

Style guides with name date inline citations (like APA and Harvard) have long used the letters appended to years. Rjjⁱⁱⁱ (talk) 15:22, 11 November 2026 (UTC)Reply

They are style guides, not database guides; they are concerend with how we display, not record, data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 15:37, 11 November 2026 (UTC)Reply

Wikidata is free to record data however it wants. It's completely immaterial to what citation templates should display. Headbomb {t · c · p · b} 15:40, 11 November 2026 (UTC)Reply

Who mentioned Wikidata? Who said anything about what any template displays? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 15:43, 11 November 2026 (UTC)Reply

I don't like it; for good reason. There is no "just" to that. State the good reason.

—Trappist the monk (talk) 15:28, 11 November 2026 (UTC)Reply

Smashing together two distinct pieces of data in a single field in this manner is bad practice.

Asking people using form-based citation tools to enter two distinct pieces of data in a single form field is likely to confuse them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 15:39, 11 November 2026 (UTC)Reply

Who cares that it's a valid ISO arcsin(Γ(-1/5)) date. It's a valid date in a reference section. Headbomb {t · c · p · b} 15:39, 11 November 2026 (UTC)Reply

It's a normal and standard way to disambiguate dates in short citations. -- LCU ActivelyDisinterested «@» °∆t° 15:47, 11 November 2026 (UTC)Reply

The question is not about how we do things in (displayed) citations, but about how we do data entry in citation tools and forms. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 15:49, 11 November 2026 (UTC)Reply

I can understand that but the date is valid, which was the original question. You'll find it's use outside of Wikipedia as well. It should be that the only people using it are doing so deliberately, so I don't see why it would confuse them. -- LCU ActivelyDisinterested «@» °∆t° 15:53, 11 November 2026 (UTC)Reply

The people adding it may be doing so deliberately, but I'm confident that:

|date=9 November 2013b

which looks like a typo, would be more likely to be "corrected" by a well-meaning naive editor than, say:

|date=9 November 2013

|sequencer=b

or whatever might be the appropriate parameter name.

I'm not seeing an argument that using a single parameter has any advantages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 16:34, 11 November 2026 (UTC)Reply

This overly complicates something that already works and confuses no one. Headbomb {t · c · p · b} 16:49, 11 November 2026 (UTC)Reply

That would confuse all the people who expect to be able to disambiguate dates per the standard for short form cites. I have seen it incorrected corrected as a typo a few times (I've corrected thousands of no target errors), but it's definitely minority of such issues. -- LCU ActivelyDisinterested «@» °∆t° 19:07, 11 November 2026 (UTC)Reply

A lot of people find converting references into Wikipedia's template formats confusing. This would not help. It's not at all intuitive that if a new editor had a text citation in Harvard or APA style with a disambiguated year that, when copying it over to Wikipedia, they would need to separate the letters and numbers into two parameters, or what they would call the parameter used for the letter. A new editor without prior knowledge won't already know what we call the parameter without looking it up in the documentation, whereas a new editor without prior knowledge can easily guess that |date= or |year= will work. – Scyrme (talk/solidarity) 23:37, 11 November 2026 (UTC)Reply