This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

{{ Cite AV media notes}} uses |others= for the artist, and liner notes often do not have a credited author. Here's an example of the template used with |others= and without |last=/|first=:

Should we suppress this maint message for {{ Cite AV media notes}}? – Jonesey95 ( talk) 07:31, 2 May 2019 (UTC)

I guess the first question that I have is: Should |others= be used in this way? The documentation for |others= at {{ cite AV media notes}} reads:

• others: To record other contributors to the work, including illustrators. For the parameter value, write Illustrated by John Smith.

In this case the work is the media notes. Did Gaga and Cooper contribute to the media notes in a substantive way? If they did, then they should be listed as authors. If not, and the media notes are the work of an anonymous PR person at Interscope Records, then Gaga and Cooper should be omitted from the citation. If we don't know who created the media notes, we should not guess. When we cite a magazine article about a concert given by Gaga and Cooper, we don't include them in the {{ cite magazine}} template; why do it in {{cite AV media notes}}?

— Trappist the monk ( talk) 13:40, 2 May 2019 (UTC)

I am open to a different usage. The template's custom documentation, under "Brief instructions", indicates that |others= should be used for "Artist, producers, etc."

It does seem strange to me, however, not to cite the artist for media notes, primarily as a way of helping the reader find the right source. For example, if I were citing the liner notes for a CD or LP whose formal title was "Symphony Number 3" or "Violin Concerto No. 1", I would want some way of giving more information about the composer or performer in order to guide the reader to notes for the right recording. I suppose the year and the label are potential disambiguators, but it is a lot easier on the reader to indicate that the recording was of a Beethoven concerto performed by the London Philharmonic. I don't know the right answer, but one primary purpose of citations is to help the reader find the original source. – Jonesey95 ( talk) 14:18, 2 May 2019 (UTC)

I agree that the documentation for {{ cite AV media notes}} says what it says. I wonder if those recommendations are correct and proper. The definition of |others= says nothing about disambiguation. The use of |others=Lady Gaga and Bradley Cooper suggests that Gaga and Cooper contributed to the media notes. Sure, they contributed to the media and I would be very surprised if their names did not appear on the media notes's cover so were I citing media notes I would probably use the words on the front cover of the notes for the citation's title. Just reaching into my box of CDs, here is Close to the Bone by Old Blind Dogs. Because the cover of the media notes reads, top to bottom:

Old Blind Dogs

Close to the bone

I might write something like:

{{cite AV media notes |title=Old Blind Dogs: Close to the Bone |year=1993 |publisher=Lochshore}}

Old Blind Dogs: Close to the Bone (Media notes). Lochshore. 1993.

I have a fair collection of classical recordings and don't know that I've ever seen one that doesn't have the composer and performers listed on the cover.

I suspect that there is a WikiProject that cares about these kinds of citations. Perhaps they should be invited into this conversation?

— Trappist the monk ( talk) 15:25, 2 May 2019 (UTC)

I concur with Trappist on this (in his first post above; I don't have an opinion on what is most common on classical CD covers, or whether a wikiproject will have something to say about the OP's question). There appear to be conflicting instructions at one page, to use |others= for "Artist, producers, etc.", without qualification and clarification as is found in other documentation about this parameter (i.e. suggesting, sensibly, that this parameter is not used in lieu of author parameters, but is an additional parameter for, well, others). This actually brings up something I was just about to try to address here, anyway, and will do so in a thread below: the problem of increased forking of the citation template docs.  —  SMcCandlish ☏ ¢ 😼  12:00, 3 May 2019 (UTC)

About |date=n.d. (I think |date=nd also works), can we please get this changed to report "undated" or perhaps "no date" instead of regurgitating the literal string "n.d."? It's a MOS:ABBR problem, in that it has no <abbr>...</abbr> markup nor a wikilink, and is ambiguous at best and just a meaningless two-letter acronym to the average reader. Would also be nice if it accepted "undated" as input.  —  SMcCandlish ☏ ¢ 😼  21:07, 3 May 2019 (UTC)

The first mention of n.d. I think occurs in this conversation. There was some talk about undated in this discussion.

— Trappist the monk ( talk) 00:24, 4 May 2019 (UTC)

Are templates like Template:Vcite2 journal and Module:ParseVauthors still necessary now that Module:Citation/CS1 natively supports a |vauthors= parameter? * Pppery * _{has returned} 23:25, 25 April 2019 (UTC)

I would say that these are no longer needed but you should ask Editor Boghog whose projects those were.

— Trappist the monk ( talk) 23:30, 25 April 2019 (UTC)

I also agree that the template is no longer needed, but at the same time, I would like to preserve the rationale for the |vauthors= parameter. Any suggestions for how to do this? Boghog ( talk) 17:48, 26 April 2019 (UTC)

As a subsection of Help:Citation Style 1#Authors?

— Trappist the monk ( talk) 17:55, 26 April 2019 (UTC)

I would honestly prefer not to keep that rationale around on official documentation. Vauthors is really more of a hack to get medical Wikipedia authors on board; we'd prefer full names using |first= and |last= (and name author format parameter as desired) to allow reusers to pick whatever citation method they prefer, and having full names in the metadata/wikitext is the only way to do so. The "there's too many in the wikitext" was never a reasonable argument for me, and especially shouldn't be now given LDR (which can see mixed use in rarer cases where there are e.g. 50 authors). -- Izno ( talk) 18:54, 26 April 2019 (UTC)

The vast majority of the citations that use |vauthors= are also stored in the PubMed database. Wikipedia is not a reliable source for citation data as it frequently contains errors. It is much more reliable to down load citation data from PubMed and there are many convenient tools for doing so. Why is it necessary to store full first names in Wikipedia when it can easily (and more reliably) be obtained from PubMed if needed? Also many don't like LDR as it splits up the text from the sources that support the text.

|vauthors= is not a hack, but a very efficient way to store author data that reduces wiki text clutter. It also enforces consistency in how first names are displayed. Boghog ( talk) 07:11, 27 April 2019 (UTC)

How first names (or any part of the names) are displayed is one thing (and I can accept that being editor optionable); storing the author metadata is different. I'm with Izno on this: full names, properly parsed ("last" name on which collation is done, and the rest as "first" name), should be standard.

I don't see how |vauthors= is "a very efficient way to store author data that reduces wiki text clutter." The "efficiency" of typing a few less characters is fairly insignificant in the broader context, and questionable in view of the loss of information. And wikitext clutter can be greatly reduced by not putting full citations into the text. (LDR is not the only alternative.) ♦  J. Johnson (JJ) ( talk) 20:05, 27 April 2019 (UTC)

Fewer characters is more efficient. Furthermore, if you are not going to display full first names, why store them? The implication is that you might want to reuse the citations elsewhere and display full first names. However Wikipedia is not a reliable source for citation data. Better to copy the |pmid= and download the data from PubMed using one of the many tools available tools for this purpose. If we ever switch to a system where citations are retrieved from Wikidata, and if a particular citation is also stored in a reliable database such as PubMed, the data will be harvested from PubMed, not Wikipedia. Other alternatives such as WP:HARV are complex to set up and maintain. Harvard might make sense sense when a few sources are cited many times, but much less sense when most sources are cited only once. Boghog ( talk) 04:00, 28 April 2019 (UTC)

Vcite format is very annoying when one is trying to determine which references by people named RS Smith are actually relevant for an article on Ruth S. Smith (who should probably have an article, by the way). Putting the longer author name into the template parameters and hiding it because reasons is at least better than not having it there at all. And the "efficiency" of typing fewer characters is bogus: you should be getting the bib data from a database of some sort, not typing it all again by hand, or else you're going to introduce lots of mistakes. — David Eppstein ( talk) 04:51, 28 April 2019 (UTC)

