Help talk:Citation Style 1/Archive 89

Archive 85

←

Archive 87

Archive 88

Archive 89

Archive 90

Archive 91

→

Archive 95

Another generic author name

I've just cleaned up a few articles where the author field ended with "(View posts)" (sample diff) -- John of Reading (talk) 09:26, 13 July 2023 (UTC)

Translated Quote Parameter

Since there is a parameter for "translated title", and there is a parameter for "quote", I suggest a parameter for "translated quote". Currently I tend to write a translation of the quote in brackets after the quote, but this is probably not optimal, since the source itself is not the source of the translation (just as we usually cannot attribute a "translated title" to the source). Thiagovscoelho (talk) 12:26, 13 July 2023 (UTC)

If the quotation is important to the article, put it in the article body and cite it. Quotations require citations; citations do not require quotations. But, if you must: |trans-quote=.

—Trappist the monk (talk) 12:49, 13 July 2023 (UTC)

Oh, I didn't know we actually had this. I guess it was because it's not available from the visual editor 😅. Sometimes I used |quote= to give a fuller version of a quotation from the article itself, and sometimes it was to make clear how a source supported a claim, since it was a large webpage source and I can't give page numbers. Thiagovscoelho (talk) 13:30, 13 July 2023 (UTC)

Istro-Romanian-language sources

Hello. I frankly have no idea if this is the appropriate venue for this.

Istro-Romanian is one of the Balkan Romance languages. The others are Romanian, Aromanian and Megleno-Romanian. Adding a parameter |language=ro/rup/ruq in a citation template will produce (in Romanian/Aromanian/Megleno-Romanian), but |language=ruo does not produce (in Istro-Romanian). An example is reference 50 at Istro-Romanians. I fixed it manually with |version= but I don't see why Istro-Romanian should be excluded from Wikipedia's technical code, or whatever the root of this is. Note that there is already Template:Lang-ruo so it's not a problem of "ruo" or of the language not being integrated anywhere within Wikipedia's code.

Can this be fixed? Super Dromaeosaurus (talk) 20:17, 16 July 2023 (UTC)

Staff

Can "staff" be added to generic author names? There are 63 articles citing "Staff, Ars". 93.72.49.123 (talk) 06:39, 20 July 2023 (UTC)

in "cite magazine", how do I cite an issue name such as "Spring 2022"?

If I put this in the 'issue' field, it renders as "No. Spring 2022" which doesn't really seem correct. But it doesn't really seem like it should be in the date field like that either. –jacobolus (t) 15:49, 20 July 2023 (UTC)

Since you didn't say what magazine you are thinking of, I will suppose this is a typical magazine. Typically, "Spring 2022" would be the date of the issue and would be specified in the date parameter. The publisher may or may not specify an issue number, which for a quarterly magazine would probably be a number from 1 through 4. That may be specified with the issue parameter. Jc3s5h (talk) 16:00, 20 July 2023 (UTC)

I see from your edit history that the magazine in question seems to be Caltech Magazine. When accessing the issue online, there is an option to see the print version. In the online reproduction of the print version, on page 2, where the "masthead" is, it states "Spring 2023 Volume LXXXVI, Number 1". I would regard this as the official date, and the date at the top of the article as a garbage date. I would write a complaint letter to the magazine about providing a date other than the official date without explaining what it means. Jc3s5h (talk) 16:08, 20 July 2023 (UTC)

Great, thanks! –jacobolus (t) 16:09, 20 July 2023 (UTC)

Unix epoch

I'm wondering whether it would make sense to show an error when a date of 1 January 1970 (the Unix epoch) is supplied. Of course there would be false positives, but from a quick search most articles appear to be using this date in error. 93.72.49.123 (talk) 06:46, 20 July 2023 (UTC)

Perhaps it would be better to run the search for that date and recruit help to go check them all. –jacobolus (t) 15:50, 20 July 2023 (UTC)

Simple search results:

• 1 January 1970 – ~745
• January 1, 1970 – ~500
• 1970-01-01 – ~905

—Trappist the monk (talk) 17:13, 20 July 2023 (UTC)

Is there a project for correcting issues? It would seem like a good place to organise something like this. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:22, 20 July 2023 (UTC)

Judging from a spot check, Category:CS1 maint: date eauals unix epoch may be indicated. I'll hit up mw:Citoid and see if they'd be willing to throw out this date for web sources. Folly Mox (talk) 20:35, 20 July 2023 (UTC)

Warning when adding duplicate arguments?

I fix a lot of script-generated citations, and about once every twenty or thirty, I'll end up duplicating a parameter that was actually already included but I didn't notice, causing the page to be added to Category:Articles using duplicate arguments in template calls and creating additional work as other editors User:Davemck and User:Ira Leviton clean up after me.

Is there a way for this to generate a warning message / for me to enable display of a warning message that is already generated? I am sometimes able to notice the category being added to the page on preview, but this typically only displays if I'm editing the full page rather than just a section, which accounts for maybe 5% of my edits. Folly Mox (talk) 13:14, 21 July 2023 (UTC)

No. MediaWiki can and does detect duplicate parameters but Module:Citation/CS1 gets only one of them (the last):

{{cite book |title=Title1 |title=Title2}}

Title2.

I use the generic text editor. When I preview this section, I see a warning message that looks something like this:

Warning: Help talk:Citation Style 1 (edit) is calling Template:Cite book with more than one value for the "title" parameter. Only the last value provided will be used. (Help)

—Trappist the monk (talk) 13:34, 21 July 2023 (UTC)

Oh, I do remember seeing warnings of that genre, but only in desktop mode. They must be restricted to that interface. Folly Mox (talk) 13:54, 21 July 2023 (UTC)

Resolved

Access-date gives an error for the 90's

Is this the expected behavior? Rjjiii (talk) 00:43, 12 July 2023 (UTC)

Where do you see this failure? Show an example.

—Trappist the monk (talk) 00:50, 12 July 2023 (UTC)

I get {{cite web}}: Check date values in: |access-date= (help) for dates until the year 2001 in these examples:

• "ZDNet". Retrieved 4 July 1998. {{cite web}}: Check date values in: |access-date= (help)
• "ZDNet". Retrieved 4 July 1999. {{cite web}}: Check date values in: |access-date= (help)
• "ZDNet". Retrieved 4 July 2000. {{cite web}}: Check date values in: |access-date= (help)
• "ZDNet". Retrieved 4 July 2001.
• "ZDNet". Retrieved 4 July 2002.
• "ZDNet". Retrieved 4 July 2003.
• "ZDNet". Retrieved 4 July 2004.

I wasn't sure if the template just assumes an early access to be an error, Rjjiii (talk) 01:01, 12 July 2023 (UTC)

The first edit in Wikipedia's database was made on January 15, 2001. So, it is literally impossible for an access-date to be before that date. AManWithNoPlan (talk) 02:06, 12 July 2023 (UTC)

Oh, that makes sense. My thought was that material printed from the web had a date on the printout, but that's overly complicated. Thanks for the explanation, Rjjiii (talk) 02:42, 12 July 2023 (UTC)

I'm going to take the '[solved]' out of the title of this thread, because you would not believe how difficult it makes wikilinking to this discussion. The parser apparently just cannot handle it. FeRDNYC (talk) 12:07, 22 July 2023 (UTC)

Page numbers when citing journals

After adding references to Grand Sanhedrin, I noticed that Template:Cite journal creates somewhat obscure and (in my opinino) inaccessible output:

> Niles, H. (12 June 1830). "The Jews". Niles' Weekly Register. 38: 296.

The number 38 represents the "Volume" and "296" presentes the page number. In other citation templates, we state the page number after "pp.", such as when using Template:Cite book. I think applying this to journal citations would make it significantly easier for readers to find the facts in the source, and thus to help them read the surrounding information. This especially because the URLs tend to go to a place for the work as a whole, which places a heavy burden on understanding that 1) the page number is in fact given, and 2) which number is what.

Perhaps less importantly than the page numer is the volume. This because each volume tends to be its own work and thus its own ISBN and/or online entry page. This means the volume number isn't required for navigation within the work. Having said that, I wouldn't mind spelling that out as "Volume 38".

Would these changes be welcomed? What other ways might there be to address the usability issue? Or perhaps there exists documentation we expect people to find that explains this?

Krinkle (talk) 23:37, 12 July 2023 (UTC)

I think {{cite news}} or {{cite magazine}} is what you want for Niles' Weekly Register:

Niles, H. (12 June 1830). "The Jews". Niles' Weekly Register. Vol. 38. p. 296.

Niles, H. (12 June 1830). "The Jews". Niles' Weekly Register. Vol. 38. p. 296.

{{Cite journal}} is for academic journals. – Jonesey95 (talk) 23:49, 12 July 2023 (UTC)

I have to agree that the output of {{cite journal}} is obscure and for clarity needs to be changed, especially where there are a mixture of formats on a page. We should not expect readers to know a convention or have to guess what things mean. Keith D (talk) 11:47, 14 July 2023 (UTC)

It's only obscure if you've never encountered the notation before. It's an extremely common citation style. Headbomb {t · c · p · b} 13:08, 14 July 2023 (UTC)

I find the output intuitive enough, as well as pretty standard (APA, I think?). The bolded volume is clear and reduces clutter, plus basically every journal citation will link directly to the article in question. I wouldn't mind "p" or "pp" for the page numbers, but the template output should be legible to anyone who's ever read a footnote in a published academic work. Folly Mox (talk) 13:08, 14 July 2023 (UTC)

But the average reader in Wikipedia will not necessarily be too experienced in conventions in academia I believe. I think this is a great idea. Super Dromaeosaurus (talk) 20:24, 16 July 2023 (UTC)

