Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

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)

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
  • |season=, |series-no=, and |series-number= limited to use by {{cite episode}}
  • |series-link= limited to use by {{cite episode}} and {{cite serial}}
  • |cartography= limited to use by {{cite map}}
  • |book-title= limited to use by {{cite conference}}
  • |conference=, |conference-format=, |conference-url=, |event= limited to use by {{cite conference}} and {{cite speech}}
  • |degree= limited to use by {{cite thesis}}
  • |docket= limited to use by {{cite report}} and {{cite thesis}}

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)

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)

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)

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:

• 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
  • |season=, |series-no=, and |series-number= limited to use by {{cite episode}}
  • |series-link= limited to use by {{cite episode}} and {{cite serial}}
  • |cartography= limited to use by {{cite map}}
  • |book-title= limited to use by {{cite conference}}
  • |conference=, |conference-format=, |conference-url=, |event= limited to use by {{cite conference}} and {{cite speech}}
  • |degree= limited to use by {{cite thesis}}
  • |docket= limited to use by {{cite report}} and {{cite thesis}}

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)

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)

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

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. 15 March 1989. 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. 15 March 1989. 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)

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)

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)

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)

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)

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)

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)

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)

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 (1 May 2015). "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 (1 May 2015). "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)

Current version of page no longer contains cited facts. url-status=??

It seems to me that there |url-status= needs another option, for a webpage which is live and has not been usurped, but where the current version no longer contains the cited info.

I have been archiving the refs on the article Paul Gogarty (an Irish politician), and the page http://www.paulgogarty.com/about/ was cited in 2009 as a ref for the assertion that he joined the Green Party in 1989 as a student. That current live age doesn't say that, because Gogarty left the Green party 10 years ago, and has been an independent since 2011. So his biog page now focuses more on his status as an independent.

However, the relevant facts are in an archived version of the page, from 2009: https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/

I was unsure what value to give for |url-status=. None of the options was a good fit:

1. |url-status=live makes the current version the primary link, which is not helpful
2. |url-status=usurped would be untrue, because the domain has not been usurped
3. |url-status=unfit initially seemed like the best option, but it does not link the original URL, which seems unhelpful
4. |url-status=dead isn't strictly true, because the original page is still live ... but this option does link the original URL

So in this edit[3] I used |url-status=dead as the least-worst option.

However, it would be better to have some option which more accurately describes the situation. Maybe |url-status=rewritten or |url-status=revised?

It seems to me that this situation is not uncommon, so there should be an option which supports it. --BrownHairedGirl (talk) • (contribs) 06:03, 17 June 2021 (UTC)

This is indeed a common situation, e.g. in websites of scientific organisations. A |url-status=revised (or |url-status=updated or |url-status=changed) as short for changed and no longer containing the cited information and linking to an archived version would be more informative than shoe-horning |url-status=dead. —  Jts1882 | talk  07:53, 17 June 2021 (UTC)

I support the idea, but we should try and find a keyword which cannot be misunderstood. "changed", "updated", "revised" or even "rewritten" could mean all kinds of changes to the page, including those which are still supporting the statement and for which we would not want to swap the |url= and |archive-url= links. Perhaps |url-status=outdated would transport that message? --Matthiaspaul (talk) 12:08, 17 June 2021 (UTC)

No, I do not think adding content-related options to the parameter is the way to go.

Assuming the information removed from the source is still correct and pertinent, and there is a reliable archive available, I would cite the archive directly (using {{cite web}} in this case) and so avoid the |url-status= situation.

The url-status parameter is an editor utility parameter regarding the url ... status. It is named so. It is there to signal editors the reason a certain link cannot/should not be used. It makes no assumptions about the link's content. If the pertinent information is not there then there are verifiability, not citation, issues. If however there is an archive, see the previous paragraph. 69.203.140.37 (talk) 12:28, 17 June 2021 (UTC)

Hm, if I have to cite an archived version of some former site because the original site no longer exists or has changed in unsuitable ways, the proper way to do so is still to add the archive link to |archive-url=, extract the original link from it for |url= and set |url-status= so that the two links are swapped. I would typically use the keyword "dead" for it, but as others have stated already, this isn't exactly intuitive and might even be misleading at times. Adding the archived version to |url= will, in most cases, cause some bot to fix up the citation later on.