|vauthors= is mainly used for biomedical citations indexed by PubMed. One probably would not be using |vauthors= with an author like Ruth S. Smith who is a librarian. |first= doesn't necessarily make it any easier finding an author since there are few restrictions on what is stored there. Wtih |vauthors=, the author format is at least consistent. Finally the efficiency has nothing to do with the number of characters typed. Of course, one would download the sources from a database like PubMed using ref tool bar, citoid, or similar tool. The efficiency has to do with the number of characters stored in the raw wiki text. Boghog ( talk) 05:52, 28 April 2019 (UTC)

I'm not certain that the librarian Ruth S Smith is the same as the heavily-cited academic author Ruth S Smith, but that's not important. If I search Wikipedia for "Smith Ruth" or "Ruth S. Smith" or "Ruth Smith" I will probably find all of the instances that are the ones I'm looking for, and only a few off-topic hits. If I search for "Smith RS" who knows how many irrelevant things will turn up instead. And number of characters stored??? Are you out of your mind, or merely innumerate? The number of characters we're spending on this discussion alone probably outranks all the bytes you've supposedly saved in all of the articles you've written. And a single image file would be many times that. Maybe you need to go read WP:NOTPAPER again. — David Eppstein ( talk) 06:33, 28 April 2019 (UTC)

Searching for authors with a common name such as Smith is not trivial, even when the full first name is included. A search for "Ruth Smith"~2 (proximity search allowing up to two words in between, order of words unimportant) returns 299 hits, a large majority of which are off-topic. A search for Smith RS, may not find what you are looking for either, but at least the list of hits that one must wade through is much shorter. The issue with efficiency is not the storage of characters, but rather trying to edit raw wiki text which is imbedded with bloated citation templates that make it more difficult to find the text you are trying to edit. WP:NOTPAPER also states there is an important distinction between what can be done, and what should be done. Boghog ( talk) 07:38, 28 April 2019 (UTC)

I suspect that all of this back and forth over the good and bad of Vancouver-style is somewhat pointless. Yeah, in Candide's best of all possible worlds, all cs1|2 authors would be in |firstn= / |lastn= but, alas, that ideal world is not this world. I've just made an awb pass through 25k of the 30k articles that populate Category:CS1 maint: Multiple names: authors list. I was plucking off the low hanging fruit, some of which was conversion of Vancouver-style name-list assignments in |author=, |authors=, and |last= to |vauthors=.

Editors at en.wiki will write Vancouver-style name-lists so it seems prudent to me to acknowledge that, stop squabbling, document the advantages and the disadvantages in a common place, and then get on with life.

— Trappist the monk ( talk) 18:39, 28 April 2019 (UTC)

Agree. Now, back to my original point; it is clear than these templates are not needed, shall I list them at TfD? * Pppery * _{has returned} 19:13, 28 April 2019 (UTC)

I don't see why not. Editor Boghog did agree that the template and module are no longer needed and can copy off the rationale to someplace and someone else can put the counter-rationale. Instances of {{ vcite2 journal}} need to be renamed to {{ cite journal}}.

— Trappist the monk ( talk) 19:32, 28 April 2019 (UTC)

And TfD started. * Pppery * _{has returned} 19:48, 28 April 2019 (UTC)

Efficiency is always a proportion. Simply typing "fewer characters" at the outset is not "more efficient", because here it is also less information. It is arguable that the decrease of typing effort is less than the decrease of information, and therefore vcite style is less efficient (more effort relative to the information). And this is without factoring in any additional effort required further on. If people want vcite style, fine, but "more efficient" is a poor reason for doing so. ♦  J. Johnson (JJ) ( talk) 19:54, 28 April 2019 (UTC)

Repeating what I wrote above, the reason is not to reduce typing. The reason is to reduce the size of bloated citation templates in the raw wiki text that make it more difficult to find text you are trying to edit. We will have to agree to disagree on the necessity of storing full first names. Time to move on. Boghog ( talk) 01:16, 29 April 2019 (UTC)

If this bothers you, you could move the inline citations into the references block, so that the text in the article body becomes readable at source-code level again and the references can be easily maintained independent of the article body.

I hate it when I run into truncated or incomplete references. Wikipedia is WP:NOTPAPER...

People claiming "efficiency" often overlook that their efficiency often creates inconveniences or extra work for others...

-- Matthiaspaul ( talk) 18:51, 30 April 2019 (UTC)

Within the scope of Vancouver style citation format (a widely used style in biomedical journals) there is no truncation of information. The citation is complete. There is no need to add the full first name of the authors. In fact, doing so to an article where the Vancouver style authors has already been established would be a violation of WP:CITEVAR. Please note that citevar covers both how the citation is rendered as well as how the citation data is stored. Boghog ( talk) 14:51, 1 May 2019 (UTC)

My remark was meant more generally, also regarding the habit of some to abbreviate journal names etc. Only providing an abbreviated first name may be allowed by the style guide but it is nevertheless backwards-oriented in an electronic encyclopedia on a planet with close to 8 billion humans and information travelling around the globe in seconds. Just like short passwords can be cracked in fractions of a second, abbreviated names are just no longer cutting it when it comes to reliably identifying an author. Ambiguity hinders interested readers when they try to find out more about an author and/or the topic. It is nice to emulate external style guides, but we are Wikipedia and moving forward we should not be shy to define our own rules if they serve our purposes better. -- Matthiaspaul ( talk) 20:54, 3 May 2019 (UTC)

If you are replying to me, as it appears by where you chose to place your comment, then you are arguing with the wrong person. I have made no comments at all regarding efficiency in this discussion.

— Trappist the monk ( talk) 20:39, 28 April 2019 (UTC)

Yes, and sorry; my comment could have been indented better. My comment was regarding Boghog's "efficiency" argument. To which he responds that his point is not efficiency in typing, but clutter in the wikitext. And there I will agree that full citations in the text obscure the text. But the answer to that is not to make some very minimal reduction in the length of the full citation, but to move all full citations to their own section. The problem doing that is it requires the use of short-cites of some form, such as done with Harv templates, which is anathema to some editors. So I would say (in response to Pppery's query) that |vauthors= is not necessary, except as a slight (very slight, and even misguided) accommodation to the sensibilities of some editors. Mind, I am not necessarily against such accommodations, but we should be clear on why we do so. ♦  J. Johnson (JJ) ( talk) 19:59, 29 April 2019 (UTC)

I was not asking whether |vauthors= was necessary, only whether it was necessary to have special templates for it when the main template already supported it. * Pppery * _{has returned} 20:03, 29 April 2019 (UTC)

Indeed. And then the discussion slid into the rationale for the vauthors parameter. ♦  J. Johnson (JJ) ( talk) 21:14, 29 April 2019 (UTC)

I agree that the separate templates are not necessary, and concur strongly with Izno ("vauthors is really more of a hack to get medical Wikipedia authors on board; we'd prefer full names using |first= and |last="). If Boghog's point is de-hyperbolized, it is correct that WP:CITEVAR permits use of Vancouver or any other citation style, and that changing the style at an article with an established and consistent citation style is discouraged, without a consensus discussion first. (CITEVAR is often misinterpreted as a "once a style it set, it cannot be changed rule", and is nothing of the sort; worse, it's even misconstrued as a "whoever set the style in the first major edit has more say in how the article should develop, moving forward" rule, which is just flatly against WP:OWN] and WP:EDITING policies). However, this doesn't mean we need stand-alone templates for Vancouver citation formatting, or even that CS1/CS2 should support any parameters relating to that citation style, though I don't think there's any real harm in the latter.

