Help talk:Citation Style 1/Archive 84

Citation span tags
Ive noticed that when a citation error is produced (E.g. ), the resulting html has the error split across 2 or more s, as seen below (Ive split the 2 spans wih a newline). : Missing or empty   (help) However, when a maintenance notice is produced (E.g. ), the resulting html is always across 1 entire, as seen below : CS1 maint: date and year (link) Ive also noticed the function for adding errors in the module /Utilities is significantly more advanced than for adding maintenance messages. Is there at all any reason for this? Id assume it would be easier for both to be across 1 entire span, as the same class is used throughout, but there might be some underlying reason im not aware of. Aidan9382 (talk) 06:18, 17 May 2022 (UTC)
 * Maintenance messages are always default hidden. Most error messages are visible but some are default hidden.  Error messages are always emitted, hidden or not.  For example,  requires journal so when that parameter is empty of omitted, cs1|2 emits an appropriate error message.  But, due to en.wiki politics, that error message is hidden:
 * : Cite journal requires  (help) ; Check date values in:   (help)
 * User css can override the  class.
 * —Trappist the monk (talk) 13:21, 17 May 2022 (UTC)
 * Can you point to the discussion where this was decided? I don't remember it. Omitting the source from a citation is not trivial. 50.75.226.250 (talk) 14:38, 17 May 2022 (UTC)
 * I meant the decision to hide work-missing errors. 50.75.226.250 (talk) 14:41, 17 May 2022 (UTC)
 * This update:
 * spawned this drama:
 * —Trappist the monk (talk) 15:53, 17 May 2022 (UTC)
 * The complaint there was about cite web requiring website and cite news requiring newspaper, both of which were subsequently reverted. No-one objected to cite journal requiring journal. Kanguole 16:09, 17 May 2022 (UTC)
 * That and the deprecated dead-url error messages were the biggest parts of the complaints, sure. But there was a vocal crowd advocating a complete reversion of the 3 September 2020 update.  To forstal that, I disabled missing-news and missing-website tests and hid deprecated and missing-periodical (journal, magazine) error messaging.  We did not have to revert the whole damn thing but as a result, missing periodical error messages are still hidden.
 * And this is all that I am going to say on this sub-topic.
 * —Trappist the monk (talk) 16:47, 17 May 2022 (UTC)
 * Thanks for digging up some of these discussions, I forgot I had actually participated. Sordid re-reading... On a personal note, I do not think that Wikipedia will ever produce proper citation system(s) for its readers. Nobody is asking them, or even bothers to educate them to the fact that they must verify everything they read in article space. The problem is not Wikipedia per se. In general imo, article/story writers rarely make good article/story editors, and neither make good designers of either the presentation or its technical aspects. A different approach may be needed here. 65.88.88.57 (talk) 17:59, 17 May 2022 (UTC)
 * That and the deprecated dead-url error messages were the biggest parts of the complaints, sure. But there was a vocal crowd advocating a complete reversion of the 3 September 2020 update.  To forstal that, I disabled missing-news and missing-website tests and hid deprecated and missing-periodical (journal, magazine) error messaging.  We did not have to revert the whole damn thing but as a result, missing periodical error messages are still hidden.
 * And this is all that I am going to say on this sub-topic.
 * —Trappist the monk (talk) 16:47, 17 May 2022 (UTC)
 * Thanks for digging up some of these discussions, I forgot I had actually participated. Sordid re-reading... On a personal note, I do not think that Wikipedia will ever produce proper citation system(s) for its readers. Nobody is asking them, or even bothers to educate them to the fact that they must verify everything they read in article space. The problem is not Wikipedia per se. In general imo, article/story writers rarely make good article/story editors, and neither make good designers of either the presentation or its technical aspects. A different approach may be needed here. 65.88.88.57 (talk) 17:59, 17 May 2022 (UTC)
 * Thanks for digging up some of these discussions, I forgot I had actually participated. Sordid re-reading... On a personal note, I do not think that Wikipedia will ever produce proper citation system(s) for its readers. Nobody is asking them, or even bothers to educate them to the fact that they must verify everything they read in article space. The problem is not Wikipedia per se. In general imo, article/story writers rarely make good article/story editors, and neither make good designers of either the presentation or its technical aspects. A different approach may be needed here. 65.88.88.57 (talk) 17:59, 17 May 2022 (UTC)

This conversation above has actually made me notice what could be a bug. Due to the way ive got my css setup, not only are all errors shown, but i have seperate background highlighting for each, and I noticed the  in the journal example was unhighlighted, and therefore not inside any span tags. I checked with default css (AKA not being able to see the hidden error), and yep, to other people theres just a magically appearing semicolon in the citation error output. Aidan9382 (talk) 16:33, 17 May 2022 (UTC)
 * Yeah, that semicolon is there. It's there to separate items in a list of error messages.  Could be removed or some code could be written to move the semicolon into the spans, I suppose, but the better solution, from the editor point of view, is to fix the cause of the error messages – then no stray semicolons...
 * —Trappist the monk (talk) 17:13, 17 May 2022 (UTC)

Add S2CID to TemplateData
I'm using ProveIt and I recently started to add S2CID to my references, but it is not showing in ProveIt by default because it is not in the TemplateData, and it would be nice to have it there. Could someone do this? Thanks! − Arthurfragoso (talk) 15:35, 21 May 2022 (UTC)

Request to remove Help talk from Category:CS1 maint: unrecognized language
Could someone please remove the Help talk space from Category:CS1 maint: unrecognized language, so Help talk:Citation Style 1/Archive 79 isn't part of the category? Thanks! GoingBatty (talk) 03:28, 24 May 2022 (UTC)
 * cs1|2 does not categorize the Help talk namespace (see lines 10–12 in Module:Citation/CS1/Configuration). Likely the issue is a bare category link somewhere in one or more of the discussions in the archived page.  Find that link and fix it.
 * —Trappist the monk (talk) 13:33, 24 May 2022 (UTC)
 * with this edit. An editor tried to link to a category but forgot a colon. – Jonesey95 (talk) 17:40, 24 May 2022 (UTC)

CS1 maint: others in cite AV media (notes)

 * moved from Category talk:CS1 maint: others in cite AV media (notes); now a redirect —Trappist the monk (talk) 12:32, 24 May 2022 (UTC)

This maintenance note seems contrary to the examples listed in Template:Cite AV media notes. This maintenance note states "others is provided to record (secondary) contributors to the cited source.", but per <> |date=2022 |url=h t t p ://www.wikipedia.org |page=1|type=Type |publisher=Publisher |id=Publisher ID |location=Location>>, others is to be used to list Artist. So when citing CD liners, the album title gets listed under title, but there is no other method for listing artist except for others, which complies with AV media notes guidelines. This CS1 maintenance seems to be the one in error. Mburrell (talk) 04:16, 24 May 2022 (UTC)
 * The obvious solution is to add the author of the notes, or "Anon." if not stated. -- Michael Bednarek (talk) 13:06, 24 May 2022 (UTC)
 * I think the obvious solution is to add an additional field to AV Media (notes) for artist. Mburrell (talk) 16:31, 24 May 2022 (UTC)
 * It should also be obvious to anyone who tries to verify a cite av media notes citation that it is much harder to find the source by the author of the notes than it is by the related artist. AV sources are rarely classified by notes authors.


 * I don't remember why there is a separate template for notes. They are as tightly integrated with the AV work as a foreword to a book. This template can easily be replaced with Media notes or "Media notes title" and Authorname, added to template cite av media. 24.105.140.106 (talk) 18:26, 24 May 2022 (UTC)
 * This maintenance category used to be part of Category:CS1 maint: others but was split out because we don't know the best way to deal with them. See the instituting discussion as well as a more recent discussion as well as this older discussion and this older discussion. Izno (talk) 18:33, 24 May 2022 (UTC)

False positive on bibcode:2019ISPAr42W19..207
This says there's an error in the bibcode There isn't, it's a valid one. One of the tests needs to be adjusted. &#32; Headbomb {t · c · p · b} 03:55, 24 May 2022 (UTC)
 * Same for bibcode = &#32; Headbomb {t · c · p · b} 03:56, 24 May 2022 (UTC)
 * I see whats gone wrong here. According to the official rules here, the last character should be The first letter of the last name of the first author, but somehow its a 7. The regex that confirms if this is valid was only expecting for a letter or dot for this reason. Im not sure if this is a misissuing or what, but for now, ill simply change the regex a bit. If someone who works on citations a lot could follow up on this, that'd be nice. Aidan9382 (talk) 04:36, 24 May 2022 (UTC)
 * I've fixed it as much as i can, but I can only fix the direct bibcode one, and not the citation one. I guess just use that for now until someone else comes along and gives hopefully more of an insight. Aidan9382 (talk) 04:40, 24 May 2022 (UTC)
 * Hhmmm... If the test that's failed is the final character needing to be a letter... we might be better off having an exception for the article than a change to the rule. &#32; Headbomb {t · c · p · b} 04:51, 24 May 2022 (UTC)

The double doesn't seem to do anything though. &#32; Headbomb {t · c · p · b} 04:53, 24 May 2022 (UTC)
 * The markup (Accept as written markup) has to be defined explicitely for values as far as im concerned, and its not just available to supress all errors. Ill see if i can add it to check_bibcode, but actual citations will need more input. Also yeah, maybe adding an exception was a better idea, my mistake! Aidan9382 (talk) 04:57, 24 May 2022 (UTC)
 * Ok im not gonna implement that. Looking at the solo implementation of elements that use the AAW markup (like ISBN) shows that its actually a feature of Citations/CS1's implementation only. I think you'll just have to let the error sit there until a potential fix comes along. Im not totally opposed to implementing an AAW addition for the solo if really needed, im just worried about going against common practice on something as major as citations. Aidan9382 (talk) 05:02, 24 May 2022 (UTC)
 * Have you notified the bibcode people about this? If the rule has changed, they should document the rule change; if the rule has not change and the bibcode is malformed they should assign a proper bibcode to that source (they can keep the malformed bibcode as a redirect).
 * —Trappist the monk (talk) 13:38, 24 May 2022 (UTC)
 * Ill go ahead and notify them about it. Ill post any eventful updates (E.g. if its changed) here. Aidan9382 (talk) 13:44, 24 May 2022 (UTC)
 * Ill go ahead and notify them about it. Ill post any eventful updates (E.g. if its changed) here. Aidan9382 (talk) 13:44, 24 May 2022 (UTC)

Got a response back, it was a misissuing. It's been fixed, but its not gonna update on the database until friday. The new bibcode will end up being. I'm telling you now since I'll end up forgetting if i don't. Aidan9382 (talk) 19:02, 25 May 2022 (UTC)

CS1 errors: dates
Hello, wondered if anyone knows what has happened to category:CS1 errors: dates which has gone up by over 100 entries. New ones in the category do not show an entry in the hidden categories on the page. It could be that some template was changed and the jobqueue is still processing them. Keith D (talk) 17:11, 25 May 2022 (UTC)


 * could you link some of the new ones? Aidan9382 (talk) 17:31, 25 May 2022 (UTC)
 * Since they all seem to be music-related, I'm guessing that this template change fixed a temporary problem that was causing a bunch of date errors, and now the job queue is removing the affected articles from the category. – Jonesey95 (talk) 17:51, 25 May 2022 (UTC)
 * Thanks, it looks like it is slowly returning to the previous level. Keith D (talk) 20:11, 25 May 2022 (UTC)
 * The category seems to be stable at 5,820 pages right now. I am very impressed by the steady progress that editors have made in reducing the number of pages in this category. I know that beyond a certain point of easy fixes, correcting each error requires actual manual work to determine and implement the right change. Nice work. – Jonesey95 (talk) 21:27, 25 May 2022 (UTC)

URL access restriction for non-accessible sources
The instructions don't seem to say what to put for url-access for something that is simply not accessible to the public at all – e.g., a document that may exist but is internal to an institution. For example, Utah Tech University has a citation to this, something that appears to only be accessible to employees and/or students of the university. The meaning of the "limited" value seems to be that it is still possible, within some limits, "to freely access this source". But "subscription" is not accurate either, since it is not possible to obtain "a paid subscription with the provider". The limit is more formidable than a "paywall". —⁠ ⁠BarrelProof (talk) 02:23, 30 May 2022 (UTC)


 * @BarrelProof - Per Template:Cite_web, I suggest registration. Happy editing! GoingBatty (talk) 04:16, 30 May 2022 (UTC)
 * I disagree. The url takes the reader to a login page that wants a 'Digital ID@utahtech.edu' identifier.  That implies that those who have the requisite IDs are faculty, staff, or students at Utah Tech University.  When rendered, registration tells cs1|2 templates to emit a tool tip that says: 'Free registration required'.  There is no indication at the sign-in page how to get a 'free registration'.
 * I have fixed the citation template. I also deleted the archive-url because an archived copy of a sign-in page is more-or-less pointless
 * —Trappist the monk (talk) 14:38, 30 May 2022 (UTC)
 * Agree with Trappist, but personally would take it further, because as noted, there is no publicly available subscription. Is that school's "Faculty Termination Policy" non-public? If so, citing it in Wikipedia may not be acceptable, and technically may violate CS1 guideline that sources be published (i.e. available to the general public). I would try to find other, public sources to support the wikitext. The restriction should include archives of non-public sources when they actually provide the content. Bad form. 68.173.78.83 (talk) 16:56, 30 May 2022 (UTC)
 * Agree with Trappist, but personally would take it further, because as noted, there is no publicly available subscription. Is that school's "Faculty Termination Policy" non-public? If so, citing it in Wikipedia may not be acceptable, and technically may violate CS1 guideline that sources be published (i.e. available to the general public). I would try to find other, public sources to support the wikitext. The restriction should include archives of non-public sources when they actually provide the content. Bad form. 68.173.78.83 (talk) 16:56, 30 May 2022 (UTC)

Linking to commercial publishers: Exception?
The page currently reads: "Do not link to: [...] Commercial sites such as Amazon, unless no alternative exists."

Would it be alright to add an exception clause for open access books, often which are available on commercial sites?

