Help talk:Citation Style 1/Archive 95

This is an archive of past discussions about Help:Citation Style 1. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 90

←

Archive 93

Archive 94

Archive 95

Archive 96

While looking through the parameters of Template:Cite magazine, I noticed that the 'others' parameter is the recommended means by which illustrators should be listed. As the 'authors' parameter was deprecated for not contributing to the citation's metadata, shouldn't a separate, optional 'illustrator' (aliases 'illustrator-last', 'illustrator-surname', 'illustrator1', 'illustrator1-last', 'illustrator1-surname', 'illustrator-last1', 'illustrator-last1'), 'illustrator-first' (aliases 'illustrator-given', 'illustrator1-first', 'illustrator1-given', 'illustrator-first1', 'illustrator-given1'), 'villustrators' (Vancouver style), and 'display-illustrators' (to determine when et al. is added) parameters be added, to ensure documented magazine illustrators are searchable as metadata in a format similar to the ones established for authors and editors?

The 'others' parameter would still be kept, of course, as a catch-all parameter for any additional contributors. -CoolieCoolster (talk) 23:36, 11 May 2024 (UTC)

There is also photographer. Some books the photography is the main content or the most notable contributor.

Looking at {{cite book}} it says:

others: To record other contributors to the work, including illustrators. For the parameter value, write Illustrated by John Smith

So I guess if you free form Illustrated by Name, it would be possible to search the metadata. In practice editors might say things like: Illustrator: Name or Name (illustrator) etc.. the main thing is the ability to search on the word "illustrator" or "illustrated" in the others field. This is messy I agree and makes parsing error prone. OTOH how to deal with a couple dozen common occupations without blowing up the complexity of citations. Maybe if the keynames were associative arrays eg. |others[illustrators]=Joe Smith, Bill Barn |others[photographers]=Mary Sue .. -- GreenC 15:29, 27 May 2024 (UTC)

|others= is a free-input parameter. If you want the very reader-unfriedly Vancouver style, you just do |others=Jones VT, Smith AM (illustrators). These templates are already excessively complex, and we do not need a whole new multiplying set of parameter variants for every imaginable kind of "other", especially as it also leads to a bunch of numbered variants of them: |illustrator5-last=, etc., etc.  — SMcCandlish ☏ ¢ 😼  16:33, 11 June 2024 (UTC)

PDFs often have page numbers printed on each page, but these are offset from the page numbers of the digital PDF file due to title pages, forewords, etc. Normally we only cite the page number printed on the page we're citing. Could we add another page number parameter for the digital page number in such a document? Maybe we could call it "digital page", "PDF page", "digital document page", or "digital version page". Toadspike [Talk] 12:06, 27 May 2024 (UTC)

I frequently add the page number to the URL as described at WP:PAGELINKS. (Further documentation: [1][2]).