I'm honestly skeptical of the underlying rationale, though. It simply cannot be true that medical academics and other professions will quit Wikipedia in a huff if we do not bend over backwards to make it easy to use a citation style some of them prefer (actually, mostly Americans, and in particular fields), or even allow it at all. These people are entirely accustomed to either conforming to the house style sheets of the publications they submit papers to, or having it conformed for them. As a long-term test, I've been normalizing Vanc. author names to |last=|first= and compliant with MOS:INITIALS every time I have some time to spare and I encounter an article with Vanc. cites that are not used consistently; in about 5 years of this, I've been reverted a grand total of twice. (I got the change to stick in one of those cases by pointing out that article wasn't consistently using the style and did not have that style in its first non-stub version; in the other I conceded because that article did originate with Vanc. style, and the non-consistent cites in the page were recent additions.) So, the idea that if you change Vanc. cites to typical WP ones all Hell is going to break loose is patently false.

Anyway, no one is forced to use these templates, and a CITEVAR "universal permissiveness" about Vanc. and all other cite styles doesn't translate to required work on the WP:CS1 end; any doctor or lab researcher can insert Vanc.-style cites all they want, manually. We shouldn't be providing tools that make it easy to use confusingly divergent cite styles; WP is for readers, not for writers, much less writers with particular field-specific style manuals on their desks.
 —  SMcCandlish ☏ ¢ 😼  21:00, 3 May 2019 (UTC)

But you have not stated why it is necessary to include first full names. we'd prefer is not a reason. The pros and cons have discussed ad nauseam above. Divergent styles, as long as they are documented is not confusing. The Vancouver system is not primarily American. It was established by the International Committee of Medical Journal Editors (ICMJE). Time to move on. Boghog ( talk) 06:33, 4 May 2019 (UTC)

This edit request to Module:Citation/CS1/Configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Bibcode access on the http://adsabs.harvard.edu/abs/ site is now complaining about oncoming deprecation.

• Change the bibcode prefix from http://adsabs.harvard.edu/abs to https://ui.adsabs.harvard.edu/abs Artoria 2e5 🌉 02:04, 5 May 2019 (UTC)

  We are aware of this upcoming change and have made the sandbox work correctly. See the above discussion. -- Izno ( talk) 02:51, 5 May 2019 (UTC)

A minor change, but possibly worth a discussion: I have updated two error category names and many maintenance category names to make the capitalization of the category names consistent. These changes would go into effect with the next module update, and existing categories would need to be renamed or moved (or just deleted and recreated, whatever makes the most sense). – Jonesey95 ( talk) 08:06, 2 May 2019 (UTC)

The category links in Help:CS1 errors will need to be revised.

— Trappist the monk ( talk) 11:24, 3 May 2019 (UTC)

Since we're considering doing this, we should consider also extending Category:CS1 maint names to Category:CS1 maintenance names e.g. 'CS1 maint: ignored ISBN errors' -> 'CS1 maintenance: ignored ISBN errors'. -- Izno ( talk) 13:13, 5 May 2019 (UTC)

Right now, |subscription= and |registration= cause categorization of pages; see in Module:Citation/CS1/Configuration:

	'subscription' = '<span class="cs1-subscription">(Subscription required (<span title="The site requires a paid subscription to access this page.">help</span>))</span>' ..
		'[[Category:Pages containing links to subscription-only content]]',
	
	'registration'='<span class="cs1-registration">(Registration required (<span title="The site requires registration to access this page.">help</span>))</span>' ..
		'[[Category:Pages with login required references or sources]]',

Do we want to do the same with the Access parameters? I did not see anywhere that this categorization occurs. -- Izno ( talk) 13:18, 5 May 2019 (UTC)

I don't know. But, if we do, they should be properties cats that are distinct from Category:Pages with login required references or sources (shared with {{ registration required}}) and Category:Pages containing links to subscription-only content (shared with {{ subscription required}}). Perhaps Category:CS1 sources limiting access, Category:CS1 sources requiring registration, and Category:CS1 sources requiring subscription.

— Trappist the monk ( talk) 13:56, 5 May 2019 (UTC)

There is increasing inconsistency between the various loci of our cite template documentation. In some cases (e.g. for |year=) various pages have been long out of step with each other. We have too much of it separately maintained (and often basically unmaintained) in too many places, like Help:CS1, Help:CS1 errors, Template:Citation Style documentation, and each template's documentation page, and probably other places, too. Some of these are pulling the same documentation via transclusion, which is a good thing, while others are separate documentation, which is increasingly WP:CFIing in confusing and unhelpful ways. E.g., the discrepancy in the treatment of |year= at these pages (I think I managed to resolve that today) is almost certainly the primary proximal cause of editors continuing to use |year=YYYY despite its deprecation (except in one very, very specific circumstance) in favor of |date=YYYY half a decade ago at a least. (Another cause is tools that have not been updated and which are hard-coded to use |year=. Sometimes authors of these tools are surprisingly stubborn in refusing to update their code to comply with current WP:CS1 documentation, or WP:MOS changes, or anything else, which I think is a form of WP:BOTPOL failure, though I would try discussion/persuasion several more times before making some kind of dramaboard issue out of it.)

There are more such "documentation forks" (I think WP:CFI needs another section for that concept), and I hadn't even noticed the one reported here a few threads above, where |others= is mis-documented at one page as just being for "authors, producers, etc." without any qualification, while another more accurately describes this as an adjunct to other biographical parameters, not a replacement for them, but for additional parties that don't fit into an author, editor, translator, or other specific bio parameter.

Maybe we need some kind of "map" of all the documentation, from which we can figure out how to transclude more and separately [fail-to-]maintain less.
 —  SMcCandlish ☏ ¢ 😼  12:14, 3 May 2019 (UTC)

In the time that I have been participating in this project, there have been many and many a complaint about the quality of the cs1|2 documentation. When I ask those complainers if they know how to make the documentation better to please do so, almost invariably, I am met with silence. We need a champion, a St George to go out and slay the documentation dragon. Are you our champion?

— Trappist the monk ( talk) 13:41, 3 May 2019 (UTC)

In part, in theory. I have the will, but my WP time is more constrained than it once was, and the thread just above this indicates that there are some gaps in my relevant knowledge. The purpose of my opening this thread wasn't to complain, but to outline the nature of the problem and see about jointly coming up with a "roadmap" for resolving it. It likely isn't an issue that needs a single champeen.  —  SMcCandlish ☏ ¢ 😼  19:28, 3 May 2019 (UTC)

Trappist, that argument at best misses the point. Your work is very much appreciated, you've helped me personally a lot, but when editors complain that the documentation is in adequate, it's because they tried to do something that didn't work because it's not written. The editor changing the code should update the documentation right after to reflect how the template works. Asking other editors who know only part of the code to go and update it should not be how any template works and will never work and will always be met with silence. -- Gonnym ( talk) 22:16, 3 May 2019 (UTC)

I get your point, but you know that the absolute worst of all possible documentation is that which was written by the developer. Why? Because the developer knows what it does so writes incomplete, insufficiently detailed, overly detailed in the wrong areas, ... This is why there are technical writers who have editors overseeing what it is that they write. That isn't perfect either but its a damn sight better that the stuff that developers churn out.

I am more than willing to assist when necessary in the improvement of the cs1|2 documentation but I should not be the author because I am too close to the code. There is a ton of documentation in the code, and every new thing that I have added to the module suite since I started working on it has been discussed here, usually with examples, so there is a lot of raw material for writers to harvest.

— Trappist the monk ( talk) 00:45, 4 May 2019 (UTC)

One obvious (to me at least) thing that should be done is to cleanup Help:Citation Style 1. For the most part, it seems a page without a purpose. It transcludes some documentation from Template:csdoc ( § Identifiers), includes what appears to copies some of the csdoc text (§ Registration or subscription required is more-or-less a text copy derived from this (or similar) version of the 'official' csdoc documentation), and has other documentation not in csdoc (the three subsections of § Dates for example). Should this help page be a clone of csdoc or should it hold explanatory text that expands upon the documentation in csdoc? Should it be something else?

