Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

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 ‹The template Category link is being considered for merging.› 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)

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 ‹The template Category link is being considered for merging.› 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:

• ‹The template Category link is being considered for merging.› Category:CS1 maint: location missing publisher
• ‹The template Category link is being considered for merging.› 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)

|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)

"Latin" Language Name Issue When Porting to other wiki

I have ported over the citation and language templates for use on another MediaWiki wiki. It all seems to be working well with the strange (and very specific) exception of the ISO 639-1 name that the CS1 citation template pulls for the "la" language code (Latin) returns "Latina" instead of "Latin". This causes the Category:CS1 Latin-language sources (la) that is generated on the article page contains an of the citations tagged with the "la" language code to be incorrect (it generates "Category:CS1 Latina-language sources (la)"). The Template:Citation Style documentation/language/doc on my wiki returns everything fine as well with the singular exception of "Latin" which also returns "Latina". Does anyone know how or where to fix this? I have re-ported over all the templates and modules that make up the various citation components, as well as all the ISO templates and modules, but I can't find where or how it is converting "Latin" to "Latina". – Lestatdelc (talk) 22:38, 13 August 2023 (UTC)

Which wiki? If, at en.wiki, you write {{#language:la|xx}} (where xx is the 2-or-3-digit language tag for the other wiki's language), MediaWiki should return that language's name for Latin. You can also try, at the other wiki, {{#language:la}}. If either test returns 'Latina' then the problem is at MediaWiki and perhaps further upstream at Unicode CLDR.

Certainly fixable locally though it would be best to make the fix at MediaWiki.

—Trappist the monk (talk) 22:57, 13 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)

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)

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)

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)

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)

[1] 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)

Recognize free DOI prefixes

See also: User talk:Citation bot/Archive 36 § More open access DOIs

Several DOIs can be known to be free from their DOI prefix. While we could autoflag them as free, a better practice, IMO, would be to have Category: CS1 maint: Unflagged free DOI (or similar), that would populate when we have a DOI prefix match, and when |doi-access=free is not set. This way we would have a category against which to run User:Citation bot (similar to Category:CS1 errors: DOI, or Category:CS1 maint: PMC format). Because right now, we need to collect all articles with DOI match (about 30,000 articles), but have no good way of excluding articles where their free DOIs have already been flagged, leading to a lot of wasted bot processing time.

10\.(1100|1155|1186|1371|1629|1989|1999|2147|2196|3285|3389|3390|3410|3748|3814|3847|3897|4061|4089|4103|4172|4175|4236|4239|4240|4251|4252|4253|4254|4291|4292|4329|4330|4331|5194|5306|5312|5313|5314|5315|5316|5317|5318|5319|5320|5321|5334|5402|5409|5410|5411|5412|5492|5493|5494|5495|5496|5497|5498|5499|5500|5501|5527|5528|5662|6064|6219|7167|7217|7287|7482|7490|7554|7717|7766|11131|11569|11647|11648|12688|12703|12715|12998|13105|14293|14303|15215|15412|15560|16995|17645|19080|19173|20944|21037|21468|21767|22261|22459|24105|24196|24966|26775|30845|32545|35711|35712|35713|35995|36648|37126|37532|37871|47128|47622|47959|52437|52975|53288|54081|54947|55667|55914|57009|58647|59081)

will match the currently known garanteed-to-be-free DOI prefixes. The list could be expanded as more are discovered (and likely externalized for ease of maintenance). Headbomb {t · c · p · b} 04:53, 18 August 2023 (UTC)

This shouldn't be very hard to implement. Any news on this? Headbomb {t · c · p · b} 23:12, 1 September 2023 (UTC)

{{cite book/new |title=Title |doi=10.1100/sommat}}

Title. doi:10.1100/sommat.{{cite book}}: CS1 maint: unflagged free DOI (link)

{{cite book/new |title=Title |doi=10.1100/sommat |doi-access=free}}

Title. doi:10.1100/sommat.

—Trappist the monk (talk) 13:38, 2 September 2023 (UTC)

Given the intent is to run a bot against this, can we adjust this to emit a properties category without message instead? Izno (talk) 17:58, 12 September 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.wikipedia.org/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 [[2]] 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)

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)

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 ‹The template Category link is being considered for merging.› Category:CS1 Kazakh-language sources (kk) to ‹The template Category link is being considered for merging.› 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 ‹The template Category link is being considered for merging.› 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)

simple.wikipedia.org

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)

date format maintenance

I was going to fix the articles in ‹The template Category link is being considered for merging.› 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)

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.wikipedia.org) 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.wikipedia.org/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)

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 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-0000007D-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.wikipedia.org%3AHelp+talk%3ACitation+Style+1" 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)

Category:CS1 maint: numeric names: authors list

I'd like to bump this series up to an error. The non-authors categories are routinely at 0 and the authors category is in the realm of 1k currently but also being poked at (by a couple people).

Are there any concerns with that? Izno (talk) 22:31, 25 August 2023 (UTC)

@Izno: No concerns, but are there patterns that a bot could fix before bumping to an error? GoingBatty (talk) 02:22, 26 August 2023 (UTC)

There's a couple patterns in this group, but I don't think any are particularly suitable to a bot:

1. Users using dashes instead of |author-mask= or |display-authors=.
2. Citoid doing a bad job (usually because it has a bad Zotero translator) getting info from news websites and dumping blobs into the author group that shouldn't be there, usually dates of publication or ID numbers.
3. Citoid getting bad data from Worldcat/OCLC, which likes to add the years of birth/death to author information and Citoid doesn't know how to plop those in (it shouldn't).

The second case can have bugs filed upstream on Phab which usually make their way over to Zotero's collection.

The third case might be something to file a bug on Phab for. These are probably the easiest for a bot to ID, because they most often have a |url= that duplicates the |oclc=. I think I might prefer a human to clean these up anyway because they sometimes have the Category:CS1 maint: others issue as well (though that seems to have improved given the size of that category has not increased significantly in a while, so maybe a bot running over that one to get citation data again from Citoid would be a good idea -- Citation bot might already have the right stuff to do something there).

For the first group, a bot won't have the context to know which is the correct fix. Izno (talk) 02:35, 26 August 2023 (UTC)

Ah, the fourth case is {{cite Twitter}} and similar where the only identifiable author information is/includes a number. The correct fix for which is the (()) syntax (or building that in to the template). Trappist was working on that at one point but seems to have dropped it? Izno (talk) 02:42, 26 August 2023 (UTC)

That would be this discussion. I offered a possible solution. I do not get the sense that other editors cared enough to use that possible solution as a remedy for the problem – the conversation died from lack of participation (indifference) as so many do.

—Trappist the monk (talk) 14:09, 26 August 2023 (UTC)

I would love to see this elevated to error status as previously disclosed. Mobile users are not able to see error maintenance messages. This will allow me to help clean out the category, which I've touched briefly before but had to peruse the full source to find the problem citations. Folly Mox (talk) 12:48, 26 August 2023 (UTC) corrected 14:45, 26 August 2023 (UTC)

If Mobile users are not able to see error messages changing maintenance messaging to error messaging will not benefit them. Are you sure that mobile users cannot see error messages?

—Trappist the monk (talk) 14:09, 26 August 2023 (UTC)

Sorry I misspoke. I meant mobile users are unable to see maintenance messages. My space is extremely distracting today. Folly Mox (talk) 14:44, 26 August 2023 (UTC)

Just for clarity, and as a mobile users, yes they can. The mobile view won't show them, but that's the least of its problems. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:52, 26 August 2023 (UTC)

If we do this, all of the numeric names messaging and categories would shift to error messages:

Category:CS1 maint: numeric names: authors list (58,310)

Category:CS1 maint: numeric names: contributors list (0)

Category:CS1 maint: numeric names: editors list (20)

Category:CS1 maint: numeric names: interviewers list (1)

Category:CS1 maint: numeric names: translators list (2)

I support that.

—Trappist the monk (talk) 14:09, 26 August 2023 (UTC)

Made the minimal adjustment in the sandbox, feel free to adjust emitted error text or category name.

Cite book comparison

Wikitext	{{cite book|author=1234|title=Title}}
Live	1234. Title. {{cite book}}: |author= has numeric name (help)
Sandbox	1234. Title. {{cite book}}: |author= has numeric name (help)

Cite book comparison

Wikitext	{{cite book|editor=1234|title=Title}}
Live	1234 (ed.). Title. {{cite book}}: |editor= has numeric name (help)
Sandbox	1234 (ed.). Title. {{cite book}}: |editor= has numeric name (help)

Cite book comparison

Wikitext	{{cite book|author2=1234|author3=5678|author=One|title=Title}}
Live	One; 1234; 5678. Title. {{cite book}}: |author2= has numeric name (help)
Sandbox	One; 1234; 5678. Title. {{cite book}}: |author2= has numeric name (help)

It would probably be nice if the number (editor number 5) could be in the error instead. I think there was some discussion of similar elsewhere for another error at some point?

Do we think we'll need a category for each kind of author going forward, with so few as we have now? Izno (talk) 20:22, 26 August 2023 (UTC)

History: Help talk:Citation Style 1/Archive 64 § Check author names are not numeric for Cite web

I suspect that I created separate name-list categories because we have separate name-list maintenance categories for multiple-names-in-a-name-parameter.

I tweaked your change to specify a single category: ‹The template Category link is being considered for merging.› Category:CS1 errors: numeric name. Also tweaked the error messaging so that it is roughly the same as the generic name message (one message per template that names the offending parameter). Is that what you meant by [it] would probably be nice if the number (editor number 5) could be in the error instead?

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

Since most of these errors are going to be generated from Citoid putting dates into author fields, I wonder if a better message might be numeric data in |author=. Folly Mox (talk) 22:17, 26 August 2023 (UTC)

The issue is not some numbers in the field (which is not presently detected), it's all non-numeric-characters in the field. Izno (talk) 22:20, 26 August 2023 (UTC)

Oh I was under the impression that any numeric data would add the article to the appropriate maintenance → error category. My mistake. Folly Mox (talk) 22:39, 26 August 2023 (UTC)

I would prefer something closer to the previous suggested text displayed, since it's not numerics that are detected but non-alphabetic characters (which include punctuation and other symbols). The category name is pretty irrelevant to me otherwise.

