Jump to content

Help talk:Citation Style 1/Archive 77

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 70←Archive 75Archive 76Archive 77Archive 78Archive 79Archive 80

url-status usurped

At Clanwilliam (County Limerick) I set several {{Cite web}} as url-status=usurped however the original links seem to be remaining in place, which is not what the documentation implies. I would not expect this, but admit I may have made a spelling mistake or something. In this case it is not too serious, in other cases it could be an inappropriate website. Thankyou. Djm-leighpark (talk) 21:04, 15 May 2021 (UTC)

The documentation is here. It says, in part:
When the original URL has been usurped for the purposes of spam, advertising, or is otherwise unsuitable, setting |url-status=unfit or |url-status=usurped suppresses display of the original URL (but |url= and |archive-url= are still required).
|url-status= is meaningless without |archive-url=. Where you set |url-status=usurped, those templates do not have |archive-url= so nothing happens.
—Trappist the monk (talk) 21:34, 15 May 2021 (UTC)

I have tweaked the Module:Citation/CS1/sandbox so that it adds a maintenance category when |url-status= is set but |archive-url= is not set. There were many upon many |url-status=<something> without |archive-url= that Monkbot task 18 cleaned up. That bot task is now suspended so we must seek another way of cleaning up this sort of problem.

{{cite book/new |title=Title |url-status=live}} → Title.{{cite book}}: CS1 maint: url-status (link)

Further, we might enhance this a bit so that |url-status=dead when |archive-url= has a value is also included in the maint cat; this is analogous to Category:CS1 maint: ref duplicates default.

Once the maintenance cat has been cleared, we should convert it to a normal error because, to be meaningful, |url-status= requires |archive-url=.

—Trappist the monk (talk) 22:05, 15 May 2021 (UTC)

Maybe the documentation could better clarify that a usurped url invalidates the link (if there is no legitimate archive link). In such cases the link should be removed. If the citation depends on the link for verification (likely where {{cite web}} is concerned), the citation itself is no longer valid and should be removed. 98.0.246.242 (talk) 22:29, 15 May 2021 (UTC)
I disagree that the citation is invalid and should be removed. It is the link that has become invalid, the citation itself was (likely) in good faith but verificability was lost. Citation removal can be tricky as it can sometimes(but not always) be recovered. As it is we leave it mostly in the hands of the bot(s) to hope successful archives are created, and they dont mark if this has not happened. And in the end manual dead/usurped link recovery can sometimes be more successful than the tool. I'm not actually sure what IAbot would make of the example given here. Djm-leighpark (talk) 01:00, 16 May 2021 (UTC)
Citations must verify the wikitext in real time, not sometime in the past or future. If they don't, they should be removed. It is worse to include a misleading (because unverifiable) citation, than having no citation at all, as it gives unverified claims the appearance of truthfulness. This is not something to leave to any bot. You, as editor, must support what you edit. This is policy, and non-negotiable. At the very least, mark the citation as needing work, and quickly (meaning in hours, not days) either correct it or remove it. 68.173.79.202 (talk) 13:06, 16 May 2021 (UTC)
Replaced, maybe, not necessarily removed. Please read WP:DEADREF. Known usurped/dead linked sources should, as you say, be marked or upgraded. I disagree with your strict statement that the citation itself is no longer valid and should be removed. — JohnFromPinckney (talk) 16:42, 16 May 2021 (UTC)
The last point at WP:DEADREF refers to removal when verification depends on the link only, without an archived version or other sourse. This was the rationale for the earlier comments above. Although the guideline on this point includes the following incomprehensible statement: if there is no archived version of the web page (be sure to wait ~24 months). No idea what this means in normal English. 98.0.246.242 (talk) 18:10, 16 May 2021 (UTC)

ssrn

Editor Nemo bis made this edit which is more or less pointless because identifier access is by default paywalled unless explicitly set to free. The Editor did add a comment in the code: 'often free to read, but rate limited and may require subscription'. I do not know how true that statement is so invite Editor Nemo bis to discuss that change here.

—Trappist the monk (talk) 14:24, 9 May 2021 (UTC)

I've removed the default option, since it access varies. SSRN started hosting pay-to-read articles, despite it being clearly against their stated mission. Headbomb {t · c · p · b} 16:09, 9 May 2021 (UTC)
But in addition to that, you need to login in order to be able to actually be able to download the supposedly open things. If you're logged out, you're subject to restrictions à la metered paywall, where the second PDF you download in a day will require you to login or things like that.
Changing the default access level is not "pointless". It's useful for people to be able to navigate the identifiers and links we provide in citations, which is the entire point of having them in the first place. Having the grey icon next to one identifier and the green icon next to another makes it easier to reach the full text without having to open a dozen tabs for each citations and without having to study the purpose and access model of each target website.
Nemo 17:18, 9 May 2021 (UTC)
"You need to login in order to be able to actually be able to download the supposedly open things", again, not for most papers. Most papers are free, and don't require login. Some might require registration. Others might require you to pay. Headbomb {t · c · p · b} 18:04, 9 May 2021 (UTC)
Support for |ssrn-access=free added:
Cite ssrn comparison
Wikitext {{cite ssrn|ssrn-access=free|ssrn=12345|title=Title}}
Live "Title". SSRN 12345.
Sandbox "Title". SSRN 12345.
It would be nice to track |ssrn= because each use of that parameter should be reviewed and |ssrn-access=free added where appropriate. But, recent XfDs prevent that without we first RfC for permission.
—Trappist the monk (talk) 12:04, 21 May 2021 (UTC)
? Is there an XfD with such implications? I thought the recent CfD (which is peripherally still under discussion) concerned different, specific parameters? 24.103.251.114 (talk) — Preceding undated comment added 12:47, 21 May 2021 (UTC)

Protected edit request on 16 April 2021

Please revert this edit, since it was based on the incorrect and now overturned closure of this RfC. The new close finds that "non-hyphenated parameters should not be deprecated in citation templates"; therefore the edit as it stands is in clear violation of this consensus. RandomCanadian (talk / contribs) 13:36, 16 April 2021 (UTC)

Accessdates and the like were not deprecated in that edit, so this edit request is based on a flawed premise. Headbomb {t · c · p · b} 13:47, 16 April 2021 (UTC)
Except it still marks these parameters as "discouraged", which is not what the close of the RfC says, does it? "This means that existing hyphenated (e.g. access-date) and non-hyphenated (e.g. accessdate) parameters should both continue to be supported by the templates." - if I can read the template correctly, that should mean they should be set to "true", not "pre-deprecation purgatory" (since there is explicitly no consensus to deprecated the parameters, now or at some future point). RandomCanadian (talk / contribs) 14:03, 16 April 2021 (UTC)
That edit has already been reversed in the module sandboxes, and the category description has been changed to explain that it is only a tracking category. Conversations continue above about how best to track the remaining unhyphenated parameters. – Jonesey95 (talk) 14:38, 16 April 2021 (UTC)
Oppose. Discouraged ≠ deprecated, and discouragement need not lead to deprecation. The RFC outcome (Option C) doesn't restrict "developer discouragement", so there is no need to reverse the edit. The module will continue to support both parameters. The module comment, re: "pre-deprecation purgatory", may be too aggressively suggesting deprecation, and can be changed or removed.   ~ Tom.Reding (talk ⋅dgaf)  16:27, 17 April 2021 (UTC)
The finding that these parameters are in any way "discouraged" was reversed, and the associated changes made should thus also be reversed. Nikkimaria (talk) 18:15, 17 April 2021 (UTC)
The concept of "discouragement" wasn't 'reversed' in close#2; it wasn't even mentioned. As such, the RFC has no bearing on whether or not to track these parameters in any way.   ~ Tom.Reding (talk ⋅dgaf)  21:36, 17 April 2021 (UTC)
Close#1 invented the concept of "discouraged", and was reversed, meaning that the concept no longer has any basis. The other changes associated with the reversed closure should similarly be reversed. Nikkimaria (talk) 21:50, 17 April 2021 (UTC)
Close#1 invented the concept of "discouraged" Not true. The first close invented the term developer discouraged. Elsewhere on this page, I wrote that developer discouraged is a new term to me. On my talk page, the closer confirmed the term is a made-up term created for the purpose of the close. The notion of discouraged cs1|2 parameters has been around for quite a while. Before it was deprecated and finally removed, use of |editors= was discouraged and at one time had its own tracking category Category:CS1 maint: uses editors parameter (July 2016 – August 2020). |authors= is discouraged; see, for example, the documentation at {{cite book}} and Category:CS1 maint: uses authors parameter (since July 2016).
—Trappist the monk (talk) 23:02, 17 April 2021 (UTC)
the closer confirmed the term is a made-up term created for the purpose of the close - ie. the close invented the concept as used in the context under discussion - the changes resulting from that close. The current close does not support the notion that these parameters are discouraged as you define it, nor that they require a maintenance category. Nikkimaria (talk) 23:17, 17 April 2021 (UTC)
You wrote: Close#1 invented the concept of "discouraged". That is a false statement because, as I explained, cs1|2 has had the concept of "discouraged" parameters since 2016. The closer's term, developer discouraged, as noted on my talk page where the closer wrote: No, I literally just made it up, was made up for the purposes of that close. Close #2 is mute with regard to categories; is mute with regard to the term discouraged; is mute with regard to the term developer.
—Trappist the monk (talk) 15:22, 18 April 2021 (UTC)
We should probably delete the main page and many other things, while we're at it, since the close made no mention of it.   ~ Tom.Reding (talk ⋅dgaf)  16:16, 18 April 2021 (UTC)
If you want to delete the main page, or make parameters discouraged, feel free to start a new RfC. In the meantime though, since the initial close was undone, the associated changes should also be undone. Nikkimaria (talk) 00:53, 19 April 2021 (UTC)

The request was for the module to be reversed; while it is nice that this has been done in the sandbox already, it doesn't answer the original request. If sandbox changes get automatically transported to the main module, then please tell us when. If not, then please inform us when this change will be reverted. Fram (talk) 17:22, 16 April 2021 (UTC)

Looking at Module:Citation/CS1, updates only happen every few months, and the most recent update was just a few days ago. It will probably be a while, given the need to avoid re-rendering millions of pages too frequently. Vahurzpu (talk) 02:51, 17 April 2021 (UTC)
Seeing as the initial RfC result was implemented within a week, it seems reasonable that the new result would also be implemented promptly, rather than waiting a few months. Nikkimaria (talk) 14:48, 17 April 2021 (UTC)
Indeed, I think that would be reasonable. I just don't think that we know what the exact next step is, especially with an unnecessary CFD started by thread OP. --Izno (talk) 14:54, 17 April 2021 (UTC)
RandomCanadian (the OP) didn't start the CfD. Fram (talk) 08:21, 19 April 2021 (UTC)
@RandomCanadian: Can this be closed? It's being discussed elsewhere (here and here). It's been more than ten days already while this edit request has been pending.. –MJL ‐Talk‐☖ 03:05, 28 April 2021 (UTC)
Note that Wikipedia:Categories for discussion/Log/2021 April 16#Category:CS1 maint: discouraged parameter has now been closed as delete. * Pppery * it has begun... 18:10, 9 May 2021 (UTC)

Now that the CfD has closed as "delete", can this edit request please be executed, and can the necesarry changes be made to depopulate the category? Fram (talk) 07:06, 10 May 2021 (UTC)

It would probably be better to wait for Wikipedia:Deletion review/Log/2021 May 10#Category:CS1 maint: discouraged parameter to close before taking any action. 13:23, 10 May 2021 (UTC) — Preceding unsigned comment added by Pppery (talk • contribs)
That DRV has now been closed without consensus to overturn the original CfD. Can someone please do this now? * Pppery * it has begun... 13:14, 18 May 2021 (UTC)
I wouldn't rush... The DRV reviewer's opinion has holes that have to be attended to. 64.18.9.210 (talk) 15:31, 18 May 2021 (UTC)
Please drop the stick. * Pppery * it has begun... 16:40, 18 May 2021 (UTC)

Now that the RfC close review, the CfD, the DRV, and the DRVRV are all closed, can we perhaps finally do this? Fram (talk) 14:21, 21 May 2021 (UTC)

 Done by Amakuru (this exact edit wasn't implemented, but code to depopulate the discouraged parameter was, which is what is fundamentally being asked for) * Pppery * it has begun... 15:14, 25 May 2021 (UTC)
Thank you. Fram (talk) 08:34, 26 May 2021 (UTC)

CS1 module suite update (date TBD) April 2021

I suggest that we do an out-of-cycle update to the cs1|2 module suite on a date TBD sometime between now and the end of April 2021, primarily in order to implement the reclosure of the unhyphenated parameter RFC. Here are the changes to date since the last major update on 10 April:

Module:Citation/CS1

  • detect generic author, editor, etc names; discussion
  • Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
  • add "CS1 uses parameter: $1" properties tracking categories; discussion
  • emit error when |first= is wikilinked; discussion
  • revise how date month-name auto-translation is enabled; discussion
  • add support to allow editors to see citations that emit properties cats; discussion
  • |url-status= without |archive-url= maint cat; discussion

Module:Citation/CS1/Configuration

  • detect generic author, editor, etc names
  • Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
  • add "CS1 uses parameter: $1" properties tracking categories
  • remove support for unused |isbn13= and |ISBN13=; discussion
  • remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
  • add support for nrf-gg, nrf-je language codes; discussion
  • revise how date month-name auto-translation is enabled
  • add support to allow editors to see citations that emit properties cats
  • Removed reliance on .error; discussion
  • |url-status= without |archive-url= maint cat
  • add support for |ssrn-access=; discussion

Module:Citation/CS1/Whitelist (updated 25 May 2021)

  • Remove support for previously deprecated parameters |booktitle=, |chapterurl=, |episodelink=, |mailinglist=, |mapurl=, |nopp=, |publicationdate=, |publicationplace=, |serieslink=, |transcripturl=
  • Remove code to detect, categorize, and display hidden maintenance message for "discouraged" parameters, per RFC reclosure.
  • add "CS1 uses parameter: $1" properties tracking categories
  • remove support for unused |isbn13= and |ISBN13=
  • add support for |ssrn-access=
  • remove support for url and URL from {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}}; discussion
  • Support for some template-specific parameters limited to those templates; discussion

Module:Citation/CS1/Date validation

  • extend allowed dates in |pmc-embargo-date= validation to two years; discussion
  • revise month-name validation; discussion
  • add support to allow editors to see citations that emit properties cats

Module:Citation/CS1/Identifiers

  • add support for |ssrn-access=

Module:Citation/CS1/Utilities

  • add support to allow editors to see citations that emit properties cats

Module:Citation/CS1/COinS

  • No changes

Module:Citation/CS1/styles.css

  • Removed reliance on .error

Module:Citation/CS1/Suggestions

  • Uncomment suggestions for parameters moving from deprecated to unsupported

Links to relevant discussions, along with implementation date suggestions, are welcome in the above list; they should all still be on this page. I will come back and add the discussion links if I have time later. – Jonesey95 (talk) 21:39, 19 April 2021 (UTC)

arxiv-class

Really don't see the point of having |arxiv-class=, class doesn't cover anything else, and is only supported by {{cite arxiv}}. There's no confusion possible, and I object its creation. Headbomb {t · c · p · b} 23:32, 19 April 2021 (UTC)
Yes, you know all this only if you follow this page. There's a chance that the module may be targeted to a wider audience. On that outside chance, the module should present editors a consistent approach, and its documentation should expand on consistency as one of the design principles applied. Additionally, the documentation could include info about the particular template, such as the one you referred to above. Again on the outside chance that editors may not encounter Arxiv or arxiv citations on a daily basis. I know, it's a drag. But you are not the one doing it, it is somebody else's burden. 173.52.226.51 (talk) 00:39, 20 April 2021 (UTC)
Actually, I'm the one doing most arxiv-related cleanup. Again, there is no confusion with anything, class doesn't pertain to anything but cite arxiv because class is only used with cite arxiv. If you don't use cite arxiv, you will not see class anywhere. |arxiv-class= is busy work that serves no purpose but to cause confusion by renaming a uniformly-used parameter into a mismash of new and old for no reason. Headbomb {t · c · p · b} 00:50, 20 April 2021 (UTC)
What was meant as "burden" was the updating/maintenance of the module. Otherwise, and sincerely, I believe that any work you do to clean up this area is commendable. 98.0.246.242 (talk) 03:28, 20 April 2021 (UTC)
"class" is a pretty vague parameter. I'm not personally sold on moving deck chairs around though so... Izno (talk) 01:15, 20 April 2021 (UTC)
These discussions about parameter labels are very refreshing. Questions spring to mind: how is an editor to know that only {{cite arxiv}} uses a "class" parameter? Secondly, is there an implicit assumption that there will forever be only one "class"-labeled parameter in all of CS1/2? I understand that people with intimate knowledge of Arxiv will find the new term unnecessary and convoluted. I am not in favor of aliases, but I would recommend |arxiv-class= as an alias of |class= for this template. CS1/2 covers a diverse field of cited sources. It is not unusual to find in any article a number of different CS1/2 citation templates. At some point, it may be easier for the average editor to have to deal with a single standardized nomenclature (the one native to CS1/2) rather than wade through unfamiliar "industry" practice. Assuming that such nomenclature is simply and concisely explained. 98.0.246.242 (talk) 03:19, 20 April 2021 (UTC)
How is an editor to know that only {{cite arxiv}} uses a "class" |class= only appears in {{cite arxiv}} documentation, and is undermentioned anywhere else. Headbomb {t · c · p · b} 12:03, 20 April 2021 (UTC)
I have my doubts that even seasoned template editors would know this. It may require an extraordinary level of attention to the particulars of template/parameter documentation. 98.0.246.242 (talk) 23:57, 21 April 2021 (UTC)
CS1/CS2 parameters should follow a consistent naming scheme within the CS1/CS2 universe so that they are easy to memorize (and ideally can be constructed from memorizing the scheme without having to remember a particular parameter specifically or to look up it up the documentation). They should also be self-explanatory so that if a user runs into a parameter s/he can guess the meaning without having to look up the documentation. While there are still areas for improvement, I think we have improved quite a bit regarding this in recent years.
|class= by itself is quite meaningless and ambiguous. There are other possible "classes" that are used in conjunction with references. We don't currently use them but we might have other |...-class= parameters in the future, so I think it is time to prepare for this. We don't need to hurry, |class= can stay for the while being, but the |arxiv-class= parameter should exist as well for a smooth transition.
Parameters and attributes named "class" are also used for other purposes (for example in HTML), making it difficult to reliably search for the CS1 parameter |class=. Searching for |arxiv-class=, however, would not give false positives.
As the |arxiv= parameter is supported by other CS1 templates than {{cite arxiv}} as well, is there a specific reason why we do not support the |class= parameter in other templates as well?
--Matthiaspaul (talk) 19:48, 22 April 2021 (UTC)
Simply put, no. This is citations, not CSS. We do not need to preemptively disambiguate something that doesn't need disambiguation. As for not supporting it in other citations, it's because it's not relevant to other citations. This is something that's only relevant to {{cite arxiv}}. There is zero point in forking the parameter and breaking tools for, we have consistant usage, let's keep it that way. Headbomb {t · c · p · b} 19:52, 22 April 2021 (UTC)