— Trappist the monk ( talk) 16:05, 5 May 2019 (UTC)

I've tweaked Module:Citation/CS1/sandbox so that the error messages emitted when something is not right with the |xxx-url-access= parameters, show the name of the actual parameters involved:

and aliasing still works:

— Trappist the monk ( talk) 18:06, 5 May 2019 (UTC)

SMcCandlish imperfectly replaced "website" with "work"? I still think "website" should be the correct name of the field as this is cite web, not cite news. But because of his edit, now whenever I edit a ref via ProveIt or add a new one via the citations toolbar, the field "website" is treated as a separate field from work (whereas they were previously one). Can someone please now merge these two fields perfectly? -- Kailash29792 (talk) 09:43, 3 May 2019 (UTC)

If you are going to mention an editor by name, courtesy requires you to ping that editor. Because you didn't, I shall: pinging SMcCandlish.

I think that I have restored the canonical form |website= with this edit. I don't use ProveIt or ve so someone else will have to test that change.

— Trappist the monk ( talk) 11:23, 3 May 2019 (UTC)

So what is the actual technical issue here? How is updating the template documentation having any affect on some external tool? I think by now most of us have noticed that editors are leaning increasingly toward using |work= instead of the custom aliases it has at various templates (|website=, |journal=, |magazine=, |newspaper=, etc.), for consistency, concision, ease of conversion between templates, and so on. We should be able to update the template docs to display (and thus encourage) use of |work=, and to mention the variant aliases only in passing, as legacy options. Having a tool like ProveIt treat |work= and |website= as separate things was the diametric opposite of the intended and expected results (and frankly seems like really bizarre behavior on the part of that tool – a problem to fix on that end).  —  SMcCandlish ☏ ¢ 😼  11:45, 3 May 2019 (UTC)

Unfortunately, TemplateData is bad idea. It attempts to combine the function of tool control (ve primarily, though, no doubt, other lesser lights) with the function of template documentation. I don't know how well TemplateData performs as tool control, but it sucks when it comes to template documentation. Because the two functions are intertwined in some inexplicable ways, changing the 'documentation' can, as OP notes, have detrimental side effects.

I think by now most of us have noticed ... You know, whenever I hear or read anything that remotely sounds like "I'm sure that we can all agree ...", that is when I start to think: "no, we do not all agree ..."; it's the contrarian in me. So, I tried a couple of simple searches.

There are, at present, ~318k articles using {{ cite web}} templates. I did two searches looking for {{cite web}} using:

|website= ~120k articles (timed out)

|work= ~128k articles (timed out)

Because both searches timed out, results are wholly unreliable and inconclusive. To get an accurate measure of |website= v. |work= in {{cite web}} perhaps we need someone who can hunt through a recent database dump or we need to modify the cs1|2 modules to add properties cats for {{cite web}}. I suppose that we ought to also include the other periodical aliases (|journal=, |newspaper=, |magazine=, |periodical=, |encyclopedia=, |encyclopaedia=, |dictionary=, |mailinglist=) and perhaps create maintenance cats for those. This (timed out) search for |newspaper= in {{cite web}} found ~8k articles.

— Trappist the monk ( talk) 13:30, 3 May 2019 (UTC)

A lot to cover, so this will be a bit long. TemplateData: I thought that was being migrated to WikiData anyway. I did understand that it could be used for tool configuration/control, but it's still strange to me that inverting the relationship between |website= and |work= had the exact effect that was reported above. My intent was certainly not to fork these parameters into separate entities, much less necessitate the creation of redundant categories!

I understand your "contrarian me" reaction, but I'm not making an "everyone agrees" point. On WP it's never true that everyone agrees on anything! Ha ha. Rather, I'm observing a trend and trusting that others have been observant enough to pick it up as well. I've been okay for years with the templates being documented as having parameters like |website= and |newspaper=, and barely mentioning |work=; I really didn't care much.