But yes, the error messaging naming the offending parameter is what I had in mind, as you've now added. Izno (talk) 22:23, 26 August 2023 (UTC)

I got to wondering about numbers-in-names. Here are a some searches (in these the search expects alphabetic characters to precede numbers):

|author<n>= and |last<n>=: ~6700 times out

|contributor<n>=, |contributor-last<n>=: no results timed out

|editor<n>=, |editor-last<n>=: ~240 times out

|interviewer<n>=, |interviewer-last<n>=: ~10 times out

|translator<n>=, |translator-last<n>=: ~300 times out

Here is another with numbers preceding alphabetic characters:

|author<n>= and |last<n>=: ~1100 times out

There are false positives in these searches because cs1|2 templates are not the only ones to use |author=, |editor=, |last=, etc.

Still, it might be worthwhile to retain the CS1 maint: numeric names <name> list categories. Because we are already looking at names in the name-holding parameters, adding a couple of test isn't too much extra work.

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

So I hacked the sandbox. Here are two templates from the author search:

Cite book comparison

Wikitext	{{cite book|edition=6th|first=Frank P. 1 David P. 2 Theodore L. 3 Adrienne S. 4|isbn=9780471457282|language=English|last=Incropera 1 Dewitt 2 Bergman 3 Lavigne 4|location=Hoboken, NJ|oclc=62532755|pages=941–950|publisher=John Wiley and Sons, Inc.|title=Fundamentals of heat and mass transfer.|url=https://www.worldcat.org/oclc/62532755|year=2007}}
Live	Incropera 1 Dewitt 2 Bergman 3 Lavigne 4, Frank P. 1 David P. 2 Theodore L. 3 Adrienne S. 4 (2007). Fundamentals of heat and mass transfer (6th ed.). Hoboken, NJ: John Wiley and Sons, Inc. pp. 941–950. ISBN 9780471457282. OCLC 62532755.{{cite book}}: CS1 maint: numeric names: authors list (link)
Sandbox	Incropera 1 Dewitt 2 Bergman 3 Lavigne 4, Frank P. 1 David P. 2 Theodore L. 3 Adrienne S. 4 (2007). Fundamentals of heat and mass transfer (6th ed.). Hoboken, NJ: John Wiley and Sons, Inc. pp. 941–950. ISBN 9780471457282. OCLC 62532755.{{cite book}}: CS1 maint: numeric names: authors list (link)

Cite web comparison

Wikitext	{{cite web|access-date=2021-10-05|first1=Carter|first2=KSL com | Updated-|first3=2021 at 11:04 a m | Posted-|first4=2021 at 6:07|language=en|last1=Williams|last2=July 2|last3=July 1|last4=P.m|title=Rare wolverine sighting in Layton may be same animal spotted in May|url=https://www.ksl.com/article/50197410/rare-wolverine-sighting-in-layton-may-be-same-animal-spotted-in-may|website=www.ksl.com}}
Live	Williams, Carter; July 2, KSL com | Updated-; July 1, 2021 at 11:04 a m | Posted-; P.m, 2021 at 6:07. "Rare wolverine sighting in Layton may be same animal spotted in May". www.ksl.com. Retrieved 2021-10-05.{{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)
Sandbox	Williams, Carter; July 2, KSL com | Updated-; July 1, 2021 at 11:04 a m | Posted-; P.m, 2021 at 6:07. "Rare wolverine sighting in Layton may be same animal spotted in May". www.ksl.com. Retrieved 2021-10-05.{{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

Keep? Discard?

—Trappist the monk (talk) 21:52, 28 August 2023 (UTC)

I'd say keep for now. Izno (talk) 22:30, 30 August 2023 (UTC)

Sorting drafts to back of categories

I think in the general users working on errors and maintenance categories tend to avoid draft space as they're obviously not in mainspace (and perhaps for some, they don't want to reset the 6 month clock). In another discussion, someone identified that some templates categorize their drafts to the Δ key (still with ABC order), which places it (on en.wp at least) at the back of the category list. I'd like to suggest that CS1 do this also. Izno (talk) 22:36, 25 August 2023 (UTC)

@Izno: Support for categories with more than 200 pages. Don't know if it's worth it for categories that are well maintained. GoingBatty (talk) 02:21, 26 August 2023 (UTC)

I think it's much less worth to make the code depend on the size of the category. :) Izno (talk) 02:25, 26 August 2023 (UTC)

@Izno: Sorry - I wasn't suggesting implementing code that looks at the number of pages in the category. I was suggesting not implementing any new code on categories that currently less than 200 pages. GoingBatty (talk) 15:52, 29 August 2023 (UTC)

So, Lua can't read category sizes (last I checked). All we could have done would have been to make a lookup table, or add a bunch of parameters to the relevant section of the code that support a bunch of carveouts. Or we can just implement it for everything. Everything makes a lot more sense. :) Izno (talk) 16:22, 29 August 2023 (UTC)

This would have been extremely useful when I was clearing down cite errors back in 2021. I would have thought the same is true of all other error or maintenance categories. It would probably be good to not just sort drafts but also the other name spaces, Template / Wikipedia / User / etc. Also I'd still be interested to see the change at testwiki that was mentioned in the now archived VPT thread. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:06, 26 August 2023 (UTC)

According to Wikipedia:Categorization § Sort keys, Δ is reserved for Wikipedia:Template documentation 'by convention'. Seems odd to me for en.wiki to use characters from another wiki language (el.wiki) as sort keys. Because cs1|2 is supported at el.wiki, I don't think that we should use Greek letters as sort keys. Are there symbols that we could use instead? I thought we might use the sun and planet symbols (☉ Sun, ☿ Mercury, ♀ Venus, 🜨 Earth, ♂ Mars, ♃ Jupiter, ♄ Saturn, ⛢ or ♅ Uranus, ♆ Neptune, ♇ Pluto) but when I tried ♇ at {{CS1 config}} as an experiment, the template was categorized at the top of the list at ‹The template Category link is being considered for merging.› Category:Templates with no visible output. We don't need many. I think that draft, template, and Wikipedia are the most common namespaces that use cs1|2 templates. All other supported namespaces could be grouped with a common sort key.

—Trappist the monk (talk) 14:50, 26 August 2023 (UTC)

From other tracking categories I assume symbols are sorted before numbers and letters, with only the special characters mentioned by Sort Keys sorted afterwards. See Category:Pages with incorrect ref formatting for example. If the special characters aren't usable due to elwiki crossover would a separate tracking categories for articles and non-articles work instead? -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:04, 26 August 2023 (UTC)

I don't think I've seen template documentation sorted to Delta, ever. Almost always it has only one category (Category:Template documentation) in which it needs no sortkey. I'd actually be curious to see examples of template documentation which even have another category besides that one.

(Δ is of course inspired by Draft. As another example of using Greek letters, Τ is often used for templates in categories they shouldn't be in anyway.) Izno (talk) 15:52, 26 August 2023 (UTC)

I have hacked the module so that non-mainspace pages are sorted at the end. I used the Greek letters:

Δ (delta – draft)

τ (tau – template)

ω (omega – wikipedia)

ο (omicron – other)

It is hard to test this change so for the time being I have disabled the namespace categorization limit in the sandbox and tweaked the actual categorization link to be [[:Category:...]] instead of [[Category:...]]. When a sandbox template is rendered, the sort key is rendered as a wikilink at the end of the rendering (after the error/maintenance messages):

{{cite book/new |title=Title |date=27 Augst 2023 |authors=EB Green}}

Title. 27 Augst 2023. {{cite book}}: Check date values in: |date= (help); Unknown parameter |authors= ignored (help)

'"`UNIQ--templatestyles-000000BB-QINU`"'<cite class="citation book cs1">''Title''. 27 Augst 2023.</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.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Check date values in: <code class="cs1-code">&#124;date=</code> ([[Help:CS1 errors#bad_date|help]])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;authors=</code> ignored ([[Help:CS1 errors#parameter_ignored|help]])</span>

You can copy that example into a page at other namespaces, preview, and observe the result. We won't know if it really works until we make the change live.

—Trappist the monk (talk) 01:10, 28 August 2023 (UTC)

Why are there two wikilinked 'o' (i.e. 'oo') after the /new citations? Most maintenance/errors categories seem to emit those now. I'm guessing those might be omicrons, rather latin o's? Is this intended, or just a temporary thing? Headbomb {t · c · p · b} 16:20, 2 September 2023 (UTC)

On this page because it's in the help namespace, the character is an omicron and it is displayed with all error and maintenance categories rendered by the sandbox. I did write: It is hard to test this change so for the time being I have disabled the namespace categorization limit in the sandbox where for the time being can be read as 'temporary'.

—Trappist the monk (talk) 18:22, 2 September 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)

Lua script error fix

I discovered a flaw in the coding for |display-translators= when that parameter's value came from a {{cs1 config}} template. The flaw was the omission of a variable in a function call. Fixed in sandbox and live modules.

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

And sort of related: fixed a bug that caused the module to emit an error message that isn't intended to be emitted. The error message 'Invalid |cs1 config=3 ' occurred because the module did not remove the extraneous space characters between the parameter's assigned value and the closing }}: {{cs1 config |display-authors=3 }}. This was only an issue with |display-<name list>= parameters. |cs1 config= is an unsupported parameter name used as a flag to prevent the module from emitting an Invalid |display-authors=<n> (and the like) when <n> is equal to or greater than the number of names in the author name list when a global |display-<name list>= is controlling the name list display.

Fixed in sandbox and live modules.

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

improve global configuration handling

I have changed how the module sandbox handles global |display-authors=<n> when a cs1|2 template has |display-authors=etal. This change also applies to all of the other name list display parameters

The live module emits a maintenance message whenever a template has |display-authors=<anything>. The sandbox is more discriminating.

When a template has |display-authors=etal, there are other authors who are not named in the template so Module:Citation/CS1 should always add the 'et al.' static text. When the template lists more names than are specified by the global |display-authors=<n> (four named authors but global |display-authors=2 for example), the live template correctly renders two names with the 'et al.' static text and emits the overridden setting maintenance message. However, when the number of authors listed in the template is the same or fewer than the number specified by the global |display-authors=, the module correctly displays the author names but incorrectly omits the 'et al.' static text which makes it appear that there are no more authors associated with the cited work.

The sandbox remedies this. When the number of authors listed in a template that has |display-authors=etal is less-than-or-equal to the number of authors specified in the global |display-authors=, the module applies the 'et al.' static text. Examples comparing the live v. sandbox module renderings for all name lists are shown in this version of my sandbox.

—Trappist the monk (talk) 16:49, 31 August 2023 (UTC)

doi problem

I got this error message:

{{cite book}}: Check |doi= value (help)

after I added this doi to a cite book template in the article Metre:

doi=/10.6028/NBS.SP.447

If I click the doi in the rendered bibliography it downloads the pdf just as it should. The publisher is the National Institute of Standards and Technology. Jc3s5h (talk) 13:39, 1 September 2023 (UTC)

DOIs do not begin with a solidus. The error message is correct.

—Trappist the monk (talk) 13:43, 1 September 2023 (UTC)

Thanks, that fixed it. Jc3s5h (talk) 13:46, 1 September 2023 (UTC)

Archived talk page included in CS1 language tracking category

Heya, folks. I regularly check a CS1 tracking category (this one, if that matters) to look for pages with wrong language codes. Recently, I found out that the page Help talk:Citation Style 1/Archive 6 was also included in the category (and hundreds of others) because it uses the template {{Cite book/new}} with the language parameter set. I presume this happens because of a change made to Module:Citation/CS1/sandbox at some point, but I'm not competent enough to find or fix it, so I'd appreciate some help here. ArcticSeeress (talk) 22:21, 1 September 2023 (UTC)

The cause of that is that I have disabled the categorization limits in Module:Citation/CS1/sandbox for testing as described at Help talk:Citation Style 1 § Sorting drafts to back of categories. The proof of that is shown in these two examples:

{{cite book |title=Northern Sami |language=se}} – no category link in this rendering:

'"`UNIQ--templatestyles-000000D3-QINU`"'<cite class="citation book cs1 cs1-prop-foreign-lang-source">''Northern Sami'' (in Northern Sami).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Northern+Sami&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

{{cite book/new |title=Northern Sami |language=se}} – this rendering has a category link:

'"`UNIQ--templatestyles-000000D6-QINU`"'<cite class="citation book cs1 cs1-prop-foreign-lang-source">''Northern Sami'' (in Northern Sami).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Northern+Sami&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

The language categories are properties categories. Only maintenance and error categories use the Greek letter sort keys so perhaps I can suppress property categories without disturbing the error and maint cat test.

—Trappist the monk (talk) 22:53, 1 September 2023 (UTC)

Property category talk page suppression restored in the sandbox; error and maint cat talk page suppression remains disabled.

—Trappist the monk (talk) 23:46, 1 September 2023 (UTC)

How to handle website unavailable in some countries?

For a |url= where the website says thing like "this content is unavailable in your country", how should that be handled by our cite templates? None of the current combinations of |url-status= and |url-access= values seem to correctly work for this situation. My workaround is to mark the url as dead with a note. Perhaps a new value for |url-access= called "geographical" or something could be introduced. Or maybe I'm overlooking the solution. Suggestions? Jason Quinn (talk) 06:06, 3 September 2023 (UTC)

If it's accessible to someone then it should not be marked dead. As I'm in the UK I often have US sites unavailable to me due to GDPR. If I really want to see it, I'll switch my VPN on and pretend I'm in the US.

There are too many variables around the world for citations to catch every possibility, so we shouldn't worry about the geographical ones. Just the global ones e.g. pay walled sites that affect everyone. Nthep (talk) 09:19, 3 September 2023 (UTC)

|url-access=limited seems to have pretty broad scope. Could that work for this situation? Agree that the link should not be marked as dead. Folly Mox (talk) 13:06, 3 September 2023 (UTC)

It is not appropriate to mark these links as anything. (And this question really needs to be made clear in the documentation since we keep getting questions on it.) Izno (talk) 03:12, 4 September 2023 (UTC)

Publications with multiple months as their dates

Hello fellow Wikipedians - Can anyone comment on the proper way to cite publications that are dated as being two or more months? For instance, I would like to use the following as a citation:

https://www.fedbar.org/wp-content/uploads/2013/01/bookrev-janfeb13-pdf-1.pdf

which is from the January/February 2013 issue of a publication called The Federal Lawyer.

However, I can't figure out how to do this without generating an error. Any insights from anyone?

Thanks KConWiki (talk) 21:20, 4 September 2023 (UTC)

Use the format indicated in MOS:NUM, which in your case would be January–February 2013. The character between the months is an n-dash. Don't use the html entity &ndash; because that won't work with the citation templates. Jc3s5h (talk) 21:33, 4 September 2023 (UTC)

OK great, done - Thanks for your guidance on that. KConWiki (talk) 21:37, 4 September 2023 (UTC)

Citing translations

When citing a translation of a foreign work, should one supply |title=original and |trans-title=translation or only |title=translation? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:32, 6 September 2023 (UTC)

WP:SAYWHEREYOUGOTIT if your referencing the translation use |title=translation -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:42, 6 September 2023 (UTC)

It seems to me both the title of the original and the title of the translation should be provided. This allows a reader to read the translation if the reader can find it. If not, the reader can, language skills permitting, read the original. Jc3s5h (talk) 20:46, 6 September 2023 (UTC)

I only use |trans-title= if I'm referencing the foreign original and want to give the reader some indication of what the title means.

I do like to provide the title of the original if I'm referencing a translated work, but I don't think any of the built in parameters is necessarily fit for this purpose. I've used |type= to hold this information in the past, but suspected it might be parameter misuse and started just adding "Translation of Non-English Title." after the closing curly brackets but before the closing ref tag. Folly Mox (talk) 21:08, 6 September 2023 (UTC)

Yeah that's not what |type= is for, adding it after the cite is a better idea. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:11, 6 September 2023 (UTC)

While we're on the subject, when a translation is an annotated, critical translation instead of just the regular type, is it better to credit the translator in the |editor= parameter? or leave them in |translator=? Folly Mox (talk) 21:30, 6 September 2023 (UTC)

Just as one person can appear as both author and editor in a compilation that includes some chapters authored by the editor, this case seems analogous imho, as that individual is both translator, and editor.

As far as Chatul's original question, the answer depends on whether you consulted the original foreign language version, or the English translation. As ActivelyDisinterested mentioned, you always say where you found it, and if that source is not in English, it's helpful to readers to add the |trans-title= parameter to give them the English version of the title. However, if you read a book in English translation, such as Beauvoir's The Second Sex, then there's no need to provide the original French title, mostly because it does not help WP:Verifiability, which is the whole reason we write citations in the first place, and it doesn't help English-speaking readers of Wikipedia, either. If you do wish to provide the original title, note that it won't fit either in parameter |title= (because param |title= is already taken by "The Second Sex") nor does it fit in |trans-title=, because that's *exclusively* for English titles of foreign works. So, where can you put it? The citation templates do not have a dedicated location for the original title of a work in a foreign language that you consulted in English translation, however, you could include it in |orig-date=, which is conceived to contain other information about an edition you did not consult. So, following the Beauvoir example, you could add: |orig-date=1st pub. [[Gallimard]]:1949 ''Le deuxième sexe''. Hope this helps, Mathglot (talk) 06:25, 7 September 2023 (UTC)

I follow the metadata the work provides. If all it says is "translator", into |others= it goes. If all it says is "editor", into |editor= it goes. In the case where the work lists them as both, I tend toward either placing it in both, or if I'm feeling lazy, solely in |editor=. Izno (talk) 20:58, 8 September 2023 (UTC)

East Asian name order

Most of my content work is in Chinese history, so I'm frequently citing works by Chinese authors. As is well known, in China the family name precedes the personal name, like Qiu Xigui.

When using the |last= and |first= parameters as usual, this causes names in citations to display like "Qiu, Xigui". While this isn't exactly wrong, it does look wrong, at least to me and many other people familiar with East Asian name order. Some English language scholars – even in the topic area – do format their bibliographical entries like this, but not as many as those who format names without the extraneous comma; some publications will ALLCAPS the family name for clarity, but I think this is recommended against here.

My usual solution to this is to put the full author name in the |author= parameter, but then I have to do extra work to get shortened footnotes to work, like |ref={{sfnref|Qiu|1999}}. Also I suspect this is suboptimal for COinS metadata.

I was thinking a new parameter like |name-separator=none could be a better solution, but I'm not sure how much work it would take to get it to apply dynamically to whichever contributor field it is supposed to. It would certainly be easy to add to existing citations without fiddling with |ref= and might benefit data reusers.

I was also wondering if this could be handled with |author1-mask=, and what the syntax for that would look like. Just the full author name?

What's the recommended practice for this, apart from "don't let it bother you"? Folly Mox (talk) 20:59, 6 September 2023 (UTC)

Publications specializing in Asian topics will typically use Qiu Xigui, etc in their bibliographies, but publications for a general audience often use a consistent marking of surnames and given names: "Qiu, Xigui" and "Smith, John". It could be argued that Wikipedia should be more like the latter category. Note also that bibliographies are already unusual: "Smith, John" isn't what you'd write in a sentence either.

However, I do find the parameter names |last= and |first= confusing, especially when working with a mix of Asian and Western author names. I find it less confusing to use the aliases |surname= and |given=. No change in the formatting, but at least the semantics is clear. Kanguole 22:01, 6 September 2023 (UTC)

(edit conflict)

Asian names in cs1|2 templates are problematic. In addition to the issue you describe, it is my understanding that when citing a person with an Asian name, the name should be written using the logograms because, apparently, it is not possible to accurately convert a transliteration, Qiu Xigui for example, to its logographic form(s): 裘锡圭 (zh-Hans) or 裘錫圭 (zh-Hant). Very often I see Asian names in cs1|2 templates written in |author= to 1) avoid the comma separator issue and 2) to include a logographic form: |author=Qiu Xigui (裘錫圭) (flipped order also).

I don't think that |name-separator=none is a solution because such a parameter would apply to all names in the list so a list of mixed Asian and western names would result in malformed western names. Such mixed lists are quite common, especially in STEM topics.

Format for using |author-mask= could be something like this:

{{cite book |title=Title |surname=Qiu |given=Xigui |author-mask=Qiu Xigui (裘錫圭)}}

Qiu Xigui (裘錫圭). Title.

'"`UNIQ--templatestyles-000000DB-QINU`"'<cite id="CITEREFQiu" class="citation book cs1">Qiu Xigui (裘錫圭). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Qiu&rft.aufirst=Xigui&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

I suppose that it might be possible to create |asian-surnamen=, |asian-givenn=, and |asian-authorn= parameters that would be rendered without the comma. I haven't given any thought to how this might be implemented. I suppose that in theory, when all three are present, |asian-authorn= would hold the author name in logogram form so cs1|2 could build an internal |author-mask= as shown above.

—Trappist the monk (talk) 22:17, 6 September 2023 (UTC)

that allows one to mix and match asian and non-asian in the same person. first=Frank asian-last=Wong. That is a recipie for confusion. Perhaps is-asian-name1=yes/no AManWithNoPlan (talk) 22:26, 6 September 2023 (UTC)

Oh yeah, I didn't mention below but I don't think a separate group of parameters for cultures where the family name is presented first is the solution here. Seems messy, and in addition to the case above we have authors of Asian descent who live and work in the West and have chosen to present their name in the Western order, so attaching an ethnic label to their name or not isn't something I'd want to get into. Folly Mox (talk) 22:34, 6 September 2023 (UTC)

Yeah my thought for |name-separator= was to have it be a group of parameters (|editor2-name-separator= etc.) to avoid the issue you mention. Apologies I failed to clarify that in the original post.

It is true that it's usually not possible to reconstruct the Chinese original from a pinyin transliteration, which is a lossy conversion. For this specific case we have an article on the individual so it's not necessary per MOS, but often it is important to include the actual words alongside transliterations, which I've also seen as |last=Qiu 裘|first=Xigui 錫圭. It sounds like the |-mask= series of parameters is the easiest way to implement what I'm looking for without messing with the underlying metadata. Folly Mox (talk) 22:31, 6 September 2023 (UTC)

I think the current author-mask solution/provision is appropriate if painful for people who really wish to style these a certain way.

Incidentally and personally, the only reason I put these in |author= is because I never know which name is given and which is family, with the large number of Americanized East-Asian names being in the same order as other American names typically are. Izno (talk) 20:55, 8 September 2023 (UTC)

Replacing “curly” quote marks with "typewriter" quote marks

Lines 478–479 of Module:Citation/CS1 read:

label = mw.ustring.gsub (label, '[“”]', '\"');
label = mw.ustring.gsub (label, '[‘’]', '\'');

and are intended to:

-- replace “” (U+201C & U+201D) with " (typewriter double quote mark)
-- replace ‘’ (U+2018 & U+2019) with ' (typewriter single quote mark)

in displaying chapter titles and the like, as far as I can tell.

Could someone explain why this is done, please? 0DF (talk) 00:50, 8 September 2023 (UTC)

To simplify the subsequent kerning patterns and because MOS:CURLY.

—Trappist the monk (talk) 00:56, 8 September 2023 (UTC)

@Trappist the monk: I was not aware of MOS:CURLY. Thanks for the explanation. 0DF (talk) 03:16, 8 September 2023 (UTC)

unicode v15.1 emoji

in Module:Citation/CS1/Configuration/sandbox, emoji_t has been updated to unicode v15.1 Newly added unicode code points are:

• U+2194 ↔ LEFT RIGHT ARROW
• U+2195 ↕ UP DOWN ARROW
• U+27A1 ➡ BLACK RIGHTWARDS ARROW
• U+1F4A5 💥 COLLISION SYMBOL
• U+1F7E9 🟩 LARGE GREEN SQUARE
• U+1F7EB 🟫 LARGE BROWN SQUARE
• U+1F9D2 🧒 CHILD

—Trappist the monk (talk) 18:12, 12 September 2023 (UTC)

Irish language

"Comhchoiste na Gaeilge, na Gaeltachta agus Phobal Labhartha na Gaeilge debate - Wednesday, 15 Jun 2022" [Joint Committee on The Irish Language, The Gaeltachts and the Use of Irish in Public]. Oireachtas.ie (in Irish). June 15, 2022.

"|language=ga" resolves as "in Ga". is that a bug, or an unwillingness to decide on the "gaelic"/"Irish language" debate? -Bogger (talk) 16:02, 13 September 2023 (UTC)

cs1|2 cannot distinguish between ga/Ga/GA/gA (the Ga language) and ga/Ga/GA/gA (the ISO 639-1 tag for Irish language) so defaults to language name. For Irish-language sources use |language=Irish; |language=Gaelic is accepted but is not recognized:

{{cite book |title=Title |language=Irish}} → Title (in Irish).

{{cite book |title=Title |language=Gaelic}} → Title (in Gaelic).{{cite book}}: CS1 maint: unrecognized language (link)

—Trappist the monk (talk) 16:24, 13 September 2023 (UTC)

There are hundreds of articles to be fixed.  Working... GoingBatty (talk) 18:11, 13 September 2023 (UTC)

@Trappist the monk: Now that I've updated over 100 articles, I'm wondering if there are any articles with citations with |language=ga that are supposed to represent the Ga language? The Ga language article doesn't use it. GoingBatty (talk) 02:24, 15 September 2023 (UTC)

@Trappist the monk: Found Yacub Addy which uses |language=gaa:

{{cite AV media |title=title |language=gaa}} → title (in Ga).

I've found a few articles where "ga" needed to be changed to "Galician", but none where "ga" meant the Ga language. GoingBatty (talk) 04:30, 15 September 2023 (UTC)

The language tag for Galician is gl. Not surprised that there aren't many Ga-language sources.

If you are interested, there is one other language-name/language-tag that can be confused:

ho is the language tag for Hiri Motu but that can be confused with the Ho language name (tag: hoc)

—Trappist the monk (talk) 14:39, 15 September 2023 (UTC)

Because our |language= documentation prefers language tags over language names, it occurs to me that Module:Citation/CS1 should presume that the value assigned to |language= is a language tag and not a two-character language name. So, I've switched the order of evaluation so that the module first assumes that |language= holds a tag and only when that fails, assume that |language= holds a language name:

Cite book comparison

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

Cite book comparison

Wikitext	{{cite book|language=ho|title=Title}}
Live	Title (in Hiri Motu).
Sandbox	Title (in Hiri Motu).

—Trappist the monk (talk) 17:29, 15 September 2023 (UTC)

How would you specify Ga as the language of the source if it works that way? -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:49, 15 September 2023 (UTC)

{{cite book |title=Title |language=gaa}} → Title (in Ga).

—Trappist the monk (talk) 19:51, 15 September 2023 (UTC)

Thanks Trappist. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:52, 15 September 2023 (UTC)

US state format/guidelines in location parameter

Are there guidelines regarding consistency of US state names used in |location= parameter? In Philippines, it previously used US state abbreviations for all its sources (example: |location=Berkeley, CA), but an editor several months ago changed most of them to avoid abbreviating the state names (|location=Berkeley, Calif.). What is the recommended format? Should I restore all state abbreviations or should I use their full names (|location=Berkeley, California)? Sanglahi86 (talk) 02:12, 15 September 2023 (UTC)

See MOS:POSTABBREV. Nikkimaria (talk) 02:22, 15 September 2023 (UTC)

Thank you for the information. Sanglahi86 (talk) 02:28, 15 September 2023 (UTC)

Language=de in "Ça plane pour moi"

Hi, I can't understand why language=de doesn't work in "Ça plane pour moi" (note 32, "Offiziellecharts.de – Plastic Bertrand – Ça plane pour moi". GfK Entertainment charts. Retrieved 15 February 2021).-- Carnby (talk) 20:08, 15 September 2023 (UTC)

Maybe because it's French?--Sturmvogel 66 (talk) 20:48, 15 September 2023 (UTC)

Because there is no citation template used there. I have added {{in lang}} to the "West Germany" entry in {{Single chart}}. I don't know if that will be accepted by the editors there, but it seemed like a nice thing to do for readers. – Jonesey95 (talk) 21:07, 15 September 2023 (UTC)

I've checked {{Single chart}}: apparently {{in lang|de}} works only if access-date is set before 2020.-- Carnby (talk) 21:14, 15 September 2023 (UTC)

@Jonesey95: Thank you. Could you please add it just after the title like in Austria or the Netherlands?--Carnby (talk) 21:20, 15 September 2023 (UTC)

Moved. Is it better now? – Jonesey95 (talk) 22:34, 15 September 2023 (UTC)

Adding a second archive url

Given the fact that sometimes Internet Archive will remove the archives of a webpage, amd that the whole Internet Archive enterprise may be in legal jeopardy, I was hoping it would be possible to add a second webarchive parameter. When I am creating a reference, I don't mind going to the trouble of creating an archive.today backup, and it seems good to have some redundancy so that archived links don't just disappear if IA ceases to exist. I think this would also imply a new parameter to track url archive status as well. -Furicorn (talk) 11:53, 16 September 2023 (UTC)

Clarifications on cite template usages and descriptions

I have a few questions about the templates, I would love to add these clarifications to the table, as well as to the text of the individual templates, as I can't imagine I'm the only one with these kinds of questions.

• {{Cite AV media}} - is this only for physical media? or does it also cover things like news broadcasts? Why does it exclude online videos? How does it differ from cite podcast? I know people can use cite web, but if you're citing a youtube video typically people aren't citing the comments
• {{Cite encyclopedia}} - is this also used for edited scholarly collections where each scholar provides a chapter? the description on the template makes it sound like it also includes those kinds of works, but I've historically used {{Cite book}} for a chapter in a book like that
• {{Cite interview}} - is this only for written interviews or does it also include video interviews?
• {{Cite technical report}} - can this description be specified a bit more, how does this differ from {{Cite report}}, seems to me govt bodies could def issue a technical report but I can't really tell from the current description
• {{Cite podcast}} - can a youtube channel be considered a podcast, since you can access a youtube channel via an RSS reader. Also why is this separate from {{Cite episode}}? It seems like they are both episodic content, and nowadays podcasts sometimes even have networks, or are distributed on the radio. I'm thinking a lot about online videos in the way we think about books, books get cited with the same template whether we found them online or physically, and I just wanted to maybe open a discussion about the proliferation of video media citations types.
• {{Cite episode}} vs {{Cite serial}} how would you choose one over the other, the difference here really confuses me.

Thanks! -Furicorn (talk) 12:28, 16 September 2023 (UTC)