See e.g. [here https://global.oup.com/academic/open-access/titles/?cc=jp&lang=en&].

Even if this is stated or implied elswhere on the page (I didn't see it if it is, sorry), it'd be good to add a short clarification clause where the page talks about linking to commerical sites. Cameron.coombe (talk) 00:01, 5 June 2022 (UTC)


 * The reasoning behind the commercial link warning is that Wikipedia should not be used as a marketing or sales tool. However open access sources are free, and I would think it obvious they would be allowed irrespective of the platform. I would support such clarification, if one is needed. I don't think there is a problem with citations linking to the site in your example.
 * As an aside, I sometimes archive live webpages on sales sites such as online stores, and then cite the archive only, so a sale cannot be done from the link. Make sure that the archive is a true screenshot with all links/scripts disabled. 68.132.154.35 (talk) 16:32, 5 June 2022 (UTC)

DOI question
I've had this problem before and anyone I have asked seems to know of no solution. I posted a query to the help desk to see if more eyes than my circle of editing people could find a solution and they referred me here. We have url and chapter-url, but as far as I can tell, there is no similar way to mark the doi and chapter-doi. And, yes, I know that it isn't required to have a link, but if you are preparing a GA or FA, its good to have them in the article for a review, besides which, as the writer, I may go back and recheck a ref. The case I am working on right now is book and chapter. The url links can't be used as they are proxied. (I am definitely challenged by wikitechnology, so I need step by step instructions that are easy to follow.) Thanks to anyone who might be able to help or offer a solution. SusunW (talk) 13:09, 11 June 2022 (UTC)
 * I understand that for citations you only need to provide the DOI numbers. It's up to readers to work out how to access the text. In your case, works for the chapter, and  for the book. -- Michael Bednarek (talk) 13:29, 11 June 2022 (UTC)
 * PS: If you're citing the chapter, simply use the chapter DOI and omit the book DOI. The ISBN is enough to identify the book. -- Michael Bednarek (talk) 13:34, 11 June 2022 (UTC)
 * Please don't include urls that have  subdomains in live articles; no reader can follow that url to its destination and I would suspect that most editors do not have privilege of the wikipedialibrary.  I've been seeing more of those urls recently.
 * This question is about this?:
 * No identifier used in cs1|2 template has separate work/subsection forms. Generally it is not necessary to supply the doi of the work if you are providing the doi of a subsection.  For example, it is easy to get to the work from the chapter's  landing page which has multiple links to the States of Liberation landing page.
 * If you, you can add the work's doi this way: id:
 * —Trappist the monk (talk) 13:44, 11 June 2022 (UTC)
 * Thank you, Trappist the monk! That answers my question. For the life of me, I cannot understand why wikitechnology is not intuitive and requires so many hoops to be jumped through. I truly appreciate your help. And yes, I know not to use the proxied link, but the only way to give the example was to use it. SusunW (talk) 14:21, 11 June 2022 (UTC)
 * If you, you can add the work's doi this way: id:
 * —Trappist the monk (talk) 13:44, 11 June 2022 (UTC)
 * Thank you, Trappist the monk! That answers my question. For the life of me, I cannot understand why wikitechnology is not intuitive and requires so many hoops to be jumped through. I truly appreciate your help. And yes, I know not to use the proxied link, but the only way to give the example was to use it. SusunW (talk) 14:21, 11 June 2022 (UTC)
 * —Trappist the monk (talk) 13:44, 11 June 2022 (UTC)
 * Thank you, Trappist the monk! That answers my question. For the life of me, I cannot understand why wikitechnology is not intuitive and requires so many hoops to be jumped through. I truly appreciate your help. And yes, I know not to use the proxied link, but the only way to give the example was to use it. SusunW (talk) 14:21, 11 June 2022 (UTC)
 * Thank you, Trappist the monk! That answers my question. For the life of me, I cannot understand why wikitechnology is not intuitive and requires so many hoops to be jumped through. I truly appreciate your help. And yes, I know not to use the proxied link, but the only way to give the example was to use it. SusunW (talk) 14:21, 11 June 2022 (UTC)

wikipedialibrary urls
If anyone is looking for something to fix... this search returns about 180 articles that have wikipedialibrary urls.

—Trappist the monk (talk) 14:04, 11 June 2022 (UTC)

When the volume of a journal is the correct target for a link
The following reference from Hurwitz's theorem (number theory) throws an error, because we don't allow links to volumes of journals. But in this case, the content of the link really is the volume of the journal, and the individual paper is more difficult to link. Any suggestions for how to format in a way that both makes sense and makes the templates happy? —David Eppstein (talk) 07:25, 17 June 2022 (UTC)
 * (note: a PDF version of the paper is available from the given weblink for the volume 39 of the journal, provided by Göttinger Digitalisierungszentrum)


 * I think an imprecise link isn't a serious problem (I see it done with Google Books all the time), and anyway it is possible to link to the article: . Yes, it's ugly, but it does seem to go to the correct place. Mackensen (talk) 11:32, 17 June 2022 (UTC)
 * I believe the URL works with fewer arguments: . XOR&#39;easter (talk) 18:04, 17 June 2022 (UTC)

Translation year
Hello there! A query. For a source like

It isn't really the case that Sallust (who died in 35 BC) wrote the thing in 1921. The year of (this specific Loeb) translation was 1921, but would it be possible to have something like a translation-date parameter which could place closer to the translator rather than perhaps implying that Sallust lived for two thousand years? (And if some parameter already does this, please direct me to it!) Maybe something like:

"Sallust [1st century BC]. "Bellum Catilinae". Sallust. Loeb Classical Library. Translated by Rolfe, John C (1921). Cambridge: Harvard University Press."

Thanks. Ifly6 (talk) 13:35, 3 June 2022 (UTC)


 * It is not a good idea to read citations as text, or as part of article prose. They utilize shorthand, ideally according to the way works are classified, hopefully presenting the best & easiest way to find the source. Neither prose-related aesthetics or semantics enter into it. As part of the article's end matter, they have their own semantics. Works are often classified and found by author and date of publication as it appears in the cited edition, and/or also by title of publication. There is no classification system that utilizes the translation date as far as I know. Certainly not in the indexing of works. I would not expect that information will help in locating the source. 50.75.226.250 (talk) 14:42, 3 June 2022 (UTC)
 * Classical scholars do not classify by translation date; that is why I am asking as to how we can move the translation date from the front to the middle. In classical scholarship, the primary sources are cited entirely without dates. Not only because the dates are usually unknown (the publication date of Bellum Catilinae is still debated, the TAQ is 35 and TPQ is 44) but also because the primary sources are not organised that way. They are organised by author and title. See https://guides.library.yale.edu/classics/classics-abbreviations ; eg, the Oxford Classical Dictionary abbreviation (commonly used in English-language scholarship), for the cited material is merely Sall. Cat. without reference to any specific translation. There is usually no reference to any specific translation because classical scholarship assumes you do not need any specific translation. Ifly6 (talk) 15:07, 3 June 2022 (UTC)
 * The date provided in the date field should be the date of publication, not the date of translation, which (for citation purposes) is not relevant. I would not compare or contrast Wikipedia citations with any scholarly, academic, or expert reference system. They target very dissimilar audiences. 50.75.226.250 (talk) 15:35, 3 June 2022 (UTC)
 * I often see citations to ancient works and wonder just how they manage to slip through the RS dragnets. Consider carefully whether you should even be citing such works.
 * The first citation looks fine and exactly like what you need/want. It indicates the modern date of publication and the original date of authorship, which is the purpose of the parameters you've used. Izno (talk) 16:01, 3 June 2022 (UTC)
 * Ancient works are primary sources, they are fine when the text is not based on them and only used as illustration.
 * "The first citation looks fine and exactly like what you need/want.", not really. Most ancient sources cannot be dated, and the translation date still appears before the date of writing, which is very confusing. T8612  (talk) 16:27, 3 June 2022 (UTC)
 * Then I'll refer you to IP50's commentary. I don't see a reason to make a change here. Izno (talk) 16:33, 3 June 2022 (UTC)
 * and : The citation is describing a published source, and the citation is structured so that interested readers can locate the cited source and verify its content for themselves. Saying that the source was published in 1921 is what we want, since that will help a reader go to a library or internet archive and find the matching source. – Jonesey95 (talk) 17:25, 3 June 2022 (UTC)
 * The blanket statements of disdain for ancient sources here are Recentism in its purest form. Some ancient sources such as Euclid's Elements are secondary, not primary, and are very reliable for what they source. Just like with modern sources, one must determine ancient source reliability individually and with care. —David Eppstein (talk) 20:14, 19 June 2022 (UTC)

Generic title
Hello, could Login be added as a generic title, Login • Instagram appears to produce the "Cite uses generic title (help)" but not just Login. Keith D (talk) 18:31, 10 June 2022 (UTC)


 * In my usage "Login" would be the title, while "Instagram" is either the work/website or the publisher, depending on this specific context. SamuelRiv (talk) 20:39, 23 June 2022 (UTC)

Proposed document edit
Currently the Work section contains the following sentence:


 * Aliases: journal, newspaper, magazine, periodical, website.

However, at least in the case of journal, the citation format can change from the layout for the 'work' option. For example:


 * work= :


 * journal= :

I'm proposing the sentence be changed to the following:


 * Aliases: journal, newspaper, magazine, periodical, website. (The alias journal will modify the citation format.)

Praemonitus (talk) 16:57, 20 June 2022 (UTC)


 * @Praemonitus I have no objection to you adding this clarification to the documentation. Be bold and make the edit!  Thank you for your efforts to improve the documentation! GoingBatty (talk) 03:47, 24 June 2022 (UTC)

Template:Cite magazine
This has both  and   as required parameters. Is it possible to make the former unrequired as it is redundant to the latter, similar to the TemplataData of cite news and cite book? Kailash29792 (talk)  06:27, 22 June 2022 (UTC)
 * It's one or the other, and they are different. Compare
 * &#32; Headbomb {t · c · p · b} 06:50, 22 June 2022 (UTC)
 * Why I brought this was, because the other two cite templates have only "pages=" which can be used even for single pages. So, consistency. Kailash29792 (talk)  06:55, 22 June 2022 (UTC)
 * ??? Not true, both forms (singular & plural) exist as distinct parameters. Afaik there is no input validation to check if it matches the singular or plural form. 172.254.222.178 (talk) 11:26, 22 June 2022 (UTC)
 * I've always interpreted the singular form of the 'pages' parameter as listing the number of pages. Praemonitus (talk) 12:32, 22 June 2022 (UTC)
 * That is an incorrect interpretation; see page documentation (and pages documentation).
 * —Trappist the monk (talk) 12:53, 22 June 2022 (UTC)
 * How then does one list the number of pages? Praemonitus (talk) 16:36, 22 June 2022 (UTC)
 * page is used to list the singular page within a source that is being cited. pages is used to list the range of pages within a source that is being cited. For citation purposes, we do not care about the total number of pages within a work.
 * So for example, if I'm citing a magazine article that appears on just page 3 of the issue, I would use 3 to get "p. 3" listed in my citation. If instead that same article ran over to a second page, 3–4 to get "pp. 3–4" or 3, 7 to get "pp. 3, 7" in my citation.  Imzadi 1979  →   16:44, 22 June 2022 (UTC)
 * "...we do not care about the total number of pages within a work." Is this some undocumented tribal knowledge? Just curious. Some digital papers don't have a normal page range, so the number of pages can provide the equivalent information. Praemonitus (talk) 01:23, 23 June 2022 (UTC)
 * the documentation mentioned above for pages says: "do not use to indicate the total number of pages in the source". The citation style is based on elements from APA and CMOS styles, neither of which cite the total number of pages in a work in a citation.  Imzadi 1979  →   02:44, 23 June 2022 (UTC)
 * Okay, but that only applies to the specific parameter, not to listing the total pages in general. Praemonitus (talk) 04:39, 23 June 2022 (UTC)
 * There is no parameter for a magazine's (or a book's or a newspaper's …) total number of pages, because it's of no importance. OTOH articles in journals are often cited with teir total page range the page number for the cited instance: . -- Michael Bednarek (talk) 06:42, 23 June 2022 (UTC)
 * To add: Citation formatting developed/descended from bibliographic formatting, which developed/descended from catalog formatting (of works in libraries, mainly). Sources (works) have been generally classified by the published unit (book, periodical, website, audio/video recording etc.). So when citations point to specific locations within sources, the page or some other marker is necessary, in order to easily find the cited in-source item. For citation purposes, the total number of pages (or bytes, or minutes) is irrelevant. Bibliographies (like catalogs) sometimes include that information, mainly to further distinguish editions/versions. 68.132.154.35 (talk) 15:38, 23 June 2022 (UTC)
 * Okay, thanks for that explanation. I'll also repeat that the lack of need for this information doesn't appear to be explained to the editing community. Or at least I couldn't readily find it. The information about the number of pages is provided on some sources for citations, such as NASA ADS, so it seems appropriate to include it in a cite. Perhaps even a footnote on the topic would be useful? Praemonitus (talk) 14:06, 24 June 2022 (UTC)
 * Well, footnotes and citations are different things and exist for different reasons. Also, it is not useful to compare citations in Wikipedia with any other formal system, or any institutional practice. Wikipedia articles (and their citations, if any) are written by anonymous contributors of uncertain expertise, and are geared to a general, non-expert audience. As for this citation "style" (a misnomer as it includes many non-style-related elements), it is highly structured as far as Wikipedia norms are concerned, and accepts the data that fit the project parameters. In CS1, if there is no reference to a certain property (such as work length), it is highly likely that such property is not part of the system, and should not be expected to make an appearance. Highly structured does not mean correctly structured, but in the particular case under discussion CS1 is codifying the correct approach imo. 68.132.154.35 (talk) 18:42, 24 June 2022 (UTC)
 * page and pages are not required parameters for nor for any of the other 20-ish cs1|2 templates.  Are you seeing something somewhere that says that in  page or pages  required?  If so, where are you seeing that 'requirement'?
 * —Trappist the monk (talk) 12:02, 22 June 2022 (UTC)
 * Again, it's one or the other, and they are different. Compare
 * The first has a hyphen, the second an endash. &#32; Headbomb {t · c · p · b} 12:03, 22 June 2022 (UTC)
 * Ya'll, see the end of the original sentence: TemplateData. $OP is not referencing what is actually required.
 * That said, cite magazine's current documentation says suggested for both page and pages. Indeed, where are you seeing otherwise ? Izno (talk) 16:00, 22 June 2022 (UTC)
 * By mistake. I confused suggested and required. Alright, is it okay to remove  from suggested and retain  ? Kailash29792  (talk)  03:21, 23 June 2022 (UTC)
 * Not really, because it depends on whether or not you're citing one page or many. &#32; Headbomb {t · c · p · b} 04:07, 23 June 2022 (UTC)
 * Ya'll, see the end of the original sentence: TemplateData. $OP is not referencing what is actually required.
 * That said, cite magazine's current documentation says suggested for both page and pages. Indeed, where are you seeing otherwise ? Izno (talk) 16:00, 22 June 2022 (UTC)
 * By mistake. I confused suggested and required. Alright, is it okay to remove  from suggested and retain  ? Kailash29792</b>  (talk)  03:21, 23 June 2022 (UTC)
 * Not really, because it depends on whether or not you're citing one page or many. &#32; Headbomb {t · c · p · b} 04:07, 23 June 2022 (UTC)

Chicago Manual of Style 17th ed. ¶ states "In notes, where reference is usually to a particular passage in a book or journal, only the page numbers pertaining to that passage are given. In bibliographies, no page numbers are given for books cited as a whole; for easier location of journal articles or chapters or other sections of a book, the beginning and ending page numbers of the entire article or chapter are given."

My recollection from university are that if one's own library didn't hold a particular journal, it might be possible to get another library to send a copy of an article, and it was expected to include the page range of the article so that the student-employee who actually made the copy would not have to judge where the article began and ended. When using citation templates, we could use cite xxx for the book or article in a bibliography and sfn with the page(s) that support the claim in the Wikipedia article. Jc3s5h (talk) 11:27, 23 June 2022 (UTC)


 * That's the practice that I follow and I do so for that very reason; inter-library loan is much easier when you know the page range. Mackensen (talk) 19:49, 24 June 2022 (UTC)

Error in author parameter
If you add for author "CS1 maint: multiple names: authors list (link)" will pop up in web cite template. Eurohunter (talk) 21:13, 22 June 2022 (UTC)
 * Not an error. See the template documentation for  in particular the Mbox with the [[file:Stop hand nuvola.svg|30px]] image.
 * To interwikilink an author's name, write :sv:Example.
 * —Trappist the monk (talk) 21:26, 22 June 2022 (UTC)
 * Yes but then people say they are surprised that article is Swedish and they want to see this . Eurohunter (talk) 17:30, 24 June 2022 (UTC)
 * This has been discussed here several times, and it seems that is not going to be supported. The obvious workaround is to construct a manual citation. -- Michael Bednarek (talk) 02:23, 25 June 2022 (UTC)
 * This has been discussed here several times, and it seems that is not going to be supported. The obvious workaround is to construct a manual citation. -- Michael Bednarek (talk) 02:23, 25 June 2022 (UTC)

Tracking (more) cites with generic author names
A couple of months ago, pointed out the large number of citations using the author last name "By", and provided a  handy search. I was able to expand that to capture a few more, by adding last1= through last4= to the regexp (and then remove a few by limiting it to the Article namespace). There are, nevertheless, nearly 200 such citations. Jonesey95 wondered if, perhaps, By could be flagged as a generic name by the CS1 Module, as names like "Editors" and other generics already are.

correctly pointed out that By is a valid surname, particularly in Norway, as illustrated by three biographical article links to the Norwegian Wikipedia. Jonesey95 conceded that, in the original search, there were two cites to authors named "By" that appeared to be genuine.

Be that as it may, in looking over the results of my search, I noted a couple of patterns:
 * 1) The citation has an author By with no corresponding first[1234]? parameter at all.
 * 2) The citation has an author By with a corresponding first[1234]? containing a detectably generic string.
 * 3) * Overwhelmingly, the majority are citations to By Provided. (Such citations also comprise all of the last2 first2 matches I've seen so far.)
 * 4) * Occasionally, By Audio is used.
 * 5) * There's one instance of By Admin which is particularly bizarre (I could see if the first/last were reversed), but whatever..