Yeah, I agree that |url-status= has a utility value for editors, that's exactly why it should have a well-defined set of non-misleading keywords to cover all practical cases, even if some of them would be handled the same by the software internally. --Matthiaspaul (talk) 13:06, 17 June 2021 (UTC)

Why should a bot mess with a perfectly good citation? Whether an archive is cited or the original is, it makes no difference as long as the wikitext is verified. There is also the issue of simplicity.

Citations have no business defining the content in any way. If the information is not there, there are other options, as shown. People should not expect a citation template, or any citation no matter how formatted, to address content issues. If it is not there, it should not be cited, period. Find another source where the information exists. Archive links are convenience links so editors won't have to reformat the entire citation if the original link (not its content) is inaccessible for any reason. In some cases though, the citation must be reformatted, rewritten, or removed. 50.74.165.202 (talk) 13:43, 17 June 2021 (UTC)

An archived copy is not a "perfectly good citation" in and of itself, since it is presumed that the archive is of a different URL which once contained reliable information. The archiving site itself isn't a source. So with that in mind, it's crucial to maintain information about what the original URL was that established the reliable website source. That is done via the URL parameter, with the archived copy linked through archive-url. The url-status then exists to tell us in what state the original URL is now, and in particular whether a user seeking the info should go to the source or the archive. I agree with the OP that having an "information no longer there" option would be good, although in terms of how the cite formats itself this will probably end up similar to "dead".  — Amakuru (talk) 13:59, 17 June 2021 (UTC)

Not so at all. Any source that verifies the wikitext is a perfectly good source for a citation. A reliable archive is a source like any other ("reliable archive" meaning one that is known to faithfully reproduce the original). It is not at all crucial to maintain information about a previous location (the "original" URL). It is necessary to include information about the location that currently verifies the wikitext (including a current URL if it exists - whether pointing to an archive or not is immaterial). Citations are not historical information, nor are they future statements. They must prove the wikitext now. If they don't, they cite nothing. 65.88.88.69 (talk) 19:37, 17 June 2021 (UTC)

@65.88.88.69: I strongly disagree with the statement that Citations are not historical information, nor are they future statements.

The role of a citation is to allow readers to verify the information cited. Part of that task is to note issues in verifiability, which is why for example with a dead link we include both the live archive link and the original dead link. That helps readers to verify the citation. I see no reason to impede that verifiability for any of the situations discussed.

I agree with Amakuru's observation that in terms of how the cite formats itself this will probably end up similar to "dead". My goal is to assist editors by providing a more explicit label to achieve that. --BrownHairedGirl (talk) • (contribs) 09:53, 20 June 2021 (UTC)

@BrownHairedGirl: quite so. A citation without evidence that the thing being cited is reliable is useless. And as much as we've made the decision to trust sites like archive.org top maintain a historical record of what a reliable source once said, the presence or absence of that original source is still a matter of profound interest. In some cases, visiting the newly-updated version of the source might provide evidence to a reader or an editor that the information cited is actually not correct any more.  — Amakuru (talk) 10:35, 20 June 2021 (UTC)

Indeed, @Amakauru. It is not hard to conceive of ways in which the archive sites could be compromised or games, or even become corrupt ... so we should facilitate those who want to conduct their own verification.

And there are many ways in which the current version of the page could be relevant, one of which is the example you give of the information being outdated. --BrownHairedGirl (talk) • (contribs) 10:42, 20 June 2021 (UTC)

Does everybody understand that the parameter in question is only an indicator about the state of the link. Nothing else belongs there, so please don't try to shoehorn extraneous stuff into it. If the verifying info is not there, a link is useless. To the reader trying to verify whatever is written in wikitext, prior or future iterations of the citation are also useless. To turn wikitext fiction into fact, a citation must (continuously) verify now. Notice that any article-space page does not carry information about previous versions of the article. If a reader cares, they can consult the history for previous iterations, including those of the citations. The source's underlying reliability is another issue, one that should be resolved prior to formatting of citations, and is a different discussion. 64.18.9.208 (talk) 12:38, 20 June 2021 (UTC)