Yeah, "this is how academic journals cite other academic journals" (or how they're cited in other works focused on academia, like research papers and science periodicals) shouldn't really matter all that much to Wikipedia, should it? It's odd that we'd cite (only) one particular class of references in "their native tongue", rather than citing them in ways that are more accessible to the target audience here. Which doesn't suddenly become academia simply because a journal was cited. FeRDNYC (talk) 11:29, 22 July 2023 (UTC)

It's how virtually all scholarship is cited in virtually all publications venues. Magazines, books, journals. This is what APA style and virtually all others mandate (some italicize the volume, most keep it plain). Headbomb {t · c · p · b} 13:30, 22 July 2023 (UTC)

I've been in favor of using the same style for journals as we do for magazines for quite some time. There are four points in favor of this.

1. Wikipedia is for a generalist audience, not just an academic one. Making academics read "Vol. 1 no. 2 p. 3" should not offend or confuse them, but making laypeople read "1 (2): 2" has a high likelihood for confusion.
2. Journals and magazines are both similar types of periodicals, yet one gets the terse in-source location format and the other does not.
3. The display of a volume number for a journal is also inconsistent with the format for the volume number in a book. Journals are the outlier here and should be adapted to conform to the rest.
4. Lastly, we already have guidance against abbreviating journal names, which is a standard practice in academic works, for accessibility to a general audience. Since Wikipedia is not distributed on paper, we don't need the space savings, however minimal that may be, of abbreviating the either the journal name or the volume/issue/page numbers. When the cost of saving space is comprehension, that savings should give way to comprehension.

For these reasons, I fully support the more verbose format from {{cite magazine}} over that of {{cite journal}}. If you need an external style guide for support, please see the Chicago Manual of Style, which has been used as an influence on CS1 in the past. Imzadi 1979 → 20:49, 22 July 2023 (UTC)

I like that journals and magazines format their volume numbers differently. It allows me to tell at a glance whether a source comes from a tradition of academic peer review or not. Also some magazines have a tendency to play fast and loose with their volume / issue numeration, whereas journals tend to have a set structure. It makes sense to differentiate them. And frankly if I were princess of citation template styles, I'd format book chapter numbers in bold right before the page numbers, similar to how journals are handled now.

I haven't seen anyone produce an argument where a reader – even never having encountered APA citation style before – could actually take the step of attempting to verify a citation (by clicking a link, copy-pasting into a search field, or whatever), and still come away from the process uncertain about how to locate the cited source. If people aren't bothering to check the source, and are just copypasting our sources into their own work, or whatever process includes seeing the citation written out but not actually looking at it, I don't feel we owe them hand-holding. Folly Mox (talk) 21:00, 22 July 2023 (UTC)

Cite tech report

With the move, the error messages and maint notices still point to cite techreport. Chandrasekhar Boyapati, William Beebee, Jr., Martin Rinard. A (Technical report).{{cite tech report}}: CS1 maint: multiple names: authors list (link) (Technical report). {{cite tech report}}: Missing or empty |title= (help) AManWithNoPlan (talk) 16:26, 25 July 2023 (UTC)

Fixed in the sandbox:

{{cite tech report/new | title=A |author1=Chandrasekhar Boyapati, William Beebee, Jr., Martin Rinard }}

Chandrasekhar Boyapati, William Beebee, Jr., Martin Rinard. A (Technical report).{{cite tech report}}: CS1 maint: multiple names: authors list (link)

{{cite tech report/new | title=}}

(Technical report). {{cite tech report}}: Missing or empty |title= (help)

—Trappist the monk (talk) 17:11, 25 July 2023 (UTC)

Trappist the monk, Can you also fix cite ssrn, vs the new cite SSRN also please. AManWithNoPlan (talk) 13:59, 26 July 2023 (UTC)

Done. Also {{Cite arXiv}}, {{Cite bioRxiv}}, {{Cite CiteSeerX}}, and {{Cite medRxiv}}.

—Trappist the monk (talk) 23:50, 26 July 2023 (UTC)

Translation link

For {{cite news}} or {{cite web}}, what parameter should be used to add a translation link to the original article (written in a foreign language) when both the URL and archive-URL have already been utilized? I don't see a translation-url or anything similar. Thank you.--TerryAlex (talk) 17:59, 25 July 2023 (UTC)

There is no |translation-url= parameter.

If you are citing the translation of something and not the original-language source, cite the translation and use |url= to link to it if it is available online. You might include |type=Translation. If you are citing the original-language source, cite that and use |url= to link to it if it is available online. In either case, you can always add an external wikilink to the 'other' (translated or original-language source) after the closing braces of the {{cite <whatever>}} template.

—Trappist the monk (talk) 18:14, 25 July 2023 (UTC)

Can you give me an example? For example, how to add a translation link to the following: {{cite news|url=www.abc.com/newsarticle.html|archive-url=web.archive.org/20230724091214/www.abc.com/newsarticle.html|title=News Article|work=ABC|date=March 23, 2021|archive-date=July 24, 2023|access-date=July 24, 2023|language=foreign|url-status=live}}. Thanks.--TerryAlex (talk) 20:32, 25 July 2023 (UTC)

I played around with the parameters and found that if I use the |at= parameter and format it like this {{cite news|url=https://www.abc.com/newsarticle.html|archive-url=https://web.archive.org/20230724091214/www.abc.com/newsarticle.html|title=News Article|work=ABC|date=March 23, 2021|archive-date=July 24, 2023|access-date=July 24, 2023|language=foreign|url-status=live|at=[https://web.archive.org/20230725112323/www.translation.com/translationpage.html English Translation]}} It yields no error and the citation shows up looking properly. Is this a good way to do it or does it violate the citation format in any ways? Thanks.--TerryAlex (talk) 00:05, 26 July 2023 (UTC)

No. Do not abuse parameters to do something for which they are not designed. Just because you don't get an error message does not mean that the use is acceptable. In your example, the wikilink assigned to |at= will corrupt the citation's metadata. What I meant in my first post was something like this:

<ref>{{cite news |url=https://www.abc.com/newsarticle.html |title=News Article |work=ABC |date=March 23, 2021 |access-date=July 24, 2023 |language=und}} [https://www.translation.com/translationpage.html English Translation]</ref>

—Trappist the monk (talk) 01:07, 26 July 2023 (UTC)

Got it. Thank you. I was initially confused and put the wikilink at the front and that syntax did not work.--TerryAlex (talk) 03:44, 26 July 2023 (UTC)

Use a single video source as a cite but multiple timestamps?

I want to reference a single video but different timestamps, ideally using SFN style where that uses page numbers, is there a way of doing this for time stamps? Darkwarriorblake (talk) 16:03, 26 July 2023 (UTC)

Not a cs1|2 question. Does {{sfn}} parameter |loc= not do what you want?

—Trappist the monk (talk) 16:24, 26 July 2023 (UTC)

Maybe, I will take a look, the talk pag for Cite AV Media just brought me here. Darkwarriorblake (talk) 16:30, 26 July 2023 (UTC)

How about this or this? – Jonesey95 (talk) 01:09, 27 July 2023 (UTC)

References

support trans-series

• {{cite book|last1=Hiriart-Urruty|first1=Jean-Baptiste|last2=Lemaréchal|first2=Claude|author-link2=Claude Lemaréchal|year=1993|chapter=XII Abstract duality for practitioners|title=Convex analysis and minimization algorithms, Volume II: Advanced theory and bundle methods|series=Grundlehren der Mathematischen Wissenschaften |trans-series=Fundamental Principles of Mathematical Sciences|volume=306|publisher=Springer-Verlag |location=Berlin |pages=136–193 (and bibliographical comments on pp. 334–335)|isbn=3-540-56852-2 |mr=1295240}}
• Hiriart-Urruty, Jean-Baptiste; Lemaréchal, Claude (1993). "XII Abstract duality for practitioners". Convex analysis and minimization algorithms, Volume II: Advanced theory and bundle methods. Grundlehren der Mathematischen Wissenschaften. Vol. 306. Berlin: Springer-Verlag. pp. 136–193 (and bibliographical comments on pp. 334–335). ISBN 3-540-56852-2. MR 1295240. {{cite book}}: Unknown parameter |trans-series= ignored (help)

Headbomb {t · c · p · b} 15:05, 2 July 2023 (UTC)

Any progress on this? Headbomb {t · c · p · b} 20:50, 1 August 2023 (UTC)

Rename category Category:CS1 maint: Zbl to Category:CS1 maint: Zbl format

For consistency with the other format categories (Bibcode, MR, PMC). Headbomb {t · c · p · b} 04:04, 7 July 2023 (UTC)

Category:CS1 maint: Bibcode format does not exist. Category:CS1 maint: MR format and Category:CS1 maint: PMC format exist to catch cases where editors write |mr=MR1234567 or |pmc=PMC12345 when they should have written |mr=1234567 or |pmc=12345. Category:CS1 maint: Zbl exists to catch cases where the specified identifier is temporary so that editors can come back later and provide the permanent identifier.

—Trappist the monk (talk) 12:17, 7 July 2023 (UTC)

Maybe it could be renamed Category:CS1 temporary Zbl label or some such, to be more clear about its non-label-format purpose? —David Eppstein (talk) 16:11, 7 July 2023 (UTC)

It's at Category:CS1 maint: bibcode, which should be shifted to Category:CS1 maint: bibcode format too. Unless we want both to be Category:CS1 maint: temporary bibcode and Category:CS1 maint: temporary Zbl. Headbomb {t · c · p · b} 17:14, 7 July 2023 (UTC)

Speaking of Category:CS1 maint: bibcode, I notice that maint_bibcode isn't defined in the Module:Citation/CS1/Configuration error_conditions table — that's why the category page is showing "Pages with this condition are automatically placed in unknown error_conditions key: maint_bibcode." instead of its own name. FeRDNYC (talk) 17:28, 13 July 2023 (UTC)

Yes, it's because the template hasn't been updated in eons. Headbomb {t · c · p · b} 20:08, 1 August 2023 (UTC)

Cite committee meeting and cite committee report

This morning, I tried repeatedly without success, first to archive on the WayBack Machine, then secondly to cite the two relevant webpages of the meeting on 19 July 2023 of the House of Commons Business and Trade Select Committee (1,2). The WayBack Machine failed to archive the two relevant Committee webpage. Using the easy citation tool in Wikipedias's Visual Editor, I was unable to cite either webpage of the Committee. Hence, I now need to cite the two webpages using the Wikipedia generic default of {WebCite}. I'm not sure what citation protocol best to follow. I've tried without success to look up the APA guidelines for citing committee meetings and committee reports. In my view, it would be helpful to have wikipedia citation templates specifically for citing committee meetings and citing committee reports.

[1] https://committees.parliament.uk/work/7774/food-and-fuel-price-inflation-will-prices-come-down-this-year

[2] https://committees.parliament.uk/event/19035/formal-meeting-oral-evidence-session/

Humanity Dick (talk) 11:59, 24 July 2023 (UTC)

Sorry, {Cite web} not {WebCite}

Humanity Dick (talk) 12:06, 24 July 2023 (UTC)

There are editors at en.wiki who think that there are too many cs1|2 templates...

Wayback machine and Visual Editor failings are not in the Citation Style 1 remit. I can't speak to Wayback machine but for VE, it seems likely that no one has written a Zotero translator for the UK Parliament committees' websites.

I will not use the visual editor so were I citing these two web pages, using the source editor I might write something like this:

{{cite web |author=((Business and Trade Committee)) |date=19 July 2023 |title=Food and fuel price inflation: will prices come down this year? |website=UK Parliament |url=https://committees.parliament.uk/work/7774/food-and-fuel-price-inflation-will-prices-come-down-this-year}}

Business and Trade Committee (19 July 2023). "Food and fuel price inflation: will prices come down this year?". UK Parliament.

{{cite web |author=((Business and Trade Committee)) |date=19 July 2023 |title=Food and fuel price inflation: will prices come down this year? - Oral evidence |website=UK Parliament |url=https://committees.parliament.uk/event/19035/formal-meeting-oral-evidence-session/}}

Business and Trade Committee (19 July 2023). "Food and fuel price inflation: will prices come down this year? - Oral evidence". UK Parliament.

—Trappist the monk (talk) 12:26, 24 July 2023 (UTC)

Thanks, Trappist. Very helpful. I'm surprised you won't use Visual Editor. When I used to edit Wikipedia anonymously, much of my time was taken up trying to add reputable sources to support uncited assertions made by other editors. Because I'm partially disabled, I can't use a PC for very long before my back and neck become too painful. Hence, these days I'm forced to do all the work I once used to do sitting at a PC lying on my back pecking away with my right forefinger on the touch screen of my 2017 iPad resting on my abdomen. Using {Web Cite} takes me forever, in part because I also have various cognitive and visual disabilities that mean I'm very inept at even the most basic stuff I need to input, frequently making frustrating mistakes and errors I then have to try to fix, often succeeding only after multiple attempts. I never seem to learn the basics, making the same mistakes again and again. Hence, for me, and I suspect for many other disabled or partly disabled contributors, the Visual Editor and the citation templates are the best thing that have ever happened on Wikipedia Humanity Dick (talk) 16:33, 1 August 2023 (UTC)

Humanity Dick: Re: archiving, the page has a lot of content buried behind links such as PDFs behind tabs. Archive.today works for single pages such as https://archive.ph/0Qv4n but would need to archive every sub-link individually. Another method is sign up for https://conifer.rhizome.org/ which allows one to interactively view links and it will record real time creating one giant archive. This is the best method for that kind of page. If you use Conifer and add it to Wikipedia, be sure to also include a {{cbignore}} otherwise IABot will remove it (c.f. T321146)-- GreenC 14:21, 24 July 2023 (UTC)

Thanks, GreenC. Also very helpful and useful. I'll have to read and reread your suggestions many times before, if ever, I'm able to understand your advice. I'm always the tortoise not the hare. I'll try to follow your suggestions and see how I get on. Humanity Dick (talk) 16:38, 1 August 2023 (UTC)

Wikipedia:Wikipedia Signpost/2023-08-01/Tips and tricks

This gives an overview of various citation tools out there. I figured many of you would get something out of this. Headbomb {t · c · p · b} 05:52, 1 August 2023 (UTC)

Page numbers

URLs get embedded in various places of the template which makes link rot repair difficult to manage for bots and scripts. Typically they are skipped. For example Help_talk:Citation_Style_1#Documentation_needed_for_linking_multiple_urls_within_the_'pages'_parameter shows the free-form nature of how we do it. Another way is more systematically like we do for |author= + |author-link= separating the metadata from the link.

It would be |page1= ("page=42") + |page1-url= with perhaps support for up to 5 or 10 pages. Note |page= would be an alias for |page1=.

For page ranges use |pages1=42-44 (display: "pages=42-44") + |pages1a-url= + |pages1b-url= where "a" is for 42 and "b" for 44. More page ranges can be added for example |pages2=47-50 (display: "pages=42-44, 47-50") + |pages2a-url= + |pages2b-url=. This way one can have a mix of single page and page ranges, all with their own URLs, contained in parameters. -- GreenC 16:03, 10 July 2023 (UTC)

Did this change at some point? I remember some time back that wikilinking pages was a no-no. That the url link should always supposed to be to the most specific part of the source. I looked but haven't found any restriction about it now but I seem to remember there was in the past. I kind of like this idea. Jason Quinn (talk) 04:57, 12 July 2023 (UTC)

@Jason Quinn: The "most specific part of the source" advice is more useful in dissuading editors from just linking to the title page of the work they're citing, rather than the chapter/heading/page where the cited information can be found. Citations that span multiple specific locations — like a page 4 newspaper article that's "continued on page 81" halfway through the sentence being cited, for example — are kind of their own deeper problem beyond that.

I'm not sure how I feel about links in the |page*= parameters, but I definitely recognize that there are times when only linking to a single location risks leaving the user fumbling around to figure out how they can reach the rest of the content being cited.

Though, now that I say this, a quick search reveals that there are a lot of citations with a specific, single link in |page=, alongside a more generic |url= linking to the source as a whole. ...I was also under the impression that was incorrect: the |url= parameter should simply hold the link from |page=, shouldn't it?

...Unless my own understanding of how these params are meant to be used is incorrect / outdated? FeRDNYC (talk) 07:45, 12 July 2023 (UTC)

The "quick search" times out due to the size but I was able to get as many as 37,000 with some refinements, though there are probably a lot more. -- GreenC 14:49, 13 July 2023 (UTC)

Yeah, sorry, that was a "quick search" as in "I spent about 12 seconds defining it"... its performance on the server being inversely proportional seems about right. FeRDNYC (talk) 17:02, 13 July 2023 (UTC)

33,000 for "pages" and 30,000 for "page" is 63,000 (depending on server load). Both time out, there are some false positives, and false negatives, in keeping the regex simple. Also weird more pages than page. It will require a different method of search. -- GreenC 18:30, 13 July 2023 (UTC)

It is often desirable for the link on the title of a book to go to the Wikipedia article on the book, using |title-link=. When that is done, and there is no named |contribution= within the book to cite, the only way to provide a convenience link for specific content within the book (and the way that has been repeatedly recommended) is to put the link into the page or pages parameter. —David Eppstein (talk) 20:26, 13 July 2023 (UTC)

Often |section-url= will do what you need. Normally I use both links unless the relevant text is on the first page of the section. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:17, 13 July 2023 (UTC)

Hmm, that's a fair point, I'd forgotten how |title-link= and |url= interact with each other. (Or more to the point, that they don't, and result in a CS1 error when used in the same citation.)

That seems like an even stronger argument for formalizing page links via some sort of |pageN-url= scheme like GreenC is proposing. FeRDNYC (talk) 02:45, 15 July 2023 (UTC)

On that topic, the examples in Template:Cite book/doc include at least one demonstrating "title with a piped wikilink":

Three authors, title with a piped wikilink, edition

Markup	{{cite book |last1=Bloggs |first1=Joe |author-link1=Joe Bloggs |last2=Smith |first2=John |last3=Smythe |first3=Jim |title=[[A Thousand Acres|1000 Acres]] |edition=2nd}}
Renders as	Bloggs, Joe; Smith, John; Smythe, Jim. 1000 Acres (2nd ed.).

Should that be changed to use |title-link= instead of piping? I'll be bold and fix it (plus any others), if we agree |title-link= is always preferable now. I feel like the documentation should demonstrate best current practices, not outdated ones. (And we wonder how editors pick up / retain bad habits?) FeRDNYC (talk) 05:06, 15 July 2023 (UTC)

The best way to establish best practices is by showing. People tend to copy-cat what they see in the real world. As such in this case, a WP:BOTREQ to convert linked |title= to |title-link= could go a long way. And/or, a feature request to Citation bot (if it doesn't already have). -- GreenC 01:33, 17 July 2023 (UTC)

While I don't disagree with any of that, it feels entirely tangential to my question about the documentation for {{Cite book}}. 😃 But I'll take it to imply that, indeed, |title-link= is always preferred, and update the docs. FeRDNYC (talk) 10:54, 22 July 2023 (UTC)

 Done I updated two examples, and also added notes to the parameter documentation to the effect that |title-link= and |url= should not be used together. FeRDNYC (talk) 11:11, 22 July 2023 (UTC)

@GreenC and FeRDNYC: A follow-on question of sorts: what about archived links for individual pages? I have been citing an old magazine article which is available online, but the hosting site could be gone tomorrow. When I link to individual pages of the article I have been linking directly to the archived url - or will we have |page1-url= and |page1-archive-url= and |page1-archive-date= fields for every individual page?  Mr.choppers | ✎  16:35, 2 August 2023 (UTC)

I would prefer directly linking the archive URL in page1-url -- GreenC 19:23, 2 August 2023 (UTC)

Proper fields for republished online news articles

I'm trying to {{Cite news}} an article that is republished from another work and the original work is attributed in the article. The original article is paywalled so I want to cite the freely available copy.

https://www.inforum.com/news/minnesota/minnesota-historical-society-nixes-renaming-historic-fort-snelling

Kelly Smith, Star Tribune staff writer. Republished same day with no changes to Inforum. Should I say via=Inforum? And for work say Star Tribune? Or work=Inforum and agency=Star Tribune? Pingnova (talk) 18:29, 2 August 2023 (UTC)

https://en.wiki.x.io/wiki/Module:Citation/CS1/Identifiers

'^[^1-5]%d%d%d%d$', -- 5 digits without subcode (0xxxx, 60000+); accepts: 10000–59999 needs to now be 1-6 instead of 1-5 since doi:10.60082/2817-5069.2017 exists. AManWithNoPlan (talk) 00:39, 27 July 2023 (UTC)

Fixed in the sandbox, I believe:

Cite journal comparison

Wikitext	{{cite journal|doi=10.60082/2817-5069.2017|journal=Journal|title=Title}}
Live	"Title". Journal. doi:10.60082/2817-5069.2017.
Sandbox	"Title". Journal. doi:10.60082/2817-5069.2017.

If I did it wrong, someone will correct it. – Jonesey95 (talk) 01:14, 27 July 2023 (UTC)

Template:Cite report

Shouldn't {{Cite report}} wrap the output of |title= in quotes? Its TemplateData says it should, at least. –MJL ‐Talk‐^☖ 17:32, 3 August 2023 (UTC)

History:

Help talk:Citation Style 1/Archive 6 § Should Template:Cite report be listed on this Help page?

Help talk:Citation Style 1/Archive 6 § Cite report

Template talk:Cite report/Archive 1 § Update to citation/core

Template talk:Citation/core/Archive 13 § Backwards specification and ownership behaviour over Template:Cite report

I wonder if we ought to revisit the no-markup 'decision'... Opinions?

—Trappist the monk (talk) 19:57, 3 August 2023 (UTC)

@Trappist the monk: I mean, I guess I should ask what {{cite report}} is primarily used for? I use it for things I would otherwise use {{cite journal}} for because there is nothing I could've put in the |journal= parameter. For example:

example

{{cite report |last1=Baumer |first1=Matt |last2=Kephart |first2=Curtis |title=Aggregate dynamics in a large virtual economy: Prices and real activity in Team Fortress 2 |id={{hdl|10419/125549}} |publisher=University of California, Economics Department |location=Santa Cruz |type=Working Paper |year=2015 |language=en}} to output: Baumer, Matt; Kephart, Curtis (2015). Aggregate dynamics in a large virtual economy: Prices and real activity in Team Fortress 2 (Working Paper). Santa Cruz: University of California, Economics Department. hdl:10419/125549.

As you can see, it's a working paper. It's not "published" in any true sense, but it does have a stable identifier and publisher. I could use {{cite web}}, but that would require me to remove the |id= parameter since it's more-or-less redundant.
If I'm using it wrong here, then I could see why original maintainers would've prefer to remove the markup. However, it doesn't make sense for the above use-case. –MJL ‐Talk‐^☖ 16:20, 4 August 2023 (UTC)

The upcoming {{cite document}} would suite that reference:

{{cite document/new |last1=Baumer |first1=Matt |last2=Kephart |first2=Curtis |title=Aggregate dynamics in a large virtual economy: Prices and real activity in Team Fortress 2 |id={{hdl|10419/125549}} |publisher=University of California, Economics Department |location=Santa Cruz |type=Working Paper |year=2015 |language=en}}

Baumer, Matt; Kephart, Curtis (2015). "Aggregate dynamics in a large virtual economy: Prices and real activity in Team Fortress 2" (Working Paper). Santa Cruz: University of California, Economics Department. hdl:10419/125549.

See the discussion about {{cite document}}.

—Trappist the monk (talk) 16:38, 4 August 2023 (UTC)

Don't use |id={{hdl|foobar}}. Use |hdl=foobar directly. Headbomb {t · c · p · b} 22:32, 5 August 2023 (UTC)

Numerology

One of the citations on this page shows an error message when the SSRN value that the citation bot added is correct and greater than 4500000. Achmad Rachmani (talk) 07:37, 7 August 2023 (UTC)

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

@Trappist the monk can you up the limit? Nobody (talk) 07:53, 7 August 2023 (UTC)

Should be line 2115 on Module:Citation/CS1/Configuration. Nobody (talk) 07:58, 7 August 2023 (UTC)

"Illustrator" parameter

Wikipedia articles on illustrated books -- especially children's books -- could really use an "illustrator" parameter, to go along with (for example) "editor." Jhlechner (talk) 15:52, 8 August 2023 (UTC)

You can use the |others= parameter for this, |others=Illustrated by John Smith for example. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:00, 8 August 2023 (UTC)

Another generic title

Hello, can you add "Facebook" as a generic title. Currently, 859 instances. Keith D (talk) 22:00, 9 August 2023 (UTC)

But work=Facebook with title=Something specific would probably be non-erroneous. —David Eppstein (talk) 00:06, 10 August 2023 (UTC)

I was looking at |title=Facebook. Keith D (talk) 12:02, 10 August 2023 (UTC)

Wizard needed: can a cite be generated from an ISBN?

I know that ReFill works such that <ref>https://example.com/whatever</ref> gets converted into a properly formatted cite template with the correct metadata. Does there exist anything that does this for ISBNs? I just noticed that I am probably wasting a lot of time typing in book citation information when there's already a gigantic unified metadata tracking system that is based on ISBNs. jp×g 23:40, 11 August 2023 (UTC)

@JPxG: Yes

1. Make a citation with {{cite book}} and fill out the ISBN parameter. You'll have something like this:
   . ISBN 978-0736426701. {{cite book}}: Missing or empty |title= (help)
2. Run Citation Bot on the page: https://citations.toolforge.org/
3. It will give you something like this when finished:
   Disney, R. H. (5 January 2010). Walt Disney's Alice in Wonderland (Disney Classic). National Geographic Books. ISBN 978-0736426701.

Rjjiii (talk) 06:09, 12 August 2023 (UTC)

@JPxG: WP:Wikipedia Signpost/2023-08-01/Tips and tricks#Citation Expander cough cough... Headbomb {t · c · p · b} 06:12, 12 August 2023 (UTC)

Cite Gaia EDR3

So, on TRAPPIST-1 we use the Template:Cite Gaia EDR3 (a wrapper for a {{cite journal}}) and we also need to add {{sfn whitelist}} because otherwise it throws sfn errors. Is there a way to fix the {{Cite Gaia EDR3}} template so that we don't need to hide bogus harv errors? Jo-Jo Eumerus (talk) 05:38, 12 August 2023 (UTC)

See Module:Footnotes/whitelist Headbomb {t · c · p · b} 06:10, 12 August 2023 (UTC)

You mean, just list the template on the whitelist? JoJo Eumerus mobile (main talk) 07:43, 12 August 2023 (UTC)

I've requested someone add the template to the whitelist here Module talk:Footnotes#Cite Gaia EDR3. Once someone adds it you won't need {{sfn whitelist}} anymore. I can't guarantee how long that will take though. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:16, 12 August 2023 (UTC)

JoJo Eumerus mobile The "Cite Gaia EDR3" template has been whitelisted for "Brown 2021". You can remove the "sfn whitelist" template from TRAPPIST-1. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:42, 12 August 2023 (UTC)

Can archive links, especially for still-living pages, be made more compact?

The current "Archived from the original on YYYY-MM-DD" phrasing at the end of many citations takes a pretty significant amount of space, especially since we now have bots indiscriminately adding these pre-emptive archive links to every citation. Is there any way we could cut that down to just "Archived YYYY-MM-DD" or the like? (If it were up to me we would entirely leave off archive links for still-living pages, as these typically have no direct benefit to readers.) –jacobolus (t) 17:57, 31 July 2023 (UTC)

I'd support removing from the original where url-status=live (where else would it be archived from?). I'd also support suppressing display of / bot removal of |access-date= where an |archive-date= is present and url-status=dead, since if the link is dead and there's an archive, there's no point. Ditto for |access-date= for all {{cite book}} and {{cite journal}}, since if they've gone to print there won't be an update to the information. Folly Mox (talk) 20:03, 31 July 2023 (UTC)

Sometimes the archive added is no good, the access-date can come in useful to finding a valid link. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:04, 31 July 2023 (UTC)

Exactly, humans should remove the access-date - if the archive is good - but no bot should do such things. AManWithNoPlan (talk) 21:58, 31 July 2023 (UTC)

Fair points, both, although I've never encountered a no good archive that wasn't either a. totally unsalvageable or b. rescuable with the earliest archive available. But now that I'm considering it, mass removal of |access-date= parameters by bot seems disruptive and annoying. Probably easier just to suppress display in cases where it's of no use to readers, only editors tryna repair an archive. Folly Mox (talk) 08:46, 1 August 2023 (UTC)

Earliest archive available is usually a decent choice, though sometimes personal web pages (as compared to e.g. newspapers) had meaningful later updates, with authors starting them as drafts or treating them as living documents. –jacobolus (t) 15:59, 1 August 2023 (UTC)

I like the idea of suppressing display of access-date if an archive URL exists. -- GreenC 16:02, 1 August 2023 (UTC)

I don't like the idea of suppressing the access date because not all webpages are static documents. Even in the case of an archive, I'd like to know when that page was accessed. Imzadi 1979 → 18:43, 1 August 2023 (UTC)

User:Imzadi1979, if you're that interested in finding out the relative values of whenever the editor who used the page to add sourced content versus whenever the page was archived, you could always drop into editing mode and have a look. Meanwhile for every use case outside that it would save close to a full line of vertical cruft on mobile, for everyone else who only cares about when the page was archived (if that). Folly Mox (talk) 19:11, 1 August 2023 (UTC)

If it takes up too much space for you, maybe the solution is to wrap that information in a class so you can suppress it through your personal CSS. I shouldn't have to drop into editing mode while reading an article. Imzadi 1979 → 19:49, 1 August 2023 (UTC)

Already available: see Help:Citation Style 1/accessdate. I presume that it works. The html rendering of |access-date= looks like this:

<span class="reference-accessdate">. Retrieved <span class="nowrap">2023-08-01</span></span>

—Trappist the monk (talk) 19:56, 1 August 2023 (UTC)

@Imzadi1979: not all webpages are static documents. Even in the case of an archive, I'd like to know when that page was accessed. But, archives are static documents — even if the page changes over time, the archive won't. It's a snapshot of a particular moment, and the date of that snapshot "trumps" the access date... no matter when the archive was accessed, the version they got is the one archived on the date indicated. An |archive-date= (and |url-status=dead) makes the access date completely irrelevant. FeRDNYC (talk) 02:01, 16 August 2023 (UTC)

@FeRDNYC: you're assuming the archive was consulted for the citation. It may be added after the fact and wasn't what was actually consulted by the editor adding the citation. The archive may be added long after the citation, so the original access date is not redundant, especially when it doesn't match the access date. If I have a webpage consulted on January 1, but not archived until January 8, the original webpage may have changed in the interim between citation and archiving. When they don't match, especially when that archive link was added much later, the original access date is not irrelevant. Imzadi 1979 → 03:21, 16 August 2023 (UTC)

I like the 'suppress one of the dates' idea too. Thumbs up. –jacobolus (t) 16:00, 1 August 2023 (UTC)

I'm against. If you checked the page on January 23, and the bot archived on February 28, there could be a lot of differences between the two. The only time I'd be in favour would be if both dates are the same, and the message could then be shortened to "retrived and archived on DATE" Headbomb {t · c · p · b} 20:56, 1 August 2023 (UTC)

This, exactly this. Even with the same date, there could be updates, but that would be rare. Imzadi 1979 → 21:26, 1 August 2023 (UTC)

It's a possibility, but 99.9& of readers would benefit if the access-date was suppressed by default when an archive date is present. It's only those of us who are trying to check and double check references who benefit from this, and we will likely be looking at the code in any case. Personally, I think that we (not bots) ought to remove |access-date= if the archived page has been checked and the content matches.  Mr.choppers | ✎  16:17, 2 August 2023 (UTC)

I agree, most users doing verification who need the access-date know it exists in the code and where to find it, for the vast majority it clutters and complicates the already heavily dense reference section. Even if we suppress, there is a possibility of making it appear by default, using the same method above that makes it disappear by default. -- GreenC 16:02, 5 August 2023 (UTC)

Yeah, I understand the use case for hanging onto the access-date for dead links with working archives. In fact I had to use that bit of information just yesterday to verify a claim where the archive predated the access-date for some reason. But that is a vanishingly scant proportion of how citations are used. I might need that information once in a thousand edits, and if I'm doing the verification work I'm already in the source. Meanwhile everyone who reads the article, including the vast majority who do not have accounts and therefore the option to suppress the display with custom css, are stuck skimming through a bunch of extra details they'll never need or care about. Folly Mox (talk) 07:54, 7 August 2023 (UTC)

...Won't archives often predate the access? The only time I'd expect it not to is when it's added after-the-fact. (And actually, even then it's probably better to find a snapshot that's as close to the |access-date= as possible, ideally.) But if someone submits an |archive-url= with a citation (I try to do so, if I think it's likely to vanish at some point), I'd certainly expect it not to be an archive created after that point! FeRDNYC (talk) 02:07, 16 August 2023 (UTC)

That's a good point. A fair proportion of editors are not as thoughtful, and do not provide archives at the time of edit. I think I would characterise the frequency of archives being added only after the original link is dead as "pretty frequent". In the case I alluded to above, the archive predated the access by sufficient time that the claim citing it was not true as of the archive date, so I fetched a more recent one. Folly Mox (talk) 02:40, 16 August 2023 (UTC)

not as thoughtful, and do not provide archives at the time of edit – personally I submit pages to be saved by the internet archive but then intentionally ("thoughtfully") do not include the archive link on the page (or sometimes even remove archive links that were added by the IA bot), because to me the proliferation of archive links for still living pages seems like a space-wasting spammy distraction. –jacobolus (t) 05:01, 16 August 2023 (UTC)

Thank you; that is indeed also thoughtful. I apologise for implying thoughtlessness from those who don't add archives to live links, which I know is a deeply contentious matter. I was trying to be kind, and ended up offensive. Really, today, I am the thoughtless one. The heat melted them all. Folly Mox (talk) 05:52, 16 August 2023 (UTC)

No worries, I wasn't offended, and didn't mean to sound testy. I just hope we can collectively consider the costs as well as benefits of displaying additional piece of metadata. :-) –jacobolus (t) 16:14, 16 August 2023 (UTC)

ISSNs in citations

https://en.wiki.x.io/wiki/Wikipedia:ISSN includes "An ISSN is particularly helpful in the following circumstances" which include "In a citation to an article that is not available online except behind a WP:PAYWALL" and "In a citation to an article that is not available online in full text". How are they helpful in those circumstances? When I've seen paywalled articles cited I've sought/created archived versions. Should I also add ISSNs? To date I've only noticed an ISSN of one Wall Street Journal article. Mcljlm (talk) 18:42, 12 August 2023 (UTC)

Well that was a load of nonsense. I've removed the dubious advice. ISSNs in citations are nearly worthless. There's some corner cases, like you're not sure of the full journal/periodical title, or that the title is ambiguous and could refer to several publications. But if you have URLs or identifiers like DOIs, then the ISSN adds nearly nothing. Most citation styles omits them entirely. Headbomb {t · c · p · b} 21:29, 12 August 2023 (UTC)

Glad to see we're on the same page, @Headbomb. Copying my original reply from the TH if it's useful for anyone:

Personally, my experience is that, because ISSNs are for publications rather than for individual articles, they're much less helpful than e.g. DOIs, and they're often overused because VisualEditor's citation tool seems to like them. Basically, all you really want to have is at least one identifier in each citation. That could be a URL, or a DOI, or an OCLC, or an ISSN, but just plain text is non-preferable. And all of this only matters if you're trying to get an article's references to a featured-quality level. Hope that helps! Cheers, {{u|Sdkb}} ^talk 18:12, 12 August 2023 (UTC)

If someone wants a project, investigating why the VisualEditor always tries to add ISSNs and getting it to...not do that...would have a huge impact on this issue. {{u|Sdkb}} ^talk 21:37, 12 August 2023 (UTC)

There have been attempts to get ve/citiod to omit WorldCat urls that duplicate OCLCs; that effort failed. I suspect that any attempt to get ve/citoid to omit ISSNs would be equally unproductive.

—Trappist the monk (talk) 21:41, 12 August 2023 (UTC)

Indeed the VE team has been spectacularly unconcerned with the concerns of the community on basic aspects of style and what's appropriate to include by default (ISSNs and Publishers being the particularly egregious items). 21:47, 12 August 2023 (UTC) Headbomb {t · c · p · b} 21:47, 12 August 2023 (UTC)

|language=en for citations on the English language Wikipedia is my favourite totally unnecessary automated reference add, which I'll usually delete when cleaning up other people's work to add page numbers etc.

From what I understand, the Foundation has a single contractor responsible for all of Citoid, who is currently tasked with integrating it into Wikidata for some reason instead of fixing any of its issues. Folly Mox (talk) 21:52, 12 August 2023 (UTC)

I know it seems dumb, but it's very helpful when translating articles between different language wikis. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 00:29, 13 August 2023 (UTC)

Yeah, I concur on that. {{u|Sdkb}} ^talk 00:39, 13 August 2023 (UTC)

Oh I don't disagree that the |language= parameter is very valuable, but it doesn't display anything when it matches the language of the project it's being used in. Aren't people checking the references whenever they translate articles? I'd think that they'd be able to fill out the language parameter manually during that process. It's hardly a blip of effort when the overall time investment of translation is taken into account. Folly Mox (talk) 02:22, 13 August 2023 (UTC)

Autotranslation, and if editors are checking crosswiki because of errors in a translation it's helpful. I'll say little on how much some editors check when translating, but I do have to go crosswiki to find missing bits of referencing quite often. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:11, 13 August 2023 (UTC)

User:Skdb, getting any of the automated reference tools to look at any part of their output at all aside from verifying it's returning a URL would be a huge step in the right direction. Folly Mox (talk) 21:55, 12 August 2023 (UTC)

It looks like VE is under the supervision of the editing team, so courtesy pinging @ESanders (WMF) and @PPelberg (WMF) — we remain open to working with you to improve citations in VisualEditor. Better automatic formatting of citations would improve both readers' and moderators' ability to verify references, in the latter case making it easier for them to approve/provide feedback on drafts. {{u|Sdkb}} ^talk 22:05, 12 August 2023 (UTC)

See also Wikipedia:WikiProject Citation cleanup/Repairing algorithmically generated citations for common issues, and mw:Talk:Citoid for recent suggestions and improvement requests. Folly Mox (talk) 02:30, 13 August 2023 (UTC)

Thanks everybody, especially Sdkb for suggesting I asked here. Until reading the responses above I assumed I was missing something significant about their use. Maybe I should delete the ISSN from the WSJ citation. Mcljlm (talk) 23:38, 12 August 2023 (UTC)

I remove ISSNs from globally known newspapers on sight, and haven't had any pushback. Same for |language=en, except for multi-lingual pages, e.g. |language=de,en,fr. -- Michael Bednarek (talk) 01:53, 13 August 2023 (UTC)

At first reading Michael Bednarek it appears to be obvious which newspapers are "globally known" but then I wondered if there's an objective list of those newspapers to which the term applies? Some published in specific countries are known to most people living in those countries but not necessarily abroad. I haven't heard about most of those listed in List of national newspapers - which omits newspapers I would have expected to be included. Mcljlm (talk) 03:48, 14 August 2023 (UTC)

Cite book template change?

Coincidentally, I had just yesterday gone through every entry on Bibliography of works on Davy Crockett to tidy up references, etc. Looked great yesterday. Imagine my surprise when I opened that list today and found red messages on numerous cite book entries such as "{{cite book}}: Cite has empty unknown parameter: |1= (help)" Etc. etc. It looked perfect yesterday. Whatever it is, also affected the drop-down cite book template - in that if you had an ISBN number, you would put it in the template and click on that little magnifying glass to the right of it, it would fill out the rest of the template. Now it just sits there and does nothing if you try that. So, I've been randomly going through other lists and it seems that only the cite book template triggers that. What happened between yesterday and today that affected the cite book template? — Maile (talk) 01:49, 13 August 2023 (UTC)

Oh, now I see Category:CS1 errors: empty unknown parameters, is a pretty good indication it isn't just me. — Maile (talk) 01:54, 13 August 2023 (UTC)

Me too, i'm seeing the same error as you! Roberth Martinez (talk) 03:37, 13 August 2023 (UTC)

Mark Robert Parris About 4 or 5 hours ago. Citation Bot added this wording to an existing source:

" {{cite book}}: Empty citation (help): |website= ignored (help)" "22:01, August 13, 2023‎ Citation bot talk contribs block‎ 3,818 bytes −24‎ Alter: template type, url. URLs might have been anonymized. Add: date, newspaper, authors 1-1. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Eastmain | #UCB_webform 25/30 " — Maile (talk) 03:14, 14 August 2023 (UTC)

The bot didn't add that source, it was already there. And the issue was that someone put nonsense in a website field. Headbomb {t · c · p · b} 04:36, 14 August 2023 (UTC)

Good information to have. Thanks. — Maile (talk) 12:18, 14 August 2023 (UTC)

Problem with {{SLS Q}}

I have encountered a problem in Elias Lönnrot: two references using {{SLS Q}} yield a maintenance error message: "location missing publisher" but the Wikidata items (Swedish Writings volume 1 (Q113396160) and Swedish Writings volume 2 (Q113396181)) have both publisher (P123) and place of publication (P291).-- Carnby (talk) 11:56, 13 August 2023 (UTC)

The template {{SLS Q}} has |publisher=unset, which is going to block an publisher setup on wikidata. I suggest asking the creator of the template about it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:17, 13 August 2023 (UTC)

Weird.-- Carnby (talk) 15:04, 13 August 2023 (UTC)

Category:CS1 errors: archive-url

Could we add Template: namespace? For example in European Union Referendum Act 2015 there is Template:UKEU2016Result which has the error. If it was in the tracking category my bot would find it automatically. As-is I have to manually track them down. In the first 200 articles of the category, randomly sorted, there were 3 articles with templates that required a fix (1.5%) -- GreenC 00:26, 14 August 2023 (UTC)

At the bottom of that template page is a link to Category:CS1 errors: archive-url. Categorization is not instantaneous. I did this simple search, did not find the template. I then refreshed the template and repeated the search and now the template is in the category.

—Trappist the monk (talk) 00:59, 14 August 2023 (UTC)

It is likely to take a few days to a month or more for all affected pages to be null-edited by the job queue. – Jonesey95 (talk) 02:20, 14 August 2023 (UTC)

Pages are now transcluding themselves

Something in the latest update is causing a page with a reference to transclude itself. This has the downside that templates that are otherwise unused, are now hidden from reports. Is this something that can be fixed? A setting that can be set to ignore on template pages? I remember a previous change a while back that also had this issue. Gonnym (talk) 09:23, 14 August 2023 (UTC)

I think that I have fixed this. I proved that to myself by adding a call to error() in the namespace test that calls title_object:getContent() (this is what counts as self transclusion). Previewing an article with the modified code showed an error for every cs1|2 template in the article (the expected result). I then previewed {{cite Grove}}; no errors so the module is not calling title_object:getContent() in template namespace. Still, as I write this, in Special:WhatLinksHere for {{cite Grove}}, the template appears to still be transcluding itself. Is there a WhatLinksHere lag as there is for categories?

—Trappist the monk (talk) 13:33, 14 August 2023 (UTC)

Yes, sometimes they need to be null edited to refresh transclusions, but in this case I think the /doc page is actually trasncluding the template in an example. I checked Template:Arrow (rail service)/detailed which was transcluding itself in the morning, and it doesn't anymore. Gonnym (talk) 13:41, 14 August 2023 (UTC)

Is year really discouraged

year: Year of source being referenced. The usage of this parameter is discouraged; use the more flexible |date= parameter instead unless both of the following conditions are met: Currently the Citation Bot adds years for journals, etc. Should we be using date? AManWithNoPlan (talk) 18:30, 1 August 2023 (UTC)

If it is true that journals are usually issued on monthly, quarterly, seasonal schedules, then |date= is most appropriate.

|year=2023 – ok because parameter name matches parameter value

|year=Winter 2023 – not ok because semantic conflict

|date=2023 – ok because parameter name matches parameter value

|date=Winter 2023 – ok because parameter name matches parameter value

We have disposed of |day= and |month= but so long as MOS:DATES allows YYYY-MM-DD format publication dates, |year= will be required when CITEREF disambiguation is needed (|date=2023-08-01 |year=2023a...)

If Citation Bot does not do CITEREF disambiguation then, for ease of coding, it should probably just use |date=.

—Trappist the monk (talk) 18:49, 1 August 2023 (UTC)

When it's a year, use |year=. When it's a full date/date with month, use |date=. Headbomb {t · c · p · b} 20:49, 1 August 2023 (UTC)

Why not just use |date= for either case? I see no benefit in having two types of fields for this information.  Mr.choppers | ✎  16:09, 2 August 2023 (UTC)

The specific situation where just date wouldn't get the job done in Citation Style 1 is when two sources by the same author, published in the same year, are cited. Lets say one is an article in IEEE Spectrum in the June 2022 issue, and one is an article in Games: Research and Practice, also in June 2022. Since all the identifiers normally used to link from the little number in the text to the endnote are the same, the citation system can't tell them apart. This is solved by putting "year = 2022a" in one citation, and "year = 2022b" in the other. Due to the design of the citation system, even when the dates are not identical, the system can't tell them apart if the year is the same. So articles published by the same author in June 2022 and September 2022 would need the year parameter with "2022a" and "2022b". Jc3s5h (talk) 16:26, 2 August 2023 (UTC)

Thanks Jc3s5h - I just entered 1979a and 1979b in date parameters a few hours ago; I had better go fix that I suppose.  Mr.choppers | ✎  16:37, 2 August 2023 (UTC)

Fixing that is not required and, if I had my druthers, they would not be fixed. Hiding the CITEREF disambiguators may make it more difficult for readers to determine which of your 1979 sources is being cited. For example, someone reading a printed copy of an en.wiki article will not be able to mouse-over the short form citation to see which one gets highlighted. The only case where |year= is required is the one I described above. Don't hide the CITEREF disambiguators.

Because the redundant |year= parameter is not necessary, when |date=1979 and |year=1979a appear in the same cs1|2 template, Module:Citation/CS1 emits a maintenance message and adds the article to Category:CS1 maint: date and year.

—Trappist the monk (talk) 17:11, 2 August 2023 (UTC)

When I've had to cite multiple works by the same author in the same year, I keep |date= as just the year, but set |ref= to use 2007a, 2007b etc. Is this recommended practice? Folly Mox (talk) 19:50, 2 August 2023 (UTC)

That is confusing the reader. Common practice is to append the distinguishing letter visibly to the year: Doe, Joe (1973a). A Title.; Doe, Joe (1973b). A Different Title.. -- Michael Bednarek (talk) 01:26, 3 August 2023 (UTC)

Yes, I concur; distinguishing letters directly appended to the year, and use |date=, because it saves you the two seconds pondering which one you ought to be using. Mathglot (talk) 06:48, 3 August 2023 (UTC)

Ok I've changed the full citation templates to use the a/b formatting consistent with the {{sfnp}}s on the articles I can remember. I think I assumed the citation templates would throw an error if the |date= fields weren't exactly dates; glad to know that isn't the case. Folly Mox (talk) 13:31, 3 August 2023 (UTC)

@Mr.choppers: Those diffs look good. I think it's only required for this kind of special case: Help:Shortened footnotes#Date Rjjiii (talk) 05:17, 3 August 2023 (UTC)

Those diffs look good. I disagree. At §Notes there are three Francillon 1979 short-form references. In §Bibliography there is no Francillon 1979 and one each of Francillon 1979a and Francillon 1979b. Which of the three Francillon 1979 short-form references goes to Francillon 1979a and which goes to Francillon 1979b?

—Trappist the monk (talk) 11:58, 3 August 2023 (UTC)

Thank you Rjjiii and Trappist the monk: Those short-form references were added long ago by someone else who didn't clarify which work they were referring to, which is why I was changing the bibliography in the first place. I intend to investigate the page history to determine what's what; if that doesn't work I'll have an excuse to buy one of those books.  Mr.choppers | ✎  13:34, 3 August 2023 (UTC)

To address this specific point, almost certainly all three point to 1979a (as the cites have page numbers in the 400s and 1979b isn't that long).Nigel Ish (talk) 15:26, 17 August 2023 (UTC)

Are "Please check ISBN" and "Articles with invalid ISBNs" obsolete?

Am I right in thinking that {{Please check ISBN}} and Category:Articles with invalid ISBNs are obsolete? (The former places articles in the latter.)

There are currently only 10 pages in that category, and all but one of them are also in Category:CS1 maint: ignored ISBN errors (which itself contains 382 pages). In the only one that isn't, Rodney Hallworth, the template marks the text "ISBN B001ALS2EY" in a hand-written book reference. The last non-minor edit on the category's talk page is from 2015; the last and only edits on the template's talk page are from 2012.

So it looks as if these have fallen out of use and been replaced by Category:CS1 maint: ignored ISBN errors and Category:Pages with ISBN errors (perhaps due to the switch from magic links for ISBNs to {{ISBN}} and isbn= parameters), and the template is only being used sporadically. Of the 10 current cases, 9 were already being tracked elsewhere, and the remaining exceptional one could have been handled by adding the ISBN template (which should be done anyway) and then the invalid ISBN would have shown up in Category:Pages with ISBN errors.

So it seems that this template and category should be decommissioned? Or am I overlooking a reason for keeping them? Joriki (talk) 20:32, 17 August 2023 (UTC)

No current opinion about the category or template; they do not fall within the cs1|2 bailiwick. That ISBN B001ALS2EY is really an ASIN so should read: 'ASIN B001ALS2EY'.

—Trappist the monk (talk) 20:52, 17 August 2023 (UTC)

I think {{Please check ISBN}} is still a valid template, and is not replaced by Category:CS1 maint: ignored ISBN errors or Category:Pages with ISBN errors, because it has a different meaning. If {{Please check ISBN}} places things in Category:Articles with invalid ISBNs as you say (looks like it does), then that category seems poorly named. Maybe that category used to list some other things that have now automatically moved to the other two categories? The template seems to mean an editor thinks there is a problem with how the ISBN is presented but cannot verify the correct form and wants someone else to check. I'd expect:

• Most things in Category:CS1 maint: ignored ISBN errors to be correct as marked up, added automatically to the page, but possibly contain some ISBNs or markup that need changes.
• Basically all things on Category:Pages with ISBN errors need some fix, and be automatically added to the category.
• {{Please check ISBN}} to have its own maint category, but only for manually flagged ISBNs that need more attention. I can imagine cases where it could be used on valid, invalid, or invalid-as-printed ISBNs., i.e. totally independent of the other categories.

Sometimes it is easy to verify an invalid-as-printed ISBN and mark it up as such, or make a correction to a invalid ISBN, sometimes it's not. {{Please check ISBN}} is a indicator to the editor who added the ref, or is watching the article to maybe double-check and mark up the ISBN correctly. Good question though, apologies if it's not 100% cs1|2. Salpynx (talk) 22:07, 17 August 2023 (UTC)

I've just been through and check every ISBN where it was used and cleared them. The majority were invalid ISBNs but are the ISBNs supplied by the publisher, and had already had (()) and so appeared in Category:CS1 maint: ignored ISBN errors. This doesn't appear to be a valid use of the template. The rest were some other kind of code inappropriately added to the ISBN field, ASIN / UPC / etc. If this template has a valid function it would be useful if it displayed somekind of message in the article, as it is unless you happen to know that Category:Articles with invalid ISBNs exists they are not going to be checked.

There was one use of the template where the ISBN was a valid ISBN, so maybe the editor who added the template just wanted someone else to check. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:46, 17 August 2023 (UTC)

author-link

Just stumbled on a problem that you could consider tracking. Cite template having an |author-link= parameter but no |author= or equivalent parameter. Probably similar situation for |editor-link=. Keith D (talk) 10:36, 14 August 2023 (UTC)

User:Keith D in addition to the tracking cat, suggest notify WP:CITATIONBOT as a feature request. Presumably in most cases it could automatically create the author name from the author-link after first removing anything in parenthesis. -- GreenC 20:23, 18 August 2023 (UTC)

Breaking change in handling of language=Swiss German?

There are a handful of pages that weren't listed at Category:CS1 maint: unrecognized language yesterday (I know because I'd gone through all the pages) but are listed there now without having been edited: The Night Game, Satanic panic, List of songs recorded by Owl City (I already fixed the last one). What they have in common is that they specify "Swiss German" as a language, which is apparently no longer recognized. If this is replaced by gsw, it now displays as "Alemannic".

{{Citation Style documentation/language/doc}} says that the 3-character code gsw stands for "Swiss German". Category:CS1 maint: unrecognized language says that "For recognized ISO 639-2 languages with multiple official names, MediaWiki recognizes only one." The official names for gsw are "Swiss German", "Alemannic" and "Alsatian".

So it seems that there's been a breaking change where gsw is now being mapped to "Alemannic" instead of "Swiss German". I wonder how we should deal with this. "Swiss German" is more specific than "Alemannic", and also more understandable to non-linguists. Everyone in Germany knows what Swiss German is, but few people know what Alemannic is or that it contains Swiss German as a subset. So it doesn't make much sense to relabel these works as "Alemannic". But keeping "Swiss German" would leave these articles in the maintenance category indefinitely. (List of songs recorded by Owl City was fixable because the resource is actually in Swiss High German, which has its own code.)

So ideally I think this change should be reverted, but I have no idea where to request that. If it isn't, then {{Citation Style documentation/language/doc}} needs to be updated (and that may apply to other codes as well if this was part of a broader change). Joriki (talk) 22:11, 18 August 2023 (UTC)

Not the fault of cs1|2. Module:Citation/CS1 gets language names and tags from Mediawiki (the Scributo form of the {{#language}} magic word). Some languages and tags are overridden in cs1|2.

Yesterday was Thursday so there has likely been an update to MediaWiki's CLDR. It appears that the update changed the English-language value for gsw from 'Swiss German' to another English-language form 'Alemannic'.

cs1|2 overrides 'Alemannisch' to 'Swiss German':

{{cite book |title=Title |language=Alemannisch}} → Title (in Swiss German).

Because cs1|2 does not override gsw, this seems to confirm that, when given tag gsw, MediaWiki used to return the English-language form: 'Swiss German'. Because there is no override for gsw, cs1|2 also recognized 'Swiss German' as a known language.

Fixed in the sandbox.

Cite book comparison

Wikitext	{{cite book|language=gsw|title=Title}}
Live	Title (in Swiss German).
Sandbox	Title (in Swiss German).

Cite book comparison

Wikitext	{{cite book|language=Swiss German|title=Title}}
Live	Title (in Swiss German).
Sandbox	Title (in Swiss German).

Cite book comparison

Wikitext	{{cite book|language=alemannic|title=Title}}
Live	Title (in Swiss German).
Sandbox	Title (in Swiss German).

Cite book comparison

Wikitext	{{cite book|language=Alemannisch|title=Title}}
Live	Title (in Swiss German).
Sandbox	Title (in Swiss German).

—Trappist the monk (talk) 23:29, 18 August 2023 (UTC)

Thanks. With your pointer to MediaWiki's CLDR I found the change that caused this. It was committed to CLDR on August 10, and a new MediaWiki version containing that change was installed on en.wikipedia on 15 August. The commit message says:

Change name for gsw to Alemannic

ISO 639-3 [1] provides three names for gsw, "Alemannic", "Alsatian" and "Swiss German". CLDR uses "Swiss German" but "Alemannic" would be a better choice for the general name - it's not a country-specific name and it matches the names we use already (e.g. Alemannic Wikipedia).

[1] https://iso639-3.sil.org/code/gsw

So if I understand correctly, once your changes to Module:Citation/CS1/Configuration/sandbox are applied in Module:Citation/CS1/Configuration, "Swiss German" will again be displayed in all cases – that sounds like a good solution. Also, as per Template:Citation_Style_documentation/language, gsw would then be preferred over "Swiss German", right? Joriki (talk) 00:31, 19 August 2023 (UTC)

I'm concerned about undoing the change to the MediaWiki default. It is simply not correct to allocate the entire gsw code to Swiss German, as already justified in the commit notes. Both the Ethnologue and the Glottolog recognize that Allemanic is a parent of Swiss German, and renaming it to Swiss German excludes other Allemanic languages that do not have their own MediaWiki code, such as Swabian. Additionally, arguments like Everyone in Germany knows what Swiss German is are irrelevant; many Allemanic languages like Alsatian are not even spoken in Germany, so it doesn't really matter what everyone in Germany thinks.

It's a bummer that these languages can't all have their own codes, and breaking changes are bad, and I wish all of that could be fixed. But until then, erroneously re-naming an entire code is not the right solution. Regards, Orange Suede Sofa (talk) 01:20, 19 August 2023 (UTC)

I didn't mean to imply that it's decisive what people in Germany know or think – that was just what I happen to know most about. My impression is that, not just in Germany, Alemannic (in this broad sense in which it encompasses Swiss German and possibly even Swabian) is more of a technical linguistic term – a bit like most people who speak English don't think of themselves as speaking West Germanic. For instance, I get 123 Google hits for "I speak Swiss German" and 4 Google hits for "I speak Alemannic" (and of course 0 Google hits for "I speak an Alemannic language"). Your example of Swabian is actually a case in point – my mother happens to be Swabian, and it was news to her when I just told her that she speaks Alemannic :-). So mapping the code to "Alemannic" and labelling Swabian resources with it may be appropriate according to some linguistic taxonomies (though see Swabian_German#cite note-5), but it wouldn't make Swabian less excluded in the view of non-linguist Swabians.

I do see the point, though, that the situation is currently bad no matter what we do and it might be considered the lesser evil to at least have a linguistically coherent classification. From what you write it sounds like there are no imminent efforts to implement ISO 639-3 in MediaWiki? (At https://www.mediawiki.org/wiki/Manual:Language it sounds as if it were already implemented.) I'd appreciate a pointer to where I can read more about the plans on that. Joriki (talk) 08:45, 19 August 2023 (UTC)

Our article on Alemannic German lists these ISO 639-3 language tags in the infobox:

• {{#language:gct|en}} → gct – no support for the Colonia Tovar dialect
• {{#language:gsw|en}} → Alemannic
• {{#language:swg|en}} → swg – no support for Swabian German
• {{#language:wae|en}} → Walser

Language tags supported by the {{#language:}} magic word are supported by cs1|2. ISO 639-3 maps gsw to Alemannic, Alsatian, and Swiss German. ISO 639-2 maps the same languages in a different order: Swiss German, Alemannic, and Alsatian.

Our article for Swiss German has only gsw in the infobox. CLDR v37.0β maps gsw to Swiss German (English) and Schweizerdeutsch (native). The common language name for gsw among all three is Swiss German

If you don't want Swiss German, Alemannic, and Alsatian to use the same language tag, you should take that up with the ISO 639-2/-3 custodians. If you want Swabian (swg) to be supported by MediaWiki, take it to Phabricator.

—Trappist the monk (talk) 11:29, 19 August 2023 (UTC)

To reiterate what I said above, I'm aware that the infrastructure is less than ideal here; what I'm specifically discussing is the thing that we do have control over, which is how we should handle the new MediaWiki default. If I can't do that here, on the thread where the local change was suggested and implemented, where should I take it? Regardless, I'm not going to agitate further, I just wanted to register a counter-argument to the local change. Orange Suede Sofa (talk) 23:55, 19 August 2023 (UTC)

Yes, once the change is made, cs1|2 templates will recognize gsw as Swiss German and will recognize Swiss German as a known language name. Because MediaWiki uses CLDR for language name translations, it knows the local language names for its supported languages (mostly):

{{#language:gsw|es}} → alemán suizo

Similarly, cs1|2 has access to these non-English names because it knows the local language of the wiki on which it is running. Using |language=gsw in a cs1|2 template copied to es.wiki will produce the correct local-language rendering without the need for editor intervention.

—Trappist the monk (talk) 11:29, 19 August 2023 (UTC)

cite book ignores |work= parameter

I've noticed that {{cite book}} has started emitting an error message where it contains |work= instead of displaying the value held in |work=. Are these being tracked anywhere? Most of the |work= parameters can probably just be reparameterised as |series=, although I found a few that weren't so easy. Seems like there should be an easy way to find these citations so whatever is held in the |work= parameter can be caused to be displayed again instead of hidden away in the source. Folly Mox (talk) 17:24, 18 August 2023 (UTC)

Follow the help link:

Title. {{cite book}}: |work= ignored (help)

My experience is different. In every case that I have found where {{cite book}} ignores |work=, the fix has been:

|title= → |chapter= (or appropriate alias)

|work= → |title=

—Trappist the monk (talk) 17:35, 18 August 2023 (UTC)

Thanks; that's good to know. One I found was fixed with |title= → |volume=; |work= → |title=. Hopefully they're mostly easy swaps of one kind or another. Thanks again. Folly Mox (talk) 18:23, 18 August 2023 (UTC)

I have also encountered a few where |series= was the right change, but most need chapter/title conversion, per Trappist. – Jonesey95 (talk) 20:36, 18 August 2023 (UTC)

There appear to be an awful lot of these - over 46000 according to https://en.wiki.x.io/wiki/Category:CS1_errors:_periodical_ignored - as the process of hiding work sometimes causes important information to disappear (including title of book or journal in some cases) - possibly making the reference more difficult or even impossible to use, it may be worth considering revision of how it is presented so the references/cites are still usable, even if they do show an error.Nigel Ish (talk) 00:11, 20 August 2023 (UTC)

This is a regal pain in the butt. I don't understand why it is still listed within the article [[1]] and with no mention that 'work' is no longer recognised in the cite book template. Keith H99 (talk) 03:38, 20 August 2023 (UTC)

From that section: Not all of these parameters are supported by every CS1 template. |work= is not listed as a supported parameter in the documentation for {{Cite book}}. Yes, there are 46,000 pages to fix, but we have had much larger piles of pages to fix before, and happily, the fixes are typically pretty easy. As usual, the error messages are new, but the errors have been there for a long time. – Jonesey95 (talk) 05:05, 20 August 2023 (UTC)

New foreign language source category

I just added language=kk-cyrl (meaning "Kazakh (Cyrillic script)") to a citation in Sadyk Abdujabbarov. That automatically added the article to the non-existent Category:CS1 Kazakh (Cyrillic script)-language sources (kk-cyrl), which is explicitly showing up as a red-linked category in the article's category list. (Category:CS1 Kazakh-language sources (kk)‎ and Category:CS1 Kazakh (Kazakhstan)-language sources (kk-kz)‎ already exist.) (Interestingly, the new category's page says "Wikipedia does not have a category with this exact title" and yet also "This category contains only the following page".)

Am I right in thinking that I should now create Category:CS1 Kazakh (Cyrillic script)-language sources (kk-cyrl) with the content {{CS1 language sources}}? And is there anything else I need to do? Joriki (talk) 14:53, 20 August 2023 (UTC)

Just the category. Copying the content of Category:CS1 Kazakh-language sources (kk) to Category:CS1 Kazakh (Cyrillic script)-language sources (kk-cyrl) is probably simplest and sort of future-proofs the category.

—Trappist the monk (talk) 15:13, 20 August 2023 (UTC)

Thanks for the quick response. But it seems that Category:CS1 Kazakh-language sources (kk) (and many more of these categories) erroneously include {{CatAutoTOC}}, which is apparently already included in {{CS1 language sources}}, resulting in a duplicated table of contents. So I think I shouldn't include that, and in fact remove it from the categories that include it? Joriki (talk) 15:32, 20 August 2023 (UTC)

Hmm, that's a relatively recent addition to {{CS1 language sources/core}}. There are, according to this search about 80 categories that have an extraneous {{CatAutoTOC}} template. I'll hack an awb script to remove them.

—Trappist the monk (talk) 15:52, 20 August 2023 (UTC)

Done.

—Trappist the monk (talk) 16:01, 20 August 2023 (UTC)

module suite update 12–13 August 2023

I propose to update cs1|2 module suite over the weekend 12–13 August 2023. Here are the changes:

Module:Citation/CS1

• detect |archive-date= / |archive-url= timestamp mismatch; discussion
• cleanup archive error messaging; discussion
• maintenance category for book and encyclopedia templates with publication dates from 1850+ that have |location= (or alias) but do not have |publisher=; discussion
• fix double-spaces associated with 'etal'; discussion
• ignore periodical title parameters in book and encyclopedia cites; discussion
• remove support for |lay-date=, |lay-format=, |lay-source=, |lay-url=; discussion
• add support for native {{cite document}}; discussion
• add support for |medrxiv= and {{cite medrxiv}}; discussion
• override MediaWiki definition for lang tag fkv; discussion
• don't feed invalid date info to metadata; discussion
• support page-wise configuration via {{cs1 config}}; discussion

Module:Citation/CS1/Configuration

• maintenance category for temporary bibcodes; discussion
• detect |archive-date= / |archive-url= timestamp mismatch;
• cleanup archive error messaging;
• i18n; autofill datenames['local digits']; discussion
• add mni script lang tag;
• maintenance category for book and encyclopedia templates with publication dates from 1850+ that have |location= (or alias) but do not have |publisher=;
• add support for |subject-first=, |subject-last=, and aliases and enumeration variants; discussion
• ignore periodical title parameters in book and encyclopedia cites;
• remove support for |lay-date=, |lay-format=, |lay-source=, |lay-url=, |transcripturl=;
• add support for native {{cite document}};
• add support for |medrxiv= and {{cite medrxiv}};
• override MediaWiki definition for lang tag fkv;
• add support for |title-note=; discussion
• fix error/maint template name annotation for {{cite tech report}}, {{cite arXiv}}, {{cite bioRxiv}}, {{cite CiteSeerX}}, and {{cite SSRN}}; discussion
• support page-wise configuration via {{cs1 config}};

Module:Citation/CS1/Whitelist

• add support for |subject-first=, |subject-last=, and aliases and enumeration variants;
• remove support for |lay-date=, |lay-format=, |lay-source=, |lay-url=, |transcripturl=;
• add support for native {{cite document}};
• add support for |medrxiv= and {{cite medrxiv}};
• add support for |title-note=;

Module:Citation/CS1/Date validation

• break out of for-loop early when date has been formatted; discussion
• detect |archive-date= / |archive-url= timestamp mismatch;
• i18n tonumber() fix; discussion
• emit error when year less than 100; discussion
• fix Julian/Gregorian metadata format for dates in 1582; discussion

Module:Citation/CS1/Identifiers

• maintenance category for temporary bibcodes;
• enabled accept-as-written markup for |bibcode=; discussion
• add support for |medrxiv= and {{cite medrxiv}};
• change |class= arXiv linkto use https; discussion
• expand DOI registrant range; discussion

Module:Citation/CS1/COinS

• add support for |medrxiv= and {{cite medrxiv}};

—Trappist the monk (talk) 15:54, 5 August 2023 (UTC)

This discussion did not arrive at consensus; the associated changes should not be implemented. This is not really a discussion at all. Nikkimaria (talk) 18:30, 5 August 2023 (UTC)

Clearly we disagree.

—Trappist the monk (talk) 21:35, 5 August 2023 (UTC)

There's really not any legitimate way to interpret the former link as a consensus in favour of the change. On that basis I will need to oppose your proposal unless those components are removed. Nikkimaria (talk) 22:24, 5 August 2023 (UTC)

I don't have a strong opinion on this (or any of the changes, really), but a. I do foresee the unintended consequence of editors pushing locations into the publisher field like |publisher=London to stop the maintenance message from appearing (which citations generated automatically from sources hosted on Internet Archive already do), and b. after reading through the linked discussion, I'm understanding that |location= in {{cite conference}} is not supposed to hold the location of the conference, which is wild to me. What is it for then, and what parameter is supposed to hold the location of the conference? Folly Mox (talk) 02:38, 6 August 2023 (UTC)

|Location= is for the location of the publisher. Bibliographically speaking, nothing holds the location of the conference. The only place it appears is often in the title, e.g. Proceedings of the 12th Conference on Rat Extermination, Held in Phoenix, AZ, on December 6–9, 2009. Likewise, |date= isn't the date of the conference, but rather the date the proceedings were published. Headbomb {t · c · p · b} 02:46, 6 August 2023 (UTC)

Wow I guess I have a lot to learn about citing sources. Thanks for putting up with me, everybody. I don't think I've ever actually seen a published volume of conference proceedings: usually I just see papers hosted privately by individual academics that state they were "originally presented" at some conference somewhere, but what I'm learning is that in terms of publication information they're really similar to festschrifts. Folly Mox (talk) 03:37, 6 August 2023 (UTC)

Information about the conference (name, dates, host city) can go in |conference=. If using {{cite conference}}, it is best to provide the title of the conference proceedings in |book-title= so that that information makes it into the citation's metadata; |conference= is not part of the metadata.

—Trappist the monk (talk) 12:54, 6 August 2023 (UTC)

What will the effect of emit error when year less than 100 be on citations to ancient book sources that legitimately predate 100 CE? Folly Mox (talk) 19:59, 5 August 2023 (UTC)

None that isn't already present. Here is the live module rendering a publication date less than 100CE:

{{cite book |title=Title |date=98}}

Title. 98. {{cite book}}: Check date values in: |date= (help)

The fix catches three-digit years less than 100CE that have a leading 0. Here is the live module – no error message when there should be an error message:

{{cite book |title=Title |date=098}}

Title. 098. {{cite book}}: Check date values in: |date= (help)

whereas the sandbox has an error message:

{{cite book/new |title=Title |date=098}}

Title. 098. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 21:35, 5 August 2023 (UTC)

@Folly Mox: At some point, I tried do this:

* {{cite sign | title = Victory stele of Thutmose III | location = Sudan, Gebel Barkal | publisher =  Egyptian New Kingdom | date = 1440 BC | via = Boston Museum of Fine Arts | url = https://collections.mfa.org/objects/145121}}

Which gives this error message:

• Victory stele of Thutmose III. Sudan, Gebel Barkal: Egyptian New Kingdom. 1440 BC – via Boston Museum of Fine Arts. {{cite sign}}: Check date values in: |date= (help)

And when I looked into it, the explanation I found (although I forget where) is that it is really easy for an average editor to verify a citation to a museum exhibit, journal article, or modern book, so the citation should point to those. That to verify the actual artifact one would need a historian, so it's the historian (or other reliable source) that should be cited on Wikipedia. Rjjiii (talk) 01:43, 6 August 2023 (UTC)

Yeah my use case is typically citing premodern works that reached a stable transmitted form early, and have been published by a number of different modern publishers in different years over the past century or so, but I'm usually going off a digitised version and I'm usually not sure which modern publisher is responsible for the exact version that's been digitised, and since display of |orig-date= is suppressed when |date= is not provided, I usually just guess at the publisher and date so I can get the |orig-date = value to display. Folly Mox (talk) 02:16, 6 August 2023 (UTC)

Will the detection of archive-date archive-url timestamp mismatches generate a maintenance category? -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:52, 5 August 2023 (UTC)

All archive-date-archive-url-timestamp mismatches will be categorized in Category:CS1 errors: archive-url.

—Trappist the monk (talk) 21:35, 5 August 2023 (UTC)

Brilliant, thanks Trappist. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:12, 5 August 2023 (UTC)

Could Help talk:Citation Style 1#support trans-series be rolled into this? This is very uncontroversial, and should be straightforward to implement. Headbomb {t · c · p · b} 22:23, 5 August 2023 (UTC)

The purpose of this announcement is to provide a last-chance opportunity for us to find and fix things that need fixing before the update. Adding new stuff no matter how straightforward to implement doesn't fit with that philosophy. |series= is one of those parameters that has different meaning for different templates; particularly {{cite episode}} and {{cite serial}}.

—Trappist the monk (talk) 12:54, 6 August 2023 (UTC)

If it can be done, then it should be done. There's no reason to wait another 8 months for this fix. Headbomb {t · c · p · b} 20:58, 6 August 2023 (UTC)

New help text and categories are in need of proofreading / copy editing. Ignore the unknown error_conditions key: <message>; the code that issues that message reads Module:Citation/CS1/Configuration which won't have the error_conditions key until it is updated from the sandbox. <message> should obviously match the topic. The new maintenance categories are:

• Category:CS1 maint: location missing publisher
• Category:CS1 maint: overridden setting

new error message help text:

• Help:CS1_errors#archive_date_url_ts_mismatch
• Help:CS1_errors#archive_date_missing_url
• Help:CS1_errors#periodical_ignored
• Help:CS1_errors#bad_medrxiv
• Help:CS1_errors#medrxiv_missing

—Trappist the monk (talk) 14:30, 8 August 2023 (UTC)

@Trappist the monk: Hey I see you have Template:Cite document up and running. I am doing some cleanup with Wikipedia:AutoWikiBrowser and I noticed that among it's automated template cleanup renaming it still wants to make {{cite document}} into {{cite journal}}. I am not sure of the appropriate way to fix that. Rjjiii (talk) 03:56, 14 August 2023 (UTC)

Okay, I tracked down the page only to find that Jonesey95 fixed this moments ago. AWB leaves it alone now. Rjjiii (talk) 05:44, 14 August 2023 (UTC)

For detect |archive-date= / |archive-url= timestamp mismatch, can some minor variance not throw up an error (e.g. +/- 24 hours)? If someone uses their local time as the "archive date/time" but the URL is encoded using UTC, this should not be an error or something that is "fixed". —Locke Cole • t • c 17:47, 21 August 2023 (UTC)

The archive-date is the one displayed by the archiving website, rather than a date time specific to one editor. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:59, 21 August 2023 (UTC)

Sooo is anyone going to…

Revert the edit that caused timestamp errors across the entire site or nah? 4theloveofallthings (talk) 09:23, 14 August 2023 (UTC)

I asked to have it downgraded to a maintenance message a few threads above, but I think User:GreenC bot is actually in the process of aligning |archive-date= parameters with the values present in |archive-url=. Folly Mox (talk) 13:08, 14 August 2023 (UTC)

I'm working on it Special:Diff/1165696727/1170235210 give me a week or so. I don't think they should be downgraded wait until I clean up the backlog there won't be so many. -- GreenC 14:15, 14 August 2023 (UTC)

BattyBot cleaned up about 1,000 of them. There are now 1,304 pages in Category:CS1 errors: dates. If I see any more patterns, I'll add them to BattyBot. GoingBatty (talk) 22:37, 21 August 2023 (UTC)

url-status=bot: unknown

I found |url-status=bot: unknown in an article. Is that a valid setting? What does that mean? In this case, the archive is to archive.today, which does not seem to be a currently functioning site. —⁠ ⁠BarrelProof (talk) 01:19, 18 August 2023 (UTC)

[2] works for me, but it doesn't work for everyone due to the DNS resolver you (end user) happen to use if it's CloudFlare-based. This has happened in the past and was resolved but happened again for unknown reasons. The bot: unknown is a flag added by IABot that says it's unable to determine the URL status and it needs someone to manually set it. -- GreenC 01:36, 18 August 2023 (UTC)

I checked https://downforeveryoneorjustme.com/archive.today before making that comment. It says the site is down. It would be helpful to add some explanation of what this means to the help instructions. Nobody's going to manually set it unless they know what they're being asked to do. —⁠ ⁠BarrelProof (talk) 01:46, 18 August 2023 (UTC)

Doesn't the |url-status= parameter refer to the original link rather than the archive url? It was my understanding that archive urls were presumed to be functional. Folly Mox (talk) 02:24, 18 August 2023 (UTC)

That's correct; |url-status= — which is ONLY valid when there are both |url= and |archive-url= parameters in a citation — provides the status of the original source URL, and dictates how the |archive-url= is presented in the citation: Whether it's relegated to being a "backup" source (when |url-status=live), whether it's given prominence over the original |url= (when |url-status=dead), or whether it's the only link provided, and the original |url= is suppressed (when |url-status=usurped). FeRDNYC (talk) 10:50, 20 August 2023 (UTC)

It was my understanding that archive urls were presumed to be functional.

It's not so much that they're presumed to be functional, more that they're recognized (unlike source |url=s) to have no value unless they're functional. IOW, if a citation template includes an |archive-url= that points to a dead link (the archiver shut down, they changed their access system without providing redirects from older-system URLs, etc.) the correct mitigation is to simply delete that parameter. An inaccessible archive... isn't. (An archive.) FeRDNYC (talk) 11:09, 20 August 2023 (UTC)

That would make sense right? I agree. But many disagree. They will say it doesn't hurt anything to keep a dead archive link; that it might be useful in some way; maybe the dead archive link will come live again. I ran into this problem when trying to clean up the WebCite links the community would not permit removing them. And they turned out to be right, WebCite did come back online (after nearly 2 years outage). But they were also wrong, because even if they had been removed, we could easily add them back again using the WebCite API. And removing them in the mean time was the right thing to do, to free up the slot, and to not waste user's time clicking on a dead archive link. -- GreenC 20:11, 21 August 2023 (UTC)

And sometimes the archive link is not exactly dead but is useless (e.g., the archive link points to an archived copy of a site page that doesn't have the referenced article on it anymore or contains only a paywall banner that requests the user to buy a subscription to the website). I have not known what to do in those cases. Should I be deleting such archive links? —⁠ ⁠BarrelProof (talk) 20:55, 21 August 2023 (UTC)

I remove archive URLs that serve no purpose as an archive. Izno (talk) 21:05, 21 August 2023 (UTC)

simple.wiki.x.io

Can someone sync the templates over to there again. AManWithNoPlan (talk) 00:38, 22 August 2023 (UTC)

You'll have to ask over there. The simple.wiki module suite requires simple.wiki sysop permissions to edit.

—Trappist the monk (talk) 01:13, 22 August 2023 (UTC)

CS1 archive date error with WebCite

In Moroccans in Italy:

• Blangiardo, Giam Carlo (July 2003), "Rapport sur l'immigration en Italie et notamment sur les ressortissants marocains" (PDF), in Kabbaj, Khadija (ed.), Marocains de l'Extérieur, Rabat: Fondation Hassan II pour les Marocains Résidant à l'Etranger, pp. 269–285, ISBN 9954-400-19-2, archived from the original (PDF) on 2013-05-06 {{citation}}: |archive-date= / |archive-url= timestamp mismatch; 2006-05-23 suggested (help)

The archive-date and archive-url are actually correct. WebCite encodes the archive date in base-62 which also serves as the capture ID eg. 6GOwnekjN. A Lua function for this is in Module:Webarchive. -- GreenC 18:00, 22 August 2023 (UTC)

I'm guessing the error is caused by the fact that that archive is a WebCite archive of the Wayback Machine archive of the original site, which is dumb. I've updated the article to just use the Wayback link, with the Wayback archive date. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:22, 22 August 2023 (UTC)

I wonder if someone with better search skills than me could check to see how many 'archives of archives' are used in |archive-url=. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:23, 22 August 2023 (UTC)

A command-line tool for testing/checking the value of WebCite IDs:

base62.lua

#!/usr/bin/lua --[[--------------------------------------------------- The MIT License (MIT) Copyright (c) 2016-2023 by User:GreenC (at en.wiki.x.io) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ]] -- Given a Webcite ID on arg[1], return dates in mdy|dmy|iso|ymd format -- example ID: 6H8pdR68H -- http://convertxy.com/index.php/numberbases/ -- http://www.onlineconversion.com/unix_time.htm --[[--------------------------< base62 >----------------------- Convert base-62 to base-10 Credit: https://de.wiki.x.io/wiki/Modul:Expr ]] local function base62( value ) local r = 1 if value:match( "^%w+$" ) then local n = #value local k = 1 local c r = 0 for i = n, 1, -1 do c = value:byte( i, i ) if c >= 48 and c <= 57 then c = c - 48 elseif c >= 65 and c <= 90 then c = c - 55 elseif c >= 97 and c <= 122 then c = c - 61 else -- How comes? r = 1 break -- for i end r = r + c * k k = k * 62 end -- for i end return r end local function main() -- "!" in os.date means use GMT zday = os.date("!%d", string.sub(string.format("%d", base62(arg[1])),1,10) ) day = zday:match("0*(%d+)") -- remove leading zero zmonth = os.date("!%m", string.sub(string.format("%d", base62(arg[1])),1,10) ) month = zmonth:match("0*(%d+)") nmonth = os.date("!%B", string.sub(string.format("%d", base62(arg[1])),1,10) ) year = os.date("!%Y", string.sub(string.format("%d", base62(arg[1])),1,10) ) mdy = nmonth .. " " .. day .. ", " .. year dmy = day .. " " .. nmonth .. " " .. year iso = year .. "-" .. zmonth .. "-" .. zday ymd = year .. " " .. nmonth .. " " .. day year = tonumber(year) month = tonumber(month) day = tonumber(day) if year < 1970 or year > 2020 then print "error" elseif day < 1 or day > 31 then print "error" elseif month < 1 or month > 12 then print "error" else print(mdy .. "|" .. dmy .. "|" .. iso .. "|" .. ymd) end end main()

An archive-snapshot-of-an-archive-snapshot? To what purpose?

The module does not know about WebCite urls (which work or don't work depending on the phase of the moon or something) but it does know about the embedded archive.org url in which it sees the timestamp 20060523220016 from which it extracts the date 2006-05-23. That date does not match |archive-date=2013-05-06. The correct fix here, it seems to me, is to write: |archive-url=https://web.archive.org/web/20060523220016/http://www.alwatan.ma/html/Publication_Fondation/Publication_2006/Publication/Ouvrage.pdf (http changed to https)

Moroccans in Italy has since been sort-of fixed; http://web.archive.org doesn't work for me so that probably should be fixed else someone will try to re-add the archive-snapshot-of-an-archive-snapshot WebCite url. This search found two other archive-snapshot-of-an-archive-snapshot WebCite urls which should probably be fixed. I don't see a need to fix the module to support archive-snapshot-of-an-archive-snapshot urls.

—Trappist the monk (talk) 18:39, 22 August 2023 (UTC)

Archive.org is running extremely slow today, the link is working (well at least for me). -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:04, 22 August 2023 (UTC)

I've cleared the other two instances. As with the first the Wayback link is working, so I've dropped the WebCite part. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:09, 22 August 2023 (UTC)

I suspect editors may have done this as clever redundancy in case either webcite or archive.org were not available. Really the best way is {{webarchive}} with the |format=addlarchives option. -- GreenC 19:32, 22 August 2023 (UTC)

date format maintenance

I was going to fix the articles in Category:CS1 maint: date format, but then I thought that replacing hyphens by dashes in parameters that the template is already automatically identifying sounds like something a bot should be doing; hence my questions:

• Are there any pitfalls I'm overlooking that require human judgement on whether to replace the hyphen?
• If not, why isn't this being done by a bot – and if it's just because no one's coded it yet, which existing bot would you suggest to integrate this in if I wanted to write the code for this?

Joriki (talk) 11:06, 22 August 2023 (UTC)

It may be considered cosmetic as the templates fix the actual page rendering. WP:COSMETICBOT. Keith D (talk) 17:37, 22 August 2023 (UTC)

If a bot is going to change dates, it might want to change them to the language independent YYYY-MM-DD format and use df= to define the format. That helps make the citation language independent. AManWithNoPlan (talk) 20:39, 22 August 2023 (UTC)

That seems like a good way to start a fight, in that AManWithNoPlan advocates using the hyphen-minus character (U+002D) while Beland in this edit asserts that whenever the hyphen character (U+2010) is available, it should be used. And, of course, it's safe to use the YYYY‐MM‐DD format for access and archive dates, since they are recent enough to surely be in the Gregorian calendar, the came can not be said for publication dates. Jc3s5h (talk) 22:06, 22 August 2023 (UTC)

That wasn't in a cs1|2 template. In cs1|2 dates the hyphen character (U+2010) is not allowed:

{{cite book |title=Title |date=2023‐08‐22}} → Title. 2023‐08‐22. {{cite book}}: Check date values in: |date= (help)

—Trappist the monk (talk) 22:20, 22 August 2023 (UTC)

@Jc3s5h: I would actually personally prefer hyphen-minus in all date formats. I was actually surprised that the ISO would require a non-ASCII hyphen, but there's a paywall in front of the actual standard so I couldn't double-check. I'm just going by what's written in that page's comments and what IJMacD said in this revert. (I added comments and tags to keep me from making the same apparent mistake again, since I regularly convert HTML entities into normal Unicode characters. -- Beland (talk) 01:12, 23 August 2023 (UTC)

I also am unwilling to spend hundreds of dollars for two short standards. I consider the unreasonable prices to be sufficient reason to ban the format from Wikipedia. Jc3s5h (talk) 01:21, 23 August 2023 (UTC)

https://www.reddit.com/r/ISO8601/comments/en5qxp/thats_not_iso8601_do_you_care_about_punctuation/ I should also note that many implementations only allow the ASCII dash/hyphen. AManWithNoPlan (talk) 01:34, 23 August 2023 (UTC)

There seems to be two subtly different issues here. 1) The date format used in references on Wikipedia 2) The content of the ISO 8601 article.

AManWithNoPlan is correct when he said the majority of implementation don't adhere strictly to ISO 8601 and only produce/accept U+2D "Hyphen-Minus".

For that reason I personally would advocate for Wikipedia references to adhere to RFC 3339 instead, which unambiguously uses U+2D.

Additionally, in my opinion, the ISO 8601 article should be a true and honest representation of what's written in the (paywalled) standard, not an idealized opinionated interpretation of what ISO 8601 should be.

To summarise: IMO, U+2D should be used in references site wide. U+2010 should be used on the ISO 8601 article (with its references using U+2D of course).

A (bootleg) copy of the standard can be found at these links:

• https://ipfs.io/ipfs/QmQPxkZQbHtc6AzFCb4sbz4hFC6sYgsr1xoyjNUwi4eFRW (Part 1)
• https://ipfs.io/ipfs/QmbddABaywHJLyC6HHQihhVcJ8BAyceoPgjsKnANop96mA (Part 2)

IJMacD (talk) 04:35, 24 August 2023 (UTC)

Testing in sandbox for French Chapitre template

Just a heads-up on some changes I envision to Module:CS1 translator to add support for fr:Template:Chapitre. After expansion, typical French usage is very similar to an en-wiki {{cite book}} template that contains a |chapter= param, so my approach has been to take advantage of the existing _cite_fr function, as we don't have a separate, {{cite chapter}} template, and we won't need a new function in the module to handle it because it's so close to cite book.

This is a very common citation template on fr-wiki and my current activity here results from a real-world problem based on my intention to translate fr:Manifestations de ménagères, in which about half of the items in the "Bibliographie" section use the "Chapitre" template. I've put that translation aside for the moment, while looking at this module.

I'm still in the middle of it, but here is roughly the current status (tl;dr: working. except for one bug not yet looked at, but more test cases needed):

• New template {{cite chapter/French}} – invokes the module, with new entry pt cite_chapter_fr
  • new redirect Template:Chapitre links to Template:Cite chapter/French and not the sandbox, so is not useful for testing, but will be useful for no-change translation by users after everything is done
  • New template {{cite chapter/French/sandbox}} transcludes invokes the Module sandbox, so is useful in test cases
• Module:CS1 translator/data – 2 needed fields added (there's a mine-field of false friends here for the unwary: éditeur ≠ 'editor', but auteurs ouvrages = 'editors' in this case, and 'veditors' with no-error markup by necessity)
• Module:CS1 translator/sandbox – (new) for testing changes. New exported function 'cite_chapter_fr', new entry pt for {{cite chapter/French}}; updates to function title_make_fr, and function _cite_fr.
• {{Cite book/French/sandbox}} – (new) invokes Module:CS1 translator/sandbox
• {{Cite chapter/French/sandbox}} – (new) invokes Module sandbox
• Template:Cite book/French/testcases – (new) because of the 'subst-ing', I've had to take a different approach here; the design approach seems workable, but if there's a better way, sombody please lmk.

This is my first attempt at Lua coding, so it's a bit slow, and I may be making dumb mistakes, or coding inefficiently, or not aligning properly with existing data structures or the original design for which I beg pardon and ask for indulgence, but I am making progress. I believe I have a working version for dealing with the unknown param |pages totales= that passes my current test cases (but more are needed), and almost everything in the Chapitre template is being translated correctly. There is one notable exception that I have not looked at yet, which is that it flags "Unknown parameter |titre chapitre= ignored". Thanks, Mathglot (talk) 11:38, 24 August 2023 (UTC)

I'm pretty sure that you don't have to worry too much about the substing. Because Template:cite chapter/French/doc (transcluded into {{cite chapter/French/sandbox}}) includes {{Subst only|auto=yes}}, substing is handled by AnomieBOT usually within the hour. To prevent AnomieBOT from substing, you can add a {{nobots}} template to the ~/testcases page. That done, test cases are written like this:

{{Cite chapter/French/sandbox |auteur=Jean-François Condette |titre chapitre=Les manifestations de ménagères dans le département du Nord de 1940 à 1944 : Révolte frumentaire ou résistance ? |auteurs ouvrage=Robert Vandenbussche (dir.) |titre ouvrage=Femmes et Résistance en Belgique et en zone interdite |lieu=Lille |éditeur=Publications de l’Institut de recherches historiques du Septentrion |collection=Histoire et littérature du Septentrion (IRHiS) |numéro dans collection=38 |année=2007 |pages totales=247 |isbn=978-2-490296-12-5 |lire en ligne=http://books.openedition.org/irhis/2189 |consulté le=2023-07-13 |passage=125–164}}

which expands to this:

{{cite book/subst |access-date=2023-07-13 |author=Jean-François Condette |chapter=Les manifestations de ménagères dans le département du Nord de 1940 à 1944 : Révolte frumentaire ou résistance ? |date=2007 |isbn=978-2-490296-12-5 |location=Lille |page=125–164 <!--pages totales=247--> |publisher=Publications de l’Institut de recherches historiques du Septentrion |series=38 |series=Histoire et littérature du Septentrion (IRHiS) |title=Femmes et Résistance en Belgique et en zone interdite |url=http://books.openedition.org/irhis/2189 |veditors=((Robert Vandenbussche (dir.)))}}

and renders like this:

Jean-François Condette (2007). "Les manifestations de ménagères dans le département du Nord de 1940 à 1944 : Révolte frumentaire ou résistance ?". In Robert Vandenbussche (dir.) (ed.). Femmes et Résistance en Belgique et en zone interdite. Histoire et littérature du Septentrion (IRHiS). Lille: Publications de l’Institut de recherches historiques du Septentrion. p. 125–164 . ISBN 978-2-490296-12-5. Retrieved 2023-07-13.

After I publish this comment, I'll add AnomieBOT to this page's {{Bots}} template to prevent the above from being subst'd.

I do not think that you should use the accept-as-written markup in |veditors= as a translation of |auteurs ouvrage=. That may violate WP:CITEVAR for templates that use |nom=, |postnom=, |prenom=, |prénom= because those |last= / |first= parameters will render in Vancouver Style when they should not.

I notice that the expansion of the example template has |series=38 and |series=Histoire et littérature du Septentrion (IRHiS) which does not get flagged by MediaWiki and is not caught by Module:CS1 translator when rendering the citation. I suspect that this is because at line 609 we don't look for out_t[param] already present in out_t. That should be fixed. Still, in your translation, you should probably concatenate |collection= and |numéro dans collection= in some way before assigning the result to |series=.

—Trappist the monk (talk) 14:29, 24 August 2023 (UTC)

Thanks for this. I agree about the as-written wrt veditors; the reason I did that for now, is that it's a q&d solution, and gets more data converted; in the long run, I would maybe attempt to parse it, separate out the authors, and so on; but that will require some study with the Lua doc, and I don't want that to hold up the conversion of {{Chapitre}}, so that's down the road. As far as series/collection, I noticed that and totally agree; the code to concatenate |pages=12–14 and |pages totales=355 into |pages=12–14 <!--pages totales=355--> lives hard-coded in function _cite_fr and was kind of proof-of-concept to see if I could do it; but the intention all along, was to generalize it into a new function that would examine a predefined table of param pairs relating one French/foreign param with no cs1|2 equivalent (like |pages totales= ) as k, to a 'nearest cs1|2 target' (if there is one) as v, and concatenate the former to the latter as hidden text; the table probably to live as an extension to /data which would define these relationships as k-v pairs relating the foreign-param to en-param (and multiple k's pointing to the same v would not be a problem). Anyway, the point being that I agree, but I don't know if I'll get to it in my first version, this being already at the limit of my Lua ability, but I think users are used to occasionally imperfect translations that might miss one thing here or there while still generating an essentially correct citation and are hugely useful timesavers, and I think that users can deal with the series/collection problem for now, and will be well-served by something that can translate {{Chapitre}} 95% perfectly, rather than not handle it at all and have to slog through it the long way, the way they do now. Maybe what I can do for now, is combine |series= and |collection= with the "brute force" method I used for |pages totales=, and the obvious parallelism between the two cases will point the way to a better, more generalized solution next iteration. Thanks very much for the feedback! Mathglot (talk) 20:09, 24 August 2023 (UTC)

Oh, just realized that |editor= still exists (although not |editors=, which would've been ideal here). In any case, this works: |editor=((Robert Vandenbussche (dir.), John Smith, Mary Doe)), so I'll make this change to the sandbox. Probably not ideal, but still one click better than |veditors=. Mathglot (talk) 20:50, 24 August 2023 (UTC)

I'm not convinced that hiding stuff or suppressing maint messaging is a good idea. Let the editor who placed the template decide what to do with parameters that aren't supported by en.wiki cs1|2. Let |pages totales= pass through so that the editor knows that it's there and can decide what to do with that information. Hiding the parameter in html comment markup makes it likely that the editor won't know that its there especially those editors who use that abomination that is ve. Similarly, don't mask the maintenance message that will occur with a comma separated list of editor names. Most editors won't see that because maint messaging is hidden by default but masking with accept-as-written markup hides the issue from gnome editors who would otherwise separate the list into individual parameters as should be done.

I would suggest that you drop the idea of parsing human names. As soon as you think you've got it sussed, someone's name will turn up that doesn't match any of the patterns you've coded for.

If Module:CS1 translator gets 90% of the way, that is good enough so long as we communicate, usually by Module:Citation/CS1 error and maint messaging, that the translations aren't perfect, that should be good enough. I suspect that it is good enough because no one has complained to me about inadequate translations and you know that en.wiki editors are not shy when it comes to complaining.

—Trappist the monk (talk) 23:16, 24 August 2023 (UTC)

Okay, what you say about letting the errors pass through is persuasive. I'll do that next iteration. I'm taking a break from the sandbox for a little bit, because I want to go back to the translation that originally inspired this. I'll make the changes you suggest when I get back to it, but if you feel like playing with it before I do, obviously feel free. I haven't yet looked at that one known bug involving unknown titre chapitre, but I have a feeling I assigned a 'nil' where I shouldn't have, or maybe the opposite.

There's another thing I've been thinking about, but again not for the short term, but it's this: a lot of times, a particular article might have a "house style" of one sort or another, and being able to match it with the translation module would be a really nice benefit. If we could somehow allow users to configure certain things about the template action. For example, I like one blank before each pipe char; others like none, or one on each side. Ditto for equal signs. Some like a vertical presentation, with a newline before each pipe. Some like first name first, others like last name first. I like having an empty |trans-title= right after the |title=, so I remember to fill it in later. I like url last, or almost last, others like it closer to the front, and so on.

Over time, I've developed a little tool kit of regexes that can do some of these, but it ends up eating up the time I just saved by using the translator module; it would be very cool to be able to configure the module for the house style, and get it to display in that manner. Mathglot (talk) 03:34, 25 August 2023 (UTC)

unknown titre chapitre fixed in live and sandbox modules. It was flawed before you touched it.

—Trappist the monk (talk) 17:40, 25 August 2023 (UTC)

Wow, cool! Thanks! (Still translating, but I'll get back to this before too long.) Mathglot (talk) 08:40, 26 August 2023 (UTC)

|archive-date= / |archive-url= timestamp mismatch

I understand this was just rolled out in the recent update, but can this somehow be downgraded to a maintenance message from error status? It honestly doesn't seem like such a big problem that it requires red error text. For archives that support generating this mismatch, couldn't the template be coded to display the archive date by parsing |archive-url=, instead of forcing editors to fill in the parameter manually, risking typos? Folly Mox (talk) 09:32, 13 August 2023 (UTC) Secondary suggestion struck 16:22, 13 August 2023 (UTC)

There's a discussion about calculating the archive-date here Help talk:Citation Style 1/Archive 88#Calculated archive-date, tldr there many good reason not to do it. The discussion on setting this error up is in archive 87, Help talk:Citation Style 1/Archive 87#Error or Maint message if archive date doesn't match url. No comment on whether this should be an error or a maintenance message, but date issue are usually errors (invalid format etc). -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:25, 13 August 2023 (UTC)

Thanks for the pointer to the conversation about parsing the date out of the URL. Struck that bit. Folly Mox (talk) 16:22, 13 August 2023 (UTC)

Errors should generally be preferred because they get fixed. Maintenance items do not get fixed with as much gusto. (That we have as many maintenance categories as we do is because several of them have lots of items to fix, which is a chicken-and-egg issue....)

What I'd like to see the module do is for the warning to output a suggested date for easy copy-pasting (compliant to the known format or ISO otherwise -- the latter case is common in section editing). Something like "archive date does not match archive URL, value January 1, 1970 suggested". The case I was running into for this was when I add an archive URL for the first time, and I'd like the module to do the work for me of adding the date. Izno (talk) 22:18, 25 August 2023 (UTC)

We could add a suggested date in the article-preferred format only when the module can see the {{use xxx dates}} template. That template is not visible when section editing so the 'suggested date would necessarily be in YYYY-MM-DD format. This same might be applied to templates with |archive-url= but missing |archive-date= but only for those archive urls that include a YYYYMMDDhhmmss timestamp (currently archive.org and archive.today).

Frankly, I don't think that we should suggest the date in dmy or mdy format. cs1|2 has date reformatting code to render citations with a consistent date format. If editors must have the wikitext dates all-same, there are scripts for that or they can reformat manually.

I don't know what you mean by I'd like the module to do the work for me of adding the date. Templates/modules cannot modify wikitext so adding |archive-date= and its value is on you.

—Trappist the monk (talk) 13:42, 26 August 2023 (UTC)

We could add a suggested date in the article-preferred format only when the module can see the {{use xxx dates}} template. I was thinking also of |df=.

Frankly, I don't think We should go the extra mile. It's probably not too much work once you have the date in the message.

I don't know what you mean A bit literalist of an interpretation on your part. You know I'm quite aware of what templates and modules can do. :) Izno (talk) 15:47, 26 August 2023 (UTC)

Yes, I know. You are not the only person (I hope) who is reading this discussion. Those others may not know that it is not possible for the module to do the work for you.

—Trappist the monk (talk) 15:42, 27 August 2023 (UTC)

it is not possible for the module to do the work for you Is there a reason it can't detect an archive.org/archive.today link, parse the date and output/override the |archive-date= if there is a mismatch (I'd actually think we should deprecate/make optional |archive-date= for these two archive sources)? No need to change wikitext or emit an error, just add it to a maintenance category so it can be cleaned up with other more serious issues by bot. —Locke Cole • t • c 20:38, 27 August 2023 (UTC)

The two links provided by ActivelyDisinterested are worth reading. Izno (talk) 20:50, 27 August 2023 (UTC)

Thanks for that, I had somehow read the second link but not the first. It's a shame that potential issues with tools/scripts is being used to limit functionality for editors (easier archive link processing). —Locke Cole • t • c 17:49, 28 August 2023 (UTC)

Module tweaked to provide suggested |archive-date= value in error message. Suggested date is formatted according to |df= or {{use xxx dates}} or YYYY-MM-DD in that order.

{{cite book/new |title=Title |url=//example.com |archive-url=https://web.archive.org/20230827081416/https://example.com |archive-date=August 26, 2023|df=dmy-all}}

Title. Archived from the original on 26 August 2023. {{cite book}}: |archive-date= / |archive-url= timestamp mismatch; 27 August 2023 suggested (help)

{{cite book/new |title=Title |url=//example.com |archive-url=https://web.archive.org/20230827081416/https://example.com |archive-date=August 26, 2023|df=dmy}}

Title. Archived from the original on August 26, 2023. {{cite book}}: |archive-date= / |archive-url= timestamp mismatch; 2023-08-27 suggested (help)

This tweak also uses the internal date formatter which it probably should have done from the beginning for i18n.

—Trappist the monk (talk) 15:42, 27 August 2023 (UTC)

Further tweak. Instead of formatting according to |df= or {{use xxx dates}} or YYYY-MM-DD, the module extracts the format used in |archive-date= and uses that format in the absence of |df= or {{use xxx dates}}.

Here is a caveat: In the second example above, the template uses |df=dmy. That parameter value tells the date-reformatter to leave |access-date= and |archive-date= formats as they are. The suggested date for the error message is YYYY-MM-DD before the format specified in |df= is applied. Because |df=dmy instructs the module to ignore |archive-date= (which this date is) the message renders as YYYY-MM-DD. I suspect that this is generally acceptable because YYYY-MM-DD is the common and usual format when |access-date= and |archive-date= have a different format from the publication dates.

—Trappist the monk (talk) 17:07, 27 August 2023 (UTC)

This seems like a lot of talk for such a small issue, after GreenC bot did it's work there are only 264 articles in the tracking category. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:03, 27 August 2023 (UTC)

Yeah, it's not like a bot can't take care of it. My followup request though was for when I go scuba diving for an archive link, as is common when repairing other citations for other reasons, and am thus adding a new archive link for the first time (and want to be more lazy about the date added). I prefer to look up archive links myself because the automated processes often fail to catch bad archives. Izno (talk) 21:10, 27 August 2023 (UTC)

I have used the automated process a couple of times, but normally always add the archive manually as the automated process can't tell if the archive is broken. I just copy in the archive link, and then read the date from the url. I wonder whether fixing this error could be automated so if the date is left out the bot just adds it a bit later, the same way AnomieBOT deals with substituting templates. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:30, 27 August 2023 (UTC)

With the new tracking category it would be possible to automate. I already fixed about 99% of them, the category is around 300 now, before it was over 40,000. It's trickier than it might seem on first look, lots of edge cases, and my bot is not full-auto, so I would need to extract the code and build a standalone bot. -- GreenC 21:41, 27 August 2023 (UTC)

Reordering CS1 parameters

Is there any script that allows one to reorder CS1 reference parameters on a page into some sort of standardized order? {{u|Sdkb}} ^talk 04:23, 14 August 2023 (UTC)

Please don't. Nikkimaria (talk) 04:30, 14 August 2023 (UTC)

Sadly no. And while it would be useful in some cases, it would also be very prone to abuse. Headbomb {t · c · p · b} 04:32, 14 August 2023 (UTC)

I certainly wouldn't want to see it used at any scale, since it's a textbook cosmetic edit, but given that we already have scripts for things like citation spacing that are used without complaint to e.g. to tidy up FACs before promotion by those particularly nitpicky, this seems in the same wheelhouse. {{u|Sdkb}} ^talk 04:42, 14 August 2023 (UTC)

Please don't do that either. Nikkimaria (talk) 04:58, 14 August 2023 (UTC)

I definitely would not want to see a "standardized order" for citation template parameters. That's like being recommended a specific number of times to run a comb through your hair. Folly Mox (talk) 05:43, 14 August 2023 (UTC)

A standardized order would be nice, to prevent crap like the citation example here. The issue is that no one will ever agree on what the standard order should be. Headbomb {t · c · p · b} 06:20, 14 August 2023 (UTC)

Making the order the same as the display output (with anything that doesn't directly affect the display at the end) seems like it might be an agreeable enough order. {{u|Sdkb}} ^talk 13:14, 14 August 2023 (UTC)

As the automated referencing tools become more robust, accurate, and popular, it's probable that whatever order they have chosen to output the parameters in will become the de facto standard, but I still feel like entering something like that into MOS guidance is intrusively micromanagey. Agree that citation templates without whitespace between the parameters are difficult to read and to edit, and the constructed example does a good as an unintuitive jumble, but I've definitely filled out templates similarly, based on what is in my clipboard to begin with, what I can remember from the information in the other tab, etc. Editing on a device that's unable to display two tabs sidey-side comes with its own difficulties when organising information. Folly Mox (talk) 13:18, 14 August 2023 (UTC)

Even if it never goes into MOS guidance, the automated referencing tools needed to have decided on an order at some point, and they probably currently conflict with each other. Centralizing some sort of best practice default order — along with clear guidance that it should never be micromanaged — seems like it would be useful, even if only for future automated reference tool developers. Having a better order generally isn't worth the disruption it causes in diffs, so I wouldn't want it even as part of the genfix set, but it does make it marginally easier to parse references in wikitext. Cheers, {{u|Sdkb}} ^talk 14:12, 14 August 2023 (UTC)

In my defence for that script, it also fixes "url-status=live" maintenance messages and I very rarely run it without making other changes to the articles as well. – Mesidast (talk) 10:33, 14 August 2023 (UTC)

It appears that WP:ProveIt's "Normalize all references" option reorders parameters, perhaps using the order from TemplateData's paramOrder (kudos @Stjn and @AntiCompositeNumber for reminding me). So the cat is already out of the bag in that sense. {{u|Sdkb}} ^talk 15:22, 17 August 2023 (UTC)

Echoing others, I wouldn't like a "standard" order, but I would love a "configurable" order, to match the "house style" of the article it was intended for. I'd also extend that idea to configurable param style: do you want a newline before each pipe, just a blank before, or blanks before and after, or no blanks? What about equal signs? And so on. That's probably something more for a Module, but a template might be able to do that, as long as it didn't have to contend with citations that contained hidden text delimiters, or other pipe-related complications. Mathglot (talk) 03:42, 25 August 2023 (UTC)

Those style questions can be suggested in TemplateData already such that various tools (I think only the template makers in WikiEditor 2010, VE, and WTE2017 and I think the citation creator in VE), but there is only one version allowed. Today, I think the general expectation is {{cite work |parameter1=value1 |parameter2=value2}} as the most readable for the predominant (inline) use case. Izno (talk) 19:49, 26 August 2023 (UTC)

When preparing a bibliography in alphabetical order, it's helpful if the parameters are in the same order that one would use to do the alphabetical ordering. So, authors first, then the date. If there were no authors, the title of the article or book would go first. But I to would oppose bots running around reordering parameter order. Jc3s5h (talk) 10:59, 25 August 2023 (UTC)

How about a template to declare a style local to an article, and guidance to not change the order in violation of that specified in the article's style template. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:31, 25 August 2023 (UTC)

Wouldn't making changes against an articles style of citation already be covered by CITEVAR, without any need for an additional template. The same thing comes up when editors edit war other spacing in citations. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:06, 25 August 2023 (UTC)

With the reminder that any script that does stuff like this is type-specimen COSMETICBOT, I would absolutely not respect any template telling me how to order citation parameters, even if I noticed it all the way at the top of the article when I'm probably editing a different section. If it bothers a major contributor to the article enough that they feel like wasting their time pointlessly shuffling parameter order, I'm certainly not going to revert them, but I'm also not going to exert the mental effort to try to remember how someone said they wanted their parameters ordered if I'm there cleaning up actual issues. Folly Mox (talk) 19:36, 26 August 2023 (UTC)

The template itself cannot so provide a required order (as in, a CS1 error). Its documentation could potentially. Izno (talk) 19:44, 26 August 2023 (UTC)

(←) I also prefer parameters to be in the order of display. This ultimately supports the bibliography comment above. If there's a script that reorders things this way, so long as it's in the context of a major edit, I see no issue. Izno (talk) 19:49, 26 August 2023 (UTC)

All that accomplishes is making it hard to see what the major edit was. Nikkimaria (talk) 02:25, 27 August 2023 (UTC)

Then that is a burden for the users reviewing the edit. Such an edit is distinctly permitted, especially in a regime where cosmetic edits aren't allowed by themselves using a script. Izno (talk) 04:43, 27 August 2023 (UTC)

Archive error

Why does this produce an error? Found in Typhoon Nanmadol (2022), there are probably others.

• Tropical Depression 16W (Sixteen) Warning No. 01 (Report). United States Joint Typhoon Warning Center. 12 September 2022. Retrieved 12 September 2022.

-- GreenC 18:36, 24 August 2023 (UTC)

I think that {{Cite JTWC}} is missing an #if statement in its application of |archive-date=. The template uses whatever is in |date= to populate |access-date= and |archive-date=. The latter appears to not be reliant on |archive-url= existing to be populated. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:02, 24 August 2023 (UTC)

(edit conflict) I have cleaned up that template a bit (it was putting today's date in places where it shouldn't have been), but it appears that in that template, |archive-url= is required if |date= is provided. I have added that requirement to the documentation. – Jonesey95 (talk) 19:07, 24 August 2023 (UTC)

Is that requirement purposeful or unintentional? It's an odd relationship. -- GreenC 19:12, 24 August 2023 (UTC)

Hi Jonesey95: What would you think about boldly removing this requirement. I'd do it but am not fluent with this script. Compare with {{Cite PAGASA}} which can have a |date= and no |archive-url=. It looks like an unintentional feature maybe added by accident:

• "Tropical Cyclone Bulletin #22 for Severe Tropical Storm 'Maring' (Kompasu)" (PDF). PAGASA. 11 October 2021. Retrieved 11 October 2021.

It would help with reducing Category:CS1 errors: archive-url. -- GreenC 20:17, 24 August 2023 (UTC)

The coding is bizarre, but the template has 64 transclusions. If someone adds an explicit and correct |archive-date= to each one, I'd be OK with fixing the template so that |date= is used as it should be and not "triple-counted". I recommend that this whole discussion be moved from here to the template's talk page. – Jonesey95 (talk) 22:38, 24 August 2023 (UTC)

Someone wanted to use the |archive-url= field to store non-web archive URLs which of course have no archive date since they are not archive URLs. This was a problem because CS1|2 was throwing a red error when there is an |archive-url= but missing |archive-date=. So they generated a default "dummy date" to stop the errors (based on the value of the |date= field). Then recently we added this new tracking category that caught the mismatch of the dates and so on. Then it all became clear. I removed the default |archive-date= from the template, and am currently processing all instances of this template, moving the |archive-url= to outside the template (when not a valid archive URL) .. it's really a second citation. -- GreenC 16:43, 28 August 2023 (UTC)

Followup: Template_talk:Cite_JTWC#archive-date_errors_etc... -- GreenC 16:49, 28 August 2023 (UTC)

Subtitle locations for multi-volume books

I've started putting subtitles for multi-volume books in the volume field rather than in the more traditional title field because I think it's easier for the reader to understand exactly that exact volume covers. Forex title=German Warships 1815–1945: U-boats and Mine Warfare Vessels|vol=Two versus title=German Warships 1815–1945|vol=Two: U-boats and Mine Warfare Vessels. The first example could easily be understood as the second volume of a book devoted to U-boats and Mine Warfare Vessels within a larger work covering German warships while the second example makes it much clearer that volume 2 of German Warships covers only U-boats and Mine Warfare Vessels, IMO.

Currently the documentation for the volume field only covers numbers, not actual text. I would like to make adding a subtitle in addition to the number a valid option. This may raise the hackles of professional catalogers, but I believe that the extra clarity is worth making this change, especially since we're not strictly bound by MARC standards. Thoughts, comments? Sturmvogel 66 (talk) 15:08, 25 August 2023 (UTC)

MARC standards are outside the scope of cs1|2 templates. The machine-readable metadata that Module:Citation/CS1 encodes into its rendering of cs1|2 templates is COinS. For books, astonishingly, COinS does not support a volume keyword. So, for readers who consume cs1|2 citations via reference management software (Zotero and the like), whatever you put into the |volume= parameter is lost to those readers.

{{cite book |title=Title |volume=Some sort of subtitle}}

Title. Vol. Some sort of subtitle.

'"`UNIQ--templatestyles-0000009F-QINU`"'<cite class="citation book cs1 cs1-prop-long-vol">''Title''. Vol.&nbsp;Some sort of subtitle.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wiki.x.io%3AHelp+talk%3ACitation+Style+1%2FArchive+89" class="Z3988"></span>

In the above, 'Some sort of subtitle' appears only in the visual rendering; there is no &rft.volume=Some sort of subtitle.

When a {{cite book}} template has any of these parameters:

• |type=
• |series=
• |language=

they are rendered between |title= and |volume= which visually disconnects the subtitle from the title.

{{cite book |title=Title |type=Type |series=Series |language=nv |volume=Some sort of subtitle}}

Title (Type). Series (in Navajo). Vol. Some sort of subtitle.

—Trappist the monk (talk) 15:43, 25 August 2023 (UTC)

I think that you're putting more weight on the appearance than is necessarily warranted. I'm more concerned about clarifying a reader's understanding about the nature of the book than anything else. Izno's comment about a volume-title field would satisfy us both, I'd think.--Sturmvogel 66 (talk) 14:21, 26 August 2023 (UTC)

User:Sturmvogel 66, as someone who cites a lot of different kinds of works that don't socket nicely into the standards, I always value creating a citation that makes sense to a human Wikipedia article reader and contains all the relevant information about the work, even if the way I end up using the parameters is not strictly correct or liable to be misread by structured data reusers. I try my best to accommodate the standards, but when the source of their data is everything ever published, there are going to be corner cases that don't play well, and my primary objective is to serve the reader. Folly Mox (talk) 17:12, 25 August 2023 (UTC)

I whole heartedly concur with your statement.--Sturmvogel 66 (talk) 14:21, 26 August 2023 (UTC)

I honestly don't include subtitles in the general. (I don't remove them where they are present.)

There are many cases where a specific volume's title, which I would suggest is not a subtitle per se, has gone into the volume field. You are not the first. These cases are more or less the dominant cause of the 65,000 pages in Category:CS1: long volume value (which is "just" a tracking category). There has been some previous suggestion for some sort of |volume-title= in the deeper archives, but I vaguely recall a more recent thought on it. Izno (talk) 22:08, 25 August 2023 (UTC)

That's an interesting idea that I'd never thought about. I can easily think of multi-volume books with both a title and a subtitle for the overall work with individual volumes having their own unique titles. I'd definitely support a volume-title field.--Sturmvogel 66 (talk) 14:21, 26 August 2023 (UTC)

|volume-title= makes sense, but only if we are not supposed to place the title in |volume= (which seems easier). Thanks,  Mr.choppers | ✎  14:38, 26 August 2023 (UTC)

Volume-title would make it very clear where the individual volume titles belong and might help forestall arguments over their proper location under the current system. WP:CITEVAR generally won't prevent a newish editor from making changes like moving subtitles from one field to another in the belief that they're doing the right thing (as they understand it).--Sturmvogel 66 (talk) 14:49, 26 August 2023 (UTC)

Proposal: 'Verified' parameter

I propose three parameters be added to this template.

1. "Verified": a boolean y/n parameter
2. "Verified by": a parameter containing the name of editor(s) (between 1 to 3)
3. "Verified date": a parameter containing the date(s) the citation was verified

The purpose of this parameter would be as follows: Wikipedia has reasonably significant issues regarding the verifiability and reliability of information on this site. The 'verified' field provides two things; (1) it gives readers a degree of confidence in a citation without having to click through, (2) it gives editors the ability to identify citations that are worth checking.

Adding these parameters would allow Wikipedians to trawl through the citations on this site and verify them.

Wikipedians already engage in the verification of citations, however it is often unclear whether a citation has already been checked by another editor or not. Adding this parameter would make it easier for editors to focus on citations / claims that haven't yet been checked, substantially increasing the productivity of site editors.

What do my fellow editors think of this proposal?

Kind regards Jack4576 (talk) 10:08, 26 August 2023 (UTC)

I think this makes more sense as a standalone template along the lines of {{webarchive}} or {{dead link}}. I also think the boolean and editor-name fields might be superfluous. It will be recorded in the article history who filled it out, which will also not be susceptible to impersonation and reduce the quantity of paperwork when adding the template.

I've thought of a similar parameter for citations that have been checked against their source for accuracy and completeness, which is kind of one step down from this. Folly Mox (talk) 14:13, 26 August 2023 (UTC)

This would be good, but only if the verifiers were vetted in some way, akin to license reviewers in Commons. This would be very good for offline sources; I have sometimes requested scans of things quoted and it would be great for that verification to become permanent.  Mr.choppers | ✎  14:43, 26 August 2023 (UTC)

I don't think there's a win here. Assume a template ends up verified. Assume later that someone vandalizes the citation. Now you're still trusting a bad citation. Izno (talk) 15:53, 26 August 2023 (UTC)

It’d be relatively easy to address this by emptying the ‘verified’ field whenever the passage containing the citation is altered (until another editor verifies the altered text matches the citation again) Jack4576 (talk) 05:50, 27 August 2023 (UTC)

A template has no understanding of the history of its use. How do you propose to "empty" the field? Having a user do so? That doesn't seem like a win at all. Izno (talk) 16:22, 27 August 2023 (UTC)

Yes the expectation would be that if the prose under a verified citation section was altered, the editor altering that prose would empty the ‘citation verified’ parameter. Another editor would have the opportunity then to check that the altered prose is still supported by citation.

Its a long standing issue that small changes to prose with an existing citation can slip under the radar, and this has been a tactic used by LTA users to vandalise the site Jack4576 (talk) 23:52, 27 August 2023 (UTC)

How would we stop a POV pusher from verifying their own cites, or if it was a separate template from simply copying the details from one cite to another. A vetted group would only work if there was some underlying software changes to support it, and could easily lead to the cabal becoming more real. Ultimately editors who are concerned about the referencing if details should verify the details themselves, other Wikipedia editors are not reliable sources. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:59, 26 August 2023 (UTC)

Ultimately editors who are concerned about the referencing ... should verify the details themselves

Agree Folly Mox (talk) 19:20, 26 August 2023 (UTC)

why should they do it themselves? why not allow other trusted editors, who wish to do so, to undertake that work for them? why not create systems to make such a task easier and more productive ? Jack4576 (talk) 05:56, 27 August 2023 (UTC)

Jack4576 (talk) 05:56, 27 August 2023 (UTC)

Having the name of the verifier listed within the parameter would enable for such verifications to quickly be removed by other editors Jack4576 (talk) 05:45, 27 August 2023 (UTC)

In addition to all the above, if the intent is to verify that a citation supports a statement in the article, a citation template is the wrong place for it. This is because several references attached to different statements can point at a single citation, through either shortened footnotes or the |name= parameter of <ref>. Kanguole 17:08, 26 August 2023 (UTC)

The existing review processes (WP:AFC, WP:DYK, WP:GA, A-class, and WP:FA) should result in a discussion or analysis recorded on the article's talk page. I think any kind of lower-stakes review of single citations, should create something similar. Rjjiii (talk) 17:34, 26 August 2023 (UTC)

The disadvantage of doing it on the talk page is that it requires click-through

Having it as a parameter within the citations allows editors/readers to recognise which citations have been verified or not with immediacy Jack4576 (talk) 05:48, 27 August 2023 (UTC)

It’d be totally possible for a verification of a citation to cover each time the citation is used across the article.

If anything, I think what you’re pointing to here is an even stronger reason to make it a parameter within the template Jack4576 (talk) 05:47, 27 August 2023 (UTC)

These are going to go stale faster than the citations themselves, either requiring enormous churn in maintenance or becoming useless and meaningless. It is very common for editors to change the text of articles without changing the underlying citations. Either that is going to have to be accompanied by additional busywork by the same editor, every time, quickly becoming rote and meaningless, or it is going to push the verification work onto other editors. In addition, many Wikipedia editors are not very rigorous about what they use citations for, and in many cases when editors are explicitly asked to verify citations (for instance in DYK and GAN reviewing) their "verification" consists merely of checking that the article has lots of little blue clicky numbers, and not much beyond that. I think that encoding all of this behavior into citation template parameters will only make our citation templates even more baroque and difficult to use (a direction they have already gone too far in, resulting in many poorly used citation templates and many bots mangling citations in an attempt to make them less broken) and waste the time of editors without resulting in much or any article or reference improvement. —David Eppstein (talk) 06:11, 27 August 2023 (UTC)

In addition, many Wikipedia editors are not very rigorous about what they use citations Right. See: Fire basket, currently linked from the main page. This would presumably have "verified" citations in those boolean yes/no parameter slots, which without additional context would be misleading, Rjjiii (talk) 06:24, 27 August 2023 (UTC)

In what way would it be misleading without additional context ?

I don’t understand the point Jack4576 (talk) 07:43, 27 August 2023 (UTC)

@Jack4576: An editor thought that the references verified the article's content. Do you think that's true? What do you see on the talk page? Regards, Rjjiii (talk) 14:04, 27 August 2023 (UTC)

People couldn’t / shouldn’t verify their own provided references, so I don’t think it would be a problem. The could be more readily identified Jack4576 (talk) 23:50, 27 August 2023 (UTC)

Jack4576, look at the participants on that talk page. This is not an example of editor verifying their own work. Why do you think a boolean tick box would be less prone to rubber-stamping like that than a DYK review? Rjjiii (talk) 00:01, 28 August 2023 (UTC)

Is the talk page a problem? All I'm seeing is one editor checking the quality of another editor's citations. This seems to be what we want.

I'm sure a boolean tick box would have some degree of rubber stamping but I think the times where verification occurs in-depth are beneficial enough to justify such a parameter. Perfect the enemy of the good, etcetc Jack4576 (talk) 02:22, 28 August 2023 (UTC)

Right! So now look at the sources. Jack4576, do you think this webpage: https://web.archive.org/web/20201107185154/https://www.t-online.de/ratgeber/id_77979942/feuerschale-kaufen-so-finden-sie-das-beste-modell-fuer-ihren-garten.html Could possibly verify this statement to which it is attached: The beacon atop the Altenburg castle in Bamberg served to communication with the neighboring Giechburg castle. Rjjiii (talk) 03:22, 28 August 2023 (UTC)

I don't understand why you are pointing toward a single instance of an editor mis-verifying a reference, as an argument against creating infrastructure to assist with keeping track of verifications generally. If you take issue with a particular instance of verification, and an editor included their name under the 'Verified by' parameter, it would be relatively easy for another editor including yourself to check over the other times they've claimed to verify a reference

Additionally I can't speak German, so I wouldn't be touching the 'verify' parameters in respect of that reference and claim. I would leave the verification to another editor who is so equipped with those gifts

I still don't understand the point you're trying to make Jack4576 (talk) 03:30, 28 August 2023 (UTC)

Verification work is already, in theory, a process editors should be undertaking when improving articles

This just enables editors to keep track of when that work has already been conducted, enabling productivity by avoiding duplication of work

To put it another way; in theory, it’s already the case that each time an article changes we should have editors checking to ensure that the change is warranted and verifiable. So the unending maintenance you point to is already the status quo

Additionally, this would be an optional parameter; I don’t think it necessarily follows that an increased amount of work would happen. Any contributions would only be voluntary

I think what i’m proposing it analogous to the GAN process, excepting that it zeroes in on individual citations/sections of an article without having the entire article in scope Jack4576 (talk) 07:41, 27 August 2023 (UTC)

If Bob claims to have verified, how does Sally know that Bob actually did verify? What if Bob thought he verified something, but actually misinterpreted the source? "verified" is a pointless parameter. {{failed verification}} is the actionable thing. Headbomb {t · c · p · b} 14:13, 27 August 2023 (UTC)

I'm wary of commenting any more in this discussion as I'm already quite present, however I am replying here because your question appears to have been posed to me directly.

The answer to your question is that: 'Because if Bob didn't actually verify, the reference was incorrect, and this was discovered; that would significantly harm Bob's reputation as an editor. The rest of Bob's verifications would then become suspect and potentially come under closer scrutiny by the community.'

{{failed verification}} does not provide the same utility as a potential 'verify parameter' or {{passed verification}} template.

The benefit of a 'verified' parameter would be that the community can keep track of what things have passed verification, so they can move onto verifying other citations that haven't yet been verified yet. Thus the editorial community can more efficiently and productively spend their time ensuring citations on the site are accurate.

All the {{failed verification}} template does is notify other editors that a citation has been identified as problematic and needs to be fixed. However, for apparently 'good' citations that lack the {{failed verification}} tag, there is still no way for an editor or reader to have much confidence (aside from blind WP:AGF) that the content of an article is actually supported by the claim. For all the reader knows, if they looked into it more closely, the citation is actually in reality a hidden {{failed verification}}.

To be quite honest I'm quite surprised at the resistance to the idea. It seems to me manifestly obvious that it would be beneficial for the community to have some way to keep track of which citations on this website are good-quality citations, and which of them are potentially suspect. It would be particularly useful productivity tool for countering the malicious efforts of WP:LTA users.

I especially don't understand the resistance given that this would be an optional parameter anyway. The only compelling argument I've seen against the idea (to my mind so far) has been David Eppstein's suggestion that the citation template is already too complicated for new users. Personally I disagree that should be the overriding concern and don't think this would cross that threshold... but I think its a fair argument. Most of the other arguments in the thread seem to doubt that this would have any utility at all, which I find quite puzzling.

It seems to me quite obvious that it would be useful for us to have some sort of tool to keep track of article prose that has been identified as being actually supported by reference. At the moment there are very few tools available to productively improve the state of WP:VERIFY across the site, or identify where the best places are to spend one's efforts in that regard. If I go about checking the citations in an article right now; for all I know that could be wasted effort because another editor has already done that for me. It would be a waste of time, and I wouldn't know, and I would be demotivated from checking verifications in future; drawn into a false sense of security. Jack4576 (talk) 15:03, 27 August 2023 (UTC)

There are thousands of editors in good standing, so no way fo knowing if the id attached to the verification is of any use. Ultimately the verification by another editor is not reliable, as editors of Wikipedia are not reliable sources. Only the continue improvement of the encyclopedia will bring about an increase in its reliability. Find an article, checking its sources, improve the article, move on.

As a more general point to this discussion, this is the talk page of cs1 template, and cs1 templates are wikitext. So anyone can change them to appear anyway they want. Adding in verification by editors that can't be spoofed in someway would require changes to mediawiki bested discussed at WP:VPT. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:29, 27 August 2023 (UTC)

the point is more that if a particular editor is identified as problematic; then all their work can be quickly searched for and scrutinised. Usually the approach would be AGF for most verifications Jack4576 (talk) 23:55, 27 August 2023 (UTC)

But a sock puppet could create multiple accounts and verify text with the username of a different editor in good standing, again this is only wikitext unless you change the wikimedia software (which this ain't the page for). Then unless all the sock puppet accounts are identified, and their edits undone, it appears as if a respectable editor verified the content. You would only be able to see this wasn't the case by verifying the verification, which is just nonsense.

Even if all that was solved it would still be a bad idea, as you shouldn't accept other editors verification only your own. If you feel the content is dubious you should check it, regardless of what other editors say. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 00:15, 28 August 2023 (UTC)

We already have processes in place to target sock-puppetry and they're relatively effective. For this reason I don't find your argument here particularly compelling. Sockpuppet contributions often come under close scrutiny once identified, and this would be no different

Of course once should check claims when they're being relied upon for an important matter, but the utility of an encyclopedia is to summarise information without requiring a click-through to every source. For the lay-user, this provides significant utility. A reference verification process brings us a step closer to the ideal state whereby most information on this site is well-referenced Jack4576 (talk) 03:35, 28 August 2023 (UTC)

The idea that our sock puppet processes catch all the sock puppets is something that fails verification. The idea that this would improve the encyclopedia is just completely wrong, as many others have now said. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:04, 28 August 2023 (UTC)

Could not disagree more strongly, we’re at an impasse Jack4576 (talk) 10:42, 28 August 2023 (UTC)

Not really an impasse as Wikipedia is built on consenus, and this discussion appears to have an obvious one. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:06, 28 August 2023 (UTC)

??? I’m talking about our discussion, not the consensus more generally. Agree that the majority seems to be closed-minded about this proposal.

Impasse is a fairly commonly used word when engaging in intellectual discussion involving civil disagreement. Jack4576 (talk) 13:12, 28 August 2023 (UTC)

Yes I fully, fully understood what you meant, and when everone else disagrees with you maybe you're closed minded to their points. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:51, 28 August 2023 (UTC)

Being at an impasse doesn’t necessarily mean anyone is being close-minded, good faith disagreement is possible. This comment feels pretty rude. Not replying to you anymore. Jack4576 (talk) 21:13, 28 August 2023 (UTC)

Ok -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:53, 28 August 2023 (UTC)

Also I never mentioned closed minded in relation to an impasse. You mentioned closed-minded in relation to most editors disagreeing with you. My point was that brushing off other editors concerns in such a manner could be seen as closed minded in itself. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:57, 28 August 2023 (UTC)

While at heart the ethos of the site is "Wikipedia is not a reliable source; if something seems sus, check the source" and not "trust Wikipedia because Wikipedia says to trust it", I don't think the idea of keeping track of who has checked a citation and whether they thought it supports the claim it's cited to is fundamentally flawed; it just shouldn't supplant people putting in the work themselves to reach their own informed conclusion. Judging by how RSP is treated, this is exactly what would happen.

To bang on a different hobbyhorse I recently found at VPI and ran with, if we had a centralised storage location for citation information, this sort of thing could be kept track of there, in a form holding article, claim, and verifying editor, which would involve a lot of copypasting prose, but could let people see at a glance how many times a citation had been verified and what prose sentences are using the source as support (which would help when the article language gets changed around without updating the citation). That's enough of that sidebar though.

I think my point might be that people are always eager to do less work, even if that means putting too much trust into flawed humans, flawed code, or flawed processes. Yes, if something like this were implemented and I saw the username of an editor I personally trusted in a topic area I knew them to be proficient in, I probably wouldn't reverify the citation against the claim and might save some time. But in the large scheme it would be removing an important safeguard in that if a citation seems suspect, editors should check the source. That's the heart of WP:V. I don't want to go all slippy-slope about it, and I wouldn't bring a standalone {{Passed verification}} template to TfD, but once it becomes a process, I just see the tradeoff of editor time for misplaced trust as not worth it for a high-quality encyclopaedia. Folly Mox (talk) 16:46, 27 August 2023 (UTC)

(The irony is that {{passed verification}} was TFDd a decade ago for all the same reasons raised in this discussion.) Izno (talk) 21:15, 27 August 2023 (UTC)

If we made verification work easier to undertake, (less duplication of effort), the quality of the encyclopaedia would be higher. To me that’s the overriding concern, rather than the risk of occasionally leading someone into a slightly heightened sense of security than is the status quo.

Regardless, thanks for sharing your prior village pump proposal I think it’s a great one and would have an interest in supporting it again if raised in future Jack4576 (talk) 00:00, 28 August 2023 (UTC)

If we could trust Wikipedia editors to all use sources properly, we would not need this tag. If we cannot trust Wikipedia editors to all use sources properly, we cannot trust them to use a verified tag properly, and duplication of effort cannot be avoided. In either case, it does not help. —David Eppstein (talk) 00:47, 28 August 2023 (UTC)

Respectfully David I don't think that follows. If trustworthy editors use a verified tag, and sign their own name through the 'verified by' parameter; then we have a verification system that we can rely upon with greater confidence than unsigned bare references.

Whilst duplication of effort cannot be avoided entirely, the ability to mark out work as having already been undertaken would nevertheless be a significant productivity increase in enough circumstances to more than justify an optional parameter IMO. YMMV. Jack4576 (talk) 02:25, 28 August 2023 (UTC)

No, we should not clog up reference sections with visible reviewer names. That is even worse than a meaningless checkbox. —David Eppstein (talk) 04:55, 28 August 2023 (UTC)

I fail to see how merely adding "verified by: username" would 'clog up' the references appearing within a section (especially given that references already have numerous parameters anyway) but if that's your view, then fair enough. I'm not going to argue aesthetics Jack4576 (talk) 05:05, 28 August 2023 (UTC)

It is not aesthetics, it is usability. References are there to provide references to readers. They are already overclogged with MUMBO 102938 JUMBO 120987 identifiers that neither provide the text of the reference to readers nor provide useful information on how to find it. Clogging them more by adding "Verified by Jack4576" is aimed only at editors, not readers, who will (like me and most editors) have no idea who Jack4576 is, what it means to be verified, or why Jack4576's opinion on the validity of the reference should be trusted. Adding extra unhelpful text makes it harder for readers to find the useful parts of the reference, and will only serve to confuse the people who see it but don't know why it is there.

As for the people who do know why it is there: the people who are already pacified by seeing lots of little clicky blue numbers, without actually verifying that the references verify anything, will continue to be pacified by seeing lots of clicky blue numbers with lots of verification stamps, without actually having any idea whether the verification stamps verify anything. That is to say, it will be an attention-wasting placebo. We already have that in the clicky blue numbers. We don't need more of it. —David Eppstein (talk) 05:21, 28 August 2023 (UTC)

+1 on David Eppstein. Pointless duplication of information: metadata about the content belongs in the history of the page. More useful would be to have easy links to the history to identify who added a reference etc. The mw:Who Wrote That? project is focused on this goal, did you try it? How does it work for references? Once people can more easily explore dubious references, maybe the next step would be a simplified interface to add and handle {{failed verification}} tags and similar. Nemo 08:46, 28 August 2023 (UTC)

It’s not metadata about the content though, it’s metadata about the particular reference supporting the content

The failed verification tag is indeed an incredibly useful template, but it is difficult for editors to decide where best to direct their efforts. For all they know, the citation they are scrutinising has already been examined closely by a trustworthy editor. They could be wasting their time Jack4576 (talk) 10:41, 28 August 2023 (UTC)

I think this is the juncture where I just want to agree to disagree. I don't see any activity that helps maintain a healthy skepticism towards what is written on Wikipedia as a waste of time. We should be double checking each other's work if we're operating in our areas of competency. We should be reading our sources' direct statements to make sure they're being accurately summarised in our prose.

Even if it turns out that everything is fine in the article and supported by the source, we're still exercising those critical muscles. It may not result in an edit that improves the encyclopaedia this time, but it helps us stay in the practice of due diligence and doing our own investigation. I don't think that's wasted effort, and I understand if you disagree. Folly Mox (talk) 13:33, 28 August 2023 (UTC)

I agree that that anything we can do to improve the integrity of our sourcing is a good thing, but it's a mug's game when any editor can alter the text without changing the sourcing accordingly and only those who have that article on their watchlist are likely to notice or even care. And that doesn't even take into account the scale of the issue with FA-quality articles often having over a hundred cites. Admittedly, the quantity of cites sharply declines in most of the rest of the articles on Wiki, but stretched over 7-odd million articles that's still a number that no volunteer group like ours can handle. I applaud anyone who actually enjoys verifying cites, but I much prefer generating them from the books and journals spread out in front of me and on my monitors.--Sturmvogel 66 (talk) 15:55, 28 August 2023 (UTC)

• Not like this. This concept is "nanopublication"

Yes, I think Wikipedia will adopt this practice eventually. No, not like described above. The key detail missing here is FAIR data or machine readability, because at Wikipedia's scale only AI verification makes sense. Fact-checking of the sort described above also needs to be multilingual, so using machines is the only option to fact check once then get verification in 100 language translations, while also watching for word changes in each. Outside of wiki there is a discourse about this, see the 2010 The anatomy of a nanopublication (Q57011346). The established idea is to deconstruct sources to claims, have an identifier for each claim, then deploy bots to automatically verify reuse of those claims in other contexts. The reason why the world is not ready for this now is because we do not even have a metadata catalog, much less any log of 100-1000 claims per item in such a catalog. The Wikimedia entry point for anyone interested in this is d:Wikidata:WikiCite or meta:WikiCite. Parts of this, unrelated to WikiCite but about AI checking, are at mw:Machine_Learning/Modernization#Lift_Wing which is the successor to Wikitech:ORES. Lift Wing needs community documentation and comment because it raises countless social and ethical issues. All the AI tools coming out need community ethical review.

Bluerasberry (talk) 16:48, 28 August 2023 (UTC)

Love this, and would support it if proposed in future. I agree that perhaps only AI is possible to resolve all of the nano-publications at-scale; however I think it’s inevitable that human verification will inevitably form at least some part of the process.

Either way, bottom line is we need a way to ensure that effort isn’t needlessly duplicated, whether (1) because we don’t want a machine to be redundantly checking over the same citation, or (2) a human doing so as described above; excepting for times when they’re doing so intentionally. (who watches the watchers -> who’s verifying the verifiers) yada yada

Thanks Bluerasberry Jack4576 (talk) 21:21, 28 August 2023 (UTC)

Generational suffix triggers CS1 maint error

I ran into a false positive for the "multiple names: authors list" error for the name "Fernando Alfonso III". My understanding (supported by this archived topic) was we put the Jr./Sr./III/etc. into |first= in the cite templates, like "|first1=Fernando, III last1=Alfonso". The reference to MOS:JR on Template:Cite web/doc is confusing, though, because that seems to apply specifically to body text and not reference parameters.

• {{Cite news |last1=Alfonso |first1=Fernando, III |date=January 6, 2021 |url=https://edition.cnn.com/politics/live-news/congress-electoral-college-vote-count-2021/ |title=Congress finalizes Biden's win after riot disrupts Capitol |website=CNN }}
• Alfonso, Fernando, III (January 6, 2021). "Congress finalizes Biden's win after riot disrupts Capitol". CNN.{{cite news}}: CS1 maint: multiple names: authors list (link)

My suggestions:

• We agree if/that a consensus exists for "First, III" or "First III" on template parameters.
• We update the cite news/cite web template documentation to include clearer language on Sr./Jr./III accordingly.
• If the consensus is pro-comma, we add a check to the "multiple names: authors list" so it doesn't fire on generational suffixes.

Thanks.-Ich (talk) 11:20, 29 August 2023 (UTC)

I think the issue here is the guidance at MOS:JR. There shouldn't be a comma involved, which is why the maintenance message is being generated, but MOS:JR doesn't make clear whether the listing should be "Alfonso, Fernando III" or "Alfonso III, Fernando". I've seen both being used in articles fairly evenly. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:49, 29 August 2023 (UTC)

Are you sure? MOS:JR says: When the surname is shown first, the suffix follows the given name. It then goes on to say Do not place a comma before a Roman numeral name suffix. Jr, Sr, III are suffixes all explicitly mentioned as suffixes in MOSJR.

—Trappist the monk (talk) 13:17, 29 August 2023 (UTC)

My point was that MOS:JR gives a very clear example in Kennedy, John F. Jr. of how Jr and Sr should be used in a listing, but the example Otis D. Wright II doesn't make clear how the name should look in a listing with a Roman numeral suffix. I've seen many "Wright II, Otis D." examples in articles, so something isn't clear enough. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:58, 29 August 2023 (UTC)

I don't find it unclear but if you do: WP:FIXIT or discuss at WT:MOSBIO.

—Trappist the monk (talk) 15:12, 29 August 2023 (UTC)

I have consolidated the possibly confusing separate notes about "Jr." and "II" at MOS:JR. I hope that is clearer for Ich. – Jonesey95 (talk) 16:13, 29 August 2023 (UTC)

I think you can also embed the problem data in ((double parentheses)) to suppress the maintenance category, in case there's a particular format you'd like to cite the name. Folly Mox (talk) 12:42, 29 August 2023 (UTC)

Please don't abuse the accept-as-written markup to violate MOS.

—Trappist the monk (talk) 13:17, 29 August 2023 (UTC)

Yes, don't do the thing I suggested, which is supposed to be for cases of corporate authorship. I didn't do the research and took the first two comments about unclear guidance as being factual. Thanks Trappist for the correction 🙏🏽 Folly Mox (talk) 14:12, 29 August 2023 (UTC)

Some history:

• Help talk:Citation Style 1/Archive 60 § Format for author name suffixes?
• Help talk:Citation Style 1/Archive 77 § Suffixes?
• Help talk:Citation Style 1/Archive 87 § Suffixes in names
• Help talk:Citation Style 1/Archive 88 § multiple names in |first=
  • Wikipedia:Village pump (technical)/Archive 206 § Can I get a list of cite web templates that probably have excessive numbers of authors in the fields?

Regardless of any perception that MOS:JR applies only to body text, cs1|2 specifically aligns itself with the rules stated there which makes |first1=Fernando III (without the comma) the correct format. If you believe that the cs1|2 documentation can be improved, please do so. If you believe that MOS:JR should be constrained to body-text only, discuss at WT:MOSBIO.

—Trappist the monk (talk) 13:17, 29 August 2023 (UTC)

Thanks for the response and links; I didn't find all the relevant topics when I searched. I'm happy to use the "no comma" style in ref parameters going forward.-Ich (talk) 16:37, 29 August 2023 (UTC)