{{harvtxt|Abate|1998|p=[https://scholar.csl.edu/cgi/viewcontent.cgi?article=1124&context=thd#page=10 2]}}

Abate (1998, p. 2) harvtxt error: no target: CITEREFAbate1998 (help)

I'd be reluctant to add this to the visible citation, since I don't presume that future readers will be looking at the exact same PDF that I am. PDFs may eventually become deprecated and readers will view some other file format. The publisher may use OCR software to detect the printed page numbers and add it to the PDF file. In the latter case, the URL doesn't change, but the way page numbers are displayed to users will change, which could make notes about PDF page numbers to users confusing. Daask (talk) 14:48, 27 May 2024 (UTC)

Agreed. Also different PDF readers might give different page numbers, depending which page it considers #1 and how it counts - there is an internal algorithm that can't be assumed to be universal for every reader. -- GreenC 14:58, 27 May 2024 (UTC)

This is another routine request that has fair objections, as above. Izno (talk) 16:11, 27 May 2024 (UTC)

To add to the objections, the PDF-format e-book pagination of something is not likely to match other e-book formats (ePub, etc.). And if the document is replaced later with a new version, the PDF pagination may completely change, because whoever generated it use a different print-to-PDF tool. There are means of linking to specific "PDF pages" in documents, that are respected by some (not all) browsers, and I suppose such a link culd be used around the page number in |page=. But even that's kind of iffy, for the aforementioned reason: if the document is later updated, that link might go to the wrong spot in the document. My practice has been to give the visible page number in the work, and if it lacks such numbering, then identify the in-document location some other way, e.g. |at="Dallas, Texas" entry, or |at=§ 8.52.7.  — SMcCandlish ☏ ¢ 😼  16:48, 11 June 2024 (UTC)

I propose that we prioritize linking to articles provided by the publisher over third-party repositories when both are open access.

When a citation template doesn't supply |url=, the URL linked by the title text is supplied instead by identifiers when an open access version is known to be available. My proposal only changes which open access version is linked when multiple options are available.

Consider the following citations of the same work:

When |pmc= is given, then a link is provided to PubMed Central because all PubMed Central articles are open access.

• {{cite journal | last=Pashler | first=Harold | last2=Heriot | first2=Gail | date=2018 | title=Perceptions of newsworthiness are contaminated by a political usefulness bias | journal=Royal Society Open Science | volume=5 | issue=8 | page=172239 | issn=2054-5703 | pmid=30224994 | pmc=6124072}}

  Pashler, Harold; Heriot, Gail (2018). "Perceptions of newsworthiness are contaminated by a political usefulness bias". Royal Society Open Science. 5 (8): 172239. ISSN 2054-5703. PMC 6124072. PMID 30224994.

When |doi-access=free, a link is provided to that DOI.

• {{cite journal | last=Pashler | first=Harold | last2=Heriot | first2=Gail | date=2018 | title=Perceptions of newsworthiness are contaminated by a political usefulness bias | journal=Royal Society Open Science | volume=5 | issue=8 | page=172239 | issn=2054-5703 | pmid=30224994 | doi=10.1098/rsos.172239}}

  Pashler, Harold; Heriot, Gail (2018). "Perceptions of newsworthiness are contaminated by a political usefulness bias". Royal Society Open Science. 5 (8): 172239. doi:10.1098/rsos.172239. ISSN 2054-5703. PMID 30224994.

• {{cite journal | last=Pashler | first=Harold | last2=Heriot | first2=Gail | date=2018 | title=Perceptions of newsworthiness are contaminated by a political usefulness bias | journal=Royal Society Open Science | volume=5 | issue=8 | page=172239 | issn=2054-5703 | pmid=30224994 | doi=10.1098/rsos.172239 | doi-access=free}}

  Pashler, Harold; Heriot, Gail (2018). "Perceptions of newsworthiness are contaminated by a political usefulness bias". Royal Society Open Science. 5 (8): 172239. doi:10.1098/rsos.172239. ISSN 2054-5703. PMID 30224994.

When both |doi= and |pmc= are provided, PubMed Central is linked

• {{cite journal | last=Pashler | first=Harold | last2=Heriot | first2=Gail | date=2018 | title=Perceptions of newsworthiness are contaminated by a political usefulness bias | journal=Royal Society Open Science | volume=5 | issue=8 | page=172239 | issn=2054-5703 | pmid=30224994 | pmc=6124072 | doi=10.1098/rsos.172239}}

  Pashler, Harold; Heriot, Gail (2018). "Perceptions of newsworthiness are contaminated by a political usefulness bias". Royal Society Open Science. 5 (8): 172239. doi:10.1098/rsos.172239. ISSN 2054-5703. PMC 6124072. PMID 30224994.

• {{cite journal | last=Pashler | first=Harold | last2=Heriot | first2=Gail | date=2018 | title=Perceptions of newsworthiness are contaminated by a political usefulness bias | journal=Royal Society Open Science | volume=5 | issue=8 | page=172239 | issn=2054-5703 | pmid=30224994 | pmc=6124072 | doi=10.1098/rsos.172239 | doi-access=free}}

  Pashler, Harold; Heriot, Gail (2018). "Perceptions of newsworthiness are contaminated by a political usefulness bias". Royal Society Open Science. 5 (8): 172239. doi:10.1098/rsos.172239. ISSN 2054-5703. PMC 6124072. PMID 30224994.

I am proposing a change only for the very last example, when both |pmc= is given and |doi-access=free. Currently, it links to PubMed Central. I think we should link to the DOI, since this is more likely provided by the publisher rather than a third-party repository.

My primary reason for this change is that some articles in PubMed Central appear to be preprints rather than the final published version, eg. PMC 6688940. (Note the text change following the mention of Salpiglossis sinuata.) Additionally, I think its worthwhile to encourage traffic to open access publishers.

Minor considerations:

1. Both PubMed Central's HTML version and the publisher's HTML version sometimes have formatting issues that the other one does not. eg. In this publisher's version, quotes lack italics or sufficiently different indentation to clearly differentiate from body text. Not an issue in PubMed Central.
2. The DOI sometimes, but rarely, links directly to a PDF, whereas PMC always links to an HTML, with a PDF usually available, eg. PMC 5780623
3. Are publishers more likely to have supplementary data? A quick glance at some sample articles didn't indicate this, but I suspect it is sometimes true.

Daask (talk) 14:24, 27 May 2024 (UTC)

The reason PMC takes precedence over DOI is historical and rooted in PMC autolinking before (free) DOIs did. Possibly because PMC version is lightweight, reduces data consumption (important on mobile and pay-per-GB internet plans) and does not require a PDF reader. Not saying this shouldn't be changed, just why this is currently the case.

Really we should have a hierarchy of priority for when multiple identifiers are free (like if |doi-access=free and |jstor-access=free) so that autolinking apply to all version of record identifiers (i.e. not arxiv/ssrn/s2cid, etc...), which should be manually overridable i.e. |auto-url=jstor. Headbomb {t · c · p · b} 23:04, 28 May 2024 (UTC)

That sounds reasonable, other than I'm skeptical we really need an override once a "cascade" of preference is established; the reasons to do an override would probably be very subjective. If we did implement one, |auto-url= doesn't make much sense to me, since if you're doing a manual override that's the opposite of automated. (Plus as semantic/pedantic matter, auto- actually means 'self-'; an autoimmune disorder is an immune-system response to some of one's own cells, not an immune response to automation or brought about by automata.)  — SMcCandlish ☏ ¢ 😼  16:55, 11 June 2024 (UTC)

As mentioned, the template continues to be broken, failing to display |issue= content in most instances. As mentioned by other editors, no, this isn't how it used to work and I wasn't insane/delusional to think so. As mentioned by other editors, no, there is no benefit or reasonable purpose to shutting it off. As mentioned by other editors, yes, it's generally beneficial to add the functionality even if (which wasn't ever the case) I had been delusional and just imagined the template worked better during a fever dream. Anyone who wants fiddlely use-specific coding can already choose between {{cite book}}, {{cite journal}}, {{cite web}}, {{whatever}}. This should be a decent multipurpose default template and there's no reason not to allow it to be.

Now, y'know, go ahead and actually fix it. Please. Thank you. — LlywelynII 23:40, 28 May 2024 (UTC)

This is a feature, not a bug. Books have no issues, so they shouldn't support |issue=. Same for websites. Journal have issues, so cite journal supports that parameter. Headbomb {t · c · p · b} 02:30, 29 May 2024 (UTC)

I believe the template under discussion here is {{Citation}}, which is not exclusively used to cite books. Folly Mox (talk) 02:34, 29 May 2024 (UTC)

I think the previous discussion said all that needed to be said. Llywelyn bringing it up again as if their point of view had consensus is simply disruptive. Izno (talk) 02:40, 29 May 2024 (UTC)

I agree that there should be a multipurpose template that displays every parameter you feed it, but I'm not upset that there isn't. Folly Mox (talk) 03:00, 29 May 2024 (UTC)

Here's {{cite magazine}} with |mode=cs2, which should meet the OP's need: "Article title", Magazine title, vol. 42, no. 69, Spring 2004. And here's {{citation}} with the same parameters: "Article title", Magazine title, vol. 42, no. 69, Spring 2004. Works for me. – Jonesey95 (talk) 03:51, 29 May 2024 (UTC)

There is one, but it's based on what parameters you feed it. If you feed it book parameters then it will format as a book. -- LCU ActivelyDisinterested «@» °∆t° 11:10, 29 May 2024 (UTC)

I don't want to put words in LlewellynII's keyboard's mouth, but it seems like that's part of the problem: {{Citation}} overthinks things, and requires editors to learn and remember which parameters it considers "book parameters" and which it considers "serial / periodical parameters", and that it cares if you try to mix and match them.

If, for some reason, an editor has a preference for |contribution= + |title= over |title= + |work=, and supplies |issue=, maybe it's not necessary to assume that the |issue= was unintentional / unimportant / impossible, and just display it anyway.

I understand this probably would require rewriting some subroutines and would also probably negate the ability to output clean metadata, but it would flatten the learning curve. My gnoming job security is based on citation templates being fiddly and algorithms doing a bad job at filling them out properly, so maybe I shouldn't be supporting changes like this, but I did want to demonstrate that there's more than one person in favour of an easy to use catchall template that behaves as expected even if the parameter aliases chosen are non-standard. Folly Mox (talk) 11:52, 29 May 2024 (UTC)

I don't think it's to difficult to understand that using |journal= is required if you citing a journal. The issue I see with displaying any parameter is what formating and placement should be applied to random parameters, and should that vary depending on what other parameters are supplied. The issue is that a certain set of formating / placement is desired but without supplying the information required to do that. -- LCU ActivelyDisinterested «@» °∆t° 12:09, 29 May 2024 (UTC)

Yeah, but this is just sort of the price we pay for continuing to support {{Citation}} (CS2), despite it being used less than 1% of the time in our citations, and almost never consistently within the article. Per WP:CITESTYLE, if we encounter an article with a mixture of citation styles, that mess should be normalized to a single style. For my part, I normalize always to CS1 (and cite the guideline as the rationale). To date, I have never been reverted on it. CS2 is basically doomed. The fact that nearly no one uses it (in part because of its "I have to remember a bunch of quirks" issues), and a large number of casual editors aren't even aware it exists, means inevitably that articles that maybe started out using it, or more-or-less-predominantly using it, become more and more CS1 over time (unless at some super-obscure page no one touches), then the more inconsistent they get the more likely it is they'll get normalized to a single style, which will usually be CS1. This is a set of effects causing a synergistic not just linear shift toward CS1. PS: The only real rationale I've ever seen offered for CS2 is that CS1 weirdly uses "." as a separator, and produces a "choppy fragments" effect that some people don't like. So, just switch to ";" and the problem goes away, along with any further inspiration to use CS2 at all. For an off-site project, I use a lot of more-or-less-WP-style citations, and have been using ";" as the citation parameter separator, and it's perfectly fine for this purpose. Even if you have mutiple "last1, first1; last2, first2;" authors in series, it's clear that they're authors and when you encounter "The onomastic heritage of Strathclyde" or whatever, you've moved on from the author list to the title of the paper/whatever. Sticking a grammatically nonsensible "." in there is a solution in search of a problem.  — SMcCandlish ☏ ¢ 😼  16:28, 11 June 2024 (UTC)

Since CS1 and CS2 are quite similar in output, I've suggested that the two styles be merged together to eliminate the need to support two. For those who like using {{citation}}, they could continue to do so, and for those who prefer the other templates, they could continue to use them, and we'd get harmonious output in the end. Imzadi 1979 → 00:28, 12 June 2024 (UTC)

Used to be simple to handle with |vol=I, II, &c. . The template currently throws out errors when |vol= has a URL in it. Surely it isn't necessary to run entire citation template for every volume of a multivolume work. I assume there's a workaround for the reduced functionality, but it's not obvious or clear from the documentation what it is. So... what is it? — LlywelynII 23:56, 28 May 2024 (UTC)

Per WP:SAYWHEREYOUREADIT and perhaps other guidance, cite the volume that supports the claim you are making in the article. – Jonesey95 (talk) 03:53, 29 May 2024 (UTC)

Indeed. Citing 2+ volumes of a work and making the reader try to guess which one is pertinent is "user-hateful". People keep getting confused into thinking that our citations and the templates we use for them serve some kind of bibliographic-catalogue purpose, and keep listing things like total number of volumes, total number of pages, form-factor of the edition/printing ("hardback", etc.), and even trying to list out all the different editions. This is not what they are for. They are for and only for helping the reader find the specific material in the specific source being cited by our article so that the claims in the material can be verified.  — SMcCandlish ☏ ¢ 😼  16:15, 11 June 2024 (UTC)

I started an FAQ for this page at Help talk:Citation Style 1/FAQ because of this discussion. IDK if we even actually need a separate page for the FAQ or if we can just put it on Help:CS1 or something. But I do think it would be valuable to have something for recurring comments/requests. Izno (talk) 23:35, 1 June 2024 (UTC)

There are templates for integrating FAQs into pages like this; see, e.g., the top of WT:MOS.  — SMcCandlish ☏ ¢ 😼  15:43, 11 June 2024 (UTC)

Is the agency parameter still working in the Cite book template? It is listed as an active template parameter on Template:Cite_book/TemplateData but the template is throwing up Unknown parameter errors, e.g. Template:Cite_OED_1933/doc Skullcinema (talk) 14:04, 26 April 2024 (UTC)

I suspect that you meant to write: [[Template:Cite_OED_1933/doc|here]] → here.

Support for |agency= in templates that shouldn't support that parameter was removed as a result of this discussion. |agency= is defined for {{cite news}}, {{cite press release}}, and {{cite web}}. Also supported by {{citation}} when that template has |newspaper= or |work=.

—Trappist the monk (talk) 23:36, 26 April 2024 (UTC)

I have encountered several of these |agency= in book citations in cleaning up CS1 errors. All the ones I have seen should instead have been |publisher=. I have seen no evidence that |agency= is actually a useful and meaningful parameter for these citations. —David Eppstein (talk) 02:09, 27 April 2024 (UTC)

In this particular case I was looking for a way to reflect the Philological Society's contribution to the work.

Obviously there are two reasons for citing a work, one to identify where the source material can be found and the second to give credit to the creators of the work. The OED is atypical for a book in that there were a myriad of contributing authors and the publisher came into the process 20 years after the start of the work.

If not |agency= would you have another option for crediting the Society within the citation? — Skullcinema (talk) 15:55, 3 May 2024 (UTC)

As the work was based on materials they helped collect would |others= be appropriate? e.g.
Murray, James A. H.; Bradley, Henry; Craigie, W. A.; Onions, C. T., eds. (1933). The Oxford English Dictionary; being a corrected re-issue with an introduction, supplement and bibliography of A New English Dictionary on Historical Principles. The Philological Society (1st ed.). Oxford: Clarendon Press. ISBN 0198611013. LCCN a33003399. OCLC 2748467. OL 180268M. -- LCU ActivelyDisinterested «@» °∆t° 21:13, 3 May 2024 (UTC)

Thanks, that will work fine. — ROU Skullcinema (talk) 22:23, 3 May 2024 (UTC)

Can we please not remove parameters breaking hundreds or thousands of article citations? The agency parameter was used in tons of {{cite report}} citations for weather-related articles citing NOAA government offices / agencies. Even if your argument is that these are "incorrect" or whatever, really seems bad to just break literally thousands of citations with no backup plan. Master of Time (talk) 09:11, 28 April 2024 (UTC)

If one is to believe the results of this search there are ~355 articles in Category:CS1 errors: unsupported parameter with {{cite report}} templates that have |agency= and where the article, somewhere, contains the word 'weather'.

Some cases, like this from Weather of 2021, the value in |publisher= us unnecessarily duplicated in |agency=:

{{cite report|agency=National Centers for Environmental Information|title=Storm Events Database January 25, 2021|url=https://www.ncdc.noaa.gov/stormevents/eventdetails.jsp?id=938002|publisher=National Centers for Environmental Information|access-date=May 5, 2021|archive-date=May 10, 2021|archive-url=https://web.archive.org/web/20210510142454/https://www.ncdc.noaa.gov/stormevents/eventdetails.jsp?id=938002|url-status=live}}

Others, like this one from the same article, appear to use some sort of made-up 'agency' name:

{{Cite report |url=https://www.ncdc.noaa.gov/stormevents/eventdetails.jsp?id=972354 |title=Pennsylvania Event Report: EF2 Tornado |publisher=National Centers for Environmental Information |agency=National Weather Service Weather Forecast Office in Philadelphia, Pennsylvania |year=2021 |accessdate=December 18, 2021 |archive-date=December 18, 2021 |archive-url=https://web.archive.org/web/20211218061648/https://www.ncdc.noaa.gov/stormevents/eventdetails.jsp?id=972354 |url-status=live }}

('National Weather Service Weather Forecast Office in Philadelphia, Pennsylvania' does not appear on the Storm Events Database page linked from the citation).

@Trappist the monk: It's not obvious, but it actually does appear. Individual Storm Data event entries (of which the link above to the Storm Events Database is one) are created by the over 100 National Weather Service WFOs (Weather Forecast Offices) across the country and are then compiled together / released by the National Centers for Environmental Information. There are multiple ways of accessing these entries, including in the form of massive monthly Storm Data PDFs (printed versions may also be available but I think for a price) and from individual links like the one above. PHI, as shown in the WFO field of the table at that link, is the code of the WFO that created this event entry. The intent of the citation (even if formatted weirdly or wrongly) is to both attribute the NCEI and the WFO that created the entry. Master of Time (talk) 11:18, 13 June 2024 (UTC)

—Trappist the monk (talk) 15:04, 29 April 2024 (UTC)

The category CS1 errors: unsupported parameter currently has more than 3000 pages listed, the majority for |agency=. Some are fixable, but what about when the citation has something different for |publisher=?.--Auric talk 13:06, 29 April 2024 (UTC)

|agency= is not now, nor ever has been, an alias or synonym of |publisher=. If the source is delivered by some provider other than the publisher, use |via= to hold the name of the provider.

—Trappist the monk (talk) 15:04, 29 April 2024 (UTC)

That makes sense, thanks.--Auric talk 17:56, 29 April 2024 (UTC)

To be fair, it appears to have been frequently misused as an alias or synonym of publisher. That does not mean that there has ever been a time when citations that did so were correct. —David Eppstein (talk) 17:58, 29 April 2024 (UTC)

There may have been some confusion when the publisher of a source is a government agency. Rather, |agency= has been a shorthand name for a parameter holding the wire agency of a news story, to properly credit that the origin of a news article in a paper was the Associated Press/United Press International/Agence France-Presse/etc. and not the cited newspaper itself, with or without any additional reporter byline. Imzadi 1979 → 22:31, 29 April 2024 (UTC)

As the parameter |agency= has been removed, how should the entry for it on Template:Cite_book/TemplateData be corrected? Should it just be deleted from the table? — Skullcinema (talk) 16:06, 3 May 2024 (UTC)

I've removed it. Izno (talk) 17:58, 9 May 2024 (UTC)

Relatedly, Citation bot has recently been adding agency= to cite book templates: see User talk:Citation bot/Archive 38#Adds unknown parameter to CS1 and Special:Diff/1221981567. —David Eppstein (talk) 19:26, 9 May 2024 (UTC)

The description of the collaboration parameter says:

collaboration: Name of a group of authors or collaborators; requires author, last, or vauthors listing one or more primary authors; follows author name-list; appends "et al." to author name-list.

When collaboration is supplied, but author is not, the current behavior is to not display the name of the collaboration at all.

The problem is that there are studies for which the primary authors are not known. For example, the following rather important study, referenced in Euler–Heisenberg Lagrangian, has 397 authors, none of them marked as primary: "Measurement of e⁺e⁻ Momentum and Angular Distributions from Linearly Polarized Photon Collisions". Listing the first few names from an alphabetically sorted list of authors makes no sense. The current behavior forces me to use author for the name of the collaboration.

I propose to change the description and the behavior of collaboration so that it only requires supplying the primary authors if they are known, still displaying the name of the collaboration if author is empty. — UnladenSwallow (talk) 18:45, 1 June 2024 (UTC)

I agree. I have encountered this situation multiple times. In some cases the publication doesn't even list the authors, it merely names the collaboration. —David Eppstein (talk) 19:03, 1 June 2024 (UTC)

Listing the first few names from an alphabetically sorted list of authors makes no sense. It is nonetheless standard practice (or was, at least, until fairly recently) to cite as Adam, J. et al. (STAR Collaboration).

That said, there is no reason for why you can't have a collaboration as a single author. Or two authors + a collaboration, that does not require et al to be displayed. Headbomb {t · c · p · b} 21:08, 1 June 2024 (UTC)

If there's no principal investigator named, what's wrong with putting the name of the collaboration into the |author= parameter? Corporate authorship is pretty normal in a lot of areas. Unless I'm misunderstanding something – always a strong possibility – it seems like the behaviour requested here would render on the page exactly the same as |author=Collaboration Name. What probem am I missing here? Folly Mox (talk) 22:14, 1 June 2024 (UTC)

I just think it would be better to always put the name of the collaboration in the collaboration parameter, whether the names of the principal authors are available or not.

A more general solution would be to rename collaboration to collective-author and require that collective authors (such as corporate authors, commissions, collaborations, etc.) always go there, so that the authorn parameters are only used for single humans. — UnladenSwallow (talk) 22:37, 2 June 2024 (UTC)

I have suggested a |org-authorn= before which would also skip our checks for commas and semicolons and allow us to remove a lot of uses of ((name_triggering_checks)). Izno (talk) 17:11, 3 June 2024 (UTC)

Or just use author_n as normal. Headbomb {t · c · p · b} 21:38, 5 June 2024 (UTC)

Listing the first few names from an alphabetically sorted list of authors makes no sense isn't really true here. It makes less sense in the minds of various academics (concerned primarily with credit) than it does here, but even in the academic world and especially here, listing the first few names enables one to easily find the paper (or whatever it is) via various means, in most cases, because such a work will typically be indexed in various dabases, bibliographies, card catalogues, etc., by a partial or complete list of named authors, alphabetically by family name. It is crucial to remember that our citations exist for helping our readers find and make use of the sources, not for making academics happy about the frequency of their names appearing.

PS: a |collective-author= or |org-author= parameter would simply be a redundant alias of |author= (or |authorn=), which already serves that purpose. This entire discussion makes me question the necessity or wisdom of a |collaboration= parameter in the first place. I have yet to run into it "in the wild" (despite over 18 years and 200K+ non-automated edits) and have never used it. There has never been a case of a citation I needed to build, no matter the complexity of the authorship, editorial process, and publishing, that I could not do entirely sensibly with other parameters, even if it ends up being something like: ... |last1=Chen|first2=Xie-luan|author1-mask=Chen Zie-luan|last2=Smith|first2=J. P.|author3=Legume Projectiles Workgroup|display-authors=etal|translator-last=O'Brien|translator-first=Maeve|others=McNabb, John (illustrator)|editor1-last=Gutierrez|editor1-first=Selena|editor2=Foostuffs Momentum Committee|publisher=X. Y. Zedman & Co., for the Ministry of Foodfights ....  — SMcCandlish ☏ ¢ 😼  16:11, 11 June 2024 (UTC)

That's because you don't edit in particle physics. See Quark#cite_note-PDGTetraquarks-14, Quark#cite_note-Belletetra-15 or Quark#cite_note-LHCbtetra-17 for example, amongst several others. Headbomb {t · c · p · b} 01:24, 12 June 2024 (UTC)

Man, two people above who just skimmed right over why I said what I said: I have suggested a |org-authorn= before which would also skip our checks for commas and semicolons and allow us to remove a lot of uses of |author=((a_name_triggering_checks)). I would love for |author= to fill the role of "only organizational names", but it's not that today, it's a template-level synonym for |last= and a lot of people also use it for |author=last, first, which maybe at some date we can instead have a more strict change to support catching those uses also, in favor of moving to |org-author= parameters........... Izno (talk) 21:46, 13 June 2024 (UTC)

I'm seeking clarification on the placement of the ISSN parameter in {{cite journal}}. Specifically, what are the arguments for displaying the ISSN after the DOI and other article identifiers, rather than directly after the journal name?

For context, the ISSN is an identifier for the journal as a whole, not the individual article. Here are two examples to illustrate my point:

Example 1 - ISSN as Part of Article Identifiers

Doe, J. (2024). "Research on Sample Topics". ''Sample Journal''. doi:10.1234/abcd.5678, ISSN 1234-5678.

Example 2 - ISSN as Part of Journal Identifier

Doe, J. (2024). "Research on Sample Topics". ''Sample Journal'', ISSN 1234-5678. doi:10.1234/abcd.5678.

In Example 1, the ISSN is listed after the DOI, suggesting it is an identifier for the article. In Example 2, the ISSN is placed after the journal name, clearly indicating it is an identifier for the journal.

I believe that if we display the ISSN, it should be positioned to reflect that it identifies the journal. This would avoid confusion and provide a clearer reference structure. Alternatively, we could consider not displaying the ISSN at all in citations.

What are the current reasons for the existing placement of the ISSN, and would it be possible to revise the format for better clarity?

Thank you for your input. Jonatan Svensson Glad (talk) 19:21, 5 June 2024 (UTC)

Identifiers are rendered as a group that is alpha ascending sorted by down-cased identifier names. So, 'ISSN', down-cased to 'issn' follows 'doi' in the rendering. It used to be that the identifiers were rendered in random order because of how Lua deals with associative tables. There were complaints about the randomness so we sort the identifiers; no more randomness.

—Trappist the monk (talk) 19:51, 5 June 2024 (UTC)

Thank you for the clarification on the current sorting mechanism for identifiers. While I understand the rationale behind grouping identifiers and sorting them alphabetically to avoid randomness, I believe this approach conflates two fundamentally different types of identifiers. The ISSN identifies the journal, while identifiers like DOI are specific to individual articles. This distinction is crucial for accurate citation and reference clarity. Consider the following points:

Clear Distinction of Identifiers

Placing the ISSN with the DOI and other article-specific identifiers can mislead readers into thinking the ISSN is also specific to the article. However, the ISSN is a unique identifier for the journal itself, not the article. Separating these would enhance clarity:

Doe, J. (2024). "Research on Sample Topics". ''Sample Journal'', ISSN 1234-5678. doi:10.1234/abcd.5678. Here, the journal identifier (ISSN) is clearly linked to the journal name, and the article identifier (DOI) follows as part of the article-specific details.

Enhanced Citation Accuracy

Academic standards and citation guidelines typically differentiate between journal and article identifiers. Aligning Wikipedia’s citation style with these standards would improve the accuracy and professionalism of our citations. For example, many style guides (e.g., APA, MLA) do not group ISSN with article identifiers.

Improved Reader Experience

For readers and editors, a clear and structured citation format is easier to read and understand. Grouping identifiers by their type (journal vs. article) can prevent confusion and ensure that the citation components are immediately recognizable:

Doe, J. (2024). "Research on Sample Topics". ''Sample Journal'', ISSN 1234-5678. doi:10.1234/abcd.5678, PMID 12345678.

Consistent Identifier Grouping

If the goal is to avoid randomness and ensure consistent ordering, we can achieve this while still distinguishing between journal and article identifiers. We could establish a format where journal identifiers (e.g., ISSN) always appear directly after the journal title, followed by article identifiers (e.g., DOI, PMID) in alphabetical order.

By acknowledging the inherent differences between these types of identifiers and reflecting this distinction in our citation templates, we can provide clearer, more accurate citations. I propose revisiting the grouping strategy to separate journal identifiers from article-specific identifiers, ensuring each is clearly defined and appropriately placed. Jonatan Svensson Glad (talk) 19:57, 5 June 2024 (UTC)

ISSN is best omitted because it is rarely a relevant identifier. You cite the article, not the journal as a whole. Headbomb {t · c · p · b} 21:37, 5 June 2024 (UTC)

It is unfortunately added as default if you use the VisualEditor's cite tool "Citoid", as well as e.g. "ProveIt", to generate the reference code. So I doubt many (at least not me) takes the time to actively remove the ISSN when included in the generated reference. Do we have a count of how many articles/references cite ISSNs currently (and how many of these are really needed to e.g. disambiguate the journal)? Jonatan Svensson Glad (talk) 21:42, 5 June 2024 (UTC)

95%+ of the time, it's automated garbage. Same type of garbage that will add |publisher=Elsevier BV to journal citations. Headbomb {t · c · p · b} 21:59, 5 June 2024 (UTC)

I believe these tools no longer adds publisher to journals though (only e.g. web and book). Jonatan Svensson Glad (talk) 22:00, 5 June 2024 (UTC)

I believe Citoid and ProveIt (which uses Citoid) will ignore ISSN for a template if you remove it from the "citoid" section of the template's /doc or /TemplateData subpage. Should it be ignored for {{cite journal}}, and should it be ignored for the other citation templates? Rjjⁱⁱⁱ (talk) 14:44, 12 June 2024 (UTC)

If we're going to retain an ISSN parameter, I would agree with the OP that this is a serial-publication-level identifier, not an article/paper identifier and would be better right after the title of the serial publciation, so it is not confusable with a pointer to the specific article/paper being cited. There's a minor wrinkle in that ISSNs are also sometimes issued for series of books, in which case the ISSN should come right after |series= if present. It not present (e.g. because the books in the series all share the same title and are only distinguished by volume number), then I guess it belongs after |title=, and sorted with other book-level identifiers like ISBN or a whole-book DOI. If the chapter/contribution has its own DOI, then that should adhere right after the chapter/contribution, I would think. In short: the desire to group and sort identifiers is reasonable, but only to the extent they are the same type and that grouping and sorting them does not confuse or mislead our reader.  — SMcCandlish ☏ ¢ 😼  15:42, 11 June 2024 (UTC)

In principle I agree with separating article-level and publication-level identifiers. In practice it is not always easy. How do you distinguish book-level dois from chapter-level dois? —David Eppstein (talk) 20:06, 13 June 2024 (UTC)

Or any book-level identifiers from chapter-level identifiers in general, especially when many can be either. Headbomb {t · c · p · b} 23:08, 13 June 2024 (UTC)

Just saw this in "Tech News: 2024-24":

• The HTML markup used for citations by Parsoid changed last week. In places where Parsoid previously added the mw-reference-text class, Parsoid now also adds the reference-text class for better compatibility with the legacy parser. More details are available. [3]
• ...
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 June. It will be on non-Wikipedia wikis and some Wikipedias from 12 June. It will be on all wikis from 13 June (calendar). [4][5]
• The new version of MediaWiki includes another change to the HTML markup used for citations: Parsoid will now generate a <span class="mw-cite-backlink"> wrapper for both named and unnamed references for better compatibility with the legacy parser. Interface administrators should verify that gadgets that interact with citations are compatible with the new markup. More details are available. [6]

 — SMcCandlish ☏ ¢ 😼  15:31, 11 June 2024 (UTC)

No issues. Izno (talk) 21:47, 13 June 2024 (UTC)

Several templates have the same issue with formatting, so I'm posting here. I'll leave a link at the less-watched talk page of each template below.

There are many specific-source templates that wrap a CS1/CS2 template. Previously, template formatting could be set with the |mode= parameter in each template. Now, the formatting can be set for the whole article using {{CS1 config|mode=}}. Some specific-source templates wrap the general purpose CS2 {{Citation}} and use |mode=cs1. Because this emits the message "{{cite book}}: CS1 maint: overridden setting (link)" and adds the page to a tracking category, the templates should be converted into CS1 wrapper templates. (Or fixed in some other way.)

Template	Proposed wrapper	Result
{{Calflora}}	{{Cite web}}
{{Cite form 990}}	{{Cite document}}
{{Cite Transperth timetable}}	{{Cite web}}
{{Cite UN World Population Prospects}}	{{Cite web}}
{{EFloras}}	{{Cite web}}
{{FEIS}}	{{Cite web}}
{{Jepson eFlora}}	{{Cite web}}
{{Minnesota Wildflowers}}	{{Cite web}}
{{Silvics}}	{{Cite book}}
{{Tropicos/main}}	{{Cite web}}

Side note: the handful of CS2 map templates like {{Cite gnis2}} have a similar issue, Rjjⁱⁱⁱ (talk) 16:31, 12 June 2024 (UTC)

There's a problem, because the choice of the wrapped template is often dictated by pre-existing parameters accepted by the wrapping template. So changing the wrapped template may break existing functionality in a hard-to-detect way. Would it be possible for the wrapping templates to (somehow) detect the mode that is set by {{CS1 config}}? That seems like the cleanest solution (if possible). I will investigate, but open to other ideas. — hike395 (talk) 19:51, 12 June 2024 (UTC)

I think having all of these templates obey the mode specified {{CS1 config}} may be possible with a helper template calling Module:Citation/CS1/Configuration. I'm busy IRL, but can get to this in the next 1-2 days. Please hold off making changes to these wrapper templates as I attempt a fix. — hike395 (talk) 20:01, 12 June 2024 (UTC)

Or, once again, why aren't we merging CS1 and CS2 together? They're very similar in overall output, and if we could just agree to harmonize them the little that we'd need, we could remove this dichotomy once and for all. Imzadi 1979 → 22:01, 12 June 2024 (UTC)

Before we get into that can of worms, maybe we can first forbid Vancouver style? That's a bigger variation in citation style than CS1 vs CS2, and one that I think causes more difficulties (because the abbreviated author names make it difficult to distinguish authors with similar names, for instance when trying to find which Wikipedia articles cite someone's work). —David Eppstein (talk) 23:14, 12 June 2024 (UTC)

@David Eppstein: yes, that too. I know the medical editors like it because they're used to that in academic literature, but I find it too terse for a general readership. Imzadi 1979 → 23:22, 12 June 2024 (UTC)

 Fixed @Rjjiii: I created Module:Citation mode which suppresses a mode argument when {{CS1 config}} is set. I edited all of the templates you listed, above, to call the module for the mode argument that they pass to their inner {{Citation}} template. For a simple example of usage, see {{cite gnis2}}.

I'm not seeing any changes in the overriden-setting tracking category: I suspect that the current members of that category are caused by some other problem.

Feel free to use Module:Citation mode or let me know if you see any problems. — hike395 (talk) 12:58, 13 June 2024 (UTC)

Thanks Hike395! That fixed the problem without causing any unexpected changes. This worked way better than my plan. Would it be a good idea to link Module:Citation mode in the documentation at Template:Citation Style documentation/display for future specific-source templates? Rjjⁱⁱⁱ (talk) 00:32, 14 June 2024 (UTC)

IIUC, Template:Citation Style documentation/display is part of the documentation for all citation templates for general editors, is that right? If a user is setting the mode in an article, I'm guessing you still want the article to show up in the tracking category. The module should probably only be used for wrapping citation templates. Is there a documentation or help page specifically for editors who are wrapping these kind of templates? — hike395 (talk) 02:29, 14 June 2024 (UTC)

I came across a case where an legitimate article was archived at archive.org. The original article was subsequently moved to a different website with a completely different path, and the original website (about.com) became black-listed by wikipedia (assuming unfit for citation). Shouldn't we have parameter "url-status = moved", or something like that to reflect what happened? Because the other parameters don't seem to apply (the new site isn't dead or unfit, or usurped), and "live" would apply, except that the archived link no longer matches the live link because of the move. Dhrm77 (talk) 18:45, 14 June 2024 (UTC)

There are many scenarios that could have a url-status flag. Soft-404s. Soft-redirects. Soft-200s. etc.. This is a soft-redirect ie. a dead link that is live at a different URL but lacks a redirect. Ok so we flag those. But why? |url-status= has one purpose, to change the appearance of the primary link. A soft-redirect situation would not require a change in how the URL is displayed that is not already done with existing modes like live and dead. The new URL has a "live" status. That it doesn't match the archive-url is not really a problem this happens frequently, sometimes when a page moves, sometimes when the citation is created editors use a different archive URL from the primary URL. -- GreenC 20:05, 14 June 2024 (UTC)

Thanks. That was helpful. Dhrm77 (talk) 20:17, 14 June 2024 (UTC)

Not sure if this is the correct place for a suggestion for the template. I am not comfortable with sending edit requests for templates (yet), so I figured I'd put it here.

If you insert an archive link into web templates, such as https://web.archive.org/web/20240615012051/http://example.com/, you can see in the url in the highlighted area that the date is present in the url. Given so, why is the archive date field required when the date is provided through the url? If you input the wrong date into the template, a mismatch error is thrown and it shows the correct date. If it knows the correct date, why not correct the error?

I am aware that not all archiving services provide the date handily in the url, but since the Internet Archive is the largest one, can't the template make an exception for the Archive? I know it's not a huge deal, but it is still another thing to type and check.

Sorry if I'm not making very much sense, I am still learning about how all of this works. Thank you. EatingCarBatteries _{(contributions, talk)} 05:56, 16 June 2024 (UTC)

I'm not quite clever enough to figure out how {{Use dmy dates}} and {{EngvarB}} don't emit a linebreak, but {{CS1 config}} and {{bots}} presently do. Does it have to do with Module:Unsubst somehow? In any case, would it be possible to have the same behavior for the latter templates, as I presently have to put them on the same line at the top of articles. Remsense诉 12:43, 18 June 2024 (UTC)

Sub-titles for {{cite book| and accompanying numbering

I need several sub title parameters for {{cite book| because the template as it now exists is difficult to work with.

For example, if I'm citing the Corpus of Hieroglyphic Luwian Inscriptions:

• the actual series is Series in Indo-European Language and Culture,
  • while the title is Corpus of Hieroglyphic Luwian Inscriptions,
    • the 1st volume is Inscriptions of the Iron Age,
      • and its first part is Text Introduction, Karatepe, Karkamiš, Tell Ahmar, Maraş, Malatya, Commagene,
      • its second part is Amuq, Aleppo, Hama, Tabal, Assur Letters, Miscellaneous, Seals, Indices,
      • and its third part is Plates,
    • the 2nd volume is Karatepe-Aslantaş
      • the 2nd volume is sub-titled The Inscriptions: Facsimile Edition,
    • the 3rd volume is Inscriptions of the Hittite Empire and New Inscriptions of the Iron Age,
      • the 3rd volume is itself divided into a part III/1 and a part III/2.

Despite the recommendations I have received during my previous requests here, this is not working for me. I am having trouble adding proper titles in the template for several publications whose titles and sub-titles are similarly extensive.

Numeration

Along with this, there also needs to be accompanying series numeration, volume numeration, and parts numeration.

Parts for {{cite encyclopedia|

I would also need {{cite encyclopedia| to also have a numbering or part accompanying the titles.

For example, the entry for Que in the Reallexikon der Assyriologie und Vorderasiatischen Archäologie has a part A written by J.D. Hawkins and a part B written by D. Syrmington.

And several more sources I cite have similar entries divided into several parts, which are either labelled with a letter of the alphabet or a number.

I need a parameter to add this numeration.

Need for |trans-series

I also need a translation option for series names in languages other than English.

Which citation to use when citing a dictionary

Additionally, which citation template should I use when citing a dictionary?

For example, if I am citing the eDiAna Dictionary, which has sections for various languages and entries that are divided into several parts written by multiple authors, which citation template should I use? Antiquistik (talk) 15:37, 16 June 2024 (UTC)

In the first case, {{cite book |chapter=<Foobar> |title=Corpus of Hieroglyphic Luwian Inscriptions – Volume 1: Inscriptions of the Iron Age |series=Series in Indo-European Language and Culture |volume=<xxx> |page=<yyy> }} will give "<Foobar>". Corpus of Hieroglyphic Luwian Inscriptions – Volume 1: Inscriptions of the Iron Age. Series in Indo-European Language and Culture. Vol. <xxx>. p. <yyy>.

Replace <Foobar> with "Text Introduction", "Tell Ahmar", or whatever. Similar for Vol 2/Vol 3.

Headbomb {t · c · p · b} 15:46, 16 June 2024 (UTC)

Honestly, this is still very unwieldy. Can't additional sub-titles be added to the template instead? Antiquistik (talk) 16:54, 16 June 2024 (UTC)

There's no need for them. Put subtitles with titles. Put series into series. Put (series) volume into volume. Put chapter into chapter. Headbomb {t · c · p · b} 17:18, 16 June 2024 (UTC)

This unfortunately doesn't work, especially with sources that have multiple levels of sub-divisions. I really need an expansion of the template. Antiquistik (talk) 21:01, 19 June 2024 (UTC)

I've just shown you. Headbomb {t · c · p · b} 21:09, 19 June 2024 (UTC)

I understand that, and I appreciate the help. But this solution doesn't solve the issues that I am facing with using the template in its current state. Antiquistik (talk) 06:48, 23 June 2024 (UTC)

What is the issue you are facing then? Give me a specific case of what you want to cite, and I'll show you how to use the template. Headbomb {t · c · p · b} 20:16, 26 June 2024 (UTC)

(ec) I've seen bots change {{cite dictionary}} to {{cite encyclopedia}}, so I suppose that's the one to use for dictionaries. Agree that |trans-series= would be helpful; I come up against this periodically, and it feels weird to cram the translation into the same parameter after splitting it out for the previous two.

As to the |subtitle= idea, I do low-key agree that adding one could be helpful, but not for reasons of unwieldiness (any solution where the source is "Chapter" in Title: Named Volume, Part something is going to be unwieldy).

My experience has been that I'll sometimes want to use |title-link= for a source we have an article about, but multiple named volumes comprise the title, so I end up with Science and Civilization in China: vol. 4 Physics and Physical Technology, part 1: Physics, with the entire title linking the article Science and Civilization in China.

The other use case I would have for |subtitle= is for links to old books on Internet Archive or HathiTrust (or, decreasingly commonly, Project Gutenberg), where the title is something fashionably lengthy for the turn of the twentieth century like Travels and researches in Chaldæa and Susiana; with an account of excavations at Warka, the Erech of Nimrod, and Shúsh, Shushan the Palace of Esther, in 1849–52 or Bismya; or The lost city of Adab : a story of adventure, of exploration, and of excavation among the ruins of the oldest of the buried cities of Babylonia, and the whole dang thing gets bluelinked across three lines by the |url= parameter, because there's no way to cordon off the main part of the title for linking or put an external link inside the |title= parameter, and any other parameter I try to kludge the subtitle into doesn't concatenate next to the title but instead is separated by other information.

Anyway I don't really see a pressing need for this, but it would be nice for those sorts of situations. Folly Mox (talk) 17:23, 16 June 2024 (UTC)

Looks like PMIDs started ticking over 38900000 in the past couple of days. An article referencing 38900028 showed up in the tracking category and it is valid. Masterzora (talk) 03:59, 23 June 2024 (UTC)

"The Antisemitism Policy Trust" causes a generic name error (here). I marked it accept-this-as-written. Was that correct? I can't find any other author on the report. What is causing it to be flagged? AlmostReadytoFly (talk) 14:56, 26 June 2024 (UTC)

The error occurs because |author= includes the word policy. I would have written that template this way:

{{cite web |title= Conspiracy Theories: A Guide for Members of Parliament and Candidates |website=The Antisemitism Policy Trust |url= https://antisemitism.org.uk/wp-content/uploads/2024/05/Conspiracy-Theory-Guide.pdf |access-date= 11 June 2024}}

"Conspiracy Theories: A Guide for Members of Parliament and Candidates" (PDF). The Antisemitism Policy Trust. Retrieved 11 June 2024.

—Trappist the monk (talk) 15:16, 26 June 2024 (UTC)

Thanks. I failed to notice "policy" in the list in Help:CS1_errors#generic_name. AlmostReadytoFly (talk) 15:40, 26 June 2024 (UTC)

I can't access the URL https://tvlistings.zap2it.com/overview.html?programSeriesId=SH01739244&aid=gapzap and marked it as dead, however another editor can apparently access it. Is there some kind of parameter that should be used here to note this? I was looking at {{Cite web}} but didn't find one. Gonnym (talk) 11:29, 27 June 2024 (UTC)

This is a perennial faq, no we do not manage policy blocks because they are changeable and relative to the viewer. For example, people in Romania can't access BBC links hosted in the UK, but only for 18 months, and this information is not made public anywhere. The possibilities are endless. The alternative? Check the archive link when you can't reach the main link. Of course this leads to the situation you describe of incorrectly marking a link dead, which is its own problem. Because even if the citation was tagged as a possible policy block, as you suggest, how would you know if it was policy block dead, or actual dead? It then leads to the problem of links not being marked dead when they should be. Probably in this case one would need to use a site like isitdownrightnow.com (assuming that site is not also policy blocked). It's a messy complex problem. -- GreenC 14:57, 27 June 2024 (UTC)

Any CS1 citation templates ends with "." However, this does not happen if a) |quote= is used and its value does not end with "."; and b) no other parameter injects content into the rendered citation after the quotation content. Example:

• {{cite book |editor1-last=Jenny |editor1-first=M. |editor2-last=Sidwell |editor2-first=P. |chapter=Reconstructing Austroasiatic prehistory |date=2015 |title=Handbook of the Austroasiatic Languages |location=Leiden |publisher=Brill |page=1 |quote=Sagart (2011) and Bellwood (2013) favour the middle Yangzi |ref=none}}

renders as:

• Jenny, M.; Sidwell, P., eds. (2015). "Reconstructing Austroasiatic prehistory". Handbook of the Austroasiatic Languages. Leiden: Brill. p. 1. Sagart (2011) and Bellwood (2013) favour the middle Yangzi

 — SMcCandlish ☏ ¢ 😼  10:45, 28 June 2024 (UTC)

'Twas ever thus; probably to avoid multiple terminal punctuation characters: !., ?., etc. This functionality was established long before we had |postscript=none.

—Trappist the monk (talk) 13:47, 28 June 2024 (UTC)

Well, can something be done about it now in this Lua golden age?  — SMcCandlish ☏ ¢ 😼  00:08, 1 July 2024 (UTC)

Is this example supposed to be bibliographically accurate? (genuine question: autism) I'm not seeing chapter Reconstructing Austroasiatic prehistory at doi:10.1163/9789004283572, nor any chapter by that name across Brill. (Also I guess add a four dots sentence-terminal ellipsis to the quote as a workaround?) Folly Mox (talk) 14:34, 30 June 2024 (UTC)

I would think it should be. It's just a citation I ran across (I think I may have formatted a bare-text one into a template though; don't remember at this point). Please do feel free to repair it in any way it needs.  — SMcCandlish ☏ ¢ 😼  00:08, 1 July 2024 (UTC)

Veering entirely off topic here, but this page provides the answer: the chapter was not included in the published book, and so the four references to this source are all citing an unpublished manuscript. Folly Mox (talk) 08:30, 1 July 2024 (UTC)

I'm fixing these, and I'll stop derailing this thread after this post, but noting for funsies that the full sentence in the original source reads "Sagart (2011) and Bellwood (2013) favour the middle Yangzi, although there is no direct linguistic evidence for this, and the expansion of the [language] phylum in its present form would have to begin further south." So there may be some misrepresentation. Folly Mox (talk) 09:07, 1 July 2024 (UTC)

Good sleuthing. I guess this PDF could count as self-publication by a subject-matter expert, so still usable, as long as used properly. But there might be more, latter, better sourcing anyway.  — SMcCandlish ☏ ¢ 😼  00:42, 2 July 2024 (UTC)

Why has this template recently changed from correctly citing references from the Clyde Ships website, such as https://www.clydeships.co.uk/view.php?ref=10727 and is now translating them to show them as Google, such as https://www.google.com.hk/?ref=10727&gws_rd=ssl ? Johnragla (talk) 20:16, 30 June 2024 (UTC)

@Johnragla have you got an example in an article to look at? Nthep (talk) 20:21, 30 June 2024 (UTC)

No, because I've used manual citations, rather than automatic. An example of how the template used to work is ref 131 on the Northern Steamship Company page. Johnragla (talk) 20:33, 30 June 2024 (UTC)

@Johnragla You're using the visual editor rather than the source editor, correct? The behaviour you're seeing is a VisualEditor citation tool issue rather than an issue with any of the citation templates (I can replicate your issue if I use the visual editor). I've no idea where that tool is managed for en:WP. Anyone? Nthep (talk) 21:10, 30 June 2024 (UTC)

@Nthep Thank you, yes, correct. Wikipedia:VisualEditor says "Use Phabricator to report problems with Visual Editor." Do you want to do that, or shall I? Johnragla (talk) 21:22, 30 June 2024 (UTC)

I'll leave it to you. Nthep (talk) 07:56, 1 July 2024 (UTC)

An increasing number of websites, particularly in the news and information space, require you to disable your adblocker to access their content. While this is not quite the same as a paywall or registration requirement, it is still an annoyance. I therefore propose that the "Subscription or registration required" parameter at Template:Cite web should have a variable added to indicate that the website requires adblock disabling for access. BD2412 T 18:02, 26 June 2024 (UTC)

Might it be better to make that a separate parameter, since a site requiring removing ad blockers might or might not, e.g., require registration. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:11, 26 June 2024 (UTC)

I have not experienced that, but then I again I never register for the sites that require registration, so I have not seen whether they also require adblock disabling. I would still think that this could be handled with a single parameter, with one additional variable for those that require registration and adblock disabling. BD2412 T 20:04, 26 June 2024 (UTC)

For large values of one. A site that doesn't work with ad blockers might be at any of four access levels, so the options are:

1. Status quo
2. Add a parameter for requires disabling ad blockers for each |foo-access= parameter
3. Define 4 new values for each |foo-access= parameter, e.g., |url-access=limited-noadblocker
4. Let each |foo-access= parameter take a list of two subparameters

I believe that the first two options are the most reasonable. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:17, 27 June 2024 (UTC)

Agreed, and I have to lean toward 1, because it's not WP's job to tell readers what they have to do to get access to something. This is just yet another form of "policy block" like region-specific blocking, and it's essentially an insoluble issue by us, because there are millions of websites and they change all the time. WP:NOT#DATABASE of random websites' policies. We're presently permitting notice of paywalled or registration-required links, but even this is dubiously useful. Any given paywalled academic site is effectively not paywalled for any academic or student whose institution provides institutional-subscription access, for example. And whether or not a site such as Internet Archive requires a free user registration to access something is ultimately immaterial, since the source is still accessible and one can (unless particularly clueless) use fake data to register anyway. Even if we continue to tolerate that minimal level of trying to tell the reader what to expect at innumerable random websites that may change their behavior at any moment (and may do it on a regional or other policy basis, too), we should not expand this worm-can further.  — SMcCandlish ☏ ¢ 😼  10:56, 28 June 2024 (UTC)

That's true across the web, and if you use an adblocker, while not illegal, you are changing how websites operate and violate the implicit free content paid by ads agreement. I'm against the inclusion of this parameter because custom scripts designed to circumvent those agreements should not be encouraged or supported. Headbomb {t · c · p · b} 20:11, 26 June 2024 (UTC)

@Headbomb: Adblockers generally do not prevent a website from including integrated textual advertising content, e.g., a sidebar or footer on a news website. They block intrusive forms of advertising like popups. There wouldn't be adblockers if there weren't popup ads. In any case, this is intended to caution our readers, many of whom do have adblockers that a specified externally linked website may be foreclosed to them. If a link had an appropriate caution, I as a reader would know not to waste my time following the link, knowing that I would not be able to access the content at the other end. I don't see how such a notice is materially different from one indicating that registration is required. BD2412 T 20:19, 26 June 2024 (UTC)

You choose to use an adblocker. The cause of the problem is the you using an adblocker to circumvent how the website is designed to be used. We shouldn't have to warn you about your own choices. Headbomb {t · c · p · b} 20:26, 26 June 2024 (UTC)

No, the cause of the problem is the failure to provide enough information to make an informed choice. Only if you chose to click on a link that you know prohibits ad blockers is it reasonable to claim that it's what you chose. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:17, 27 June 2024 (UTC)

Requiring you to disable adblockers is not merely an annoyance: it is a breach of your security perimeter, of which adblocking may be an important part. See e.g. the NSA and CIA use ad-blockers (2021) and FBI Recommends Ad Blockers (2022).

Conversely, use of adblockers is not a circumvention and should not be discouraged. It is an important security measure. —David Eppstein (talk) 20:47, 26 June 2024 (UTC)

I agree that ads are a common attack vector, cross-site scripting was a bad idea from the beginning. -- LCU ActivelyDisinterested «@» °∆t° 16:32, 27 June 2024 (UTC)

Yep.  — SMcCandlish ☏ ¢ 😼  10:51, 28 June 2024 (UTC)

Is this only for sites that currently need to have adblockers disabled? What happens if some adblockers work but other don't, or adblockers must be disabled now but later they work out a way to circumvent the detection? If this isn't just based on the technical issue then what of sites that disallow adblockers but make no technical measures to stop you from using them? -- LCU ActivelyDisinterested «@» °∆t° 07:52, 27 June 2024 (UTC)

@ActivelyDisinterested: See, e.g., this. I encounter this sort of thing all the time. I don't think anyone wants to follow a link that we provide as a source in an article, only to have a screen-blocking pop-up in their face telling them that they must disable their ad-blocker to continue. BD2412 T 15:03, 27 June 2024 (UTC)

You miss my point. The adblockers work to overcome detection, so if your adblocker no longer triggers that message what then? No site supported by ads wants you to use an adblocker, and Wikipedia shouldn't care one way or the other. -- LCU ActivelyDisinterested «@» °∆t° 16:31, 27 June 2024 (UTC)

If a site is functionally inaccessible because it requires that you remove defenses, then it is no better than a site that requires you to pay to access it. I'm just saying that we should have the option of letting our readers know that before they click the link that we are providing to them. Wikipedia should care about the experience we provide our readers. BD2412 T 16:51, 27 June 2024 (UTC)

The majority of Wikipedia's readers are not using it or care about it. For them there is no difficulty accessing it. -- LCU ActivelyDisinterested «@» °∆t° 19:51, 27 June 2024 (UTC)

What's the purpose of this? Potentially saving the vanishingly small percentage of people who actually verify sourced information intersecting the set of people who use adblockers the trivial time it takes to decide of whether to whitelist a news site's ads, disable their ad blocker, close the tab, or attempt to locate the tiny continue to article link in the "Looks like you're using an adblocker" modal?

I don't think that technical foibles are really necessary to include in citation information, but particularly not at the citation template level. If this is a real concern, follow the citation template with a transclusion of {{subscription or advertising}}.

This might also be the wrong area of concentration if we're concerned about clear signalling of access levels: as far as I'm aware, zero citation generation scripts contain functionality that automatically adds |url-access= subscription to any source, meaning that we have tens of thousands or hundreds of thousands of citations to subscription-only sources with no red padlock icons. Folly Mox (talk) 11:25, 27 June 2024 (UTC)

@Folly Mox: Do you have data on the "percentage of people who actually verify sourced information"? Many browsers now have an adblocker built in, particularly because adblockers prevent websites from downloading tracking software onto your computer. As for whether it is used, we have countless citation templates that are missing basic things like dates, author names, even titles of the work cited. We have functionalities throughout the encyclopedia that are little-used, but would improve the encyclopedia if well-used. We should still have those options. BD2412 T 15:13, 27 June 2024 (UTC)

I don't have data on what percentage of editors bother to verify sources. I feel like I remember hearing that the Foundation has stats on reader clickthrough to sources, and it's something like 1%, but I don't remember where I read that or when the data is from.

Point taken about unused functionality; have you thought about the suggestion to use {{subscription or advertising}} if no consensus develops to add |url-access=ads? Folly Mox (talk) 17:49, 27 June 2024 (UTC)

The template {{subscription or advertising}} renders as

(subscription or advertising required)

Until there is a decision to not delete it, ... -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:11, 27 June 2024 (UTC)

Yeah, I forgot to check transclusions when I found that template and proposed it as an alternative solution, and another participant in this discussion nominated it for deletion in the time since my above comments. Honestly I don't feel particularly strongly about this thread either way. I was just trying to find a quick and simple method to address the concerns with existing templates. Folly Mox (talk) 11:02, 29 June 2024 (UTC)

Rather than worrying about this, or the other many variation (see for instance the section below), would it be worthwhile just change this to have one option 'restricted'. This covers subscription, adblocking, geoblocking, etc. -- LCU ActivelyDisinterested «@» °∆t° 19:54, 27 June 2024 (UTC)

I do think that the type of restriction may be relevant, and editors who are creating templates should have the flexibility to specify a type. Perhaps the parameter should provide an option to add a generic "restricted" signal, or a more specific signal of the editor's choosing. BD2412 T 21:24, 27 June 2024 (UTC)

We should not be trying to track this sort of information in citation templates. These are website "policy" issues that can change at any time for any reason based on the whim of a low-level engineer, a mid-level manager, or high-level politician. Policy can change every few months. There is no way to keep it accurate. Nor is it required to cite a source. There is an expectation readers are able to navigate around the web. -- GreenC 15:20, 1 July 2024 (UTC)

Before nomination of {{subscription or advertising}} for deletion, its two ns0 transclusions were altered to {{subscription required}}, as the websites cited no longer supported free reading with ads. It is a difficult thing to stay on track of updating. Folly Mox (talk) 16:12, 1 July 2024 (UTC)

Nonetheless, there are many external websites to which we link for which a reader traversing the link will receive an immovable popup requiring the lowering of their adblock defenses. BD2412 T 02:07, 7 July 2024 (UTC)

Maybe I'm bad at reading comprehension, but I couldn't find how to add a new supported language code on the page Template:Citation Style documentation/language/doc. Can anyone help please? Amir E. Aharoni (talk) 12:14, 3 July 2024 (UTC)

What language tag? The lists of MediaWiki-supported language name/tags are automatically rendered by querying MediaWiki with the Scribunto language library function mw.language.fetchLanguageNames(lang, 'all'). To be displayed at Template:Citation Style documentation/language/doc MediaWiki must have support for the language name/tag.

—Trappist the monk (talk) 13:21, 3 July 2024 (UTC)

It's "wlx", which is not yet fully supported by MediaWiki. Maybe it will be supported in the future, but is it possible to add a custom language until then? Amir E. Aharoni (talk) 14:42, 7 July 2024 (UTC)

Hi, @Trappist the monk, it's me again, from Help talk:Citation Style 1/Archive 93#Limits. As I could see today by chance, my suggestion was excepted, and tabular data is a part of the code now, isn't it? IKhitron (talk) 23:45, 3 July 2024 (UTC)

Help talk:Citation Style 1/Archive 94 § module suite update 23–24 March 2024

—Trappist the monk (talk) 00:43, 4 July 2024 (UTC)

Smith, Adam (July 7, 2024). Title (Speech). Event. Location. {{cite speech}}: Unknown parameter |transcript-url= ignored (help) Amayorov (talk) 17:59, 7 July 2024 (UTC)

|transcript= and |transcript-url= were not supported by {{cite speech}} in its wikitext (old) form so they are not supported in its current Module:Citation/CS1 form:

The |transcript= parameters are supported by {{cite av media}} and {{cite episode}}.

—Trappist the monk (talk) 18:28, 7 July 2024 (UTC)

It appears on Template:Cite speech though!

Besides, even if this parameter isn't supposed to work, shouldn't we add it? It could be very useful. Amayorov (talk) 19:05, 7 July 2024 (UTC)

If you mean the mentions in Template:Cite speech § Deprecated, you will find that mention in every cs1|2 template (Template:Cite book § Deprecated, Template:Cite journal § Deprecated, etc). The mention is supposed to convey the fact that support for the unhyphenated |transcripturl= has been withdrawn globally. Nearly a year later, that table will be emptied at the next module suite update when support for |authors= is withdrawn.

—Trappist the monk (talk) 19:14, 7 July 2024 (UTC)

I see, thanks! Amayorov (talk) 22:40, 7 July 2024 (UTC)

The redirect Wikipedia:Lua cites has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 July 8 § Wikipedia:Lua cites until a consensus is reached. Nickps (talk) 13:48, 8 July 2024 (UTC)

Module:Citation has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Nickps (talk) 16:01, 8 July 2024 (UTC)

Actually I nominated for redirection rather than deletion. There is no such TfD notice template though. Nickps (talk) 16:03, 8 July 2024 (UTC)

cs1|2 is somewhat schizophrenic when validating |year=. If I write:

{{cite book |title=Title |year=August 2023}} → Title. August 2023.{{cite book}}: CS1 maint: year (link)

no error even though 'August 2023' is not a 'year'. But, if I write:

{{cite book |title=Title |year=August 2023 |date=August 2023}} → Title. August 2023. {{cite book}}: Check date values in: |year= (help)CS1 maint: date and year (link) CS1 maint: year (link)

there is an error message because 'August 2023' is not a 'year'.

I propose to add a maintenance category to identify cs1|2 templates that have |year= where the assigned value is not YYY, YYYY, their circa forms, year-only ranges, and with or without CITEREF disambiguators. To make cs1|2 consistent in how it validates |year= I propose that we define |year= so that it may only hold one of the year formats named above. To accomplish that, we need to know where noncompliant |year= year parameters exist so that they may be repaired before a fix is made in Module:Citation/CS1/Date validation. The category is necessary because there are a so many non-cs1|2 templates that use |year= that Cirrus searching is woefully inadequate.

Yea or nay?

—Trappist the monk (talk) 15:53, 29 June 2024 (UTC) 13:24, 30 June 2024 (UTC) (modified)

How should a range, |year=2020–2022, be treated? -- Michael Bednarek (talk) 01:03, 30 June 2024 (UTC)

That would need to be allowed. Kanguole 11:55, 30 June 2024 (UTC)

Literalist as I have been accused of being, year to me means just that. Year range is a date so |date=2020–2022. Clearly there will be whining about this so I have modified the proposed definition of |year=.

—Trappist the monk (talk) 13:24, 30 June 2024 (UTC)

This matches a rationale for keeping both |date= and |year= explained at Help talk:Citation Style 1/Archive 31#Preference between year or date parameter in Cite Journal. Two editors mention using |year= to discourage future editors/bots from changing "YYYY" to something like "January YYYY" arbitrarily. Rjjⁱⁱⁱ (talk) 07:27, 30 June 2024 (UTC)

Support as maintenance category; oppose as error category. I don't think that a new CS1 error is being proposed here, but for clarity. Folly Mox (talk) 12:50, 30 June 2024 (UTC)

Initially a maintenance category. Once that category is cleared, it goes away, the fix is made to Module:Citation/CS1/Date validation, and thereafter, noncompliant |year= parameters become errors categorized in the already existing Category:CS1 errors: dates.

—Trappist the monk (talk) 13:24, 30 June 2024 (UTC)

Sounds fair. Folly Mox (talk) 14:13, 30 June 2024 (UTC)

I have tweaked the sandbox. The examples below are variations on this theme:

{{cite book/new |title=Title |year=900}}

|year=900 (ok):

Title. 900.

|year=c. 900 (ok):

Title. c. 900.

|year=c. 900a (ok):

Title. c. 900a.

|year=1900 (ok):

Title. 1900.

|year=900–1000 (ok):

Title. 900–1000.

|year=1951–52 (ok):

Title. 1951–52.

|year=August 1900 (not ok because month is not a year):

Title. August 1900.{{cite book}}: CS1 maint: year (link)

|year=Winter 1951–52 (not ok because season is not a year)::

Title. Winter 1951–52.{{cite book}}: CS1 maint: year (link)

|year=April–May 1900 (not ok because month range is not a year):

Title. April–May 1900.{{cite book}}: CS1 maint: year (link)

—Trappist the monk (talk) 16:28, 12 July 2024 (UTC)

I feel like "c." constructs should authomatically use {{circa}} to explain the notation, especially since

{{cite book/new |title=Title |year={{circa}} 900}}

Title. c. 900. {{cite book}}: Check date values in: |year= (help)CS1 maint: year (link)

produces an error. IceWelder [✉] 19:43, 12 July 2024 (UTC)

{{circa}} is bad for accessibility (mobile readers can't hover) in addition to polluting the metadata. c. 900 is pretty widely understood as an approximate date. Folly Mox (talk) 22:17, 12 July 2024 (UTC)

"Volume values that are wholly digits, wholly uppercase Roman numerals, or fewer than five characters will appear in bold." Why is bold text used in these cases? - BobKilcoyne (talk) 05:47, 30 June 2024 (UTC)

That's true for e.g. {{cite journal}}, and not true for e.g. {{cite periodical}}, {{cite encyclopaedia}}, {{cite book}}.

I don't remember which published academic citation style guides recommended bolding the volume number, but it does a good job of setting it apart from the issue number and visually separating the citation. I feel like we had a discussion here about this just last year at least. I'll see if I can locate it in the archives for you. Folly Mox (talk) 13:03, 30 June 2024 (UTC)

Well, I wasn't able to locate the discussion I was remembering, but see for example:

• Help talk:Citation Style 1/Archive 50 § When |volume= is a Roman Numeral (2018)
• Help talk:Citation Style 1/Archive 62 § Bolding of the volume number (2020)
• Help talk:Citation Style 1/Archive 77 § Journal volume in Bold (2021)
• Help talk:Citation Style 1/Archive 79 § Still an issue with book volumes (2021)

Short answer I guess is that a lot of people talked it through over the years and it got consensus. Folly Mox (talk) 13:21, 30 June 2024 (UTC)

This seems like a reasonable style for citation output in the form "63 (7): 43–51", but a) we really have reason to do that at all, since WP:NOTPAPER and we have no reason to compress space; and b) "vol. 63, no. 7, pp. 43–53" (or "Vol." and "No." if one insists on capitalizing those things) is much clearer. It's also a format in which the boldfacing would serve no purpose. That is, the boldfacing only serves a disambiguating purpose for a format that we have no reason to use and a good reason not to.  — SMcCandlish ☏ ¢ 😼  00:48, 2 July 2024 (UTC)

This, exactly. I consistently use {{cite magazine}} even when citing traditional academic journals just to get away from the compressed format of {{cite journal}}. Imzadi 1979 → 04:18, 2 July 2024 (UTC)

I support switching to an explicit style. — UnladenSwallow (talk) 04:26, 13 July 2024 (UTC)

I oppose switching to a single style for both academic journals and popular periodicals. Having 30 (2) for journals and Vol. 30 no. 2 for magazines lets me tell at a glance what kind of publication I'm looking at in the reference list. Additionally, if we were to adopt a single style, I'd argue for the other direction, since bolded text is easier to distinguish amongst an information dense morass of a citation than a couple abbreviations prepending two of possibly a half dozen or more numeric strings. Folly Mox (talk) 14:57, 13 July 2024 (UTC)

If not using paper meant space was no longer an issue, we'd be using "volume", "number" and "pages" instead of "vol.", "no." and "pp.". Many screens are smaller than pages, and readers are still human, so the old ergonomic factors still apply. Kanguole 15:33, 13 July 2024 (UTC)

The cite magazine template should support the |agency parameter - for example this article https://www.golfdigest.com/story/golf-hope-ap should be cited as "Vegas Hangs On". Golf Digest. Associated Press. January 23, 2011. - but that throws an error. Some magazines do use news agencies so this should be a supported parameter. Tewapack (talk) 19:39, 2 July 2024 (UTC)

Tewapack, lateness of reply acknowledged, but how is this source not a case for {{cite news}}? Granted it's hosted by Golf Digest, but nothing on the page indicates it was published as a story in any issue of their periodical. It appears just to be a wire story that they reprinted online. I'd probably go with {{cite news |url= https://www.golfdigest.com/story/golf-hope-ap |title= Vegas Hangs On |work= Golf Digest | date= January 23, 2011 |agency= Associated Press}} Folly Mox (talk) 16:13, 13 July 2024 (UTC)

In a conversation at Template talk:Internet Archive#Registration required parameter it was pointed out that {{Cite book}} does not produce an external link indicator for a title URL if |url-access= is specified:

• Bloggs, Joe. Book of Bloggs.
• Bloggs, Joe. Book of Bloggs.

What's the rationale? -- Michael Bednarek (talk) 14:26, 7 July 2024 (UTC)

If there was any discussion to explicitly overwrite the external link icon, I don't recall it. You might find your answer somewhere in the archives. I think the first discussion in a rather long chain of discussions might be at Help talk:Citation Style 1/Archive 13 § Open access icon.

If I had to guess, I would say that we opted to do as MediaWiki does with external links to pdf documents:

[https://example.com/document.pdf A PDF Document] → A PDF Document

—Trappist the monk (talk) 14:57, 7 July 2024 (UTC)

Seems fine. Having links cluttered with an icon that means "this is an ext. link" followed by another that means "this is an external link to which X access conditions apply" would be redundant and annoying.  — SMcCandlish ☏ ¢ 😼  11:07, 14 July 2024 (UTC)

I tried to use {{ill}} inside a {{cite journal}}, like this:

* {{cite journal |author={{ill|Reinhold Merkelbach|de|Reinhold Merkelbach}} |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

But that currently renders without any wikilink, like this:

• Reinhold Merkelbach [de] (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16. {{cite journal}}: Check |author= value (help)CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

Is this bad interaction fixable by someone who knows about templates? --Quuxplusone (talk) 14:46, 6 July 2024 (UTC)

You'll want to use |author-link=:de:Reinhold Merkelbach, which has the desired effect. Folly Mox (talk) 14:49, 6 July 2024 (UTC)

Not fixable. When expanded, your example {{ill}} produces this:

[[Reinhold Merkelbach]]<span class="noprint" style="font-size:85%; font-style: normal; ">&nbsp;&#91;[[:de:Reinhold Merkelbach|de]]&#93;</span>

|author= wants to see only a single name (which may be wikilinked) but it certainly does not want to see the styling that {{ill}} adds.

One other way to wikilink the author's name is:

|author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]]

—Trappist the monk (talk) 15:06, 6 July 2024 (UTC)

Hm, that's too bad. I'm not a fan of unmarked wikilinks to non-English Wikipedias, so the suggestion to mark it up as Reinhold Merkelbach (via author-link or otherwise) is right out. I'll leave it as-is for now, but I hope this can be fixed someday. (For example, by finding whatever innards of the author field currently "want[] to see only a single name (which may be wikilinked)" and whitelisting {{ill}} as a valid possibility there, too.) --Quuxplusone (talk) 17:39, 6 July 2024 (UTC)

Not going to happen. cs1|2 annotates interwiki-linked author names so that readers can see that the interwiki-linked author name is at a non-English Wikipedia:

{{cite journal |author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

Reinhold Merkelbach [in German] (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16.

—Trappist the monk (talk) 17:54, 6 July 2024 (UTC)

I understand the reasons for the behaviour by the citation templates. However, this construction, [[:xx:Name]], will AFAIK forever prevent those links to be automatically converted to a local link if an article for that author gets written here. I wonder if this could be improved if the templates added a tracking category in those cases (in article space only) so that User:Cewbot's task #1, run by User:Kanashimi, has a way of locating this usage. -- Michael Bednarek (talk) 00:54, 7 July 2024 (UTC)

The bot can only handle interlanguage templates. Sorry it can't handle links to other language wikipedias, that would require quite a bit of extra work. Kanashimi (talk) 02:38, 7 July 2024 (UTC)

A tracking category for interwiki links in templated citation authors could still be useful for others to check. —David Eppstein (talk) 04:09, 7 July 2024 (UTC)

In the sandbox, interwiki-linked and interproject-linked names (author, editor, etc) will be categorized in one of two new properties categories. When both project and language are part of the link prefix, only the project will be categorized; this is in keeping with the rendered annotation. Using the example above, copy one (or both) of these to someplace in mainspace (necessary because prop cats are suppressed here), edit and preview (do not save):

{{cite journal/new |author=[[:de:Reinhold Merkelbach|Reinhold Merkelbach]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

{{cite journal/new |author=Reinhold Merkelbach |author-link=:d:Q972677 |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |year=1989 |pages=15–16 |url=https://www.jstor.org/stable/20187001}}

At the bottom of the mainspace article you will see two red-linked categories:

Category:CS1 interwiki-linked names

Category:CS1 interproject-linked names

Articles in those categories will be sorted by the interwiki or interproject prefix.

Keep? Discard?

—Trappist the monk (talk) 17:41, 13 July 2024 (UTC)

A safer test is to copy the templates to the 'Input wikitext' box at Special:ExpandTemplates. Then click OK. Redlinked cats at the bottom of the page.

—Trappist the monk (talk) 17:49, 13 July 2024 (UTC)

"cs1|2 annotates interwiki-linked author names so that readers can see that the interwiki-linked author name is at a non-English Wikipedia" — Oh, that's awesome! I recommend tweaking the formatting just a little bit, so that instead of displaying as "Reinhold Merkelbach [in German]" it would display as "Reinhold Merkelbach [‌de‌]". (That's trivial, and would also address Michael Bednarek's defect report.) And then perhaps instead of making the user have to know to type [[:de:Thing|Thing]], permit them to type {{ill|Thing|de|Thing}}. That would have the effect of accomplishing what I'm looking for, as a very small modification of what you've already implemented. --Quuxplusone (talk) 17:41, 7 July 2024 (UTC)

The implementing discussion may explain to you why we did not do what you want us to do: Help talk:Citation Style 1/Archive 86 § author-link=interlanguage

—Trappist the monk (talk) 18:00, 7 July 2024 (UTC)

Keep? Discard? +1 for 'keep'. -- Michael Bednarek (talk) 03:00, 14 July 2024 (UTC)

I have to think that, for metadata purposes, it would be much cleaner to do this:

{{cite journal |last=Merkelbach |first=Reinhold |author-link=de:Reinhold Merkelbach |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |date=1989 |pages=15–16 |url= https://www.jstor.org/stable/20187001}}

But for some reason this is mis-rendered, presumably due to some questionably desirable pre-filtering of the value of |author-link=:

Merkelbach, Reinhold (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16. {{cite journal}}: Check |author-link= value (help)

This:

{{cite journal |last=Merkelbach |first=Reinhold |author-mask=[[de:Reinhold Merkelbach|Merkelbach, Reinhold]] |title=Zwei neue orphisch-dionysische Totenpässe |lang=de |journal=Zeitschrift für Papyrologie und Epigraphik |number=76 |date=1989 |pages=15–16 |url= https://www.jstor.org/stable/20187001}}

also fails:

Merkelbach, Reinhold (1989). "Zwei neue orphisch-dionysische Totenpässe". Zeitschrift für Papyrologie und Epigraphik (in German) (76): 15–16. {{cite journal}}: Check |author-mask= value (help)

Ideally, I would think |author-link= would be the way to do this, and that it would detect the canonical other-project prefixes (mostly language codes), and do {{ILL}}-style stuff. Even if that's too much work, then just not barfing on a xx: language-code prefix would be good, even if does no extra things borrowed from {{ILL}} and just builds the link the way doing a bare [[de:Reinhold Merkelbach|Merkelbach, Reinhold]] works outside the template: Merkelbach, Reinhold.  — SMcCandlish ☏ ¢ 😼  11:21, 14 July 2024 (UTC)

You are mistook:

[[de:Reinhold Merkelbach|Merkelbach, Reinhold]] → Merkelbach, Reinhold

works in this namespace but does not work in mainspace because the above markup is for adding interwiki links to the languages menu. Prove it to yourself by editing a page that does not list Deutsch in the languages menu (USS Will Rogers is one such). Edit and paste the above wikitext into the article and preview. Deutsch will be listed in the languages menu but Merkelbach will not be found where you inserted the link. This is why your example templates show the Check author-link= value error message. We don't want to be indiscriminately adding links to the languages menu so Module:Citation/CS1 suppresses the malformed author link whether the template wikilinks the |author= parameter or uses the |author-link= parameter; contributor, editor, etc links similarly suppressed.

This is, by the way, discussed at the error message's help link.

—Trappist the monk (talk) 14:52, 14 July 2024 (UTC)

• 34 (19 September 2021). "Lane Rasberry". 34Questions. YouTube. {{cite web}}: |author1= has numeric name (help)

The |author1=34 generates a red message. This is how the author signs their name, "34", and the name of the work is 34Questions. Is there a way to express this without a red message? -- GreenC 23:08, 16 July 2024 (UTC)

{{cite av media |author1=((34)) |title=Lane Rasberry |url=https://www.youtube.com/watch?v=gmhsqYsvz-I |publisher=34Questions |via=YouTube |language=en |date=19 September 2021}}

34 (19 September 2021). Lane Rasberry. 34Questions – via YouTube.

—Trappist the monk (talk) 23:14, 16 July 2024 (UTC)

Cite paper redirects to Cite journal. What should be done when the paper in question is a white paper published by a manufacturer, but not part of a journal, and not one of a clear series? It's more of a technical backgrounder on their significant invention. Andy Dingley (talk) 13:50, 14 July 2024 (UTC)

I use {{Citation}} for this sort of source, but if it's online and you don't need specific page numbers, {{Cite web}} will work. Both templates accept |series=. If this is about Paxman Hi-Dyne engines, I'd probably go with {{Cite web}}, since the reproduction of the original via Richard Carr's Paxman History Pages is a human conversion to HTML and the original source is not what was consulted. Folly Mox (talk) 14:39, 14 July 2024 (UTC)

I have a photocopy of the paper copy too, but there's nothing useful on there about a journal as such.

I know it's pointless on WP, because they're all just redirects, but I do prefer the semantics of marking up journals as journals and papers as papers. Andy Dingley (talk) 14:46, 14 July 2024 (UTC)

Perhaps one could employ |type=White paper? Remsense诉 15:42, 14 July 2024 (UTC)

(edit conflict)

but if it's online and you don't need specific page numbers Do you mean to suggest that {{cite web}} does not support the pagination parameters? If you do then you are mistook:

{{cite web |url=//example.com |title=Title |page=23}} → "Title". p. 23.

{{cite web |url=//example.com |title=Title |pages=23–45}} → "Title". pp. 23–45.

—Trappist the monk (talk) 15:43, 14 July 2024 (UTC)

Is {{cite report}} appropriate here?  —  Jts1882 | talk  15:34, 14 July 2024 (UTC)

Thanks, that seems like the best fix. Andy Dingley (talk) 19:55, 14 July 2024 (UTC)

While we're here: is this also ideal for standards documents? Remsense诉 20:07, 14 July 2024 (UTC)

{{cite standard}} exists. Izno (talk) 23:31, 17 July 2024 (UTC)

Some web servers refuse access as a way of avoiding having to respect the GDPR. This is especially the case for some US-based servers - presumably the idea that ordinary people might have the right to privacy is too radical to some newspapers. See this example for an archiver, in which case the archiver was presumably a server located outside of the US. Maybe there are similar cases for some Russian and Chinese servers that refuse access to people who can't be tracked.

Our current option limited for url-access for {{web cite}} gives the mouseover text Free access subject to limited trial, subscription normally required, which is misleading for web servers that require privacy violation. The alternatives registration and subscription are misleading for this case too.

We need to either:

• add a fourth option, e.g. geolimited with mouseover text Access forbidden to some geographical locations; or
• change the limited text to something more generic such as Free access in some cases.

This will require an extension or correction (respectively) to

['registration'] = {class='id-lock-registration', title='Free registration required'},
['limited'] = {class='id-lock-limited', title='Free access subject to limited trial, subscription normally required'},
['subscription'] = {class='id-lock-subscription', title='Paid subscription required'},

in Module:Citation/CS1/Configuration by someone with editing access. Boud (talk) 11:35, 16 July 2024 (UTC)

Possibly related discussions:

• Help talk:Citation Style 1/Archive 62#Request for new url-access_value(s) - Dec 2019/Jan 2020
• Help talk:Citation Style 1/Archive 74#Intent of url-access=limited - Jan 2021

Neither of these seem to mention the geo-related access-only-with-privacy-violation issue. The GDPR officially became active in 2018 and my feeling is that US geo restrictions were implemented by some US newspapers quite rapidly. But it seems like this issue hasn't been discussed earlier. Boud (talk) 11:45, 16 July 2024 (UTC)

See Help talk:Citation Style 1/FAQ. This is not going to be done, and it is a misuse of these parameters to specify that a geo-limitation is enforced on the URL. Izno (talk) 23:30, 17 July 2024 (UTC)

This would cover DOI patterns

• 10.1093/mnras
• 10.1111/j.1365-2966
• 10.1046/j.1365-8711

Is is possible to implement those? Headbomb {t · c · p · b} 02:44, 17 July 2024 (UTC)

I presume that you are asking if it is possible to mark dois that match these patterns with the CS1 maint: unflagged free DOI maintenance message. Possible but costly. If we create a list of these sorts of patterns, each pattern must be individually matched against every doi that is not marked with |doi-access=free and the doi registrant is not listed as always free. The test for always-free dois does not suffer from this because the free-registrant table is converted from a sequence to an associative array (only occurs once per article rendering). Looking up a doi registrant in the array is quick.

Seems to me that this is a task better suited to some sort of bot.

—Trappist the monk (talk) 11:46, 17 July 2024 (UTC)

Why couldn't the others also be converted to an associative array? I know with regex, it's rather trivial to match those (e.g. 10\.1093\/mnras). The reason why this would be desirable is that it's rather trivial to find something like insource:/10\.1046\/j\.1365-8711/, but it's close to impossible, if not impossible to find which citations aren't marked with |doi-access=free. And with ~7000 articles citing MNRAS, it's extremely inefficient to do Citation bot runs in the hopes of catching stragglers. Headbomb {t · c · p · b} 12:24, 17 July 2024 (UTC)

Extracting the doi registrant from a doi prefix is easy because the registrant is always delimited by 10.registrant/ so in regex: registrant = 10\.([^\/]+)\/. To determine if that registrant is free-to-read, we simply index into the known-free associative array: is_free = known_free_doi_registrants_t[registrant].

it's rather trivial to match those (e.g. 10\.1093\/mnras). True, but every doi in the article must be tested like that. And if not found, we then have to test every doi in the article with 10\.1111\/j\.1365-2966. And if not found, we then have to test every doi in the article with 10\.1046\/j\.1365-8711.

The portions of the doi suffixes that you name above are not fixed length and aren't delimited by always-known delimiting characters so each doi must be tested against each pattern.

—Trappist the monk (talk) 14:19, 17 July 2024 (UTC)

If we create an associative array where the registrant is the index and the value is a sequence of unique doi suffix incipits then it is simple to test each registrant without having to test each doi suffix. So, if the array looks like this:

local extended_registrants_t = {												-- known free registrants identifiable by the doi suffix incipit
	['1046'] = {'j.1365-8711'},													-- MNRAS
	['1093'] = {'mnras'},														-- MNRAS
	['1111'] = {'j.1365-2966'},													-- MNRAS
	}

So, for registrant 1234 not a known registrant and not an extended registrant no further testing required. Registrant 5320 is a known free-to-read registrant so if no |doi-access=free add the maint cat. Registrant 1093 is an extended registrant so for each value in its associated sequence, do a string find for that value. If found and no |doi-access=free add the maint cat. Still slower but not so bad as I was thinking it would be.

{{cite journal/new |title=Title |journal=Journal |doi=10.1093/mnras/summat}}

"Title". Journal. doi:10.1093/mnras/summat.{{cite journal}}: CS1 maint: unflagged free DOI (link)

{{cite journal/new |title=Title |journal=Journal |doi=10.1111/j.1365-2966.summat}}

"Title". Journal. doi:10.1111/j.1365-2966.summat.

{{cite journal/new |title=Title |journal=Journal |doi=10.1046/j.1365-8711.summat}}

"Title". Journal. doi:10.1046/j.1365-8711.summat.

—Trappist the monk (talk) 16:12, 17 July 2024 (UTC)

Why not just test for "1046/j.1365-8711" directly? Anyway, if the above works, we have a way of tagging specific open access journals, when the DOI patterns are journal-specific. Headbomb {t · c · p · b} 20:44, 17 July 2024 (UTC)

I already answered that question. If I did not explain it clearly enough, tell me what it is that you don't understand.

—Trappist the monk (talk) 22:02, 17 July 2024 (UTC)

My bad, I only saw the second reply the first time around. Headbomb {t · c · p · b} 22:40, 17 July 2024 (UTC)

I request making parameter access-date to be used if there is a DOI or a PMID. Currently an error appears with an access date parameter without a URL, meaning the "|access-date=2015-02-11" part has to be in an HTML comment outside of the template (cf., inter alia, Desmarestiales).

Having no need for a URL for an access date to be used helps when one uses a book (or a book chapter, if the book is there but some chapters are not) or a journal article that is not accessible online, for it was not uploaded.

An alternative solution would be to have a URL or a DOI, or a HDL, or a PMCID, or a PMID to be required to make the access date able to be used. Alfa-ketosav (talk) 08:34, 22 July 2024 (UTC)

These would be completely pointless. doi:10.1086/392675, for example, will always refer to a paper published in March 1999. That you read it on January 4, 2014, March 28, 2022, or July 1, 2024, is completely inconsequential. Same for all other identifiers. Headbomb {t · c · p · b} 09:00, 22 July 2024 (UTC)

Alfa-ketosav, |access-date= is intended only for sources whose content is likely to change over time, so people can locate the cited version in archives. Stable identifiers point to content that doesn't change. What do you feel the benefit is to adding this datum to stable sources? Folly Mox (talk) 10:55, 22 July 2024 (UTC)

If the URLs DOIs point to change, or a journal's website shuts down, it may be possible that a DOI breaks, even if only for a short time. Alfa-ketosav (talk) 11:18, 22 July 2024 (UTC)

Which still won't make the paper you read any different. Headbomb {t · c · p · b} 11:21, 22 July 2024 (UTC)

Editor Uzume, where is the discussion about these changes?

—Trappist the monk (talk) 11:23, 25 July 2024 (UTC)

@Trappist the monk: right here, apparently. —Uzume (talk) 11:26, 25 July 2024 (UTC)

Nothing happens here without we discuss it. Please justify these changes. To me, the current url prefixes are easier for human readers to interpret, especially the prefix for OCLC. The current prefix clearly indicates what the worldcat url points to: https://www.worldcat.org/oclc/ can easily be read by humans as an OCLC identifier url; https://search.worldcat.org/title/ cannot.

Is there any indication from worldcat that the current prefixes are about to become unsupported?

—Trappist the monk (talk) 11:52, 25 July 2024 (UTC)

@Trappist the monk: I would be curious what documentation you might find on the subject. As far as I know there is no indication that the current prefixes will continue to be supported either but they do still work for the time being. —Uzume (talk) 14:35, 25 July 2024 (UTC)

You are the editor who wants this change so the burden of demonstrating its necessity falls to you.

For a bit of history of the OCLC prefix:

• 2006-09-12: included in {{OCLC}} at the creation of that template (http://worldcat.org/oclc/)
• 2012-08-27: introduced to Module:Citation at this edit (as protocol relative //www.worldcat.org/oclc/)
• 2013-02-19: included in Module:Citation/CS1 at the creation of that module (also protocol relative)
• 2013-04-07: moved to Module:Citation/CS1/Configuration at this edit (also protocol relative)
• 2023-02-09: switched from protocol relative to https scheme at this edit (https://worldcat.org/oclc/)

I acknowledge that past performance is no predictor of future existence. I wonder how often worldcat's internal remapping of the OCLC urls has changed in the 18 or so years since en.wiki started linking to that service.

—Trappist the monk (talk) 16:34, 25 July 2024 (UTC)

@Trappist the monk: I do not want the change but change has a way of always coming whether we want it or not. I think the burden is on OCLC but at some point we will likely have to deal with changes at WorldCat. Feel free to delay it or ignore it. I was just trying to get ahead of what might break in the future. I took the time to make the changes. If people want to throw them away I do not mind. —Uzume (talk) 17:23, 25 July 2024 (UTC)

@Trappist the monk: I suppose the biggest argument for such links is that if one goes to such a record, e.g., {{OCLC search link|22239204}} → 22239204 (and yes, @Folly Mox the template is called "OCLC search link" so it is a search), then that page has a button for sharing a link to the record and from there, an item entitled "Copy link" which presumably is the link WorldCat recommends people use. And that yields: https://search.worldcat.org/en/title/22239204, providing the link prefix of https://search.worldcat.org/en/title/ before the identifier to be linked to. So, perhaps I failed to get the URL correct and did not specify the "en" English UI (I tested and links like https://search.worldcat.org/ja/title/22239204 link to the same record with a Japanese UI). Please feel free to update the link prefixes appropriately. Incidentally, that very same record also has a "show more information" link that provides more information and within that it links to the "Online version" of the represented item. That link points to https://search.worldcat.org/search?q=no:701649298 providing a means to get to items via their search query. Perhaps you'd prefer that link prefix as https://search.worldcat.org/search?q=no: for OCLC searches directly aligns with the link prefix https://search.worldcat.org/search?q=n2: for ISSN searches. —Uzume (talk) 21:35, 25 July 2024 (UTC)

I don't think it makes sense for an identifier to link to a search. Jmo. Folly Mox (talk) 14:17, 25 July 2024 (UTC)

I've reverted the recent changes to identifier templates and infoboxes pending the outcome of this discussion Headbomb {t · c · p · b} 14:29, 25 July 2024 (UTC)

@Headbomb: Your powers of reversion are amazing as always. Incidentally, at least with respect to ISSN, the change to use a search URL was discussed at Template talk:ISSN#Change request, requested by an editor without an account (IP user) and made by @MSGJ with 415549762 back in 2011-02-23 (more than 13 years ago at the time of this writing). —Uzume (talk) 16:19, 25 July 2024 (UTC)

@Headbomb: Perhaps you'd prefer moving to issn.org as per your 942292297 in Feb 2020. I think that is a great idea. —Uzume (talk) 17:36, 25 July 2024 (UTC)

@Folly Mox: Why not? When you select such a link you are searching their federated union catalogue for that identifier (either their OCLC control number/WorldCat title ID or an ISSN). —Uzume (talk) 14:44, 25 July 2024 (UTC)

I understand that https://www.worldcat.org/oclc/identifier resolves to https://search.worldcat.org/title/identifier, but as Trappist said above, humans might parse it differently on sight. For me personally, it gives the feeling that we don't actually know the OCLC identifier, and to people unfamiliar with the system entirely, they might not make the connexion between search.worldcat.org and OCLC. I don't feel particularly strongly about this, and have no opinion whatsoever about the ISSN bits, since I rarely include them and never click through on them. Folly Mox (talk) 22:10, 25 July 2024 (UTC)

I wanted to cite this: http://www.rafmuseum.org.uk/documents/Research/RAF-Historical-Society-Journals/Journal-11-Sir%20Frank-Cooper-on-Air-Force-Policy-in-the-1950s-1960s.pdf ("THE PROCEEDINGS OF THE ROYAL AIR FORCE HISTORICAL SOCIETY, Issue No 11"), but {{cite proceedings}} ignores the |issue= parameter. The only supported parameter seems to be |volume=, but it unconditionally adds "Vol." and complains "|volume= has extra text" about anything that is not a plain digital number. Can the proper output be achieved using currently existing templates, or {{cite proceedings}} needs to be modified (then please do)? — Mikhail Ryazanov (talk) 18:10, 25 July 2024 (UTC)

Use cite journal. Cite proceedings is for conference proceedings. Headbomb {t · c · p · b} 18:37, 25 July 2024 (UTC)

{{cite journal}} requires both |title= and |journal=, but I need to cite the whole publication. And it's not a journal issue but really proceedings from their symposium (which "in modern usage, [means] an academic conference or meeting, such as a scientific conference"). — Mikhail Ryazanov (talk) 21:06, 25 July 2024 (UTC)

That looks like a journal with "proceedings" as part of its title (as many journals have), not a proceedings of a conference, to me. You should use cite journal for any paper published within it. It is not generally useful to cite whole issues of journals, but maybe the editorial is what you want to cite. As for the symposium: the editorial makes clear that this issue of this journal is filled with some but not all papers from the symposium. It is not the proceedings of the symposium (a book of all the papers from the symposium). It is an issue of a journal (the proceedings of the society) that happens to contain many but not all papers from a symposium with a different name. —David Eppstein (talk) 21:19, 25 July 2024 (UTC)

{{cite proceedings}} is a redirect to {{cite conference}}. {{cite conference}} is screwy (because no one has ever complained enough?). It will support |issue= if it also contains |journal=:

{{cite proceedings |title=Title |journal=Journal |volume=XX |issue=4 |conference=Conference}}

Title. Conference. Journal. Vol. XX, no. 4.

In the above example, |title= should not be italicized.

I agree with Editor David Eppstein except that I think that The Proceedings of the Royal Air Force Historical Society is a periodical rather than a journal. Use either; your call.

—Trappist the monk (talk) 21:53, 25 July 2024 (UTC)

My particular example is from Humphrey de Verd Leigh § External links. Here I've tried to format it more reasonably than it was, but it's not clear what exactly was supposed to be cited (Leigh is mentioned directly in at least two different presentations by different authors, but there might be also something else related). RAF Historical Society itself seems to call it a "journal", but at the same time says that "proceedings of each seminar, and the guest speaker’s paper read at each AGM, are published" in it. I don't know how people distinguish "periodical" and "journal", but this one is not very periodic (they had several issues in 1991, then none in 1992, then only this one in 1993, then several in 1994...). — Mikhail Ryazanov (talk) 22:30, 25 July 2024 (UTC)

The only (very brief) mention of Humphrey de Verd Leigh is in a single paper:

• Paris, Michael (1993). "Flying training in the RFC, 1912–1915: A failure to prepare?" (PDF). Proceedings of the Royal Air Force Historical Society (11): 25–30.

What reason do you have for insisting on citing the whole issue rather than being more specific? —David Eppstein (talk) 23:30, 25 July 2024 (UTC)

I'm not insisting and have no reason for that, please read my explanations above. If you know better what to do, just go ahead. — Mikhail Ryazanov (talk) 23:46, 25 July 2024 (UTC)

I explicitly suggested what to do above: cite the single paper by Paris that mentions the subject, as a journal paper, using the formatting I used. —David Eppstein (talk) 23:50, 25 July 2024 (UTC)

Is there a way to display the title of a work in quotes rather than italics when using {{Cite AV media}}? I can't figure out a way to change the default italic formatting. Lord Bolingbroke (talk) 01:32, 28 July 2024 (UTC)

Please add a new function 'list' (or maybe, 'languages') to Module:CS1 translator that returns a list of all the supported languages. My immediate use case is about mentioning this module on a Talk page, and naming the language list, so ideal would be comma-separated, and pre-final 'and': i.e, "Arabic, Chinese, , ... , and Turkish". (That suggests other possible enhancements down the road, including: returning WP (ISO)-prefix codes, or returning one language name given an index number or a WP/ISO code, returning the name if it's supported and empty if it isn't, for use in table-building, or support-checking. I can give a specific case where this would be useful, if interested, on an instruction page for translators.) Thanks, Mathglot (talk) 01:12, 31 July 2024 (UTC)

If you [mention] this module on a Talk page, you could link to it. The module documentation, right at the top, has a table of supported templates with their associated languages (see Module:CS1 translator § Supported templates). If this is too technical, does {{Non-English citation templates}} answer?

Is there a demonstrable need? This sounds like 'it sure would be nice if someone created thing one in case someday, someone else, might want to do thing two.'

—Trappist the monk (talk) 13:38, 31 July 2024 (UTC)

Okay, that'll do. Mathglot (talk) 19:10, 31 July 2024 (UTC)

For two articles in this category, I can't find the red error message:

• 2024 United Kingdom general election
• Results breakdown of the 2024 United Kingdom general election

Normally cntrl-f searching the rendered page for "archive-url" finds it. -- GreenC 23:10, 1 August 2024 (UTC)

I edited, changed nothing, published: not in category anymore.

—Trappist the monk (talk) 23:38, 1 August 2024 (UTC)

Thanks. I did purge, needed null. Never been clear on the difference. -- GreenC 01:49, 2 August 2024 (UTC)

{{Cite standard}} is currently a redirect to {{Cite tech report}}. I feel this is unideal, as the |type= specified is unideal when citing standards, which are distinguished from technical reports by many bodies. Would it be a headache to retarget this redirect in a manner that only changes this parameter? Not sure if |type=Standard or left unset is ideal, but. Remsense诉 23:46, 1 August 2024 (UTC)

If you don't like the auto-value assigned to |type= choose another: |type=Standard or if that isn't acceptable, |type=none.

{{cite standard |title=Title}}

Title.

{{cite standard |title=Title |type=Standard}}

Title (Standard).

{{cite standard |title=Title |type=none}}

Title.

—Trappist the monk (talk) 01:00, 2 August 2024 (UTC)

Of course: my point is that since this would have to be done in each case, I would question the utility of this particular redirect. Remsense诉 01:03, 2 August 2024 (UTC)

There is no way to cite a standard and have cs1|2 autoset |type=Standard (or whatever). You can avoid using {{cite standard}} and use another cs1|2 template but you will still need to manually set |type= if you want the template to render a type. If you don't, use a cs1|2 template that doesn't autoset |type=. Alternately, change {{cite standard}} from a redirect to a wrapper template around your favorite cs1|2 template and preset |type= to your preferred value.

—Trappist the monk (talk) 01:14, 2 August 2024 (UTC)

I was considering the latter, thank you for your expertise! Remsense诉 01:57, 2 August 2024 (UTC)

The |type= parameter is an alias for |medium=; repurposing it as |type=standard precludes using |medium=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:29, 2 August 2024 (UTC)

Sorry to persist about this, but as stated in this discussion about the issue: invisible templates such as {{Bots}} and {{CS1 config}} emit a newline, which is apparently an ancient bug avoided in other widely used templates like {{EngvarB}}with a <nowiki>...</nowiki> hack. If it's not liable to create problems, would it be possible to implement this same workaround in {tlx|Bots}} and {{CS1 config}} for the time being? Remsense诉 00:04, 2 August 2024 (UTC)

Phabricator: https://phabricator.wikimedia.org/T369520

And a ping to John of Reading when he returns from vacation; he seems to have come up with the hack here: [7] Rjjⁱⁱⁱ (talk) 00:16, 2 August 2024 (UTC) Edit: old discussion at VPT 00:19, 2 August 2024 (UTC)

@Rjjiii: That hack should be fine in these templates. I don't have TE rights currently, so cannot make the edits. -- John of Reading (talk) 07:28, 3 August 2024 (UTC)

User:Jon (WMF) has posted a message in Module talk:Citation. Since that page is a redirect, I provided a {{-r}} link to that comment. Nickps (talk) 19:30, 2 August 2024 (UTC)

The misplaced section has been moved below: #Urgent: Please fix this template for printed content Module:Citation/CS1/styles.css. —⁠andrybak (talk) 22:11, 2 August 2024 (UTC)

I have already corrected this issue. Izno (talk) 23:09, 2 August 2024 (UTC)

 Done

Thank you! Jon (WMF) (talk) 01:12, 3 August 2024 (UTC)

"Newsroom" (or "newsroom", "News-room", "news-room", "News Room", "News room", "news room"). I've encounted this in |last= at least twice in the last month or so. Might need to flag "News" by itself, too, though I guess it's conceivable for someone to be named something like "Janet News". I know for a fact that Room is an extant surname.  — SMcCandlish ☏ ¢ 😼  11:01, 14 July 2024 (UTC)

That reminds me that I keep running into "Company" in |last= and was a bit surprised it's not considered a generic name. An insource: search yielded around 1000 hits, including maybe 30% false positives because I didn't want to pound the servers with a regex to escape the =. A quick scroll through the first 500 results showed a single valid usage as a surname, at Ziphosuchia, with the balance of true positives consisting of publishing companies misparsed by Citoid and pals. Folly Mox (talk) 11:24, 14 July 2024 (UTC)

We might add a test to find only Company or company as whole values. If someone cares to check the results of this search if may be possible to loosen the restriction so that the test finds names that include Company or company. Corporate authors are allowed so I don't think that we can error when a name simply includes Company or company.

—Trappist the monk (talk) 15:30, 14 July 2024 (UTC)

Sorry for the inclarity, but yes I meant specifically just |last=Company, without involving substring matching. Folly Mox (talk) 21:40, 14 July 2024 (UTC)

User:DreamRimmer has taken care of the largest single offender in this category of error following a request at WP:AWBREQ. A search for insource:"last Company first" now returns only around 350 matches, although of course it misses cases where the parameters are in a different order. The one author we cite whose actual human surname is "Company" is cited in at least three articles as it turns out, the other two being Ischyrochampsa and Wanosuchus (I note to myself for future double parentheses). Folly Mox (talk) 00:18, 18 July 2024 (UTC)

Before timing out, this search found ~2040 articles that have |lastn= or |authorn= parameters with values that begin News or news. When I ran that search, I found: Newsby, Newsinger, Newsom, Newsome, Newstead, Newsum among the first 20 results; some of them multiple times. So our generic name search is limited to finding only News or news as whole values to avoid false positives.

For the others that you name:

Newsroom and newsroom: ~570 articles

News-room and news-room: none

News Room, News room, and news room: 2 (times out)

Adding a specific test for Newsroom and newsroom seems worthwhile; the others, not.

—Trappist the monk (talk) 15:30, 14 July 2024 (UTC)

Another that you all should look at is |lastn=Bureau or |authorn=Bureau. This search fund about 8300 articles where the assigned value begins with Bureau. Of those about 6680 hold only the word Bureau. There are authors whose surname is Bureau.

—Trappist the monk (talk) 16:59, 15 July 2024 (UTC)

Added tests for bureau and company as whole values; added test for the various forms of newsroom named in the OP where the word(s) may appear anywhere in the parameter value:

{{cite book/new |title=Title |last=Bureau}} → Bureau. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=Bureau}} → Bureau drawer. Title.

{{cite book/new |title=Title |last=Company}} → Company. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=Company}} → Mega Huge Company. Title.

{{cite book/new |title=Title |last=Newsroom}} → Newsroom. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=News room}} → News room. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=News-room}} → News-room. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=The News Room}} → The News Room. Title. {{cite book}}: |last= has generic name (help)

—Trappist the monk (talk) 14:03, 22 July 2024 (UTC)

And one more: Desk whole word:

{{cite book/new |title=Title |last=Desk}} → Desk. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=Desk drawer}} → Desk drawer. Title.

—Trappist the monk (talk) 16:03, 22 July 2024 (UTC)

And two more: Group and Limited both whole word:

{{cite book/new |title=Title |last=Group}} → Group. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=Group photo}} → Group photo. Title.

{{cite book/new |title=Title |last=Limited}} → Limited. Title. {{cite book}}: |last= has generic name (help)

{{cite book/new |title=Title |last=Limited availability}} → Limited availability. Title.

—Trappist the monk (talk) 14:05, 24 July 2024 (UTC)

Another worth considering is correspondent as the only entry in an author field. Currently 515 occurances. Keith D (talk) 10:33, 27 July 2024 (UTC)

This search suggests rather more than 500 articles with correspondent in |authorn= or |lastn=:

Added:

{{cite book/new |title=Title |author=Correspondent}} → Correspondent. Title. {{cite book}}: |author= has generic name (help)

{{cite book/new |title=Title |last=Correspondent Bank}} → Correspondent Bank. Title. {{cite book}}: |last= has generic name (help)

—Trappist the monk (talk) 13:52, 27 July 2024 (UTC)

And another? What about |last=staff? Before it times out, this search finds about 19,500 articles where |last=authorn or |lastn= is assigned the single value Staff or staff. Is 19,500+ to much to dump into Category:CS1 errors: generic name‎ (38,135)? Certainly we could write an awb script to remove parameters that are assigned the single value Staff. The script must also remove matching |firstn= when present.

Displaying 'Staff' as an author name seems to me contrary to our past advice where we used to recommended |author=<!--Staff writer(s); no by-line.--> which seemed to implicitly suggest that we should not be using 'Staff' as an author name. At this edit in November 2016, pursuant to this discussion we changed the recommended hidden text. It also seems to me that specifically naming 'Staff' as an author doesn't make it any easier for readers to locate a source because that name is too generic. Staff then amounts to pointless clutter. As an alternate option we could have the awb script convert Staff to <!--Not stated-->. This same awb task could also be used to replace <!--Staff writer(s); no by-line.--> with <!--Not stated-->.

What do?

—Trappist the monk (talk) 22:28, 7 August 2024 (UTC)

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

On line 1179 of Module:Citation/CS1/Configuration/sandbox, I have added 'grc' to the array script_lang_codes, so that Ancient Greek can be supported as a script-title language. Trappist the monk has also added 'ce' to the same array, for Chechen, which should also be safe to add, but these are not the only changes between the sandbox and the live version of the include, so please copy over the whole array definition from line 1178 to 1183. (Note too that the array includes manual line breaks, so some items have moved onto the following line, compared with the live version; please check that no duplicate values exist in the array before saving.) Thank you! — OwenBlacker (he/him; Talk) 21:11, 3 August 2024 (UTC)

No need to hurry. The grc text is correctly marked up:

{{Citation |author=[[Herodian]] |script-title=grc:Τῆς μετὰ Μάρκον βασιλείας ἱστορία |trans-title=History of the Empire from the Death of Marcus |at=[http://www.tertullian.org/fathers/herodian_03_book3.htm#C8 III, 8, 2] |language=grc}}

'"`UNIQ--templatestyles-000000D9-QINU`"'<cite id="CITEREFHerodian" class="citation cs2 cs1-prop-script cs1-prop-foreign-lang-source-2">[[Herodian]], <bdi lang="grc" >Τῆς μετὰ Μάρκον βασιλείας ἱστορία</bdi> &#91;''History of the Empire from the Death of Marcus''&#93; (in Ancient Greek), [http://www.tertullian.org/fathers/herodian_03_book3.htm#C8 III, 8, 2]</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=grc%3A%CE%A4%E1%BF%86%CF%82+%CE%BC%CE%B5%CF%84%E1%BD%B0+%CE%9C%CE%AC%CF%81%CE%BA%CE%BF%CE%BD+%CE%B2%CE%B1%CF%83%CE%B9%CE%BB%CE%B5%CE%AF%CE%B1%CF%82+%E1%BC%B1%CF%83%CF%84%CE%BF%CF%81%CE%AF%CE%B1&rft.pages=III%2C+8%2C+2&rft.au=Herodian&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+95" class="Z3988"></span>

Herodian, Τῆς μετὰ Μάρκον βασιλείας ἱστορία [History of the Empire from the Death of Marcus] (in Ancient Greek), III, 8, 2

It is my intention to update all of the cs1|2 suite modules within the next couple of weeks.

—Trappist the monk (talk) 21:44, 3 August 2024 (UTC)

Fair enough; I'm certainly in no hurry and had seen that the markup was working. I mainly just wanted to suppress the error message once I spotted it. If you're already on it, then I'll leave you to it. Thank you! 🙂 — OwenBlacker (he/him; Talk) 22:32, 3 August 2024 (UTC)

Each parameter to be wrapped in a <span class="cs1parameter"></span>?

For example, if we had

• Linden, David van der (23 December 2015). "Coping with crisis. Career strategies of Antwerp painters after 1585". De Zeventiende Eeuw. Cultuur in de Nederlanden in Interdisciplinair Perspectief. 31 (1): 18. doi:10.18352/dze.10126.

That was built something like

• <span class=cs1last>Linden</span>, <span class=cs1first>David van der</span> (<span class=cs1date>23 December 2015</span>). "<span class=cs1title>Coping with crisis. Career strategies of Antwerp painters after 1585</span>". <span class=cs1journal>''De Zeventiende Eeuw. Cultuur in de Nederlanden in interdisciplinair perspectief''</span>. <span class=cs1volume>'''31'''</span> (<span class=cs1issue>1</span>): <span class=cs1pages>18</span>. <span class=cs1doi>{{doi|10.18352/dze.10126}}</span>.

Then people could customize how citation look. Don't want ISSNs to display? hide them with your own CSS tweaks. Don't like last/first order? Rejiggle it to First/Last with CSS. Want "vol./no./p. or pp." to show or not show? CSS tweaks again.

Headbomb {t · c · p · b} 16:47, 5 August 2024 (UTC)

Adding something like that shouldn't be that hard, but the question is what are the costs for doing so. Would the additional characters cause loading time to increase on large articles? Gonnym (talk) 15:54, 6 August 2024 (UTC)

This would significantly increase the output of a page using CS1 and likely decrease the number of pages that fit under WP:PEIS. Right now our limit seems to be around 600 references on any given day. Playing with it in a text editor with the full output of the initial example (including the coins), we're looking at an increase from 1090 to 1340 bytes, which is about 23%. On a page with 600 references of a similar size, that take the maximum down to about 480. And for pages where more authors are typical in citations, the ratio would grow pretty significantly (and you wouldn't be able to format the multi-author list without Javascript). I think it'd be neat to do something like this, but I don't think it's in the cards without sacrificing coins, which at least has what I think is a more meaningful benefit to people other than the elite. Izno (talk) 21:23, 9 August 2024 (UTC)

Would we need COinS if we had this? Headbomb {t · c · p · b} 21:32, 9 August 2024 (UTC)

Various software consume COinS natively today (notably Zotero). They would need to build adapters of some sort to consume our references marked up like this. Maybe fine for Google who I'm sure uses the data and can adapt at whatever velocity to a change in our output, not so good for the open source and general user community. Izno (talk) 22:09, 9 August 2024 (UTC)

Not related to the bot, but people stalking this page could perhaps help me. What should be done with this reference on Bartholomeus de Momper the Elder:

Linden, David van der (2015). "Coping with crisis. Career strategies of Antwerp painters after 1585". De Zeventiende Eeuw. Cultuur in de Nederlanden in Interdisciplinair Perspectief. 31: 18. doi:10.18352/dze.10126.

The link the doi points to is "for sale" and not working. Can mark the doi link as not working/usurped? Jonatan Svensson Glad (talk) 02:39, 5 August 2024 (UTC)

(talk page stalker) In Special:Diff/1238717754 I marked the DOI inactive using |doi-broken-date=, and provided an alternative URL whilst the journal sorts out its DNS registration. Future inquiries of this sort are best handled at Help talk:Citation Style 1, FYI. Kindly, Folly Mox (talk) 09:52, 5 August 2024 (UTC)

Josve05a, fixing ping. Folly Mox (talk) 09:54, 5 August 2024 (UTC)

The DOI is not broken though. The landing page is usurped. That's a different issue. This should be discussed at Help:CS1. Headbomb {t · c · p · b} 17:00, 5 August 2024 (UTC)

So, anyone got a solution how to mark a doi-link as usurped? Is that an acceptable input in |doi-broken-date= somehow? Jonatan Svensson Glad (talk) 09:04, 9 August 2024 (UTC)

It's true that the DOI is not inactive in the usual sense which leads to a "DOI not found" result at doi.org, but it's not not broken. This is such an unusual situation that I don't think we need a |doi-status=usurped or anything.

I liked my original solution, but it's true I don't know what bots do with the inactive DOI maintenance categories. Headbomb's removal of the |doi-broken-date= is worse, since it leaves the broken link in the reference, but rather than reverting I've commented out the DOI for now. I suppose it could be altered to a plaintext field or postscript, so that it's visible to the reader but not linked to the usurped domain. Folly Mox (talk) 11:08, 9 August 2024 (UTC)

How is this case really any different from the last bullet point at Category:CS1 maint: DOI inactive (transcluded from {{broken doi explanation}})? That item reproduced here for convenience:

• The DOI resolves to a dead link. These are hard to report, since the doi.org thinks the DOI works and sometimes the journal no longer exists.

In this particular case, a squatter is sitting on https://www.de-zeventiende-eeuw.nl/. For our purposes, that link is just as dead as a doi that links to a 404 page. I suspect that the squatter does not return 404 so it may be necessary to tweak Citation bot to look for <meta name="description" content="This domain may be for sale!" /> or some such so that it doesn't inadvertently remove this sort of source from Category:CS1 maint: DOI inactive.

If one is to believe this search, there are eleven articles that have 10.18352/dze... dois.

—Trappist the monk (talk) 13:54, 9 August 2024 (UTC)

My user story is that newer editors using the Visual Editor's built in citation functionality running on Citoid often create garbage citations which have bad values and end up sorted into maintenance categories for others to fix.

There doesn't seem to be any will / urgency to implement any kind of error checking into Citoid: the goal seems to be to integrate it into more Wikimedia projects without addressing most of its problems.

My theory is that we may be able to get inexperienced editors to get in the habit of double checking the automatically generated citations if we show them the errors they're causing as soon as the citation is generated.

Module:CS1 is the thing that can do this best, and already handles it for existing citations.

I'm wondering whether there is or could be a hook somewhere in the module that citations could be passed to whenever they're created in the Visual Editor environment, to give editors instant feedback on the outcome of the Citoid library call.

I'm aware we'd need Foundation cooperation to integrate a CS1 error / maint check, either within Visual Editor or as part of the Edit Check feature once that is deployed. I'm just wondering how possible / difficult this side of it would be. Folly Mox (talk) 22:03, 5 August 2024 (UTC)

One possibility would be to use an edit filter that catches new CS1 errors, warns against them, and requires editors to confirm before saving. I don't think that would require any Wikimedia cooperation. —David Eppstein (talk) 23:11, 5 August 2024 (UTC)

I'm pretty sure there would be a lot of pushback to make the visual editor experience blocked/hampered by filters just on the grounds that the visual editor is shit. Headbomb {t · c · p · b} 00:16, 6 August 2024 (UTC)

VE's citation generator could theoretically detect the presence of errors and maintenance items: since it's already doing the rendering, it can just take what's inside cs1-maint/cs1-visible-error/cs1-hidden-error. Izno (talk) 21:30, 9 August 2024 (UTC)

What if the author is a organization such as AJC Sports? Abhiramakella (talk) 23:51, 10 August 2024 (UTC)

Then use only the |publisher= parameter, and do not specify an individual author. Remsense诉 00:03, 11 August 2024 (UTC)

AJC == The Atlanta Journal-Constitution? Then {{cite news}} and |newspaper=AJC Sports or |work=AJC Sports. Omit |author=. See Help:Citation Style 1 § Authors.

—Trappist the monk (talk) 00:25, 11 August 2024 (UTC)

Editors who use the manual citation generator in the Visual Editor see an interface in which they are unable to enter any author names that do not conform to the Lastname-Firstname naming system. This is not an issue for manual sourcing or for the Wikitext citation generator, which both allow the use of the |author alias. My understanding is that the VE tool does not allow for the use of aliases, and some devs have indicated that changing the template data here is a preferred solution to this [8][9]. VE is already enabled for new users and recommended via pop-up to anonymous editors, so is there a way to adjust the WP:TEMPLATEDATA so that the author field can be used by VE? CMD (talk) 10:44, 11 August 2024 (UTC)

The quirks of VE and TemplateData really are outside of the cs1|2 bailiwick. If what you say is true (I will not use ve so don't really know) then that suggests yet another fault in ve: an inability to recognize and utilize parameter aliases. If that is the case, perhaps phabricator should be your next stop.

Have you tried adding |authorn= as separate parameters to the TemplateData? You should choose different names like Whole author name n. If that works, you should probably update the descriptions to note that only one of |lastn= or |authorn= is allowed – that order for Last name n; flipped for Whole author name n.

—Trappist the monk (talk) 14:40, 11 August 2024 (UTC)

The place to make this change is going to be the Template:Cite web/doc type pages, because these contain the WP:TEMPLATEDATA that is being proposed to be changed here. Template talk:Cite redirects here, which is why I suggested CMD make a post here to verify consensus for this. Phab probably wouldn't be the best place for this since this is an enwiki issue, not a wiki agnostic issue.

To be clear about what we're talking about here, the proposal is to add Author 1, Author 2, etc. to the left side of this screenshot.

This could have implications. For example, the number of folks using last= and first= may go down and the number of folks using author= may go up. If there is someone that goes around changing author= to last= and first= because last= and first= are considered a better practice, for example, then having a little discussion before actioning this may be helpful. –Novem Linguae (talk) 15:44, 11 August 2024 (UTC)

When I suggested WP:PHAB, it is because TemplateData already knows about aliases. This is a snippet from Template:Cite web/doc § TemplateData (the first entry in the rendered table; paramOrder puts last at the top of the table):

"last": {
	"label": "Last name",
	"description": "The surname of the author; don't wikilink, use 'author-link'; can suffix with a numeral to add additional authors",
	"aliases": [
		"last1",
		"author",
		"author1",
		"author1-last",
		"author-last",
		"surname1",
		"author-last1",
		"subject1",
		"surname",
		"author-last",
		"subject"
	],
	"type": "line",
	"suggested": true
},

Clearly, TemplateData already knows about those aliases. There should be no need for editors to add individual entries to the TemplateData for some or all of those aliases. Because all of those aliases are known, ve should be able to present them all to the editor; perhaps as a radio button sublist under Last name with last selected as the default. As the editor, if you want |author= from the alias list, tick that radio button and untick the associated 'First name' checkbox. The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData. And it certainly is not a cs1|2 template problem because cs1|2 templates are not the only templates that use parameters that have aliases. Not going to hold my breath waiting for a MediaWiki solution. In the meantime, the alias list is pointless and editors must add individual TemplateData entries for all aliases. How cumbersome; you can see why I abhor ve.

It has been said here that |first= / |last= is the preferred name-list style but that does not work for all names (most notably Asian names where the separating comma in the rendering is problematic). There is a clumsy workaround for that but a good solution has yet to be discovered. If the goal of ve is to use only preferred parameter names, support for aliases should be withdrawn. Not going to hold my breath for that either.

—Trappist the monk (talk) 16:30, 11 August 2024 (UTC)

Maybe it would help for Chipmunkdavis to provide a concrete example of how they are "unable" to enter an author name. If you want to cite a work by Sting (musician), what is preventing you from putting "Sting" in |last= using VE? Our documentation says "For corporate authors or authors for whom only one name is listed by the source, use last or one of its aliases". – Jonesey95 (talk) 17:01, 11 August 2024 (UTC)

Nothing is preventing me, I'm an experienced editor who knows the suggested course of action to ignore the instruction saying "The surname of the author" and just put in what I want, and also knows if I do that to go into the wikitext to fix the mislabeling of "Sting" as a last name. Relatedly the documentation should be changed, "whom only one name" is a small subset of affected names. CMD (talk) 17:11, 11 August 2024 (UTC)

Maybe I misunderstood the meaning of the word "unable" in the OP: Editors who use the manual citation generator in the Visual Editor see an interface in which they are unable to enter any author names that do not conform to the Lastname-Firstname naming system. The documentation is not protected. That includes the TemplateData portion of the documentation, which is what provides guidance to editors who use VE. – Jonesey95 (talk) 17:52, 11 August 2024 (UTC)

You seem to have, as you copied through the fuller text however editors are unable to do so by following the instructions in the interface' your suggested solution is to ignore the interface. The documentation is not provided as guidance to editors that use VE, editors are provided only with the text that Novem has provided a screenshot of above. CMD (talk) 17:59, 11 August 2024 (UTC)

WP:SOFIXIT? If editors can't or won't read template documentation, I don't know what to tell them. If VE needs its own documentation, it is up to people who care about VE to make it work. – Jonesey95 (talk) 20:30, 12 August 2024 (UTC)

That is what I am doing, I am here to fix it. That is why I have opened this discussion, it is intended to find ways to fix it. CMD (talk) 03:42, 13 August 2024 (UTC)

We came here to check consensus and I do not see sny objections, so let's just go ahead and edit the TemplateData and call it a day. We should make a list of every template that starts with cite, then edit the corresponding /doc pages (this is where TemplateData is stored) and add something like author, author2, ..., author10. CMD, want to take a stab at it? –Novem Linguae (talk) 12:15, 13 August 2024 (UTC)

|author= already exists in the TemplateData. I think what you want to do is click "Edit template data" and then change the description for that parameter, currently The surname of the author; don't wikilink, use 'author-link'; can suffix with a numeral to add additional authors, to something that matches the actual documentation, possibly "The surname of the author, name of the corporate author, or author for whom only one name is listed by the source; do not wikilink ...". – Jonesey95 (talk) 13:48, 13 August 2024 (UTC)

Ummm, are you sure? If you look at the JSON formatted TemplateData for {{cite web}}, you will find only two instances of "author" (with quotes): the |last= definition as an alias (see my post above) and at "maps": → "citoid": → "author": (as I understand it this latter applies only to automated, citoid-created, templates).

If someone adds |authorn= as a separate parameter, I fear that we will see an increase in the number of articles that populate Category:CS1 errors: redundant parameter because OMG!-there's-an-empty-box-in-the-form;-I-must-fill-it. This is why I suggested radio buttons for aliases; something that MediaWiki would needs implement. Not that it will do much good, but anyone adding |authorn= as a separate parameter to TemplateData should carefully consider the description wording to emphasize the only-one-of-authorn-or-lastn-is-allowed property of name-list parameters.

—Trappist the monk (talk) 14:25, 13 August 2024 (UTC)

My impression from the OP's description of what they see when using VE is that changing the "Description" for |last= in the Template Data will resolve their issue. – Jonesey95 (talk) 15:02, 13 August 2024 (UTC)

Asking new editors to translate "last" as not meaning "last" is not an optimal solution, as it suggests to new editors that the instructions/labels we have are poorly written, and it will populate templates with a |last field that does not contain a last name. The OMG-empty-box-fill is a complicating issue as well. I wonder how often both fields are filled with the wikitext citation tool. CMD (talk) 15:41, 13 August 2024 (UTC)

Are new editors likely to be using the manual citation generator in the Visual Editor? From your OP, I understood you to be describing experienced editors. Hard (impossible) to know how often both fields are filled with the wikitext citation tool. Category:CS1 errors: redundant parameter is mostly empty which suggests that there is a cohort of gnome editors who keep it swept clean. I guess there is more of a sense of accomplishment when emptying nearly-empty error and maint cats – I wish they would turn their attention to some of the very-not-so-empty cats...

—Trappist the monk (talk) 16:04, 13 August 2024 (UTC)

Mayhaps we're both confused. OP's first sentence is: Editors who use the manual citation generator in the Visual Editor see an interface in which they are unable to enter any author names that do not conform to the Lastname-Firstname naming system. To me, that says that using ve to manually create citations does not allow editors to create citations that use |authorn=. Instead, editors must use |lastn= and, as a separate operation go into the wikitext to fix the mislabeling of "Sting" as a last name. From all of that, I understand OP to be saying that they want to have authorn appear in the list of available parameters when manually creating citations using ve. The 'MediaWiki approved™' solution is to add authorn definitions to TemplateData. I think that this is a copout and that MediaWiki should allow editors to select from the list of aliases that TemplateData already knows about.

—Trappist the monk (talk) 16:04, 13 August 2024 (UTC)

The general issue is present for all editors who use the VE citation tool, even experienced editors would be putting in incorrect markup if they used |last for a different name. However, the issue is obviously far more impactful for new editors, and VE is from various accounts much easier for them to use than wikitext markup. You seem to understand me accurately; I also felt the unwillingness to deal with this in VE itself was somewhat a copout and stated as much on the pump discussion. Nonetheless, I think it's an issue worth solving, and if there's another way to move it along (perhaps even just in the interim) it seems worth implementing. CMD (talk) 17:38, 13 August 2024 (UTC)

In Carl von Weinberg, citations #1 and #9 are the same, except for the |quote=. This is a common scenario, but inefficient. How would you do it, without changing the citation style of the article? -- GreenC 14:53, 16 August 2024 (UTC)

Depends. How important are the quotations to the article? At a glance, I would say not-so-important; the source is, after all, free to read and relatively short. I would delete and combine. Quotations require citations, citations do not require quotations.

—Trappist the monk (talk) 15:02, 16 August 2024 (UTC)

You could always have something like

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.^[1] Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.^[2]

Headbomb {t · c · p · b} 15:15, 16 August 2024 (UTC)

Perhaps something in the pipeline with meta:WMDE Technical Wishes/Sub-referencing. CMD (talk) 15:36, 16 August 2024 (UTC)

Good timing! "Our plan is to deploy the sub-referencing feature for wikitext and Visual Editor by the end of 2024." - This is great. Thanks for the link. -- GreenC 16:18, 16 August 2024 (UTC)

Once this becomes available, it will make |page= and |quote= somewhat tricky, it will be better to include that information as a sub-reference, so that other sub-references can be attached to the origin cite which is clean of specific page # or quote data. The diffusion of information will create problems with tools, since being able to parse page numbers becomes difficult, information is in multiple templates. Plus, the option for sub-references to be named, makes it more complex. Plus, the possibility of other arguments being sub-referenced, such as authors in a multi-author book. It goes on. I suspect this well-intentioned feature is going to cause a great deal of chaos. -- GreenC 16:36, 16 August 2024 (UTC)

Followed up here, though unclear who is reading the page. -- GreenC 16:49, 16 August 2024 (UTC)

Hello, could the "Cite uses generic title" message be extended to apply to titles beginning with "Error 404" or "ERROR 404".

Such as "Error 404".

Keith D (talk) 21:20, 17 August 2024 (UTC)

In an amusing coincidence, search is currently returning exactly 404 hits for insource:"error 404". —David Eppstein (talk) 21:22, 17 August 2024 (UTC)

This search finds about 85 articles.

Added.

—Trappist the monk (talk) 23:06, 17 August 2024 (UTC)

I propose to update cs1|2 module suite over the weekend 17–18 August 2024. Here are the changes:

Module:Citation/CS1:

• allow |agency= in {{cite magazine}}; discussion
• maintenance category when value assigned to |year= is more precise than a year; discussion

Module:Citation/CS1/Configuration:

• fix 'email' generic name pattern; discussion
• fix undeclared variable 'uncategorized_namespaces_t'; no discussion; this edit
• add free DOI registrants: 4230 (LIPIcs) and 12942 (Living Reviews)
• maintenance category when value assigned to |year= is more precise than a year;
• support free-to-read DOI on certain 10.registrant/incipit...; initial support for MNRAS, MNRAS Letters, Geophysical Journal International, RAS Techniques and Instruments; discussion
• test for 'bureau', 'company', 'correspondent', 'desk', 'group', 'limited', 'newsroom' generic names; discussion
• update WorldCat URL prefixes; discussion

Module:Citation/CS1/Whitelist

• remove support for |authors=; limit |people= to {{cite av media}}, {{cite episode}}, and {{cite serial}}; discussion

Module:Citation/CS1/Date validation

• maintenance category when value assigned to |year= is more precise than a year;

Module:Citation/CS1/Identifiers

• support free-to-read DOI on certain 10.registrant/incipit...; initial support for MNRAS, MNRAS Letters, Geophysical Journal International, RAS Techniques and Instruments;

—Trappist the monk (talk) 22:48, 9 August 2024 (UTC)

Also:

• support free-to-read DOI on certain 10.registrant/incipit...; additional support for Access Microbiology, Microbiology, Journal of General Microbiology, Microbial Genomics [10]
• support free-to-read DOI on certain 10.registrant/incipit...; additional support for Heliyon [11]
• support free-to-read DOI on certain 10.registrant/incipit...; additional support for Journal of the Endocrine Society, JCEM Case Reports [12]

Headbomb {t · c · p · b} 17:33, 13 August 2024 (UTC)

doi:10.1093/notesj/gji104 is found as a match for doi:10.1093/jgi... Headbomb {t · c · p · b} 14:45, 19 August 2024 (UTC)

Fixed in the sandbox I think:

{{cite book/new |title=Title |doi=10.1093/notesj/gji104}} → Title. doi:10.1093/notesj/gji104.

{{cite book/new |title=Title |doi=10.1093/gji104}} → Title. doi:10.1093/gji104.{{cite book}}: CS1 maint: unflagged free DOI (link)

—Trappist the monk (talk) 17:45, 19 August 2024 (UTC)

Could someone add a better definition for docket to Template:Cite report? At the moment it simply reads "docket number", but nowhere in the template documentation does it explain what a "docket" is – which is not particularly helpful for those unfamiliar with the word. –Noha307 (talk) 03:48, 19 August 2024 (UTC)

wikt:docket Probably the 4th definition. Izno (talk) 16:21, 20 August 2024 (UTC)

Wikipedia:Village_pump_(technical)#Coming_soon:_A_new_sub-referencing_feature_–_try_it!.

It will involving breaking CS1|2 citations apart, and spreading those pieces around into different parts of the article, as free-form untemplated text. It's integral to MediaWiki. There are no guidelines for usage, anything goes. -- GreenC 17:08, 19 August 2024 (UTC)

Are there any plans yet to build a {{subref}} (or whatever name) template that can accept the arguments that Module:Citation/CS1 and Module:Footnotes accept? Rjjⁱⁱⁱ (talk) 02:31, 20 August 2024 (UTC)

Should be. I got kick back, saying editors should have the "luxury" to do whatever they want, without constraint. That doesn't mean we can't make templates, but that also suggests there will be a small but vocal faction that will want complete personal freedom to add whatever thing they want in a sub-ref. I couldn't even get agreement we might need some sort of guideline on how to use sub refs. So, be prepared for this to become a massive headache. There's really nothing stopping anyone from creating sub refs for multiple authors, pages, quotes, URLs, archive URLs, DOIs and other identifiers, dates, ISBNs, works, in-source locations, access-date, and much more. Essentially, everything in a citation can be removed and replaced with a sub-ref. This will create red errors in citations, make parsing citations nearly impossible, fixing citations incredibly hard, link rot will go undetected and unfixed, none of the bots will work like Citation bot and Refill that so many depend on. The libraries like PyWikiBot won't work without a massive overhaul of core components and creation of new features and functions. -- GreenC 03:42, 20 August 2024 (UTC)

If you want to create guidelines and gain consensus for them, then start at WP:VPPOL, not here which is a less-watched, more technical page. I'm not unsympathetic to your view (I don't like LDR style referencing - implied in this development as the way to go, but perversely I do like {{sfn}}) but the discussion needs to go wider than the technical pages and technical-minded editors who haunt them.

It's an eternal problem with Wikipedia that technical changes happen in a vacuum and not in conjunction with changes with business practices. It's understandable when you consider that the way de-wp probably want to use a feature will be a different way to how the same feature will be used on en-wp, so I don't blame WMF for having a bit of a dump and run approach. We know the technical change is going to happen so let's have the associated en-wp business change discussion upfront but in the right place, which isn't here.

Like any change, there are always fears about what will ensue. All the things you list may happen but less Chicken Little and more "approach X is to be recommended because it prevents/reduces ABC happening" is, imo, a better starting place for discussion. The use of ibid has been discouraged for years but it still gets used, to no great detriment overall. We even have WP:CITEVAR as policy accepting variances in referencing styles, so yes there are almost inevitably going to be edits using sub-refs in ways that you and I will not like for one reason or another. They're not going to eliminated but get the MOS/policy position established which reduces the likelihood of them happening in the first place. Nthep (talk) 07:42, 20 August 2024 (UTC)

Very well said. There will likely be consensus for this feature generally, but if there is a guideline and what that guideline says, should be decided by the community. The community needs to understand the consequences of citations that are no longer supported by tools. It will become painfully apparent with time, but the sooner this is resolved the better. -- GreenC 17:06, 20 August 2024 (UTC)

If a wiki page cites, e.g., multiple stories in an anthology, multiple articles in an issue, multiple papers at a conference, then it would be normal for different subreferences to have different |auther= parameters. OTOH, I see no reason to not exclude, e.g., |isbn=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:52, 20 August 2024 (UTC)

Editors will be creative how they slice and dice citations. There will be a variety in one article, that exists nowhere else, or only a few articles. Many rare birds. Thus, automated tools loose the benefit of CS1|2, which is standardization. Our tools will simply cease to function (for those citations). So we gain things, and loose things. If folks are OK with the loss of Refill, Citation bot, InternetArchiveBot, GreenCbot, AWB, PyWikiBot, etc.. then they are also OK with link rot, usurped URLs, general maintenance of metadata, clearing tracking category errors, etc.. The expectation that tools will be able to adapt should not be assumed. Many rare birds, at high risk of extinction, another way of saying non-robust, error prone, weak ie. bad design. Wikipedia has a lot of bad design but this one of predictable and preventable, with the right guardrails. -- GreenC 16:32, 20 August 2024 (UTC)

There should be no issue with the main reference. I also don't see an issue with sub-references that use CS1 or CS2 template with |title=op cit. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:07, 20 August 2024 (UTC)

Specifying |title=op cit in a cs1|2 template inside of a <ref extends="...">{{cite whatever |title=op cit |...}}</ref> will cause the cs1|2 template to emit bogus title metadata: &rft.btitle=op+cit so anyone consuming article citations via reference management software won't be given the source's actual title in the scraped citation. Fortunately there are few cs1|2 templates that use |title=Op. cit.; see this search. Similarly, for |title=Ibid; this search.

Yeah, we could add a mechanism (parameter) that would tell a cs1|2 template to mute its metadata output, but that would needs be a manual operation because the cs1|2 template cannot know which <ref extends="...">...</ref> tags wrap it.

—Trappist the monk (talk) 17:48, 20 August 2024 (UTC)

I'm assuming that whoever uses <ref extends=main-reference>citation-template</ref> will use the proper parameters for the wrapped sub-reference, provide that template supports an appropriate parameter. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:23, 20 August 2024 (UTC)

@GreenC, make sure you don't WP:CANVASS when you decide not to invoke the names of your would-be opposition. You got kickback for good reason. Izno (talk) 16:22, 20 August 2024 (UTC)

This could be done by creating a variant of the citation templates that wrapped the citation in <ref name="CITEREFSmith2000">...</ref> instead of putting the ref in the <cite> tag. Then {{subref}} could be written to use that ref in a similar way to {{sfn}}. None of this seems to require anything more from the MediaWiki implementation. Kanguole 10:03, 20 August 2024 (UTC)

That is

{{ref cite book |first=E. |last=Miller |title=The Sun |location=New York |publisher=Academic Press |year=2005}}

(arbitrary template name) would expand as

<ref name="Miller2005">Miller, E. ''The Sun''. New York: Academic Press, 2005.</ref>

and {{subref|Miller|2005|p=23}} would expand as

<ref extends="Miller2005">Page 23.</ref>

and the existing sub-referencing implementation would do the rest. The only thing missing would be merging of duplicate pages, but there are hooks to enable that too. Kanguole 10:24, 20 August 2024 (UTC)

That is an interesting idea. It does lock this method further into source code editing. At the moment, the list-defined references (LDR) that this method relies on aren't fully implemented in the Visual Editor. The VE can't add, remove, or replace a list-defined reference. Hypothetically though, if the WMF can get LDR working in VE, then this could be much friendlier to new users than {{sfn}}. The template could be designed to plug into the sub-references like:

<ref extends="Miller2005">{{subref|p=23}}</ref>

Rjjⁱⁱⁱ (talk) 15:50, 20 August 2024 (UTC)

From Holographic algorithm:

^[1]

Same problem with {{cite conference}} in Tervamäki ATE-3 and Tervamäki JT-5. Changing |conference-url= to |url= solved the problem eg. Special:Diff/1241238099/1241238294. This could be a new problem, I've never seen it before, three articles showed up in Category:CS1 errors: archive-url. -- GreenC 03:27, 20 August 2024 (UTC)

The values assigned to |conference-url= and to |archive-url= are not links to the paper named in |title= and do not match the source linked by |doi=. |archive-url= and |access-date= do not apply to |conference-url= hence the error messages: |archive-url= requires |url= and |access-date= requires |url=. Both apply to |url= or in its absence to |chapter-url= (and aliases).

Were it me, I would rewrite:

{{cite conference |title=Holographic Algorithms |book-title=FOCS 2004: 45th Annual IEEE Symposium on Foundations of Computer Science |first=Leslie |last=Valiant |author-link=Leslie Valiant |date=17–19 October 2004 |conference=FOCS 2004 |publisher=IEEE Computer Society |pages=306–315 |isbn=0-7695-2228-9 |doi=10.1109/FOCS.2004.34 |conference-url=https://web.archive.org/web/20120313170241/http://www.cs.brown.edu/~aris/focs04/}}

Valiant, Leslie (17–19 October 2004). "Holographic Algorithms". FOCS 2004: 45th Annual IEEE Symposium on Foundations of Computer Science. FOCS 2004. IEEE Computer Society. pp. 306–315. doi:10.1109/FOCS.2004.34. ISBN 0-7695-2228-9.

This is not anything new. {{cite conference}} needs to be rewritten because editors routinely write poor proceedings citations (we are citing the proceedings, not the conference – if you want to cite the conference website, use {{cite web}}).

—Trappist the monk (talk) 14:37, 20 August 2024 (UTC)

OK. Thanks for your time explaining. I'll keep this in mind next time I clear the category, about 80% by bot the remaining 20% manually have unusual cases like this. -- GreenC 15:51, 20 August 2024 (UTC)