But some of what I've noticing more and more over about the last three years are the following: There's been a sharp increase in constructions like {{ cite news|work=Foo News|...}} and {{ cite web|work=The BarBaz Blog|...}}. If you convert an entire article to use the consistent and concise construction, virtually never will anyone will revert you (probably only at an obscure-topic WP:FA that has an effective WP:OWNer), because the change is generally seen as an improvement; but if you go the opposite direction, replacing |work= with things like |website= and |magazine=, a revert is much more likely, as WP:MEATBOT-style change that is not helpful in any way to anyone. People actually complain about |website=, etc., and label them pointless, confusing, and so on (I ran into that again just yesterday as part of the perennially recycling argument about italicization of work names when the source is electronic; the forcefulness of the complaints about the different and longer-named parameter aliases (e.g. "|work= or one of its pointless aliases (website, newspaper, etc)" – from someone who's actually on the opposite side from me on the matter actually under discussion over there) was what inspired me to look into normalizing toward |work=. I picked a single template to do this with as a test run, and it's interesting that no one objected about the substance/intent of the change, only the unexpected effect it had on one tool, from the TemplateData part of that edit. A major source of misuse of parameters (especially work titles in |publisher= and |via=) is confusion about which parameter is for what; the more differently named parameters there are, the harder it is for people to make sense of them and memorize them. The trend toward |work= is natural for more generalized reasons, too, familiar to those who spend a lot of time in discussions at WP:P&G pages and in WP:TFD: concision is generally a virtue, and consistency almost always is one in such matters. WP:CREEP is a problem, whether it's happening in P&G pages or template documentation; instructions are instructions, and the more we have and the more variant they are, the harder it is to become an editor and remain one who knows how things work and should work. For many years we've been increasingly normalizing similar templates to have identical parameters (for editor sanity, for codebase sharing, and for direct merger of redundant templates). So, I'm in no way surprised at the favoring of |work= over time.

Part of my "job" as a P&G editor, a TemplateEditor, a PageMover, and a gnome in general is to normalize how stuff works to match what the community is doing/expects, what the operational consensus is, whether people have had fighty RfCs about it or not. I'm actually pretty good at this; given the large amount of that work I do, quite boldly, I would have been topic-banned from such activities, or just indeffed, long ago if I were technically incompetent at it, were just implementing my own or some WP:FACTION's preferences, or were simply terrible at gauging what the ground-truth consensus is.

Anyway, yeah, I would expect searches like the ones you did to time out, because there are millions of instances. I don't think such stats would be useful even if they could be gathered, because of legacy use and other skew. They'd only be informative if they could be gathered completely and compared at least as granularly as month to month. Even then, there's the fait accompli bias that most of the templates' documentation encourages the use of the variant, long-winded parameter aliases. And we'd need some way to exclude results from tools hard-coded to use particular parameter names. However, the fact that the results you were able to get out of the searches, before the timeout, showed |work= with a marginal lead anyway despite being virtually hidden in the documentation is telling.
 —  SMcCandlish ☏ ¢ 😼  20:33, 3 May 2019 (UTC)

I have not noticed whether or not editors are currently using |work= more than |website= – but then I just don't pay much attention to that kind of stuff. I had thought that if the searches returned something useful that would be a simple way to gauge a trend if one exists by taking an initial sample now and over the next some-number of months take additional samples. This same can be accomplished by creating properties cats (relatively easy to do I think), or by hunting through database dumps (more difficult according to Editor GreenC).

After |website= was added to Module:Citation/CS1/Whitelist ( this edit 9 April 2013) we went through a spate of confusion, anger, ... (pic your emotion). Since then, there has been little or no discussion here about |work= being preferred over |website=. Much of that previous discussion was about either of these parameters rendering in italics.

The original rational for |website= in the cs1|2 module suite seems to have arisen from this feature request. I didn't find discussion that necessarily supports that particular feature request but there is this and a long section of a much longer section (you rose in opposition in that latter conversation).

— Trappist the monk ( talk) 23:41, 3 May 2019 (UTC)

I'm not sure reviewing that old history is useful today (and I eventually, even on that page, was convinced to "support adding |website= as, and only as, synonymous with |work=". It's not a issue of whether |website= exists, but of whether we "advertise" the consistent parameter or the divergent ones more. And, secondarily, what needs to be done to favor |work= without breaking a tool and causing it to treat them as separate parameters rather than one parameter with a |website= alias.  —  SMcCandlish ☏ ¢ 😼  09:11, 4 May 2019 (UTC)

For me, because I would not favor |work= over any of the 'periodical' parameters (|journal=, |magazine=, |newspaper=) in their respective cs1 templates and {{ citation}}, so I would not favor |work= over |website= in {{ cite web}} or {{citation}}. The periodicals that I read or refer to in everyday conversation are journals, magazines, newspapers; these are the common English terms for those things. I don't think that I've ever referred to a magazine or newspaper as a work except here in the context of these templates. When I visit some website, I'm visiting a website, not a work. Yeah, all of these things are 'works' but that is a jargon-ish term that I think is useful as a fall-back in certain cases (media other than newspapers in {{ cite news}} for example).

en.wiki prefers commonly recognizable names for article titles and other things, why should these templates counter that preference by preferring jargon over a common name for parameters that it uses?

— Trappist the monk ( talk) 12:04, 4 May 2019 (UTC)

Just a question of complexity having to remember different argument names for use in different citation templates - once you remember "work" it should universally work. It's easier to remember one argument name, work is intuitive. Not everyone will agree with that there are arguments both ways. Ultimately I put more emphasis on reduction of complexity because it is an existential threat to the project, putting a damper on attracting new users and burning out old over the long run - a small forcing to be sure but something that is controllabe. -- Green C 12:58, 4 May 2019 (UTC)

Using the name of a thing as it is named in common, every day, English language adds unacceptable complexity? I have a hard time wrapping my poor little brain around that. Complexity for whom? I have been trained throughout my lifetime to think of a magazine as a magazine, a newspaper as a newspaper, a website as a website. Learning that such things lump to the term 'work' was a new concept to me when I first came to Wikipedia. I would not be surprised to learn that most new editors experience something similar. If we promote |work= as the primary parameter name for {{ cite web}} and the periodical cs1 templates, then, were I again a novice, I would have to look that up to see how to use that parameter. If I were a newby and citing a journal or a website, I suspect that I'd catch-on more quickly with parameter names that reflect the thing that I'm actually citing.

Existential threat? Can you point us to research that shows that template complexity – more to the point, cs1|2 complexity – has detrimentally effected new-editor attraction and older editor retention?

— Trappist the monk ( talk) 14:59, 4 May 2019 (UTC)

It's easier to remember 1 thing, learned one time, then to remember 5 different ways depending on context. This is evident, most people default to 2 or 3 cite templates most of the time, mostly cite web, rather than learn the family of cite templates and their argument names. The issue of complexity and retention was probably studied during development of VE since it was supposed to make Wikipedia more accessible to non-technical users, this was a major push, and I expect they did so because of feedback. I wouldn't take it personally that CS1|2 is somehow at fault, it's better than any alternative, but it's part of the larger picture of increasing complexity across Wikimedia. This problem is not even unique to Wikimedia, Windows and Apple were supposed to hide OS complexity so that more people could use computers. I am a unix command-line person, but also recognize most people are not that vested. -- Green C 01:04, 5 May 2019 (UTC)

Sure, learning one new thing instead of five new things might be easier. But since I already know the five things, learning an un-intuitive new thing that overrides the five intuitive things is to me adding complexity. I don't imagine that new editors sit down and read the cs1|2 template docs. If they muddle their way into the ve add-a-template editor and type cit into the add-a-template text box, ve will offer them a handful of templates. For me it offers:

{{ citation}}, {{ cite}}, {{ cite web}}, {{ cite book}}, {{ cite news}}, {{ cite journal}}, {{ cite av media}}, {{ cite episode}}, {{ cite encyclopedia}}, {{ cite av media notes}}, {{ cite press release}}

If they use the wikisource editor, then they are offered:

{{cite web}}, {{cite news}}, {{cite book}}, {{cite journal}}

I haven't tried the hybrid editor so I don't know what editors are offered there. I suspect that these offered-subsets of the cs1|2 templates account for the preponderance of citation templates that editors use simply because these are the templates offered and because {{cite web}}, {{cite news}}, {{cite book}}, {{cite journal}} answer the majority of editors's citation needs.

— Trappist the monk ( talk) 12:27, 5 May 2019 (UTC)

Sounds like when I worked in the IT dept of a large company about 20 years ago, and they brought in a bunch of kids straight out of University to write the Next Big Project. They were all talking about methods, actors and broadcasting to such an extent I wondered if they all came from drama school, instead of (as they claimed) a decent computer science faculty. The new software never did work, and was abandoned after three wasted years. No, magazines are magazines and I have something like 900 back numbers of The Railway Magazine to show that. -- Redrose64 🌹 ( talk) 00:01, 5 May 2019 (UTC)

There is one example I can think of where |website= and |work= would be useful as seperate parameters. Fossilworks is a website that uses the Palaeontogy Database (the work?), which also can be accessed from its own website. This is usually handled |publisher= parameter for one of them, which doesn't seem right.    Jts1882 |  talk  13:09, 4 May 2019 (UTC)

You don't offer any specific examples here but an insource: search for "Palaeontogy Database" did not find that string in use in article space. Perhaps you meant ' Paleobiology Database'? There are about 7k hits for that. A similar insource: search for Fossilworks also found about 7k hits. If the url is pointing to fossilworks.org then |website=Fossilworks is appropriate; if to paleobiodb.org then |website=The Paleobiology Database is appropriate. We shouldn't astonish readers by writing citations that name one source but link to another.

— Trappist the monk ( talk) 14:59, 4 May 2019 (UTC)

Apologies both for wrong database name and lack of examples. I was going to add examples but had to leave unexpectedly. You can find several examples using |work=Paleobiology Database|publisher=Fossilworks in this search. I think the reason it was done this way is that the fossilworks website requests that both the database and their gateway website are given in citations. There are some examples of other ways that this has been attempted.    Jts1882 |  talk  15:59, 4 May 2019 (UTC)

We cite wherever we read the info, not what is requested of us by external entities (even if it isn't just a "cite this database" kind of page). -- Izno ( talk) 16:10, 4 May 2019 (UTC)

Fair enough, we cite where we read it, but the example in WP:SAYWHEREYOUGOTIT also gives the original source in the form "Original Source cited by What I Read". Most of the time we read online versions of a journal, but we still give the details of the printed volume. What I am looking for is the best way the give both the actual work (the paleobiology database) and where I read it (fossilworks). One method often used is to set |publisher=fossilworks but this doesn't seem an accurate use of publisher and the website should be the one italicised.    Jts1882 |  talk  10:50, 6 May 2019 (UTC)

I have to agree with Editor Izno here. And, the How should I cite Fossilworks FAQ does not describe citations of individual records.

I looked through the first dozen or so of the search results. What I found was an amazing lack of consistency. In most cases, the title in the citation was not the title of the entry at fossilworks (close sometimes, but not that close) for example from Lion, this:

{{cite web|url=http://fossilworks.org/bridge.pl?a=taxonInfo&taxon_no=162281|title=''Panthera leo atrox''|last=|first=|date=|work=[[Paleobiology Database]]|format=|accessdate=2012-03-11}}

"Panthera leo atrox". Paleobiology Database. Retrieved 2012-03-11.

leads to a fossilworks entry titled: †Uncia atrox Leidy 1853 (lion) which only shares the atrox part – yeah, Panthera leo atrox is an alt form but it isn't the entry's title so readers (like me) are surprised when they land at †Uncia atrox Leidy 1853 (lion) on Fossilworks (not Paleobiology Database). We should not surprise readers. This one, from Giraffe shows that links to the paleoboidb.org url get remapped to fossilworks:

{{cite web|url=http://paleodb.org/cgi-bin/bridge.pl?action=checkTaxonInfo&taxon_no=42695|title=Giraffa (giraffe)|publisher=[[The Paleobiology Database]] |accessdate=2016-09-13}}

"Giraffa (giraffe)". The Paleobiology Database. Retrieved 2016-09-13. – and yep, different title (this time not found as an alt at the database entry and not at The Paleobiology Database.

I could go on but won't. Perhaps those articles would be better served were there a {{ cite fossilworks}} template that would wrap an appropriate cs1|2 template to handle all of the constant stuff like the website name etc and give the citations some form of consistency. That won't fix the big problem of citation titles that don't match the database entries but it would be a step in the right direction. I can help if the cognizant wikiproject wants to implement an appropriate template.

— Trappist the monk ( talk) 17:11, 4 May 2019 (UTC)

This is something I plan to do. As you have seen there is incredible inconsistency in how the citations are made. The Giraffa one is unusual as the url is a hybrid using the fossilworks web service function with a paleobiology database url. The paleobiology database item would normally use this url. So how should this be handled? The Paleobiology Database is the actual work, so |work=Paleobiology Database is appropriate. Using the PB database as the work and just referencing fossilworks in the url is the kind of surprise we should be avoiding. A number of the examples use |publisher=fossilworks but this seems inappropriate. |via= is another possibility but that seems to be used for archive services and sites like JSTOR.

This general question of how to best cite taxonomic databases and the gateway websites comes up quite often and will more in future. WoRMS is another website that provides access to a variety of separate databases, some of which it curates or shares curation, others it hosts, and some it mirrors. A good citation should give both the source of the material and where it was accessed. A database parameter might be useful for use with websites serving as gateways to various databases. Then it could be tied with the |access-date= and produce output of the form "Retrieved from the Paleobiology Database on 6 May 2019" while using |website=fossilworks.    Jts1882 |  talk  10:50, 6 May 2019 (UTC)

It has taken a bit of time for me to, I think, untangle this. http://paleodb.org/ and http://fossilworks.org/ urls link to a database at Macquarie University. ^FAQ1 https://paleobiodb.org/classic/... urls link to a database held at University of Wisconsin–Madison. ^FAQ2 Two separate databases. There is at least a one-way sync from the UW database to the Macquarie database ^FAQ2 – there is no mention of data sync in the other direction.

Because there are two different databases, I think that including the 'Paleobiology Database' name in Fossilworks citations serves only to confuse because a database that isn't the fossilworks 'Paleobiology Database' exists under the name of 'Paleobiology Database'. Which one do you mean?

— Trappist the monk ( talk) 15:12, 6 May 2019 (UTC)

SMcCandlish, please don't think I am trying to be your enemy. If you think "work" should be the main field, please do so. But not in a way that makes website a separate field. -- Kailash29792 (talk) 13:45, 3 May 2019 (UTC)

Exactly! I'm having a "Whaaat?" reaction myself, because there wasn't a reason that I was aware of to expect such a result, and I've never encountered one before, even after years as a TemplateEditor doing fairly complicated work (though I don't do much on the Module/LUA side). If someone proposed (again) to make them separate parameters on purpose, I would oppose (not just because it's rehash, but on the merits of the idea, or rather the lack of them). It's not actually clear to me how this result was possible, because I simply changed the things the TemplateData said should be treated as aliases (including |work=) of |website= to instead be treated as aliases (including |website=) of |work=. I'm guessing there was some kind of tiny syntax error in what I did in the TemplateData block, or I'm missing information about what that third-party tool is doing with that information in its own codebase.  —  SMcCandlish ☏ ¢ 😼  20:33, 3 May 2019 (UTC)

The regex method won't work because there are embedded templates like {{date}} it will stop matching on the first "}", and there are cite templates with empty arguments that were copy-pasted in and not a good reflection of usage, and Elasticsearch considers the search too expensive. It would require parsing the dump taking into count these factors. I can do this, but it would take some work, so only if really needed. -- Green C 15:18, 3 May 2019 (UTC)

As noted above in my long-ass post, I doubt such stats would be useful, due to various forms of skew.  —  SMcCandlish ☏ ¢ 😼  20:33, 3 May 2019 (UTC)

FYI

 – Pointer to relevant discussion elsewhere.

Please see Talk:Mueller Report#Publisher versus work or website in citation template.  —  SMcCandlish ☏ ¢ 😼  05:47, 2 May 2019 (UTC)

Note that this discussion has continued, and led to a new section below on clearly defining examples for the |work=/|website= and |publisher= parameters. -  Paul ^{T +}/ _C 19:50, 6 May 2019 (UTC)

I propose to update the cs1|2 module suite sometime on the 20–21 April 2019 weekend. The changes are:

to Module:Citation/CS1:

• support auto-date-formatting ( discussion)
  • requires update to User:Ohconfucius/script/MOSNUM_dates.js from User:Trappist the monk/script/MOSNUM_dates.js (this is a blocking requirement) Y
  • {{ use dmy dates}} and {{ use mdy dates}} documentation update suggested
• support |transcript= for {{ cite AV media}} ( discussion)
• add |display-contributors= and |display-translators=, refactor et al check ( discussion)
• move et al and editor markup patterns to Module:Citation/CS1/Configuration
• make editorship of a work explicit when used with an authored work ( discussion)
• move missing pipe from maintenance to error; display where the missing pipe is ( discussion)
  • move explicit et al from maintenance to error
  • detect et al in |editors=
  • better error messaging
  • Category:CS1 errors: missing author or editor moves to Category:CS1 errors: missing name
• tweak is_pdf() to detect html entity fragment delimiter ( discussion)
• support single letter second-level domain names for .today tld ( discussion)

to Module:Citation/CS1/Configuration:

• support auto-date-formatting
• move |host= from alias of |authors= to alias of |last= ( discussion)
• add uz for |script-title=
• move et al patterns, editor_markup_patterns from main module
• move missing pipe from maintenance to error; display where the missing pipe is
• move explicit et al from maintenance to error
• tweak etal patterns ( discussion)

to Module:Citation/CS1/Whitelist:

• allow numbered |host#= parameters
• deprecate |subscription= and |registration= ( discussion)
• support |displayauthors in limited_basic_arguments list ( discussion)

to Module:Citation/CS1/Date validation:

• support auto-date-formatting

to Module:Citation/CS1/Identifiers:

• detect presence of mw:Extension:Wikibase_Client/Lua ( discussion)
• more accurate inactive DOI category ( discussion)

— Trappist the monk ( talk) 15:37, 14 April 2019 (UTC)

Required auto date formatting interface protected edit request made.

— Trappist the monk ( talk) 16:17, 14 April 2019 (UTC)

Subscription

@ Trappist the monk: Why are subscription= and registration= now deprecated? Where was the discussion to make them deprecated? Who determined they were not of use to specify that a subscription is required to access the full version of an article or journal? You linked to a discussion, where you only said you would be removing it without justifying why. Shouldn't this have been a consensus matter? Ss 112 15:07, 20 April 2019 (UTC)

@ Ss112: They are deprecated in favor of |url-access=. See Help:CS1#Registration or subscription required and subsections. -- Izno ( talk) 15:14, 20 April 2019 (UTC)

The problem with |subscription= and |registration= is that they are vague, non-specific parameters. Functionality of these two parameters with greater specificity is provided by |url-access= and related parameters. It is, unfortunately, all too common for editors to use these parameters for urls other than |url=. It is legitimate for a citation to have, for example, both |url= and |section-url=; one source may be behind a paywall while the other source is not (they don't have to link into the same domain); it is not possible for |subscription= and |registration= to specify which is which but |url-access= and |section-url-access= can.

Replacement of words, which as most of the users of Wikipedia can read English, are useful to most users with one of a series of tiny almost identical icons of which the meaning isn't at all clear is a terrible idea, which makes the reference harder to read and understand. And defacing articles with unsightly error messages to try and force this reader- and editor-unfriendly system on articles is a worse idea. This change should be reverted. Nigel Ish ( talk) 20:10, 24 April 2019 (UTC)

I'll get round to updating the help text in a bit.

— Trappist the monk ( talk) 15:22, 20 April 2019 (UTC)

@ Trappist the monk: In the future, perhaps we can migrate the parameters before deprecating them. One editor just flat out removed a previously non-ambiguous use of "subscription".— Bagumba ( talk) 01:13, 21 April 2019 (UTC)

Do I understand that you are volunteering for that migration task next time we have a deprecation? If so, then great; keep an eye on this talk page (though I don't anticipate that we will be deprecating anything anytime soon). It appears to me that Editor Mill 1 didn't properly understand what deprecation means but I see that you and another editor provided appropriate guidance so those problems caused by Editor Mill 1 have been resolved. Thank you for that.

There really is no pre-deprecation step in our process of abandoning a parameter. After the decision is taken to abandon a parameter in favor of something better or more useful, the first step is deprecation. The parameter still works. For me, it is preferable that we show an error message for these two parameters so that editors who care about an article can review their sources and perhaps replace restricted sources with something better that doesn't lurk behind a paywall. That is better than any old someone doing a drive-by edit with awb or some other script (and yeah, that will happen).

— Trappist the monk ( talk) 10:34, 21 April 2019 (UTC)

@ Trappist the monk: My bad. I mistook deprecated for removed.— Bagumba ( talk) 10:49, 21 April 2019 (UTC)

Trappist the monk, is there some middle ground that I'm not aware of between |subscription= / |registration= and |url-access=? What I mean is, since the former are deprecated, it means that, for example, a journal cited without a URL but with a DOI parameter can no longer include any indication (that I'm aware of) that says the source requires a subscription. JSTOR, for example, requires a subscription, but without the URL included, |url-access= gives a "requires URL" error. Hopefully that made sense -- and apologies if this has been addressed and I missed it. – Broccoli & Coffee ^{( Oh hai)} 20:05, 26 April 2019 (UTC)

Sources linked through identifiers, |jstor=, |doi=, etc typically lie behind a paywall. Because that is the normal case, we do not highlight that norm so cs1|2 does not support subscription / registration icons for those identifiers. For the occasional cases where the identifier-linked source is free-to-read, use |doi-access=free and the like. |url= is the opposite; sources linked by |url= (and |chapter-url= and aliases) are normally free-to-read. When they are not, |url-access=subscription (also registration and limited) can be used.

— Trappist the monk ( talk) 20:46, 26 April 2019 (UTC)

Thanks, that does make sense. – Broccoli & Coffee ^{( Oh hai)} 21:23, 26 April 2019 (UTC)

Parameter: |subscription

Deprecated? When? Where? Why? All these things I am yet to know! But seriously, what's the story? —— SerialNumber 54129 19:26, 22 April 2019 (UTC)

I think that this is answered at Help talk:Citation Style 1#update to the cs1|2 module suite weekend of 20–21 April 2019.

— Trappist the monk ( talk) 19:36, 22 April 2019 (UTC)

Interesting discussion—about a lack of discussion! :p —— SerialNumber 54129 09:53, 23 April 2019 (UTC)

The linked conversation was a very brief summary. There was an RFC the closing summary of which says:

• Aspect B3 (Deprecating/eliminating/supporting old and new systems): There is a clear preference to Deprecate the old system.

|subscription= and |registration= are the 'old system'.

— Trappist the monk ( talk) 13:59, 23 April 2019 (UTC)

Broken citation module

The citation plugin in VE seems to be broken at this time. Adding a plain URL (such as this one) to the Citoid field or to a regular (manual) citation template field results in the following error:

Lua error in Module:Citation/CS1/Configuration at line 458: attempt to index local 'content' (a nil value)").

Please fix this, this may affect every Wikipedia user trying to add a reference in visual editing mode.-- DarTar ( talk) 03:03, 23 April 2019 (UTC)

It appears that the problem only occurs when creating a new page. Editing an existing page seems to work just fine.-- DarTar ( talk) 04:37, 23 April 2019 (UTC)

I tested this locally, the bug in the preview seems to have been introduced by the most recent change here as reverting it fixes it: https://en.wikipedia.org/?title=Module%3ACitation%2FCS1&type=revision&diff=893307475&oldid=879151028 Mvolz (WMF) ( talk) 08:00, 23 April 2019 (UTC)

Looks like the issue is that there is no mw.title.getCurrentTitle():getContent() when a page is being created; but that is checked in the function get_date_format in Module:Citation/CS1/Configuration to figure out the date format (this feature was indeed added in the last update). Galobtter ( pingó mió) 08:05, 23 April 2019 (UTC)

I abhor ve so don't use it. If I create a new page in main space and add a simple {{ cite book}} template to that page using the wikisource editor and preview that new page, no error. That suggests to me that the problem isn't with this module suite but rather it is with ve, with the preview mechanism, or with Scribunto. Just because this module reveals the problem does not make it the source of the problem.

We can, I suspect, mask the problem by writing:

local content = mw.title.getCurrentTitle():getContent() or '';

but that is possibly just a mask and not a proper fix. — Trappist the monk ( talk) 11:34, 23 April 2019 (UTC)

It looks like VE is passing a page title value when generating the rendering, so there may be an issue with Parsoid passing the right context to Lua. Investigating that issue might take a while, so in the meantime we should apply the or ''; fix. ESanders (WMF) ( talk) 14:11, 23 April 2019 (UTC)

The underlying issue is tracked as phab:T221625. ESanders (WMF) ( talk) 14:18, 23 April 2019 (UTC)

So I misread that as a missing title, but actually getContent() is getting the full wikitext content of the page. I imagine this is expected behaviour in the Lua module that pages that don't exist, or haven't been previewed yet, return 'nil' for getContent. As VE is rendering these previews async against the last saved version of the page, this gadget should handle the case where getContent() returns nil. ESanders (WMF) ( talk) 14:24, 23 April 2019 (UTC)

Answered at phabricator.

— Trappist the monk ( talk) 15:10, 23 April 2019 (UTC)

Deprecated subscription=

This section gives cryptic advice, and my efforts to follow that advice generated more errors in the citation. Template:Cite news#Deprecated gives a list of odd-looking terms in place of url= when subscription=yes had been used for a newspaper citation. In specific, in the Natzweiler-Struthof article on the concentration camp, there is a ref to the New York Times of 10 Oct 1945, title=Kramer persists in denying guilt. It had an error message because it used the subscription=yes parameter. Now I have a subscription to the New York Times, so I do not know what a person sees who does not have one, if they click the link. I tried using article-url-access= for the New York Times article, and that generated error messages saying accessdate needs url, among other messages. As far as I understand, the New York Times does still require a subscription for much access to its articles; I know it was counting articles for me in 2018, and I had exceeded the count so access was blocked, and thus I decided in early 2019 to get a subscription. Can someone please expand the table at Deprecated to say when those various parameters need to be used? It is not obvious to me. I do not want to test each one in succession to learn that. Now the reference uses url= for the link to the image of the old article and generates no error messages as to format. Should I be adding a template with subscription required, from Template:Subscription required? -- Prairieplant ( talk) 03:46, 24 April 2019 (UTC)

en.wiki readers who do not have subscriptions to The New York Times see a prompt for subscriber credentials and a link to purchase a subscription.

The access date and other errors happened at this edit which replaced |url= with |article-url-access= in a citation that was not the 1945 NYT article ( the result). The |xxx-url-access= parameters are not replacements for |xxx-url= but are, instead, replacements for |subscription= and |registration=.

Here is the original New York Times citation with |subscription=:

{{cite news |title=Kramer Persists in Denying Guilt |url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |subscription=yes |accessdate=19 September 2015 |work=The New York Times |issue=Vol. XCV, No. 32,036 |publisher=The New York Times Company |date=10 October 1945 |page=8}}

"Kramer Persists in Denying Guilt". The New York Times. No. Vol. XCV, No. 32, 036. The New York Times Company. 10 October 1945. p. 8. Retrieved 19 September 2015. {{ cite news}}: |issue= has extra text ( help); Unknown parameter |subscription= ignored (|url-access= suggested) ( help)

The |xxx-url-access= parameters each match a |xxx-url= parameter. Your example citation doesn't use |article-url= because that parameter is not supported by {{ cite news}}:

{{cite news |title=Kramer Persists in Denying Guilt |article-url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |accessdate=19 September 2015 |newspaper=The New York Times |date=10 October 1945 |page=8}}

"Kramer Persists in Denying Guilt". The New York Times. 10 October 1945. p. 8. Retrieved 19 September 2015. {{ cite news}}: |article-url= ignored ( help)

The example citation does use |url= so the proper access parameter is |url-access=

{{cite news |title=Kramer Persists in Denying Guilt |url=http://timesmachine.nytimes.com/timesmachine/1945/10/10/issue.html |url-access=subscription |accessdate=19 September 2015 |newspaper=The New York Times |date=10 October 1945 |page=8}}

"Kramer Persists in Denying Guilt". The New York Times. 10 October 1945. p. 8. Retrieved 19 September 2015.

Yeah, documentation can always be made better. If you see a way to improve our documentation please do so.

— Trappist the monk ( talk) 11:42, 24 April 2019 (UTC)

Trappist the monk Thank you! I can remember that, a parameter in place of subscription, but includes url, and use it in another article that has a ref to the Oxford Dictionary of National Biography. I have never put anything before url, so xxx-url is wholly new to me. I think simple examples for the common places with subscription =yes would help. showing that the lock icon will appear in the ref on the page people read would be very helpful. My reaction was to take things away until the error message went away. I am most familiar with newspapers with limits, and now the Oxford Dictionary of National Biography, and just a few others encountered as I found them. -- Prairieplant ( talk) 12:39, 24 April 2019 (UTC)

Although it needs to be rewritten to bring it more in line with cs1|2, for ODNB, there is {{ cite ODNB}}.

— Trappist the monk ( talk) 13:07, 24 April 2019 (UTC)

Trappist the monk I would never find that example when I am hunting down how to fix an error message. Perhaps someone could go into the template that makes the table about the Deprecated, and arrange it so that it is clear that the word registration or subscription FOLLOWS the new parameters? It was confusing in the first place to see url and it does not mean the url itself, rather a sideways reference to the url. It took the conversation with you for me to see that it is written above the |url-access to have one of those two words follow the brand new parameter (new to me, anyway). When there are too many choices, for me, it would be helpful to show the exact order in the Deprecated box, what to use now, that is, url-access=subscription. This is a reversal of the order so long used, and I had no idea this topic was under discussion until error messages popped up in articles. Those are all my ideas. -- Prairieplant ( talk) 11:52, 25 April 2019 (UTC)

The deprecated parameter table is defined at Help:CS1 errors because it is transitory; once the deprecation period ends that table will be cleared until the next time we deprecate something. Feel free to edit that table. The basic subscription/registration documentation is at Template:Citation Style documentation/registration. Feel free to edit that.

For a very long time I have said that |dead-url= should be renamed to something else because the value that it takes is not a url but a keyword. I have never gotten much support for renaming it to something else, perhaps because I haven't yet found a better name; yeah, we could flip it to |url-dead= but that just doesn't sound write. This parameter, I think, is the only one like that. Got a suggestion for that?

— Trappist the monk ( talk) 12:22, 25 April 2019 (UTC)

I think I have suggested |url-state= with possible values dead, live, and possibly also the HTML response #s (e.g. 404) which would enable machine checking (ru.WP allows HTML responses). Current values would be deprecated but could be bot-trivially replaced. -- Izno ( talk) 15:02, 25 April 2019 (UTC)

Previous conversations that suggest |url-state= or |url-status=:

Help talk:Citation Style 1/Archive 11#Suppressing unnecessary archive-urls

Help talk:Citation Style 1/Archive 19#deprecate |dead-url=?

Help talk:Citation Style 1/Archive 42#Correct usage of dead URL?

— Trappist the monk ( talk) 15:30, 25 April 2019 (UTC)

|isdead-url= ? Nthep ( talk) 16:21, 25 April 2019 (UTC)

Sorry, but I don't think that is a good name because in cs1|2, all url-holding parameters have names that end with -url. It is this that makes |dead-url= a poor name (editors regularly give that parameter the dead url as a value) and why so far, in my opinion, |url-status= might be preferred. We use |dead-url= for a variety of things so if possible we should retain the current keywords unfit, usurped, and bot: unknown (we would have to replace yes and no with dead (default) and live. Thank you for the suggestion. Got any others?

— Trappist the monk ( talk) 23:20, 25 April 2019 (UTC)

I strongly concur with that, and would favor "url-status" as less ambiguous than "url-state" ("state" has too many other meanings). Having |dead[-]url= end with "url=" causes other problems, e.g. when cleaning up citations for consistency and readability: a mass change done to all the actual URL-providing parameters in the page ends up having to be reversed for the dead-url case.  —  SMcCandlish ☏ ¢ 😼  20:37, 3 May 2019 (UTC)

Self transclusion

Why do the cite templates cause a page to transclude itself? Examples:

• Help talk:Citation Style 1
• User:Redrose64/Sandbox14

-- Redrose64 🌹 ( talk) 22:30, 25 April 2019 (UTC)

Module:Citation/CS1/Configuration has this at line 456:

local content = mw.title.getCurrentTitle():getContent() or '';				-- get the content of the article

The documentation for the getContent() title object says:

• getContent(): Returns the (unparsed) content of the page, or nil if there is no page. The page will be recorded as a transclusion.

Only way that I know of for a template to see what is outside the boundaries of its enclosing {{ and }}. This was done to support auto date formatting.

— Trappist the monk ( talk) 23:03, 25 April 2019 (UTC)

This sounds expensive. Very expensive. If an article (such as Alodia) has 53 cite templates, that means that 54 copies of the article are being parsed in order to obtain one tiny setting. The article is 80,871 bytes, so it works out at over 4 MB. -- Redrose64 🌹 ( talk) 23:09, 25 April 2019 (UTC)

@ Redrose64: That's not true; the parsing is in a mw.loadDataed submodule, so it only happens once per page. * Pppery * _{has returned} 23:15, 25 April 2019 (UTC)

See the auto date formatting discussion above. There I show that this mechanism while not cost-free, is very inexpensive.

— Trappist the monk ( talk) 23:24, 25 April 2019 (UTC)

Trappist the monk, 200 ms difference with a 505 reference article. Impressive. — CYBERPOWER ( Chat) 23:52, 25 April 2019 (UTC)

While I would like to take the credit for that, I cannot – I just implemented it after Editor Erutuon reminded me how Lua data tables work.

— Trappist the monk ( talk) 23:58, 25 April 2019 (UTC)

Well regardless of whether you'd like to take credit or not, I want to thank you for making the change here! I'm ecstatic to not have to add |df=mdy-all/|df=dmy-all to a whole bunch of citations anymore!! -  Paul ^{T +}/ _C 19:54, 6 May 2019 (UTC)