Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

|url-status=

Of late there has been a bit of churn at Template:Citation Style documentation/url, likely due to discussion at User talk:Citation bot § Removing url-status = live.

To minimize the documentation churn, we should discuss here and then change the documentation.

You will note from the Citation bot discussion that there are those who believe that |url-status=<any legit value> should be allowed anytime and others who disagree (I am firmly in this latter camp).

The recent churn at the documentation template caused me to take a hard look at the documentation for |url-status= which, to me, has become a rather confusing mishmash so I propose to replace it with something like this:

• url-status: A control parameter to select one of |url= or |archive-url= to link |title=; requires url and archive-url. Use {{dead link}} to mark dead |url= when there is no |archive-url=.

  Accepts multiple keywords:

  • dead – (default when |url-status= omitted or empty) selects |archive-url=
  • live – selects |url=; used when |url= is preemptively archived
  • deviated – selects |archive-url=; used when |url= is still 'live' but no-longer supports the text in a Wikipedia article
  • unfit – selects |archive-url=; used when |url= links to porn, spam, advertising, or other unsuitable sites; links to |url= are suppressed in the rendering
  • usurped – selects |archive-url=; used when |url= links to information unrelated to the original link; links to |url= are suppressed in the rendering

The current version doesn't clearly state the purpose of the parameter so I started there and then rewrote, as a list, the various keyword definitions. I removed mention of maintenance messaging because that just adds to the mess (and if we discuss maint messages here, we'll end up discussing them everywhere... so more mess elsewhere.

Opinions?

—Trappist the monk (talk) 14:49, 29 September 2023 (UTC)

If we're going to require |archive-url= can we say requires |url= and |archive-url=? |archive-url= already requires |url=. I will say I don't really like the {{dead link}} alternate (no idea how common this is), since it requires navigating to the end of the template call, and typing in a date, rather than just adding a parameter wherever. I understand this is probably easier on a keyboard. Folly Mox (talk) 14:59, 29 September 2023 (UTC)

We could. I think that including |url= in the requirements more tightly binds the three parameters together as a unit and by doing so (perhaps) editors might be less likely to add stand-alone |url-status= to a citation (or not).

It is not in the cs1|2 remit to assume the duties and infrastructure of inline citation cleanup templates. Adding |url-status=dead to a cs1|2 template that doesn't have |archive-url= with value does not now add the article to an Articles with dead external links category and should not do so in the future; that is not the purpose of |url-status=dead (and wasn't the purpose of its predecessor |dead-url=yes). And you don't have to type the date... AnomieBOT will do that for you.

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

All right, I can manage a little extra effort if it's for best practices. Your explanation for the wording makes sense as well. Thanks. Folly Mox (talk) 19:10, 29 September 2023 (UTC)

Per Mike at Citation bot talk, archiveurl should not be required. Nikkimaria (talk) 03:11, 30 September 2023 (UTC)

Agree with everything Trappist the Monk said. It makes no sense for the CS1|2 template to mark dead links, and then other non-CS1|2 templates use {{dead link}}, plus square and bare URLs - it's a confusing mismatch of systems that will be prone to error eg. people using one system, or another system, or both systems. Then there is all the legacy issues. 100s of bots, reports, tools, etc.. are configured to do things as they are. It will lead to breakages, errors, that will take years to resolve and cause a lot of damage upstream eg. reFill will take decades to fix at current pace, and VE who knows. Then there is the user-base, literally millions of brains which have been hard-wired by 15+ years of doing things this way that need change, it's unnecessarily disruptive. Once you know how its done, it's not hard to follow or understand. -- GreenC 04:16, 30 September 2023 (UTC)

The only problem here is that |url-status= name causes confusion, which inturn leads to it being misused. The solution to that is not continued misuse. Clarification of how it should be used is definitely a step in the right direction. So inagre definitely agree with Trappist. Using {{dead links}} is a separate template the same as any other maintenance tag, citation needed, clarify, dubious for instance. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:23, 30 September 2023 (UTC)

Per Nikki's comment above, here's a version of what I posted at the bot's talk. I have two use cases, one for |url-status=dead and one for |url-status=live. This URL will quite possibly go out of date in months; a quarterly update at that website causes pages like this to be regenerated and the URL may change (it's difficult to predict whether or not it will change, for reasons I can explain if anyone cares). When I create a link to that URL, it's live and not deviated, but I know it's possibly going to go out of date so I always add the archiveURL when I can. I have also been putting in |url-status=dead, because otherwise someone reviewing the links is likely to mark it as live. (At a recent FAC source review a reviewer suggested marking one of these as live, not dead, for example.)

The use case for |url-status=live without archive-URL is when archive.org is down or refusing to archive, which happens fairly often. I try to always archive links when adding the citation; I think that's best practice. If I can't do the archive, then for the links I know are going to be stable long-term I add |url-status=live so that if someone else comes along and adds an archive URL it won't default to the archive link in the citation.

I understand that neither use case exactly fits the intended use of these parameters, but they are natural ways to use them. My main complaint about the bot having removed them is that they are not inaccurate (they don't lead to erroneous output HTML) and they don't incorrectly represent reality. A response at the other conversation was that they do lead to maintenance message output, but if these use cases are a natural way to interpret the parameters I don't think these parameter states should generate maintenance messages. What is the harm in allowing this usage? Mike Christie (talk - contribs - library) 12:03, 30 September 2023 (UTC)

I believe a lot of this comes from the fact that the parameter is named url-status, if it was renamed archive-url-switch or some other name this wouldn't be an issue (but that would require updating lots of other tools, so is a waste of resources).
Using url-status to mark dead links seems like a bad idea, as it doesn't generate any visible output, unlike {{dead links}} which creates a proper maintenance message. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:23, 30 September 2023 (UTC)

I agree that the name is what led me to use the parameters in this way. Why do you feel it needs correction, though? The negative outcome you give -- using url-status to mark dead links doesn't cause visible output -- doesn't apply here, as far as I can see, since I only set the parameter to dead when the archive-url is there, which means no further action is necessary. And dead-link would be wrong anyway -- this situation doesn't require a user to come along fix a link, which would be a hopelessly repetitive task for philsp.com, the website in question. (There are 771 cites to the website per an insource search I just did.) Mike Christie (talk - contribs - library) 12:30, 30 September 2023 (UTC)

Any fix would be to stop it's misuse, but as I said renaming the parameter at this point is unlikely. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:13, 30 September 2023 (UTC)

I have updated the documentation.

—Trappist the monk (talk) 13:19, 7 October 2023 (UTC)

Excellent clarification. I have added additional dead and deviated display and function identically, with a live link to the URL; usurped and unfit display and function identically, with no link to the URL. While the relevant paragraphs do say links to url= are suppressed in the rendering, I think it helps to point out that dead and deviated are the same, as are usurped and unfit. Best wishes, Pol098 (talk) 14:25, 7 October 2023 (UTC)

And I reverted that because I think that your addition is redundant but we can discuss if you'd like. Maybe there is a better way of writing what I proposed above.

—Trappist the monk (talk) 14:28, 7 October 2023 (UTC)

usurped says used when url links to information unrelated to the original link. The term usurped in this context is best understood as a misappropriation ie. someone other than the original owner of the domain has taken it over at the registar level and redirecting traffic to a new website, typically of a vice nature; or a domain reseller. This is why we sanction display. But it's not the same as merely unrelated content, for example many websites redirect dead links to their home page. Those we mark as dead links. Suggest the documentation for usurped take a higher level and say used when the domain in url no long serves it's original intent such as (mis)appropriation by other entities. Is it possible individual url's could be usurped? I suppose like a Facebook page that is hijacked. Usurpation most of the time is at a domain-level. I think for individual URLs, which are rare, we could rely on unfit. Thus the distinction between them is domain vs. url. GreenC 15:48, 7 October 2023 (UTC)

Done with a bit of copy editing: diff.

—Trappist the monk (talk) 16:30, 7 October 2023 (UTC)

Thank you. Some more changes. -- GreenC 03:16, 8 October 2023 (UTC)

I spent a fair amount of time editing articles trying to use "deviated" and wondering why it seemed the same as "dead". While the recent rewrite adds clarity and, if read carefully, does imply that they work the same, I do recommend some explicit statements that dead and deviated are identical, as are usurped and unfit, with no difference for the reader, just for editors. I'm not going to change again, but if this is thought useful please modify. Maybe just that: "dead and deviated display and function identically, as do "usurped and unfit", shorter than my original comment. Alternatively a rewrite of the list:

• live – selects |url= and shows link to |archive-url=; used when |url= is pre-emptively archived with |archive-url=
• dead and deviated – (default condition when |url-status= omitted or empty) select |archive-url= and show link to |url=. dead is used as an indication to editors when a link no longer exists, and deviated when |url= is still 'live' but no-longer supports the article text.
• unfit and usurped – select |archive-url= and do not link to |url=. unfit is used for a |url= that now links to porn, spam, advertising, or other unsuitable sites.usurped is used when |url= links to information unrelated to the original link

Best wishes, Pol098 (talk) 12:29, 8 October 2023 (UTC)

Thanks for that. dead and deviated cannot both be the default condition. The definitions for unfit and usurped have been refined to distinguish one from the other since your writing.

—Trappist the monk (talk) 14:06, 8 October 2023 (UTC)

Thanks for these documentation updates. I've just edited Usury to change the Financial Times citation (currently # 35) from |url-status=unfit to live and to add |url-access=subscription. I believe this is correct as the live URL has a paywall and the archive.today URL does not. I don't believe FT's addition of the paywall is "unfit" advertising. If I'm interpreting the documentation incorrectly, a reply would be helpful.

As an afterthought, I was initially suspicious of the cbignore for Wayback in favor of archive.today until I found that Wayback only saved versions with the paywall. Thanks for all you do! KarenJoyce (talk) 02:24, 26 November 2023 (UTC)

The {{cbignore}} was added by User:Frabrikator Special:Diff/1001248446/1001281991. Possibly IABot at the time was occasionally converting archive.today links to Wayback due to a bug now fixed - it no longer does that. I removed it. -- GreenC 02:41, 26 November 2023 (UTC)

Since we are on the topic of url-status, another question is with "deviated". In the worlds of computer and library science, the phenomenon is "content drift": Example, Example, Example, Example. It would be canonical and accurate to call it |url-status=drift or |url-status=drifted or |url-status=drifting. Most likely "drifted". I doubt there are so many we can't easily modify via bot. As a bonus they both start with "d", and drifted is fewer letter and syllables. (IMO deviated sounds vaguely sinister, like deviant, which is the purpose of unfit and usurped.) It would help get everyone on the same page inside and outside Wikipedia with the same terminology of content drift. -- GreenC 17:25, 8 October 2023 (UTC)

Requesting a new parameter value: |url-status=paywall would mean that the link works only if the user is paying to access it. Commenter8 (talk) 16:09, 5 November 2023 (UTC)

The current documentation for |url-status= is at Template:Cite book § Subscription or registration required. There, the term 'paywall' is used as part of the definition of the keyword subscription. Is that not sufficient? If not, how is it not sufficient?

—Trappist the monk (talk) 16:22, 5 November 2023 (UTC)

deprecate |authors=

Since May I have been picking away at Category:CS1 maint: uses authors parameter. Today that category is more-or-less empty. |authors= has been 'discouraged' in the documentation since June 2016. I have marked |authors= as deprecated in Module:Citation/CS1/Whitelist/sandbox and will tweak the template documentation to show that the parameter is deprecated.

|authors= has two aliases: |people= and |credits=; these parameters are not deprecated.

—Trappist the monk (talk) 14:21, 24 October 2023 (UTC)

You realize this will just cause people to abuse |author= to list multiple authors, right? —David Eppstein (talk) 14:48, 24 October 2023 (UTC)

What is the consequence of a deprecated parameter? eg. it works but displays a warning message? -- GreenC 14:55, 24 October 2023 (UTC)

And then later on Trappist removes it from the template and makes its use even more inflexible and human-unfriendly. —David Eppstein (talk) 15:19, 24 October 2023 (UTC)

It's a false dichotomy of human-friendly *versus* unfriendly for the sake of the machine. There's a lot more to it. There is human friendliness dimension to both sides depending which aspect you want to emphasize ie. the simple one-time input process, or the infinite re-use of the data by end-users, which benefits from greater precision and fewer ambiguities in the names. -- GreenC 18:05, 24 October 2023 (UTC)

At present, templates using |authors= render with a maintenance message:

{{cite book |title=Title |authors=Red Brown, EB Green}}

Title. {{cite book}}: Cite uses deprecated parameter |authors= (help)

After the next module suite update, templates using |authors= will render with an error message:

{{cite book/new |title=Title |authors=Red Brown, EB Green}}

Title. {{cite book}}: Unknown parameter |authors= ignored (help)

Instances where a deprecated parameter is used in mainspace will be categorized in Category:CS1 errors: deprecated parameters.

—Trappist the monk (talk) 16:32, 24 October 2023 (UTC)

You think that editors don't already do that? I invite you to inspect the articles listed at Category:CS1 maint: multiple names: authors list. Deprecating |authors= makes the author name-list parameters consistent with the other name-list parameters. For the other name lists:

• |contributors= never supported
• |editors= deprecated at this edit; unsupported at this edit
• |interviewers= replaced |cointerviewers= at this edit; unsupported at this edit
• |translators= never supported

—Trappist the monk (talk) 16:32, 24 October 2023 (UTC)

I don't see this making a lot of difference, it's very uncommon to see |authors= used anymore, and it's been nearly seven years since the process was started. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:58, 24 October 2023 (UTC)

Agree with David: the proposal is not an improvement. I have reverted the documentation change. Nikkimaria (talk) 18:33, 24 October 2023 (UTC)

Improvement for who? There is more to it than convenience of 1-time data input. Can you explain your rationale for saying "not an improvement" that includes all stake holders? Other processes, people, databases, tools. etc downstream.

TTM is doing what is the best for the most people, big picture. In interface design, best practice is to "nudge" users towards greater accuracy and fewer errors. Use of CS1|2 is optional, if you really prefer complete free-form data entry, don't use CS1|2. This just-so nightmare: |authors=Elizabeth, Middleton Maria, Baroness, Susan, Amy Maria, invented by me, demonstrates ambiguities in parsing by humans and machines (it's Middleton Maria Elizabeth, Susan Baroness, and Amy Maria .. or, Baroness Middleton Maria Elizabeth and Amy Maria Susan). The solution to use ";" between names is nice in theory but in reality free form gives expected results: names that are not consistently parsable. -- GreenC 19:45, 24 October 2023 (UTC)

The proposed change may improve matters for data reusers, but David has raised a reason why it may not - as for that matter have you, in promoting abandonment of templates altogether. That's the bigger picture: if user-unfriendly changes discourage people from using templates, or adding citations at all, it impacts every other potential stakeholder. Nikkimaria (talk) 20:08, 24 October 2023 (UTC)

What do you may? It clearly would and does for reusers. David's point had nothing do with reusers. I'm not promoting anything, only observing what has always been true we have two systems. I can't imagine anyone abandoning CS1 over this one parameter which has been actively deleted for years. There is no evidence this is a user unfriendly change that would discourage use of templates, otherwise show me the complaints when this parameter has been deleted from templates. -- GreenC 22:14, 24 October 2023 (UTC)

Since I began replacing |authors= the only 'complaints' were related to these articles:

• Battle of the Hatpins
• Christine Egan
• Francis Godon
• Phoenix Sinclair
• The Forks, Winnipeg

I started clearing Category:CS1 maint: uses authors parameter when it had ~14,150 articles (the first edit that I can find was this one). I started from the top of the category (article names beginning with digits and then alphabetically) so whenever an article re-appeared in the category it was obvious. There weren't many reappearances and those that did re-appear did so because of new additions to an article, other copy editing, or unrelated mistakes on my part. All of these five articles reappeared when Editor Nikkimaria silently reverted my edits. Many of the edits to replace |authors= were done using various AWB scripts. After a time I tweaked the scripts so that they would skip Editor Nikkimaria's articles. I did not do that for any other articles because no other editor complained either directly or indirectly.

—Trappist the monk (talk) 23:46, 24 October 2023 (UTC)

Complaints about cleaning up the metadata in existing templated references are uninformative about how rigid and difficult-to-use you are making the citation templates for human editors attempting to create new references. —David Eppstein (talk) 00:04, 25 October 2023 (UTC)

If it was really a problem, we'd be seeing more complaints about its removal in over 14k cases. This is an objective data point. "Ridged and difficult to use" is by contrast a subjective opinion by a couple users. And this opinion does not take into account all the stake holders and their needs, it prioritizes one set of stakeholders. Considering how complex Wikipedia is (tables, other templates, etc..) replacements for this parameter are not very complex, have been in place for years, and many people use them already without complaint. -- GreenC 00:24, 25 October 2023 (UTC)

The proposed change also attempts to prioritize one set of stakeholders. To answer your question above about why I say "attempts" and "may": your assertion above that it "clearly would" is based on the assumption that removing the intuitive, convenient option will lead editors to the "preferred" option instead - but that is not the only possible outcome. David has proposed one alternative: editors will instead switch to piling multiple authors into |author=. You have named another: editors will switch to using free-text citations. I have given a third: editors will simply not provide the data. The first case would necessitate additional work to provide any improvement for data reusers; the other two would worsen the situation for reusers (which is why reuser-focused "improvements" that worsen the editor experience are problematic). Nikkimaria (talk) 02:59, 25 October 2023 (UTC)

What about some sort of compromise solution? Where all the specific citation wrappers ({{cite book}}, {{cite web}}, etc.) can be optimised for data reusers, and {{citation}} can just retain all the parameters people want to deprecate, and not do sanity checks on what parameters should and shouldn't be there, apart from disallowing multiple parameters that are aliases of each other?

That would let the downstream people get their metadata all nice and fastidious so no human ever has to look at it to guarantee a computer will understand it properly, and have an alternative easy / freeform mode for editors who don't want to type |editor7-last= etc., or who want to cite something in a way that doesn't vibe with whatever the metadata standard is (location without publisher, book that is part of a larger work, "chapter" of a website, or whatever). Folly Mox (talk) 03:28, 25 October 2023 (UTC)

"an alternative easy / freeform mode for editors who don't want to type editor7-last" Don't the vcite templates already offer this? Rjjⁱⁱⁱ (talk) 06:34, 25 October 2023 (UTC)

Wow I don't think I'd ever before heard of or seen in the field any of the vcite templates, and reading the documentation for {{vcite book}} gave me some idea what it must feel like for a new editor to encounter CS1 for the first time. Folly Mox (talk) 11:20, 25 October 2023 (UTC)

There's also |vauthors= which does the same as authors, but in an established style. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:50, 25 October 2023 (UTC)

That parameter I did know about, but I find it too limiting. The |authors= thing that is the immediate discussion here isn't my fight, but it seems true that in general, the CS1 templates – which are essentially equivalent to house style at this point – have been in the recent past moving towards clean metadata for reusers and away from usability for Wikipedia editors.

I don't know if the solution is training everyone to produce citation data that can be cleanly reused by downstream people, forking the citation system so there's alternatives for editors who don't want to deal with all the nuances of best practice, subjecting major changes in the citation templates to broader community consensus, or what. But it's evident that we're coming to, at, or beyond the point where there's conflicting interests.

I'm really deeply appreciative for all of Trappist's work on these templates, which I use all the time, every day, and frequently convert plaintext citations into. I'm not trying to invalidate any of that, and maybe I'd have a different perspective if I had any idea who "reuses" citation metadata from Wikipedia, how they reuse it, and for what. Folly Mox (talk) 12:32, 25 October 2023 (UTC)

For the avoidance of doubt, I also really deeply respect Nikkimaria, GreenC, and David Eppstein for all the work they've done for the project as well. I wish we could all agree on things and I'm not sure how. Folly Mox (talk) 12:49, 25 October 2023 (UTC)

It is not true that the proposed change ... attempts to prioritize one set of stakeholders (emphasis added). Three of the stakeholder sets that benefit from this proposed change are our readers-set, the everyday-editor-set, and the gnome-editor-set. The intent is to make all name-list parameters consistent across all of the name lists. Deprecating |authors= helps our readers because free-form name-lists are just that; there are as many ways to write a free-form name-list as there are editors who write those lists. Yeah, we can say in the documentation that the names of individual authors in the list shall be separated by semicolons not commas but don't hold your breath for editors to do that (the vast majority of names in |authors= that I have fixed over the past months were separated with commas (Name, Name, Name, Name, ... – is that a list of Last, First names or a list of Last names only? Sometimes it's not possible to tell without consulting the source). Deprecating |authors= helps the everyday-editor-set by making name-list entry of any stripe (author, contributor, editor, interviewer, translator) use similarly named parameters; supporting one-off parameters just causes confusion. Deprecating |authors= helps the gnome-editor-set by reducing the amount of work that must be done to fix citations written by conscientious editors who used |authors= because it is listed in the documentation as a valid parameter.