As such, it seems to me that there's more than enough information available to detect abusive uses of By in citations, and to include them in Category:CS1 errors: generic name, without any of the false-positive flagging of real authors named "By" that David Eppstein was concerned about. There's no reason generic-name detection has to operate exclusively on a single citation parameter in isolation, when it can incorporate the other parameters (or lack thereof) to enable more advanced and accurate detection. FeRDNYC (talk) 19:45, 23 June 2022 (UTC)


 * One check that can also be useful is all-numeric / close to all numeric entries in last/first. Like if you have 2015-09 that's clearly an issue. &#32; Headbomb {t · c · p · b} 20:14, 23 June 2022 (UTC)
 * I thought there was already a CS1 error for "date in &lt;non-date parameter>" or something like that, no? I'll have to check. If not, I can certainly agree that would be useful to watch for. FeRDNYC (talk) 20:36, 23 June 2022 (UTC)
 * Aha! there's already a  check in the module, as it  turns out. It actually looks for any string consisting entirely of non-alphabetic characters. (The actual code is this:)   Where   is  the Lua pattern-matching equivalent of   in standard Perl-Compatible Regular Expression syntax.) So it should already detect "name"s like  . FeRDNYC (talk) 21:28, 23 June 2022 (UTC)
 * (Pretend I wasn't being a tedious American stereotype there, by acting as if names contain ASCII characters exclusively. Unicode letter glyphs like ä, ç, è, and etc. are undoubtedly also supported by the version of Lua pattern-matching implemented in .) FeRDNYC (talk) 21:37, 23 June 2022 (UTC)
 * Pinging to the discussion as the primary author of the current generics detection code. FeRDNYC (talk) 20:35, 23 June 2022 (UTC)
 * Hmm, looking at the current generic detection code ( at line 1401 of the current Module:Citation/CS1), I see that generic-name detection is performed as either a pattern or simple string search on each of the   and   parameters in turn. So, detections that target specific paired uses of last & first probably aren't possible with the current code.
 * I would propose, to, the addition of a further  list, against which a check is run on a joined representation of the entire author name. (So, effectively, undoing the splitting performed by   before checking the name.) that would allow detection of joined names like these:
 * Which would cover the vast majority, if not all, of the problematic uses of By that originally pointed out, without any false positives on valid uses of By.  And we'll probably find more instances where it's useful for detecting other generics, as well.
 * The  list would hopefully be much shorter than the   list used to check first/last names separately, so scanning it hopefully wouldn't have a severe impact on performance. (Please correct me if I'm wrong about that.) Could something like that be a workable approach to generic whole-name detection, where the individual first/last name(s) alone don't tell enough of the story? FeRDNYC (talk) 21:17, 23 June 2022 (UTC)
 * Maybe I misunderstand your proposal, but wouldn't adding say, "provided", "audio" etc. in Module:Citation/CS1/Configuration's 'generic_names' list accomplish similar results? These terms would be considered generic whether they appear in lastn or firstn. 71.105.141.131 (talk) 23:26, 23 June 2022 (UTC)
 * It would accomplish results, but not necessarily similar ones. I guarantee there's someone, somewhere in the world with the first or last name "Audio". "Provided" isn't outside the realm of possibility, either. (Edit: And that still doesn't cover the question of "By" alone, which is insufficiently generic as a first or last name but is flaggably generic when used as the entire name. That's something the current code can't detect.) FeRDNYC (talk) 00:04, 24 June 2022 (UTC)
 * Ok, but by the same token, any term or combination of terms may exist somewhere as a name. And there is the issue of code efficiency and code complexity. Perhaps a certain number/percentage of such generics should actually be detected in live citations before any list/code expansion is considered. 65.254.10.26 (talk) 00:21, 24 June 2022 (UTC)
 * Well, we have numbers on "By": Nearly 200 cites with the last name "By". A couple are seemingly genuine. A large percentage of them are of the (currently undetectable) form By first (meaning, no first-name value provided). I'd guesstimate 80-90%, from looking through the matches. It's hard to be exact, because you can't search for the lack of a parameter without getting into unworkably complex regular expressions that the server will reject as too expensive. FeRDNYC (talk) 00:29, 24 June 2022 (UTC)
 * Then again, a search for cites with "Audio" as the first or last name finds 17 matches, all of which are flaggably generic. (Mostly, they're cites from some audio website that use the name of the site as the author name.) So "Audio" may be a good candidate for  regardless. FeRDNYC (talk) 00:22, 24 June 2022 (UTC)
 * Meh. If we add   to the list and the test just happens to catch a real name (surname or given) we have the accept-this-as-written markup that will bypass the error detection.  For example, Twitter and Google are both generic names so this cite emits error messages:
 * with the markup, no error messaging:
 * I don't think that adding 'audio' is worthwhile if there really are only 17 hits; just fix them. A similar search for 'provided' returned 6 hits (timed out so there could be more) so, again, just fix them.  I think that we rejected testing for 'admin' because it was suggested that there might be too many false positives where 'admin' really is the author.
 * —Trappist the monk (talk) 00:58, 24 June 2022 (UTC)
 * Fair 'nuff. I find myself in agreement with 's original proposal that  is a good candidate for the generics, then. The five or six false positives (now that I've looked through the entire list), as you say we can mark as accept-as-written, and there are still close to 195 more that are flaggable.
 * There are also a number of cites, I'm now seeing, that use By <entire_author's_name>, so it'd be nice to have the generics matching find those as well. I just fixed one... FeRDNYC (talk) 01:10, 24 June 2022 (UTC)
 * Regarding : While I understand and can appreciate that position, it does also sort of implicitly assume that no more instances will be created in the future.
 * If all of the "Audio" links were really old and just never got cleaned up, that'd be fine. We could just fix those 17, and that would be that. But this one was added in 2019, and this one in May 2020.
 * (The second one is actually a cite to a YouTube video, posted by the account "Madhura Audio". I'm not 100% sure what our policies are on that; perhaps it's even correct for the author to be listed as "Madhura Audio". But the cite is written as MadhuraAudio which definitely feels wrong to me. Business YouTube accounts don't have first and last names, they're not people.) FeRDNYC (talk) 07:13, 24 June 2022 (UTC)
 * I don't think that adding 'audio' is worthwhile if there really are only 17 hits; just fix them. A similar search for 'provided' returned 6 hits (timed out so there could be more) so, again, just fix them.  I think that we rejected testing for 'admin' because it was suggested that there might be too many false positives where 'admin' really is the author.
 * —Trappist the monk (talk) 00:58, 24 June 2022 (UTC)
 * Fair 'nuff. I find myself in agreement with 's original proposal that  is a good candidate for the generics, then. The five or six false positives (now that I've looked through the entire list), as you say we can mark as accept-as-written, and there are still close to 195 more that are flaggable.
 * There are also a number of cites, I'm now seeing, that use By <entire_author's_name>, so it'd be nice to have the generics matching find those as well. I just fixed one... FeRDNYC (talk) 01:10, 24 June 2022 (UTC)
 * Regarding : While I understand and can appreciate that position, it does also sort of implicitly assume that no more instances will be created in the future.
 * If all of the "Audio" links were really old and just never got cleaned up, that'd be fine. We could just fix those 17, and that would be that. But this one was added in 2019, and this one in May 2020.
 * (The second one is actually a cite to a YouTube video, posted by the account "Madhura Audio". I'm not 100% sure what our policies are on that; perhaps it's even correct for the author to be listed as "Madhura Audio". But the cite is written as MadhuraAudio which definitely feels wrong to me. Business YouTube accounts don't have first and last names, they're not people.) FeRDNYC (talk) 07:13, 24 June 2022 (UTC)
 * (The second one is actually a cite to a YouTube video, posted by the account "Madhura Audio". I'm not 100% sure what our policies are on that; perhaps it's even correct for the author to be listed as "Madhura Audio". But the cite is written as MadhuraAudio which definitely feels wrong to me. Business YouTube accounts don't have first and last names, they're not people.) FeRDNYC (talk) 07:13, 24 June 2022 (UTC)

i18n Season YYYY–YYYY date fix
Wikis that use the cs1|2 module suite and allow local names for Season YYYY–YYYY dates don't work. Fixed in the sandbox. To show that I have not broken anything here, these two should not display error messages: these three should show error messages: —Trappist the monk (talk) 14:03, 25 June 2022 (UTC)
 * If you intend this to go into production in a few days, can you please add this to the change log above for the upcoming module update? Thanks. – Jonesey95 (talk) 23:00, 26 June 2022 (UTC)

vauthors bug for period saints
No, I'm not talking about CS1 being biased against Medieval Catholicism, although this bug did come up when editing the Quran article. The period in "St. Clair" throws an error (regardless of the hyphenation). Just for fun I tested some other possible problematic names I could think of but those seem fine.

Note this even fails if using the tag. My brief search didn't yield whether Vancouver says to not use such punctuation. SamuelRiv (talk) 23:29, 30 June 2022 (UTC)
 * Not a bug. Vancouver style drops the dot from St. Whatever; see Surnames with hyphens and other punctuation in them.
 * —Trappist the monk (talk) 23:36, 30 June 2022 (UTC)


 * Cool thanks, good to know. My google-fu black belt is apparently revoked. SamuelRiv (talk) 23:39, 30 June 2022 (UTC)

Update the module
I've asked 2 months ago and was ignored. Can the module be updated with the pending changes? Gonnym (talk) 14:02, 23 June 2022 (UTC)
 * The previous update to the modules was on 22 January 2022. We usually list the changes here for comment for about a week before updating. I propose that an admin update the modules no earlier than 1 July 2022, one week from today. In the interim, I have marked this request as "answered" so that it does not sit in the edit request queue. That does not mean it is actually answered; it should be reactivated on 1 July.
 * Updates to the modules, based on the notes in the sandboxes, will be:
 * Module:Citation/CS1:
 * Move citation specific volume & issue lists to ~/Configuration; see discussion
 * Add script parameter error msg supplements; see discussion
 * Bug fix for format in cite episode; see discussion
 * Emit error msg when using identifier-created url and archive-url is present; see discussion
 * Module:Citation/CS1/Configuration:
 * Move citation specific volume & issue lists to ~/Configuration (see link above)
 * Automate local language month name fetching; see discussion
 * i18n local_lang_cat_enable bug fix; see discussion
 * Exclude template namespace from auto-date formatting; see discussion
 * Detect et al with trailing semicolon; see discussion
 * Module:Citation/CS1/Date validation:
 * Date range reformat bug fix; see discussion
 * Module:Citation/CS1/Suggestions:
 * Removed suggestions for unhyphenated versions of deprecated lay* parameters, since we should not be recommending the use of deprecated parameters.
 * I think that is all of the changes, aside from trivial changes to things like PMID limits that have already happened in the live modules. If not, please amend the list above. Corrections to the above are welcome. – Jonesey95 (talk) 15:29, 23 June 2022 (UTC)
 * I have reactivated this edit request, since a week has passed since I posted the details above. Can an admin please update the modules listed above? Thanks. – Jonesey95 (talk) 16:59, 1 July 2022 (UTC)
 * I have reactivated this edit request, since a week has passed since I posted the details above. Can an admin please update the modules listed above? Thanks. – Jonesey95 (talk) 16:59, 1 July 2022 (UTC)

Suggestions to expand "Cite uses generic title/name" errors
Could someone please expand the "Cite uses generic title" error to also include "PressReader.com - Digital Newspaper & Magazine Subscriptions"? There seem to be 272 articles with this text in the title parameter. Thanks! GoingBatty (talk) 19:54, 25 June 2022 (UTC)
 * Is this suggestion worth considering? Thanks!  GoingBatty (talk) 00:30, 2 July 2022 (UTC)
 * Not for me to say. The community appear to be indifferent so ...
 * —Trappist the monk (talk) 11:00, 2 July 2022 (UTC)
 * Not all of us. :-) GoingBatty (talk) 18:47, 2 July 2022 (UTC)

Could you please consider expanding the "Cite uses generic name" error to also include Admin and Admin ("Admin" and "admin")? There seem to be over 3,300 articles with this text. Thanks! GoingBatty (talk) 00:36, 2 July 2022 (UTC)
 * Have a look in the archives. I think that we decided against 'admin' because it is too often a legitimate author name.
 * —Trappist the monk (talk) 10:56, 2 July 2022 (UTC)
 * Aha - found Help talk:Citation Style 1/Archive 79 where "Admin" was already discussed. Thanks!  GoingBatty (talk) 18:47, 2 July 2022 (UTC)

Catalogue numbers in templates
Originally posted at Village pump (idea lab), it was suggested that here would be a better place.

Hi all, am I the only person who finds the layout of catalogue numbers (eg isbn, jstor, oclc, doi ) a bit intrusive? I came across James Leasor, which is a good example of how they can dominate the screen. I find that small caps ISBN 9780552105866 are much less wearing on the eye than ISBN 9780552105866, and are the same size as a standard url link. I'm sure no-one would advocate url links this size. Would there be a case for incorporating this into all the the and similar templates? I imagine it would be trivial to implement, but what do others think? I should mention that my prefs/gadgets include "Disable smaller font sizes of elements such as infoboxes, navboxes and reference lists", but there is still an inconsistency in the relative 'importance' of the information. Cheers, MinorProphet (talk) 10:05, 29 June 2022 (UTC)


 * A few observations:
 * Citation templates are not bibliographic records, and are not the proper tool for descriptive bibliographies like the one in the article you linked. Citations exist to help discover works that support article wikitext, not to populate work lists.
 * The "numbers" you mention can be very important in discovering works, and they are the most easily consulted information for this purpose, as they are always indexed.
 * Because of the above, where citations are concerned, it is not imo a good idea to diminish their screen real estate, and citation templates should adhere to that.
 * Bibliography lists are a different animal. Perhaps non-citation-template based lists can be formatted differently. But structured citation formats like CS1 have different approaches to presentation, where function is more important than form. 172.254.222.178 (talk) 12:16, 29 June 2022 (UTC)
 * "Citations exist to help discover works that support article wikitext, not to populate work lists." Citations templates can definitely be used to populate lists of works though. It's a perfectly legitimate use case. &#32; Headbomb {t · c · p · b} 14:19, 29 June 2022 (UTC)
 * You can use anything to list anything, but that is not why citations exist. They exist to cite sources. Citations, and their narrow representation as templates, can make for very stunted bibliographies. 50.75.226.250 (talk) 14:55, 29 June 2022 (UTC)
 * , please see MOS:SMALLFONT for the reason we can't do this. Text in reflist, where the vast majority of cite templates exist, is already rendered at 90% of the nominal page size, and we can't go below 85%. – Jonesey95 (talk) 13:33, 29 June 2022 (UTC)
 * Why would reducing the size of important discovery items (relative to the rest of the citation) be even considered? Is this just an intellectual exercise? 50.75.226.250 (talk) 15:02, 29 June 2022 (UTC)
 * This can be worked around however. Today format takes a diminished size and could be even smaller than it is if someone wanted it. Izno (talk) 17:16, 29 June 2022 (UTC)
 * Not relevant. format is a post-discovery helper parameter for url. Identifiers such as those mentioned by the OP are discovery parameters, and should not be visually demoted relative to the rest of the citation. Perhaps all these "ideas" are humorous and I am missing the joke. 172.254.155.50 (talk) 19:49, 29 June 2022 (UTC)
 * A statement about the technical feasibility of a change, correcting another's misstatement, is not a judgement of the change itself, regarding particularly the identifiers.
 * As for format, before the TemplateStyles change, it was actually at 85%, but 85% times the 90% Jonesey makes a comment about was indeed much smaller than the 85% of total. Something in the realm of 76.5%. I bumped it up to 95% then having realized that we were missing the 85% mark. Izno (talk) 20:06, 29 June 2022 (UTC)

Thanks to all for your comments and suggestions. Looks like that's a no, then. MinorProphet (talk) 17:00, 1 July 2022 (UTC)

s2cid limit needs to be updated
I recently added a citation with the correct s2cid of 250118314, but received a "check value" error; the help directed me to report this here. Clicking the link generated in the citation confirms it is correct. The article I had edited was Linear Elamite. – Scyrme (talk) 16:02, 2 July 2022 (UTC)


 * Seems it's been updated. Thanks to whoever did this! – Scyrme (talk) 21:55, 3 July 2022 (UTC)

Inter-language author-link
I have some cases where the author of a source has a Wikipedia page, but not on the English-language Wikipedia. Is iy possible to have an inter-language author-link? Hawkeye7  (discuss)  00:08, 6 July 2022 (UTC)
 * Yes.
 * &lt;author name>
 * or
 * &lt;lang tag>:&lt;author name>
 * —Trappist the monk (talk) 00:34, 6 July 2022 (UTC)
 * , yes:
 * Fabian foresaw the consequences that the war guilt question could have for the rise of extremism, which had been awakened in Germany as early as 1920 with the creation of the Nazi Party (NSDAP), which would make the Treaty of Versailles and the question of responsibility its trademark issue: "But the war guilt question can also lead to the poisoning of relations between peoples, it can become a weapon forged for the hand of international nationalism."
 * Mathglot (talk) 00:38, 6 July 2022 (UTC)


 * Thanks! That's awesome! Hawkeye7   (discuss)  05:26, 6 July 2022 (UTC)

Is catalog lookup link mandatory for id template compatibility
Title? I'm updating/creating templates for EUR-Lex codes with hopes for compatibility with CS1's  parameter, so I copied the same pattern used in SELIBR and others, and they all use Catalog lookup link, but is it required? I ask because ECLI does its own thing and, as I only started learning template code today, it will take time for me to wrap it in Cll, so I'm just wondering whether I even need to (I know practically I don't because CS1 is not ideal for most law at the moment anyway, but I raised that issue elsewhere).

As an aside, lookup templates based on Cll, somewhat tailored for CS1, (like SELIBR and those with native support like ISBN) still work in CS1 with multiple identifier arguments, which doesn't really make sense for citation purposes. I doubt it's worth coding an exception over that unless it's easy. SamuelRiv (talk) 01:24, 4 July 2022 (UTC)
 * Afaik, catalogs will add multiple identifiers only when the work exists in multiple editions or formats in their repository (sometimes with a "master" identifier if the catalog allows master records). In this case, only the identifier that corresponds to the edition/format consulted by the citing editor is required and appropriate. As for the use of Cll, this is not the purview of CS1. You may want to raise the issue in a more template/module-specific forum, where issues of code reuse, compatibility, and development can be discussed more fully. 50.75.226.250 (talk) 15:07, 5 July 2022 (UTC)
 * I have several other questions just about what's possible with a CS1 wrapper -- should I got to then? SamuelRiv (talk) 22:06, 5 July 2022 (UTC)
 * I would start at the talk pages of the templates/modules you're working with, including Cll, and expand from there if there's no traction. I haven't looked into CS1 wrappers/metatemplates in a few years, but I remember the category was pretty messy, and iirc included templates that were based on CS1 style elements, but not CS1 templates. Some of the editors regularly posting here did some cleanup in the meantime I believe. 64.18.11.64 (talk) 11:04, 6 July 2022 (UTC)

Proposed change or changes to the link status parameter
I started a discussion at Village pump (technical) and was told about this page. I'm not sure if this discussion will move here, but if not at least there is a link to the VP discussion.--Epiphyllumlover (talk) 17:48, 21 June 2022 (UTC)
 * Yes, I've seen quite a few such template instances that have an archive link but are still active. Perhaps the bot is checking the links at a time when there is an outage or a certificate issue? Sometimes it can be as simple as the link changing from http to https. Praemonitus (talk) 01:49, 22 June 2022 (UTC)
 * Among the suggestions at the Village Pump was to change the dead links to plain unlinked text. I haven't seen an example how that might look, but I suspect it would add considerable verbiage to the emitted text. I suggest that would be a bad thing; it would add horrible clutter. -- Michael Bednarek (talk) 02:36, 22 June 2022 (UTC)
 * There are inline googleoff and googleon tags that could be used. Praemonitus (talk) 03:41, 22 June 2022 (UTC)
 * Like nofollow, this should probably be a mainspace-wide issue. Another problem with delinking the "original" url is the case of preemptive archiving. In such cases the original link is not dead, only pre-empted. This is an efficient way of handling possible link rot, as it requires no maintenance, without any degradation of the reader-facing info. 172.254.222.178 (talk) 11:42, 22 June 2022 (UTC)
 * The citation templates already have a parameter, live, to indicate preemptive archival linking. When used, the citation will continue to link to the original article, with the archive link only being listed as a backup. As such, there is no reason to de-link the originals in those cases, and all of the information is available to disable de-linking for those citations. It shouldn't be a problem. FeRDNYC (talk) 18:38, 23 June 2022 (UTC)
 * That wasn't quite what I'm envisioning, rather it was to add an extra parameter which could be used on some articles, and probably not much. There already is an extra parameter for inappropriate links. I would use it for articles where I'm concerned about Google ranking, because Google has changed and is apparently following links even when told not to. The discussion has since been archived at Village pump (technical)/Archive 198. It seemed like a roughly divided response, but one that could change if views on the site got worse. I don't expect it to be accepted at the moment.--Epiphyllumlover (talk) 22:35, 1 July 2022 (UTC)

Issue regarding the transcript-url parameter on Cite podcast
According to the documentation for Cite podcast, while the parameter transcripturl has been deprecated, the parameter transcript-url should work. However, when using it, the template returns an unknown parameter error:



Compare the equivalent Cite AV media where the parameter does work:

I've tried looking at the relevant module to see what change might've caused this, but it's beyond me. Does anyone know what the issue might be? Sincerely, InsaneHacker (💬) 11:24, 7 July 2022 (UTC)
 * has never supported transcript or transcript-url.


 * For the above comparison, I have tweaked the module sandbox so that transcript and transcript-url are recognized and so not discarded. This shows that Module:Citation/CS1 does not support these parameters for  and never has.  I don't know why  repeats url as a bare url (and I'm not going to spend any time trying to figure that out).
 * For the community: should the cs1|2 module suite be changed to support transcript, transcript-format, and transcript-url?
 * —Trappist the monk (talk) 12:12, 7 July 2022 (UTC)
 * has never supported transcript or transcript-url. Well, that explains it. I hope I didn't misunderstand the documentation, which seems to list it as a valid parameter?
 * [S]hould the cs1. Are the equivalent parameters in Cite AV media not from the CS1 module?
 * I personally think a transcript link parameter is beneficial for AV media, since it increases accessibility and eases verification checks by other users. I was looking at the archives of this talk page while searching for a solution to my problem, and it seems this has been discussed before without any outcome. Sincerely, InsaneHacker (💬) 12:25, 7 July 2022 (UTC)
 * The template documentation says nothing about transcript.  The deprecated and recently removed parameter tables are generic and are included in most if not all cs1|2 template doc pages.
 * Of the 27 cs1|2 templates, transcript, transcript-format, and transcript-url are supported only by and.
 * Can you link to the previous discussions? Such links can be helpful.
 * —Trappist the monk (talk) 14:12, 7 July 2022 (UTC)
 * I was primarily thinking of this discussion where an anon user complained about the supposed disappearance of the parameter in a variety of templates, although as I understand your comment, it wasn't present in some of these to begin with at all. The last few comments in that discussion were about whether or not such a parameter was needed. Others of interest are this one which appears to be right before the introduction of the parameter to Cite AV media and this one where including the parameter in other templates, including Cite podcast was aired, but the discussion seemingly didn't go anywhere. Sincerely, InsaneHacker (💬) 19:27, 7 July 2022 (UTC)
 * Can you link to the previous discussions? Such links can be helpful.
 * —Trappist the monk (talk) 14:12, 7 July 2022 (UTC)
 * I was primarily thinking of this discussion where an anon user complained about the supposed disappearance of the parameter in a variety of templates, although as I understand your comment, it wasn't present in some of these to begin with at all. The last few comments in that discussion were about whether or not such a parameter was needed. Others of interest are this one which appears to be right before the introduction of the parameter to Cite AV media and this one where including the parameter in other templates, including Cite podcast was aired, but the discussion seemingly didn't go anywhere. Sincerely, InsaneHacker (💬) 19:27, 7 July 2022 (UTC)

Trappist asked for comments on the use of the transcript parameter group.

The parameter group should be supported, but only if designed, applied and documented correctly.

Let's start with definitions: Transcript Definition & Meaning - Merriam-Webster (3 definitions).
 * Definition 3 (medical usage): Ii doesn't seem any CS1 templates need to employ the medical definition (DNA transcript), and is hard to conceive of a situation they would.
 * Definition 2 (art usage, see more here): Probably, and  could conceivably use this parameter group in rare cases.
 * Definition 1b (court or academic record): It is possible that the court usage of transcript and the court transcript itself may need to be indicated, but as there is no specialized template for citing court cases, this could be wide open. Academic transcripts are considered private documents and there is no reason to presume they would be published, except rarely, as parts of other works such as biographies perhaps. Or to make things more convoluted, academic transcripts could be entered as evidence in court cases, so one could conceivably cite academic transcripts as in-source locations of court transcripts.
 * Definition 1a (verbatim copy, the most common use): any work that may be cited in non-text media could use the parameter group. This includes (an audiobook not specifically published as a print book),, , ,  etc. etc.

Application note: Transcripts themselves should be cited as the works they represent if they are expressly published as transcripts, for example such transcript of a speech should still be cited with. Some transcripts are published with titles different from the original. Others may be cited in non-online media, and therefore such transcripts would not use a URL. There may also be situations where transcripts may have a different title, and a URL. All these cases should be formatted and presented differently. For now, this comment is just exploring the definitiona and their applicability. 68.132.154.35 (talk) 16:55, 7 July 2022 (UTC)

Following from the above, an implementation proposal:


 * Renames: transcript to transcript-title
 * Adds: transcript-url-access
 * Presentation: transcript parameter values render in plain-text for simplicity
 * Conditions:
 * transcript-url-format ignored if there is no transcript-url
 * transcript-url-access ignored if there is no transcript-url
 * id (for the transcript) required if there is transcript-title but no transcript-url
 * [displays transcript-title value] else [displays] Transcript (static text)
 * When both guideline items below apply, format the citation similarly to citing a translation — Preceding unsigned comment added by 50.75.226.250 (talk) 15:48, 8 July 2022 (UTC)
 * Guidelines:
 * Editors should add transcript-title when different from work title
 * When editors cite a work via its transcript only, strongly encourage transcript

Other, advanced considerations: transcript identifiers, transcript archiving, other-language transcripts. 50.75.226.250 (talk) 15:36, 8 July 2022 (UTC)

i18n uncategorized namespace list
Some history: In Module:Citation/CS1/Configuration at line 12 we have a list of namespaces that cs1|2 does not categorize. The namespace names there are the canonical (English) names that appear to work in all other wikis when used in a wikilink or url. But, when cs1|2 fetches the namespace name from a non-English wiki, the non-English wiki returns the name in its own language. That means that editors in those other-language wikis must translate (replace) the English names with local names.
 * Special:Permalink/551163953
 * Help talk:Citation Style 1/Archive 3
 * Help talk:Citation Style 1/Archive 4 – +draft & draft talk (apparently without discussion)
 * Help talk:Citation Style 1/Archive 31
 * Help talk:Citation Style 1/Archive 42
 * Help talk:Citation Style 1/Archive 64

I have hacked Module:Citation/CS1/Configuration/sandbox to fetch the list of talk namespace identifiers from MediaWiki. The namespace list is specific to the local wiki in that local namespace names are the local language names but the namespace identifiers are the same for all wikis: namespace 2 at en.wiki is 'User' and at sq.wiki is 'Përdoruesi'.

This has the further benefit of making sure that the list of talk pages remains up-to-date; for example, at some point, apparently, the 'Book talk' and 'Education Program talk' namespaces and associated subject-namespaces disappeared.

—Trappist the monk (talk) 15:10, 9 July 2022 (UTC)


 * @Trappist the monk, shouldn't we also allow a way for foreign wikis to add add/remove untracked NS to wish? Or advise how to do so with a comment? That's how I was envisioning the change initially when I proposed it, even though maybe it won't be as much of a problem anyway. - Klein Muçi (talk) 15:39, 9 July 2022 (UTC)
 * Oddly enough, I watch this page, no need to ping me.
 * A custom list of uncategorized namespaces is possible. If, for example, you don't want to track errors in the 'Kategoria' namespace, change:
 * uncategorized_namespaces_t = {[2]=true};
 * to:
 * uncategorized_namespaces_t = {[2]=true, [14]=true};
 * I suspect that wikis are content with the default that we use here.  If they are not, they can change   to suit their needs.
 * This change should resolve the issue at sq:Diskutim:Lasgush Poradeci that you mentioned on 2_update_-_SqWiki|my talk page.
 * Documentation will come...
 * —Trappist the monk (talk) 16:06, 9 July 2022 (UTC)
 * Oh, okay then. I was thinking that they would have to figure that out on their own so I was suggesting either to have most NS numbers there and commented out and advise how to comment/uncomment at wish or advise on doing what you propose, which is more elegant but heavier on the comments' side.
 * PS: Generally speaking, I find your sense of irony amusing, at least. This was a bit bland though. :P - Klein Muçi (talk) 16:34, 9 July 2022 (UTC)
 * —Trappist the monk (talk) 16:06, 9 July 2022 (UTC)
 * Oh, okay then. I was thinking that they would have to figure that out on their own so I was suggesting either to have most NS numbers there and commented out and advise how to comment/uncomment at wish or advise on doing what you propose, which is more elegant but heavier on the comments' side.
 * PS: Generally speaking, I find your sense of irony amusing, at least. This was a bit bland though. :P - Klein Muçi (talk) 16:34, 9 July 2022 (UTC)

documentation
I've tweaked Module:cs1 documentation support to add an uncategorized namespace lister function. This function is intended for use in. After the next cs1|2 update, add this in place of the manual list:

For convenience, I added one parameter to that function. all when set to any value will emit a simple unordered list of all namespace names and their identifiers. Namespace names with identifiers less than 1 (currently Mainspace (0), Special (-1), and Media (-2), are omitted from the list:

—Trappist the monk (talk) 18:23, 9 July 2022 (UTC)

Add a brief note regarding Worldcat (OCLC) as a reliable source
Template:Cite book states at Parameters » Description » URL: "Do not link to any commercial booksellers, such as Amazon; use  or   to provide neutral search links for books."

However, if you use the very helpful Unreliable/Predatory Source Detector (UPSD), book titles hyperlinked to a corresponding Worldcat page will be highlighted in light yellow, indicating a potentially unreliable source. In this case, Worldcat.org is flagged as a "preprint or general repository".

The rationale for this categorization is that Worldcat.org contains self-published books, which are usually not reliable sources. Thus, one should not assume that a book found in a union catalog such as Worldcat.org is necessarily a reliable source. Stated differently, one should not assume that an OCLC link always constitutes a "neutral search".

At the same time, Worldcat.org listings serve important functions, such as helping readers find a book in a nearby library. And editors can identify vanity books (one form of self-published texts) as an unreliable source and not cite them in the first place.

I therefore suggest adding a brief explanatory note at the end of the sentence quoted above that reads something like this:


 * Keep in mind that an OCLC number, which corresponds to the book's listing on Worldcat.org, does not convey any sort of special status for a book. Editors should first determine if a book is a reliable source, and then cite the book with (among other data) an OCLC number. Hyperlinking book titles to Worldcat.org, or simply including the (automatically hyperlinked) OCLC number, helps readers find books in nearby libraries, so it is a desirable component of a citation.

Thank you for your kind consideration,

Mark D Worthen PsyD (talk) [he/him] 20:58, 9 July 2022 (UTC)


 * I don't think the note you're proposing is needed. That's true of ISBNs as well. The current note is to favour neutral link over commercial links. Whether or not a source is reliable is hardly related to citation templates. &#32; Headbomb {t · c · p · b} 21:39, 9 July 2022 (UTC)
 * I agree with Headbomb, and thought of ISBNs, ASINs, and even DOIs. Pretty much all identifiers are just that, identifiers, and do not necessarily convey information about the reliability of the linked item. They are finding aids. – Jonesey95 (talk) 02:18, 10 July 2022 (UTC)
 * When I see the title of a source linked, meaning someone supplied a value for url, then my assumption is that the link will take me to a digital copy of the source. Since Worldcat is not hosting the book, but instead providing the ability to find a copy of the book in a library, the URL for the book's listing at Worldcat shouldn't be provided in url. If I see that it is, I assume it's an errant attempt to supply oclc and edit the citation accordingly to remove the URL and make sure the OCLC is listed instead. I take similar action when someone links a book to a publisher's catalog listing/sales page for a book or for third-party sales page like Amazon.  Imzadi 1979   →   04:12, 10 July 2022 (UTC)
 * Thank you Imzadi1979, that is very helpful.
 * Headbomb said, "Whether or not a source is reliable is hardly related to citation templates." If that is true, why does your script identify the source (Worldcat.org) as potentially unreliable? Excuse my ignorance if the answer is obvious (to everyone but me). :^\
 * - Mark D Worthen PsyD (talk) [he/him] 04:58, 10 July 2022 (UTC)
 * See WP:UPSD &#32; Headbomb {t · c · p · b} 11:11, 10 July 2022 (UTC)
 * Thank you - pithy, helpful explanation. Mark D Worthen PsyD (talk) [he/him] 23:44, 10 July 2022 (UTC)
 * Does Worldcat actually host books though, like Google Books? Or is it just cataloging them? That's an important distinction, I think.  Imzadi 1979  →   00:19, 11 July 2022 (UTC)
 * AFIACT, it's just a catalog listing. Some people mentioned that it showed a Google Book embedded preview, but I've never seen that one myself. &#32; Headbomb {t · c · p · b} 00:43, 11 July 2022 (UTC)
 * Worldcat used to link to Googlebooks for some catalog entries. But when Google shifted to the 'new' books, that stopped working.  I delete https://www.worldcat.org/oclc/ &lt;id> on sight when &lt;id> matches.  If only ve would stop adding the worldcat url when it writes a template with &lt;id>...
 * —Trappist the monk (talk) 00:54, 11 July 2022 (UTC)
 * Might be time to propose a bot run to purge those links (and replace them with oclc). Same for pubmed links that can be handled by PMID. &#32; Headbomb {t · c · p · b} 01:02, 11 July 2022 (UTC)
 * Might be time to propose a bot run to purge those links (and replace them with oclc). Same for pubmed links that can be handled by PMID. &#32; Headbomb {t · c · p · b} 01:02, 11 July 2022 (UTC)

CITEREF disambiguators in date-holding parameters other than |date= and |year=
Another discussion elsewhere got me wondering why we don't trap the use of CITEREF disambiguators in date-holding parameters that don't contribute to the citation's anchor ID. The parameters that contribute to the anchor ID are: All other date-holding parameters should not have CITEREF disambiguators. I have tweaked Module:Citation/CS1/Date validation to catch CITEREF disambiguators in parameters where they are not appropriate:
 * date
 * year – promotes to date when date not present in the template
 * publication-date – promotes to date when both of date and year are not present in the template

—Trappist the monk (talk) 14:30, 11 July 2022 (UTC)
 * Here's a hypothetical situation:
 * A dynamic webpage updated >1 daily
 * on the same date
 * citation0 (cites update0) archived in archive-snapshot0
 * citation1 (cites update1) archived in archive-snapshot1
 * ?: Keep dab on archive dates?
 * 50.75.226.250 (talk) 15:42, 11 July 2022 (UTC)
 * I don't think so. Citation anchor IDs are composed of up to four author/contributor/editor surnames and the year portion of the publication date with optional disambiguator.  The date assigned to archive-date plays no part in that and shouldn't; it should only hold the date of the archived snapshot.  If an editor must cite the same dynamic webpage updated >1 daily then multiple cs1|2 templates each with a different archive-url and date appropriately disambiguated.  If required, CITEREF&lt;something>a, CITEREF&lt;something>b, etc.
 * —Trappist the monk (talk) 17:40, 11 July 2022 (UTC)
 * The hypothetical case has nothing to do with the CITEREF anchor, it was remarked upon because of the proposed disallowance of disambiguated archive dates. It is admittedly a far-edge case, and its only function would be to visibly signal a match between the update URL and the archive URL (via the respective dates of both). This may be useful, especially (but not solely) when/if one or more of the original URLs are marked as not live. Additionally, allowing dab in archive-date is probably a small net positive. The code will not have to error-out any and all disambiguated archive dates except the ones with matching disambiguators, likely a very small percentage of a very small percentage of cases. 68.132.154.35 (talk) 19:06, 11 July 2022 (UTC)
 * I don't see value to supporting anything but the parameters Ttm originally identified here. There is no edge case here; disambiguation has always been documented as expected to be in date. archive-date isn't date and is never promoted as such in the module or in documentation. Izno (talk) 19:11, 11 July 2022 (UTC)
 * The status quo now is that archive-date accepts disamibuators. This would be useless, unless there is a case of two or more citations which cite updates of the same webpage on the same day (dab date), with corresponding archives on the same day (dab archive date). Can such a case be ruled out? Does it cost anything to leave the status quo as is regarding dab archive dates? If anything, leaving archive-date out of the particular error-checking routine may be a net plus. 68.132.154.35 (talk) 19:25, 11 July 2022 (UTC)
 * unless there is a case of two or more citations which cite updates of the same webpage on the same day So use the already supported "same day" mechanism we have in place for anything else. Izno (talk) 19:44, 11 July 2022 (UTC)

Warning generated for list of authors
"author=Technical Committee ISO/TC 58, Gas cylinders, Subcommittee SC4" is generating a warning. What is wrong with the format? · · · Peter Southwood (talk): 08:57, 12 July 2022 (UTC)
 * cs1|2 is not smart enough to distinguish a comma separated list of human names from a corporate or organizational name that contains commas. author must hold only one name.  cs1|2 allows one comma in author (for Last, First names).  Any more than one comma in author (or any semicolon) is presumed to be a list of human names so cs1|2 emits the maintenance message.
 * When citing a corporate or organizational author with commas, you can do this (described at ):
 * It may not be the case here but I very often encounter corporate or organizational 'authors' that are essentially duplicates of the publisher. For those citations, author can be deleted.
 * —Trappist the monk (talk) 11:46, 12 July 2022 (UTC)
 * It may not be the case here but I very often encounter corporate or organizational 'authors' that are essentially duplicates of the publisher. For those citations, author can be deleted.
 * —Trappist the monk (talk) 11:46, 12 July 2022 (UTC)
 * —Trappist the monk (talk) 11:46, 12 July 2022 (UTC)

What is the correct value for the website parameter?
I've been searching through the archives, as well as the documentation at cite web. What is the correct value for website? For example, if I had the following citation  is the domain name   correct, or should it be  ?

The cite web documentation for this is kinda opaque. It says that website is an alias for work, and that work should be the name of the source. But it doesn't give any examples. Template:Cite web says that for my example you'd use, as does Help:Citation Style 1. However in the archives for this talk page, I found the following conflicting discussions; Archive 82:Cite web Website parameter being misused?, Archive 81:website or publisher parameter, Archive 77:Bad value in website= field

If the value should be, could we get that more clearly spelled out at Template:Cite web? I know of at least one lame edit war in the last day that revolved entirely around this issue, and I know I come across cite web citations frequently where the domain name  has been used.

Note: URL was picked at random, and obviously I wouldn't cite the index page of that website. Sideswipe9th (talk) 01:59, 6 July 2022 (UTC)
 * The current instructions at Template:Cite web now say website: Title of website; may be wikilinked. Displays in italics. Aliases: work". That's pretty clear, but the underlined text could be added so it says "website: Title of website (not the domain name, unless that is also the name of the website) ; may be wikilinked. Displays in italics. Aliases: work". It's always seemed clear to me, but I run into this error frequently. SchreiberBike &#124; ⌨ 02:33, 6 July 2022 (UTC)
 * Yeah, that's the way I've always used it, or tried to use it myself. But I wanted a sanity check, especially after seeing an edit war about it yesterday. After finding conflicting information in the archives, I thought it best to ask and possibly see if we can improve the documentation at cite web to make it clearer. Sideswipe9th (talk) 02:39, 6 July 2022 (UTC)
 * Same. So, New York Times, not: nytimes.com. Mathglot (talk) 02:44, 6 July 2022 (UTC)
 * Well, except that we shouldn't be using cite web for the NYT; that goes under cite news, with newspaper= rather than website=. —David Eppstein (talk) 05:00, 6 July 2022 (UTC)
 * Agree with User:David Eppstein here; my example was not the best. But yes, in this case it should be New York Times. If it's a web site, then PayPal. Mathglot (talk) 05:53, 13 July 2022 (UTC)
 * The underlined text doesn't have consensus I'd say; our preference might be for the English text, but we do (or at least should) still accept the domain name if the plain English doesn't feel right (for example, I've used the domain for citations to faculty spaces hosted on a university website, when the name of the faculty's space was not otherwise clear). Izno (talk) 05:56, 6 July 2022 (UTC)
 * Previously, the doc stated that the website name would be the home page's title tag. Or top heading if the title is non-sensical or generic (such as "Home", "Index" etc.). There may also be (increasingly rare) situations where the domain suffix is included in the trade name ("Company.com Inc.") and would be also included in the website name. 64.18.11.64 (talk) 10:52, 6 July 2022 (UTC)
 * Based on the above, it seems that there's agreement that website should not be the domain name when the website has a clear name. I frequently see people using domain names, e.g. rottentomatoes.com instead of Rotten Tomatoes, and I think it should be discouraged. I suggested some language above and I'll try again. How about "website: Title of website (not the domain name when the website has a clear name) ; may be wikilinked. Displays in italics. Aliases: work" ? SchreiberBike &#124; ⌨ 14:50, 7 July 2022 (UTC)
 * Yeah I think something like that would bring some clarity to the parameter part of the documentation. I wouldn't be surprised if some of the confusion and bad practice is because the text at Template:Cite web doesn't actually state how to use it in practice, just that it's a alias for work. Expecting editors to look at the Examples or Help:Citation Style 1 where it is clearer what the value should be, is not a good information flow to inform editorial practice. Sideswipe9th (talk) 14:56, 7 July 2022 (UTC)
 * How about phrasing it to suggest what to do rather than saying what not to do, e.g. "When the website has a clear name, use that rather than the domain name"? Kanguole 15:01, 7 July 2022 (UTC)
 * Yep, much better. How about "website: Title of website (when the website has a clear name, use that rather than the domain name) ; may be wikilinked. Displays in italics. Aliases: work" ? Any suggestions for how to modify Template:Cite web? SchreiberBike &#124; ⌨ 15:11, 7 July 2022 (UTC)
 * As this has sat here for a while and had no objections, I've gone ahead and edited Template:Citation Style documentation/web, which seems to have inserted the text above into various Template:Cite ... documentation pages. It's not perfect, but it's a step forward. Thank you, SchreiberBike &#124; ⌨ 02:41, 14 July 2022 (UTC)

When updating the URL, should the access-date and archive-url parameters also be updated?
One of the pages I'm wanting to edit uses the template, but the news article URL that the page links to 404s - the site in question has changed its layout. I've found the new URL on the site, and I'm assuming (but am not completely sure) that the access-date parameter should be changed in the template, since the new URL was accessed on the date I'm editing. Is this correct?

Obviously, the old archive-url link still works, since it's, well, an archive. Should I leave the archive URL as-is, or update it to match the new URL? --TheSophera (talk) 23:48, 17 July 2022 (UTC)


 * However you like, so long as the links verify the cited fact. If there no fact being cited, IMO prefer the newer link in both url and archive-url .. the main thing is WP:V -- Green  C  23:55, 17 July 2022 (UTC)

unsupported and deprecated parameter cleanup
I am reminded that, per Editor Jonesey95, we should have a formal discussion to fully remove support for: All of these, if used in a cs1|2 template, will emit the unknown parameter error message, transcripturl excepted which is deprecated in.
 * booktitle
 * chapterurl
 * episodelink
 * mailinglist
 * mapurl
 * nopp
 * publicationdate
 * publicationplace
 * serieslink
 * transcripturl

The only vestiges of these parameters are found in Module:Citation/CS1/Configuration except for transcripturl which is also in Module:Citation/CS1/Whitelist.

Shall we remove support for the above named parameters?

—Trappist the monk (talk) 14:25, 7 July 2022 (UTC)
 * I support this cleanup. To elaborate on the above description, the function of the canonical versions of these parameters is not being removed; we are only removing the unhyphenated aliases of the parameters. We have slowly standardized on hyphenation of multi-word parameters over the years. In other words, chapter-url will continue to work fine, but chapterurl will not. The above parameters currently emit an "unknown parameter" error message in preview as well as assigning . That category contains only 69 pages currently, so finally removing the above parameter aliases should not affect the display of articles beyond those 69 pages. Trappist, please correct any of this if it is incorrect. – Jonesey95 (talk) 16:07, 7 July 2022 (UTC)
 * This search should find articles in that use any of the above listed parameters except transcripturl for which use this search.
 * —Trappist the monk (talk) 18:56, 7 July 2022 (UTC)
 * One other category where use of these parameters might be found is . Use this search to look there (includes transcripturl).
 * —Trappist the monk (talk) 21:35, 9 July 2022 (UTC)
 * I've gnomed that category down to empty and none of the errors that I fixed were caused by the parameters in question. Tangent alert! There were, however, a lot of errors caused by deadurl.  Is there currently a bot fixing these, and if not might Monkbot be interested in them?  They're a bit tedious to do by hand but a bot should find them tasty.  Best, Wham2001 (talk) 09:07, 8 July 2022 (UTC)
 * Support the cleanup, per Jonesey95. 68.132.154.35 (talk) 17:04, 7 July 2022 (UTC)
 * The documentation for Citation Style Vancouver suggests the opposite convention to CS1|2 – not using hyphenated parameter aliases – for the sake of getting out every bit of performance. Will CSVAN's documentation change to encourage using to hyphenated parameter names? Is CSVAN still even maintained? SamuelRiv (talk) 17:57, 7 July 2022 (UTC)
 * Those templates use a mishmash of parameter styles: trans_chapter, chapter-url, and chapterformat are listed in the documentation for Vcite book. CS1 started moving away from this mishmash long ago, and is almost done. Vcite book has only 123 transclusions, and Vcite web has only 93. It would be an interesting exercise to determine if those templates could be converted to cite book with appropriate style parameter values without changing their rendered appearance. If so, it would probably make sense to merge them with their corresponding CS1 templates. – Jonesey95 (talk) 18:36, 7 July 2022 (UTC)
 * Small-caps is going to be a hard stop. Izno (talk) 18:51, 7 July 2022 (UTC)
 * Is CSVAN still even maintained? No, and the user who created it mostly by himself has been blocked for a long time now. Izno (talk) 18:50, 7 July 2022 (UTC)
 * I think that I would oppose merging Citation Style 1 with Citation Style Vancouver. cs1|2 is complex enough that attempting to support CSVAN would be a nightmare.  Perhaps best to simply let existing  citations fade away and then remove support for the templates via TFD.
 * —Trappist the monk (talk) 18:56, 7 July 2022 (UTC)
 * the user who created it mostly by himself has been blocked for a long time now Who might that be? The templates, , and  were all created by , who is no longer around, this is true; but their [//en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3AEubulides block log] is clean. -- Red rose64 &#x1f339; (talk) 19:40, 8 July 2022 (UTC)
 * I'm thinking of Wikid, who I recall pushing these as if they were sliced bread. Izno (talk) 21:13, 8 July 2022 (UTC)
 * Who also has a [//en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3AWikid clean block log], and moreover, [//en.wikipedia.org/w/index.php?title=Special:Contributions/Wikid&namespace=10 zero edits in template space]. -- Red rose64 &#x1f339; (talk) 20:48, 9 July 2022 (UTC)
 * I think "Wikid" refers to . * Pppery * <sub style="color:#800000">it has begun... 21:17, 9 July 2022 (UTC)
 * Performance may have been one of the reasons that the templates were created but that 'advantage', if it were an advantage, pretty much went away when MediaWiki enabled mw:Extension:Scribunto and Lua.
 * —Trappist the monk (talk) 18:56, 7 July 2022 (UTC)
 * I'm only now trying to learn this stuff and searching through the forums gives all the discussions of the old performance issues of COinS but only hints as to what extent that was resolved (other than people stopped talking about it). CSVAN still features prominently in Wikipedia referencing which is on the CS1 Help page, so if it's old and dead (as are a lot of citation templates) then some cleanup is warranted just to let people know what the current standards are. I'm still curious if it's possible to "switch off" the metadata tags with say a wrapper for CS1|2-based templates which may have some fields that might not be suitable for inheritance, such as if the data in the field will likely always be considered polluting. SamuelRiv (talk) 19:12, 7 July 2022 (UTC)
 * Use of the templates in mainspace:
 * ~30
 * none
 * ~25
 * ~20
 * ~35
 * These numbers suggest that the popularity of the templates is on the wane.  No doubt the primary reason is that bots, visual editor, RefToobar, Diberri Boghog template filler, etc create cs1|2 templates.  If I'm not mistaken, WP:MED used to be one of the primary users of the  templates.  The above searches suggest that WP:MED has moved away from.
 * Wrapping cs1|2 templates gives you the benefits of the cs1|2 module suite which includes metadata, error checking, presentation, etc. If you don't want metadata or if you think that the metadata provided by a wrapped cs1|2 template would be bogus, it would probably be best to write your template from scratch.  If you expect such a template to be used in articles that are predominantly cs1|2-cited articles, be mindful of presentation because editors care about that; that includes differentiating between cs1 and cs2 presentation.
 * —Trappist the monk (talk) 22:07, 7 July 2022 (UTC)
 * No. Significant opposition to the proposed changes was raised in the RfC, and it does not appear that anything has changed since then.
 * Pinging participants in that RfC who have not yet commented here, apologies if I've missed anyone: . Nikkimaria (talk) 01:38, 8 July 2022 (UTC)
 * What is the objection to this specific change, which will have zero effect on any articles? Deprecation of the above parameters happened in February 2021, all of the parameters were updated shortly thereafter, and any stray instances of those parameters have been generating error messages (and have been quickly fixed) since April 2021. Additional factual information appears in this discussion. – Jonesey95 (talk) 13:45, 8 July 2022 (UTC)
 * The problems with this effort were outlined in the two previous RfCs, plus there is the concern raised by Hog Farm/Nosebagbear below. Nikkimaria (talk) 17:21, 9 July 2022 (UTC)
 * The problems with this effort were outlined in the two previous RfCs, plus there is the concern raised by Hog Farm/Nosebagbear below. Nikkimaria (talk) 17:21, 9 July 2022 (UTC)

Please quote where in the April 2021 RFC it specified certain parameters and not others. The RfC question was The background section said Option C was And the close was:  Where does any of that specify some deprecated parameters and not others? and means, to me, that ALL non-hyphenated parameters were un-deprecated in April 2021. am I misreading this close? Levivich<sup class="sysop-show">[block] 14:39, 10 July 2022 (UTC)
 * Support removal—since these unhyphenated forms don't do anything anymore except generate errors, why are we keeping them around any longer.  Imzadi 1979  →   02:52, 8 July 2022 (UTC)
 * Thank-you for the ping – my watchlist is currently an unusable tire-fire so I would have missed this discussion otherwise.  I support (if we're doing bold !voting) removal of these aliases largely per Jonesey95. They appear not to be in use anywhere in the encyclopedia (unlike, say, accessdate which was controversial in the RFC). As such I think that standardisation on the hyphenated variants is only beneficial. Best, Wham2001 (talk) 09:14, 8 July 2022 (UTC)
 * Support removal - it is much easier to maintain (and copy to other wikis) if there are not a bunch of variants that are really not needed. And thank you for the ping. --MGA73 (talk) 16:24, 8 July 2022 (UTC)
 * There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates (option C). That's April 2021. What did I miss? Levivich<sup class="sysop-show">[block] 16:55, 8 July 2022 (UTC)
 * It is confusing. What you missed is the link to a subsequent January 2022 RFC at the top of this thread; in that RFC, the above parameters remained deprecated, but complete removal of support for them was pushed to a new discussion. This is that discussion. What you and many participants in that April 2021 discussion missed is that the above parameters did not exist in article space at the time of the discussion. They had already been deprecated, and removal of support for them was to be a mere formality. Unfortunately, they were one of the babies thrown out with the bathwater and remained in a sort of limbo. This discussion is finishing that cleanup work in the formal way required by the January 2022 RFC closure. Support for or deprecation of the six remaining active unhyphenated parameter aliases, accessdate, airdate, archivedate, archiveurl, authorlink, and origyear, is not being contemplated in this discussion, and I beg everyone here not to mention them again in this thread, lest it go off the rails. – Jonesey95 (talk) 06:36, 9 July 2022 (UTC)
 * I am confused. Thanks for the link, but what you linked to does not appear to be an RFC. What I linked was an RfC from a year ago where we decided not deprecate any unhyphenated parameters. So where is the RfC that changed that consensus? Because from where I'm sitting, since April 2021, there are no deprecated unhyphenated parameters. I don't think there's been another RfC since there, has there? Even this isn't tagged RfC. So what gives? Why are editors referring to deprecated parameters after the April 2021 RFC? Levivich<sup class="sysop-show">[block] 02:48, 10 July 2022 (UTC)
 * The January 2022 RfC here. -- Green  C  03:01, 10 July 2022 (UTC)
 * Where in that RFC was it decided to deprecate anything? Can you quote it for me? Levivich<sup class="sysop-show">[block] 03:07, 10 July 2022 (UTC)
 * That RFC found no consensus to remove deprecated parameters, and though it's not stated in the closing, the reason is because there aren't supposed to be these deprecated parameters in the first place. chapterurl should be an alias for chapter-url, booktitle should be an alias for book-title, and so forth. That's what the April 2021 RFC decided, and as far as I can tell, that hasn't changed. People are pointing to a (non-RFC) discussion in Feb 2021 as the place where it was decided to deprecate these parameters, but that local consensus was overridden by the global consensus of the April 2021 RFC that said "There is a rough consensus that non-hyphenated parameters should not be deprecated in citation templates." That global consensus wasn't changed by the January 2022 RFC. This is all highly irregular. Levivich<sup class="sysop-show">[block] 03:10, 10 July 2022 (UTC)
 * The January 2022 RFC said that there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out. This is that necessary discussion, a year and a half after the January 2022 RFC. The parameters above have been deprecated since February 2021, have not been used anywhere since March or April 2021, and the proposal now is to remove them from the citation module code entirely. This is how deprecation works, when it works; parameters or methods are deprecated, then removed from use, then discontinued entirely. Historically, with these modules, the process has happened much more smoothly and with a lot less drama. – Jonesey95 (talk) 06:17, 10 July 2022 (UTC)
 * What does "non-hyphenated parameters should not be deprecated", from the April 2021 RFC mean, and why doesn't that override the earlier Feb 2021 decision to deprecate? I'm sorry that my questions are too "drama" for you, I'll try to ask them in a less dramatic way. Can we just do this where you pretend I'm not stupid and explain in plain English why the words "non-hyphenated parameters should not be deprecated" doesn't mean that non-hyphenated parameters should not be deprecated, and why you're saying that any non-hyphenated parameters are deprecated if there was an RfC that resulted in consensus that non-hyphenated parameters should not be deprecated. Because that's how RFCs work. Levivich<sup class="sysop-show">[block] 06:37, 10 July 2022 (UTC)
 * When the closer said that "non-hyphenated parameters should not be deprecated" in April 2021, they were referring to the remaining six unhyphenated multi-word parameters: accessdate, airdate, archivedate, archiveurl, authorlink, and origyear. Those six parameters are not at issue here; the beginning of mass bot modification to hyphenated parameters prior to a deprecation discussion about those six was the main cause of that RFC and the main objection of participants. Maybe that is the main source of your confusion? That would be understandable, because that discussion got pretty convoluted.
 * As of April 2021, the parameters at the top of this discussion were already deprecated and had been removed from all namespaces that assign CS1 tracking categories. They were not undeprecated by the April 2021 discussion. Now, go forward in time to January 2022. In that month's RFC, there was a long list of code changes proposed, including remove support for previously deprecated parameters (note that this is the list of ten parameters, deprecated since February 2021, at the top of this July 2022 discussion). Those changes were generally approved for implementation, but there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out, so those ten parameters remained in the deprecated state. Now we are having that further discussion, with the goal of moving those ten parameters from deprecated, non-standard, and unused (where they have been since February 2021) to completely unsupported, i.e. removed from the code. – Jonesey95 (talk) 07:07, 10 July 2022 (UTC)
 * As of April 2021, the parameters at the top of this discussion were already deprecated and had been removed from all namespaces that assign CS1 tracking categories. They were not undeprecated by the April 2021 discussion. Now, go forward in time to January 2022. In that month's RFC, there was a long list of code changes proposed, including remove support for previously deprecated parameters (note that this is the list of ten parameters, deprecated since February 2021, at the top of this July 2022 discussion). Those changes were generally approved for implementation, but there is no consensus on removal of deprecated parameters in this discussion, and further discussion will be necessary to roll that part out, so those ten parameters remained in the deprecated state. Now we are having that further discussion, with the goal of moving those ten parameters from deprecated, non-standard, and unused (where they have been since February 2021) to completely unsupported, i.e. removed from the code. – Jonesey95 (talk) 07:07, 10 July 2022 (UTC)
 * It is clear to me that my multiple attempts to use words to explain the timeline have not been effective for you, so I will either leave it to someone else to help you, or leave it to the person who summarizes this discussion to determine what the next step should be. Happy editing! – Jonesey95 (talk) 04:02, 11 July 2022 (UTC)


 * Support removal - been deprecated for a long time, and are essentially unused now. Time to clean them up. -- Pres N  19:25, 8 July 2022 (UTC)
 * Support removal it's high time to cleanup.&#32; Headbomb {t · c · p · b} 20:00, 8 July 2022 (UTC)


 * Support removal. Was pinged to this discussion. These parameters are not used and the convention is to use hyphenated versions. Gonnym (talk) 23:18, 8 July 2022 (UTC)
 * Support removal for these few as they've been essentially trace fossils for quite some time, with the understanding that this discussion should not be claimed as a consensus for removal of other non-hyphenated parameters. Hog Farm Talk 06:40, 9 July 2022 (UTC)
 * Concur with removal for these without precedent - as with Hog Farm, I back the removal here without wanting the risk for it to act as a precedent across all paramaters. Nosebagbear (talk) 12:32, 9 July 2022 (UTC)
 * Oppose This is trying to justify something that the community agreed should never have been done based on a fait accompli * Pppery * <sub style="color:#800000">it has begun... 18:44, 9 July 2022 (UTC)


 * Support removal and thank you for your efforts in maintaining citation templates. 19:42, 9 July 2022 (UTC) — Preceding unsigned comment added by Renata3 (talk • contribs)
 * Oppose because this is going to be used as evidence to remove the other non-hyphenated parameters -- Guerillero Parlez Moi 14:11, 11 July 2022 (UTC)
 * That is not a valid reason for any opinion, pro or con. A discussion result is not evidence of anything except of the existence or absence of consensus among participants of said discussion. Apart from that anything can be used to promote or oppose anything. And that is irrelevant. 50.75.226.250 (talk) 15:54, 11 July 2022 (UTC)
 * Support removal of these parameters for better standardisation. Tol  (talk &#124; contribs) @ 18:58, 12 July 2022 (UTC)
 * Support only for those that generate errors - What is the point of keeping them if they generate errors? I opposed ditching the hyphenated parameters in the previous RfC, and still think there are too many hyphenated parameters that people actively use. I don't mind deprecating them, but they shouldn't be removed. Just have a bot/AWB/whatever go around and clean them up if they're functional-but-not-ideal. The idea is to to maximize user functionality. Lots of people have used hyphenated parameters for a long time, so getting rid of them... is just going to generate errors or not show up. Of course, if some are already only generating errors, that ship has sailed. &mdash; Rhododendrites  <sup style="font-size:80%;">talk \\ 12:29, 13 July 2022 (UTC)
 * @Rhododendrites: Do you mean non-hyphenated? No one is suggesting to get rid of the hyphenated ones. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 06:48, 14 July 2022 (UTC)
 * All of the parameters listed at the top of this discussion generate error messages and error-tracking categories. They have been deprecated since February 2021. Deprecated (and unsupported) parameters in CS1 templates generate error messages and error-tracking categories. – Jonesey95 (talk) 07:41, 14 July 2022 (UTC)
 * Yes, I understand that, but they're not hyphenated (eg. booktitle is unhyphenated). &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 19:17, 14 July 2022 (UTC)
 * Oppose removal, after thinking about it a bit, because instead of removal, what should happen is that these unhyphenated parameters should be aliases to their hyphenated counterparts. booktitle should be an alias to book-title, chapterurl should be an alias to chapter-url, and so on. That these parameters currently give errors isn't a reason to remove them, it's a reason to fix them and return them to the aliases they used to be. The April 2021 RFC found consensus that non-hyphenated parameters should not be deprecated in citation templates and that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters. Assuming that was done, there should be no non-hyphenated parameters on the deprecated parameter list; they should not be throwing off errors; support for these parameters should not be removed; they should be returned to functioning aliases. Levivich (talk) 02:28, 17 July 2022 (UTC)
 * Comment: I am not sure what the best option is here, since I can come up with decent arguments in favor of either. On one hand, removing them would be kind of a pain in the ass. Having the templates break entirely when given unhyphenated parameters would cost us something, in that everyone trying to insert a reference would have to go back and dick around with the template to fix huge red error messages. In a big article with a lot of references, this can be a significant amount of work. On the other hand, keeping them would also be kind of a pain in the ass -- it would populate the citation error category, requiring someone to go through and gnome the errors out. On the third hand, though, this seems a lot easier than having people fix the parameters while writing the article (you could probably just have a bot go through every few days and fix the errors). In conclusion... who knows. jp×g 20:15, 17 July 2022 (UTC)
 * It is possible that misunderstands the proposed change and its effects. These unhyphenated multi-word parameters, like chapterurl, have been deprecated for a year and a half, currently display error messages, do not (or should not, at least; we may have missed a couple) appear in the documentation, and are not in use in the spaces that are categorized by the citation templates. Nobody is going to have to do any work to implement or clean up after this change. Standard hyphenated multi-word parameters, like chapter-url, will continue to work without any problems. – Jonesey95 (talk) 23:35, 17 July 2022 (UTC)
 * Yeah, sorry, I wrote this ass-backwards. I meant to say "unhyphenated". jp×g 07:14, 18 July 2022 (UTC)

need to automate doi-access change to 'free', based on date
Is this worth adding to the module, or should I create a new citation template for JIPA?

We will be citing several hundred illustration of the IPA in JIPA, linked via DOI to their host publisher site at CUP. They are subscription for the first 3 years, then free public access. It would be nice if the template could handle this. E.g., something like, where we could set freeage to 3. (Since for the URL link 'free' is the default, there shouldn't be any confusion that 'freeage' applies to the DOI link.)

See Qaqet language, where I used the 'translation' parameter to add a note about the article. It is -- or will be -- in the 'Illustrations of the IPA' section of the journal, and that is the standard wording used in the lit to refer to these JIPA articles, so that phrasing should be included but isn't part of the title. Also there is supplementary material (sound files) online which are a good publicly accessible resource and should be mentioned, but I don't see a param designed to handle that info.

Please ping. Thanks, — kwami (talk) 21:48, 12 July 2022 (UTC)
 * For pmc identifiers we have pmc-embargo-date. But, embargoed pmcs are relatively common and not constrained to any particular journal.  Are there other journals or publishers that have similar doi embargos?  I'm not enthusiastic about creating and maintaining code in the cs1|2 module suite that will support only one journal.  If doi embargos are a common practice among multiple journals/publishers then we might consider creating doi-embargo-date.
 * trans-title has a defined purpose. Do not misuse cs1|2 parameters for purposes that do not fit with the parameters' defined purposes.  Use department for the 'Illustrations of the IPA' section of the journal.
 * —Trappist the monk (talk) 11:04, 13 July 2022 (UTC)
 * Okay, thanks. That meaning of "department" isn't in my vocabulary. What param should I use for notes/comments, such as 'includes supplementary material'? 'Pages', maybe? — kwami (talk) 01:54, 18 July 2022 (UTC)
 * doi-embargo-date has some merit as an idea. The issue is mostly that this is a very hard thing to keep track of manually, since it varies a lot by journal and publisher. &#32; Headbomb {t · c · p · b} 02:18, 18 July 2022 (UTC)
 * cs1|2 does not have any parameters for notes/comments. pages has a defined purpose.  Do not misuse it for something else.  If you want to append notes/comments to a citation, they can go at the end – after the template's closing   and before the reference's closing.
 * —Trappist the monk (talk) 11:39, 18 July 2022 (UTC)
 * cs1|2 does not have any parameters for notes/comments. pages has a defined purpose.  Do not misuse it for something else.  If you want to append notes/comments to a citation, they can go at the end – after the template's closing   and before the reference's closing.
 * —Trappist the monk (talk) 11:39, 18 July 2022 (UTC)

AV identifiers
For your consideration: May have enough critical mass to be included in the Identifiers group. 50.75.226.250 (talk) 16:09, 18 July 2022 (UTC)
 * ISAN
 * ISRC [agency website]
 * ISWC

RFC: Rename url-status parameter
The meaning of the url-status citation parameter is frequently misunderstood by editors. (See the discussion immediately above this one, url-status=live without an archive-url, for just one example of literally dozens, if not hundreds, over the years.)

I would argue that this confusion is our fault, because the current parameter name is just terrible. url-status has nothing whatsoever to do with the current status of the citation URL. (An unknowable, since it can change at any moment.) The only effect of live is to prevent the citation's archive-url from being promoted to the primary citation link, the way it otherwise is with the default dead in effect. Like archive-date, NO value of url-status has any meaning unless an archive-url parameter is also provided.

As such, the name of the parameter should clearly start with. Above, I proposed primary / backup, but that doesn't account for the third possible value of the existing parameter, usurped. So upon further reflection, I instead propose that we deprecate url-status and replace it with primary / backup / usurped.

I'm fully conscious of what a colossal PITA it will be to make this change, but I feel it can be done in stages (and with some bot assistance) to ease the pain. More importantly, I feel it's ultimately worth the pain because the current parameter name, url-status, is just bad. It bears almost no relation to the actual meaning of the parameter, in ways that will continue to mislead and confuse editors until we finally fix our stuff. (I'll cross-link this proposal to Village Pump (technical) as well.) FeRDNYC (talk) 18:15, 14 July 2022 (UTC)
 * primary: Would be the default, where the archive-url is the primary citation link and the url becomes a "the original" link. Same as the current default dead.
 * backup: Would disable the replacement of the url as the primary link, to support preemptive archival linking of non-dead citations. (Same as live today.)
 * usurped: Would, like usurped today, disable all linking to the citation's original url, for situations where the original link has changed without becoming dead.


 * I ended up posting at Village_pump (proposals) instead. FeRDNYC (talk) 18:27, 14 July 2022 (UTC)
 * Strong oppose. You said that url-status= has nothing whatsoever to do with the current status of the citation URL when in fact it literally does. The whole point of url-status is to determine if the link is dead. You can have url-status=dead without there being an archive link. That way, other people can add the archived link later.
 * Besides the amount of disruption and work required for a basically cosmetic change is not worth it. Rlink2 (talk) 18:30, 14 July 2022 (UTC)
 * Comment I have no opinion even though it will result in a lot of broken bots and user tools that would need to retool (if ever gets done, some poorly maintained but active tools remain nameless). Also "primary" and "backup" are coded terms that are not in themselves explanatory. Suggest "first" and "second" ie. archive URL displayed first ie. archive-display=first .. is a lot more intuitive and easy to remember what it means. --  Green  C  18:36, 14 July 2022 (UTC)
 * Strong oppose—this parameter was renamed/reworked not that long ago, and renaming it again would be highly disruptive.  Imzadi 1979  →   18:39, 14 July 2022 (UTC)
 * History:
 * —Trappist the monk (talk) 18:42, 14 July 2022 (UTC)
 * Oppose Let's not have more of this sort of churn please. * Pppery * <sub style="color:#800000">it has begun... 18:44, 14 July 2022 (UTC)
 * Oppose pointless churn, big hassle for editors and bot developers, no benefit to readers. —David Eppstein (talk) 18:58, 14 July 2022 (UTC)
 * —Trappist the monk (talk) 18:42, 14 July 2022 (UTC)
 * Oppose Let's not have more of this sort of churn please. * Pppery * <sub style="color:#800000">it has begun... 18:44, 14 July 2022 (UTC)
 * Oppose pointless churn, big hassle for editors and bot developers, no benefit to readers. —David Eppstein (talk) 18:58, 14 July 2022 (UTC)
 * Oppose Let's not have more of this sort of churn please. * Pppery * <sub style="color:#800000">it has begun... 18:44, 14 July 2022 (UTC)
 * Oppose pointless churn, big hassle for editors and bot developers, no benefit to readers. —David Eppstein (talk) 18:58, 14 July 2022 (UTC)


 * Oppose, no benefit. Proposal is worse than the status quo. Editor should not have attempted to start an RFC before starting a discussion to get the general consensus, which is clearly opposed. – Jonesey95 (talk) 19:14, 14 July 2022 (UTC)
 * Oppose I don't see how this parameter is confusing. InfiniteNexus (talk) 04:11, 19 July 2022 (UTC)

Accept zero padding in dates
Currently the template does not accept a date such as 09 July 2022, giving an unhelpful error message. Instead one must write 9 July 2022. I think it's silly to bother editors with this, the template should accept both styles and silently reformat it. I thought it would be better to ask here before changing it because this template is so widely used. Tercer (talk) 12:52, 16 July 2022 (UTC)
 * See MOS:DATESNO: "Do not zero-pad day". – Jonesey95 (talk) 20:20, 16 July 2022 (UTC)
 * You misunderstand me. I'm saying that we should always display 9 July 2022, but allow editors to input 09 July 2022. Tercer (talk) 20:28, 16 July 2022 (UTC)
 * Why not get people to do it right in the first place? If they get into the habit of using it in cite templates then they will use it in other places in the text which will not get autocorrected. Keith D (talk) 22:27, 16 July 2022 (UTC)
 * , I understand what you are saying, but it is a bad idea, as Keith D explains. For the same reason, we also emit error messages when editors type 1/15/2003 or 01-15-03 or 2004-05. Editors should type valid dates so that there is a better chance that the date they type is correct and will not have to be checked or fixed by others. – Jonesey95 (talk) 00:19, 17 July 2022 (UTC)
 * Dates in M/D/Y format, two-digit years, or "2004-05" are ambiguous (though technically speaking, 1/15/2003 isn't). 09 July 2022 isn't ambiguous, though. (On a side note: Module:Citation/CS1/Date validation seems to have the code already written to support leading zeros, though it is commented out.) isaacl (talk) 20:56, 17 July 2022 (UTC)

Frankly, annoying editors with a pointless error message in order to teach them a minor stylistic point? You guys are a lost cause. I'm sorry I tried to help. Tercer (talk) 08:12, 17 July 2022 (UTC)
 * You are correct, and such pointless error messaging has caused problems in the past. Also agree this increasingly looks like a lost cause. 104.247.55.106 (talk) 13:43, 17 July 2022 (UTC)

I entirely agree with @. I do a lot filling of refs, and for accuracy's sake I copy-paste the date from the article where possible. Many date formats are unambiguous, but need to be re-formatted to avoid error error messages. These other formats are easily parsed; why trigger an error message when the date is unambiguous?

e.g. for 9 December 2014, the templates should accept:
 * 09 December 2014
 * 9 December, 2014
 * 9 DECEMBER 2014
 * 9 DECEMBER, 2014
 * 9 DEC 2014
 * 9 Dec. 2014
 * 09 Dec., 2014
 * 09th DEC, 2014
 * ... and many other variants.

The current demand for conformity is just a make-work. -- Brown HairedGirl  (talk) • (contribs) 08:03, 22 July 2022 (UTC) By all means trigger a warning, but not an error.

Cite document emits a missing periodical maintenance message. It shouldn't
Case in point:

Pinging User:Keith D. &#32; Headbomb {t · c · p · b} 12:28, 22 July 2022 (UTC)
 * It also does not have the page identifier (pp.) Keith D (talk) 12:32, 22 July 2022 (UTC)
 * is not a cs1|2 template. It is merely a redirect to .  As such, cs1|2 sees the template as a  template and renders whatever it has been given as a journal-style citation.   requires journal so when that parameter is empty or omitted, cs1|2 emits the error message.  Pagination rendering follows the  format (&lt;colon>&lt;space>&lt;pagination>).
 * The source in the example template is clearly not a journal so were it me, I'd rewrite the example template:
 * —Trappist the monk (talk) 13:07, 22 July 2022 (UTC)
 * cite document is meant for things that aren't journals and should behave accordingly. The solution can't also be to redirect it to cite web instead of cite journal because it should also not require a url. &#32; Headbomb {t · c · p · b} 13:16, 22 July 2022 (UTC)
 * Documents should be cited only when published. Unless published as pamphlets, i.e. standalone which would fall under cite book, they are mostly published as parts of other works, including collections, repositories and websites. The citation should follow the conventions of the including entity, so cite web seems proper here. The logical treatment would be to delete so-called citation templates that contravene these simple guidelines, or at a minimum to strongly emphasize that editors should not expect support for such templates here if they insist on using them. This page should not waste time every time an editor gets a fancy redirect idea. 50.75.226.250 (talk) 14:53, 22 July 2022 (UTC)
 * I agree with Headbomb, a document is not necessarily contained in a journal, and it does not necessarily have a URL. Two CS1 templates that seem close are cite report and cite techreport. "Cite report" documentation says "[it] is used to create citations for reports by government departments, instrumentalities, operated companies, etc. Examples include: government printed reports which lack ISSN or ISBN numbers, and reports from major semi-governmental instrumentalities that are freely circulating and available for verification, but which lack a formal ISBN/ISSN publication process."
 * It isn't spelled out what it is about "cite report" that make it unsuitable for any report, published by anybody, that isn't in the domain of one of the other CS1 templates. If it's a paper report published by the Committee to Use Customary American Units of Measure (which I just made up) why would and somehow manages to satisfy WP:IRS, why couldn't you use "cite report"? Jc3s5h (talk) 15:02, 22 July 2022 (UTC)
 * Although all reports are documents, not all documents are reports (technical or otherwise). CS1 definition is narrow, but correct. Published government reports are generally easily available and are usually subject to higher scrutiny before and after publication, at least in countries with some semblance of working democratic institutions. There are specific reasons why government publishers may not care for an ISBN, ISSN or any identifier other than their own, or perhaps an id from a catalog of record which in the US is the Library of Congress. Like published court opinions, government reports are authoritative records, not just reliable ones. 172.254.222.178 (talk) 00:46, 23 July 2022 (UTC)
 * Can we just redirect cite document to something other than cite journal as journal appears to be the wrong target. Keith D (talk) 11:40, 23 July 2022 (UTC)
 * The nomenclature is wrong, because it suggests that documents are self-contained, stand-alone publications. From the purview of the reader they rarely are, they are locations in another source. When they are published as stand-alone they fall (as a citable publication) under cite book. Perhaps the fit is not 100%, but it is good enough. We are discussing templates (forms) not custom-tailored solutions with a perfect match. Also, anyone is free to not use templates and structure a citation as they see fit. Or maybe a non-CS1 template can offer a better application. 68.173.78.83 (talk) 13:01, 23 July 2022 (UTC)
 * has existed as a redirect to [//en.wikipedia.org/w/index.php?title=Template:Cite_document&action=history ever since it was created way back in 2010]. If it were to be altered to redirect to another template, this would require a WP:RFD first. This would not be necessary if somebody were to alter it to be a full CS1 template in its own right. -- Red rose64 &#x1f339; (talk) 13:24, 23 July 2022 (UTC)
 * Been there, done that, got the bloodstained t-shirt: see Help talk:Citation Style 1/Archive 81 I think the conclusion was broadly that it is less than ideal but it is a complete can of vipers [sic] and filed under "too difficult". --John Maynard Friedman (talk) 15:27, 23 July 2022 (UTC)
 * Where is the difficulty? As was suggested in the previous conversation (and similar, much older ones) there is no such thing as a "document" citation class in the real world. A "document citation" template is as untenable as an "article citation" or a "song citation". As for the misdirected redirect, anyone can redirect a template to a citation template. That does  not make the underlying template responsible for any misalignment, or for the waste of time these recurring discussions are. 68.132.154.35 (talk) 15:44, 23 July 2022 (UTC)
 * So by that logic, the United States Declaration of Independence is a collective hallucination of millions of Americans since 1776. It is clearly not a journal. It is clearly not a web page. Nor a book. So Magna Carta is obviously a hoax! And Luther never wrote the Ninety-five Theses? Need I continue? --John Maynard Friedman (talk) 23:17, 23 July 2022 (UTC)
 * Ok, that is your interpretation, which is fine, but it has nothing to do with citing sources in general, or using structured citations in particular. 104.247.55.106 (talk) 13:03, 24 July 2022 (UTC)
 * The full publication information is on page 4: This article is a result of the research and subsequent book produced as part of the AHRC funded project ‘Controversies in Coal: Interment, Impoundment and Intrigue at Harworth Colliery (1913-1924) through the Centre for Hidden Histories at the University of Nottingham. The Project ran from September 2016 to April 2017. So find the book bib info and then you have several options: you could do a construction like: ", published in "; or you could put the two together in cite journal or cite encyclopedia, though the latter might be more appropriate since its effectively a collection of articles. (By the way, speaking of redirects, we really need a   redirect and collection alias for encyclopedia, since that makes up a huge amount of (intended) use cases, which is not obvious at all from the documentation.) SamuelRiv (talk) 05:12, 24 July 2022 (UTC)
 * This does not seem correct. As quoted above, and in the article, this was not "originally published in", and neither is it a research report. It is an article resulting from both, published in an unrelated platform, the Academia website. The closest existing matching template, if one wishes to use CS1 templates, is still . We cannot make up a probable imaginary provenance for it and retrofit into any other template. 204.19.162.34 (talk) 17:13, 24 July 2022 (UTC)
 * Imaginary provenance? The wording in the report is not precise -- to do diligence you would look up the book, and if it's an article in a collection then the above is the appropriate citation format. If a standalone article that later is published in a collection can't be cited in this way, that goes against the running consensus for why we allow preprints to be linked for journal citations and Google Books excerpts from eBooks to be linked for print books.
 * That being said, I looked up the book and in this particular case the book seems to be cited less than the paper. It must have been an institutional publication, because I've only found two citations to the book and some mentions on museum websites. Also for some reason it's missing on AHRC's projects page, though the project lead is there. So at the end of the day I couldn't find even a table of contents to verify if the book is the same as or contains the article, though they have the exact same title, author, and date. SamuelRiv (talk) 17:47, 24 July 2022 (UTC)
 * It seems you presume there was no due diligence related to the previous post? You would be wrong. You duplicated the steps taken to formulate the previous post, and all that is still irrelevant. The article is not a "report", "preprint", "paper" or whatever other label is wrongly assigned. It is based on the book (and the related research), according to the author. It is not a reprint or an extract from that book, and it should not be assigned to that source. It is content of a webpage in a website that includes similar items. Making it something that is not, will likely make it harder to find for readers who want to verify whatever wikitext it supports. 71.105.141.131 (talk) 22:02, 24 July 2022 (UTC)
 * As an experiment, I edited 50 of the articles that used the redirect.  I replaced the redirects with:
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * It seems you presume there was no due diligence related to the previous post? You would be wrong. You duplicated the steps taken to formulate the previous post, and all that is still irrelevant. The article is not a "report", "preprint", "paper" or whatever other label is wrongly assigned. It is based on the book (and the related research), according to the author. It is not a reprint or an extract from that book, and it should not be assigned to that source. It is content of a webpage in a website that includes similar items. Making it something that is not, will likely make it harder to find for readers who want to verify whatever wikitext it supports. 71.105.141.131 (talk) 22:02, 24 July 2022 (UTC)
 * As an experiment, I edited 50 of the articles that used the redirect.  I replaced the redirects with:
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * By far the most common replacement was (24×) followed by  and  (7× each).  It is unlikely that there is a simple 'automated fix' that converts a  redirect to some other, more correct template.  There may be some small subsets of  use that are amenable to fixes-by-script but, to be fixed properly, most  redirects will need humans to do the fixing.
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)
 * —Trappist the monk (talk) 19:32, 24 July 2022 (UTC)

Generic title
Hello, can "Page Title" at the start of a |title= be added to the generic title list. Currently about 25 occurrences. Thanks, Keith D Keith D (talk) 23:04, 22 July 2022 (UTC)

infobox and citation tag translation across wiki's
Has there been any thought to making sure the various infoboxes and citation tags across different wiki's are the same? I've translated a few items from and to English using the translation tool and more often than not it makes a mess of the citation tags being translated (to a lesser extent, infoboxes). It's a pain in the butt to try and figure out how to fix the citation tags after doing a translation. Oaktree b (talk) 14:50, 26 July 2022 (UTC)
 * Infoboxen are out of scope here. What do you mean by citation tags?  Did you mean to write 'citation templates'?  What citation templates?  What languages?  We do have some crude 'translation' templates that are automatically subst'd to a more-or-less appropriate cs1|2 template.  For example, the German template de:Vorlage:Literatur is a redirect  to .  If you copy a  template from de.wiki to en.wiki and save, User:AnomieBOT will subst that template with a 'translated' equivalent .  No guarantee that such translations are correct, they often aren't.  For other available 'translators' see.
 * —Trappist the monk (talk) 15:21, 26 July 2022 (UTC)
 * Such things can only be harmonised across all language Wikipedias if all can first agree on a common policy reagrding verifiability. German Wikipedia, for example, has nothing matching our and  tags. Does that mean that they insist on sources for everything - or that they don't care if something is sourced or not? Looking at sections like de:Michael Schumacher, I suspect the latter. -- Red rose64 &#x1f339; (talk) 18:38, 26 July 2022 (UTC)
 * I think the topic of how to write a citation is more or less separate from whether a citation is needed or not.
 * The citation templates in the English Wikipedia are based on English-language citation guides such as the Chicago Manual of Style and APA Style. I don't know how much citation customs in other languages resemble English-language customs. Jc3s5h (talk) 19:45, 26 July 2022 (UTC)

Section ≠ chapter
Is there a proper way to cite a particular section from a particular chapter from a particular part of a particular book, which is a particular supplement to a particular volume of a particular encyclopedia? Namely, there is a NASA publication called "Computers in Spaceflight: the NASA Experience", formally being "Volume: 18, Issue: Supplemet 3" of "Encyclopedia of Computer Science and Technology", but in fact it is a book and is also published on the Web, with separate webpages for each section. The structure is: I need to cite that section, and preferably without losing the rest of the structure information (chapter, part, book title and its location within the encyclopedia). Can this be done? doesn't even allow specifying chapter and section at the same time. — Mikhail Ryazanov (talk) 11:59, 26 July 2022 (UTC)
 * Book: "Computers in Spaceflight: The NASA Experience"
 * Part II: "Computers On Board Unmanned Spacecraft"
 * Chapter 6. "Distributed Computing On Board Voyager and Galileo" [no separate URL]
 * Section: "Voyager – The flying computer center"


 * Since the chapters are sequential across the parts (of which there are only 3), and I don't think the parts would be published in separate print volumes, I'd suggest omit the part name and just do title(book title), chapter[Chapter 6: Distributing ...], and at(section title) (it appears the sections are each bold title, not each separate webpage). SamuelRiv (talk) 15:30, 26 July 2022 (UTC)
 * (Sections there are separate webpages, as can be seen within the "Part II" link above. Bold titles within each section webpage correspond to subsections – which are not important here.)
 * Using at looks strange:
 * and issue is not shown at all (without any warnings). — Mikhail Ryazanov (talk) 21:53, 26 July 2022 (UTC)
 * The pdf version at archive.org uses the term 'issue' 15 times; none of which refer to an issue of an encyclopedia. The term 'Encyclopedia' is used only once (in §Foreword):
 * The Editors have taken the unusual step of devoting an entire Supplement volume of the Encyclopedia to a single topic: "Computers in Spaceflight: the NASA Experience."
 * Comparing these google-books scans, Volume 17 Supplement 2 and Volume 18 Supplement 3, it seems obvious that Supplement n is merely a subtitle of the volume number.
 * Two options I think, If you are citing the html version, :
 * if you are citing the book-length pdf, cite it as a book and forget about the encyclopedia:
 * —Trappist the monk (talk) 22:49, 26 July 2022 (UTC)
 * @Mikhail Ryazanov To add to Ttm, the encyclopedia can still be named in cite book per the series parameter (its usage in the template documentation is at "Complex usage showing effect of using volume parameter and lastauthoramp parameter (with volume and lastauthoramp)"). I agree that in this case "Supplement 3" belongs as part of the volume parameter. You should limit yourself to linking to either the pdf (from the NASA citations page or the one Ttm found) or the the web version, as both are free and readily accessible and you generally want to minimize ambiguity of which source was originally used. The at parameter is supposed to be for any kind of pinpoint (except page), so you would have to denote "sec.", "subsec.", "§", "para.", or whatever you need to do to (ideally) get as precise or as broad a pinpoint as is best for verification. The form Ttm shows is fine too. SamuelRiv (talk) 23:47, 26 July 2022 (UTC)
 * Well, since also complains about external links in section, the best I could do was to use chapter § section and URL (instead of more logical chapter § [URL). But it would be much better if the template could handle chapter and section together, with corresponding ...-url. Regarding "limit to linking to either the pdf or the the web version", the problem is that the PDF is really huge, so linking to a lightweight web page makes much more sense, but the web version doesn't have proper bibliographic information, thus it also makes sense to link to the NASA bibliographic page for the whole book. After all,  allows multiple simultaneous links (doi, pubmed, jstor, ...) and wiki-linking the journal itself, and  also has isbn "linking" to the whole book record even when url is much more specific. — Mikhail Ryazanov (talk) 18:14, 28 July 2022 (UTC)
 * The approach is incorrect. Instead consider this: when a wikitext claim is made, it is hopefully supported by a source known to the editor. The only thing citations are concerned with is revealing that source to the reader in the least-complicated way possible. The location of bibliographic information is not entirely relevant, as what is cited in this case is not a bibliographic record, but the specific content and way(s) to find it. The reason behind multiple content identifiers is redundancy with as little clutter as possible. Classification/marketing identifiers such as ISBN or OCLC help in finding the content, not exposing it, and serve a different purpose. And do not forget that in many cases, online PDFs allow page-linking. 24.103.63.182 (talk) 12:22, 29 July 2022 (UTC)
 * —Trappist the monk (talk) 22:49, 26 July 2022 (UTC)
 * @Mikhail Ryazanov To add to Ttm, the encyclopedia can still be named in cite book per the series parameter (its usage in the template documentation is at "Complex usage showing effect of using volume parameter and lastauthoramp parameter (with volume and lastauthoramp)"). I agree that in this case "Supplement 3" belongs as part of the volume parameter. You should limit yourself to linking to either the pdf (from the NASA citations page or the one Ttm found) or the the web version, as both are free and readily accessible and you generally want to minimize ambiguity of which source was originally used. The at parameter is supposed to be for any kind of pinpoint (except page), so you would have to denote "sec.", "subsec.", "§", "para.", or whatever you need to do to (ideally) get as precise or as broad a pinpoint as is best for verification. The form Ttm shows is fine too. SamuelRiv (talk) 23:47, 26 July 2022 (UTC)
 * Well, since also complains about external links in section, the best I could do was to use chapter § section and URL (instead of more logical chapter § [URL). But it would be much better if the template could handle chapter and section together, with corresponding ...-url. Regarding "limit to linking to either the pdf or the the web version", the problem is that the PDF is really huge, so linking to a lightweight web page makes much more sense, but the web version doesn't have proper bibliographic information, thus it also makes sense to link to the NASA bibliographic page for the whole book. After all,  allows multiple simultaneous links (doi, pubmed, jstor, ...) and wiki-linking the journal itself, and  also has isbn "linking" to the whole book record even when url is much more specific. — Mikhail Ryazanov (talk) 18:14, 28 July 2022 (UTC)
 * The approach is incorrect. Instead consider this: when a wikitext claim is made, it is hopefully supported by a source known to the editor. The only thing citations are concerned with is revealing that source to the reader in the least-complicated way possible. The location of bibliographic information is not entirely relevant, as what is cited in this case is not a bibliographic record, but the specific content and way(s) to find it. The reason behind multiple content identifiers is redundancy with as little clutter as possible. Classification/marketing identifiers such as ISBN or OCLC help in finding the content, not exposing it, and serve a different purpose. And do not forget that in many cases, online PDFs allow page-linking. 24.103.63.182 (talk) 12:22, 29 July 2022 (UTC)
 * Well, since also complains about external links in section, the best I could do was to use chapter § section and URL (instead of more logical chapter § [URL). But it would be much better if the template could handle chapter and section together, with corresponding ...-url. Regarding "limit to linking to either the pdf or the the web version", the problem is that the PDF is really huge, so linking to a lightweight web page makes much more sense, but the web version doesn't have proper bibliographic information, thus it also makes sense to link to the NASA bibliographic page for the whole book. After all,  allows multiple simultaneous links (doi, pubmed, jstor, ...) and wiki-linking the journal itself, and  also has isbn "linking" to the whole book record even when url is much more specific. — Mikhail Ryazanov (talk) 18:14, 28 July 2022 (UTC)
 * The approach is incorrect. Instead consider this: when a wikitext claim is made, it is hopefully supported by a source known to the editor. The only thing citations are concerned with is revealing that source to the reader in the least-complicated way possible. The location of bibliographic information is not entirely relevant, as what is cited in this case is not a bibliographic record, but the specific content and way(s) to find it. The reason behind multiple content identifiers is redundancy with as little clutter as possible. Classification/marketing identifiers such as ISBN or OCLC help in finding the content, not exposing it, and serve a different purpose. And do not forget that in many cases, online PDFs allow page-linking. 24.103.63.182 (talk) 12:22, 29 July 2022 (UTC)

automatic live v. sandbox suggestions-module selection tweak
Unlike all other modules in the cs1|2 module suite, the list of suggestions (Module:Citation/CS1/Suggestions or Module:Citation/CS1/Suggestions/sandbox) is only loaded when it is needed. Editor Tholme points out that the mechanism that decides whether to load ~Suggestions or ~Suggestions/sandbox needs improvement. That editor offered one solution that I knee-jerk reverted. Correctly, my revert was reverted and I have since improved on Editor Tholme's fix.

—Trappist the monk (talk) 18:42, 30 July 2022 (UTC)
 * Thanks, your fix was off course a lot better :) Would it also be possible to move the sandbox i18n variable to Module:Citation/CS1/Configuration? This way we can import the Module:Citation/CS1 to other languages without doing any changes in this module. Tholme (talk) 19:45, 30 July 2022 (UTC)
 * I don't think that that is possible because Module:Citation/CS1/sandbox doesn't know to load the sandboxen submodules until it examines its own invoke. So to do what you suggest, Module:Citation/CS1/sandbox would need to load Module:Citation/CS1/Configuration to know that it needs to load Module:Citation/CS1/Configuration/sandbox.  An alternative might be to do something like I have done at this edit to Module:Citation/CS1/sandbox.  This requires all templates that invoke Module:Citation/CS1/sandbox to have a new parameter SandboxPath.  At  the new parameter is /sandbox.  At no.wiki the templates that invoke no:Modul:Citation/CS1/sandkasse are listed here.
 * —Trappist the monk (talk) 22:24, 30 July 2022 (UTC)
 * Yes, that is off course a problem... Thanks for your suggestion with a new parameter, but I think this is more work than just updating  in Module:Citation/CS1. I do think it would be ok if this module checked for variable sandbox in Module:Citation/CS1/Configuration and not Module:Citation/CS1/Configuration/sandbox. There would be need to be a comment that the sandbox variable needs to be correct in the live module and not only in the sandbox. This would also mean that the sandbox module will need to load Module:Citation/CS1/Configuration first, and then afterward read all the other configuration from Module:Citation/CS1/Configuration/sandbox. I think this should work. Would you be ok with an implementation like this? Tholme (talk) 23:41, 30 July 2022 (UTC)
 * Or maybe load it from  in Module:Documentation/config? It seems like most wikis uses this. Tholme (talk) 00:13, 31 July 2022 (UTC)
 * Interesting notion, that. But, at present, 187 MediaWiki wikis use Module:Citation/CS1 (see ) but only 111 use Module:Documentation/config (see ).  Yeah, updating 12 templates at no.wiki (36 here) is a bit of extra work but that work only needs doing once – there are wikis out there that do not sandbox their cs1|2 module suite so no extra work for them ...  I'm not so much in favor of borrowing code from outside of cs1|2 because that code is not beholden to us so can be modified to suit its primary purpose which might break cs1|2.
 * I've tweaked my prospective code a bit to protect against SandboxPath (parameter present without assigned value which returns an empty string; which would make sandbox module name same as live module name):
 * The way the prospective code is written, when a sandbox template doesn't have SandboxPath, Module:Citation/CS1 will use whatever default sandbox name is provided in the module.
 * —Trappist the monk (talk) 11:58, 31 July 2022 (UTC)
 * It occured to me that something like this might work:
 * This returns whatever text follows that last  in the invoking template's name.  But, there is no guarantee that whatever text follows the last   will be the 'sandbox'.  For example, at en.wiki we have a series of (very) crude translator templates that have the form  so the above will return   to the live module.  Not a good idea...
 * —Trappist the monk (talk) 16:07, 31 July 2022 (UTC) 16:20, 31 July 2022 (UTC) (strike)
 * Well that's not quite true.  wraps a cs1|2 template and it is  template name that is returned by   so if the wrapped template is a sandbox template then perhaps this mechanism will work.  At en.wiki there is of course the  variant that we have used for a very long time in place of.
 * —Trappist the monk (talk) 16:20, 31 July 2022 (UTC)
 * Thanks for your efforts. I think I will just stick with changing the sandbox variable in Module:Citation/CS1 after import. Tholme (talk) 21:39, 31 July 2022 (UTC)
 * —Trappist the monk (talk) 16:07, 31 July 2022 (UTC) 16:20, 31 July 2022 (UTC) (strike)
 * Well that's not quite true.  wraps a cs1|2 template and it is  template name that is returned by   so if the wrapped template is a sandbox template then perhaps this mechanism will work.  At en.wiki there is of course the  variant that we have used for a very long time in place of.
 * —Trappist the monk (talk) 16:20, 31 July 2022 (UTC)
 * Thanks for your efforts. I think I will just stick with changing the sandbox variable in Module:Citation/CS1 after import. Tholme (talk) 21:39, 31 July 2022 (UTC)

ISBD reference
International Standard Bibliographic Description. May be used as an authoritative reference in discussion of structured citations.
 * ISBD 2011
 * ISBD 2021 Update
 * 68.132.154.35 (talk) 14:20, 31 July 2022 (UTC)

Protected edit request on 1 August 2022
Please change the link ISBN (identifier) in cite book to ISBN. <b style="color: black;">Kailash29792</b> (talk)  11:01, 1 August 2022 (UTC)
 * This would require a full RFC not just for ISBNs, but all identifiers. &#32; Headbomb {t · c · p · b} 13:18, 1 August 2022 (UTC)
 * I could be mistaken but I think Kailash29792 is asking for the wikilinks in the documentation to be changed from ISBN (identifier) to ISBN. Not sure why though as the identifier page is already a redirect to ISBN. Sideswipe9th (talk) 14:43, 1 August 2022 (UTC)
 * I interpreted the request to change the output of the template, not the documentation. The templates intentionally link through the redirect so that they can be filtered out in the Special:WhatLinksHere page for the article on ISBN. (Ditto all of the other identifiers.) Linking directly to the article in this way would break this filtering technique. It would require an RfC to overcome the past decisions on this topic.  Imzadi 1979  →   17:06, 1 August 2022 (UTC)

PMC numbers have gone beyond 9300000
See tecovirimat where a citation to pmc=9300470 is now showing an error. Please increase limit in the validation code. Thanks. Mike Turnbull (talk) 11:20, 1 August 2022 (UTC)


 * ✅ Thanks, whoever fixed that. Mike Turnbull (talk) 13:34, 1 August 2022 (UTC)

Demeter's Manual of Parliamentary Law and Procedure


Whats the issue with this citation? &#32; Headbomb {t · c · p · b} 13:05, 1 August 2022 (UTC)
 * ALL citations seems to be broken.AManWithNoPlan (talk) 13:05, 1 August 2022 (UTC)


 * Wikipedia broken ☹️  Bluerasberry   (talk)  13:09, 1 August 2022 (UTC)
 * Wikipedia broken[Citation needed] Simeon (talk) 13:11, 1 August 2022 (UTC)


 * Maybe this? https://en.wikipedia.org/w/index.php?title=Module:Citation/CS1/Configuration&diff=1101715557&oldid=1096144888 AManWithNoPlan (talk) 13:12, 1 August 2022 (UTC)
 * I thought that, but if you see the section above the error preexists that edit. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 13:18, 1 August 2022 (UTC)

Whatever it was, it seems fixed now. &#32; Headbomb {t · c · p · b} 13:17, 1 August 2022 (UTC)


 * Well that was nasty, but the sea of red I was seeing across all articles using sfn is now gone. Sandy Georgia (Talk)  13:20, 1 August 2022 (UTC)
 * Sea of red still there for me, for example on Cycloheptatriene. Mike Turnbull (talk) 13:22, 1 August 2022 (UTC)
 * @Michael D. Turnbull: Purging the page resolved the issue. GoingBatty (talk) 13:25, 1 August 2022 (UTC)
 * Yes, thanks. Now you only have to purge 6 million+ other pages! (I jest). Mike Turnbull (talk) 13:26, 1 August 2022 (UTC)

Wikipedia Signpost/2022-08-01/Tips and tricks
Just a heads up that my little handy dandy guide on Citation bot finally got in the Signpost, as intended years ago. Feel free to leave a comment (or make suggestions for other guides on different topics). &#32; Headbomb {t · c · p · b} 20:04, 1 August 2022 (UTC)

url-status parameter invalid
The instructions indicate the use of |url-status=deviated, and when the original URL has been usurped for the purposes of spam, advertising, or is otherwise unsuitable, setting |url-status=unfit or |url-status=usurped. And, at Category:CS1 errors: invalid parameter value it says that these values are valid. However, at Category:CS1 maint: unfit URL it does not accept these values. Can this be fixed so that green hidden "One or more cite news templates have maintenance messages" for their use can be avoided? --Bejnar (talk) 17:48, 3 August 2022 (UTC)
 * See also Category talk:CS1 maint: unfit URL which hasn't been addressed. --Bejnar (talk) 18:11, 3 August 2022 (UTC)
 * It is not clear to me what it is that you are saying. deviated, unfit, and usurped are all valid:
 * – the rendered citation links to the url assigned to url as a secondary link
 * – the rendered citation does not link to the url assigned to url
 * – the rendered citation does not link to the url assigned to url
 * Were these parameter values invalid, cs1|2 would return an error message:
 * – all keywords used in cs1|2 templates must be lowercase
 * What do you mean by: at Category:CS1 maint: unfit URL it does not accept these values? There are  articles in that category so something must be happening.
 * —Trappist the monk (talk) 18:27, 3 August 2022 (UTC)
 * See, for example, this citation:
 * – all keywords used in cs1|2 templates must be lowercase
 * What do you mean by: at Category:CS1 maint: unfit URL it does not accept these values? There are  articles in that category so something must be happening.
 * —Trappist the monk (talk) 18:27, 3 August 2022 (UTC)
 * See, for example, this citation:
 * See, for example, this citation:

[Cite news|last=Masi |first=Alessandria |date=14 December 2015 |title=Saudi Coalition, Houthi Rebels Intensify Attacks In Yemen Ahead Of Proposed Ceasefire |newspaper=International Business Times |url=http://www.ibtimes.com/saudi-coalition-houthi-rebels-intensify-attacks-yemen-ahead-proposed-ceasefire-2223830 |archive-url=https://web.archive.org/web/20161004172106/http://www.ibtimes.com/saudi-coalition-houthi-rebels-intensify-attacks-yemen-ahead-proposed-ceasefire-2223830 |archive-date=4 October 2016 |url-status=unfit ] at December 2015 Taiz missile attack which yields an error. I marked it as unfit, because the article is occluded at the original website. If "unfit" needs to be checked, then how is the error cleared? --Bejnar (talk) 18:37, 3 August 2022 (UTC)
 * Maintenance messages are not error messages.
 * For me, the url http://www.ibtimes.com/saudi-coalition-houthi-rebels-intensify-attacks-yemen-ahead-proposed-ceasefire-2223830 is not .  There is no mechanism to mark urls that are geographically limited – is that your issue?  I think that we have discussed this before; if we have, we did not decide to do anything about geographically limited urls.  Marking a geographically limited url as unfit does not seem to me to be a good idea; the url is fit to be viewed – it isn't spam or porn or a phishing site, etc – so should not be labeled as.
 * —Trappist the monk (talk) 19:04, 3 August 2022 (UTC)
 * It was not geographically limited. When access was attempted this morning, the article was occluded by a "please subscribe" overlay with no "close" function. Now when I access it, it displays properly, and the url-status can be reset to live.  But that was just an example, my question still is, as modified, if maintenance is required for those 21 thousand articles, how is it to be accomplished? That is, what is the review procedure that affirms a valid use of the value "unfit" for that parameter? --Bejnar (talk) 22:19, 3 August 2022 (UTC)
 * If the site requires a subscription then subscription is the correct parameter to use.
 * There is no required action for most maintenance messages. Alas, some maintenance categories (,‎, ) should emit error messages but those categories apply to so many articles that making them error messages would cause a torches-and-pitchforks uprising; we've seen that kind of uprising before and it isn't pretty.
 * —Trappist the monk (talk) 23:09, 3 August 2022 (UTC)
 * There is no required action for most maintenance messages. Alas, some maintenance categories (,‎, ) should emit error messages but those categories apply to so many articles that making them error messages would cause a torches-and-pitchforks uprising; we've seen that kind of uprising before and it isn't pretty.
 * —Trappist the monk (talk) 23:09, 3 August 2022 (UTC)

url-status = deviated
What is the recommended action when a cite with deviated is converted to a dead link. Normally it is flipped to dead. -- Green  C  18:08, 3 August 2022 (UTC)
 * If a  url becomes   (returns 404) then deviated should be removed.  No need to replace it with dead because cs1|2 assumes that the url in url is dead when archive-url has an assigned url.
 * —Trappist the monk (talk) 18:32, 3 August 2022 (UTC)

pmid limit
"If the value is correct and larger than the currently configured limit of 35900000, please report this at Help talk:Citation Style 1, so that the limit can be updated."

https://pubmed.ncbi.nlm.nih.gov/35918775/ Aethyta (talk) 19:47, 3 August 2022 (UTC)