Reverted the arxiv-class thing in the sandbox. This does not have consensus. Headbomb {t · c · p · b} 05:01, 28 April 2021 (UTC)

Headbomb, I think your removal was incomplete. The sandbox renders with red Lua errors. Scroll up and down this page to see them. – Jonesey95 (talk) 05:10, 28 April 2021 (UTC)
He removed the whole line and probably should not have since that is not undoing what the original edit did. ;) Fixed. Izno (talk) 05:19, 28 April 2021 (UTC)
Yes, thanks for fixing. LUA is awful. Headbomb {t · c · p · b} 05:55, 28 April 2021 (UTC)
I don't find your arguments that we shouldn't have |arxiv-class= very convincing.
{{cite arxiv}} is a CS1/CS2 citation template and within that family of citation templates all parameters should follow the same naming scheme in order to make it easier for editors to remember or even derive parameter names and their relations. This holds true also for parameters which are for some reason private to a specific template only, because otherwise we could have a |class= parameter in another template with a completely different meaning. |class= being a modifier for one of the identifiers (|arxiv=) its name should be |arxiv-class= following the example of all other such parameters we have (|doi=/|doi-broken-date=, |pmc=/|pmc-embargo-date=, |asin=/|asin-tld=) and a whole bunch of |bibcode-access=, |doi-access=, |hdl-access=, |jstor-access=, |ol-access=, |osti-access=, |s2cid-access=. They all start with the identifier name they belong to and end on the argument type to be entered (a date, a top-level-domain, an access state), so following this scheme a class type belonging to |arxiv= should be specified in a parameter named |arxiv-class=. This would be consistent. |class= by itself is not following this scheme and therefore is inconsistently named. It is also a meaningless parameter name by itself, so people running into it cannot derive its purpose from its name, and for people who are potentially using it, it is more difficult to remember because it is an exception to the mind model of how other parameter names were chosen.
Unfortunately, you didn't answer my question why we don't support the parameter in all CS1/CS2 parameter supporting |arxiv=. You just stated it would not be relevant in other templates, but did not answer why. In the original thread you even asked for |class= to become kind-of a mandantory parameter for {{cite arxiv}}; from this I derive that it is important to you. So, why is it important in {{cite arxiv}} and not in, say, {{cite book}} which supports |arxiv= as well? I'm asking because right now it is handled as an exception, and it would simplify the code if we won't have to treat it like an exception.
Regarding HTML/CSS, the existence of the "style" attribute was brought forward against naming a parameter |style=, which is (one reason for) why we settled on |name-list-style= eventually. Similar situation for "class".
Regarding scripts, adding a parameter is not breaking anything. And it would be trivial to change the scripts to support both parameters |arxiv-class= and |class=, anyway (if we don't fade out |class= at a later stage). If, as you stated, you are mostly alone working in this area, updating the scripts should be even easier. Of course, in an ideal world a good parameter name would have been chosen right from the start, so that there would be no desire to change it, but if we want to reach the goal of having a logical and consistent interface for all CS1/CS2 templates eventually, we shouldn't wait harmonizing parameter names until we actually run into a name conflict, because the longer we wait the more we will have to clean up afterwards. Therefore, even if we do not disable support for |class= soon (in order to keep backward compatibility until everyone has switched), we should start to educate people to use |arxiv-class= instead as soon as possible.
--Matthiaspaul (talk) 07:18, 28 April 2021 (UTC)
Except that class doesn't modify in anyway arxiv. What you'll find in {{cite arxiv}} is most typically {{cite arxiv|...|eprint=1234.54321|class=hep-ex}}. Headbomb {t · c · p · b} 09:27, 28 April 2021 (UTC)
I'm inclined to agree with Editor Matthiaspaul because I too don't find Editor Headbomb's reason persuasive. Editor Headbomb appears to be the only editor who is opposed; Editor Izno appears to be indifferent; IP editor (98.0.246.242, 173.52.226.51) appears to support; Editor Matthiaspaul supports; and I support because I am persuaded by the argument that parameter names should be correctly descriptive (we should think about |ref= – in another discussion). So, I think that Editor Headbomb's edit should be reverted.
—Trappist the monk (talk) 13:10, 28 April 2021 (UTC)
The argument for renaming the parameter arxiv-class in cite arxiv is as nonsensical as renaming isbn to book-isbn in cite book. It's a parameter unique to cite arxiv, there is no need for disambiguation, especially at the expense of creating unnecessary complexity that will cause maintenance headache and tool breakage. Headbomb {t · c · p · b} 15:49, 28 April 2021 (UTC)
I think right now I lean toward "let's not move the deck chairs around with only 3 in support and 1 opposed" at this time. Adding a parameter later is easy; removing one later is not. Generally I'd be appreciative for opinions from editors who aren't you four. I see persuasive arguments for changing the name but not sufficiently persuasive if all it is doing is moving deck chairs (or with the stated purpose of moving deck chairs).
That all said, I continue to prefer to wait until the CFD for the category responsible for this update be settled first, so perhaps others may comment and settle the matter. Izno (talk) 14:21, 28 April 2021 (UTC)
I would say that any discussion in these parts involving 4 editors is packed to the rafters... 98.0.246.242 (talk) 01:12, 4 May 2021 (UTC)
As much as it pains me to say it, Izno was right to say that we should wait for the CFD closure. Blargh. – Jonesey95 (talk) 18:20, 9 May 2021 (UTC)
What is the use of |class= even in {{Cite arXiv}}? This is not physical library where we need to first take the stairs to astro-ph. Is is because some areas have low standards or because it helps identify areas like a journal title would or is it another reason? AManWithNoPlan (talk) 01:52, 21 May 2021 (UTC)
It's the topical classification of the arxiv, which corresponds to moderation sections (i.e. standards). hep-ph is in the High Energy Physics - Phenomenology section, hep-ex is the High Energy Physics - Experimental section. gen-ph is general physics [which is where a lot of woo nonsense get classified into], and so on. A while back, this was part of the identifier (physics/0123467), but the identifier changed to YYMM.####, with the classification listed separately in square brackets. Headbomb {t · c · p · b} 03:23, 21 May 2021 (UTC)
See also User_talk:Headbomb/unreliable#gen-ph. Headbomb {t · c · p · b} 03:27, 21 May 2021 (UTC)
Years ago it was explained to me that a national physics conferences have an anything goes crack-pot section in which basically all talks were accepted, but were limited to 5 minutes including the changing speaker time. We chemists generally have a poster section like that. AManWithNoPlan (talk) 14:27, 21 May 2021 (UTC)

Anyone want to update the list and support this update?

A number of changes have been made to the sandboxes since I posted the above list. Is there support for this out-of-cycle update? If so, please speak up here, and someone needs to update the above list of changes. – Jonesey95 (talk) 05:10, 28 April 2021 (UTC)

So long as arxiv-class is kept out, what's in there shouldn't be controversial / reflects RFCs. Headbomb {t · c · p · b} 09:25, 28 April 2021 (UTC)
I've made an attempt at updating the list of changes from the comments section of each sandbox, although there appear to be some edits to Module:Citation/CS1/Identifiers/sandbox and Module:Citation/CS1/Configuration/sandbox that don't have any entry in the changes list. (And I support this update happening, in order to finally implement the result of the discouraged parameters CfD) * Pppery * it has begun... 00:47, 21 May 2021 (UTC)
... does something else need to be done before this update happens? * Pppery * it has begun... 00:02, 22 May 2021 (UTC)
I believe it should be good to go from what's in the Sandbox. @Trappist the monk: is there anything holding this up? I would sync from the sandbox myself, but it looks like nobody except Trappist has edited Module:Citation/CS1/Whitelist in the past eight years, so I don't want to tread on any toes! We do need to get the latest updates in though, because currently certain parameters are still being tracked as "discouraged". Cheers  — Amakuru (talk) 21:02, 23 May 2021 (UTC)
More silence ... @Amakuru: The CS1 module suite is not WP:OWNed by Trappist the monk, and this would not be the first time an external admin edited it. The only reason Module:Citation/CS1/Whitelist hasn't been edited by anyone else in years is that its contents have never been controversial before, whereas various other CS1 modules have been controversial and were edited by others at various times. You should just do it, and either copy from Module:Citation/CS1/Whitelist/sandbox to Module:Citation/CS1/Whitelist, or just implement #Protected edit request on 16 April 2021 above and revert the last two edits to Module:Citation/CS1/Whitelist(going back to Special:PermaLink/999303024). It's more important that things get done than vague worries about things like tread[ing] on [...] toes at this point (now more than 2 weeks after the CfD was closed, and one week after the DRV was closed) * Pppery * it has begun... 14:03, 25 May 2021 (UTC)
@Pppery:  Done. As you say, there has been enough time for this to be enacted, and nobody has even replied to the above comments. So I have gone ahead and pushed the sandbox changes from Module:Citation/CS1/Whitelist/sandbox live into Module:Citation/CS1/Whitelist. If anything else needs doing, or this leads to any errors then please let me know.  — Amakuru (talk) 15:13, 25 May 2021 (UTC)
Thanks. I don't think anything else needs doing, although it will likely take several weeks for the Job queue to remove all 1,000,000+ pages from the category. * Pppery * it has begun... 15:22, 25 May 2021 (UTC)

Tracked parameter code (partially?) removed

The "discouraged parameter category" this CFD has been closed, and Pppery set the hyphenated parameters back to "true" in Whitelist/sandbox (no judgment on this action, just stating facts to keep the timeline straight). I don't think that change to just one of the modules will completely undo the parameter tracking system that we have set up. It is unclear to me whether the sandboxes are in a deployable state as of this time stamp. – Jonesey95 (talk) 18:20, 9 May 2021 (UTC)

I believe it's deployable in the sense that nothing would break were they to be deployed, but there's some now-dead code in the Configuration and main modules that someone could clean up if they felt inclined to. * Pppery * it has begun... 00:45, 10 May 2021 (UTC)
I would recommend waiting. I have commented at the closer's talk page (well one of them) and at CfD regarding the closure, which imo is ripe for review. So let's see where this will go, if anywhere. Relax and enjoy! 98.0.246.242 (talk) 01:44, 10 May 2021 (UTC)
Note that this IP has now taken the CfD to deletion review at Wikipedia:Deletion review/Log/2021 May 10#Category:CS1 maint: discouraged parameter. * Pppery * it has begun... 13:23, 10 May 2021 (UTC)
... and the DRV has now been closed without consensus to overturn the CfD closure. Can this please go ahead now? * Pppery * it has begun... 13:14, 18 May 2021 (UTC)
Maybe, maybe not. I have asked for certain clarifications from the DRV reviewer. Depending on whether the answers are forthcoming and make sense, this will then proceed accordingly. 67.254.224.137 (talk) 19:53, 18 May 2021 (UTC)

I am having a nice discussion with the DRV reviewer about this. But I don't want to be seen as holding up anything that happens here. I have a feeling that the issue of the biased CfD nomination may have to be escalated to a wider forum more appropriate to reviewing administrator decisions. So please proceed, I have no objections, as the final resolution of this may take a while. And of course anything can be reversed :-) 64.18.9.192 (talk) 12:10, 19 May 2021 (UTC)

Preprint template TemplateData showing multiple "not valid parameter" errors

{{cite arxiv}}, {{cite biorxiv}}, and {{cite ssrn}} are all showing at least one "not valid parameter" error message at the top of their TemplateData sections. Some of the messages conflict with existing template documentation. I don't mess with TemplateData, but if anyone wants to sort this out, that would be helpful. If actual documentation changes are needed, I'm happy to help with those. – Jonesey95 (talk) 16:36, 25 May 2021 (UTC)

New "unsupported parameter" errors after Whitelist update

A note to those who watch the "unsupported parameter" error category: the Whitelist portion of the module was updated today, and it has resulted in a flow of new pages into Category:CS1 errors: unsupported parameter. I believe that I have compiled a comprehensive list of the relevant changes below:

The documentation for the relevant CS1 templates does not entirely match these changes yet, and in some cases, the Whitelist, instead of the documentation, may need to be modified. The documentation for {{cite serial}}, for example, currently shows |season= as valid, but it generates an error. Post any questions here. – Jonesey95 (talk) 17:02, 25 May 2021 (UTC)

@Jonesey95: thanks for compiling this list. If there are any Whitelist changes that need to be effected, and Trappist isn't around, then I'll be happy to help out. Cheers  — Amakuru (talk) 17:07, 25 May 2021 (UTC)
@Amakuru: I guess this was done to finally implement the RfC consensus (seeing as the hyphenated parameters are no longer classified as "discouraged")? @Jonesey95 why is the second "cite episode" unlinked when the other repeated template names are linked -BRAINULATOR9 (TALK) 17:28, 25 May 2021 (UTC)
@Brainulator9: yes, that's correct. See the section above, at Help talk:Citation Style 1#Anyone want to update the list and support this update? I implemented all the changes that were waiting in the sandbox, which I assume is the usual procedure. Presumably it's those changes that have led to the now-deprecated parameters mentioned above. Cheers  — Amakuru (talk) 17:39, 25 May 2021 (UTC)
Yes, the change to the Whitelist has resulted in a new batch of citations being detected as using unsupported (not deprecated; there is a meaningful difference when it comes to this module at least) parameters. – Jonesey95 (talk) 18:30, 25 May 2021 (UTC)

Identifying paper with cite conference

The documentation at template:cite conference for {{cite conference}} is incomplete, e.g., it mentions |book-title= but does not describe its use nor its relation to |conference= and |title=. As a concrete example, if I want to cite the paper The interface message processor for the ARPA computer network, which was presented at the 1970 Spring Joint Computer Conference and printed in AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference, do I mark it up as 

{{cite conference
 |      title = The interface message processor for the ARPA computer network
 |      pages = 551-567
 | conference = 1970 Spring Joint Computer Conference
 | book-title = AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference
 |       year = 1970
 |  publisher = AFIPS Press
}}

which will render as

"The interface message processor for the ARPA computer network". AFIPS Conference Proceedings Volume 36 1970 Spring Joint Computer Conference. 1970 Spring Joint Computer Conference. AFIPS Press. 1970. pp. 551–567.

or do I abbreviate SJCC, remove some of the redundant text or wikilink, e.g., AFIPS, in the parameters? Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:51, 25 May 2021 (UTC)

You figured it out. I have updated the documentation to explain how to use |book-title=. I don't know when that explanation went missing, if it was ever there. – Jonesey95 (talk) 18:43, 25 May 2021 (UTC)

Template:Cite sign

What parameters are supported by Template:Cite sign, and where is the blank version we are told to copy? DuncanHill (talk) 22:45, 24 May 2021 (UTC)

I'm also having this issue. The template needs more descriptors specific to signs, too. Tyrone Madera (talk) 19:21, 25 May 2021 (UTC)
@Tyrone Madera: As there appears to be nobody here either willing or able to help I shall ask at WP:VPT instead. DuncanHill (talk) 15:20, 30 May 2021 (UTC)
I've made a start on a blank version. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:28, 30 May 2021 (UTC)
@Pigsonthewing: thank you, and is there anything in this which you might find helpful? DuncanHill (talk) 16:18, 30 May 2021 (UTC)

edtf date formats as cs1|2 date parameter values (-2)

MediaWiki giveth; MediaWiki taketh away. Changes made because of phab:T132308 are to be rolled back so I have removed support for the EDTF (YYYY-MM-XX) date format from the sandboxen.

—Trappist the monk (talk) 22:15, 11 May 2021 (UTC)

We might need a bot run to fix the 600+ articles in which this format currently appears. – Jonesey95 (talk) 22:43, 11 May 2021 (UTC)
I don't think so. In bureaucratic terms, a WP:BRFA is far too costly. I've begun picking away at the 600 with awb as the mood takes me; I'll be done soon enough, after all, there is no hurry.
—Trappist the monk (talk) 23:00, 11 May 2021 (UTC)
"In bureaucratic terms, a WP:BRFA is far too costly." This is the sort of thing that could be approved in a day after a short trial. Headbomb {t · c · p · b} 23:17, 11 May 2021 (UTC)
Could be AWBd in 2 hours instead... Izno (talk) 23:57, 11 May 2021 (UTC)
That has never been my experience. And besides, in the current toxic atmosphere 'Monkbot task anything' is likely to incite drama. No thanks.
Current batch of YYYY-MM-XX dates converted. There are likely to be more between now and when the rolled-back version of citoid goes live.
—Trappist the monk (talk) 13:12, 12 May 2021 (UTC)
I've been wondering if we shouldn't just make a |machine-date= for machine filling. (I briefly considered |iso-date= but that doesn't indicate to users that they shouldn't use that.) Use it as the backup date if someone should add |date=. Izno (talk) 03:44, 31 May 2021 (UTC)

Cite serial

Is there any reason that {{Cite serial}} (274 transclusions) cannot be merged into {{Cite episode}} (over 15K transclusions)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:29, 30 May 2021 (UTC)

I think it should be redirected after ensuring that nothing will break. I've never fully understood the difference between them. In practice, {{cite serial}} appears to be used quite a bit for individual episodes instead of something that is part of "a collection of episodes" that is not a season (UK "series"). The edit summary for its creation says Creating "Cite serial" - it's a copy of "Cite episode" except it italicizes a serial title, rather than putting it in quotes. For use of tv shows which use both serial titles and episode titles. In practice, I don't think it's used for that in most cases. Perhaps we should just go through the citations one by one and convert the ones that cite a single episode (without a serial title) to {{cite episode}}, and then see what is left. – Jonesey95 (talk) 17:41, 30 May 2021 (UTC)
Agreed. I tried to conceive a valid reason for one to cite an entire season/series rather than the particular episode(s), and it escapes me. The closest I could come to a rationale would be an article citing multiple episodes of the same series, where the editor might prefer a compound reference with the series as the main citation and the individual episodes in sublist. A bit involved. 161.221.13.10 (talk) 20:30, 30 May 2021 (UTC)
Surprisingly no previous TFD on the point that shows up in WLH. I vaguely recall this being somewhat contentious, but maybe that's some weird memory to do with Dr. Who fans (you know how they get).
The migration to CS1 discussion may be illuminating as to actual purpose and why they weren't merged way back when. Izno (talk) 20:42, 1 June 2021 (UTC)

How to markup reports done under contract to government agencies?

I want to create a citation for https://apps.dtic.mil/dtic/tr/fulltext/u2/a206308.pdf in Timeline of operating systems#1980s, and am having trouble locating the correct template and parameters. The markup 

{{cite report
 |     title = Quarterly Status Report - Report #1 
 |        id = AD-A206 308
 |      date = 15 March 1989
 |       url = https://apps.dtic.mil/dtic/tr/fulltext/u2/a206308.pdf
 | publisher = TRW - Federal Systems Group - Systems Division
 }}

produces "Quarterly Status Report - Report #1 (PDF) (Report). TRW - Federal Systems Group - Systems Division. 1989-03-15. AD-A206 308." and seems like a reasonable start, but it is missing, e.g., the contract number, the order code, the program code, the program name, the sponsoring agency. I intend to use |work= for the program name as a stopgap, but that doesn't seem right. What is the proper markup? 15:58, 31 May 2021 (UTC)Shmuel (Seymour J.) Metz Username:Chatul (talk)

Chatul Is all of that detail really neccessary to uniquely identify the document? Roger (Dodger67) (talk) 16:31, 31 May 2021 (UTC)
Agreed, that detail is not generally necessary. You might consider |via= for DTIC and |work= for Advanced Computing Systems: An Advanced Reasoning-Based Development Paradigm for Ada Trusted Systems and Its Application to MACH. That would be the sufficient details to find a copy. (Also |archive-url= and -date, of course.) --Izno (talk) 16:58, 31 May 2021 (UTC)
You can also put any text that you want to append after the cite template itself, and inside the ref tags: Quarterly Status Report - Report #1 (PDF) (Report). TRW - Federal Systems Group - Systems Division. 1989-03-15. AD-A206 308. Contract number ABCD123. Sponsored by DARPA. etc. – Jonesey95 (talk) 21:48, 31 May 2021 (UTC)
Are you proposing
{{cite report
 |     title = Quarterly Status Report - Report #1 
 |        id = AD-A206 308
 |      date = 15 March 1989
 |       url = https://apps.dtic.mil/dtic/tr/fulltext/u2/a206308.pdf
 |      work = Advance Computing Systems: An Advanced Reasoning-Based Paradigm for Ada Trusted Systems and its Application to MACH
 |       via = https://apps.dtic.mil/dtic/tr
 | publisher = TRW - Federal Systems Group - Systems Division
 }}
Contract number MDA 972-89-C0029. Sponsored by [[DARPA|ARPA]], order No. 6414, Program Code No. 9T10.
BTW, the actual title included the date. Was it proper to redact it since I had a |date=, or should I have left it in? Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:36, 1 June 2021 (UTC)
Via is not for URLs; use DTIC in context. Yes, that is what Jonesey is proposing. Izno (talk) 14:51, 1 June 2021 (UTC)
Yes, 'suppressing' the date is fine and/or idiomatic when it appears in the title (probable exception: you have nothing else to put in the title). Izno (talk) 14:55, 1 June 2021 (UTC)
I'm not aware of any guidance in WP:MOS on what level of detail to provide in citations; such guidance, and links to it from template documentation, would be helpful. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:36, 1 June 2021 (UTC)
Sufficient information to identify where the information being cited originates such that another sufficiently motivated person can verify the content being cited themselves (c.f. WP:Citing sources). For web sources, this is fundamentally the URL and perhaps the archive URL. Anything else is largely a bonus. The parameters this template supports are almost always sufficient to identify a source. Certainly, contract number, sponsoring agency, order number, and program code are superfluous given the other information in the cite report you have filled in response to Jonesey's comment. Izno (talk) 14:54, 1 June 2021 (UTC)

|lay-url and |laysummary

WP:MEDPOP suggests using {{{laysummary}}}. However, when I put that into the template, apparently, because somebody decided somewhere that unhyphenated parameters are not OK, I get this error message... So the solution is either A) to add the suggested alternative as an alias (as consistent with making templates easier to use for everyone) or B) to update MEDPOP to enforce whatever you folks over here have decided on doing. Cheers, RandomCanadian (talk / contribs) 19:25, 1 June 2021 (UTC)