We've discussed this one before, though I would not know what to search for. I think the correct way to cite such a case today, and I remember arguing the same then, would be simply setting to dead. The original source is effectively dead for the purposes of the citation, even if the site is still available. If you are dead set on including both that citation and information, you should add an archive URL, set to dead, add a wikitext comment about why you set to dead, and move on. The reason I add the latter two caveats is due to WP:BLP/WP:V/WP:NPOV. If the source is not independent, one should question whether it's appropriate to use that source and whether it is appropriate to include that information. If it is so important as to be clearly an NPOV piece of information, then one still needs to meet the bar associated with BLP (in this case). Izno (talk) 13:48, 17 June 2021 (UTC)

If we are going to consider additional keywords, perhaps blacklisted (or the politically correct term du jour) might be one to add. When |url= has a blacklisted url, the blacklist prevents saving of the article. To get round that, editors add an |archive-url= and either comment out, remove, or otherwise break the value in |url= so that the page will save. This gives a link to a snapshot of the source but also creates errors. |url-status=blacklisted would allow |url= to be blank (commented) or missing; Module:Citation/CS1 would not emit error messages but would emit a maintenance category.

—Trappist the monk (talk) 14:04, 17 June 2021 (UTC)

The point is that the keywords indicated in the OP are not link (URL)-related, so they are outside the scope of a URL's status. "Blacklisted" passes the test, per your discussion fork above. In general and as you know, citations point to sources, they don't make statements about their content. That can be a subject of a footnote (if necessary) perhaps with its own citation track. 65.88.88.69 (talk) 19:55, 17 June 2021 (UTC)

@65.88.88.69: I strongly disagree. "URl no longer contains the cited information which it previously contained" (or some short form thereof) is very much a matter of the URI's s status.

Citations do indeed point to sources, and part of that task is to note issues wrt verifiability. --BrownHairedGirl (talk) • (contribs) 09:44, 20 June 2021 (UTC)

URIs are identifiers. They make no statements regarding the item they identify. Either the identification is correct (item exists) or is not. Let's not try to redefine a URI's function. It seems that there is a confusion regarding verifiability. Citations that resolve to existing sources by definition explicitly verify whatever is claimed in wikitext. If they don't, they are invalid, and should be removed. The reasons for the invalidation are not pertinent; the reader wants to see a valid citation, not explanations of why a citation is not currently valid. As was said earlier, if editors want to keep the wikitext they should find another source. 64.18.9.209 (talk) 13:10, 20 June 2021 (UTC)

Replacing "--" by "–"...

Hi, this is a followup to a recent but meanwhile archived discussion at Help talk:Citation_Style_1/Archive_75#Issue_with_{{{issue}}}, which was about converting double-hyphens and triple-hyphens in page ranges to en dashes and em dashes.

I originally implemented that on 2020-11-17 based on some suggestion that double-hyphens could occur in BibTeX entries and thereby could end up here as well occasionally. Unfortunately, I introduced a bug into the code trashing stripmarkers ("never do any last-minute changes after having already tested the code..." ;-) and because I could not locate the original discussion any more, it was removed rather than fixed. Well, I still haven't found the original discussion, so it probably wasn't here, but I just ran into a site (by renowned Nelson H. F. Beebe) excessively (hundreds) using double-hyphens in BibTeX citations, so I thought I would drop a link here just for reference:

http://ftp.math.utah.edu/pub/tex/bib/bstj1930.html

Since we are doing all kinds of plausibility checks and also some on-the-fly conversions (including with pages and page ranges), I still think we should cover this case. After all, a double-hyphen in a page range can never be part of the page designation itself and the only reasonable interpretation is as an endash in a page range. The alternative to just silently converting them to improve our display and make our metadata output more consistent would be to throw a maintenance message, but this would require more code. --Matthiaspaul (talk) 12:46, 17 June 2021 (UTC)

Searches:

-- 25 (times out)

--- none

—Trappist the monk (talk) 12:59, 17 June 2021 (UTC)

Not sure why you escaped the dashes, but I can get to 36 with timeout.

I do not see a need for this change. There are sufficiently few and clearly not many being introduced that the interested user can just work from a search. Izno (talk) 13:51, 17 June 2021 (UTC)

In fact, I can refine this to

• pages 32 timeout,
• pp 11,
• page 4 timeout

Still don't think we need it. Izno (talk) 14:23, 17 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)

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)

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

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)