It is the duty and obligation of the cs1|2 templates to render name-lists that use a consistent format citation-to-citation in both human- and machine-readable forms. cs1|2 cannot format free-form name-lists because it cannot accurately parse a free-form list of alphabetic character groups (names) into human-readable author names (if anyone reading this knows how to do that reliably, don't be shy). It is for this reason that cs1|2 does not include authors listed in |authors= in a template's COinS metadata. Readers who use reference management software to consume our citations do not get that critical author metadata. All readers, whether they are reading with their own eyes or by the eyes of a machine, are entitled to complete and accurately rendered citations.

—Trappist the monk (talk) 14:45, 25 October 2023 (UTC)

The assumptions put forward above warrant further examination. The average reader doesn't care in the slightest what parameters or templates we use; as far as they care about citation formatting at all, it is only whether there is sufficient information provided to identify and ideally access the source. So for the bulk of the readers-set, the proposed change is neutral, assuming no negative impact on editors. However, for everyday editors who are not intimately familiar with templates, "authors" is an intuitive and convenient choice for adding multiple authors. As for gnomes, as with data reusers, it helps them only if the change results in the desired behaviour from everyday editors - see above. If that's not the result, it may even increase their workload.

The primary purpose of citation templates is to support editors in conveying the sources of information they add to Wikipedia. If they fulfill some other obligation, great - but if they fail in that primary purpose, it doesn't matter how perfectly they meet other goals. I echo Folly Mox's excellent argument above: this specific issue may be the straw that breaks the camel's back for some users to move away from using templates, or it may not - but this discussion is certainly highlighting some fundamental, as-yet-unresolved conflicts between the needs and perspectives of users and reusers. Nikkimaria (talk) 00:28, 26 October 2023 (UTC)

The average reader does care when the content of a free-form citation parameter is difficult to decipher because the editor who created that parameter's value did it in such a way that surnames are indistinguishable from given names because name separators are the same as author separators or are omitted entirely. Readers who consume these citation templates using reference management software like Zotero care because they don't get the author data; cs1|2 cannot parse a free-form author-name list so it cannot fill the $rft.aulast, $rft.aufirst, and $rft.au k/v pairs in the COinS metadata. All readers are entitled to the best citation rendering that we can provide; continuing to support |authors= because most readers don't care about properly rendered citations deprives those readers who do care.

Editors who don't care will continue to abuse |authorn= and |lastn= to do the same as they do with |authors= – if we are to believe this archive snapshot from 2023-08-05, editors abuse |author= and |last= more often than they use |authors=. These days, most editors, even those who don't care, don't have to be intimately familiar with cs1|2 templates because we have VisualEditor and RefToolbar which will do the grunt work for them. These tools don't need and should not use |authors=.

Gnomes have enough stuff to fix across the encyclopedia. We can take one item off of the stuff-to-fix-list by deprecating and removing support for |authors= – Category:CS1 maint: multiple names: authors list will still be there for those who enjoy cleaning up after inexperienced or lazy editors.

The primary purpose of citation templates is not for editors but for readers because the templates provide consistent rendering of citation information. Editors are now and always must be secondary to the needs of the readers.

—Trappist the monk (talk) 15:08, 26 October 2023 (UTC)

If you want the readers to get the benefit of citation templates, the citation templates must remain usable by human editors. The alternative is templates only usable by machines and article references constructed by humans that avoid the templates and deny robot access to those articles because the robots make everything so difficult to edit. I have already seen articles with blanket bot denial tags because of the persistent habit of the bots of adding useless junk ids (which fail to benefit readers in any way) to citation templates, and I have already noticed in my own content creation that I have been formatting a greater fraction of citations manually without templates because I just can't justify the effort of fitting them into a citation template shaped box. With usability-reducing changes like this I only expect that sort of thing to become more widespread.

On the other hand, if the citation templates remain usable by humans and cleanable by bots, you get the best of all worlds: the readers get the consistency benefits of templated citations, the humans get to use citation templates to help format their references more-or-less consistently, and then the bots and gnomes can clean them up. But there will be nothing for the bots and gnomes to clean up if you make the templates usable only by bots and gnomes, because actual content creators won't use them. —David Eppstein (talk) 15:24, 26 October 2023 (UTC)

Clearly you dislike bots. This talk page is not the place to rant about bots. For that, discuss at the bot operators' talk pages or WP:BOTN. This discussion is about deprecating |authors=.

Yes, I want readers to get the benefit of citation templates. cs1|2 cannot consistently, accurately, reliably, pick your own qualifier, format human and organizational names when given a free-form string of characters written using Latin and non-Latin scripts (Cyrillic, Greek, Arabic, Hebrew, CJK, Devanagari, ...). So, editors must help by providing individual names in individual name-holding parameters. Alas, some editors never will. If they don't want to provide individual names in individual parameters, they can use |author= or |last= (they already do) and someone, someday, will cleanup after them. We don't need |authors= it should be deprecated and then support for it should be withdrawn.

—Trappist the monk (talk) 15:39, 27 October 2023 (UTC)

Editor Nikkimaria has also silently reverted my edits to Module:Citation/CS1/sandbox, Module:Citation/CS1/Configuration/sandbox, and Module:Citation/CS1/Whitelist/sandbox which explains why the examples above don't match the text in my 16:32, 24 October 2023 post. All of my edits should be restored.

—Trappist the monk (talk) 23:46, 24 October 2023 (UTC)

That's unprecedented, never seen that before. Sandboxes are made for this, it's why we have them. They need to restore the sandbox while consensus discussions continue. Or provide a really good explanation why they are interfering in the consensus process. -- GreenC 00:32, 25 October 2023 (UTC)

These sandboxes are not simply used for demonstration purposes as is typical elsewhere, but instead to accumulate changes for bulk implementation. Since this change doesn't have consensus at this point, it ought not to be added to the accumulation. Nikkimaria (talk) 02:59, 25 October 2023 (UTC)

Consensus is determined on this talk page, or similar, and not by what is contained in the sandbox.

It's true the sandbox is a staging area for proposed changes, but a lot happens between now and the final push to production. Ultimately what goes into production is determined by consensus. In fact before the sandbox goes live, there is an announcement with a waiting period and link to this discussion; and clearly everyone knows at this point this change is controversial, so it would be nearly impossible to go by unnoticed, even assuming someone tried to keep it in slyly. Furthermore given your past history with this forum, I seriously doubt anyone is going to try and slip it by when there is no consensus. The purpose of the sandbox is so we can see the proposal and then comment on it, but your interference is disrupting that process. -- GreenC 05:27, 25 October 2023 (UTC)

Unfortunately what my past history with this forum has shown me is that the ideal you describe doesn't match reality. Nikkimaria (talk) 13:04, 25 October 2023 (UTC)

I don't know what you refer to - are you saying there was consensus not to do something, yet it was done anyway? Most likely you opposed something but it went through anyway due to a plurality of opinions per WP:DISCUSSCONSENSUS. All I know is your bad faith in the process is interfering in consensus building, and with maintaining the template. Any wrong you feel you were the victim of in the past doesn't excuse bad behavior in the present. All it does is perpetuate bad faith, further bad behavior, more disruption. -- GreenC 15:45, 25 October 2023 (UTC)

If you don't know, wouldn't it be best to not jump right off on a bad explanation? But in the interests of not perpetuating bad faith etc further, let's refocus on the proposal. Nikkimaria (talk) 00:28, 26 October 2023 (UTC)

Right, I'd like to focus on the issue, by restoring the sandbox, so we can see the code in action, but which you have removed from public view, based on an assumption of bad faith in this 'forum'. -- GreenC 03:52, 26 October 2023 (UTC)

It would be a good option to separate the testing function of a "traditional" sandbox from the staging function of this implementation, rather than having the two combined. This would allow you to see the code in action while also avoiding having changes being added/left to staging prematurely in future, addressing both of our concerns. What is the best way to accomplish this? Nikkimaria (talk) 04:29, 26 October 2023 (UTC)

What difference would it make? It's not like we have a problem with things accidentally being left in the sandbox. Rather, you believe people intentionally do things on the sly. New staging versions won't help. At some point, the staging versions need to be staged for review. Which anyone can edit. It's just another sandbox. 9 of them currently full of complex changes and code. It would be the same "problem" but worse, a new set of files to watch and maintain. Rather, the current process is to post in this forum all the proposed changes with a link to the discussions that brought them about and a waiting period for anyone to object. Again, what's the problem? I have not seen anyone but you complain about bad faith in this process, and you have only cast aspersions ie. with no evidence. -- GreenC 14:42, 26 October 2023 (UTC)

Nowhere in this discussion have I expressed a belief that "people intentionally do things on the sly" - as above, it would be best to not jump off on a bad explanation. The problem is that, as noted here, "anything that makes it into the sandbox eventually makes it into the main module": changes can get added to and remain in staging, and after that get pushed to production, without consensus being reached for them. Here's an example: a change was proposed, there was opposition to it, the discussion did not achieve a clear consensus in favour of implementation, and yet the change ended up in the next module update. This was not addressed by the update post (perhaps because of the issues noted here? It certainly wasn't the only update in that set with concerns.) This comment from a subsequent discussion is also worth reading. Nikkimaria (talk) 02:24, 27 October 2023 (UTC)

I can't see the utility in maintaining a variant parameter because one editor objected over five articles. Splitting out multiple authors to use first and last names is desirable on metadata grounds and furthermore is not hard. Seven years of a deprecation warning is more than enough time. Mackensen (talk) 12:14, 25 October 2023 (UTC)

Another point here is that most new citations will have been generated automatically. I create a lot of cites and a negligible fraction are hand written. Also new editors are pointed to tools that allow for the auto-creation of cites. None of the tools will generate a cite that contains this parameter. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 13:49, 25 October 2023 (UTC)

Your experience does not match mine. I regularly manually-format some citations, or in many cases manually format them and then pass them through some automated cleanup before saving. Most tools you describe are useless to me because I do most of my Wikipedia draft creation offline, because the Wikipedia draft process has been taken over as a honeypot for spammers instead of as a useful way to create new content. In addition, although I do have scripts that can create properly formatted citations from doi's, they usually require manual cleanup (because the publisher metadata is bad) and I do not have such script for other common aggregators of reference content like jstor, proquest, and NASA/ads.

Additionally, some of the software I still use is legacy from long-obsolete OS and compiler versions, and I'm not entirely sure I can recompile it. This means that ongoing changes to parameter formats, and especially, removal of older parameter synonyms, are likely to cause it to stop working. This particular change won't do that but others of similar nature easily could. —David Eppstein (talk) 15:47, 25 October 2023 (UTC)

I know well the annoyance of changes scuppering well setup work flows, but the citation formats can't remain set in stone because they break your personal setup.

As an aside have you thought about migrating your draft creation to user space? It avoids any of the problems associated with draft space, and a history of the original authors working can be incredibly useful years later when trying to understand issue with the article. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:12, 25 October 2023 (UTC)

On the contrary, there is absolutely no reason to break backward compatibility and plenty of reason not to. Along with people stuck with legacy software, another good reason is that broken backward compatibility makes old versions of our articles unreadable. —David Eppstein (talk) 17:50, 25 October 2023 (UTC)

I create a lot of cites and the only time I generate them algorithmically is if it's a scientific paper with like six or more authors. The generation scripts frequently miss out on publisher, and always don't generate en.wp specific parameters like |author-link=, |script-title=, etc. But you bring up a good point that many new cites do come from scripts, and it makes a lot more sense to direct energies towards improving Citoid and the things that call it, than it does to twiddle uncommon bespoke parameters that it doesn't deal with. Folly Mox (talk) 16:17, 25 October 2023 (UTC)

It seems the vast majority of citations are produced using modern tools then cleaned for issues manually (Citoid regularly has issues). It is simply not that burdensome. As to those papers with hundreds of authors – eg B P Abbot, R Abbot, T D Abbot, F Acernese, K Ackley, C Adams, T Adams, P Addesso, R X Adhikari, V B Adya, C Affeldt ... O M Smirnov, R P Fender, and P A Woudt, "Multi-messenger observations of a binary neutron star merger" Astrophysical Journal Letters 848 (2017) (with over 3,500 authors and 1,000 affiliations; or consider the Physical Review Letters article with 5,154 authors) – just don't name all of them. Use |display-authors=etal. Regardless, corrections should be propagated: doing so will require machine-readable parameters to get it right. Ifly6 (talk) 18:16, 25 October 2023 (UTC)

display-authors is intended to be used to change the display only. Simply not adding all of the authors in the first place is an example of a problem, not a solution. Nikkimaria (talk) 00:28, 26 October 2023 (UTC)