Updated medpop.
The 'lay source' parameters that are supported are a topic of discussion for the chopping block in a few recent instances on this talk page, because if the lay source really is valuable as a source, it should get its own template, not be hacked badly into the journal article's template. Current use of lay-url is only 2300 pages. Izno (talk) 20:24, 1 June 2021 (UTC)
|lay-date=, |lay-format=, |lay-source=, and |lay-url= should go away because cs1|2 templates are intended to cite a single source. These parameters make it sort-of-possible to cite two independent sources using a single cs1|2 template but, the citation of the second source is flawed because these four parameters cannot be used to create a complete second citation and there is no support in the citation's metadata for the second source. If the lay source is truly important to an article (WP:MEDPOP seems to suggest that most lay sources are not), then {{cite magazine}}, {{cite news}}, {{cite web}}, etc are better choices for citing the lay source.
—Trappist the monk (talk) 23:09, 1 June 2021 (UTC)
the lay source is often the orginal source too because of template misuse. AManWithNoPlan (talk) 23:16, 1 June 2021 (UTC)

cite newspaper

Given that pages using {{cite news}} outnumbers {{cite newspaper}} by over a factor of 100, and newspaper is just a redirect. Is there any reason to not have the Citation Bot covert newspaper to news when it finds them? AManWithNoPlan (talk) 01:14, 27 May 2021 (UTC)

If that were the only change Citation Bot made to a page, it would be a cosmetic edit, and six editors would show up with pitchforks and torches and block the bot. Other than that, I don't see a problem with it, and the guideline at WP:BRINT vaguely supports replacing template redirects with their targets, as long as there is some other substantive change being made to the page at the same time. – Jonesey95 (talk) 15:12, 27 May 2021 (UTC)
No pitchforks from my side, but I think that {{cite newspaper}} is actually the more appropriate name for the template. {{cite news}} has the advantage that it is shorter. What gives? Keep them as was decided upon by the editor who added them. ;-) --Matthiaspaul (talk) 16:57, 29 May 2021 (UTC)
The ratio of pages with news to newspaper is about 200 to 1. I highly doubt almost anyone is make a decided choice - some editors carefully choose between issue and number in cite journal, so never say never. I find that many applications of newspaper are to online newspapers and many applications of news are to paper copies. The existence of two templates only can confuse editors and in no way helps users. AManWithNoPlan (talk) 17:05, 29 May 2021 (UTC)
In fact, I'm one of those who tries to carefully distinguish between journals and magazines, numbers and issues, written-at and publication places, etc., always trying to use what is used in the actual source, if that can be determined, and use the most specific parameter or template name for it. While some of this gets displayed the same way at present, this may not always remain so in the future. For example, if we switch the display of journals to use abbreviations instead of the symbolic notation we use now, we will ideally have to distinguish in the display of "No." and "Iss.". This will also have to happen when we finally add support for periodicals which indicate both, a number and an issue, as we long planned to do. Similar, if I cite from what can be clearly identified as a newspaper, either because it advertises itself as such, or if I cite from something for which a paper issue exists, I use {{cite newspaper}}. If I cannot determine this, I typically use {{cite news}} if it is a news outlet and {{cite web}}, if it is some other type of web page. While {{cite newspaper}} and {{cite news}} do the same at present, at some point in the future, they may deviate in different directions supporting different parameters or requiring a different rendering (like {{cite journal}} and {{cite magazine}}) or different meta-data creation. So, it makes sense to give the editor, who is actually citing the source, the chance to document what it actually is - it will be much more difficult for other editors and at a later point in time - and next to impossible for a bot. Occasionally, someone might have used {{cite journal}} for a magazine, {{cite magazine}} for a journal, etc. and it is perfectly fine for another editor to improve that, but unless a bot is utilizing a curated datebase indicating if some outlet is a journal or a magazine, this is not something a bot should try to do. Same for {{cite newspaper}} and {{cite news}}.
Another reason why I generally tend to prefer {{cite newspaper}} over {{cite news}} is that the latter is somewhat ambiguous a name as we also have {{cite newsgroup}} - sometimes, when I haven't used the template for some while, I wonder if {{cite news}} is the same as {{cite newsgroup}} or {{cite newspaper}}, so it is safer to use the longer, more specific names.
--Matthiaspaul (talk) 08:44, 30 May 2021 (UTC)
Do the existing templates support the distinctions that you wish to preserve? Does the documentation describe all of the relevant parameters? I know that for, e.g. {{cite book}}, it is not possible to preserve the hierarhical relation among part, chapter and section, since all of the types of locations are synonymous or undefined, and only one location and its URL is allowed. You can't maintain fidelity without enhancing the existing templates. Try, e.g.,

{{cite book | title = Text with nested divisions | part = foo | chapter = bar | section = baz }}

and you get

"bar". Text with nested divisions. {{cite book}}: More than one of |section= and |chapter= specified (help); Unknown parameter |part= ignored (help)

Would what you want to do with {{cite newspaper}} have similar issues? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:15, 30 May 2021 (UTC)
I would not consider fidelity a requirement. Citations are pointers to sources. As long as the source can be easily located with a minimum of information, citations do not need to be exact representations of the source's structure. The additional info may give a better picture of the source to the reader or it may make it easier to locate. This has to be measured against clutter and complexity. Also, templates are just that. They are formatted applications of the most generic cases, of common denominators and regular trade practice. Covering more specialized cases is not really the main objective, and imo is not worth the programming effort. Especially so when programming is subject to irrational whims and the technicalities surrounding such work have to be submitted for review. 23.246.115.158 (talk) 13:05, 31 May 2021 (UTC)
The final sentence above was not referring to editor Chatul. 64.18.9.192 (talk) 13:52, 31 May 2021 (UTC)
Is {{cite newspaper}} still appropriate when the news isn't available on paper but only as web page text, audio or video? Certes (talk) 17:12, 29 May 2021 (UTC)
Is "page" appropriate in the present medium? Can we please step away a bit from micromanaging everything. Sheesh! 98.0.246.242 (talk) 17:19, 29 May 2021 (UTC)
FCOL, {{cite newspaper}} is and always was a redirect. When did WP:NOTBROKEN become obsolete (or should I say, deprecated). Sheesh indeed. -- Michael Bednarek (talk) 17:29, 29 May 2021 (UTC)
http://en.wiki.x.io/wiki/Wikipedia:Templates_for_deletion/Log/2007_October_13#Template%3ACite_newspaper {{cite newspaper}} was voted to be deleted, and the redirect was put in place to hold us over until all the usages were removed. AManWithNoPlan (talk) 14:13, 2 June 2021 (UTC)
Not quite. The template was indeed deleted in October 2007 and then recreated as a redirect in February 2008. Redirects to templates are a dime a dozen, and sometimes more used than their canonical names. There's nothing wrong with that and there's no need to do anything about it. -- Michael Bednarek (talk) 14:54, 2 June 2021 (UTC)
It is not obsolete, but as a cosmetic change with other non-cosmetic changes template redirects are quite often converted to their canonical name to simplify the root wikitext. As Jonesey above points out this is routine and implemented in other (semi)automated systems.
CitationBot converting to the canonical form in this case seems quite reasonable. Izno (talk) 15:51, 2 June 2021 (UTC)
Redirects may be free, but free can mean many things, in computing. I've spent a lot of my "free" time discovering and programming around them (or missing and causing errors), that would have been better used elsewhere. That doesn't mean eliminate all aliases, they can be useful, but when they are small in number let's convert to canonical. If they fail to reappear (no one is using them) then delete. -- GreenC 19:37, 2 June 2021 (UTC)

Suffixes?

Just curious, in the Cite xxx templates, what about suffixes like Jr., Sr., III, etc.? They are part of the "first" parameter, right? Thanks! — XComhghall (talk) 10:43, 2 June 2021 (UTC)

Correct. I would separate with comma to disambiguate compound first names or middle anything. 24.103.251.114 (talk) 11:20, 2 June 2021 (UTC)
Clarify:
{{cite book|first=FirstA FirstB, Sr|last=Last|title=Title}}
Last, FirstA FirstB, Sr. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)
This is not a guideline, just a personal pref. 24.103.251.114 (talk) 11:31, 2 June 2021 (UTC)
I generally do not place the comma per MOS preference for no-comma, but yes, placing it in |first= is correct. I also do not add a comma for some future where we can detect commas in our name parameters for maintenance. Izno (talk) 15:56, 2 June 2021 (UTC)
There is a guideline for this. See MOS:JR, which says When the surname is shown first, the suffix follows the given name, as Kennedy, John F. Jr. Also, in an accompanying note, we find: Do not append "Jr." and the like to the surname (Kennedy Jr., John F.) especially in citations, as this pollutes the surname metadata with extraneous information and will also alter the sorting order, to after all simple "Kennedy" entries. So |first=John F. Jr. would be correct per MOS in a cite template. – Jonesey95 (talk) 16:07, 2 June 2021 (UTC)

Having a special value for url-status when a page is geo-restricted?

This came to my mind when I was considering citing a page from a video streaming website. It had a TV show description I needed but rendered a "content isn't available in your country" template page until I used some VPN magic. Still it is crawlable by Internet Archive (with desired content shown in place), so despite the fact that citing a source like this should be avoided if possible, I can imagine having a thing like "url-status=georestricted" that could be used alongside with "archive-url". Kadilov (talk) 12:10, 2 June 2021 (UTC)

Georestrictions may have legal ramifications that should not be gamed by archive links. I suggest offering the source in a different, legitimate form. 50.74.165.202 (talk) 13:27, 2 June 2021 (UTC)
I agree after giving some more thought to this. As I see it now, an archiving service may be the first actor who violates something in this chain, though it does not relieve others from responsibility. Kadilov (talk) 11:55, 3 June 2021 (UTC)
This is a regular request. Please review the archives for why it has not been implemented. Izno (talk) 15:38, 2 June 2021 (UTC)
Thanks. Now found this discussion. Kadilov (talk) 11:55, 3 June 2021 (UTC)
Policy blocks are fluid and contingent. For example, China blocks Germany over a dispute. Readers from China want URLs hosted in Germany to be archived to avoid the block. Later, China lifts the block and the status changes again, but only for Chinese readers. There is no way to say "url-status=georestricted" but only if you are located in China, and only for the duration of the block. This is a straightforward example, they get more complicated. Recommend a browser plugin that auto redirects to the Wayback version when there is a 404 (or similar). Avail at bottom of the page WP:LINKROT. -- GreenC 19:25, 2 June 2021 (UTC)
I don't see these examples as applying to enwiki. I perhaps wrongly, interpreted the OP as applying to georestrictions on enwiki users. I would make sure that bypassing such restrictions through the use of an archive is not a copyvio or other legal misstep before inserting an archive-url. 24.103.101.218 (talk) 22:51, 2 June 2021 (UTC)
I think we should not use correlations between language and a country of residence here. As for laws, I am not a lawyer but now I think of my proposal as something that arguably encourages breaking typical Terms of Service (provided by a website). Kadilov (talk) 11:55, 3 June 2021 (UTC)

Cite lecture?

Currently, {{cite speech}} includes the parenthetical "(Speech)" after the title of a speech. Is there a way to change this—in particular, to make it render as "(Lecture)"? --Usernameunique (talk) 13:51, 2 June 2021 (UTC)

No... actually. For some reason unknown. And it's using the TitleNote meta-parameter, instead of the one that might make sense which is |type= (which is how cite interview and I think cite report do it). Bizarre. Izno (talk) 15:49, 2 June 2021 (UTC)
Because {{cite speech}} uses |event= which renders to the left of |type=:
{{cite speech |title=Title |event=Event |type=Type}}
Title (Type). Event.
The event is not a speech.
At the time that {{cite speech}} migrated to Module:Citation/CS1 the mechanism that I adopted was a convenient solution (and there had been no call to override the default annotation). |type= (if present) should override the default annotation text (which is a candidate for i18n) in {{cite speech}} so I'll work on those things.
—Trappist the monk (talk) 16:48, 2 June 2021 (UTC)
But ... There are these and this one so while what I have hacked in the module works:
{{cite speech/new |title=Title |type=Lecture |event=Event}}
Title (Lecture). Event.
it doesn't work when |type= is being used to indicate the type or medium of the cited source.
—Trappist the monk (talk) 17:35, 2 June 2021 (UTC)
Thanks, Trappist the monk. Should I use {{cite speech/new}}, or are you still tinkering with it and {{cite speech}}? --Usernameunique (talk) 03:52, 4 June 2021 (UTC)
{{cite speech/new}} is a sandbox so should never be used in article space. As I noted above, there is the issue of |type=Video etc that still requires resolution. It may be that the very few {{cite speech}} templates that use |type= or |medium= are better served by {{cite AV media}}. For template-to-template consistency, it may be that {{cite speech}} should be like all other cs1|2 templates that have default annotation values so that |type=Lecture or |type=Video simply overrides the default annotation. These things have not been decided.
—Trappist the monk (talk) 13:17, 4 June 2021 (UTC)

Script-series

Requesting for script-series (and trans-series) parameter the way we have script-title and script-chapter in Template:Cite book. It is only logical since if a foreign book is a part of foreign series and has its title written in script-title, it has its own script-series parameter as well. Lulusword (talk) 07:08, 5 June 2021 (UTC)

Whitelist/Blacklist

Many organizations are moving away from usage of these terms. Google and Microsoft have had guidelines against it for over a decade, though not requirements. There are many alternatives, sometimes they can be even more clear. It doesn't mean our particular usage is racist, it almost never is, but it is systemic and potentially inflammatory. Some articles about it:

  • [1], "my colleague went on to impress upon me the discomfort he felt everyday living in a world where black was equated with bad [disallowed] and white with good [allowed]."
  • [2]