The idea that we have to include all 100+ authors, though, would not be correct; we're all volunteers here and there is no policy against specifying sufficient authors to identify the paper clearly. Yes, doing something like |display-authors=4 and then just not entering more than 4 names out of the 100 is not the way elide them. The way to do it properly is |display-authors=etal after the fourth (or whatever) author you do want to specify. That's the reason that special etal parameter value exists. (The way-old method of doing something like {{|para|author5|et al.}} and stopping with author entry thereafter is deprecated and has probably already been replaced system-wide (I haven't seen an instance of it in a long time), since it produces blatantly false metadata that claims an author's name literally is "et al."

PS: We also need to update the |display-authors= parameter doc to make it clear that this is only for suppressing reader-unhelpfully large lists of authors (dozens or more), not for forcibly conforming all citations in a page to an artificially short list like 3 names. I've run into a case of a guy doing this robotically at articles he has an interest in, and even after it is explained to him that suppressing data we have already entered on 4 or 6 or whatever authors and hiding it from the reader on purpose is utterly pointless and defeats the purpose of entering the author information, and he has no consensus to do it, he just editwars to do it again anyway. I've not made it a noticeboard matter yet, but we're probably going there.
 — SMcCandlish ☏ ¢ 😼  02:02, 26 October 2023 (UTC)

Agree with the deprecation of |authors=. For reference, what we have now is:

authors: Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

Trappist the monk changed this to:

authors: deprecated Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

but was reverted by Nikkimaria.

Arguably it should have been:

authors: deprecated Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

since that provides one of the deprecation reasons, and the closing statement remains correct.

Regardless, the idea that people should be using any "free-form list of author names" at all when we have |first=|last= and |firstn=|lastn= is rather nonsensical. [Maybe with the exception of |vauthors=, though I think that should be deprecated too, since Vancouver style conflicts with other guidance like MOS:INITIALS, and produces confusing output in many cases, e.g. where jammed-together initials coincide with conventional biographical acronyms like MD. Even if we keep |vauthors=, it should be replaced with first/last params in any article that is not consistently using Vancouver style; normalize to a consistent citation style per WP:CITEVAR, and normalize to the more sensible one used by 99+% of our editors.] Yes, we will have some lazy or confused people abuse |author= or |last= for multiple authors (which already happens all the time anyway), but it would be better to have primarily one form of parameter abuse to look for and clean up after than multiple conflicting ones. For someone who simply cannot wrap their head around CS1 templating, or who has text-entry mobility issues and can't deal with it, or whatever, they can just do <ref>Freeform text here</ref>, and someone will clean up after it later. It is much easier to see and clean up after that than to catch template-buried misuses of parameters. We have no reason whatsoever to have a CS1 parameter that effectively not just replicates freeform ref text but encourages people to do freeform input (and even |vauthors= isn't freeform, but a prescribed, if very unhelpful, format). Either use the templates properly or don't use the templates. There is no point of any kind in a template parameter that basically resolves to "didn't use the template properly", which is exactly what |authors= is, as presently documented and non-deprecated.  — SMcCandlish ☏ ¢ 😼  02:02, 26 October 2023 (UTC)

|vauthors= was something of a compromise in 2015 to get people off of one of the alternatives mentioned above. The structure of the format is the predominant reason why it was accepted into this series of templates. To me this is the wrong tree to be barking up. Izno (talk) 08:41, 27 October 2023 (UTC)

I also agree with deprecating the parameter for the reasons already stated. As one of the gnomes who has also picked at the authors category, and one of the primary gnomes responsible for cleaning out the 5000 someodd uses of |editors= before that too was removed, Trappist's examples of garbage citations don't even cover the spectrum of misuses of this parameter (and its now-removed cousins like |editors=). His and SMC's commentary on this are fully in alignment with my views. I'm glad he got this parameter to the point where we can finally be entertaining this discussion.

As stated above, for the users who really do not want to or even cannot take the time to add citations in a structured or even consistent manner, |author= remains with its own category capturing misuses which gnomes work on at whatever pace suits. That parameter won't be going anywhere and certainly neither will the category catching those misuses, but "I can't be assed to input my dozen authors correctly right now" is not a sufficient or even good excuse to continue supporting what is a duplicate parameter. Izno (talk) 08:41, 27 October 2023 (UTC)

Hard agree with Izno, SMC, Trappist, et al. Re Nikkimaria's Simply not adding all of the authors in the first place is an example of a problem, not a solution: Absolutely nobody – and I mean absolutely nobody – is best served by listing all 5,154 authors of G Aad et al, Phys Rev Lett 114, 191803 (2015). Ifly6 (talk) 00:16, 29 October 2023 (UTC)

Not withstanding the "hard cases make bad law" principle, there really are a pretty large number of academic works with 100+ authors, and they are almost certainly best treated by listing the first few authors (enough to be certain of identifying the source correctly) followed by |display-authors=etal. But another thing we absolutely don't need is, after we've gone to the trouble of specifying 7 authors here and a dozen there and 4 on that one, and 9 on this other one, as complete author lists, having some rando later editwar to force them all to |display-authors=3 just to be a bonehead who likes suppressing information. Whether 15 authors, or 20, or 40 is "too many" to list seems really up to editorial judgment at an article, but if we already have the information in the citation, it is hard to think of a rational reason to hide the data from the readers. If someone is absolutely certain that 30 authors is too many, they should get consensus to trim the actual included list of them to a shorter number and elide the rest with |display-authors=etal. But keeping them all in the code then using trickery to suppress readers' ability to see them, like |display-authors=10 when there are 30 already coded, is just ridiculous.  — SMcCandlish ☏ ¢ 😼  02:55, 29 October 2023 (UTC)

A fortnight and more since the last post on this topic suggests that those editors who watch this page and who wished to express an opinion, have done so. I get the sense from the preceding discussion that there is more support than there is opposition for/to deprecating |authors=. I have restored the reverted edits to the module suite and the documentation.

—Trappist the monk (talk) 20:10, 14 November 2023 (UTC)

I agree; however, it currently reads:

*authors: deprecated Free-form list of author names; use of this parameter is discouraged because it does not contribute to a citation's metadata; not an alias of last.

and when I see "use of this parameter is discouraged" in strikeout type, that means to me,

• "use of this parameter used to be discouraged at some point, but we thought better of it, so we've struck it out, and it is no longer discouraged."

Combined with the lead-off "deprecated" term, that appears to be self-contradictory. Mathglot (talk) 02:01, 23 November 2023 (UTC)

Agreed, and I pointed this out before myself. Th fix is to stop the strike-through at "author names;". It's also still true that "not an alias of last.", so that shouldn't be struck either.  — SMcCandlish ☏ ¢ 😼  02:14, 23 November 2023 (UTC)

url-status=dead (and a side-topic about language=en)

I've seen some removals of this at articles lately. Are we certain this is really redundant? There's a potential difference to me here between "someone has checked this and we know that it is dead" and "no one has checked this and the parameter is missing". It seems to me that removing it could just lead to unnecessary editorial time-waste checking to see if the non-archive original URL is actually live or not. If we're sure it's not needed, I'm okay with that; I'm in favor of reducing redundancy. (Like why oh why do people keep adding |language=en when that's the site-wide default when no other language has been explicitly specified? And doubleplus why do people keep doing |langauge=en-GB, etc., when the exact dialect of the source is irrelevant? No one competent to read American English is going to need a translator to read British English.)  — SMcCandlish ☏ ¢ 😼  14:07, 31 October 2023 (UTC)

Re the language parameter, I doubt this is people adding it, more not removing it. The citation tool adds the parameter automatically if it finds the relevant information on the source page. Nthep (talk) 14:51, 31 October 2023 (UTC)

Hmm. So, how to get that to stop happening when (on this site) the value returned in en or en-*? It's annoying, and resulting in an unbelievable amount of pointless code bloat.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC)

Having |language= set helps with translation efforts. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:18, 31 October 2023 (UTC)

Any translator taking material from en.wikipedia.org already knows that the default language is en, and 99%+ of our cites to en sources do not have this parameter, so it is not helping with translation efforts. Even if it was, somehow, some way, it is not worth the amount of code bloat in our live articles.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC)

It's very little code bloat, especially as the reader doesn't even see it. Also a lot of non-technical editors translate articles and rely on automatic trasnlation of cites. The mass removal has been previously discussed on one of the village pump pages, and gained no traction. I was initially for removing it, but came to see the other sides point. It's 12 characters, it hurts no-one and helps some. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:02, 31 October 2023 (UTC)

No readers ever see any code bloat, because it's in the code, by definition. It's an editing and maintenance issue, not an end-user readability matter. It's 12 (often 15) characters over and over and over again on page after page after page. Not trivial. Mass removal of anything generally gets opposed on "I don't want my watchlist going nuts" grounds, especially when the change does not affect the reader's view. So that's not a principled position against deprecating this usage and getting tools to stop automatically doing it. If there's an actual use case for this, I have yet to see it, and I've been here 17 years. I guess I will go see if I can find some arguments for it that I missed, since you suggest there are some, but these vague hints are not promising. If the user already knows by default that the material will be English (and besides, the entire page already has lang="en" for its entire content except were explicitly overridden), there doesn't seem to be an auto-translation-tools reason for this.  — SMcCandlish ☏ ¢ 😼  17:22, 31 October 2023 (UTC)

That's how the auto-translation tools work and usually they are translating the cite once they have reached the target wiki, so no lang="en" is not set. You've missed that {{Ouvrage}} is a redirect to {{Cite book/French}} for instance, and what AnomieBOT does when it's used. So there is a explicit reason to have it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 31 October 2023 (UTC)

Can you explain what you mean in more detail? If the tools are translating some other wiki's content, then that wiki will be providing its own lang information already. I don't see what the {{Ouvrage}} redirect has to do with anything, or {{Cite book/French}} for that matter, since if it's translating a template imported with French-language parameters from fr.wikipedia, that template will already either be for a French source (by default) or come with a |language=en (or I suppose |langue=en) if it's an English-language source being cited, and not need a |language=en parameter newly added, plus will get substituted out by a bot anyway and no longer need that parameter after the work is done. Am I missing something still? The fact that there are special and short-term use cases for |language=en doesn't seem to translate (pun intended) into a stick-them-in-every-English-citation-redundantly rationale.  — SMcCandlish ☏ ¢ 😼  18:06, 31 October 2023 (UTC)

Just because {{Ouvrage}} was imported from fr.wiki does not mean that the source is written in French – likely it is, but there is no guarantee. fr.wiki doesn't use cs1|2 but they do have |langue=. At fr.wiki, when |langue=fr, the language output is suppressed; that's where we got the idea to suppress the output here when |language=en.

—Trappist the monk (talk) 18:34, 31 October 2023 (UTC)

1. An editor translates the article text.
2. The editor directly copies the cites without any translation.
3. Anomiebot substitutes the cites using Cite book/French as direction of how to correctly rename the fields.

All this happens on enwiki, so unless the frwiki cites have |language=fr set the cites on enwiki don't have it either. All of this makes it easier for editors to translate articles without having learn the technical details of how the templates work.

It is a real and specific reason to include |language=en. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:58, 31 October 2023 (UTC)

"makes it easier for editors to translate articles" is an almost entirely theoretical idea, since nearly none of our citations to English-language sources have |language=en. There is surely a better way to do this than dumping enormous amounts of redundant code into our articles. The fact "this could work to make translation easier" doesn't make this the best, or even a reasonable, idea in furtherance of that goal. (If I need to move my car over by one foot, I could do it by hitting it with sledgehammer and over and over on one side, moving it a milimeter at a time, but this would not be a good idea.) Fr.wikipedia should be presuming by default that a copy-pasted citation off of en.wikipedia that they are using a local tool to translate into an equivalent French cite template is by default an English-language source. There is no reasonable other assumption to make. I'm not convinced in any way that whatever need is being flagged here can only, or even best, or even practically, be solved by jamming in literally millions of |language=en instances. I think we are more clever than this and can build better, cleaner-running tools. Same with "unless the frwiki cites have |language=fr set the cites on enwiki don't have it either"; if our template-translation tool knows the template is from fr.wikipedia (and it would have to, to properly parse the parameters) then we already know that the default thing to do, absent something like a |langue=zh in their template, is to add |language=fr in our version.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

As I said earlier I was convinced of it in another discussion, because people are actively using it this way so no it's not theoretical in anyway. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:26, 1 November 2023 (UTC)

This is more vague "I saw something somewhere once" hearsay. We need specifics, and an examination of whether their alleged need for this can be met some other way that doesn't entail adding millions of blobs of otherwise unneeded code all over the 'pedia.  — SMcCandlish ☏ ¢ 😼  18:09, 1 November 2023 (UTC)

I'm not going to go and dig around every VP archive to find the discussion, and it's obvious even that would not change your mind so I'll drop it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:13, 1 November 2023 (UTC)

My mind actually frequently changes, especially on matters like this, in response to evidence that can't be easily dispelled (like some of the translation-related arguments made so far can be, but there may be stronger ones). I don't think it's unreasonable to respond with "show me" when someone says "I've seen the proof".  — SMcCandlish ☏ ¢ 😼  21:05, 1 November 2023 (UTC)

The problem is not that no people ever could be using it this way. The problem is that (a) only vanishingly few current citations include this, so it can't be relied on, (b) that most citations are in English is obviously implicit here, and describing that explicitly adds a lot of boilerplate noise to the template, (c) the harm of Wikipedians translating English articles to their own language and accidentally not tagging all of the citations as being in English is temporary and pretty trivial, (d) large-scale automated edits adding it to existing citations are a big distraction not justified by the trivial benefit. This problem would be much better addressed by fixing whatever automatic translation tool people are using. –jacobolus (t) 18:16, 1 November 2023 (UTC)

And |language=en is 12 characters that hurts no-one , so what. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:15, 1 November 2023 (UTC)

The citation templates are already a lot of noisy boilerplate, even in the best case, and a magnet for relatively useless redundant metadata. The longer and more annoying filling out the templates gets, and the more often bot-like editors come and pointlessly twiddle the parameters for little or no benefit to readers, the more I'm tempted to just use plain wikitext for citations, optionally with {{wikicite}}. Every new hoop the templates make human editors jump through is another step in the wrong direction. –jacobolus (t) 22:50, 1 November 2023 (UTC)

No new hoops are being added as I said no-one has suggested mass adding it, or the need for editors to add this parameter when setting up cites, or for any editors to go adding this parameter to already existing cites. Many cites that are created automatically using lookups include this parameter, this is not something that is controlled by the editors maintaining these templates. You have the whole discussion back to front. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:59, 1 November 2023 (UTC)

I thought the problem was with people making edits adding language=en to existing citations? If not, what's the complaint? –jacobolus (t) 23:04, 1 November 2023 (UTC)

The discussion is that it should be removed from cites that already have it, which I feel is a waste of time and could negatively impact some editors is niche situations. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:10, 1 November 2023 (UTC)

If someone wants to incidentally remove language=en in a citation or two as part of reformatting them, fine. Automatic removal of language=en on a wide scale seems like a big waste of attention. –jacobolus (t) 23:36, 1 November 2023 (UTC)

(edit conflict)

|language=en has nothing to do with the html attribute lang="en". The |language= parameter is there so that readers can know the language of the cited source; see the template doc. cs1|2 suppresses rendering of the source language when the source language is the same as the local wiki's language. If a cs1|2 template is never, ever, going to be copied to another language wikipedia, then |language=en is obviously superfluous. If the cs1|2 template may be copied to another language wikipedia, then |language=en renders the source's language in the local language without the copying editor having to do anything: at sq.wiki, for example, |language=en renders as '(në anglisht)'. Leaving |language=en aids editors who copy en.wiki articles to their home wiki and does no harm to editors here. Translation is aided by editors here using the ISO 639 language tag instead of the language name because MediaWiki will provide the name in the local language without the editor there having to translate 'English' to the local language or to the ISO 639 tag.

—Trappist the monk (talk) 18:25, 31 October 2023 (UTC)

If our only or primary rationale for injecting |language=en eventually millions of times into our content is to save someone the trouble at another wiki of adding their local equivalent of |language=en to citations they copied from us, then my opposition to this idea is now more solidified than it was to begin with, especially since a template translation tool can be configured to just add that parameter by default any time it is working with a template that it recognizes as having come from en.wikipedia and which doesn't say something like |language=ja (and the tool would have to be able to do that recognition or it would not be able to convert the highly particular template parameters to the local version in the first place).  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

I entirely agree. Please everyone let's not start havings bots or humans-pretending-to-be-bots add language=en to every citation. What a massive waste of time and attention. And please don't start randomly adding language=en to a hodgepodge subset of citations either. This is an unnecessary and unhelpful thing to include. –jacobolus (t) 06:43, 1 November 2023 (UTC)

No-one is suggesting any such thing, this discussion is actually about the opposite - the exclusion of |language=en not adding it. Many tools will automatically add this when editors use auto-creation, if you disagree with that this is the wrong talk page as those tools are not maintained here. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:23, 1 November 2023 (UTC)

The direct implication of al these "it's so useful for translating" claims (which have so far been unevidenced or easily dispelled, but maybe there is a better one yet to be made) is that eventually they will be imposed everywhere. It's a natural consequence of the argument that they're useful. They're only useful if they're imposed consistently. So raising this concern is in no way out-of-bounds.  — SMcCandlish ☏ ¢ 😼  21:05, 1 November 2023 (UTC)

They have not, and as above please don't try to restart this. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:30, 1 November 2023 (UTC)

"They have not" what? That has no clear referent, either as to what comes after "not" or what/who "they" is.  — SMcCandlish ☏ ¢ 😼  06:44, 2 November 2023 (UTC)

I know that I also have seen comments here and there also that the use for translation happens. Take it on faith that we're not spouting complete bullshit. :) You can still make your other points ad arguendum regardless.

As for mass-addition of |language=en, that is definitely a strawman. The only system that does anything remotely like that is Citoid (and other systems that use Citoid's output these days) when a website puts a language into its HTML. And like all such citations, I clean the ones that have totally garbage output that often get caught in our category dragnets and allow someone else to state a preference on whether |language=en actually should exist in the article or not. Following the principles of WP:CITEVAR even if this case is one ultimately of wikitext formatting (where we have already established the requirements of CITEVAR don't apply besides to the distinction between using CS1/2 and a hand-input style) and annoyance with what some see as clutter to-be-removed rather than clutter to tolerate for the health of the movement rather than our specific wiki. Izno (talk) 21:06, 4 November 2023 (UTC)

Yes, |url-status=dead in the presence of |url= and |archive-url= is meaningless. When given |archive-url= with an assigned value, Module:Citation/CS1 assumes that |url= is dead. It has been ever thus:

Cite book comparison

Wikitext	{{cite book|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com}}
Old	Title. Archived from the original on 2023-10-21. https://archive.org.
Live	Title. Archived from the original on 2023-10-21.

I don't know where that extra archive.org url is coming from

{{cite book/old}} does not know about |url-status=. Rewriting the example template to use |deadurl=yes returns the exact same result

{{cite book/old|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com|deadurl=yes}}

Title. Archived from the original on 2023-10-21. https://archive.org. 

Rewriting the example template to use |url-status=dead returns the exact same result with the live template:

{{cite book|archivedate=2023-10-21|archiveurl=https://archive.org|title=Title|url=https://example.com|url-status=dead}}

Title. Archived from the original on 2023-10-21.

|url-status=dead is not a substitute for {{dead link}}. |url-status=dead is never needed and is always redundant. Perhaps the dead keyword should be deprecated and support for it withdrawn.

—Trappist the monk (talk) 15:11, 31 October 2023 (UTC)

This would definitely help with editors misusing it to mark dead links. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:19, 31 October 2023 (UTC)

Okay, if it's really useless, and it's causing confusion with {{dead link}}, then I'm all for the deprecation, will stop using this parameter, and will remove it (and the old |deadurl=yes) when doing cite cleanup. Update: Now not sure sure of that, given the disputation below.  — SMcCandlish ☏ ¢ 😼  15:27, 31 October 2023 (UTC); revised: 18:16, 1 November 2023 (UTC)

The behavior described here, of always treating urls that have an archive-url as being dead, is fucked up. In most cases when there is a live url, we want to send readers to the live url, because in most cases updates to the content are helpful to readers. When Internet Archive Bot or whoever adds an archive-url as a prophylactic measure rather than because the url has gone dead, that should not suddenly make that version of the url be the only one that readers ever see going forward. —David Eppstein (talk) 16:02, 31 October 2023 (UTC)

If |url= is live when InternetArchiveBot adds |archive-url= to a cs1|2 template, it should set |url-status=live. If IABot is not doing that, you should take up the issue with its maintainer either at User talk:InternetArchiveBot or at User talk:Cyberpower678.

—Trappist the monk (talk) 16:24, 31 October 2023 (UTC)

I strongly agree with @David Eppstein. @Trappist the monk removing these parameters en masse without community consensus is disruptive. Please immediately desist until you have broad support. –jacobolus (t) 22:48, 31 October 2023 (UTC)

Here's what I said at user talk:Trappist the monk: Including "url-status=dead" is much more explicit communication to human editors than just leaving url-status out entirely. It's important because the internet archive's bot (and various human editors) keep adding archive URLs to still-living pages, so the mere presence of an archive URL is not sufficient to communicate that the original page is dead, but instead what it communicates is "whoever added the archive URL was too lazy to check", which then wastes follow-up effort by other editors manually checking all of these.

conveys no meaningful information – this is not true. url-status=dead clearly communicates that the link is dead. The complete absence of such a parameter does not communicate the same thing. You should not be removing these en masse without community consensus. –jacobolus (t) 22:50, 31 October 2023 (UTC)

Agreed - the parameter is useful. There are several news sites where current live url requires subscription for full text access, but the Internet Archived version from the first day the article was live allows the user to access the full text; when I use this cludge, I do typically include some note to the reader indicating this in the citation. Regards. User:Ceyockey (talk to me) 00:28, 1 November 2023 (UTC)

Well, if you're already manually including a note to this effect, using the parameter to also signify this in a really subtle way would seem to be redundant. For most use cases, we don't have a rationale to completely suppress the link to the original URL anyway, since a source that requires a subscription is not forbidden. I think the proper thing to do is this: {{cite news |title=Maps: Tracking the Attacks in Israel and Gaza |date=October 31, 2023 |work=The New York Times |url= https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |url-access=subscription |url-status=live |archive-url= https://web.archive.org/web/20231101004026/https://www.nytimes.com/interactive/2023/10/07/world/middleeast/israel-gaza-maps.html |archive-date=November 1, 2023 |access-date=November 1, 2023}} I just tested in a sandbox, and this has the original URL available and flagged with the subscription icon, and the archive-url available with no such flag. People with NYT subscriptions can use the former, everyone else the latter, and if a user clicks first on the former but has no subscription and just didn't pay attention to the icon, and has to backtrack and click the IA link instead, the sky has not fallen down. Especially if you're also adding a note along the lines of "Full text available free at the archive link." PS: This cite type definitely works for NYT, and Washington Post (e.g. [1]), but I don't know if IA's archival stuff manages to defeat other paywalls. Sometimes there might not be a useful archive-url with the full text, and we might be stuck with just |url=...|url-access=subscription. So it goes.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

Adding url-status=live is obviously helpful for a live link. But adding url-status=dead is also a helpful signal for a dead link, because it is explicit rather than implicit. A human reader of either of those can immediately tell what the person who added the parameter meant, instead of being forced to guess. –jacobolus (t) 06:46, 1 November 2023 (UTC)

Thanks for the advice. User:Ceyockey (talk to me) 00:01, 4 November 2023 (UTC)

Are we certain this claim about Internet Archive Bot is correct? Does someone have a recent diff of this or any other bot adding |archive-url= without |url-status=live when the original page is in fact live? If it is happening, wouldn't the solution be to fix the bot rather than add redundant |url-status=dead to zillions of citations? Is occasional human error sufficient reason to do it? Especially when the whole point of the archive-URL is that it is working copy of the source in question, so no reader is harmed by going to that version instead of the original anyway? I'm skeptical that we should be tolerant of longwinded code bloat on a massive scale as the solution to an alleged bot problem that should be easily fixable, and a human-error problem that is like unto an innumerable number of other trivial human errors we deal with without going to such extremes. I would think also that whether or not |access-date= is older than |archive-date= is already the functional system we have for determining whether the original URL has been checked for live status when adding the archive-url, or whether someone or something just tacked one of the latter on in drive-by fashion without checking whether the status is live.  — SMcCandlish ☏ ¢ 😼  06:06, 1 November 2023 (UTC)

whether or not |access-date= is older than |archive-date= is already the functional system no this is by no means adequate. It's based on a chain of dubious inferences which are regularly violated. –jacobolus (t) 06:47, 1 November 2023 (UTC)

I spot checked the first 30 or so diffs at Special:Contributions/InternetArchiveBot. I found one instance of IABot adding |url-status=live(Special:Diff/1182963903) and one instance of the bot adding |url-status=bot: unknown (Special:Diff/1182966277). To every other cs1|2 template touched by the bot, it added the superfluous |url-status=dead.

—Trappist the monk (talk) 13:38, 1 November 2023 (UTC)

The bot is generally using these parameters in a reasonable way. Having the bot be explicit about whether the URL is live or dead is a good thing.

Personally I'd prefer if people (or bots) never prophylactically added archive links to still-living pages except in special circumstances with some human intention involved (e.g. the "living" page is paywalled). –jacobolus (t) 14:04, 1 November 2023 (UTC)

The purpose of |url-status= is to tell Module:Citation/CS1 what to do when presented with both |url= and |archive-url=. In the absence of |url-status=, Module:Citation/CS1 defaults to linking |title= with |archive-url=; this is the module's default case. Setting |url-status=dead does not instruct the module to do anything different from its default (thus my conveys no meaningful information comment). The addition of |url-status=dead is therefor pointless, redundant, code bloat, clutter, pick your favorite term. Parameters that accomplish nothing have no value so should be removed.

—Trappist the monk (talk) 13:38, 1 November 2023 (UTC)

The purpose of url-status is to communicate the status of the URL, both to the citation rendering template, and also to human editors. –jacobolus (t) 14:05, 1 November 2023 (UTC)

The purpose of |url-status= is to control the selection of the live URL or the archive URL, as the documentation has always shown. It does not and has never been for the url-status of the source, does that make it confusing named - yes - should it be used to show the status of the URL - no that's what {{dead links}} is for as that template actually shows the link is dead to the reader (url-status=dead give no display output to the reader). -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:20, 1 November 2023 (UTC)

The way you tell *readers* that the link is dead is by switching the order of the links and making the archive link primary. The way you tell markup-reading *editors* that the link is dead is with the "url-status" parameter. Leaving this parameter out entirely is not explicit enough to clearly communicate the status of the URL. When the parameter is left out, human editors will waste their time double checking all of the links, because the status is not communicated clearly and unambiguously. –jacobolus (t) 22:52, 1 November 2023 (UTC)

To be more concrete/explicit, it is confusing to have:

No archive URL → url-status is implicitly alive

Archive URL → url-status is implicitly dead

This is okay as a fallback interpretation, but it is much better still to have an explicit url-status included whenever there is an archive URL, because it is then entirely clear what was intended and what the most-recently-checked URL status is. An editor who checks the link can just change dead ↔ live as needed. –jacobolus (t) 23:01, 1 November 2023 (UTC)

I think we're just saying the same thing slightly differently and from different directions. I agree that url-status is used to select whether the URL or archive URL is used.

The problem is that editors use it when no archive URL is present. So the URL is dead, no archive link is present, and they set |url-status=dead rather than use {{dead link}}. It's that scenario I'm saying is wrong. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:09, 1 November 2023 (UTC)

The problem is that editors use it when no archive URL is present – this is different than the problem I am complaining about, which is semi-automated edits which do nothing but remove url-status=dead from links that have an archive link. –jacobolus (t) 23:39, 1 November 2023 (UTC)

Yeah I thought we were talking at cross purposes. I'm against editors mass removing these, it's just a pain that it gets misused a lot. Editors also incorrectly add |url-status=live to cites with no archive url, which does generally get removed. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 01:56, 2 November 2023 (UTC)

Though it might not be a bad idea to allow url-status=dead even without an archive link, and format the output the same as {{dead link}} in that case. –jacobolus (t) 23:42, 1 November 2023 (UTC)

Which guidance does it violate, when a link is dead, an archive exists, and no alternative url is found hosting the information, to set the |url=(archive page)? I'm pretty certain this is against some policy or another, but I'm not sure which one, and it seems like a natural shortcut when citing deadlinked sources. Folly Mox (talk) 00:41, 2 November 2023 (UTC)

I concur with jacobolus. When there is no url-status there is a higher probability a mistake was made. The explicit url-status provides a greater degree of assurance what the last editor intended. It's not intuitive that a missing url-status is the same as dead, more like an expert editor's shortcut. -- GreenC 23:11, 1 November 2023 (UTC)

I'd be happy with renaming the field |archive-req= with yes/no/usurped/deviated being the answers, but at this point that would probably break to many things. My point was that it's not a field to mark the URL status, it's for showing which URL to use. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:17, 1 November 2023 (UTC)

Yeah, that would lead to massive breakage. And it's not clear what it even means ("archive-req"?).  — SMcCandlish ☏ ¢ 😼  10:19, 4 November 2023 (UTC)

Well, someone's still removing |url-status=dead from random articles, but I don't get the sense that there's actually a consensus in favor of the idea. I like the notion of removing any parameter that is actually redundant, but in fairness I'm not certain this is seen to be reundant, regardless what the original idea for implementing the parameter was. But that kind of concern in and of itself has not always won the day (e.g., I and others were basically just overridden on the use of |access-date= as an indicator of when someone last actually looked at the source, of any type, to see whether it agreed with the content it was cited for, and it has been disabled for anything without |url= because the original idea of the parameter was supposedly just indicating when the URL was checked to be valid/loading at all). People can have different points of view about these things. I am fairly certain that MEATBOT-style removal of |url-status=dead should probably not be happening while this discussion is unsettled, though. (Just as I have stopped normalizing ISBNs to hyphenless form since there's a discussion open at VPPOL about what should be done).  — SMcCandlish ☏ ¢ 😼  10:19, 4 November 2023 (UTC)

I continue to remove the parameter when it appears in an article of interest, though it's not a category I focus on. I do so for the same reasons as presented by Trappist, and for the same rationale for the parameter's creation. Izno (talk) 21:13, 4 November 2023 (UTC)

To some degree, I find it ironic and/or hypocritical that in the very same section we have people arguing that |language=en is cruft and unnecessary and to be removed despite at least one valid use case, and |url-status=dead (for dead URLs) is not. Izno (talk) 21:15, 4 November 2023 (UTC)

In my opinion, language=en is by far the majority case, and very obviously implicit for every citation and not at all a point of confusion. Also even for non-English links, leaving out an explicit mention of which language the citation is in is a kind of trivial oversight of minimal harm to readers (because for example the title is usually written in that language; someone seeing a source with title in German or Latin is not going to be excessively surprised that they don't get an English page when they click). There really isn't any need to be explicit that every ordinary citation to a source with a title and other metadata written in English points to an English language source. So including that parameter redundantly is pointless cruft. I don't mind if someone copy/pastes a citation from another language wiki and happens to leave language=en; in that instance its presence isn't doing any harm and doesn't need to be immediately cleaned up or anything. But I definitely don't want us to have a bot crusade inserting language=en to every citation site-wide, which would be extremely obnoxious to say the least.

By contrast, citations to web pages which also include an archive link are not inherently obviously aimed at a dead link. An archive link might also be included because e.g. the original source has since been put behind a paywall, or because the IABot or some editor trying to be helpful has obnoxiously added a "prophylactic" archive link to a still living page. Interpreting the presence of an archive link without any explicit mention of the URL status to mean the archive link should be primary is an okay default fallback (we have to assume something in this case, and neither choice is a priori obviously correct). But having an explicit parameter is better, because it communicates clearly to human editors examining the source. This parameter is not pointless, even if its presence does not change the rendered output. Having a bot or meat bot remove url-status=dead at large scale based on personal preference of one editor is also super obnoxious. –jacobolus (t) 23:07, 4 November 2023 (UTC)

But having an explicit parameter is better, because it communicates clearly to human editors examining the source. Agreed and that parameter is |url-status=live; that parameter and value not present? Assume dead.

—Trappist the monk (talk) 23:24, 4 November 2023 (UTC)

You can't say exactly the opposite of my point and then summarize that as "agreed". Come on... –jacobolus (t) 23:32, 4 November 2023 (UTC)

Apologies for necroing this thread, and so deep in the indents no less, but I noticed that User:Citation bot is removing |url-status=live from live URLs, and I immediately thought of the exchange just above. Do we, ultimately, have any idea what the default / unset value for this parameter indicates? Folly Mox (talk) 09:56, 3 December 2023 (UTC)

It's not "ironic and/or hypocritical" to oppose inclusion of one parameter and support keeping another for completely unrelated reasons. The "valid use case" for |language=en has been quite thoroughly refuted by multiple editors, and when the other side is asked for a better use case (and they keep saying they've seen one), they wave their hands and walk away. When it comes to |url-status=dead, a very broad, works-for-everyone use case has been presented, and the response so far as been an argument that the original purpose of the parameter was something different, and that there are technical alternatives (I even suggested one myself). These situations are not even slightly parallel. But my point is a process and propriety one, not a keep/kill that parameter one: there is an active dispute about this particular parameter+value, |url-status=dead (a dispute in which I'm now neutral), but at least two of you are still going around removing it at will despite vociferous objections. I may disagree strongly (and I do) with the objections to removing |language=en, but I have still stopped removing it until that dispute resolves, whether that happens tomorrow or in ten years.  — SMcCandlish ☏ ¢ 😼  23:41, 4 November 2023 (UTC)

Not refuted at all by anyone, just willfully ihnored. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:35, 5 November 2023 (UTC)

When I and at least one other editor point out that the "need", flagged as the reason to keep doing this stuff all over our articles, is better handled at the other end by the template-translation scripting, that is in fact a refutation. You can try to mount a rebuttal to that refutation, but a false claim that the original proposition was "willfully ignored" is simply untrue and does not consititute a rebuttal of any kind. It's just silly handwaving. I've asked at least 4 times now for vague and also handwavy claims that someone has seen (at some time, somewhere) some other, different translation-related use case to be substantiated with details, so that this alleged use case can be examined, and no one's done it. This is just blowing of smoke, and it's not going to fool anyone.  — SMcCandlish ☏ ¢ 😼  13:29, 5 November 2023 (UTC)

Everything I brought up you just handwaved away as not actually a problem, and swept it under the carpet. As I said above I'm not going into this again, but to say it's been refuted is not true. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:13, 5 November 2023 (UTC)

When someone complains of you engaging in a behavior like handwaving instead of producing evidence, you just using the playground game of "no I'm not, you are!" by using the term back at them reflexively is not a cogent argument, especially when they are not in fact doing it too. Nor is pretending that your evidence or concerns were ignored when they were actually addressed in considerable detail. The fact that the translation issue you want to solve has multiple technical solutions, and one of them is simple and clean (write a better translation script that does sensible things like assume English by default when translating from en.wikipedia) while the other is a total trainwreck (inject redundant code blather millions of times into en.Wikipedia articles) just is as it is. It doesn't make someone somehow in the wrong for pointing this out to you (even if takes multiple tries to get you to hear it). No one is doing you any form of injustice or eganging in bullshitty argumentation tactics with you, and no one is magically obligated to feel convinced by arguments you're impassioned about for some reason, when they don't actually align with the facts at hand and reasonable conclusions drawn from them.  — SMcCandlish ☏ ¢ 😼  15:39, 5 November 2023 (UTC)

I told you how it currently works in the real world and you completely ignored it, as you did any other argument made, at which point I have up trying to convince you as it's obvious you are unwilling to be convinced. You are the one handwaving away anything that doesn't align with your opinion and then saying I haven't produced any argument. I'm sorry if the way the real world works doesn't align with your opinion, but please stop trying to project that onto me. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:39, 5 November 2023 (UTC)

This is more bald-faced proof by repetitive re-assertion, and more childish and nonsensical "maybe I can WP:WIN by taking my opponent's words and just shuffle them around to refer to him instead of me" stuff, so I'm simply not going to respond to you any further.  — SMcCandlish ☏ ¢ 😼  16:55, 5 November 2023 (UTC)

FFS your entire argument against anything I've said has been that it doesn't apply. I already said I was done with this, but you started it up again. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:07, 5 November 2023 (UTC)

Let me try to paraphrase your argument in the various above posts, as best I understand it:

Some automatic tools for helping editors translate wiki pages from French -> English let them copy/paste citation templates unchanged, and a bot comes to clean up the citations. If those citations have language=fr explicitly set on them (is this common?), it will also be set in the English page, but if they don't, then the tools/bot doesn't add it and then the resulting English wiki page won't explicitly specify that citations are in French unless a human editor spends the trivial amount of extra manual effort adding it. You once saw a discussion somewhere which you now can no longer find, in which some editors on the English wikipedia said they want to provide the same service to foreign language translators, so have started adding language=en to their citations. Instead of removing those, we should follow their lead and add language=en widely, because it doesn't take up much space and would provide a nominal service to other language wikis.

Is the above fair, or do I entirely misunderstand what you are arguing for. I also have found it very vague and unconvincing overall. –jacobolus (t) 16:58, 5 November 2023 (UTC)

Fair enough, I don't mind if you disagree (WP:SATISFY), but that's a long way from saying that my arguments have been completely refuted.

As to the translation automation, that's just how it works. If anyone wants to change the real world situation, they should go talk with the people maintaining the translation tools. It's something way beyond the purpose of this talk page.

Also again this thread is not about, and I have not advocated for, the addition of |language= to any cites. I'm against mass removing ones that are already there. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:13, 5 November 2023 (UTC)

I also don't think language=en should be mass removed, because it's annoying churn for a triviality (cf. WP:COSMETICBOT). But often if I manually edit citations that have language=en set on them, I remove it.

Do you have a problem if language=en is removed alongside other more substantive edits? Or is your position that language=en should be left alone whenever it was set? –jacobolus (t) 17:23, 5 November 2023 (UTC)

I don't, as I believe it is useful for certain editors, but I have no great urge to restrict the actions of other editors. I am opposed to "it serves no purposes and should always be removed". -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:54, 5 November 2023 (UTC)

I would still characterize it as serving no purpose. The claimed "purpose" is trivial and almost entirely hypothetical. In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally (which is fine; it does little harm to leave this as a no-op). –jacobolus (t) 18:03, 5 November 2023 (UTC)

In my opinion the only real purpose of having this attribute is to not throw an error when it gets inserted lazily/accidentally Where are you seeing errors? There should be no errors related to |language= but there is a maintenance message when |language= is assigned a value that cs1|2 (MediaWiki) does not recognize (see Category:CS1 maint: unrecognized language).

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

Yes, there are no errors. That's the point. It would be bad for language=en to throw an error, even though it doesn't do anything. Making this a no-op that people are free to remove at leisure is an appropriate behavior here. –jacobolus (t) 19:10, 5 November 2023 (UTC)

If you feel it's trivial fair enough, but I'm sorry I really struggle to understand how the issue is hypothetical when it is how the translation of cites currently works. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:13, 5 November 2023 (UTC)

It's hypothetical insofar as something 99% of current citations on on this wiki to English language sources do not include this parameter, so anyone translating an arbitrary English wiki article to Russian or whatever is going to need to manually check every one anyway, so that this is not saving them any appreciable amount of effort.

If we care strongly about this particular group of users, it would be much more useful to fix the English -> X language tool to automatically fill missing language params with the implicit "en" instead of trying to expand the number of references here with language=en explicitly specified.

If that's the only purpose you can come up with for specifying 'language=en', then I say it should be fair game to eliminate them here. But bots and meat bots: please only make this kind of trivial change in a trickle alongside more substantive changes, instead of spamming everyone's watchlists with cosmetic changes. –jacobolus (t) 19:18, 5 November 2023 (UTC)

If you don't believe the use case is noteworthy I won't argue. But I believe we should be encouraging not discouraging the inclusion until someone bothers to change the translation tools. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:49, 5 November 2023 (UTC)

I concur with jocobolus, word-for-word. And as I predicted, the end goal of the other side on this matter is "encouraging ... the inclusion" of |language=en, spreading it to more and more citations, just as I said it was, but I was accused of straw-manning. Are we done now, or is there additional evidence and reasoning to present? This so far has been a complete rehash of the previous cycle.  — SMcCandlish ☏ ¢ 😼  19:55, 5 November 2023 (UTC)

That's what I believe, but as I've said repeatedly I don't support any official change to policy or documentation. Also your comments, particularly "of the other side", just shows the battleground mentality you've shown in this discussion. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:07, 5 November 2023 (UTC)

Every dispute has two sides (if not more). Using plain English is not a transgression. Casting "parting shot" aspersions at people's "mentality" and accusing them of battlelgrounding is not a good look. When I make a proposal (which happens all the time), if I find that is isn't going anywhere despite my efforts to outline my rationale (also happens all the time), I just walk away. There is no need to throw the rude gesture at those who didn't agree with you as if they're bad people for not taking your side (yes side – it's the completely normal term for this) in the discussion. All this personality stuff aside: What we have here is a conflict between a "Why can't we just do something nice for these folks doing hard work" sentiment running into facts that the proposed thing to do is not practical, there is a better solution immediately obvious, and doing it the proposed way will turn into a bigger and bigger mess, harder and harder to clean up later, the longer it operates. Not every well-intentioned idea is one we should go with.  — SMcCandlish ☏ ¢ 😼  20:57, 5 November 2023 (UTC)

I'm not going to read that I don't think it's going to get any better. I'm at a lose as to why a discussion about 12 characters in a cite has become so hostile. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:50, 5 November 2023 (UTC)

I don't think anyone's angry with you, doesn't like you, or is otherwise exhibiting hostility. People just disagree about things, including the weight of evidence and the solidity of reasoning given as rationales in discussions. No one enjoys being disagreed with (probably?), but disagreement happens, and it doesn't mean you're under attack or that people have a personal bone to pick with you. Hope that helps.  — SMcCandlish ☏ ¢ 😼  14:28, 6 November 2023 (UTC)

I'm sorry but I disagree you level of personalisation has been striking. I don't need any help I'm just confused by that level heat over something so unimportant. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:27, 6 November 2023 (UTC)

You keep saying things like "something so unimportant" and "only 12 characters", but two of us have repeatedly pointed out to you that 12 (often 15) characters repeated millions of times is not trivial, but you dodge this and keep re-asserting that it's just 12 characts and unimportant. You must understand that this is frustrating and comes across as refusal to engage meaningfully in the discussion.  — SMcCandlish ☏ ¢ 😼  17:05, 7 November 2023 (UTC)

Unless you believe I am lying I do not have to prove anything. You can accept my points or not, but everytime I have made a point you have attacked the comment not it's substance. So no, I have no more desire to continue this discussion with you.
And yes it is a minor thing. A million times 12 characters is a drop in the ocean of billions of markup characters. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:33, 7 November 2023 (UTC)

An assurance approximately equivalent in utility to |<citation verifies previous sentence>=y. My observance is that the real focus of all this arguing should really be pointed to ensuring that each and every live link that argues it's live (with or without an archive link) to be checked for liveness. I have spent quite some time in the general hitting ostensibly live citations that aren't (for which I have done the good duty of finding them appropriate archive URLs). Izno (talk) 21:17, 4 November 2023 (UTC)

Ah, but |<citation verifies previous sentence>=y gives us license to remove driveby {{cn}} tags slapped down in haste by editors with no time to check the source cited one sentence later. Folly Mox (talk) 23:29, 4 November 2023 (UTC)

Cite journal: "no journal name supplied" seems to be a common error, surely it can be identified

My heart sinks when I see "Script warning: One or more {{cite journal}} templates have errors; messages may be hidden (help)." because so often the message is hidden.

In my experience, the most common cause of this error is that the journal name has not been supplied (or doesn't do so using journal=). If there are many journal citations, it can take an unreasonable time to find the one in error and correct it. Surely the very first thing the syntax error checking algorithm should do when checking a {{cite journal}} call is that there is actually a named journal? 𝕁𝕄𝔽 (talk) 13:10, 2 November 2023 (UTC)

@Trappist the monk: Maybe it's time to unhide this particular error. GoingBatty (talk) 14:05, 2 November 2023 (UTC)

(edit conflict)

The Cite journal requires |journal= and Cite magazine requires |magazine= error messages were hidden because of this WP:AN discussion. Recently, we had another discussion. At the last module suite update, we created a {{cite document}} template. Creation of that template should be the last impediment to unhiding the missing periodical error message for {{cite journal}} and {{cite magazine}}.

Are there any who object to unhiding these error messages?

—Trappist the monk (talk) 14:18, 2 November 2023 (UTC)

I don't know of anyone who objected to those being errors. The objections were to flagging {{cite web}} without |website= and {{cite news}} without |newspaper=. Kanguole 14:41, 2 November 2023 (UTC)

They go hand in hand. Dis-use of the appropriate parameters in those templates is the same problem and the reason there were warnings for that as well (same exact spot in the code, etc etc). Cite journal just had the separate additional issue that it was being used as {{cite document}} which had no other alternative. Izno (talk) 20:51, 2 November 2023 (UTC)

They were all errors for a few weeks, but they've been treated differently for the last 4 years. I see that {{cite document}} is an additional issue, though. Kanguole 22:23, 2 November 2023 (UTC)

{{cite document}} no longer redirects to {{cite journal}} as it once did. What is the additional issue that you are complaining about?

—Trappist the monk (talk) 23:21, 2 November 2023 (UTC)

In that case, none. Kanguole 23:38, 2 November 2023 (UTC)

Yes, I guessed that the root of the problem was the strange decision to redirect {{cite document}} to {{cite journal}}. To take another perspective, I've seen citations dressed up as journal articles but it appears that the papers concerned didn't make the cut. So IMO, we absolutely should expose this error. --𝕁𝕄𝔽 (talk) 15:24, 2 November 2023 (UTC)

FWIW, in my experience many of the affected citations are not journal articles and should use a different template. Maybe I'm just unlucky, but I have found fewer that are just missing the title of the journal or magazine. I support exposing the error messages for {{cite journal}}. – Jonesey95 (talk) 17:30, 2 November 2023 (UTC)

But not for {{cite magazine}}? Why not?

—Trappist the monk (talk) 17:38, 2 November 2023 (UTC)

I didn't state a preference for {{cite magazine}}. It's probably fine to show error messages for it, but I don't see it often, so I don't have a sense of the ways in which editors are making errors with it. That template is causing at most 2,850 of the 48,000 pages in the error category, if my search-fu is working, so it's on the margin. – Jonesey95 (talk) 00:16, 3 November 2023 (UTC)

Yeah, you didn't, but since I asked about both, I read your positive support for journals as negative support for magazines. What is the margin? My experience with these {{cite magazine}} errors is that editors abuse the template in much the same way that they abuse {{cite journal}}.

—Trappist the monk (talk) 00:57, 3 November 2023 (UTC)

As I understand it, that's also the error category that holds {{cite book}}s where |work= has been specified. Not sure how many of the member articles stem from that combination. Folly Mox (talk) 17:54, 3 November 2023 (UTC)

Category:CS1 errors: periodical ignored.

—Trappist the monk (talk) 17:57, 3 November 2023 (UTC)

Thank you for the correction 🙏🏽 Folly Mox (talk) 20:05, 3 November 2023 (UTC)

I conclude that the consensus is strongly in favour of unhiding Cite journal requires |journal= and Cite magazine requires |magazine= error messages. My reading of the WP:AN discussion is that the flame-out was over a sudden imposition of a demand for {{cite news}} to have a work= (which could be argued but that's another discussion) and {{cite web}} to have a website= (which has always seemed redundant to me). There were also many instances of {{cite document}} redirecting to cite journal and thus throwing up false positives: that problem has been fixed with the new template for documents.
@Trappist the monk:, make it so! (I've always wanted a good excuse to say that ). --𝕁𝕄𝔽 (talk) 17:15, 3 November 2023 (UTC)

I've been watching but not commented and am strongly in favour of this if any more support was needed. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:17, 3 November 2023 (UTC)

Ditto.  — SMcCandlish ☏ ¢ 😼  08:07, 4 November 2023 (UTC)

Unhidden in the sandbox.

—Trappist the monk (talk) 20:08, 14 November 2023 (UTC)

Because the missing-periodical error message is the last of the hidden error messages, when we update the module suite the preview message that says:

One or more {{Cite ...}} templates have errors; messages may be hidden (help).

will no-longer be true. The intent of that message is to link to instructions that will allow editors to show messages that are hidden. Should we rewrite the message to something like:

One or more {{Cite ...}} templates have errors; (help).

or perhaps something like this:

One or more {{Cite ...}} templates have errors; (control error message display).

or is there some better message that we can present?

—Trappist the monk (talk) 20:20, 14 November 2023 (UTC)

How about something like:

One or more {{Cite ...}} templates have errors; (general help) - see the help link next to each error for assistance specific to that error

GoingBatty (talk) 22:31, 14 November 2023 (UTC)

Perhaps not? The link in the message does not link to 'general help' but rather, links to specific help about showing or hiding cs1|2 messaging.

—Trappist the monk (talk) 17:34, 15 November 2023 (UTC)

OK. Since the link in the message goes to instructions that will allow editors to show messages that are hidden, and this change would allow all errors to be shown, then I think the link is no longer needed for errors. (It's still needed for maintenance messages that are hidden.) Therefore, I propose:

One or more {{Cite ...}} templates have errors. Click the help link next to each error for assistance for that type of error.

Thanks! GoingBatty (talk) 18:55, 15 November 2023 (UTC)

I guess I don't think that omitting the link is a good idea. Help:CS1 errors § Controlling error message display includes instruction for editors who wish to completely suppress cs1|2 error messaging so we should retain the link in the summary message.

I want to update the module suite so, for the nonce, I'll leave the message as it is.

—Trappist the monk (talk) 18:24, 18 November 2023 (UTC)

module suite update 25–26 November 2023

I propose to update cs1|2 module suite over the weekend 25–26 November 2023. Here are the changes:

Module:Citation/CS1

• upgrade numeric names maintenance message to error; discussion
• add Greek character sort keys for error/maint messages in non-article namespaces; discussion
• improve global |display-<namelist>= handling; discussion
• for |language= look for tag first then name; discussion
• fix for phab:T117845; discussion
• bug fix when |work= and aliases in {{cite book}} ignored; discussion
• deprecate |authors=; discussion
• bug fix for {{cite book}} with |trans-<periodical>=; discussion

Module:Citation/CS1/Configuration

• Swiss German fix; discussion
• make extra text in volume non-hidden as it is kept clear these days
• upgrade numeric names maintenance message to error
• add Greek character sort keys for error/maint messages in non-article namespaces
• add maint cat for unflagged free-to-read dois; discussion
• update emoji_t to unicode v15.1; discussion
• remove no-longer-supported |chapterurl=;
• support single letter 2nd level domains for media TLD; discussion
• fix for phab:T117845
• deprecate |authors=
• unhide missing-periodical error messages; discussion

Module:Citation/CS1/Whitelist

• deprecate |authors=;

Module:Citation/CS1/Date validation

• |archive-date= / timestamp check to use internal reformatter for i18n; emit suggested date; discussion

Module:Citation/CS1/Identifiers

• add maint cat for unflagged free-to-read dois;

—Trappist the monk (talk) 23:34, 18 November 2023 (UTC) +last minute bug fix 15:27, 25 November 2023 (UTC)

Right now the numeric maint is emitting when the numeric error emits. It would be good to emit only the error in such cases. Izno (talk) 18:57, 25 November 2023 (UTC)

True, but when that happens it doesn't happen for the same parameter. For example, this emits two messages, the error message for |author=1234 and then maint message for |author2=4D2

{{cite book |title=Title |author=1234 |author2=4D2}}

1234; 4D2. Title. {{cite book}}: |author= has numeric name (help)CS1 maint: numeric names: authors list (link)

So not really redundant messaging.

—Trappist the monk (talk) 19:46, 25 November 2023 (UTC)

The maintenance cats also need to be updated for the new use, which is some numbers in the name, and recommended disposition (or not). Izno (talk) 18:58, 25 November 2023 (UTC)

Did that while you were writing you message.

—Trappist the monk (talk) 19:46, 25 November 2023 (UTC)

@Trappist the monk: Hi, I'm not sure if this issue was caused by this change or if I missed an earlier change that caused this, but 'CS1 maint: numeric names: authors list' is now being flagged for {{Cite tweet}} when there is a number in the |user= parameter even if there is no number in the |author=, |first=, or |last= parameters. I noticed this at Star Trek: Picard (season 1) which has a Twitter reference called "Culpepper3Split" where it is valid for the |user= parameter to have a number in it. I tested removing the number and it cleared the warning. - adamstom97 (talk) 01:13, 28 November 2023 (UTC)

That maintenance message is new with this update. {{cite tweet}} concatenates |last=Culpepper, |first=Hanelle, and |userHillview798= into |author=Culpepper, Hanelle [@Hillview798] which it hands off to {{cite web}} for rendering. This is not a {{cite web}} or Module:Citation/CS1 problem but is a problem of Module:Cite tweet – |user= value, the brackets, and the @ symbol do not belong in |author= as given to {{cite web}}.

You should raise this issue at Template talk:Cite tweet. See Template talk:Cite tweet/Archive 2 § Template-protected edit request on 8 March 2023 which describes a different but related problem. A solution proposed for that would have addressed both problems but was not adopted. I don't know why.

—Trappist the monk (talk) 02:07, 28 November 2023 (UTC)

Cool, thanks for the explanation. - adamstom97 (talk) 02:16, 28 November 2023 (UTC)

Which solution are you pointing to, the author-mask or the substitution? I'm having a hard time making sense of this :\ SWinxy (talk) 05:57, 28 November 2023 (UTC)

I don't know what you mean by the substitution. That term does not appear in the discussion I linked: Template talk:Cite tweet/Archive 2 § Template-protected edit request on 8 March 2023.

—Trappist the monk (talk) 15:09, 28 November 2023 (UTC)

I mean gsubbing the author field, which is what you seem to have proposed. SWinxy (talk) 16:42, 28 November 2023 (UTC)

Do you mean lines 39–41? Please be explicit; don't make me pull out your teeth one by one...

—Trappist the monk (talk) 16:53, 28 November 2023 (UTC)

Yes. Sorry, I'm trying to wrap my head around what was proposed to fix those problems. SWinxy (talk) 21:28, 29 November 2023 (UTC)

In addition to removing errors for {{Cite tweet}} when there is a number in the |user= parameter, we need to allow all CS1 templates to have digits in the author parameter. Template:Citation Style documentation says "author: this parameter is used to hold the name of an organizational author (e.g. a committee) ..." That would include, for example, The Jackson 5, OS/2 Development Team, Windows 95 Development Team, and thousands of other possible organizational authors that have digits. —Anomalocaris (talk) 11:48, 13 December 2023 (UTC)

Of course. The primary purpose of the maintenance category/messaging is to catch the junk that citoid-supported tools dump into the various name parameters, |last2=May 02, and the like (there are lots of name parameters that contain date fragments). Valid names-with-digits like those you list as examples are relatively uncommon but can be excluded from the maintenance category. Compare these:

{{cite book |title=Title |author=OS/2 Development Team}}

OS/2 Development Team. Title.{{cite book}}: CS1 maint: numeric names: authors list (link)

{{cite book |title=Title |author=((OS/2 Development Team))}}

OS/2 Development Team. Title.

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

Anomalocaris, this syntax is documented at Help: Citation Style 1 § Accept-this-as-written markup, although it's admittedly not particularly intuitive to find the solution when you're experiencing this problem. Folly Mox (talk) 14:19, 13 December 2023 (UTC)

Trappist the monk, Folly Mox: Thank you, I had forgotten about that workaround. —Anomalocaris (talk) 18:57, 13 December 2023 (UTC)

Another render of the source template

Hello! The Russian Wikipedia uses this module, as well as other modules that display source templates differently, for example:

• Cite journal:

Aries, Myriam B. C. & Newsham, Guy R. (2008). "Effect of daylight saving time on lighting energy use: a literature review". Energy Policy. 36 (6): 1858–1866. doi:10.1016/j.enpol.2007.05.021. Retrieved October 18, 2013.

• Our templates:

Aries, Myriam B. C. & Newsham, Guy R. Effect of daylight saving time on lighting energy use: a literature review (en.) // Energy Policy. — 2008. — Vol. 36, no. 6. — P. 1858–1866. — doi:10.1016/j.enpol.2007.05.021. Retrieved October 18, 2013.

Tell me, is it possible to use different styles for different templates? Are there render settings for each type? This module is very difficult to understand and I need help :) Iniquity (talk) 19:21, 20 November 2023 (UTC)

I presume that by Our templates you mean ru.wiki's templates, not en.wiki's templates. There are a lot of wikis that take a copy of en.wiki's Module:Citation/CS1 suite of modules. Each wiki can, and many do, modify their copy to suit their particular needs. Because there are so many wikis that have copies of the en.wiki module suite, it is impracticable to have simple settings to change the rendering.

I created a {{cite journal}} template from the first of your two example renderings:

{{cite journal |author=Aries, Myriam B. C. |author2=Newsham, Guy R. |name-list-style=amp |date=2008 |title=Effect of daylight saving time on lighting energy use: a literature review |journal=Energy Policy |volume=36 |issue=6 |pages=1858–1866 |doi=10.1016/j.enpol.2007.05.021 |access-date=October 18, 2013}}

Aries, Myriam B. C. & Newsham, Guy R. (2008). "Effect of daylight saving time on lighting energy use: a literature review". Energy Policy. 36 (6): 1858–1866. doi:10.1016/j.enpol.2007.05.021. {{cite journal}}: |access-date= requires |url= (help)

I then pasted that into my sandbox at ru.wiki and previewed which gave me a rendering that looks like this:

Aries, Myriam B. C.; Newsham, Guy R. (2008). “Effect of daylight saving time on lighting energy use: a literature review”. Energy Policy. 36 (6): 1858—1866. DOI:10.1016/j.enpol.2007.05.021. Дата обращения October 18, 2013.

The ru.wiki module is sufficiently old that it does not recognize |name-list-style= so the ru.wiki rendering does not have the ampersand between the author names and at ru.wiki emits a Неизвестный параметр error message. The ru.wiki rendering does not emit an error message for |access-date=-requires-|url=; uses curly quotes, an emdash separator between page numbers, and capitalizes the doi prefix. Certainly this experiment does not look anything like the Our templates example.

So what is it that you really want to understand?

—Trappist the monk (talk) 19:59, 20 November 2023 (UTC)

Yes, I know that the module is outdated and I'm currently trying to update it, thanks :)

I would like to know if it is possible for the 'cite journal' to display the source as in our (ruwiki) templates, for example: ru:Template:Статья. Iniquity (talk) 20:41, 20 November 2023 (UTC)

Of course it is, if you're willing to put in the work and are willing to redo the work every time someone at ru.wiki decides to update the module suite. I guess I gotta wonder if it might be easier to write a translator module that maps non-Russian parameter names to their Russian counterparts and then calls the appropriate Russian template. We have done that here for a few languages that make extensive use of Module:Citation/CS1. See Module:CS1 translator.

For example, at ru.wiki, ru:Template:Cite journal would call the translator module. The translator module might map the en.wiki parameters to these ru.wiki parameters:

|author= → |автор= – apparently |автор= cannot be enumerated so values from |author= and |author2= must be concatenated into a single value

|date= → |год=

|title= → |заглавие=

|edition= → |издание=

|volume= → |том=

|issue=, |number= → |номер=

|pages= → |страницы=

It would then call {{Статья}} from the translator module:

{{Статья |автор=Aries, Myriam B. C. & Newsham, Guy R. |год=2008 |заглавие=Effect of daylight saving time on lighting energy use: a literature review |издание=Energy Policy |том=36 |номер=6 |страницы=1858–1866 |doi=10.1016/j.enpol.2007.05.021}}

Aries, Myriam B. C. & Newsham, Guy R. Effect of daylight saving time on lighting energy use: a literature review // Energy Policy. — 2008. — Т. 36, № 6. — С. 1858–1866. — doi:10.1016/j.enpol.2007.05.021.

—Trappist the monk (talk) 23:29, 20 November 2023 (UTC)

We have done that here for a few languages that make extensive use of Module:Citation/CS1. See Module:CS1 translator.
Oh thank you for suggesting this module. This may help with some things.

Of course it is, if you're willing to put in the work and are willing to redo the work every time someone at ru.wiki decides to update the module suite. I guess I gotta wonder if it might be easier to write a translator module that maps non-Russian parameter names to their Russian counterparts and then calls the appropriate Russian template.
I would like to transfer all of our source templates to one module because I want to remove the entire zoo of templates that currently exists in ruwiki. And given that this module exists in a huge number of Wikipedias, the right goal is to remake everything so that it works on this module, and not to create my own. Iniquity (talk) 00:26, 21 November 2023 (UTC)

@Trappist the monk, can you help me with my request? :) Where is the rendering order described? Iniquity (talk) 11:15, 25 November 2023 (UTC)

There is no such description. Some parts of a rendered citation are assembled in individual functions – format_chapter_title(), language_parameter(), format_pages_sheets(), etc – while other parts and the whole are assembled in citation0(). This is why I suggested that you create a translator module if you must produce a rendering that is so distinctly different from a cs1|2 rendering.

Yeah, its a mess, and if I ever get up the courage to do it, I'll rewrite to make it more flexible.

—Trappist the monk (talk) 15:09, 25 November 2023 (UTC)

I'm understood, thank you! Iniquity (talk) 03:20, 26 November 2023 (UTC)

Consistency in parameter order

Is there a reason the various CS1 templates are inconsistent in their ordering of TemplateData parameters? They generally agree on author names being first, but then the order after that varies wildly. If there is no reason for this inconsistency, we should establish a standardized order — perhaps based on {{Cite web}}, since it's the most commonly used. InfiniteNexus (talk) 05:48, 21 November 2023 (UTC)

Why? The order is irrelevant. If you really want to spend your limited volunteer time normalizing them, I doubt anyone would revert you, but it seems rather pointless.  — SMcCandlish ☏ ¢ 😼  06:13, 21 November 2023 (UTC)

For one, Wikipedia:ProveIt (and possibly other tools) uses the TemplateData order to normalize citations. But if you think no one would revert/object, I will go ahead and change it. The only reason I came here first was because Template:Cite web#TemplateData had a very serious-looking stop sign. InfiniteNexus (talk) 06:20, 21 November 2023 (UTC)

Maybe there is a reason for that; Trappist the Monk would probably know. If ProveIt is using it in some automated fashion maybe something else is also, and expecting a particular order? I dunno.  — SMcCandlish ☏ ¢ 😼  06:32, 21 November 2023 (UTC)

The {{warning}} template was added by Editor GreenC at this edit. I agree that fussing with the parameter order in template data is likely a waste of time because anyone can edit the template data to add, remove, rearrange, whatever as they please. If you normalize parameter order for all twenty-eight cs1 templates and {{citation}} (and all of their wrapper templates?) I suspect that you will forever be chasing after random edits restoring your preferred order. Seems like a lot of work for no real benefit.

—Trappist the monk (talk) 13:54, 21 November 2023 (UTC)

ProveIt doesn't have bot approval for these automated cosmetic changes to citation markup, does it? Kanguole 14:27, 21 November 2023 (UTC)

I doubt it does, although I also don't think it edits as a bot (unsupervised). I agree that if all ProveIt has available on an article is reordering template parameters, it should decline the edit. Template parameter order is one of the few things on the project that truly doesn't matter at all. Folly Mox (talk) 00:13, 23 November 2023 (UTC)

I would certainly object to gnomes or bots going around making edits that change the parameter order in articles. That sort of thing makes it very difficult for humans looking at watchlists to figure out which edits made actual changes and which are cosmetic. I would prefer that the order be left in place unless you are making significant other changes to the citations. For what it's worth, the order I often use is authors first and then alphabetical by parameter name. I'm not going to defend that as a good order, but it's what the software I use produces and so I'm very unlikely to change that habit. That said, I don't care what order they are listed in TemplateData, as long as people editing articles don't think that the order is meaningful. So if you think your time is well spent making meaningless changes to TemplateData, go ahead. —David Eppstein (talk) 00:47, 23 November 2023 (UTC)

Completely agree it's another thing that should just be left unless you are overhauling the article. -- LCU ActivelyDisinterested «@» °∆t° 00:58, 23 November 2023 (UTC)

ProveIt is not a bot that makes automated cosmetic edits; it is a gadget currently used by 22,138 editors. When someone uses ProveIt to normalize citations on a page (which is a function provided by many other scripts that may not be as popular), they take full responsibility for such action, and this is usually done to maintain consistency within the article or clean it up in preparation for ease of readability when editing.

Given these responses, does that mean no one objects to the TemplateData parameter order being adjusted? If so, I will go ahead and do so. InfiniteNexus (talk) 01:15, 24 November 2023 (UTC)

It is not the TemplateData order that I would object to. It sounds like, however the templates are ordered, ProveIt will do what it does. But if someone were running around using ProveIt to normalize citations on a page, and this led them only to make cosmetic modifications such as parameter reordering with no significant improvement to the references, I would definitely object, just as I objected today to CitationBot running around reordering templates in a way that separated authors from their authorlinks. —David Eppstein (talk) 01:36, 24 November 2023 (UTC)

If someone were doing that in a systematic matter, they would obviously be considered disruptive and be reported to ANI. And I definitely don't think someone should be going around normalizing random articles' references without doing anything else, and for no particular reason. InfiniteNexus (talk) 04:42, 24 November 2023 (UTC)

That's probably the correct outcome, but I'm not certain it would happen, especially if the editor were not hitting pages on the same people's watchlists. I think it's better to prevent this sort of non-constructive editing by controlling how the software functions, rather than try to fix it after it's become a problem. I'll remind people that it took several months before User:Philoserf was brought to AN for disruptive usage of the ReferenceExpander script, and a second thread a month later before he was blocked for it, and we still haven't finished cleaning up after that.

It's safer to minimise the potential for disruption by script usage than it is to trust that editors won't use scripts disruptively, and trust that the process to stop disruptive script usage will function in a timely manner. Folly Mox (talk) 12:09, 24 November 2023 (UTC)

If you have a look at Wikipedia:Bot policy, you'll see that it covers what ProveIt is doing.

Personally, I object to normalization even when combined with non-cosmetic edits. Kanguole 09:07, 24 November 2023 (UTC)

Also, as long as ProveIt is doing this, if you change the order of the parameters in TemplateData, we'll see a bunch of useless edits where ProveIt re-normalizes previously normalized citations. Kanguole 09:34, 24 November 2023 (UTC)

Bookshelf NBK ID for the books of National Library of Medicine indexed via MEDLINE

I already requested that earlier at Help_talk:Citation_Style_1/Archive_72#Request_for_the_"nbk"_(NCBI_bookshelf)_attribute_for_"cite_book" but nobody replied, can you please consider this request again?

Please add the "nbk" attribute for the "cite book" template to specify the NCBI NBK number. You already have the "pmc" and "pmid" attributes, but the "nbk" is different. It refers to the NCBI bookshelf site that has different URL forman than PubMed Central. The URL to the bookshelf looks like https://www.ncbi.nlm.nih.gov/books/NBK557634/ (where 557634 is the NCBI NBK number). My idea is when you specify the "nbk" to the "cite book", the direct URL to the book at the NBI site will be generated. Currently, NCBI bookshelf books cannot be accessed directly from Wikipedia or other Wikimedia cites that allow the "cite book" template. Maxim Masiutin (talk) 01:20, 22 November 2023 (UTC)

Is there some better example, of something we'd actually cite? The example given above is to an article/chapter of tertiary summary material (i.e. something like Wikipedia itself) from what appears to be an unreliable source named StatPearls, all about medical topics but certainly not a source that passes WP:MEDRS. If there is something, why wouldn't we just put the URL to it in |url=? Are we expecting cases where the full text is available at some other URL but also available by NCBI? If so, do we need to care?  — SMcCandlish ☏ ¢ 😼  02:51, 22 November 2023 (UTC)

If you go to this URL, you will see {{PMID:32491566}} at the bottom of this page.

The NCBI NBK number is a link to the free content of a book.

Whereas free journal article content on MEDLINE has a PMC identifier that Wikipedia links, the books do not have PMC number, they have NBK number instead.

Therfore, Pubmed ID links to the information about this book but not actual content. While we can provide an identifier to a free content of an article via PMC, we lack the same oportunity to provide a direct link to free content of a book.

The argument about the reliable source should be addressed by each editor on a case-by-case basis, we should give a technical oportunity to link to the content directly, as we do for PMC which are also not always reliable sources.

See the following examples of NBK books: {{PMID:30860714}}, {{PMID:29262018}}, {{PMID:29262018}}, etc.

Thank you very much for considering my request! I'm strugging with the lack of this NCBI NBK number ID for years literally! Maxim Masiutin (talk) 03:01, 22 November 2023 (UTC)

But |url= already "give[s] a technical oportunity to link to the content directly". We shouldn't add custom linking parameters for source databases unless we're certain they have a lot of material we want to use as sources and the parameter would be frequently used by editors for reliable ones. The fact that you can find material that is reachable by |pmc= but which isn't good source material isn't an argument to add a new |nbk= parameter. PS: I checked the three PMIDs you gave above; one is a duplicate, and the other two just go to more of this StatPearls junk.  — SMcCandlish ☏ ¢ 😼  03:10, 22 November 2023 (UTC)

When we specify the |pmc=, we don't have to specify URL; the template generates URL automatically.

However, for NBK we have to specify url which is always an uniform having an NBK parameter.

So your reasoning on not adding it is because StatPearls is a low quality source? Maxim Masiutin (talk) 03:13, 22 November 2023 (UTC)

You can search "StatPearls" in pubmed or open URL https://pubmed.ncbi.nlm.nih.gov/?term=StatPearls and get many search results on the books I mentioned. Maxim Masiutin (talk) 03:15, 22 November 2023 (UTC)

Taking these points in order: Yes, but so what? Someone still has to copy-paste something from the URL bar or elsewhere on the source page into a citation template parameter, so |nbk= saves no work at all. Yes, and so what? It is not harmful or an imposition in any way to type |url= and paste a URL into it; this will actually be faster and easier that typing |nbk=, selecting a particular string perfectly from a URL, and pasting that in. No, my reasoning is that you haven't presented a valid use case for this, and when pressed for examples that might qualify as sources we would use you've just coughed up more links to the same poor source material. Finally, the fact that your poor source can be found via other searches is completely irrelevant to both whether it is a source we should use and whether we should have an |nbk= parameter.  — SMcCandlish ☏ ¢ 😼  03:22, 22 November 2023 (UTC)

Thank you for your reasoning. Still, I hope that the NBK parameter will appear in the future. Maxim Masiutin (talk) 03:32, 22 November 2023 (UTC)

Maybe StatPearls was not a good example, but there are books there which are not necessarily rubbsh, such as https://www.ncbi.nlm.nih.gov/books/NBK26830/ Maxim Masiutin (talk) 19:29, 25 November 2023 (UTC)

• You don't need a new field for this, you can just the the |id= field and the {{NCBIBook}} template.
  {{citation |last1=Kinter |first1=KJ |last2=Amraei |first2=R |last3=Anekar |first3=AA |title=Biochemistry, Dihydrotestosterone. |date=January 2023 |pmid=32491566 |id={{NCBIBook|NBK557634}}}}
  gives you:
  Kinter, KJ; Amraei, R; Anekar, AA (January 2023), Biochemistry, Dihydrotestosterone., PMID 32491566, NCBI NBK557634
  There are templates for most common identifiers. -- LCU ActivelyDisinterested «@» °∆t° 21:35, 22 November 2023 (UTC)

  Thank you very much! I didn't know that! You've made my day! Maxim Masiutin (talk) 21:39, 22 November 2023 (UTC)

Possible edge case to include: Titles and chapters that end with punctuation

Hello,

I don't know if this has been discussed before and rejected, and I'm not even 100% sure it's a good idea myself given that the case is rare. Right now, it appears that a period unconditionally appears after a title or chapter param. This probably simplifies the logic and also might make parsing the text easier. That said, it is a little odd if the title ends with punctuation such as "?", "!", or "...". Is it worth sticking some logic in there to omit the period in those cases as unnecessary?

Examples (title first, then chapter):

• Grabbe, Lester L. (2007). Ancient Israel: What Do We Know and How Do We Know It?. Bloomsbury. ISBN 978-0567110121.
• Berry, Helen (2017). "Gertrude Bell: Pioneer, Anti-Suffragist, Feminist Icon?". In Collins, Paul; Tripp, Charles (eds.). Gertrude Bell in Iraq: A Life and Legacy. Oxford University Press. pp. 127–151. ISBN 978-0-19-726607-6.

It's also possible that maybe this change makes less sense for chapter titles specifically, as there's an additional layer of quotation marks wrapping it. It also might look okay if there's a url= parameter, as the title will be linked but the period won't be, separating it some. But the "?." looks kinda doofy if a url isn't set, and I suspect it would be outright confusing for titles that end in an ellipsis (Reader: did the author intentionally pick four periods, or is it three periods + a Wikipedia-placed period?). Any thoughts? SnowFire (talk) 19:15, 22 November 2023 (UTC)

This is a known issue and has been known since at least July 2013. To do it right requires a rewrite of safe_join(). There is an existing hack that should correctly handle ellipses:

{{cite book |title=Title...}} → Title...

—Trappist the monk (talk) 23:16, 22 November 2023 (UTC)

Volumes with their own subtitles

Resolved

 – Seems to have been PEBKAC on my part.  — SMcCandlish ☏ ¢ 😼  23:26, 22 November 2023 (UTC)

Presently the templates are being "too smart for their own good" and throwing an error when they encounter something like |volume=VI: ''The Reformation'', and I am desirous that this misbehavior stop.  — SMcCandlish ☏ ¢ 😼  21:25, 22 November 2023 (UTC)

@SMcCandlish: Which article? Which template? GoingBatty (talk) 21:36, 22 November 2023 (UTC)

Something from yesterday. I'm not sure I remember at this point. Will see if I can dig it up again.  — SMcCandlish ☏ ¢ 😼  21:41, 22 November 2023 (UTC)

The only thing that should show a cs1 message is the comma, and it should as otherwise you end up with "VI: The Reformation,.". You will get an error message if you include "|volume=Volume VI: .." as you then end up with the duplicated "Vol. Volume VI:..". -- LCU ActivelyDisinterested «@» °∆t° 21:45, 22 November 2023 (UTC)

Found it. This:

{{Cite book |url=https://books.google.com/books?id=UxWZ-OmTqVoC |title=Mammals of the Soviet Union |volume=2, Pt. 2: ''Carnivora (Hyenas and Cats)'' |isbn=9004088768 |last=Heptner |first=V. G. |date=1989}}

now produces:

Heptner, V. G. (1989). Mammals of the Soviet Union. Vol. 2, Pt. 2: Carnivora (Hyenas and Cats). ISBN 9004088768.

But when I did this yesterday it threw an error that complained about something like extraneous/additional material in the volume parameter (I don't remember the exact red error wording), and I had to change it to |title=Mammals of the Soviet Union, Vol. 2, Pt. 2: Carnivora (Hyenas and Cats). I don't know why it's working now and didn't work yesterday.  — SMcCandlish ☏ ¢ 😼  21:51, 22 November 2023 (UTC)

Possibly either of these?
Heptner, V. G. (1989). Mammals of the Soviet Union. Vol. Volume 2, Pt. 2: Carnivora (Hyenas and Cats). ISBN 9004088768. {{cite book}}: |volume= has extra text (help)
Heptner, V. G. (1989). Mammals of the Soviet Union. Vol. 2, Pt. 2: Carnivora (Hyenas and Cats), . ISBN 9004088768.{{cite book}}: CS1 maint: extra punctuation (link)
Just having the volume title shouldn't cause any error messages. -- LCU ActivelyDisinterested «@» °∆t° 22:07, 22 November 2023 (UTC)

Best practices for a full citation with no author, when linked by shortened footnotes

Resolved

 – The help page now transcludes the advice from Template:Harvard citation documentation and includes two examples informed by the discussions below. Many thanks for the assistance and happy Thanksgiving, Rjjⁱⁱⁱ (talk) 08:45, 23 November 2023 (UTC)

I have a question about a help page which is directly giving advice about the CS1/CS2 templates. Are any of the no-author styles explained at H:SFN, misusing a parameter? The section at Help:Shortened footnotes#No author reads:

Some sources do not have a single author with a last name, such as a magazine article or a report from a government institution. Options include:

• For a newspaper or periodical, use the name of the publication and the date, or set the author parameter to "publication name staff".
• For a publication by an institution, use the name of the institution.
• Some style guides recommend using the title of the article (title-date).
• Other style guides recommend using "Anonymous" or "Anon."

This seems to contradict the template documentation, but I have seen a lot of people create citations using the |author= field this way. Regards, Rjjⁱⁱⁱ (talk) 22:44, 22 November 2023 (UTC)

You've gone to the trouble of quoting H:SFN which you then claim seems to contradict the template documentation but you fail to specify or quote that conflicting documentation. Which template? Which documentation?

—Trappist the monk (talk) 23:03, 22 November 2023 (UTC)

@Trappist the monk: Valid point, Template:Cite book/doc gives this example: |author=<!--Staff writer(s); no by-line.--> and explains the author parameter as so: this parameter is used to hold the name of an organizational author (e.g. a committee) or the complete name (first and last) of a single person; for the latter, prefer the use of |first= and |last=. This parameter should never hold the names of more than one author. Template:Cite news/doc and Template:Cite journal/doc contain the same text. Rjjⁱⁱⁱ (talk) 23:16, 22 November 2023 (UTC)

I changed the example in Template:Cite book/doc § Usage to match the recommendation at Help:Citation Style 1 § Authors.

Why do you think there is a contradiction? All that the cs1|2 template doc says is use real names, for humans prefer |last=/ |first= pairs for each human author. The |author=<!--Not stated--> is merely a recommendation to prevent future en.wiki editors from wasting their time searching for author(s) who have not been named. I don't see any of that as a contradiction.

I do think that making up names for any of the |author= aliases (|author=Anonymous etc) is wrong because that attributes the work to an author who appears to be named 'Anonymous'. Similarly, |author=publication name staff is just as bad. For periodicals, I think that the best solution for use with {{sfn}} is to set |ref={{sfnref|''<periodical name>''|<date> and {{sfn|''<periodical name>''|<date>}}

—Trappist the monk (talk) 23:45, 22 November 2023 (UTC)

Surely the advice should be to setup the |ref= field appropriately rather than misusing |author=. Especially when it duplicates publisher, and doubly so when it comes to constructs such as title/year. -- LCU ActivelyDisinterested «@» °∆t° 23:34, 22 November 2023 (UTC)

Yes, and this poor documentation probably explains why I keep running into redundant junk like |author=NYT staff, or even worse |author=The New York Times|work=The New York Times or |author=Museum of Modern Art|publisher=Museum of Modern Art. The material at H:SFN is clearly wrong, or at least badly misleading. You might need to use a short footnote that read something like "Museum of Modern Art (2023)" when there is no specified author, but the way to template this is to use |ref={{harvid|Museum of Modern Art|2023}} in the main citation, not to do a bogus |author=Museum of Modern Art that is redundant with |publisher=Museum of Modern Art. This can probably be resolved by editing H:SFN and the docs of Template:Sfn to include specific examples of this sort, and to explicitly say not to abuse the |author= or |last= parameter to kluge this. PS: {{harvid}} has been moved to {{SfnRef}}, and it may be preferable to update the mentions of {{harvid}} to use the current actual name of the template.  — SMcCandlish ☏ ¢ 😼  23:42, 22 November 2023 (UTC)

+1 -- LCU ActivelyDisinterested «@» °∆t° 23:50, 22 November 2023 (UTC)

I copied the text by Charlie Gillingham from Template:sfn/doc to Help:Shortened footnotes, changing "harvid" to "sfnref", which already suggested using |ref=.[2] And regarding the question of why I saw the language as contradictory, I was saying that advice to use the title of the work or a description of the author (at H:SFN) seemed to contradict the advice to use a person or organization's name (at Template:Cite book/doc). I was uncertain, so I asked. Rjjiii (ii) (talk) 00:53, 23 November 2023 (UTC)

Also, thanks all for the input, Rjjiii (ii) (talk) 00:54, 23 November 2023 (UTC)

Keeping in mind that {{sfn}} should be short, and this is all about convenience for editors (i.e., not users), I think the |ref= should be encouraged to be short as well, so rather than |ref={{harvid|Museum of Modern Art|2023}}, it should be |ref={{harvid|MMA|2023}} which will very likely be unique among refs on the page (and if not, there are alternatives). Mathglot (talk) 01:14, 23 November 2023 (UTC)

I disagree. Initialisms are inherently obscure so in general should be avoided. But, surely, if you are going to use an initialism, and the source has a commonly used initialism, use the source's initialism, not one that you made up or is used by some other organization. In your example, if you must use an initialism it should be 'MoMA' not 'MMA' (commonly used for Mixed Martial Arts}. For the avoidance of doubt, both long- and short-form citations should use the same name.

—Trappist the monk (talk) 01:25, 23 November 2023 (UTC)

Yep.  — SMcCandlish ☏ ¢ 😼  02:16, 23 November 2023 (UTC)

The example from the {{sfn}} doc page includes a generic "BGI" initialization. I've replaced that on H:SFN with a "MoMA" shortened footnote.[3] I haven't changed anything on the template documentation. Rjjiii (ii) (talk) 02:42, 23 November 2023 (UTC)

Unnecessary pile-on support for this statement. Anything used in the {{sfnref}} should either appear verbatim in the full citation or be listed in a "(Cited as Short Name)" parenthetical immediately following the full citation. Folly Mox (talk) 05:35, 23 November 2023 (UTC)

And by the way, for those who are talking about "modify the sfn doc" (which I generally agree would be a good thing) it's a little hard to find; it's at Template:Citation Style documentation/author. Mathglot (talk) 01:44, 23 November 2023 (UTC)

@Mathglot: Thanks for helping out. I see you've transcluded the text from Template:Harvard citation documentation#No author name in citation template. That seems easier to maintain. Would it be wise then, to transclude the whole thing, and use whichever example is best on that page? Rjjⁱⁱⁱ (talk) 04:03, 23 November 2023 (UTC)

Also, what do you mean about "the table column presentation is messed up in this one"? I see a 2x2 grid in both? Rjjⁱⁱⁱ (talk) 04:06, 23 November 2023 (UTC)

Yes, it's 2x2, but left col is 90% of page width on a computer monitor; are you using only mobile to view it? Maybe I should verify with some other browsers, in case it's just me? Mathglot (talk) 05:07, 23 November 2023 (UTC)

Works now; your "3rd time" fix did it. Must've been the url. I've seen that issue before, and I forget how I fixed it, but there's a way. In the meantime, the shorter url works fine. Mathglot (talk) 05:24, 23 November 2023 (UTC)

@Mathglot: thanks for the explanation! I tested the mobile skin and both desktop skins but only on Firefox. Chrome keeps the URLs as one line and Firefox breaks them at the slashes. As soon as I read your "left col is 90%", I realized how I goofed. I've run into this problem before and totally forgot about it. With a smaller URL and a space before the parameter, it now looks fine on desktop Chrome, mobile Chrome, mobile Safari, Edge, the android app, and some niche browsers. Thanks again, Rjjⁱⁱⁱ (talk) 05:47, 23 November 2023 (UTC)

Guess I'm a niche browser person; I use Vivaldi almost exclusively, others on mobile, or for testing or special purposes. Mathglot (talk) 06:35, 23 November 2023 (UTC)

As far as transcluding the example as well: excerpting from a Template that can have params is tricky, because {{Excerpt}} doesn't pass params; so I conservatively excerpted only the top part with the intro paragraph and bullet list, because I could easily see that there were no template params like {{{1|}}}; the markup code below it was denser, and I didn't want to risk a mistake by transcluding it if it used params. If it doesn't, that should be excerptable as well. Mathglot (talk) 05:11, 23 November 2023 (UTC)

Ordering of full citations

If an article is using shortened references, that means a full list of sources appears in alphabetical order according to the first element; the only fields which can be first in a CS1 template are |author=/|last= or |editor-last= I believe. If there is a |ref={{harvid|MoMA|2023}} then a reader should be able to find MoMA accordingly amongst other M-names and so the first element should include whatever tag the reader will use to find the source in an alphabetic list.

For the curious, here's the CMoS:

If a publication issued by an organization, association, or corporation carries no personal author’s name on the title page, the organization may be listed as author in the reference list, even if it is also given as publisher. To facilitate shorter parenthetical text citations, the organization may be listed under an abbreviation, in which case the entry must be alphabetized under that abbreviation (rather than the spelled-out name) in the reference list.

Umimmak (talk) 06:37, 23 November 2023 (UTC)

Wikipedia isn't bound by a single thing CMoS says. Our own material at WP:CITE (including WP:SFN) requires neither shortened footnotes (much less ones in CMoS style in particular) nor an alphabetical list of sources. It generally makes sense to provide one, if an article is using shortened footnotes, but putting a {{cite web |publisher=[[Museum of Modern Art|MoMA]] |...}} in alphabetical order under "MoMA" is perfectly fine. If some reader's head would just explode upon encountering this, they are not competent to be reading our material in the first place. And no one reads lists of citations like a novel. They get to a citation by clicking on a link to it. If for some reason they did not but are manually hunting around for a MoMA source in a list of sources (why?), all they have to do is Ctrl-F MoMA Enter (or on a Mac Cmd-F MoMA Enter). If this still just somehow doesn't compute for someone on the editorial side, they can do the source list entry as * MoMA: {{cite web |publisher=[[Museum of Modern Art|MoMA]] |...}} (though I think other editors would later remove the leading "MoMA: " as extraneous and silly, treating our readers as if they had brain damage). Nothing said above is any excuse for doing a bogus |author=MoMA.  — SMcCandlish ☏ ¢ 😼  07:18, 23 November 2023 (UTC)

The tone of your comment was needlessly rude…

We aren’t bound by Chicago, obviously, but I think it’s worth seeing what other style guides do in similar situations. Why alphabetize anything if the links take an online reader directly to the source or they can use a search function? People sometimes print out articles, the Creative Commons license allows materials to be used elsewhere which might not have as robust links, links can also be be broken for a variety of reasons and having sources in an order which makes intuitive sense to the reader might be an asset that the editors of some articles might desire.

If there is no author, the first part of the citation would be the title; MLA uses an abbreviated title in its parentheticals when there is no author, and this is another option if it’s really that bad to repeat information. That way sources can be still sorted alphabetically by their first element and by whatever appears in the shortened citation. Umimmak (talk) 08:02, 23 November 2023 (UTC)

I already said it was probably a good idea to alphabetize them. If you insist on having the first element on the line be the name by which it is alphabetized, I already provided you a way to do that without fudging citatation template parameters, though there is no reason in the first place to suppose that our readers are so dense they can't understand that an entry with no author which is alphabetized in the Ms between Michaels and Munster is under MoMA, the publisher name.  — SMcCandlish ☏ ¢ 😼  08:14, 23 November 2023 (UTC)

Way off topic: This ship may have sailed, but {{harvtxt|ref=none|Last|YYYY}}.  will create exactly the citation format for the bibliography when given the same parameters as {{sfnref}}. The citation templates could generate this when fed sfnrefs, but I don't know if it's worth the effort. It also won't be highlighted from the pinball links.

References

• SSAC (2023). "Black History Month Profile: Leroy Chollet (Loyola)". SSAC Sports. Montgomery, Alabama: Southern States Athletic Conference. February 27, 2023. Archived from the original on March 29, 2023. Retrieved March 29, 2023.

Rjjⁱⁱⁱ (talk) 08:40, 23 November 2023 (UTC)

Simpler to just do plain text:

• SSAC: "Black History Month Profile: Leroy Chollet (Loyola)". SSAC Sports. Montgomery, Alabama: Southern States Athletic Conference. February 27, 2023. Archived from the original on March 29, 2023. Retrieved March 29, 2023.

if the goal of this stuff is just to ensure that the citation line-item begins with the string it is alphabetized by. Which, again, is not a requirement that we have; it's just something a few editors want to have happen for reasons I find non-compelling since it's obvious in an alpha-ordered list of such sources that this one is alphabetized under "SSAC Sports". If this is just for editorial benefit, Mathglot's approach below gets the job done, though would be simpler to type and easier to read as <!--Aron 1962--> than <!--{{sfn|Aron|1962|p=}}-->.  — SMcCandlish ☏ ¢ 😼  09:29, 23 November 2023 (UTC)

True, and maybe I'm taking ease of use to a fault, but what I want to do is kill two birds with one stone, demonstrating the alphabetization element first, as well as having a copy-paste element readily available that makes use of {{sfn}} as brainless as possible. There are *so* many errors with it (as ActivelyDisinterested can attest), that anything I can do to assure the correct {{sfn}} formulation is used, is a step in the right direction, and worth the (minimal) extra effort in typing out a few more characters. That said, SMcC's (how do you abbreviate a name like that, anyway?) version does the job. Mathglot (talk) 09:43, 23 November 2023 (UTC)

Fair enough. I guess the articles I'm shepherding that use one form or another of shortened references haven't had a problem of "drive-by" users making mucked up sfn instances with wrong author names or dates in them, so I'd never had a "show them how to do the citation right" need. PS: Yes, SMcC or S.McC. or S. McC. would be pretty typical. My pool team has two Johns, and we call them John McN. and John P. in texts. If the latter had been Irish, he might have ended up compressed to John O'P. :-)  — SMcCandlish ☏ ¢ 😼  09:55, 23 November 2023 (UTC)

Just to say there are so many errors with it because it doesn't appear that the error category has ever been cleared down before. New errors are generally caused by inexperienced editors not understanding how referencing should be done. -- LCU ActivelyDisinterested «@» °∆t° 12:07, 23 November 2023 (UTC)

The alphabetization of sources in a "Works cited" or "Bibliography" section is mostly for the user, but has benefits for the editor wishing to expand the article and reuse the citations as well. Unfortunately, it's not always easy to find the "alphabetization item", which might be last1, last, author, surname, editor1-last or something from |ref=, and which might be placed anywhere in the template... tick, tock; .... tick, tock; ... tick, tock; ... Have you found it, yet? I finally got tired of this, and to make it easier for myself on subsequent edits, and for other editors, I hit upon the solution I used in Liberation of France#Works_cited (edit ). It makes it easier for editors, and has no effect on readers. Mathglot (talk) 09:12, 23 November 2023 (UTC)

An easier solution is to include alphabetical breaks <!-- A --> etc. As can be seen in the Bibliography of Historiography of Christianization of the Roman Empire. Any editors can just search the correct string, and it's very simple and easy to understand for new editors. -- LCU ActivelyDisinterested «@» °∆t° 12:12, 23 November 2023 (UTC)

@ActivelyDisinterested Naively done as there causes a WP:LISTGAP. Please feel free to correct it as you see fit. Izno (talk) 19:07, 25 November 2023 (UTC)

They're not causing LISTGAP at Historiography of Christianization of the Roman Empire, maybe that only applies if you haven't used {{refbegin}}/{{refend}}. -- LCU ActivelyDisinterested «@» °∆t° 19:13, 25 November 2023 (UTC)

ActivelyDisinterested, yes, actually, the use there is a LISTGAP problem. A comment on its own line will break the lists, which is what LISTGAP concerns itself with. IznoPublic (talk) 03:10, 26 November 2023 (UTC)

Are you suggest that a screen read would want to read through the hundred+ cites in that article as if the where a list? Maybe as a sleep aid. And if they did the list would be sectioned alphabetically. This isn't four items in an infobox. -- LCU ActivelyDisinterested «@» °∆t° 12:14, 26 November 2023 (UTC)

@ActivelyDisinterested no, they don't, and that's the problem. What they will hear is "list of N/26 items, would you like to listen?" times 26 as they attempt to come to the end of the section. This is categorically worse for navigation. Moreover, they will have no idea that each is separated by a letter, the only information they get is "list of N/26 items" before diving into each. Izno (talk) 21:41, 26 November 2023 (UTC)

Year parameter

Sometime ago I happened to read in this page that the use of year parameter was discouraged; but now I am unable to find that topic anymore. Do I have to assume that the year parameter is reinstated in full? Thanks. Carlotm (talk) 02:43, 24 November 2023 (UTC)

Nah, use it when appropriate, like when that's all there is, often for books. -- GreenC 04:22, 24 November 2023 (UTC)

User:Carlotm, are you sure you're not remembering the thread at Wikipedia talk:Citing sources#Changing the "year" parameter documentation? I mix up that page and this one in my own head with some regularity. Folly Mox (talk) 12:17, 24 November 2023 (UTC)

The suggestion is the same as always, use |year= or |date= but not both as it's redundant (with one exception, but that's to much to get into). -- LCU ActivelyDisinterested «@» °∆t° 16:02, 24 November 2023 (UTC)

Thanks to all.Carlotm (talk) 06:33, 25 November 2023 (UTC)

Misspelling parameter

Page: Module:Citation/CS1. When I was worked at adaption some parameters from English Wiki to Ukrainian Wiki, I found out that at the line 2648 in module Citation/CS1: "if (utilities.in_array (config.CitationClass, {'book', 'encyclopaedia'}) and (utilities.is_set (Periodical) or utilities.is_set (ScriptPeriodical) or utilities.is_set (ScriptPeriodical))) then" there is mispelled parameter. Because there are two ScriptPeriodical and they are in if statement, so there in no to double check the same parameter twice. Therefore, I think one of the parameter needs to be changed to TransPeriodical. Repakr (talk) 15:02, 25 November 2023 (UTC)

Just in the nick of time... Yep, you are correct, thank you. I have fixed that in the sandbox:

Cite book comparison

Wikitext	{{cite book|title=Title|trans-newspaper=Trans Newspaper}}
Live	Title. {{cite book}}: |trans-newspaper= ignored (help)
Sandbox	Title. {{cite book}}: |trans-newspaper= ignored (help)

—Trappist the monk (talk) 15:21, 25 November 2023 (UTC)

Proposed script-author parameter

I'd like to re-raise a proposal that was previously supported at

• Help talk:Citation Style 1/Archive 64#Citing native scripts of the author's name and/or title of a work in Citation Style 1

specifically that the value of |script-author= be rendered in parentheses following the author name, and similarly for other people.

This is particularly important for Chinese and Japanese names, for which the romanized form is lossy. Many editors are adding the original names to other parameters, which messes up the metadata and (if |author= is used) the refname used by the {{harv}}/{{sfn}} family. The solution is to give them somewhere else to put this name so that it will be displayed.

I am not proposing the more elaborate forms suggested here. Kanguole 23:23, 25 November 2023 (UTC)

Outing myself as the editor who recently changed a related style guideline from recommending one wrong way to cite East Asian names (after the not-wrong way, ofc) to recommending a different wrong way.

I'd also be glad to see a |script-author= parameter join the other |script-parameter= team. Yes, the use case is different (don't need to worry about italics), but it would keep the metadata clean and allow shortened footnotes to function intuitively without use of |ref= (this applies to only one wrong way of citing East Asian authors).

Somewhere down the road, this could also help deal with the #Author roles problem discussed above, which current practice blocks. Lastly, |author-mask= is tedious, and fiddly when more than one author is attributed (since it suppresses commas, ampersands, and "and" between authors).

I recognise this is a whole can of cans (superior to a can of worms, which tbh should be stored fresh or dried), because it opens the door not only to |script-editor= but also potentially to |script-author16= and pals. Folly Mox (talk) 00:40, 26 November 2023 (UTC)

It's unclear to me whether this is a proposal for usage like 1) |script-author=zh to indicate the language, or 2) |script-author=李四 to provide the name in some other script. If no. 1, I can see this potentially adding utility, if COinS would support metadata to generate indicating the script used for the author name. If no. 2, then I don't see a reason for this when we have |author-mask=.  — SMcCandlish ☏ ¢ 😼  08:23, 26 November 2023 (UTC)

Any |script-parameter= requires both a language code and a value, separated by a colon, like |script-author=zh:顧愷之. The point (as I see it) is to be able to display the native names without touching the metadata or having to fiddle with |author-mask=, which requires duplicating information as well as sometimes including punctuation, which is difficult to remember. Folly Mox (talk) 09:23, 26 November 2023 (UTC)

Ah, I see. I like the idea of not redundantly repeating strings, but it comes at the cost of adding a complicated parameter (actually set of parameters) with two-part syntax, which seems very error-prone to me. Especially if |author-maskn= actually does work fine, just at the cost of some repeated name strings. 06:17, 27 November 2023 (UTC) — SMcCandlish ☏ ¢ 😼 

Not sure I understand why we need this. If the cited source provides both the native-script name and its transliteration then it seems to me that a concatenation of both can be included: |author=<native> (<transliteration>) or |author=<transliteration> (<native>). Is it common for sources to provide both? If not, then no need for |script-author=.

If the majority of ja or zh sources provide names in native and transliterated forms then perhaps there is a need for |script-authorn=. If that is the case, how are we to order the native and transliterated forms in the rendering? Native first? Transliterated first? Which of them contributes to the template's CITEREF id? Only ja and zh or do we also include ko?

—Trappist the monk (talk) 15:50, 26 November 2023 (UTC)

I would think we'd show Latin-script first, and emit that version in the metadata (both COinS and CITEREF), since this is en.wikipedia. And should probably be script-neutral, since it would be usable for Cyrillic languages, South Asian languages of various scripts, and so on.  — SMcCandlish ☏ ¢ 😼  06:17, 27 November 2023 (UTC)

"Need" is a strong word. It would be convenient for editors and not much more. I agree with SMcCandlish just above that transliterations would be displayed first, and the only version incorporated into the metadata.

While it would certainly be nice to be able to include people's native names in any script (to facilitate learning more about them or finding other publications in their native language), to my knowledge the only scripts that have one-way transliterations into Latin that cannot be reverse engineered are Chinese and Japanese. Some scripts that have various transliteration styles, such as Korean, will present the same name differently depending on the age of the source and possibly other factors.

|author-mask= works, and this idea would duplicate the (predominant?) use case that has grown up around it despite its original intent. It does seem cleaner and more intuitive to match the other |script-parameter= parameters for the "people" fields, and would flatten the learning curve a bit, be agnostic between punctuation and author attribution positioning, and reduce duplication of data, which makes it a more attractive best practice.

Side bonuses would be the ability to create a maintenance category for parentheticals in people fields, as well as the ability when |script-name=zh: or ja: or ko: is present, to set the default name presentation to last first instead of last, first.

I do understand that it would be non-trivial to implement, and isn't strictly necessary since the current system functions, albeit a bit hackily for this sort of information. Folly Mox (talk) 12:30, 27 November 2023 (UTC)

I'm a native Anglophone, and I sometimes have to look at the original Hebrew before I can parse a transliterated word. I suspect that transliterations of other Semitic languages are also problematicval -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:37, 27 November 2023 (UTC)

On the question of sources, it's not especially common to provide both native and transliterated names in the publication by the author, but it does happen. This is more common in books than journal papers, and mostly confined to the humanities while absent in the sciences. In bibliographies (which is basically what we're doing), the practice seems almost universal in the humanities.

The major use case of knowing a person's real name, for me, is to be able to identify them in native language publications. This lets me locate the original source, find out if there's more by them on a subject, check their reputation and affiliation, and see if there's an interwiki article about them if en.wp lacks one.

I don't recall ever seeing an English Wikipedia article where Chinese authors are credited solely by their native names, and the practice is already widespread of including both versions where |author-link= has no target.

One final point is that this goes both directions, for example Sarah Allan is credited under the transliterated name 艾蘭 when publishing in Chinese language publications, Edward Shaughnessy writes under the name 夏含夷, etc. I'm not aware of any cases of English Wikipedia citing zh / ja language sources by authors who write predominantly in English and other Latin script languages, but we would want to have both versions of the name for these sources as well so they could be located for verification. Folly Mox (talk) 13:10, 27 November 2023 (UTC)

This crude search (times out) suggests that editors do write |authorn= parameters using only non-Latin characters. There are lots of results where |authorn= is empty or has languages other than CJK, but still there are plenty of CJK-only author names.

This crude search (times out) attempts to find |authorn=<romanized> (<native>).

This crude search (times out) attempts to find |authorn=<native> (<romanized>).

The latter two searches suggest that en.wiki editors do not commonly include both native and romanized versions of author names.

I asked Is it common for sources to provide both? because somewhere around here there is some instruction that editors should not engage in translation of quoted text. I view romanization of non-English names as a form of translation. In much the same way that |trans-title= should not be used if the source itself does not provide an English translation, so too, if the source itself does not provide a romanization of a native name, en.wiki editors should not attempt to romanize those native names.

—Trappist the monk (talk) 16:00, 27 November 2023 (UTC)

Huh I've always followed the guidance at WP:RSUEQ: If you quote a non-English reliable source (whether in the main text or in a footnote), a translation into English should accompany the quote. Translations published by reliable sources are preferred over translations by Wikipedians, but translations by Wikipedians are preferred over machine translations.

I consider citing a source as being in the same sphere as quotation, and almost always translate titles if I'm able. Transliteration of Chinese names is usually easy, to the point where most Chinese names could be transliterated by algorithm with very few errors.

As an aside, on articles where only native names are used in the bibliography, are shortened footnotes of the form {{sfnp|劉|2010}}? Seems like it might be offputting for our target audience. Folly Mox (talk) 17:15, 27 November 2023 (UTC)

But RSUEQ is about inline and block quotations in the article body (or in the |quote= parameter of a citation), which are meant to be read and understood by our readers as prose. But our citations of source titles and authors are not article content in this sort of sense; the only reason we have them is for identifying and finding the sources to verify the content, so there is no need to make up or machine-generate a source title or author title transliteration or translation, since it won't match the actual title/author of the source as published and thus won't help find it, and may even mislead the reader into picking the wrong source that happens to have the same name in English. It is noteworthy that the "Citing" section, right above the "Quoting" section that is the target of the WP:RSUEQ shortcut, does not advise providing translations or transliterations. It is not an accident. As I noted earlier (below) someone might argue that there is still some kind of reader utility in providing such translations or transliterations anyway, but there are counters to this argument.  — SMcCandlish ☏ ¢ 😼  23:16, 28 November 2023 (UTC)

Wikipedians adding their own personal or tool-generated transliterations and translations for source titles and transliterations for authors probably is not a good idea; it leans toward WP:OR (though I guess it's not technicaly part of the "article content" in the strict sense), is potentially error-prone (or bias-prone, e.g. favoring an old "traditional" transliteration style that is no longer the one typically used), and doesn't do anything to help anyone find the source, which is what the citation is for (it's not to satisfy someone's idle curiosity about what 基 might look like transliterated into Latin text). On the other side of such an argument, there are AI-fuelled translators and transliterators and if they produce pretty consistent results, then a transliteration of an author name and a translation of an article title might actually be pretty accurate. Then a counterpoint to that is it might be downright unhelpful: e.g. the real source is "החיים שלי עם חתולים", which transliterates as "Hachaim shley am alett" which is basically usless, and translates into English as "My life with cats", but Googling around for that English pseudo-title will turn up all sorts of results [4], probably none of which will be the source cited. And then an argument in the other direction might be that at least the reader would be able to see something about what the source is about, from its title translation, and even editors might be better able to detect when a bogus source has been added, e.g. if the title translates to "Triumphs of the Soviet Space Program" but the article is about the Kievan Rus', there is probably an issue. So, I'm not entirely sure, but still lean toward "don't add your own transliteration or translation of citation details".  — SMcCandlish ☏ ¢ 😼  00:00, 28 November 2023 (UTC)

I mean, as far as I'm aware, MOS:CHINA has always said If a work is in an East Asian language, the original title should be romanized.... Names of publishing companies or presses are transliterated but not translated.... Sure, if someone only provides a translation of the title, you'll never find it to verify, but the guidance says to transliterate, which is hardly biased or error-prone. I like to provide translations of title in addition to the originals and usually transliterations, because it gives people an idea what the source is about (other than "an editor claims it verifies some content").

Seems a little weird that people trust editors to read foreign language sources and summarise their contents, but not to provide a direct translation of the name of a published source (or even transliterate a name? which is like, how do you think we refer to things in article prose when they don't have an article here?).

When writing about foreign language topics, editors translate all the time. It's part of the work. Something like translating the name of a source is the same basic level of competency as routine calculation. It's not OR to be able to read a second language. Folly Mox (talk) 00:29, 28 November 2023 (UTC)

Oops I shoulda scrolled up from my previous link. WP:TRANSCRIPTION says Faithfully translating sourced material into English, or transcribing spoken words from audio or video sources, is not considered original research. Folly Mox (talk) 00:33, 28 November 2023 (UTC)

I'm skeptical that the MOS:CHINA material on this actually represents a broad consensus. I strongly suspect that if an RfC were put up at WP:VPPOL asking "In citations, should source titles and author names in non-Latin script be transliterated by editors into the Latin alphabet (or translated into English) when the publication itself only provides the name(s) in the original non-Latin script and non-English language?" the answer would be "No (and no)", because it does not help the reader find the source, which is what citations are for. Aside from the uncommon |quote= parameter, our citations are not "content" in the usual sense, but serve a specific purpose. An argument can be made that the publication company being transliterated does help evaluate the source, since we (or someone else) may have information about the publisher that could help in evaluating reputability, especially when it comes to things like distingishing between a university or general book publisher versus a govermental organ or a game company that published the game our article is about, for example. I honestly don't really feel all that strongly about it, but I suspect that other editors do, and this is actually worth putting to a broad RfC audience somewhere like VPPOL.  — SMcCandlish ☏ ¢ 😼  23:16, 28 November 2023 (UTC)

I suspect the guidance is misaligned as well, but not in the same way. I suspect people would prefer, for titles, native and translations, with no transliterations. Transliterations of titles is common in academic publishing for some reason (possibly grandfathered in due to inability to print 漢字 until like the nineties), but adds nothing for the reader, except when both: accompanied by the native title, and the reader is a student of the language and doesn't know how to pronounce things.

I know for me personally, when I see a citation in a script I can't read, it's deeply comforting to have the transliteration of the names and translation of the title. This doesn't assist in verification, but it gives me some idea, in my brain, who is being cited and what the work is about, in a broad sense. Folly Mox (talk) 19:06, 29 November 2023 (UTC)

But that's a personal whim you can satisfy in seconds of your own time using Google Translate. It doesn't "translate", if I may pun, into a need for Wikipedia editors do this work for you, in untold thousands of citations. I encounter Chinese, Russian, etc., citations all the time and am not perturbed by them. If I want to know what the title "宇多田ヒカル、11年ぶりシングルCD発売決定 Skrillexと『キングダムハーツIII』OP制作" translates to, I can take a few seconds to paste it into Google Translate.  — SMcCandlish ☏ ¢ 😼  08:04, 1 December 2023 (UTC)

It's unjustified to require that people use machine translation/transliteration for this: those are not trivial tools, and we should try to impose Google Inc. (et al.) on people as little as possible. They are also not perfect, especially for languages that use Chinese characters. Remsense留 18:27, 1 December 2023 (UTC)

Wikipedians should absolutely add both transliterations and translations of foreign text. This is an English encyclopedia and we don't expect readers to be able to handle random snippets of Urdu, Ancient Greek, Nahuatl, and Swahili interspersed with the English. –jacobolus (t) 17:30, 29 November 2023 (UTC)

Examples from Lexell's theorem:

Schubert, Friedrich Theodor (1789) [written 1786], "Problematis cuiusdam sphaerici solutio" [The solution of a certain spherical problem], Nova Acta Academiae Scientiarum Imperialis Petropolitanae (in Latin), 4: 89–94

Shvartsman, Osip Vladimirovich (2007), "Kommentariy k stat'ye P. V. Bibikova i I. V. Tkachenko 'O trisektsii i bisektsii treugol'nika na ploskosti Lobachevskogo'" Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского» [Comment on the article by P. V. Bibikov and I. V. Tkachenko 'On trisection and bisection of a triangle in the Lobachevsky plane'] (PDF), Matematicheskoe Prosveschenie, ser. 3 (in Russian), 11: 127–130

Steiner, Jakob (1827), "Verwandlung und Theilung sphärischer Figuren durch Construction" [Transformation and Division of Spherical Figures by Construction], Journal für die reine und angewandte Mathematik (in German), 2 (1): 45–63, doi:10.1515/crll.1827.2.45, EuDML 183090

Chasles, Michel (1837), Aperçu historique sur l'origine et le développment des méthodes en géométrie [Historical overview of the origin and development of methods in geometry] (in French), Brussels: Hayez, Ch. 5, §§ 42–45, "Géométrie de la sphère" [Spherical geometry], pp. 235–240

Of course where available it's nice to use someone else's translation, e.g.:

Lexell, Anders Johan (1784) [written c. 1777], "Solutio problematis geometrici ex doctrina sphaericorum", Acta Academiae Scientarum Imperialis Petropolitinae (in Latin), 5: 1781 (1): 112–126, figures tab. 4, translated as "Solution of a geometrical problem from the theory of the sphere" (PDF), 17centurymaths.com, translated by Stén, Johan Carl-Erik, 2009

–jacobolus (t) 17:42, 29 November 2023 (UTC)

Well, just expressing "absolutely should" without providing a rationale other than a tautological observation of what site this is, and providing some examples of you writing citations the way you like to write citations, isn't very convincing. :-) I'm dead certain that if this question is put to an RfC, as I suggested above, that the input will be broad in its responses. I'm skeptical there would be much support for doing this, except in cases where off-site sources provide them and they help actually find the citation. Transliterations are generally meaningless to much of anyone (except when commonly used in RS for the same referent), and translations are unlikely to help find a verify the source (except when it's also been published in an English version, in which case we should be citing that instead).  — SMcCandlish ☏ ¢ 😼  14:28, 30 November 2023 (UTC)

The rationale is that readers of English text are not expected to know what "verwandlung und theilung", "cuiusdam", "aperçu", or "трисекции и бисекции треугольника на плоскости Лобачевского" mean (and it's even harder to puzzle out if the text is written in Marathi or Cantonese). These labels are often treated by English readers are opaque or even unrecognizable symbols without internal meaning. If not only the title but also the author name, publication name, etc. are in a non-Latin script, then the whole thing just becomes a blob of meaningless scribbles.

This makes it impossible for readers to evaluate what the source is about, what it has to do with the content of the article, whether/why it is important, whether they have seen it mentioned before, whether it's worth trying to find a copy of to examine (or e.g. get a machine translation of), and so on.

I don't really care about a transliterated title if we have a script title and a translation, but let's compare with/without a transliterated author name/journal and translated title:

Шварцман, Осип Владимирович (2007), Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского», Математическое Просвещение, Третья серия (in Russian), 11: 127–130

Shvartsman, Osip Vladimirovich (2007), Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского» [Comment on the article by P. V. Bibikov and I. V. Tkachenko 'On trisection and bisection of a triangle in the Lobachevsky plane'], Matematicheskoe Prosveschenie, ser. 3 (in Russian), 11: 127–130

A recognizable author name and a legible title are the two single most important elements to include in a citation. The rest can be convenient but is mostly dispensable (motivated readers can find it if they need). –jacobolus (t) 15:24, 30 November 2023 (UTC)

But there is no point in "recognizing" that Шварцман transliterates to Shvartsman if this does not help the reader find the source. If the source is only available in Russian, then the strings to search for to find it are literally "Шварцман" and "Комментарий к статье П. В. Бибикова и И. В. Ткаченко «О трисекции и бисекции треугольника на плоскости Лобачевского»" ([5], very first search hit, link toward bottom of short resulting page, then click the PDF button on the next page; took just a few seconds). If the source does exist in English then we should be citing that instead. Meanwhile, the translated strings "Shvartsman" and "Commentary on the article by P. V. Bibikov and I. V. Tkachenko 'On trisection and bisection of a triangle on the Lobachevsky plane'" don't help find the source at all (wild goose chase). Our citations do not exist to satisfy curiosity about how Cyrillic strings transliterate or translate into Latin script or English language, only to help the reader find the citation and verify the content. Any reader that cannot read the Cyrillic in the citation cannot read the Cyrillic in the source book/article, either, so cannot verify the citation and has to rely on someone else to do that work, so is not harmed by a transliteration not being provided. Meanwhile, the reader who is competent to read that material does not need that extra stuff. Any reader who is just really curious what a particular cited work's title translates to can just copy-paste it into Google Translate or an equivalent tool. It's not really the job of our templates and our editors to do that make-work for them, since it doesn't help with verifying our content. I used to think about this the way you do, and went to pains at articles like Utada Hikaru to provide translations of work titles, and it was a lot of work, but in the end it simply doesn't help anyone verify the content, and it just adds a lot of code bloat and a lot of visual cite bloat for the reader, without actually providing utility to them.  — SMcCandlish ☏ ¢ 😼  07:44, 1 December 2023 (UTC)

Transliterations are often provided and utilized haphazardly in journals and the like, providing a transliteration is rather likely to increase one's search results on a given individual. — Remsense留 07:54, 1 December 2023 (UTC)

Perhaps for names of people, and when dealing with languages/scripts that have a consistent transliteration system. But several do not, and translations of titles aren't going to match someone else's translation, except in the simplest cases (which will also, in being so simple, have lots of false-positives in English anwyay, so still not a help in finding the source). I can maybe concede that transliteration of author/editor names could be of some use, for the same reason as with publisher names: doing some background research of one's own to get a sense of reputability. PS: I added some example search stuff, and so on, to my previous post just above this but edit conflicted with you.  — SMcCandlish ☏ ¢ 😼  08:10, 1 December 2023 (UTC)

only to help the reader find the citation and verify the content – to first approximation, precisely zero readers care about "verifying the content". What readers care about is making sense of the subject. For readers who speak English and have no experience with Russian or related languages, the Cyrillic alphabet is entirely nonsensical, and barfing blobs of Cyrillic at readers is unhelpful and snobbish. Anyone can click the hyperlink to find the paper in Russian (and if they don't read Russian but want to make sense of it, as I did, they can OCR the image-based PDF and then machine translate the resulting text so they can understand the proof contained in the paper and cited by the article). But as for your point about web searches, Osip Shvartsman returns a wide variety of relevant results in English. Осип Шварцман does not. Edit to add: The #1 result in your "wild goose chase" search is a highly relevant paper in English (translated from Russian) which cites the paper in question ("O. V. Shvartsman. Comment on the article by p. v. bibikov and i. v. tkachenko. Matematicheskoe Prosveschenie. Tret’ya Seriya., (11):127–130, 2007.") and the paper it was responding to ("P. V. Bibikov and I. V. Tkachenko. On trisection and bisection of a triangle in the hyperbolic plane. Matematicheskoe Prosveschenie. Tret’ya Seriya., (11):113–126, 2007."), probably the single most relevant possible English language search result. Good job Google! –jacobolus (t) 08:19, 1 December 2023 (UTC)

That view is completely inconsistent with our verifiability policy, which is crystal clear that our material is sourced with citations so that readers can verify it. The average reader is not going to do this, and they "make sense of the subject" by reading the article content that interests them, not by looking at citations. Most of our readers never look at any of the citations. The ones who do are mostly students, journalists, people experienced in the topic, and those intensely interested in the topic and being certain about the facts, and these are the people our citations are for. They are the people who go find the cited source (at least when easily available) and see what it says. But ultimately we all know by know that that primary (by orders of magnitude) actual users of our source are other editors doing V and OR checking work to make sure our article are not full of nonsense. All of these classes of users, however, are going to be using the citations the same way: to find the source and see that it backs up the content we cite to it. "Anyone can click the hyperlink to find the paper in Russian", sure when it's an online source that is not paywalled, but many source are not, and we provided all the source info we have that is helpful in finding the source (not in learning other factoids about the source that are not necessary for finding it) because we cannot guarantee that an online one will be online indefinitely, and we also have WP:RESUSE to consider, from programmatic repurposing of WP content to just users print out articles on paper, where links don't work. WP:NOT#DATABASE, including a bibliographic one. There are all sorts of details about a source that we could include but do not, such as how many total pages it has, whether is a paperback or a hardback, who illustated the cover, etc., etc., etc. We don't include it because it doesn't help find the source."a highly relevant paper in English (translated from Russian) which cites the paper in question" is irrelevant. [{WP:SAYWHEREYOUGOTIT]]. We are not citing some other paper that mentions the paper we are citing, we are citing the paper we are citing. That is the purpose the citation serves, to find that source. That doing something else might be entirely accidentally "interesting" for someone in some way is a moot point. We could make all our citations vaguely interesting and useful, in an off-topic sense for citations, in a myriad of ways (e.g. including images of book covers, linking directly to shopping sites to buy them, providing word-count and reading-level analyses of them, connecting author names to databases instead of WP articles, linking to book reviews as adjunct information, and so on), but we do not because it's not the point of the citation or of Wikipedia.  — SMcCandlish ☏ ¢ 😼  11:11, 1 December 2023 (UTC)

This discussion has already digressed pretty far from "should we have a |script-author= parameter to match the others instead of relying on |author-mask= hacks?", but I agree with jacobolus and Remsense here, while noting that the previous time this talkpage hosted a digression into the philosophical argument of "what citations are for" versus "how citations are used", (in the "Do we need |access-date ?" thread still live above), several of the protagonists came down on opposite sides to where we find ourselves this time round. Folly Mox (talk) 11:35, 1 December 2023 (UTC)

FWIW, I think a script-author parameter sounds like a good idea. This kind of question should be left up to author discretion, and letting template users put the author name in two forms is a pretty obvious help with that. –jacobolus (t) 15:15, 1 December 2023 (UTC)

The fact that debates on this page come to contradictory-leaning results is not a surprise due to the small number of participants here. This is why I routinely suggest holding WP:VPPRO or WP:VPPOL RfCs on matters that are apt to ultimately affect many thousands of articles across random categories. Citation templates doing what they do for particular reasons with a strong WP:CONLEVEL behind them is much easier to support than "it's working this way right now because five people one day thought it seemed like a good idea and weren't inclined to brook any opposition".  — SMcCandlish ☏ ¢ 😼  01:57, 2 December 2023 (UTC)

I am in favor of an RFC if it achieves the best-developed results, but since I was not privy to previous aforementioned discussions, I wish it would have been explicitly proposed earlier. Remsense留 02:24, 2 December 2023 (UTC)

The example of transliterating החיים שלי עם חתולים as Hachaim shley am alett is useless not because it is a transliteration, but because it is not a correct transliteration. "Hachaim Sheli Im Chatulim" would be more helpful, although there are some dialect differences, especially for the consonants ח (Chet) and ע (Ayin). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:38, 30 November 2023 (UTC)

Re: "an English Wikipedia article where Chinese authors are credited solely by their native names" – I've run into this many times for both Chinese and Japanese, and it's almost always a non-English news/web source. So, maybe not something we encounter in journals, but for looser types of sourcing, it's pretty common (but also applies to South Asian languages, Cyrillic ones, Hebrew, Korean, and so on).  — SMcCandlish ☏ ¢ 😼  23:38, 27 November 2023 (UTC)

Oh right, of course people cite only native names when they're using a referencing script to handle all the work for them. I'm not sure why I didn't think of that. Folly Mox (talk) 01:03, 28 November 2023 (UTC)

I would like to endorse the proposal for the reasons Kanguole and Folly have already stated: as someone who spends a lot of time wrangling citations involving the Sinosphere, a new feature like this, consistent with those already existing in the CS1 template is very near the top of my wiki-wishlist. Remsense留 01:27, 30 November 2023 (UTC)

I strongly endorse the proposal for the numerous reasons given above. That |script-title= has existed for years shows prima facie that the feature would be useful, as the author is at least as important as the title. I arrived here when I tried to use {{cite book}} to add a source where authors provided their names in both the source Chinese and Romanized. The Chinese is needed to match their names to catalog entries where machine-generated Romanizations are different from the ones they give in this source, while the Romanizations in this book are needed to match this source with other sources with no Chinese to establish that the authors are the same. —  AjaxSmack  17:11, 7 December 2023 (UTC)

Date format for CITEREF

Hello! Need help again. In the Russian Wikipedia, we replace all dates with the ISO format (we display them in a human-readable way in the desired language through another module) so that those who copy articles and sources from us do not have to fool around with unreadable and unprocessable dates (English, Russian, Spanish or any other). But I now noticed that CITEREF cannot take the year from such a date (YYYY-MM-DD). It can be fixed? :) Iniquity (talk) 16:21, 27 November 2023 (UTC)

Umm, not true:

{{cite book |title=Title |last=Green |first=EB |date=2023-11-27}}

Green, EB (2023-11-27). Title.

'"`UNIQ--templatestyles-000000B3-QINU`"'<cite id="CITEREFGreen2023" class="citation book cs1">Green, EB (2023-11-27). ''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.date=2023-11-27&rft.aulast=Green&rft.aufirst=EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>

Show me an example of a cs1|2 template at ru.wiki that does not correctly include the year portion of |date= in the template's id= attribute.

—Trappist the monk (talk) 16:34, 27 November 2023 (UTC)

Oh, thanks for the example. This turns out to be an error that the module does not support YYYY-MM. It seemed to me that the module supported the whole ISO :( Iniquity (talk) 16:41, 27 November 2023 (UTC)

This is not an error. The issue is that, at least in English, YYYY-MM can be ambiguous with YYYY-YY, indicating a range. Izno (talk) 16:59, 27 November 2023 (UTC)

Yes, I remembered that old discussion, thanks! I'll have to fix this locally somehow :( Iniquity (talk) 17:01, 27 November 2023 (UTC)

I have fixed YYYY-MM DATE for ruwiki, can you check plz, is it right way? :) [6] Iniquity (talk) 21:35, 28 November 2023 (UTC)

Looks like the change is probably correct. You've tested your code, right? You might want to fix the comment at line 505 (remove reference to 'day').

—Trappist the monk (talk) 22:59, 28 November 2023 (UTC)

Thank you very much for checking! I will fix it :) Iniquity (talk) 01:42, 30 November 2023 (UTC)

Maintenance category for redundant links

I've seen that people make good use of Category:CS1 maint: PMC format. It would be nice to have a maintenance category for citations which contain a PMC ID but also a link from the url parameter: such links are often subject to link rot and need updating or removing. This could later be extended to other green OA IDs if they auto-link. Nemo 07:08, 28 November 2023 (UTC)

New CS1 error for "Cite journal"

{{Cite journal}} now shows a Cs1 error wherever a source is templated according to it but does not actually cite a journal title. Can this be fixed by editing the template or fixed en masse by a bot in all use cases? Æo (talk) 17:53, 28 November 2023 (UTC)

No, a bot is not able to fix all of these cases. There may be some groups with similar patterns that can be fixed by editors using AWB. The help text explains how to fix each erroneous template transclusion. – Jonesey95 (talk) 18:42, 28 November 2023 (UTC)

Aliase for 'Author'

Hello! I need to set an alias for the "author" parameter, but adding ['Author'] = 'автор', to the configuration not works. Iniquity (talk) 21:38, 28 November 2023 (UTC)

In ~/Configuration, remove ['Author'] = 'автор' and add 'автор#' to ['AuthorList-Last'] = {...} (at about line 390).

In ~/Whitelist, add ['автор'] = true to local limited_basic_arguments_t = {...}. Then add ['автор#'] = true to local numbered_arguments_t = {...} and to local limited_numbered_arguments_t = {...}

—Trappist the monk (talk) 23:16, 28 November 2023 (UTC)

Thanks a lot! :) Iniquity (talk) 01:42, 30 November 2023 (UTC)

Redundant listings in Category:CS1 maint: unflagged free DOI

Nice tracking category! However, this currently comes up with citations which do not need doi-access=free because they already have an auto-linking PMC identifier (example). That makes it harder to find citations which would actually benefit from being turned green. Nemo 10:57, 30 November 2023 (UTC)

|pmc= and |doi= point to different sources. |pmc= defaults to free-to-read; |doi= does not. |pmc='s free-to-read-ness does not apply to |doi=. Readers who would prefer to read the |doi= source are entitled to know if that source is free-to-read. All identifiers that are free-to-read should be marked with |<identifier>-access=free.

I don't know what you mean by That makes it harder to find citations which would actually benefit from being turned green.

—Trappist the monk (talk) 14:46, 30 November 2023 (UTC)

I mean that adding OA identifiers is most useful on citations which don't already have one. Once you have a PMC ID, the marginal utility of a doi-access=free parameter is significantly reduced. Nemo 15:06, 30 November 2023 (UTC)

cs1|2 does not support Open Access (OA) because open access implies that the source may be reused in some form or other. As far as cs1|2 is concerned, a source is free-to-read or it lies behind some sort of paywall or registration barrier.

The free-to-read icon attached to a PMC identifier conveys no useful information about the paywall/registration/free-to-read status of the source pointed to by |doi= or any other identifier parameter. In fact, the omission of a free-to-read icon for |doi= when |pmc= has a value implies that the source pointed to by |doi= lies behind a paywall or registration barrier.

—Trappist the monk (talk) 15:20, 30 November 2023 (UTC)

Alright, can we have a maintenance category for citations which don't have an OA identifier aka "free-to-read icon" then? Nemo 16:31, 30 November 2023 (UTC)

I guess I'm not sure how useful that would be. The cs1|2 module suite is used on more than 5.6 million articles so a list of all articles with cs1|2 templates that have identifiers but don't have a matching |<identifier>-access=free could number a million or more. It seems likely that many of those should never have a |<identifier>-access=free so those articles would live in the new category forever. How is that useful?

—Trappist the monk (talk) 20:59, 30 November 2023 (UTC)

Allow setting doi-access to registration or limited

It has come to my attention that some people have been using doi-access=free in citations for works which are not open access but which occasionally offer some gratis access method, such as an intermittent bronze OA (non-libre gratis OA) status or the possibility for some people to register or go through other authentication walls, without payment, to access the full text. Such use is clearly contrary to the documented definition of "free", which says "free to read for anyone" (emphasis added), and which is distinct from the value "registration" for the case where "a free registration with the provider is required".

However, I have sympathy for the argument that there's been some confusion so far, and that the absence of doi-access=free is sometimes misinterpreted as a positive statement of something it's not. The easiest way out would be to allow adding doi-access=limited and doi-access=registration as we do for url-access. That would allow users to manually set this value to indicate the gray area situations. It would also allow us to finally default a blank doi-access to mean "subscription", and to show the red lock by default. Nemo 11:20, 30 November 2023 (UTC)

I could see adding |doi-access=registration as a valid access indicator (and I think this might help with some of OAbot's unaddressed misbehavior), but |doi-access=subscription is like |url-access=free. I would not want to see bots adding zillions of understood default access indicators, or their associated lock icons in reference lists, which would be the outcome of enabling the specification of the default value. Folly Mox (talk) 11:56, 30 November 2023 (UTC)

Good point, I mixed up. I meant it should be possible to explicitly set it to registration or limited, while "subscription" would be the default (still considered an error if added explicitly, as it is now). Nemo 11:59, 30 November 2023 (UTC)

The case I highlighted which started the discussion referred to by Nemo is doi:10.1001/jama.2009.405. There seems to be a difference of opinion whether this can be described as doi-access=free. My interpretation is that this source is indeed compliant: the webpage that is the target of the doi has the full text and that text can be downloaded by simple copy-paste, if the reader so desires. (To download a .pdf a user must provide their email address.) I don't see this as a grey area: citations are there in Wikipedia articles so that readers can verify that the source supports the text and using doi-access=free makes the title of the work a direct link to the place that the text is hosted and can be read by anyone. Mike Turnbull (talk) 12:03, 30 November 2023 (UTC)

To avoid more important work, I verified that the full article and all figures and tables present in the PDF are duplicated on the webpage. The only content lost is the page numbers. I think I'd characterise this as "free to read for anyone" and hence a poor example, but the problem described may actually exist: dois that offer only a preview for all viewers, but access to the full source for non-pay-for registered accounts. Folly Mox (talk) 12:33, 30 November 2023 (UTC)

I've seen OABOT removing many doi-access=free tags today from articles that appear to be completely free to read on the publisher's web page. I think we should leave those tags in place, because they are free to read. As you say this should only be for works where the full work is viewable, but I don't think freedom to reuse under an open license is relevant or necessary. —David Eppstein (talk) 23:14, 2 December 2023 (UTC)

Agreed. I just saw one of those, too.  — SMcCandlish ☏ ¢ 😼  11:32, 3 December 2023 (UTC)

And reverted it.  — SMcCandlish ☏ ¢ 😼  12:46, 3 December 2023 (UTC)

@Nemo bis Here's another removal that is perhaps understandable if you are a bot rather than a human. The relevant doi is doi:10.1016/0016-5085(92)91094-K. Click the link and it will open the actual article on the website. However, the URL is interesting: https://www.gastrojournal.org/article/0016-5085(92)91094-K/pdf?referrer=https%3A%2F%2Fen.wikipedia.org%2F includes the fact that this is has been a request from wikipedia! If you use the link https://www.gastrojournal.org/article/0016-5085(92)91094-K/ in a browser tab not associated with Wikipedia, you get to the publisher's web page, where there is a comment saying that the paper is only available as a .pdf. Humans can read that advice and do indeed get free access to the .pdf with one more click. Mike Turnbull (talk) 14:08, 3 December 2023 (UTC)

There was no excuse at all for this removal for doi:10.1139/v84-243 and I urge you to stop the bot immediately and revert all such removals. It might be better to permanently disable all free -> blank interventions and focus on the more useful blank -> free. Mike Turnbull (talk) 14:29, 3 December 2023 (UTC)

I'm not sure how this is relevant to this discussion. Anyway, the bot has already stopped removing doi-access=free. Can we go back to whether we can use doi-access=registration or doi-access=limited where the publisher requires login? JSTOR comes to mind, but I can find more examples if useful. Nemo 21:47, 3 December 2023 (UTC)

Here are some example DOIs from the JSTOR prefix, which are currently cited with doi-access=free but actually require registration: doi:10.2307/1378152, doi:10.2307/3632910, doi:10.2307/3496680, doi:10.2307/2324301, doi:10.2307/2371798. On phabricator:T344114#9392971 you can see how they're displayed to me. How are we supposed to mark these? Do I have to go through the entire registration process to check whether I will actually be able to read and download the file without paying? And how will I know that the requirements are the same in another country? Nemo 14:31, 8 December 2023 (UTC)

Category:CS1: Julian–Gregorian uncertainty

Hello 🙂 I was wondering how you would go about removing an article from the hidden category above. There are over 100,000 pages tagged with this category, and at least to me, it's a little unclear how to fix this. I also see that this might be a temporary category, so, is there still a need for this, or can it be deleted? Kind of a two parted question, but I hope you understand. Cheers! Johnson524 15:39, 30 November 2023 (UTC)

You shouldn't bother; that category is a properties category not a maintenance or error category. It exists merely for the information it might contain. Here is some history:

Help talk:Citation Style 1/Archive 39 § metadata dates rfc

Help talk:Citation Style 1/Archive 41 § CS1: Julian–Gregorian uncertainty

Help talk:Citation Style 1/Archive 54 § Julian and Gregorian dates

Help talk:Citation Style 1/Archive 56 § Julian Gregorian uncertainty

Help talk:Citation Style 1/Archive 88 § Julian vs. Gregorian

Apparently no one cares about this anymore since those who do or did have never said anything here about it. That being the case, I'm going to remove the code that categorizes articles into Category:CS1: Julian–Gregorian uncertainty.

—Trappist the monk (talk) 18:40, 30 November 2023 (UTC)

Sounds good, thanks for checking up on this 👍 I'll be sure to take a look at those history links, cheers! Johnson524 18:46, 30 November 2023 (UTC)

Categorization gone from the sandboxen. You can test in mainspace (because property cats do not include pages in the Help namespace) with this:

{{cite book/new |title=Title |date=1 June 1815}}

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

Happy to see this go, as I said in the last discussion it would be better handled by an inline template used in specific instances that editors believe to be at issue. -- LCU ActivelyDisinterested «@» °∆t° 15:17, 1 December 2023 (UTC)

Interlanguage links

Is there any way to incorporate interlanguage links, in e.g. |author parameters? ~~ AirshipJungleman29 (talk) 22:32, 2 December 2023 (UTC)

Yes:

|author=[[:<tag>:<article name>|<author name>]]

or:

|author-link=:<tag>:<article name> – required for |last= / |first= pairs; may be used for |authorn=

where:

<tag> is the target wiki's interwiki prefix (de for German, ar for Arabic, etc)

<article name> is the article name at the target wiki

<author name> is the author's name

Do not use {{Interlanguage link}}.

—Trappist the monk (talk) 23:35, 2 December 2023 (UTC)

Citing a pamphlet published or edited on behalf of

I'm citing a German pamphlet which is listed as published/edited on behalf of - Herausgegeben im Auftrage. The work was published on behalf of the organization „Reichsarbeitsgemeinschaft ‚Das kommende Deutschland'“. Johannes Täufer is listed as the author, and Astrologischer Verlag Wilhelm Becker is the publisher. What's the preferred way in {{cite book}} to record a "published on behalf of"? -Furicorn (talk) 08:03, 3 December 2023 (UTC)

If Astrologischer Verlag Wilhelm Becker is listed as the publisher, I would write |publisher=Wilhelm Becker.

—Trappist the monk (talk) 12:33, 3 December 2023 (UTC)

In cases of doubt where it's unclear if one party was just the printer and another was the publisher is a more "directorial" sense, I put both, since our citations are not articles about the works, and exist to help readers find the publication (both strings will help do that).  — SMcCandlish ☏ ¢ 😼  12:43, 3 December 2023 (UTC)

So would you say |publisher=Astrologischer Verlag Wilhelm Becker, on behalf of Reichsarbeitsgemeinschaft‚ "Das kommende Deutschland"? Thanks -Furicorn (talk) 19:43, 3 December 2023 (UTC)

Not sure about this case, since I've not researched the publication and the parties behind it. In cases where I can't tell anything for certain, I do something like |publisher=Astrologischer Verlag Wilhelm Becker / Reichsarbeitsgemeinschaft Das kommende Deutschland (the quotation marks being superflous), since the strings in question are still helpful in finding the source, but I needn't do any iffy OR on my own part to try to decide who "is" the "real" publisher. This also comes up in modern cases; e.g., Scientific Style and Format has specific individual author-editors of particular editions, and is (in recent editions) "published by" the Council of Science Editors in the editorial-direction sense and (again in recent editions) "published by" Chicago Univerisity Press in the printer sense. I can't predict what kind of "publisher" a particular reader cares more about (an editorial "publisher" has much more to do with reputability and bias, while a printing "publisher" is more important for how the book is indexed in bibliographic databases), so I would be inclined to included both in the citation, especially as it provides additional relevant search strings. But this probably comes up more for Victorian and earlier publications, in which it may be difficult to determine whether some non-notable company name at the bottom of the title page represents a printer hired to just do the job, or a publisher who had some editorial input, especially if juxtaposed with the name of an organization or other entity that clearly did have some control over it.  — SMcCandlish ☏ ¢ 😼  03:21, 4 December 2023 (UTC)

Thanks for the reply - I found the German National Library entry for the pamphlet (DNB-IDN 576618977), and based on that I figured out that the phrase meant that the author had written the work as a representative of the committee. So I added the committee name in the parameter |last=, similar to how the library had done it. -Furicorn (talk) 06:40, 4 December 2023 (UTC)

Should be in its own |author2= (equivalent to |last2= but clearer), not jammed into the same |last[1]= as the human author name, or it pollutes the metadata about what his name is.  — SMcCandlish ☏ ¢ 😼  15:49, 4 December 2023 (UTC)

Thanks! Very useful to know, I've gone ahead and done that.

-Furicorn (talk) 06:34, 5 December 2023 (UTC)

Citeseerx link

The first of two questions about one particular paper that I intend to cite (via a CS1 citation template). The questions are, I think, otherwise independent of each other.

You'll find a page introducing the article at doi:10.1177/007542428902200202. To see the actual article, log-in (or payment) is required. However, I also found the article at this URL, which starts "https://citeseerx.ist.psu.edu" and for which log-in or payment is not required. Now, I am almost totally ignorant of Citeseerx, but as doi:10.1177/007542428902200202 works, I infer from Template:CiteSeerX's documentation that CiteSeer^x: 10.1177/007542428902200202 should work too. It doesn't. Have I misunderstood something? -- Hoary (talk) 11:59, 3 December 2023 (UTC)

Looks right, so my guess would be that CiteSeerX has not indexed that document internally by DOI (or not by that DOI). If, as you say, you are using a CS1 citation template, there is no reason to use {{CiteSeerX}} in the first place; just do |url=https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=ca452b918dd0498837c9d127dae5b5db833e51ee and if you're concerned about its lifespan, make sure web.archive.org saved a copy (done). Similarly, normal DOI usage in CS1 would be |doi=10.1177/007542428902200202 not a {{DOI}} template.  — SMcCandlish ☏ ¢ 😼  12:29, 3 December 2023 (UTC)

Thank you, SMcCandlish. Yes, sorry, I sleepily forgot to say that I was using the CiteSeer and DOI templates only temporarily, intending to replace them with citeseer= and doi= within the Cite journal template. Yes, all of what you say makes good sense -- and thank you in particular for taking the trouble to get the Internet Archive to store the article. -- Hoary (talk) 21:56, 3 December 2023 (UTC)

Two issue numbers, two years

A second question about a paper I intend to cite (via a CS1 citation template).

doi:10.1177/007542428902200202 describes an article as "First published October 1989" in "Volume 22, Issue 2" of the journal. Now look at the running header on evenly-numbered pages here at PSU. It reads: "JEngL 22.3 (October 1989 [1993])" [my emphases].

Now, if I were to read of a paper described as "1989 [1990]", I'd guess that it came out in a journal issue dated 1989 but in reality emerging only in 1990. But the journal wouldn't announce (in effect) "1989, nah, we're kidding, 1990". And I haven't heard of journal publication being delayed four years.

Informed comments? -- Hoary (talk) 11:59, 3 December 2023 (UTC)

This looks to me like it was first published in 22(3), Oct. 1989, but that the description of the article mistakenly has it as 22(2); and that it was later reprinted in 1993, or that 1993 is the date it was put online, or was revised in some way in 1993, or some other post-publication ocurrence. But it's hard to say without knowing more about the history of the periodical. It seems extremely unlikely to me that an issue published in 1989 would be 22(2) and an issue published in 1993 would be 22(3) rather than 26(X). If I were not able to get a clearer answer, I would cite it as |date=October 1989|volume=22|issue=3 to agree with the publication itself (as much as seems possible), rather than some third-party claim about its volume number; then follow the citation template, but still inside <ref>...</ref>, with something like 'Also dated "[1993]" suggesting a revision or republication.'  — SMcCandlish ☏ ¢ 😼  12:37, 3 December 2023 (UTC)

Good thinking, SMcCandlish. Shall do. -- Hoary (talk) 21:58, 3 December 2023 (UTC)

It seems that now we have heard of a publication being delayed four years: journal editor William A. Kretzschmar's 1995 note (TWL link) in volume 23 issue 1–2 (where the running header has "1990–1995") indicates that he was responsible for publishing the journal and events overtook him, leading to extreme delays for two volumes and handing over publication duties to Sage.

So the 1989 volume was published 1993, and the 1990 volume was published 1995. Not sure how to cite it accurately, but an interesting tale. Folly Mox (talk) 23:01, 3 December 2023 (UTC)

Blimey. I mean, great sleuthing, Folly Mox. -- Hoary (talk) 02:53, 4 December 2023 (UTC)

Well, lots and lots of things are written at an earlier time than they are published, and we use the date of publication not of authorship, so these could be cited as 1993 and 1995 respectively, or maybe with ranges like 1989–1993 and 1990–1995, though that might just be confusing. I guess it depends on what is shown in the actual publication. If it says "1990–1995", then having that in the citation might actually help locate the source, while if these dates are just researched background information they probably would not. A "we originally intended to publish this in 1989" date doesn't really mean anything in most cases.  — SMcCandlish ☏ ¢ 😼  02:58, 4 December 2023 (UTC)

Honestly I feel like this might be an appropriate use case for |orig-date=. But if I'm wrong, in terms of findability, the publisher (Sage, not the o'erburdened Dr Kretzschmar) has the "intended" publication date, so that might be the one to pick. Folly Mox (talk) 03:36, 4 December 2023 (UTC)

Seems like the journal sold themselves to SAGE, who has since done an atrocious job digitizing / putting up metadata for the archived papers. Publication date should be 1993, and optionally might have orig-date=Submitted 1989 or the like. –jacobolus (t) 17:48, 5 December 2023 (UTC)

Sounds reasonable.  — SMcCandlish ☏ ¢ 😼  07:57, 6 December 2023 (UTC)

But I think that the reader -- or, at the risk of sounding a bit snobbish, the kind of reader who'll want to read the kind of stuff that's distilled from academic journals -- will realize that "BITD" (before the interwebs) even the submission of an appreciatively received MS wouldn't bring fast publication. There's a difference between routine delays such as that on the one hand, and a hardly credible four-year delay on the other. To be more certain of how the paper is presented, I'd like to see the front cover and first few pages of the actual codex; but (lacking easy access to a university library) that would take more time than I'm eager to spend, so I shan't bother. And as for findability, it's hard to believe that anyone will do it by year (or even volume and number): far more likely they'll merely click on the DOI, or on an (apparently above-the-board) free copy, or on a Wayback copy of the latter. -- Hoary (talk) 06:29, 4 December 2023 (UTC)

Well, we can't depend on every reader having access to these links, per WP:REUSE, even the simplest re-use of someone printing out a copy before heading to a library. Otherwise we might as well have nothing in a citation at all but the URL when a URL is available. :-)  — SMcCandlish ☏ ¢ 😼  15:49, 4 December 2023 (UTC)

Extra text in |volume= and |issue=

We have Category:CS1 errors: extra text: volume and Category:CS1 errors: extra text: issue that list articles where a cs1|2 template has |volume= or |issue= with some sort of extraneous text that reflects the parameter name: |volume=Vol. XX or |issue=No. 13. There are at least a couple of thousand articles where the text that is extraneous to one parameter can be found in the other: |volume=No. 13 or |issue=Vol. XX.

This search (times out) finds ~1500 articles where the value assigned to |issue= begins with Vol (case insensitive)

This search (times out) finds ~700 articles where the value assigned to |volume= begins with Iss, Num, No, N°, № (case insensitive)

I propose to do one of two things:

1. create separate tests for these conditions so that they can be categorized separately from the existing Category:CS1 errors: extra text: volume and Category:CS1 errors: extra text: issue
2. modify the existing tests to include these conditions so that they will categorize into the existing categories

Opinions?

—Trappist the monk (talk) 20:37, 3 December 2023 (UTC)

@Trappist the monk: If you modify the existing tests to include these conditions so that they will categorize into the existing categories, then I'll update my existing bot tasks to fix these. GoingBatty (talk) 20:51, 3 December 2023 (UTC)

@Trappist the monk: Correction: I'll update my existing |volume= bot task, and submit an additional bot request to fix |issue=. GoingBatty (talk) 20:53, 3 December 2023 (UTC)

I've tweaked the sandbox to combine the currently separate lists of volume and issue patterns into a single list of patterns. I have also added tests for n° and №. When the test is run, the values assigned to |volume= and |issue= are checked against the combined patterns.

Cite magazine comparison

Wikitext	{{cite magazine|magazine=Magazine|title=Title|volume=n° 32-33}}
Live	"Title". Magazine. Vol. n° 32-33. {{cite magazine}}: |volume= has extra text (help)
Sandbox	"Title". Magazine. Vol. n° 32-33. {{cite magazine}}: |volume= has extra text (help)

Cite magazine comparison

Wikitext	{{cite magazine|magazine=Magazine|title=Title|volume=№2}}
Live	"Title". Magazine. Vol. №2. {{cite magazine}}: |volume= has extra text (help)
Sandbox	"Title". Magazine. Vol. №2. {{cite magazine}}: |volume= has extra text (help)

No change in categories.

—Trappist the monk (talk) 19:19, 6 December 2023 (UTC)

Impact of "Template:American transit ridership" edit

{{American transit ridership}} was updated 05:46, December 6, 2023. Apparently, this resulted in 300+ articles being added to "Category:CS1 errors: dates". Can a script be run to perform an "empty edit" on the articles in this category? I assume this will remove them from the category. User-duck (talk) 17:37, 6 December 2023 (UTC)

I have fixed the template. The Category:CS1 errors: dates (175) will empty on its own.

—Trappist the monk (talk) 17:43, 6 December 2023 (UTC)

Missing or incomplete template data

The following CS1 templates have missing or incomplete template data:

• Template:Cite arXiv
• Template:Cite AV media
• Template:Cite AV media notes
• Template:Cite document
• Template:Cite mailing list
• Template:Cite serial
• Template:Cite speech
• Template:Cite tech report
• Template:Cite thesis

The template data goes into the documentation page, so any editor can add it, Rjjⁱⁱⁱ (talk) 19:57, 6 December 2023 (UTC)

cite book abruptly stopped working

Hi, first, thanks for all the work you put into making this! It has saved me a lot of time.

Early this evening, however, my requests to {{cite book}} in order to fill in additional information on the basis of the isbn field started generating a little Wikipedia box with the message "Error: Citations request failed" and the "option" to click OK. I am especially puzzled because it was working fine just a few hours earlier with an identical command.

I've tried it in other userspaces on Firefox and then on Safari and got the same thing. You can see my efforts here.[7]

Cheers, Patrick J. Welsh (talk) 05:10, 7 December 2023 (UTC)

It's working again! Many thanks if anyone did anything to resolve this! Otherwise please disregard the above.

Cheers, Patrick J. Welsh (talk) 06:37, 7 December 2023 (UTC)

User:PatrickJWelsh, the CS1|2 templates themselves don't have the functionality to look up additional information based on a stable identifier like an ISBN. I'm not sure which tool you were using to do this, but I know that some ISBN lookup tools have been using Worldcat as their lookup database, which is being changed. Separately, the backend framework for a number of older tools is being deprecated soon, so the blink in functionality you saw a few hours ago could have been someone migrating a tool to the new backend, or an accessibility problem with an external database, but has nothing to do with citation templates. Just fyi. Folly Mox (talk) 12:43, 7 December 2023 (UTC)

Fixing Citoid created references for Youtube

Tracked in Phabricator
Task T278281

Hi all

Youtube is the second most popular website in the world, with a huge number of reliable news sources using it as a platform for sharing video. Unfortunately Citoid doesn't work properly for creating refs for Youtube currently. This leads to poor quality labelling of references being made, and while there are some templates to specifically cite video content, they aren't user friendly at all. I started a Phabricator ticket in 2021 to try and address this issue, however its not been worked on. Can I request anyone interested in this:

• Subscribe to the Phabricator task so its made clear this is an issue many people would like to be fixed.
• Try citing Youtube videos in articles and give feedback in the Phab task if you notice anything I haven't mentioned.

Also just to say I've seen a couple of people say "Youtube is an unreliable source and shouldn't be used", I think this is a missunderstanding of what the platform is, its the channels that should be assessed for reliability rather than the publishing platform as a whole. E.g the BBC News channel is reliable (its listed under Perennialy reliable sources on en.wiki), where as My Toy Reviews or DailyWire or whatever are obviously not reliable.

Thanks very much

John Cummings (talk) 08:56, 8 December 2023 (UTC)

While we're on this topic, people really, really, really need to stop doing |publisher=YouTube. Unless you're citing something like YouTube's own terms-of-use policy (something actually published by YouTube), it's |via=YouTube, and the |publisher= (if not omitted as often completely redundant with the name of the channel, which belongs in |work=, with the specific video title in |title=) must be the name of the entity that editorially controls and originated the content. YouTube is just a conduit/platform/carrier. Doing |publisher=YouTube is like saying that your mobile service provider owns and originated and has editorial control over your phone conversations with your sister.  — SMcCandlish ☏ ¢ 😼  11:49, 8 December 2023 (UTC)

Hi SMcCandlish can you please include this as a request in the phabricator ticket so it gets integrated into the work for whoever might work on it. Thanks, John Cummings (talk) 13:35, 8 December 2023 (UTC)

Done.  — SMcCandlish ☏ ¢ 😼  03:33, 9 December 2023 (UTC)

SMcCandlish, thanks :) John Cummings (talk) 08:21, 9 December 2023 (UTC)

People who use Citoid and people who manually set template parameter values have near zero overlap. Folly Mox (talk) 13:40, 8 December 2023 (UTC)

I do both all the time. It's far quicker to create cites using autofill, but not always possible (or desirable as it sometimes autofills nonsense). -- LCU ActivelyDisinterested «@» °∆t° 15:10, 8 December 2023 (UTC)

Yes. People who use tools like this should be checking and where necessary manually cleaning up with generated citations before clicking "Publish changes".  — SMcCandlish ☏ ¢ 😼  03:33, 9 December 2023 (UTC)

I've had to rebuild the referencing of many articles that ReFill or other tools have nuked. It would be useful to have error messages flash up when editors hit publish. -- LCU ActivelyDisinterested «@» °∆t° 14:55, 9 December 2023 (UTC)

I feel your pain.  — SMcCandlish ☏ ¢ 😼  02:52, 11 December 2023 (UTC)

Same. The whole idea that an algorithm can reliably produce accurate citations based solely on html metadata is uh folly. The full page has to be parsed, and sometimes even then it's not possible because some values load in through javascript. Evidently Zotero gets it right more often because their translators can follow after javascript loads in the client, but anything that runs on Citoid should have a minimum permissions group and a rate limit. Folly Mox (talk) 05:04, 11 December 2023 (UTC)

A rate limit sounds a good idea, many of the issue Wikipedia seems to face is editors running automated processes without any real oversight. By the time they get stopped they can in short order create a huge mess for other editors to clear up. -- LCU ActivelyDisinterested «@» °∆t° 15:31, 11 December 2023 (UTC)

{{cite web|website=Newspapers.com|title=New York Times - 1|archive-url=[...] Rjjⁱⁱⁱ (talk) 05:07, 11 December 2023 (UTC)

CS1 documentation is unclear and poor. I have detailed such issues here before, but I've only ever seen variations on the same response -- that if editors misuse parameters it's their own fault.

(If people are regularly misusing the parameters of your function, it's because your function documentation and/or semantics are inadequate.) SamuelRiv (talk) 04:16, 9 December 2023 (UTC)

SamuelRiv if you have any suggestions for best practice when citing videos hosted on Youtube, please dd them to the phab task :) John Cummings (talk) 08:21, 9 December 2023 (UTC)

Also, If you believe that the cs1|2 documentation needs to be improved, please improve it. The documentation is not protected so anyone may improve the documentation.

—Trappist the monk (talk) 12:56, 9 December 2023 (UTC)

This is a classic problem, people think the help documentation is poor but no-one wants to write help documentation. -- LCU ActivelyDisinterested «@» °∆t° 15:33, 11 December 2023 (UTC)

Hmph. I write more documentation that just about anyone on-site, but pretty much every time I touch those pages of documentation I get insta-reverted by one or two, um, "over-controllers" of their content. (I quite literally have a much higher success rate editing core policy pages.) It's basically too discouraging to much bother with. I only try it every few years or so, and it hasn't gotten any better/easier to get sensible changes to stick (other than fixing typos or code errors).  — SMcCandlish ☏ ¢ 😼  22:07, 12 December 2023 (UTC)

Need some sort of "id"/"ref" or similar parameter for some citation templates

In particular for Template:Cite press release, there is often an official id or reference number associated with pressers that would be great to be able to preserve and document in the {{cite ...}} reference, not in the least because it would aid the ability to search for alternative or archived urls if the source is dead. I can also see the need for other citation formats.

For an example, URL https://press.un.org/en/2022/ga12417.doc.htm is a UN press release with the ID GA/12417 that can be googled to find news articles or resolutions referencing the press release in question. Mahmoud (talk) 21:00, 9 December 2023 (UTC)

You can use |id= for this purpose. -- LCU ActivelyDisinterested «@» °∆t° 21:03, 9 December 2023 (UTC)

See Template:Cite press release#Identifiers for more information. – Jonesey95 (talk) 23:44, 9 December 2023 (UTC)

email not flagged

Hello, in this version of Miss Brazil CNB 2022 which has |last2=email, "CS1 errors: generic name" is not reported. Keith D (talk) 01:53, 13 December 2023 (UTC)

Local dates

Hello, I seem to have specified everything in the configuration, but it still does not want to read dates correctly in the local language: ru:Участник:Iniquity/test date - displays an error with the date. What could it be? Iniquity (talk) 18:32, 14 December 2023 (UTC)

I think that you need to set local_date_names_from_mediawiki = false; (line 615 in ru:Модуль:Citation/CS1/Configuration). When that is set true, the module overwrites your manual translations so the month-names that you used in your example (2 ноября – 21 декабря 1968) no longer exist. I think that I confirmed that with this in the debug console:

=mw.dumpObject (p.date_names['local']['long'])
table#1 {
    ["август"] = 8,
    ["апрель"] = 4,
    ["декабрь"] = 12,
    ["июль"] = 7,
    ["июнь"] = 6,
    ["май"] = 5,
    ["март"] = 3,
    ["ноябрь"] = 11,
    ["октябрь"] = 10,
    ["сентябрь"] = 9,
    ["февраль"] = 2,
    ["январь"] = 1,
}

Only twelve month names when there should be twenty-four; the month-names from your example are among the missing.

The template worked when I rewrote the date as |date=2 ноябрь – 21 декабрь 1968.

What happens when you set local_date_names_from_mediawiki = false;?

—Trappist the monk (talk) 19:54, 14 December 2023 (UTC)

Yes, this fix works! Thanks again :) Iniquity (talk) 19:58, 14 December 2023 (UTC)