These terms are a reminder that culture considers white good/allowed and black bad/disallowed. As a large and globally inclusive organization we can do better with an easy change in wording. -- GreenC 19:57, 2 June 2021 (UTC)

Until whitelist and blacklist stop being the mainstream default terms for these things, we shouldn't do linguistic gymnastics to avoid them. No different than white hat and black hat hackers, or the myriad of other things. White and Black (the colors) being good/bad is enshrined in culture (or alternatively Dark/Light). You have to do a huge non-sequitur leap to go from villainous colour/light schemes meaning good/bad to mean that skin color is good/bad. Headbomb {t · c · p · b} 21:08, 2 June 2021 (UTC)
Because the rest of the core software is changing its terms as is a large set of other software? It's not exactly mental gymnastics to change "Whitelist" to "Validargs" or similar, which coincidentally describes the purpose of the module. Izno (talk) 21:57, 2 June 2021 (UTC)
I've got no objection to renaming the module/function name to ValidArgs/InvalidArgs or similar, if that's all that's proposed. Headbomb {t · c · p · b} 22:05, 2 June 2021 (UTC)
I'm pretty sure that's the only use of the terms in this module set. I'm sure someone could control F find more... Izno (talk) 22:21, 2 June 2021 (UTC)
We recently declined a similar re-naming at Wikipedia talk:Spam blacklist#Requested move 10 February 2021. – Finnusertop (talk ⋅ contribs) 22:24, 2 June 2021 (UTC)
Not only is this topic a can of worms, but it's part of a bigger can of worms. Should our sensitity to left handed people cause us to refrain from using such words as gauche and sinister? Should such issues be discussed in isolation, or should there be a broader discussion of terms that might be construed as pejorative towards one group or another?
With regards to the specific issue of blacklist versus blocklist, the anti-spam community debated it for decades and never came to a consensus; both terms are still in use. RFC 5782 uses both terms. Personally I favor blocklist, but if a DNSBL or organization has the other in its name, then changing it here would be WP:OR at best. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:47, 6 June 2021 (UTC)
The term Dark Ages has been disputed, and continues to be, for 100s of years. Historians say don't use it, but then continue to use it (occasionally - less so than before). More in popular culture than professionally. That is probably what blacklist/whitelist will be, a sort of indication of amateur or retrograde. We can't get rid of it socially (systemic), but it can be disputed by those who have examined the issue. It's a question of where you want your app or organization to be. Some of course will embrace it to be edgy or counter, but that has its own problems. The easiest solution IMO is just don't use it, avoid the issue, if you can. The neutral term is Early Middle Ages. -- GreenC 03:24, 6 June 2021 (UTC)

Examples for Template:Cite report

Hi! I've stumbled into Template:Cite report and I would find it really helpful if someone could give examples of how to use the template in the template description. I feel like I could use an example of a report being cited using the template, and some other users might also benefit as well. Best, Tyrone Madera (talk) 16:17, 5 June 2021 (UTC)

There is an example of such just above. Izno (talk) 17:46, 5 June 2021 (UTC)
Izno, Awesome. Should it be put in the template as an example? Tyrone Madera (talk) 17:55, 5 June 2021 (UTC)

Issue/number being ignored?

I have just updated some citation in the article Jerusalem District, and it looks like the issue / number fields are being ignored. This happens with both cite report and cite web. Am I using the citation wrong / is this a known issue, or does the template need to be fixed? Thanks. —Ynhockey (Talk) 10:21, 6 June 2021 (UTC)

|issue= and |number= are periodical parameters. {{cite web}} and {{cite report}} are not periodical templates. When I look at the two sources that use |number= at Jerusalem District, I don't see any indication of an issue or number 71.
See the table that shows which templates support |issue=.
—Trappist the monk (talk) 12:02, 6 June 2021 (UTC)

url in name parameters

We don't allow wikilink markup or urls in |<name>-linkn= parameters. We do allow wikilink markup in the name's |lastn= parameter but not in the name's |firstn= parameter. I just stumbled upon this {{cite web}} template that has a url in |author=. So I added a test to Module:Citation/CS1/sandbox to catch names that have urls:

Cite web comparison
Wikitext {{cite web|access-date=2014-03-01|author=Dr. [http://science.jpl.nasa.gov/people/Benner/ Lance A. M. Benner]|date=2013-11-18|publisher=NASA/JPL Asteroid Radar Research|title=Binary and Ternary near-Earth Asteroids detected by radar|url=http://echo.jpl.nasa.gov/~lance/binary.neas.html}}
Live Dr. Lance A. M. Benner (2013-11-18). "Binary and Ternary near-Earth Asteroids detected by radar". NASA/JPL Asteroid Radar Research. Retrieved 2014-03-01. {{cite web}}: External link in |author= (help)
Sandbox Dr. Lance A. M. Benner (2013-11-18). "Binary and Ternary near-Earth Asteroids detected by radar". NASA/JPL Asteroid Radar Research. Retrieved 2014-03-01. {{cite web}}: External link in |author= (help)

—Trappist the monk (talk) 15:58, 5 June 2021 (UTC)

Should probably do this with most of our parameters for anything that evaluates to having a full URL, that isn't meant for a URL parameter, TBH. Izno (talk) 17:45, 5 June 2021 (UTC)
Agreed, but shouldn't wikilinks be similarly rationalized. There are specific wikilink parameters in place and bifurcating the issue by allowing wikilinks in |last= for example, allows waste and confusion. Seem to remember prior discussion about this. 2603:7000:3842:C100:D26:7E6:7C2F:18B6 (talk) 22:47, 5 June 2021 (UTC)
Wikilinks are allowed in |lastn= because those parameters are aliases of |authorn=.
—Trappist the monk (talk) 23:22, 5 June 2021 (UTC)
Going in circles is great, but this wasn't the question. To rephrase: why are wikilinks allowed in parameter sets that have a corresponding |parameter-link= option? I mean, apart from general inertia. 64.18.9.198 (talk) 00:42, 6 June 2021 (UTC)
Inertia certainly, but why should we prohibit wikilink markup in |authorn=?
—Trappist the monk (talk) 11:48, 6 June 2021 (UTC)
I don't know, perhaps for the same reason as this section's heading? 50.75.222.254 (talk) 14:11, 6 June 2021 (UTC)
I see no reason to limit links whatsoever. Moreover, though you clearly don't mean to suggest the argument for it, we should remove X-link where X is not an authorship parameter. The module handles stripping of brackets today and wikitext links are more wikitext and tool-friendly. That would appear to be title-link, episode-link, and series-link. Izno (talk) 18:48, 6 June 2021 (UTC)
Ok. The sandbox now checks every parameter that isn't a url-holding parameter. url-holding parameters are the parameters associated with these url-holding metaparameters: ArchiveURL, ChapterURL, ConferenceURL, LayURL, MapURL, TranscriptURL, URL and these non-url-holding metaparameters that are allowed to hold urls: Page, Pages, At, QuotePage, QuotePages. Are there any others that should be included in these lists?
—Trappist the monk (talk) 16:28, 6 June 2021 (UTC)

Love the convoluted logic which is eventually applied as unnecessarily complicated code and inscrutable documentation. There are 3 simple, workable options:

  • All parameters allow links away from the citation
  • No parameter allows links away from the citation
  • Designated, function-indicative parameters (such as |something-link|url=) that are link-specific allow links away from the citation

Anything else requires explanation. But, go ahead, do your thing. 24.103.101.218 (talk) 00:20, 7 June 2021 (UTC)

Yes, anything else does require explanation.
We have a good reason to accept links in |last= and analogous authorship parameters: duplicating the text of one parameter into another parameter simply to add a link is simply asinine, which is what we would need to do to accept links for organizations. We also have a good reason to accept |author-link=: we want to provide links for parameters that have been split into |first= and |last=, as we would like to see for all authorship related parameters.
Those design considerations do not extend to any of our other parameters.
The reason linking is (or perhaps, should be) allowed for internal links is that we prefer users to link to internal links if they are going to link to anything. We explicitly want to avoid the actual spam (and/or sea of blue effects) associated with external links in the other parameters (or confusion by users, which is already warned about as "URL in website", regarding the use of |website=).
There is not, and never has been, a requirement for all parameters to do all things, or one thing only, or have any consistency at all. You have pointed out an inconsistency, that's great, but whether we take that to extend to all parameters or to limit it to no parameters is a choice we get to make between those options as well as any others we deign to consider. That is actual design. Presenting false trichotomies does not actually help your case in this regard.
For a particular prior case, we have previously had the explicit discussion to limit |volume= and |issue= to some templates. Not all templates have access to those parameters. I do not see how that was ever the wrong choice, for the templates that do not have access to one or the other of those parameters do not fundamentally need them. Just because we do not treat these templates consistently does that mean we got the choice wrong.
Thank you for indeed helping to identify 3 parameters that do not need a link parameter any more. :^) Izno (talk) 01:11, 7 June 2021 (UTC)
One thing that I have seen is that many editors use {{cite web}} when a different template is appropriate. Are there any cases where an editor actually needs an unsupported parameter for {{cite web}} as opposed to being able to use a more appropriate template? I would rather have other templates enhanced than have enhancements to {{cite web}} that are done solely to support inappropriate use. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:05, 7 June 2021 (UTC)
Well I know why the module is becoming more inefficient with every update, no need to lay it out.
It is not just the inconsistency of "something-link" being asinine while "something-url" isn't. It is not just the fact that the wikilink may have different format or text than the name(s) inserted in the author parameters which would necessitate further editing of the author fields by the user. Neither is the fact that good software design does not allow the same parameter to be populated with different data types ("text" or "link"). Or the fact that parameters that are classified by data type are more understandable and better utilized by editors. Also it is not because the so-called "internal" links are technically any different (they are all URLs parsable by mediawiki) or conceptually different (they can also be spam, irrelevant, or unverified nonsense just like external links).
Nah... the reason imo for the module's increasing inefficiency is that these things have to be explained. Continuously :-) 68.173.79.202 (talk) 13:23, 7 June 2021 (UTC)

extra text that is not detected in |page(s)=

The template {{p.}} and it's redirect {{pp.}} when used in |page(s)= create extra text conditions that are not detected by the module. I have added pattern to Module:Citation/CS1/Configuration that fixes that:

Title. p. p. 123. {{cite book}}: |page= has extra text (help) ← {{cite book |title=Title |page={{p.|123}}}}
Title. p. p. 123. {{cite book}}: |page= has extra text (help) ← {{cite book/new |title=Title |page={{p.|123}}}}

—Trappist the monk (talk) 13:55, 10 June 2021 (UTC)

Walls-of-text when editing

Quite recently I've started seeing lots of citations with all the spaces around the pipes removed, for example: {{cite web|author=Center for Whale Research|date=June 17, 2018|title=Southern Resident Orca Community Demographics, Composition of Pods, Births and Deaths since 1998|url=https://www.orcanetwork.org/Main/index.php?categories_file=Births%20and%20Deaths|publisher=Orca Network|accessdate=July 31, 2018}} ... This makes it hard to read (and edit) as a wall of text and also causes text wrapping problems. I haven't seen any change promulgated in the guidelines that says to remove the spaces. Could it be a bot doing it? In any case, could we re-emphasize the standard of a space before each pipe and figure out what's driving this change? Abductive (reasoning) 20:46, 9 June 2021 (UTC)

There are scripts that convert to {{A|B=C}}, scripts that convert to {{ A | B = C }}, and everything in between (I have a personal preferred style, but that's not this discussion), and no-one's been willing to have a discussion about standardizing on the point (at least for citations). So I'm not really surprised if you're noticing a trend, but I doubt the trend is anything more than confirmation bias on the point. Izno (talk) 20:50, 9 June 2021 (UTC)
The examples on the Help page that this is the talk page of all show a consistent bias towards a space before each pipe. Could the guilty parties just come clean? Abductive (reasoning) 20:54, 9 June 2021 (UTC)
I think the best way is to have a space before each pipe, no-spaces makes it harder to read, while spaces both before and after pipes and before and after equal (=) signs seems excessive and unnecessary. However, I don't know if this is worth having a potentially massive RfC where it's likely consensus won't be reached. Many will probably also cite WP:CREEP against the very idea of setting a standard. —El Millo (talk) 21:15, 9 June 2021 (UTC)
It doesn't seem like there is a cadre of entrenched users ignoring the longstanding consensus and demanding the wall of text, I think it is a bot or bots doing it. Abductive (reasoning) 21:25, 9 June 2021 (UTC)
(ec) I've found that a space around pipes and after = makes it easier to edit, because then I can double-click the text to change it; without a space, the double-click selects the pipe or = as well. But I don't edit articles just to do that (and sometimes I forget to do it in my own edits). Just pointing out that the space can be useful. Schazjmd (talk) 21:26, 9 June 2021 (UTC)
Are you sure, Schazjmd? Whenever I double-click text next to an equal sign, it only selects the text. —El Millo (talk) 21:34, 9 June 2021 (UTC)
Oh, it's just my setup? I figured it worked that way for everyone. (Now I have to try to figure out what I might have done on my computer to make it behave that way...) Thanks, Facu-el Millo! Schazjmd (talk) 21:38, 9 June 2021 (UTC)
Different browsers on different operating systems differ in how they deal with double click. It also matters whether the text area is plain old HTML or if it is spiced up with Javascript (and the latter can cause variance itself). There may be nothing you can do about it beside try a different browser than your normal one. Izno (talk) 21:43, 9 June 2021 (UTC)
When I'm typing citations by hand, I tend to omit the spaces because that's less typing. When I'm converting from one-parameter-per-line to all-on-one style citations, if I space the pipes and equal signs, the regular expression substitutions I use for this tend to also mess up long parameterized urls (like the ones for Google Books) so the unspaced style is safer. Anyway, for avoiding wall-of-text issues, my feeling is that moving the references to the end of the article by giving them names and using the |refs= parameter of {{reflist}} is much more effective than any variation in how you space the parameters of the reference. —David Eppstein (talk) 21:42, 9 June 2021 (UTC)
Agreed, WP:LDR or WP:SFN does more to deal with walls of citations. Izno (talk) 21:45, 9 June 2021 (UTC)
IMHO, bots that make mass changes to style, absent a strong consensus, are disruptive. This is especially true when somebody takes the time to make his markup easy to edit and a script wipes out his work. I could make a case for automatic prettyprinting, but even that is laden with pitfalls. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:49, 9 June 2021 (UTC)
Abductive and others, if you think a bot is applying this style, find an article with citations like this, and go back through its history to find when and how the citation was inserted. Histories are (almost all) publicly visible; there is no reason to speculate. If you find that a bot or script is changing the citation style, address that CITEVAR issue with the bot or script operator. – Jonesey95 (talk) 23:29, 9 June 2021 (UTC)
I will fully admit: I prefer things unspaced because in many cases, it creates smaller wikitext that can fit on one line. Whether I convert anything depends on what the article is already using (I try to keep styles consistent if possible). Sometimes, though, it is a hassle. Long lists of author names split into first and last names can be really awkward, as can particularly long URLs. The worst instance is probably |archive-url=, which at least 90%, I feel, of the time contains the same value as |url= but with stuff added to the beginning. Shortened footnotes and list-defined references are definitely better for cleaning up clutter than spacing things out. (Full disclosure: I use the 2017 wikitext editor on desktop computers, which allows line breaks on hyphens, spaces, and question marks, and probably some other characters. The mobile version, however, seems line break with pipes, too, last I checked. Could implementing this on desktops solve our problems?) -BRAINULATOR9 (TALK) 13:30, 10 June 2021 (UTC)
Perhaps I'm misunderstanding what you're saying, but it doesn't seem like you understand the purpose of |archive-url=. The parameter is used to contain an archived version of the link, so that the content is still accessible if the link is ever broken or the info is ever removed. Wayback Machine, the most commonly used archive, just makes the links so that they contain the full url of the page being archived (https://web.archive.org/web/[archive number]/[original's url]). It's not like it's useless repeated info, and it's not like there's anything we can do about it. —El Millo (talk) 17:30, 10 June 2021 (UTC)
I understand what |archive-url= does and that it's not restricted to the Wayback Machine. I'm just saying it's the most prevalent instance of unfixable line break mishaps. -BRAINULATOR9 (TALK) 19:04, 10 June 2021 (UTC)

Chapter woes

What am I doing wrong here? I thought as long as work was omitted the chapter should work correctly.

Markup Renders as 
{{Cite web |chapter-url=http://www.airvectors.net/avf4u_1.html#m3 |chapter=Corsair in the Pacific War |url=http://www.airvectors.net/avf4u.html |title=Vought F4U Corsair |last=Gobel |first=Greg |date=1 May 2015 |publisher=AirVectors}}

Gobel, Greg (2015-05-01). "Vought F4U Corsair". AirVectors. {{cite web}}: |chapter= ignored (help)

Also when I change chapter to at it tells me chapter-url is ignored, which is not explicitly covered in the error guide. Ibadibam (talk) 16:30, 10 June 2021 (UTC)

Webpages do not have chapters. Use cite book. AManWithNoPlan (talk) 16:48, 10 June 2021 (UTC)
Or, use title= and url= for the individual piece you are citing and work= for the larger collection of web pages it comes from. —David Eppstein (talk) 17:09, 10 June 2021 (UTC)

I think I would much prefer this, as I do not really see this as a book citation (for which 'chapter' might apply); I believe this is also what David is suggesting:

Markup Renders as 
{{Cite web |last=Gobel |first=Greg |date=1 May 2015 |url=http://www.airvectors.net/avf4u_1.html#m3 |title=Corsair In World War II |website=AirVectors |at=Corsair in the Pacific War}}

Gobel, Greg (2015-05-01). "Corsair In World War II". AirVectors. Corsair in the Pacific War.

I have added the specific section callout. This seems like a sufficient citation to me. You do not need to identify all layers between the specific web page and any higher level works. --Izno (talk) 18:49, 10 June 2021 (UTC)

Bad value in website= field

I've noticed a value entered to some cite web uses "TREKNEWS.NET | Your daily dose of Star Trek news and opinion" in an example like: {{Cite web|last=Staff|first=TrekNews net|date=2017-02-10|title=[REVIEW] Deep Space Nine Complete Series DVD Box Set|url=https://treknews.net/2017/02/10/review-star-trek-ds9-complete-series-dvd-box-set/|access-date=2021-02-19|website=TREKNEWS.NET {{!}} Your daily dose of Star Trek news and opinion|language=en-US}}. Should this be flagging any tracking category perhaps? Gonnym (talk) 11:36, 11 June 2021 (UTC)

Which flag that would be? The website field is badly formatted, the only thing there should be www.treknews.net. There could be some error checking to catch extraneous characters before the prefix and after the suffix I suppose. Tracking category submissions must go through an RfC process now as I understand it. 24.103.251.114 (talk) 12:20, 11 June 2021 (UTC)
Websites may be in either their "URL" form (as in 24's comment) or a caps URL form ("TrekNews.net") or their word form ("Trek News"), so looking for spaces would not help. The latter half of the title is a bit spammy but is a valid part of the name, and isn't obviously unuseful in the sense that "Bloomberg, are you a robot" is. This case seems fine. I do recommend doing an insource search and removing the offending half of the name. Izno (talk) 12:26, 11 June 2021 (UTC)
The guidance (and code) may need to be finetuned. In good practice, websites are directory entries distinguishable by the prefix "www". Good practice not being universal practice. Although there is nothing wrong with subtitles (even when these are in effect, marketing messages), the template does not have to accept them. If it makes the code tighter and more efficient, in the sense of allowing for expanded error checking, why not? Subtitles would only be pertinent if index pages needed disambiguation, and that is not a case. 24.103.251.114 (talk) 13:05, 11 June 2021 (UTC)
How do you distinguish a 'subtitle' for a website? Izno (talk) 13:49, 11 June 2021 (UTC)
Anything after the suffix? That is why it was suggested that the work be expected in DNS format exclusively. A conditional formatting parameter could switch the display to hide the DNS artifacts per editor preference. I understand that this involves a lot of work for a module that is constantly scrutinized by snowflakes, so these suggestions are very tentative. 65.88.88.69 (talk) 14:56, 11 June 2021 (UTC)
Right, but 'DNS' format is not required and I do not think it should be required for the field. Izno (talk) 15:35, 11 June 2021 (UTC)

Protected edit request on 11 June 2021

An acknowledgement and inclusion of the TemplateData newly created for Cite Map in its documentation in the same style as Cite Book BMACS1002 (talk) 23:57, 11 June 2021 (UTC)

Template:Cite map/doc is not protected. There is nothing preventing you from adding TemplateData.
—Trappist the monk (talk) 00:21, 12 June 2021 (UTC)

cite document

There is a template {{cite document}} which seems to have always redirected to {{cite journal}}. It's got 7968 transclusion and most of these are coming up with red cs1 errors as the required parameter |journal= makes little sense for documents.

For the page I saw this on A30 road the references ref to off line sources held by the UK national archive, and one user has commented on Template talk:Cite document that it's used for a commencement speech. While changing thee links to {{cite web}} would cure the cs1 warning, this does not seem to be semantically correct, but there no obvious candidate in the cite family. --Salix alba (talk): 03:02, 12 June 2021 (UTC)

There have been previous inquiries and discussions about this. The main issue here is the fact that few documents are published as stand-alone items, and only published sources can be cited. Long documents may be published as reports; there are a couple of templates available. Other published documents may use {{cite book}}, or {{cite web}}. In the particular case, the document can be sourced as a location in an online publication (the website for the UK National Archives). Use {{cite web}}. If a hard copy of the pertinent Archives volume was consulted use {{cite book}}. 64.18.9.201 (talk) 13:11, 12 June 2021 (UTC)

Autolinking

Please autolink the title when |hdl= and |hdl-access= are provided similar to how it works with a supplied |doi=. Please add hdl as an option for |title-link= with |hdl= for cite journal. It would be useful if the combination of |hdl=, |hdl-access=, and |title-link= worked for cite report, techreport, or web too. Thank you. --Whywhenwhohow (talk) 04:30, 8 March 2021 (UTC)

The PMC content is sometimes stale when compared with the journal article and should not be the default when a free doi or free hdl is present. The existence of the paramaters |doi-free= or |hdl-free= should cause the doi or hdl to have priority and be used instead of the pmc for the title link. --Whywhenwhohow (talk) 23:59, 8 March 2021 (UTC)
What is the process to implement these recommendations? --Whywhenwhohow (talk) 05:27, 26 March 2021 (UTC)
For the articles you edit? Add the url you want to link as the |url= parameter. That way the logic for which thing somehow overrides which other thing can be as convoluted as you like and the rest of us don't have to try to understand or remember it. —David Eppstein (talk) 06:14, 26 March 2021 (UTC)
Yes, this would be appropriate. Institutional repositories hosted by academic institutions are by far the most stable and reliable link targets we have in our citations.
On the other hand it's not appropriate to give priority to the DOI over the PMC ID, because PubMed Central is more likely to present relevant updates, such as retraction notices of medical articles, which often go missing on the publishers' websites. Legacy publishers generally lag several years behind PubMed, see for instance Elsevier. Nemo 18:38, 25 April 2021 (UTC)
Dearchived due to ongoing discussion. Nemo 18:54, 27 May 2021 (UTC)
"Ongoing discussion" meaning the topic wasn't edited for a month? That's a curious definition. Izno (talk) 19:20, 27 May 2021 (UTC)
The topic was mentioned here, though I was unaware of this discussion at the time. Certes (talk) 16:51, 28 May 2021 (UTC)
Right now |pmc= overrides |doi-access= free link. Has any thought been put into this order? AManWithNoPlan (talk) 22:13, 24 June 2021 (UTC)
{{cite journal |title=Title |journal=Journal |pmc=12345 |doi=10.1415/sommat |doi-access=free |title-link=doi}}
"Title". Journal. doi:10.1415/sommat. PMC 12345.
—Trappist the monk (talk) 22:33, 24 June 2021 (UTC)

Thesis in italics

The guideline MOS:MINORWORKS recommends quotation marks, not italics, for titles of theses. This contrasts with the behaviour of {{Cite thesis}} wher |title= is italicised. Which is correct?

As for the merits of the distinction major/minor works in this regard: Most PhD dissertations are quite substantial, and often they are later published as books, so italics makes sense. My impression of masters theses is that they are more like extended essays, so it's not clear to me whether they are minor or major. Anyway, there's a conflict between the MOS and the tamplate's behaviour.

I raised the same question at Wikipedia talk:Manual of Style/Titles#Thesis in italics. -- Michael Bednarek (talk) 01:44, 18 June 2021 (UTC)

Generally, works published as stand-alone items are in italics, and items that are parts of published works are quoted. Since the CS1 citation templates are named per (stand-alone) source, this template would only be suitable for theses published as stand-alone items. I would imagine this to be a fairly small number? 74.64.150.19 (talk) 11:56, 18 June 2021 (UTC)
History: From its creation in 2009 until this edit in 2011, |title= rendered upright without quotation marks. After that edit, |title= renders in italic.
—Trappist the monk (talk) 12:45, 18 June 2021 (UTC)
I don't understand 74.64.150.19's response. Every thesis is a stand-alone work, isn't it? // Regarding history: maybe User:Headbomb can provide guidance whether the advice in MOS:MINORWORKS should be removed. -- Michael Bednarek (talk) 13:05, 18 June 2021 (UTC)
I'm not sure why I'm pinged here, or what the question is, but thesis are major works, and their titles should be italicized. I believe this is the current behaviour of the templates. Headbomb {t · c · p · b} 13:31, 18 June 2021 (UTC)
Michael Bednarek, thanks for posting this. I have responded over at the MOS page with some detective work. In short, I believe that the guidance was added to the "minor works" list in error and without discussion in 2019, and that it contradicts both our long-standing practice and some style guides. MOS should be modified, not {{cite thesis}}. – Jonesey95 (talk) 16:04, 18 June 2021 (UTC)
@Michael Bednarek: for the purposes of citations, "stand-alone" would mean works published as themselves, and not as part of a larger work, or of a collection. An article/essay published as a pamphlet is a stand-alone work, indexed as such, and found as a discrete item. Its title should be italicised. The same piece published in a magazine or journal is a location in a stand-alone work, and its title should be in quotation marks, as it is in fact text quoted from the source. 65.88.88.69 (talk) 19:42, 18 June 2021 (UTC)
I've now adjusted MOS:TITLE. -- Michael Bednarek (talk) 01:29, 19 June 2021 (UTC)

Journal volume in Bold

The volume parameter is showing up in bold in the journal citation. It is quite jarring as it stands out among all the other parameters, and I thought it's a bug. The documentation said it can be in bold, but did not say why the bold is required. On going through the archives I found similar concerns (1, 2, 3), and on how to workaround the bold, and requests and proposals to handle or eliminate the bold completely. I accordingly modified Iridium Communications so the bold is avoided.

In Template:Citation Style documentation/volume I added a mention of why the bold is done, from one of the conversations. From the proposals in /Archive 62#Bolding of the volume number, I vote for: 

Proposal 2 	vol. 3, pp. 12–56.

so the reader understands what the 3 stands for, plus it is not in bold. - Jay (Talk) 13:40, 20 June 2021 (UTC)

I'm inclined to revert your change to Iridium Communications because that change causes Module:Citation/CS1 to emit a |volume= has extra text error message (which see). I am also inclined to revert your changes to Template:Citation Style documentation/volume unless you can name the international standard that lays out the expected styling for journals. What is the name of this international standard?
—Trappist the monk (talk) 14:02, 20 June 2021 (UTC)
Citation bot already reverted my workaround, and I can take that up at the bot's page. On the international standard, I got that from /Archive 4#Bold/non-bold volume parameter doc issue, or bug, where user Gadget850 said: "Volume values that are wholly digits, wholly uppercase Roman numerals, or less than five characters will appear in bold, as per the international standard that lays out the expected styling for journals. Any non-numeric value of five or more characters will be presumed to follow some other convention and will not appear in bold." - Jay (Talk) 06:35, 21 June 2021 (UTC)
An editor saying something in a general comment on a talk page doesn't necessarily make it true. This obviously isn't article space so not quite WP:V level, but I would agree with Trappist that we shouldn't call something an "international standard" in the documentation unless we can justify that with some reliable source saying so.
On the original question, I've grown quite used to the bold volume numbers, I don't find them particularly jarring, but I do think it's important to justify why we're doing it that way, and to be confident that readers will be able to interpret that layout without hitting the edit button and looking at the template parameters.  — Amakuru (talk) 07:16, 21 June 2021 (UTC)
I'm used to the bold volume numbers as that is common in the scientific literature (e.g. Nature and Science both use bold volume numbers). But while I'd expect the bolding for scientific journals, I find the bolding jarring with books, where I'd expect "Volume 2" rather than "2" for books. I think it would be better if {{cite journal}} and {{cite book}} handled volumes differently. There is the option of using |Volume=((Volume 2)) to suppress the hidden error message but this seems an unnecessary extra step. —  Jts1882 | talk  08:31, 21 June 2021 (UTC)
For Nature and Science that use bold volumes, "there are also plenty that don't any more / never have (e.g. BMJ, Cell, PLOS, BMC)." (by User:Evolution and evolvability). What looks normal on printed pages, may not look so on web pages. Especially on a wikipedia page where nothing but the first mention of the subject is allowed to be in bold. - Jay (Talk) 15:07, 21 June 2021 (UTC)
I just said I was used to seeing the bolding in the scientific literature. I gave Nature and Science as examples as they are well-known and more geared to a general audience. My unscientific survey of journals I read and publish in suggests a majority use bold (e.g. PNAS, J. Physiol, J. Biol. Chem). Cell and Neuron (Cell Press) don't use bold but use italics to provide emphasis to the journal number. The BMC journals were on my bold list, but it looks like they now don't bold the number now, which may or may not be an indication of the modern trend. For journals that show issue numbers in parenthesis, none that I looked at used bold, although Cell Press used them in normal text following an italicised journal number. I don't feel too strongly about bolding the journal number, as many journals don't, but find the emphasis useful. What I don't think is correct is the bolding of book volume numbers or flagging the text "volume" as an error (which result in people deleting volume titles and just leaving the number). In my brief survey, the journals that bold the journal number don't bold the book volume number and use Volume 2 or Vol. 1, although finding examples for this is difficult. —  Jts1882 | talk  16:15, 21 June 2021 (UTC)
I agree it doesn't make it true. I cited the user and his quote to provide context, the best I could get, because in the discussions I'm seeing in the archives, the typical explanation for something being a particular way is "because this was discussed and agreed by the editors on Wikipedia years ago", with no other context. What I gave is a lead, so someone who was part of the discussions can pitch in with the unnamed standard, since the quoted user is now inactive.
A quote from another archive /Archive_8#Add a 'volume-b=' parameter that skips the four-chr test for bolding?, where user J. Johnson (another inactive user) says: "Volume numbers, which are especially significant for serials and journals, are often overlooked on account of being so short, wherefore they are commonly bolded so they are more readily seen in long citations." Now this is a usability explanation that can be given in the doc, and this would suffice for the time-being. It answers the question, why are volumes bolded, but not, Is it the right thing to do? - Jay (Talk) 14:31, 21 June 2021 (UTC)
It is not a good idea to make assumptions based on what one is used to, or by looking at other citation systems. This is a general-purpose encyclopedia geared towards non-experts. There are no prior examples of citation systems addressing such an audience. All existing citation systems are geared to experts, sometimes in very narrow fields. Very rough guidelines is the most such systems can provide. The present citation system must be more than anything, simple, understandable, and consistent. And also coherent, given the expected level of reader expertise (zero). The volume parameter is one of the places where the system fails, but not for the reasoning you outlined, imo. It is inconsistently presented (sometimes bold, sometimes not) and arbitrarily so (why bold if less than X rather than Y characters?)
It would make sense to emphasize the parameter by using bold weight: in cases of multi-part sources the parameter is instrumental in locating the verifying info, and its presentation should attract the reader's attention. But this may be secondary to consistency. Whatever is decided should apply uniformly, wherever this parameter is used in-system. This is easier for both non-expert readers and non-expert editors. Certainly easier than following arcane trade practices per citation template or following whatever foreign citation system suits one's particular preferences.
If memory serves, I believe I first made a similar comment in some Wikipedia page almost 20 years ago :-) Likely I will be repeating this 20 years from now, if I'm still around. Something to do, I guess. 66.65.114.61 (talk) 14:37, 21 June 2021 (UTC)
The most recent discussion on this topic is at Help_talk:Citation_Style_1/Archive_75#Obtuse_template_style; you'll see I started a draft RFC and posted for some feedback there which I took somewhat, but no-one followed up after my last comment there. Happy to hear more, just not sure I'll take more... :^)
As for comments above about standard/not standard, the couple of ISO standards out there seem to favor the written out "vol." without bolding, but I could swear that I had seen at least one ISO citation with bolding/parens along the lines of the couple major journals already mentioned. Izno (talk) 20:26, 22 June 2021 (UTC)

|script-chapter= (and aliases) without |chapter= (or aliases) not recognized in cite encyclopedia

Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|script-entry=zh:Entry}}
Live Entry. Encyclopedia.
Sandbox Entry. Encyclopedia.

fixed.

—Trappist the monk (talk) 11:39, 26 June 2021 (UTC)

Old parameter coauthors

The citation templates supported the coauthors parameter before lua modules were introduced. Does anybody here remember how the references with that parameter were treated when en.wiki switched to lua modules? Were they removed from template calls in the articles? (there are very few remaining, see insource:/coauthors=/). I need this for another wiki. Many thanks! Ponor (talk) 01:14, 30 June 2021 (UTC)

They were supported by the Lua modules for a while, and then we deprecated |coauthors= and converted them all to |author1= etc. or |last=/|first= pairs. – Jonesey95 (talk) 03:04, 30 June 2021 (UTC)

DOI and/or URL for cite SSRN to support PlumX/Altmetric?

Anyone here familiar with PlumX/Altmetric and how they pull data from Wikipedia references? Should we add the ability to specify a DOI and/or a URL for {{cite ssrn}}? Wikiscienceguru wrote on my talk page about a change they made using {{cite journal}} with a DOI and a URL instead of using {{cite ssrn}} for a paper from SSRN:

So the important change I made is to include the DOI. If this is not done, metrics tools like PlumX and Altmetric do not find the reference in Wikipedia which prevents people from finding wikipedia articles that reference a given article. While SSRN is technically not a journal, it does have what it calls "eJournals" which include content based on editorial staff selection criteria. The referenced article is in an eJournal. But again, most importantly, the DOI must appear in the reference (not as a link) to be captured by PlumX and Altmetric. References by PlumX and Altmetric steer traffic to wikipedia via those references. SSRN functions as a Journal so perhaps it's best to use that citation style. Somehow, the DOI must appear in the reference as directly visible text, not hidden within a link.

--Whywhenwhohow (talk) 03:46, 7 July 2021 (UTC)

That's nice, but that has 0 bearing on how we make citations. Wikiscienceguru, those platforms should fix their software. We should not use a specific template to make them happy. Izno (talk) 04:12, 7 July 2021 (UTC)
{{cite ssrn}} is kind of a special purpose template. If the issue is that it does not support |doi=, you could use e.g. {{cite web}}, which does support |doi= and |ssrn=. However, according to [3] at least Altmetric also retrieves SSRNs from citations, so adding DOIs should not be necessary in the first place. In general, if their harvesters don't recognize some identifiers in the visible text of a citation, they should be improved to also read the invisible COinS metadata as it is provided by all CS1/CS2 citation templates in Wikipedia (and various other places). Thereby they could reliably retrieve SSRNs, DOIs and many other identifiers via the rft_id key (see also: Module_talk:Citation/CS1/COinS).
--Matthiaspaul (talk) 14:34, 7 July 2021 (UTC)

access-date query

Hi all

If I have a citation with a dead URL, for which an archived version has been added, e.g. through an archive.org link, should the access-date parameter represent the date on which the actual original URL was last verified to be online and accurate, or should it be the date on which the archived version was last retrieved? Cheers  — Amakuru (talk) 08:44, 5 July 2021 (UTC)

In this case I would not use the |access-date= parameter at all, but if you prefer it should be set to the date the archived snapshot was created. --Matthiaspaul (talk) 10:40, 5 July 2021 (UTC)
Well, we already have |archive-date= to cover that, so I'm not sure it would be particularly helpful to use that date. I guess the question is whether the archiving site will ever go down or somehow change the way the source looks... If not, then as you say perhaps omitting it altogether similar to a GBooks link would be best. Personally I've always just used the date I looked at the archive site myself, but I just wondered this mornign if that was really correct.  — Amakuru (talk) 10:45, 5 July 2021 (UTC)
Just for clarification: My above comment addresses the scenario of adding |access-date= at a time when the original site is already dead, and where an |access-date= newer than the |archive-date= implies that the archived contents was still live at that date - something that does not necessarily hold true and that, except for in very rare cases, cannot be determined retroactively any more.
Like Trappist below I do not suggest to remove an already existing |access-date= parameter, because when that parameter was applied at a time when the original site was still alive the date provides valuable information for verification purposes and to possibly find the most suitable replacement link.
--Matthiaspaul (talk) 15:54, 5 July 2021 (UTC)
|access-date= applies to |url=. When |url= has died, do not delete or modify |access-date= unless you replace |url= with a url that links to the same source (because that source revised how they structure their online presence). We hope that the date in |access-date= reflects the date that a human editor confirmed that the source addressed by |url= supported our article (alas, there are tools out there that automatically add today's date to |access-date= when they cleanup bare url references today). We need to know the correct |access-date= so that when |url= goes 404, we can find an archived snapshot from on or near that date.
—Trappist the monk (talk) 11:09, 5 July 2021 (UTC)
First, if I may suggest, don't think as an editor, and think as the consumer (the reader). What serves the reader is a live url and an indication of the date that url was accessed. When a previously live link has died for whatever reason, and there is an archive, the live url that verifies the source is the archived one. If you can access that, you should say it, with the date you did so. The |url-status= will auto-format the current live link, but the editor must update the parameter |access-date= by hand. The parameter that indicates the snapshot date is a different parameter |archive-date= and has a different purpose. 64.18.9.201 (talk) 12:17, 5 July 2021 (UTC)
Yes, I think this matches what I would expect as a reader too. Note the way such a citation renders:
As a reader, I would expect that "Retrieved 5 July 2021" to refer to the actual link of the source as I'm verifying it, which in this case is the archived copy. Saying the "access-date" refers to the "url" may make sense from the point of view of this template, but IMHO what's important is the rendered text and what it implies. Cheers  — Amakuru (talk) 12:37, 5 July 2021 (UTC)
Hm, I don't think it is a good idea to retroactively add an |access-date= to specify the date an archived snapshot was accessed once the actual |url= has died. The |archive-date= already implies that the original site was accessed (by the archiver) on that date. At most, |access-date= could be set to the same date as |archive-date=.
An |access-date= newer than an |archive-date= implies that the actual site was still alive at the given moment in time and its contents still supported the statement. Except for in very rare cases, we do not know if this holds true or not, therefore we should not make such statements. It would be possible that the contents of the site changed in unsuitable ways no longer supporting the statement prior to going dead. If, in this case, |access-date= would be given as the date when the (older) archive was accessed, it would lead to the assumption that the original site supported the statement up until it died and not only up until the archived snapshot was taken. To distinguish between these cases we would need to known when a site went dead and see if the |access-date= is older or newer than this date, but we do not normally have this information. --Matthiaspaul (talk) 15:54, 5 July 2021 (UTC)
No. Nobody is adding an access date retroactively. The opposite is happening: the date the source is accessed is added concurrently. It does not matter at all to the reader if that source was an original or an archive, although it is good practice to indicate so, as is currently happening. It is wrong to leave a stale date as access date. It is a false statement because the pertinent new live link is not accessed on that date. The archive date is indicating the snapshot, and is important when the original changes, since it is part of a revision history. By definition, the snapshot used verifies the wikitext exactly like the contemporary original. So if the archive is going to be used instead, the date it is accessed should be indicated. 68.173.76.118 (talk) 20:15, 5 July 2021 (UTC)
My preference is to remove the access-date when I discover a url to be dead and replace it with an archived url, because the version of the source at the old access-date is no longer verifiable and we need to go by the archived version instead. There is no point in also adding an access-date because archived versions do not change, so the date that I found it in the archive is not useful information to readers. Adding an archive to a still-live url is not something I usually do, but if you are doing that, then the access-date can remain as a record of when the content at the live url was verified. —David Eppstein (talk) 20:34, 5 July 2021 (UTC)
Not all archives are stable. Services such as WebCite may remove archived material especially if there are multiple archives of the same source. I have experience of Wayback Machine archive URLs that have changed, affecting the entire snapshot chain. I agree that known stable/well-managed archives that become the live URL would not need an access date, and therefore the parameter could be removed in such cases. In the other cases, the live URL (whether original or archive) should have a corresponding contemporaneous access-date. 68.173.76.118 (talk) 21:15, 5 July 2021 (UTC)
The point is that if you link to a version with an archive-date, the date of that version will never change. It is stable in the sense of being a fixed snapshot, regardless of whether it might someday become a deadlink. So having an access-date to tell you which version of a changing web page was used is pointless for an archived page. —David Eppstein (talk) 21:35, 5 July 2021 (UTC)
There's a misunderstanding, I believe. The archive-date identifies the snapshot, as you state. The access-date identifies the date that snapshot was accessed as the then-live URL. In the case of non-stable archives, I think that link info is as pertinent as any other link info. Some time ago I inserted a citation whose source (the live URL) was a newspaper archive, curated by the newspaper itself. So this is an authoritative archive. Recently, following a change in publishers, the entire archive was repositioned as a subdomain of the publisher's subscription services. I became aware of the change months later, and edited the citation. I believe that in the meantime the info regarding the link's known accessible date added value for readers wishing to find the source. It could be a starting point to discover where the source went. With rapid developments in the publishing industry, this may not be an unusual incident. 74.85.112.198 (talk) 23:47, 5 July 2021 (UTC)
I do not see the relevance of telling readers "the date that snapshot was accessed", as you put it. It provides no useful information to readers. —David Eppstein (talk) 01:10, 6 July 2021 (UTC)
|access-date= is for |url=, not for |archive-url=. Period. Izno (talk) 01:27, 6 July 2021 (UTC)
You are only partially correct. The access date refers to the live URL, neither the "original" nor the "archived" one. Any URL may need an access date if there is a good possibility it will not be stable, regardless of provenance. If the documentation says otherwise, it should be fixed to line up with common sense, so that editors don't come here with such questions (not the editor's fault). And verifying readers won't have to be entangled with yet another wrong/false date statement. 65.88.88.200 (talk) 20:31, 7 July 2021 (UTC)
No, it is specifically for |url=. Your opinion is simply wrong. Izno (talk) 00:55, 8 July 2021 (UTC)
"Simply wrong" according to whom? These templates exist first and foremost to make it easy for editors to produce reader-friendly citations in a standard format. And as such, as I said above, the crucial point is that what the |access-date= parameter produces is a snippet of text saying "Retrieved 8 July 2021". The question we need to ask ourselves is therefore not "does that date refer to the URL parameter", but rather "what will the reader interpret that date to mean"? In that regard I think the IP is right, the reader will logically assume that it refers to the primary URL associated with the citation, which in the Case of a dead-link is the archived version. If I'm wrong about that interpretation then say, but please don't argue it on the basis of what the parameter was "intended to mean", because that is (a) not what matters to our readers, and (b) not documented in any case so still subject to opinions. It may or may not be best to remove the date altogether at the time of switching to an archived version, but I don't think we should pretend it still refers to when the original URL was accessed.  — Amakuru (talk) 14:00, 8 July 2021 (UTC)

As stated, Izno is partially correct, in a very narrow technical sense regarding module argument dependencies. That is not relevant to editors or readers. I suspect what they want to see is rational real-world equivalents without the low-level mumbo-jumbo.

Technical-mumbo-jumbo example 1 (|url-status=live)
{{cite web|title=Title|website=Website|url=http://original_url.com|archive-url=http://archive_url.com|archive-date=2020-01-11|access-date=2021-01-11|url-status=live}}
renders
"Title". Website. Archived from the original on 2020-01-11. Retrieved 2021-01-11.
with html exposed
'"`UNIQ--templatestyles-00000057-QINU`"'<cite class="citation web cs1">[http://original_url.com "Title"]. ''Website''. [http://archive_url.com Archived] from the original on 2020-01-11<span class="reference-accessdate">. Retrieved <span class="nowrap">2021-01-11</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Website&rft.atitle=Title&rft_id=http%3A%2F%2Foriginal_url.com&rfr_id=info%3Asid%2Fen.wiki.x.io%3AHelp+talk%3ACitation+Style+1%2FArchive+77" class="Z3988"></span>
Notice that the "live" title URL in rendered html is the original URL
Technical-mumbo-jumbo example 2 (|url-status=dead - default)
{{cite web|title=Title|website=Website|url=http://original_url.com|archive-url=http://archive_url.com|archive-date=2020-01-11|access-date=2021-01-11}}
renders
"Title". Website. Archived from the original on 2020-01-11. Retrieved 2021-01-11.
with html exposed
'"`UNIQ--templatestyles-0000005B-QINU`"'<cite class="citation web cs1">[http://archive_url.com "Title"]. ''Website''. Archived from [http://original_url.com the original] on 2020-01-11<span class="reference-accessdate">. Retrieved <span class="nowrap">2021-01-11</span></span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Website&rft.atitle=Title&rft_id=http%3A%2F%2Foriginal_url.com&rfr_id=info%3Asid%2Fen.wiki.x.io%3AHelp+talk%3ACitation+Style+1%2FArchive+77" class="Z3988"></span>
Notice that the "live" title URL in rendered html is the archived URL. The access date of the live link is either superfluous (if a stable archive) or wrong (it refers to obsolete access of now-dead link). The documentation compounds the error. The low-level coding produces it, by generically tying |access-date= to |url= without any contingencies.

65.88.88.76 (talk) 19:01, 8 July 2021 (UTC)

Bogus names

Following up on Help_talk:Citation_Style_1/Archive_76#junk_author_names where we added a facility to detect bogus names in citations, I saw that Trappist fixed the bogus name "Verfasser" in some 30 citations recently. Even though "Verfasser" is a German word (meaning author/editor) I consider the number high enough to no longer see this as an unsystematic error requiring manual detection and fixing. I have therefore added "Verfasser" to the list of names the template checks for so that it cannot be added to citations any more without generating an error:

Verfasser, Troumbis, Andreas Y. Declining Google Trends of public interest in biodiversity: semantics, statistics or traceability of changing priorities?. OCLC 1188566404. {{cite book}}: |last= has generic name (help)CS1 maint: multiple names: authors list (link)
Troumbis, Andreas Y. Declining Google Trends of public interest in biodiversity: semantics, statistics or traceability of changing priorities?. OCLC 1188566404.

--Matthiaspaul (talk) 11:54, 11 July 2021 (UTC)

@Matthiaspaul: I have a bot task for this - see BattyBot's contributions with an edit summary of "Removed/fixed incorrect author parameter(s)". I have more patterns to share if you're interested. Is there a maintenance category associated with this error? GoingBatty (talk) 18:09, 11 July 2021 (UTC)
Articles with names that satisfy the generic-name test (name_is_generic()) will be categorized in Category:CS1 errors: generic name. There are four sort-of-related maintenance categories: Category:CS1 maint: numeric names: authors list, Category:CS1 maint: numeric names: editors list, Category:CS1 maint: extra text: authors list, and Category:CS1 maint: extra text: editors list.
—Trappist the monk (talk) 18:53, 11 July 2021 (UTC)
Sure, if you know more such patterns, they can be considered for inclusion as well. --Matthiaspaul (talk) 20:48, 14 July 2021 (UTC)

The parent page

1. The volume parameter is not correctly explained. The text should be amended to account for the current schizophrenic presentation.

2. In External links/Online sources it is stated that reviews of the work should not be linked. ???? Practically any art/literature related article is suspect if that is the case?

3. The parameter subject is not explained/described anywhere.

66.108.237.246 (talk) 13:48, 14 July 2021 (UTC)

Proposal: default to display-authors=6

Edits that add references with long lists of authors are quite common, leading to references with very long lists of author names. For journals and books, it seems to be common practice to limit this list to 6, 4, or 3 authors. Likewise, display-editors=3 is quite common. So instead of always having to do this kind of maintenance manually every time, I'd like to propose that the citation templates default to display-authors=6 and maybe display-editors=3, then Wikipedians only have to set these parameters when necessary. --Fernando Trebien (talk) 17:11, 19 June 2021 (UTC)

I believe that this limit was in place for a long time, at first for technical reasons IIRC, but consensus here was that the artificial limit should be removed and left up to editors. If you dig a bit through this page's archives, you can probably find relevant discussions. (Edited to add: here is a discussion from 2014 talking about the old functionality.) – Jonesey95 (talk) 17:20, 19 June 2021 (UTC)
Yes, as Jonesey notes, the count that you find regarding 6 particularly was first a requirement of the templates before Lua, which could not process many more authors than that. This requirement made its way into the tools of the time that were used (e.g. Refill and others).
9 is the other number you will see.
I am not a fan of adding a limit here. Individual page authors can sort out how many authors they want. Izno (talk) 17:44, 19 June 2021 (UTC)
@Jonesey95: @Izno: Just for clarity, I'm not proposing a hard limit, just a default value. What happens is that many authors are careless about conciseness in citations. So an attentive author could still override the proposed default by setting display-authors=0 or any other value they see fit. I also believe that many experienced authors would find these defaults good enough in most cases, so they wouldn't feel they have to set them differently, which saves work. --Fernando Trebien (talk) 18:40, 19 June 2021 (UTC)
If you set a limit, then in practice it will become a hard limit in most cases. If you think that the number needs limiting in some particular article, then why not set it in that particular article, rather than pushing your preference to all articles where the editors have not already expressed a preference, and forcing all editors of articles with many-author references to come to consensus on how many is appropriate for that article? It's perhaps worth mentioning in relation to this that lately within academia I've seen a push for avoiding "et al" abbreviation of authors, especially in fields where authors are traditionally alphabetical (see for example the STOC 2021 call for papers), as it can be unfair to alphabetically-disadvantaged researchers to never have their names mentioned. —David Eppstein (talk) 18:57, 19 June 2021 (UTC)
Makes sense. There should be an easier way to handle this, perhaps adding a parameter like alpha=y to indicate that the citation system is alphabetic, which would set display-authors=0 by default. So, of course, we would need a crawler to look for citations of articles from specific journals that adopt this practice to add alpha=y to them. In any case, I've seen citations containing more than 50 authors, it seems problematic to simply allow them to be so extensive from the start. --Fernando Trebien (talk) 14:00, 20 June 2021 (UTC)
I consider this to be searching for a solution to a problem that does not exist. The majority of sources do not include many contributors, and in the few cases where dozens or even hundreds of authors could actually become problematic (per WP:NOTPAPER I don't think it does unless there would be many such references on a single page) the number of authors to be displayed can be controlled by the |display-authors= parameter. The simple solution you are looking for is to not implement any limit and choose a suitable |display-authors= limit (only) where it is actually necessary.
Any static default hardcoded into the template would be arbitrary and may give unfair advantage to some contributors (which we, as an encyclopedia, should all treat the same) or even violate our policy on neutrality (WP:NPOV). Different publishing houses have different strategies to list authors; some do not sort them at all, some sort them by relevance to the work, by their amount of contribution, by chronology of their contributions, by alphabet, by affiliation, by their reputation, by their function, by their age or by other criteria, and within each group, the entries might be listed in ascending or decreasing order - only the contributors and the publisher know. Any static default limit would be off in most of the cases, therefore we should not even try and introduce any such technically unnecessary limits to citation templates.
--Matthiaspaul (talk) 11:30, 11 July 2021 (UTC)

edited and translated

There are fields for editor and for translator, but these are often the same person and it looks awkward showing them in two different fields. Is there a way of showing " Smith, Joe, ed. and trans."? Dudley Miles (talk) 18:24, 26 June 2021 (UTC)

I suspect that there is little need to duplicate a name in the case that you have mentioned. Remember, the purpose of a citation is to help readers locate the source that you consulted when writing the en.wiki article. In cs1|2 templates, you can probably just write |editor-last=Smith |editor-first=Joe and that will be sufficient. There are cases, I just did one, where an author is also an editor so for that I wrote:
{{cite book |first=Kevin J. |last=Cathcart |chapter=The Curses in Old Aramaic Inscriptions |title=Targumic and Cognate Studies: Essays in Honour of Martin McNamara |editor=Cathcart |editor2=Michael Maher |year=1996}}
Cathcart, Kevin J. (1996). "The Curses in Old Aramaic Inscriptions". In Cathcart; Michael Maher (eds.). Targumic and Cognate Studies: Essays in Honour of Martin McNamara.
In this case it is important to state the chapter author and to name the editors of the edited collection. If you believe that it is important to separately name the translator then |translator=Smith should suffice (assuming that there is only one 'Smith' in the citation).
—Trappist the monk (talk) 18:56, 26 June 2021 (UTC)
I am thinking of a different case, an edition of a medieval work in Latin. Some editions are just the work in Latin, others also have a translation, and it would be very helpful for readers to know whether the edition includes a translation. I have cited *Greenaway, Diana, ed. (1996). Henry, Archdeacon of Huntingdon, Historia Anglorum The History of the English People. Oxford, UK: Clarendon Press. ISBN 978-0-19-822224-8.
I did not add the trans field as I thought it would look odd, but I think a field for 'ed and trans' would give the reader very useful additional information. Dudley Miles (talk) 20:23, 26 June 2021 (UTC)
I would use the language parameter, inserting both languages either by code or literal. And I would also use the translator parameter per Trappist. The parameter you suggest is probably too specialized to be considered.
{{cite book|title=Title|trans-title=Translated title|editor=Editor|translator=Editor|language=latin, en}}
renders
Editor (ed.). Title [Translated title] (in Latin and English). Translated by Editor. {{cite book}}: |editor= has generic name (help)
98.0.246.242 (talk) 20:38, 26 June 2021 (UTC)
Thanks for your help. I have added "language=latin, en". It looks a bit odd to me but at least it conveys the information. I still think the standard method used in academic citation of showing "ed. and trans." is better. It is very common, not specialized. Dudley Miles (talk) 20:58, 26 June 2021 (UTC)
Common, but complicates the citation module somewhat painfully, especially if there are multiple editors/translators who are not both of the two. Izno (talk) 21:10, 26 June 2021 (UTC)
There is no simple solution with multiple editors/translators, but the addition of fields editortrans-first and editortrans-last would cover most eventualities without causing complications. Dudley Miles (talk) 21:26, 26 June 2021 (UTC)
And still adds complexity, contrary to your suggestion. The simple solution as suggested above works today at some cost of repetition. I would not support a change here. Izno (talk) 21:58, 26 June 2021 (UTC)
So are you proposing *Greenaway, Diana, ed. (1996). Henry, Archdeacon of Huntingdon, Historia Anglorum The History of the English People. Translated by Greenaway, Diana. Oxford, UK: Clarendon Press. ISBN 978-0-19-822224-8.? This seems absurdly clumsy compared with a simple trans and ed field. Dudley Miles (talk) 22:34, 26 June 2021 (UTC)
/shrug. Circles at that point. Izno (talk) 22:54, 26 June 2021 (UTC)
I too think dedicated parameters for editors who are also translators would be overkill and open a can of worms: What about contributors who are authors and translators rather than editors and translators? What about those who are authors and editors? Or authors, editors and translators combined? Not to mention that there are more roles than authors, editors and translators alone. We obviously can't have dedicated parameters for all these combinations. This would complicate the user-interface too much. If anything, this would have to be something that the template would have to figure out by itself based on the usage of the existing parameters.
What I can envision for somewhen in the distant future is added support for some symbolic arguments which would allow someone to refer to another already given name in order to not have to repeat that name again (in order to reduce the risk for typos and also to define relations). At a yet later stage the template could then internally group the roles for display purposes. This could look like
|editor-first1=First1 |editor-last1=Last1 |editor-first2=First2 |editor-last2=Last2 |translator1=editor1
But in the current implementation this would add significant overhead, and there are more important things to be added first. Therefore, I would suggest to just add the names according to their roles using the existing parameters regardless of the mild clumsiness and repetition it causes.
--Matthiaspaul (talk) 16:56, 4 July 2021 (UTC)
Isn't Henry of Huntingdon the author so shouldn't the citation read:
{{cite book |author=Henry of Huntingdon |editor-first=Diana |editor-last=Greenaway |translator=Greenaway |title=Historia Anglorum: The History of the English People |publisher=Clarendon Press |location=Oxford, UK |year=1996 |isbn=978-0-19-822224-8}}
Henry of Huntingdon (1996). Greenaway, Diana (ed.). Historia Anglorum: The History of the English People. Translated by Greenaway. Oxford, UK: Clarendon Press. ISBN 978-0-19-822224-8.
Probably should have |orig-date=...
—Trappist the monk (talk) 22:51, 26 June 2021 (UTC)
Regarding commonality, I doubt that the combination editor/translator is a good example. Out of the entire universe of published works, relatively few list an editor. Fewer may list both an editor and a translator. I believe a substantially smaller subset of the last category would have the same person as editor and translator. That I think applies also in the much smaller universe of academic works. There is also the issue of utility. What is the marginal advantage that extra parameters add in order to find the cited source? If a work has an editor, it is likely that it has been classified (in main index or subindex) by editor, or also by editor. I can see how adding the additional info (+editor) can speed up discovery. If the work has been edited by different editors in different editions, then editor is necessary. I don't see equal utility by adding a translator, because usually bibliographic/reference databases rarely provide translator index results, even for translated works (unless perhaps one digs deep into the reference record). The marginal advantage the translator parameter adds in finding the source is more apparent when a certain work has different translators in different editions with the same editor. If a different edition has different editor (or editor/translator) see the comments on editors in this post. In any case, I always provide the translator, in the outside case there exist editions with different translators. 98.0.246.242 (talk) 00:32, 27 June 2021 (UTC)

Auto-generated URL question

{{cite journal}} will auto-generate a URL in the |url= field under some conditions eg. when |doi-access=free and |url= is otherwise empty. My question is, do other templates auto-generate |url=? The conditions are not important, only knowledge of which templates are capable of auto-generating URLs in the |url= field (for whatever reason). Is it possible {{cite magazine}} can auto-generate a URL? Or any of the other CS1|2 templates?-- GreenC 16:01, 15 July 2021 (UTC)

No. Only {{cite journal}} supports this because the identifiers that are the source for the url (currently |pmc= and |doi=) typically apply to journal articles. It has been suggested that |doi= with |doi-access=free might be applied to chapters of books or entries in encyclopedia. So far as I know, there has been no effort undertaken to accomplish this or to even determine if we should support |chapter= / |entry= autolinking from |doi=. I think that there has also been a suggestion to autolink |title= in {{cite book}} from |hdl= but again, just the suggestion.
—Trappist the monk (talk) 16:12, 15 July 2021 (UTC)
Ok, thanks. -- GreenC 16:26, 15 July 2021 (UTC)
There have been multiple requests to extend support for auto-linking beyond |pmc= and |doi= - I remember specific requests for |hdl=, |jstor=, |pmid= and |s2cid= as well as requests to support auto-linking for all identifiers. In addition to this, there have been requests to allow auto-linking in all CS1/CS2 templates instead of in {{cite journal}} only.
While I was not a fan of auto-linking in general, I can accept it for as long as there is a way to override or disable the automatic selection (as is meanwhile implemented through |title-link=none/pmc/doi/link). I would also support adding this feature to all citation templates and to extend support to all identifiers under one restriction:
For new identifiers, we should not support automatic selection because it would be impossible to come up with a reasonable list of priorities for automatic selection when more than a few identifiers are involved. However, if the feature requires manual selection via |title-link=identifier it cannot cause harm. Eliminating exceptions and being able to use more generic table-driven code rather than hardcoded special cases will help to simplify the code and documentation, and therefore will make the templates easier to use and maintain.
Regarding autolinking support for chapters, this was requested several times as well. In fact, I even started implementing it in the sandbox in 2020 by adding |chapter-doi= and |title-doi= parameters as more specific aliases to |doi=, but this was removed again. --Matthiaspaul (talk) 20:54, 15 July 2021 (UTC)
All free versions of record identifiers, not all identifiers. PMID, for instance, will never link to a version of record. arxiv is likewise, not a version of record (although it could certainly autolink in {{cite arxiv}}). Headbomb {t · c · p · b} 21:17, 15 July 2021 (UTC)
Regarding free, this should probably use the same mechanism as with |doi= and |doi-access=free (see Help:Citation_Style_1#Access_indicator_for_named_identifiers).
Regarding version of record vs. arxiv, this could be controlled by a flag in the identifier table, but supporting an identifier in specific templates only could complicate things again rather than simplify them. For as long as only manually selected auto-linking would be implemented for the other identifiers (as suggested by me above), the auto-linking would always be the result of an editor's conscious decision, so perhaps the extra complexity to prevent certain combinations would not be needed (those, which do not make much sense would probably not be selected in the first place, and if so occasionally, they can be easily corrected).
--Matthiaspaul (talk) 10:45, 16 July 2021 (UTC)

Publisher of a website

Cite web says "The publisher is the company, organization or other legal entity that publishes the work being cited"

When a page is cited from the MTV website, sometimes I see |publisher=MTV. Viacom or |work=MTV|publisher=Viacom

Are either/both of these variations acceptable or is there a more preferred way to cite this? Kaltenmeyer (talk) 22:32, 15 July 2021 (UTC)

|title= is the name of the page or article that you are citing; |work=MTV or |website=MTV is the name of the enclosing work (the website, or for a journal article |journal= or for a newspaper article |newspaper= – they are essentiall synonymous); |publisher=<publisher's name> is the name of the business entity that published the work and so the article. In general, |publisher= isn't needed in {{cite web}} for the same reason that |publisher= isn't usually needed for {{cite journal}} and {{cite news}} – the business entities behind the journal / newspaper / website are bought and sold so the publisher information doesn't really help the reader locate a copy of the source. Of course there are those who disagree with me ... some of them vehemently ...
—Trappist the monk (talk) 23:03, 15 July 2021 (UTC)
Unless there's something surprising or special about the publisher, I usually leave it out of {{cite web}} citations. That Viacom owns MTV is, IMO, widely known and not surprising. If the site has some more arcane or technical name, like Our Friend the Butterfly, and the publisher is the International Union for Promoting Fluttering Insects, I would include both, as it might be relevant to weighing the ref's worth. I believe I have also done |website=National Weather Service |publisher=National Oceanic and Atmospheric Administration as well. — JohnFromPinckney (talk / edits) 23:05, 15 July 2021 (UTC)
There are 2 reasons, somewhat esoteric, I would include the publisher: if there are works with the same name but with different publishers; and as a location of last resort. If the source cannot be found anywhere, it is possible that the publisher, or the then-publisher may be able to provide a copy. 64.18.9.208 (talk) 11:30, 16 July 2021 (UTC)
If anything, what gets to me is that CS1 italicizes website names regardless of whether or not it's appropriate. This means I end up seeing things like MTV or CNN in citations when I have never seen MTV or CNN italicized in general. Whether to mention that MTV is owned by Viacom (or I guess ViacomCBS now)... I don't know. MTV's been with Viacom for over 35 years – not only the majority of its total lifespan but also its entire Internet lifespan – so ownership is stable, and I guess clearing things up for those who don't know might be desirable (WP:DOCITEBLUE, WP:POPE, comic on today's lucky 10,000), but most websites need little more than a URL to help you find it, technically speaking. -BRAINULATOR9 (TALK) 18:00, 16 July 2021 (UTC)
See MOS:ITALICWEBCITE, more specifically the footnote. —El Millo (talk) 18:04, 16 July 2021 (UTC)
Thanks for that; it helps to know that this was settled in an RfC. -BRAINULATOR9 (TALK) 19:31, 16 July 2021 (UTC)

Invalid Cite web aliases in TemplateData

For a list of depreciated Cite web parameters, see Cite web § Deprecated.

I have attempted to edit the TemplateData shown for the {{Cite web}}. In the previous iteration, depreciated aliases for the various editorn-link parameters were listed. These invalid aliases were: editornlink and editorlinkn. I am trying to remove the nonexistent aliases from the TemplateData, but Wikipedia won't let me save my changes, citing JSON errors. — CJDOS, Sheridan, OR (talk) 19:05, 20 July 2021 (UTC) (edited 19:11, 20 July 2021 (UTC))

I have attempted to resolve the JSON syntax errors per mediawikiwiki:Help:TemplateData#Syntax error in JSON / Bad JSON format, believing that I had orphaned commas in my edit (which was true), but it still won't let me save changes due to other unidentified JSON syntax error present. — CJDOS, Sheridan, OR (talk) 19:30, 20 July 2021 (UTC)

JSON is fragile and the error reporting is laughable so it is probably best to use Manage TemplateData button at the top of the page when viewed using the wikitext editor using the section [edit] link (the button is directly under the main page header).
—Trappist the monk (talk) 19:40, 20 July 2021 (UTC)
Thank you. I will try that later, but I'm taking a break for now. If I'm not mistaken, I believe true is supposed to be encased in quotation marks, but that hasn't cleared the JSON syntax error messages. — CJDOS, Sheridan, OR (talk) 19:58, 20 July 2021 (UTC)
The Boolean constants true and false should not be quoted - if they are, they get casted to string type and may not test correctly. --Redrose64 🌹 (talk) 20:07, 20 July 2021 (UTC)
 Done: I have performed the editorn-link edit in the manner suggested. Thank you. — CJDOS, Sheridan, OR (talk) 20:14, 20 July 2021 (UTC)

doi:10.119.1/foobar should throw an error

See

  • Scurek, R. (2004). "Understanding the CPT group in particle physics: Standard and nonstandard representations". Am. J. Phys. 75 (5): 638–643. doi:10.119.1/1.1629087.

Headbomb {t · c · p · b} 20:40, 22 July 2021 (UTC)

The correct DOI would be 10.1119/1.1629087, but wouldn't the registrant code in your example "119.1" be in a valid format as well (that is, at least four digits, larger than 1000, possibly subdivided with dots)? What kind of pattern do you suggest to look for?
--Matthiaspaul (talk) 00:32, 23 July 2021 (UTC)
I imagine that if we troll back through this page's archives we will find a discussion where it was decided that we will allow registrant portion of the doi to have fewer than four digits when it has a subcode (line 564).
—Trappist the monk (talk) 00:48, 23 July 2021 (UTC)
Possibly this discussion from December 2019. – Jonesey95 (talk) 06:00, 23 July 2021 (UTC)

Date validation error

A recent edit diff introduced two "Lua error in Module:Citation/CS1/Date_validation at line 936: attempt to compare nil with number" at 1985–1986 Hormel strike#Bibliography. The edit did not change the bibliography but it added "|cs1-dates=y" to give {{Use mdy dates|date=July 2020|cs1-dates=y}}. The problem is probably due to the letters in the two problematic {{cite web}} instances: |date=August 9, 2010a and |date=August 17, 2010b and that should be fixed. However I'm wondering if some tweak to Module:Citation/CS1/Date validation should occur, possibly to change tonumber(t.y) to (tonumber(t.y) or 0) at line 936. Johnuniq (talk) 07:22, 28 July 2021 (UTC)

Thanks for that suggestion. I implemented it. But, as soon as I did, I realized that a better solution is to strip the CITEREF disambiguator and let the process proceed. Doing that gives the desired rendering in the citation. It would seem that a maintenance message when this occurs might be appropriate.
—Trappist the monk (talk) 11:06, 28 July 2021 (UTC)
Thanks to you both for the hint and fix. I too think that a maintenance message might be useful.
However, thinking about those odd disambiguators in dates, I really think that we should slowly start to deprecate and find a better solution for them. Some while back I proposed to add this functionality to the |ref= parameter: Help_talk:Citation_Style_1/Archive_76#Module:Citation/CS1/testcases/anchor_and_some_questionable_tests
--Matthiaspaul (talk) 17:10, 28 July 2021 (UTC)

ref-duplicates-default detector flaw

This should emit a maintenance message but doesn't:

{{cite book |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}
Last, First (1953). Title.{{cite book}}: CS1 maint: ref duplicates default (link)

The value assigned to |ref= is the same as is produced by {{sfnref}}:

{{sfnref|Last, First|1953}}
CITEREFLast,_First1953

But, the comparison between |ref= and the CITEREF ID created by Module:Citation/CS1 is made before the newly created CITEREF ID has been anchor encoded: CITEREFLast, First1953 (space character instead of an underscore). Because the two values are different, no maintenance message.

Fixed:

{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}
Last, First (1953). Title.{{cite book}}: CS1 maint: ref duplicates default (link)

And, when they really are different:

{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First2020}}
Last, First (1953). Title.

no maintenance message.

—Trappist the monk (talk) 17:59, 23 July 2021 (UTC)

Visual Editor claims that usurped is not expected in the url-status field

Whenever I am trying to switch a deadlink citation to an archive link, I sometimes need to mark it as usurped. But it seems that the only values that the Visual Editor expects are "live" (the default) and "dead". Adding usurped or unfit gives the warning " This is not one of the suggested values and may not work with the template". Can they be added as legitimate values please. By experimentation, they do actually work as expected if added, but the message would have you think otherwise. Thanks Kerry (talk) 05:49, 30 July 2021 (UTC)

That is not a cs1|2 issue but rather is an issue with VE's template data. You are free to edit the template data to add usurped and unfit. There are 27 cs1|2 templates so you should check and update all of them.
—Trappist the monk (talk) 12:01, 30 July 2021 (UTC)
I've added the two to cite web as well as all four to cite news. Others may make similar edits for other templates. Izno (talk) 12:52, 30 July 2021 (UTC)

Identifier-specific template EBSCOhost

Moved thread to Template talk:EBSCOhost#Identifier-specific template EBSCOhost. --Matthiaspaul (talk) 22:29, 31 July 2021 (UTC)

summary messaging in the preview warning header

Whenever you preview a page, above the previewed text there is a yellowish message box that reads: 'This is only a preview; your changes have not yet been saved!' Scribunto has a function mw.addWarning() that can add text to that box. Usually I only notice that box when some template has duplicate parameters. For example, this template:

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

causes this message:

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

It occurred to me this morning that adding generic messaging about cs1|2 errors and maintenance messages might help editors notice that there are errors in an article's cs1|2 templates. So I've hacked Module:Citation/CS1/sandbox as an experiment. To see this experiment, edit and then preview this version of my sandbox.

Opinions?

—Trappist the monk (talk) 14:16, 12 July 2021 (UTC)

I like it in general, and I can imagine it being useful for a variety of template errors. There is precedent for using it for duplicate parameters, but those are rare since they were cleaned up, so most editors probably haven't seen such an error. I think we would have to get buy-in from the community, since these messages would be appearing on every editor's preview screen. Pitchforks, etc. I wonder if there is a way to do a small-scale test. – Jonesey95 (talk) 16:24, 12 July 2021 (UTC)
I suppose that, if we must, we could limit the output to cs1|2 templates that are not {{cite book}}, not {{cite journal}}, not {{cite news}}, not {{cite web}}, and not {{citation}}. Or, conversely, to just one of the 'big 5' ...
—Trappist the monk (talk) 17:24, 12 July 2021 (UTC)
I agree that this looks like a good idea. Might one possibility for a test be to limit it to a single additional class of error, and to pick something that's clearly always a significant error: e.g. {{cite journal}} being used without journal=? Wham2001 (talk) 18:00, 12 July 2021 (UTC)
The Cite <template> requires |<param>= error messages are hidden so don't seem to me to be a good candidate for a test. Though I haven't tried it, I think that picking a particular error is rather more difficult and goes beyond the intent of this messaging which is more summary than detail. But, it does raise an issue: what to do about hidden error messages? We might change the message so that it reads:
{{<template>}} template has n× errors; messages may be hidden (help)
I've also noticed that exact duplicates of the messages added to the yellowish box are not repeated so it would make some sense to have the messages read:
One or more {{<template>}} template has n× errors; messages may be hidden (help)
—Trappist the monk (talk) 19:04, 12 July 2021 (UTC)
I like this as well. Would it be possible to let the "cite xyz" prefix in the messages link to the template's help page, like in "{{cite book}}"? This would make it easier to look up the template-specific help in case of errors and would follow the same idea as this older proposal to add small "" icons in front of the citations in preview mode: Help_talk:Citation_Style_1/Archive_69#Template-specific_help_in_preview. --Matthiaspaul (talk) 18:22, 12 July 2021 (UTC)
What's interesting is that if identically looking messages are added, only one of them will be shown. To avoid this, a template would have to provide some disambiguating information (like its CITEREF anchor):
{{citation}} template "Author2020" has 2× errors
{{citation}} template "Author2021" has 1× errors
This would help to avoid oddly looking messages such as
{{citation}} template has 2× errors
{{citation}} template has 1× errors
and also help to locate the problematic template if there are many uses of the same template, but on pages with many citations (with errors) the list could become very long.
On the other hand, it could also be used to keep the message very short in total by just stating that there are errors instead of how many:
{{citation}} template has errors
--Matthiaspaul (talk) 18:42, 12 July 2021 (UTC)
I've tweaked the test a bit (error messages only) because of that identical-messages-not-repeated thing, linked to the template pages and corrected for config.CitationClass that doesn't exactly match the template's canonical name. I'm not wedded to the 'n× errors' text; I added it because I wanted to see how easy it would be to include that kind of information. It is perhaps too much detail; this is supposed to be summary (I've also changed the topic's title to reflect 'summary' rather than 'generic')
—Trappist the monk (talk) 19:04, 12 July 2021 (UTC)
If it's only meant as a summary to alert the editor that there are errors to look at (further down), I think, the number of errors is not important to know at all. It's also irrelevant to know that different citations using the same template might contain different numbers of errors. By eliminating the number we would avoid such odd looking messages.
Still good to know how to include additional information for cases where this might be useful to provide in the future.
--Matthiaspaul (talk) 19:38, 12 July 2021 (UTC)
I personally like the colored messages, but for consistency with the messages issued by MW itself, perhaps it would better if our messages were using the same style and capitalization. This could look similar to:
Warning: Help talk:Citation Style 1 is calling Template:Cite book/new with more than one value for the "title" parameter. Only the last value provided will be used. (Help)
Warning: Help talk:Citation Style 1 is calling Template:Cite book/new with errors. Messages may be hidden. (Help)
Warning: Help talk:Citation Style 1 is calling Template:Cite book/new with warnings. Messages may be hidden. (Help)
--Matthiaspaul (talk) 17:01, 13 July 2021 (UTC)
For comparison, the {{infobox}} templates don't use mw.AddWarning() but issue error messages looking somewhat similar to MW's:
Preview warning: Page using Template:Infobox with unknown parameter "unknown"
This message shows up at the location of the template's invocation (that is typically just below the yellowish preview box). What we can draw from this is that issuing inline messages only in preview would be an option for us as well. So, it we would want to keep the message in the yellowish preview box really short, it could be reduced to a single line even in case of multiple templates generating errors like:
Warning: Help talk:Citation Style 1 is calling citation templates with errors or warnings. Messages may be hidden. (Help)
We would still be able to provide links to the individual templates' help pages by using the same preview messaging mechanism as {{infobox}} to insert those small "" icons (per the above linked thread) in front of the citations (at least those, which have errors):[1]
  1. ^ Cite journal template documentation Smith, John (9999). "Title of Things". Journal of Stuff. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. {{cite journal}}: Check date values in: |date= (help)
--Matthiaspaul (talk) 17:43, 13 July 2021 (UTC)
I don't particularly care for the MediaWiki warning style. I'm pretty sure that I know what page it is that I'm editing so that information isn't needed. I've tweaked the colored messages so they don't bleed quite so much and removed the error-tally from the messages. The point is to draw attention to the need for repairs so the color is, I think, important. If the cs1|2 messages look too much like the MediaWiki messages, I fear that they will be ignored.
—Trappist the monk (talk) 21:42, 13 July 2021 (UTC)
I think that the revisions are an improvement. I noticed one apparent typo: "One or more {{cite book}} template has errors" should read "... templates ..." – Jonesey95 (talk) 17:26, 14 July 2021 (UTC)
Are you sure? Plural 'templates' just sounds wrong to me because 'One' dominates and 'or more' could almost be set off with commas or parentheses:
One, or more, {{cite book}} template has errors
One (or more) {{cite book}} template has errors
And, if it is as you say, wouldn't it be: "One or more {{cite book}} templates have errors"?
I suppose we could evade the issue and rewrite – though this doesn't share nicely with maintenance messaging:
{{cite book}} template errors detected
or we could write:
{{cite book}} template has errors
{{cite book}} template has maintenance message
—Trappist the monk (talk) 17:54, 14 July 2021 (UTC)
I missed the verb. It should be "templates have". Here's a lively thread with references to sources (which do not always agree, of course). If we can't agree, a slightly uglier phrasing of "At least one cite book template has errors" would be grammatical. – Jonesey95 (talk) 22:54, 14 July 2021 (UTC)
Some observations:
The preview messages give the canonical name of the template. It would show, for example, {{cite book}} even if {{cite book/new}} is what was invoked. Similar, it would show {{cite news}} even when the actually used template is {{cite newspaper}}, a redirect. While the first case could be fixed programmatically, there is no cure for the second type of cases. However, perhaps no actual fix is necessary. The wording could be adjusted accordingly, for example:
or something along this line. Alternatively, since noone commented negatively on my proposal for template-specific ""-style help links in front of the problematic citation templates themselves above, I'm bringing this up again in this context. Thereby we could eliminate the need to explicitly state the name of a template in the preview at all:
  • A CS1/CS2 citation template has errors
  • A {{cite ...}} template has errors
  • CS1/CS2 citation templates have errors
  • {{cite ...}} templates have errors
As can be seen on this page, the preview message also occurs on talk pages. While this is certainly desirable here (to illustrate the messages) this could encourage editors on other talk pages to correct errors in templates even in other editors' talk page contributions - while this would be in most cases harmless, I'm not sure if we should encourage this. However, disabling the messages on all talk pages we would need some means to override this (for example, to still show them on this talk page, where the automatic disabling could be overridden by our debug parameter |template-doc-demo/no-tracking=yes, for which BTW we are still seeking a better name).
--Matthiaspaul (talk) 14:32, 21 July 2021 (UTC)
It is not possible to know the name of the template that {{#invoke:}}s Module:Citation/CS1. We can spoof {{cite book/new}} if we modify that template to use |CitationClass=book/new (and then modify the module so that it recognizes both forms ...). Not worth the effort to do that.
I have no enthusiasm for template-specific ""-style help links. And, |link= has the same 'canonical name only' problem that you are complaining about with the preview messages...
We can use the same mechanism that we use to prevent talk-page-categorization to prevent preview messaging in those same namespaces. We might need to create a variable no_preview_msgs so that we allow preview messaging in ~/sandbox pages else we can just reuse no_tracking_cats.
—Trappist the monk (talk) 15:22, 21 July 2021 (UTC)
Just in case this somehow went down the wrong throat, I was not complaining at all, just listing observations and possible options in our quest to find the best-possible solution.
Also, I agree with you that gettting {{cite book/new}} right would not be worth the effort.
Regarding the template-specific help icon, I don't understand your |link= argument. Of course, for the reasons stated, the help link would point to {{cite news}} even if the actual invocation would be from {{cite newspaper}} or {{cite news/new}}. But by using an icon instead of text we would not have to explicitly state the target name as in the preview message, thereby avoiding the issue altogether.
From the usability point of view, both ways provide the template-specific help link. There are probably some minor pros and cons depending on if the context-link is in the preview box at the top of the screen (getting sort-of the template's name to search for, but having to look up the error messages elsewhere) or in front of the offending citation (getting a help link in the immediate vincity of the template throwing the error/warning, but not getting any hint at the template's name at all) - but I would consider them both as good enough for the purpose. It would even be possible to combine them.
From the coding perspective, the box message gets issued through mw.addWarning(), whereas the icon would depend on {{REVISIONID}}, not much code overhead either way.
Regarding not being enthusiastic, I would appreciate if you could explain this a bit more rationally to better understand your thinking. Is it related to the look, the usability, the implementation, or just a lack of fun doing it?
--Matthiaspaul (talk) 17:34, 21 July 2021 (UTC)
Using an icon image does not avoid the issue of explicitly stating the target name because, for accessibility, we must supply values for the icon's |alt= and |link= parameters. |alt= might get something like link to cite news template documentation so alt text and the link suffer from the same problem as the preview warning when the offending template is a redirect or a wrapper. Omitting the canonical template name from the alt text (link to template documentation) is not acceptable because we should identify the icon's link target.
I don't think that lack of enthusiasm demonstrates irrationality on my part. I am not enthusiastic about icons because I'm not enthusiastic about icons. I don't like that these proposed icons are at one end of the rendered citation while the error messaging is (primarily) at the other end. I wonder if we should include a list of cs1|2 templates somewhere on Help:CS1 errors and then link to that list from each error message section in the same manner that we link to the help desk. Or, perhaps, modify the error messaging so that the linked canonical template name prefixes the error messages in preview. To do that will require a bit of work to move all error messages that now render mid-citation to the end of the rendering (something that I think should be done anyway):
[offending template rendering] {{cite news}}: <error message> (help)
—Trappist the monk (talk) 13:51, 22 July 2021 (UTC)
Thanks, this is exactly the type of explanation I was missing. I did not intend at all to imply irrationality on your side. But to understand each other we need to explain our feelings and reasoning to others. I did not consider the lack of alt text an accessibility issue here because I saw the icon as a non-essential part of the UI and was willing to compromise on it in order to keep it as short and unobtrusive as possible. In the old thread, I was also proposing to alternatively just use a text question mark. But I can see your point. In the old thread, Headbomb suggested adding a whole sentence fragment following the citation, something that I found too long for what we wanted to achieve, but I like your proposal to move all mid-citation messages to the end and prefix them with just the canonical name of the template - this way, it remains unobtrusive and short.
--Matthiaspaul (talk) 01:57, 24 July 2021 (UTC)
I have hacked Module:Citation/CS1/Identifiers/sandbox so that all of the error messages that it produces are now listed at the end. These error messages account for the preponderance of mid-citation error messages. I have added the template name prefix and an error message sort to Module:Citation/CS1/sandbox so that error messages are listed, more-or-less, in alpha-order. The sort is simple ascii and isn't perfect because the error messages to be sorted have html markup and html entities; for example, these sort in this order:
  1. <span class=\"cs1-hidden-error citation-comment\"><code class=\"cs1-code\">&#124;volume=</code> has extra text ([[Help:CS1_errors#extra_text_volume|help]])</span>
  2. <span class=\"cs1-visible-error citation-comment\"><code class=\"cs1-code\">&#124;issue=</code> has extra text ([[Help:CS1_errors#extra_text_issue|help]])</span>
  3. <span class=\"cs1-visible-error citation-comment\">Check <code class=\"cs1-code\">&#124;arxiv=</code> value ([[Help:CS1_errors#bad_arxiv|help]])</span>
A good place to see this in action is at Module talk:Citation/CS1/testcases. Still need to seek through error message creation in other module pages to find the remaining mid-citation error messages and move them to the end. Once that's done, I think that further optimization can be done because messages can (should be?) added to z.message_tail by set_message() instead of where the message occurs unless something special is required for a particular message.
—Trappist the monk (talk) 11:56, 25 July 2021 (UTC) 19:52, 25 July 2021 (UTC) (better sort example)
I like this (most of it). One further idea:
In order to make it easier to put the focus on the rendered citations with the detailed error messages, I think, the messages in the preview box should contain a link to this location. As a matter of fact, we can't link to all of them, but the most reasonable location to link to would be the first citation throwing an error. Once fixed, the link would point to the next offending citation in the row, and so on, so this linking scheme would appear to be quite natural in the process of fixing errors. Also, clicking the link would (and should) work even for citations generating "invisible" messages, so the editor would at least see the (first) offending citation, even if not the actual message.
Implementing this would be quite easy: All we would need is a template-specific anchor for errors and for maintenance created in front of a citation if (and only if) this citation throws the corresponding type of message (regardless of visibility). The message in the preview box could then link to this anchor. If multiple citations of the same type would throw messages, they would all create identically named anchors and, clicking the link in the preview box, the browser would focus on the first of them.
In theory, creating identically named anchors is invalidating the HTML, but this does not cause any real-world issues and it also happens with non-disambiguated ({{harv}}-style) references. Still, to avoid this at least in the normal article view we could generate these invisible anchors only in article preview (using {{REVISIONID}}), so that they would only exist when an editor is previewing a page, and there is actually a preview box with errors containing links to them.
The preview messages could look like (mockup):
One or more {{cite journal}} templates issue errors; messages may be hidden (help)
One or more {{cite book}} templates need maintenance; messages may be hidden (help)
--Matthiaspaul (talk) 10:32, 29 July 2021 (UTC) (updated 11:01, 29 July 2021 (UTC))
As a simple experiment, I have hacked Module:Citation/CS1 to create an anchor from config.CitationClass for the error warnings (not for maintenance). Edit this page, preview.
I'm not sure that the word 'errors' should be linked; that doesn't make it obvious that the link takes the editor to a broken citation. Perhaps something like:
One or more {{cite journal}} template has errors; messages may be hidden (help). Jump to citation.
—Trappist the monk (talk) 13:38, 29 July 2021 (UTC)
And now maint warnings.
—Trappist the monk (talk) 14:56, 29 July 2021 (UTC)
We could use the same style as MW:
This is only a preview; your changes have not yet been saved! → Go to editing area
One or more {{cite journal}} templates have errors; messages may be hidden (help). → Go to citation
--Matthiaspaul (talk) 17:07, 29 July 2021 (UTC)
Meh. We are not MW so why would we want to look like MW?
—Trappist the monk (talk) 17:29, 29 July 2021 (UTC)
Consistency of the user interface, to give the user a smooth and seamless experience and let it look as if it was designed as "one thing" as much as possible instead of everyone inventing their own style.
--Matthiaspaul (talk) 20:09, 29 July 2021 (UTC)
Thanks for implementing it. I have changed the trailing semicolon into a dot to properly stop the sentence and for consistency with the MW message above.
Playing with the feature I must say I really like it and hope that it will be well-accepted by the community and help to spot citation errors more easily. :-)
Still, I think, that some more refinement is desirable in regard to the message text:
One or more {{cite book}} template has errors; messages may be hidden (help). → Go to citation
One or more {{cite book}} template has maintenance messages; messages may be hidden (help). → Go to citation
To me the combination of "more" and singular "template has" sounds odd. Jonesey suggested plural "templates have". You mentioned that, for you, "one" dominates. There is a singular-rule for or-clauses, but it applies only for as long as all individually listed items are singular. To me, "more" implies plural of templates, and the verb follows the numerus of the nearest subject.
Another observation is semantically: In a strict sense, it is (hopefully) not the template having errors, but the template's invocation (the citation) in the article. Perhaps this could be remedied without complicating things too much simply by using verbs like "issue errors" or "emit errors" (or your "detected errors" above) instead of "have errors". In the maintenance case, we could use "need maintenance" instead of "have maintenance messages":
One or more {{cite book}} templates issue errors; messages may be hidden (help). → Go to citation
One or more {{cite book}} templates need maintenance; messages may be hidden (help). → Go to citation
or perhaps something like
Template {{cite book}} signals citation errors; messages may be hidden (help). → Go to citation
Template {{cite book}} requests citation maintenance; messages may be hidden (help). → Go to citation
--Matthiaspaul (talk) 18:27, 31 July 2021 (UTC)
Template {{cite book}} requests citation maintenance. Do not like. Too anthropomorphic. I still prefer 'One or more cite xxx template has ...' but I would also write 'the government are morally bankrupt' instead of '... is morally bankrupt'. But the tide is against me so I've changed to 'One or more cite xxx templates have ...'
—Trappist the monk (talk) 18:46, 1 August 2021 (UTC)
Regarding alpha-sorting of the messages, I think this is good enough for now, although this sometimes leads to somewhat odd results when there are many messages at once. In the long run, I think, we would have to add some weighting to group the more essential messages first, possibly ordered by occurence in the citation's rendering, followed by ID-related messages sorted alphabetically (or, more indirectly, by order of IDs in the table). But since there are typically not many messages at once, I think it is already good enough for a release.
--Matthiaspaul (talk) 13:18, 1 August 2021 (UTC)
It isn't hard to strip html and html-like tags from the error messages and sort by the message text: 
table.sort (z.error_msgs_t,
	function (a, b)
		return a:gsub ('%b<>', '') < b:gsub ('%b<>', '') end
	)
and then if you really want to sort by first letter of the error message, you have to also strip leading pipes from those messages that begin with a parameter name. Unless it is really necessary, we document the apparent anomalies and leave it at that.
—Trappist the monk (talk) 18:46, 1 August 2021 (UTC)
I suppose anything that points out errors before the edit is committed is a good thing. I don't see any obvious negatives, except that the usual chorus of snowflakes may find something else to complain about, regardless. 64.18.9.209 (talk) 12:12, 13 July 2021 (UTC)
Wild brainstorming: Is there a way to make the text of added preview warnings invisible somehow, and does mw.addWarning() provide return codes, perhaps even a special one when a message gets discarded for being a duplicate? If so, perhaps this mechanism could be utilized to let a citation detect that it is using the same CITEREF anchor as another citation on the same page and therefore would need disambiguation in conjunction with {{sfn}}... --Matthiaspaul (talk) 19:00, 13 July 2021 (UTC)
Why would you want to hide a preview message? It can be done with css display: none; but why? Are you suggesting that this could be (mis)used as a inter-template mailbox? Sort of a one-way mailbox though, isn't it?
Here is the documentation, such as it is, for mw.addWarning(). No return value but if you write this in the debug console the 'return' value is 'nil':
=(nil == mw.addWarning('warning text')) and 'nil' or 'sommat else'
—Trappist the monk (talk) 19:31, 13 July 2021 (UTC)
Exactly, the wild idea was to send "invisible" messages containing the CITEREF anchor name to the preview box and act on the return code (if there would be a special one when discarding duplicate messages). However, just wishful thinking... --Matthiaspaul (talk) 20:04, 13 July 2021 (UTC)
BTW. The German documentation is somewhat better, but still no return code: de:Hilfe:Lua/Programmierung#mw.addWarning() --Matthiaspaul (talk) 20:08, 13 July 2021 (UTC)
While I heartilly endorse having an error summary at the beginning or end, I would prefer to keep or improve the exiting inline error messages. The easier it is to find the offending markup, the better, and removing the messages from the citations would be a step backwards. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:43, 25 July 2021 (UTC)
Umm, where did you get the idea that this proposal will remove error messages attached to individual citations? It will not. The summary at the top is intended to alert editors that errors are present at the bottom of an article preview where editors might not think to look before saving an edit.
—Trappist the monk (talk) 13:59, 25 July 2021 (UTC)
See also: Help_talk:Citation_Style_1#error_messaging --Matthiaspaul (talk) 10:32, 29 July 2021 (UTC)
Retrieved from "http://en.wiki.x.io/w/index.php?title=Help_talk:Citation_Style_1/Archive_77&oldid=1068128438"