Help talk:Citation Style 1/Archive 82

< Help talk:Citation Style 1
Archive 75 ← Archive 80 Archive 81 Archive 82 Archive 83 Archive 84 Archive 85

Generic author name detected when wikilink containing "author" is used in author parameter

This citation template currently triggers a "generic name" error:

Cite book comparison
Wikitext {{cite book|author=]|date=1993|isbn=0-9508981-9-8|publisher=Witan Books|title=The Port Vale Record 1879-1993}}
Live Kent, Jeff (1993). The Port Vale Record 1879-1993. Witan Books. ISBN 0-9508981-9-8.
Sandbox Kent, Jeff (1993). The Port Vale Record 1879-1993. Witan Books. ISBN 0-9508981-9-8.

Is this what we want to happen? We do not currently enforce the "Do not wikilink" instructions in the {{cite book}} documentation, but it looks like this is sort of doing that. Should the documentation about the "generic name" error be updated to include a note reminding editors to use |author-link=? – Jonesey95 (talk) 16:02, 29 January 2022 (UTC)

Apparently not a very common problem. This search finds less that 100 articles. Anything that improves the cs1|2 documentation is a good thing. —Trappist the monk (talk) 23:31, 29 January 2022 (UTC) @Jonesey95 and Trappist the monk: I believe I've fixed these 75 articles, but it will take a while for the search to catch up. GoingBatty (talk) 01:19, 30 January 2022 (UTC) Links are generally added in |author= especially for organizational authors. If we have advice against that, I think we should remove it. Izno (talk) 23:37, 29 January 2022 (UTC) @Izno: Why shouldn't links for organizational authors be added in |author-link= like they are for human authors? GoingBatty (talk) 01:21, 30 January 2022 (UTC) Which looks easier to you? |author=] or |author=Central Intelligence Agency |author-link=Central Intelligence Agency Izno (talk) 02:35, 30 January 2022 (UTC) @Izno: Of course adding the wikilink in the |author= parameter would be easier. Were you suggesting that organizational authors be treated differently from human authors, or that we should abolish |author-link= for all authors? GoingBatty (talk) 04:28, 30 January 2022 (UTC) Neither? I was responding to We do not currently enforce the "Do not wikilink" instructions in the {{cite book}} documentation, but it looks like this is sort of doing that. Izno (talk) 06:00, 30 January 2022 (UTC) I've split the generic patterns tables into accept and reject sublists. In the sandbox, the accept list now has '%*%(author%) *|]*%]%]' which should catch any piped wikilink with 'author' disambiguators. See the compare in the OP. —Trappist the monk (talk) 14:00, 31 January 2022 (UTC)

Copying module to other wikis

Hello everyone!

Some years ago someone copied the module to dawiki and it worked fine. But at some point we had some problems with IABot and I wanted to update the module. But I could not find the problem. The user that had been working on the module wrote that his health was not good and we have not heard from him since. A lot of knowledge disappeard with him even if he wrote some notes in the code.

But with a lot of help from Trappist the monk and a few users from dawiki the module was updated on dawiki in December 2021. I tried to make notes and explain the changes I made. But it was messy because of all the changes back and forth.

In January 2022 the module was updated on enwiki so I had the chance to update the Danish module again and this time make the changes more pretty and with better descriptions. Sadly the notes are mostly in Danish.

I could probably have saved a lot of time if there was some good manual somewhere on how to move the module. Perhaps there are some help somewhere. Then I just need to know where. And hopefully other users can save some time when they know how the module was modified on dawiki and why.

To help myself and future users on dawiki I have made some intro on da:Modul:Citation/CS1/sandkasse (sandkasse means sandbox) and the other (sub)mudules + in a table on da:Moduldiskussion:Citation/CS1#Opdatering_2021_pga_IABot. So basicly there is a text saying copy module from enwiki and change 1, 2, 3...

The Danish module have like 30 watchers so there is almost no chance that users from other wikis will find out I wrote those notes. So I'm looking for a place for a "How to copy the module from enwiki to another wiki" and someone to help me write the guide. --MGA73 (talk) 11:54, 30 January 2022 (UTC)

Yay for you! I suppose that one possible location for such a document might be Module:Citation/CS1/doc/Importing the Module:Citation/CS1 suite to your wiki (no doubt, there is a better title to be had). We can link to that page from Module:Citation/CS1/doc. Someone with experience doing these kinds up imports is Editor Klein Muçi from sq.wiki who has imported the en.wiki suite to sq.wiki and la.wiki. —Trappist the monk (talk) 12:26, 30 January 2022 (UTC) It seems that the location is seen as a module so it will try to debug whatever text I add there. So perhaps Help:Citation Style 1/Importing the Module:Citation/CS1 suite to your wiki could be another possible place? --MGA73 (talk) 16:09, 30 January 2022 (UTC) It is, but the content model can be changed to wikitext if the decision is taken to put the import doc in module space. That's where I think it should go because it is the module that is the big import headache. Others may disagree. —Trappist the monk (talk) 16:30, 30 January 2022 (UTC) If you know how to fix it then I'm in for the name. --MGA73 (talk) 16:33, 30 January 2022 (UTC) done —Trappist the monk (talk) 16:37, 30 January 2022 (UTC) Thanks a million! I added a little to start with. Everyone is welcome to add stuff they might find useful. --MGA73 (talk) 18:23, 30 January 2022 (UTC) @Trappist the monk, thanks for the mention! :) @MGA73, hello! I'll try to help you. I see you have already started but maybe you may be interested in this old idea of mine. I think it correlates with what you're already doing there. Take a look, maybe you're interested. (I can give further details if so needed.) - Klein Muçi (talk) 22:08, 30 January 2022 (UTC) @Klein Muçi I think it would be a good idea. I'm sure we talked about it before but to make it happen someone needs to invest a lot of time in the project. I think we would still need to translate stuff to other languages and know where modifications are needed. We will get some of that knowledge by this help page too. --MGA73 (talk) 06:55, 31 January 2022 (UTC) @MGA73, the general idea is to maybe use Wikidata to create a list of links with all the projects already using the module, their categories and their templates. Then we check what's their up to date status when compared with the EnWiki one and what may be some kind of elements they may wish to keep different from the EnWiki one and note that one down + maybe 1-2 main maintainers who to contact for each project. Then, considering that for most projects the only CS1 subpages that may require more attention than just blindly copy-pasting are the main one and the /config. one, we can, hopefully, create a bot that just updates the other subpages globally, leaving only those 1-2 pages for the human editors to update who may be notified with an automatic message once every update happens. The update documentation may be more thorough on those 2 pages. The best place for coordinating this approach would be Meta but the community there has been rather silent about my requests there so... When I first was thinking about this idea, I was thinking about it in terms of manual labor, but I believe the tables of links I mention above could be created rather fast automatically utilizing Wikidata somehow. We'd only have to deal with noting down their up to date status, the maintainers and hopefully the bot. @Trappist the monk, what do you think? Is there a way to gather that information (the tables of links) fast automatically? - Klein Muçi (talk) 11:28, 31 January 2022 (UTC) I guess I don't fully understand your question. A list of links to other wikis that use some version of Module:Citation/CS1 is already available at wikidata; see Module:Citation/CS1 (Q15403807); there are similar lists for the other modules in the suite. —Trappist the monk (talk) 12:46, 31 January 2022 (UTC) @Trappist the monk, yes, that's the idea. Is there a way to get those lists transcluded in a wikipage as part of a large table? The table would be made up from the said links + 2 extra cells (at least) which would have information about the update state + main local mainteners per project (information which would have to be gathered manually). - Klein Muçi (talk) 14:30, 31 January 2022 (UTC) Perhaps as an initial table creation. Once manual edits are made to the resulting table(s) then it becomes all manual I think. Enter this in a Lua debug console: =mw.dumpObject (mw.wikibase.getEntity ('Q15403807')) That will return a long list of sitelinks and some other stuff as a lua k/v table. A lua function could create wikitables from that for wikipedias, wikitionaries, etc pre-populated with language names, interwikilinks, and columns for humans to populate (so long as the module knows what those columns are ...). —Trappist the monk (talk) 15:05, 31 January 2022 (UTC) @Trappist the monk, well that's close enough. Can you deal with the creation of the said Lua module? The very raw table I'm imagining is like this: Project - Link - State - Maintainer SqWiki - Moduli Citation/CS1 - Updated/Outdated - Klein Muçi This is a very basic table. If it proves helpful, its function can be extended to also include information about the categories or maybe even its associated templates. Ideally, using the information from that table, a global bot can be used to update the modules which require only blind copy-pasting and a message can be sent to each maintainer to deal with the pages that require human intervention. What do you think? - Klein Muçi (talk) 22:45, 31 January 2022 (UTC) I think that these tables will be quite large so each module should probably have a subpage under Module:Citation/CS1/doc/Importing the Module:Citation/CS1 suite to your wiki. Discussion about the details of the tables should probably continue at Module talk:Citation/CS1/doc/Importing the Module:Citation/CS1 suite to your wiki rather than here. —Trappist the monk (talk) 23:56, 31 January 2022 (UTC) @Trappist the monk, yes I was thinking the same thing. (Things get scary when category tracking is also introduced.) The problem though is that personally I never learned how to create a table from scratch using wikitext let alone make a module in Lua to create it from me, so unfortunately unless you or someone else is offered to deal with that part, there won't be much to further continue discussing. - Klein Muçi (talk) 00:08, 1 February 2022 (UTC) At least this part of the discussion continues at Module talk:Citation/CS1/doc/Importing the Module:Citation/CS1 suite to your wiki § Copying module to other wikis. —Trappist the monk (talk) 00:35, 1 February 2022 (UTC)

|issue= and |volume= i18n

Discussion at another-language wiki showed yet another place where the local editors had to edit their Module:Citation/CS1 module to meet their needs.

In order for {{citation}} renderings to match the equivalent cs1-template renderings, we constrain the use of |volume= when |website=, |script-website= and |mailinglist= are used in the citation. We allow {{citation}} to render |issue= when |journal=, |magazine=, |newspaper=, |periodical=, |work=, and their |script-*= counterparts are used. The lists of those parameter has been moved into Module:Citation/CS1/Configuration/sandbox.

Citation comparison
Wikitext {{citation|title=Title|url=//example.com|volume=123|website=Website}}
Live "Title", Website
Sandbox "Title", Website
Citation comparison
Wikitext {{citation|issue=123|magazine=Magazine|title=Title}}
Live "Title", Magazine, no. 123
Sandbox "Title", Magazine, no. 123

Is the ignored |volume= something that should be 'announced' in the way that we 'announce' that |chapter= is ignored?

—Trappist the monk (talk) 23:44, 31 January 2022 (UTC)

@Trappist the monk: I'm presuming you're saying that |volume= used to be displayed under these conditions and now it is not. To your question about an announcement, are you able to do a search to determine how many citations would be impacted? Thanks for your continued work to improve these templates! GoingBatty (talk) 02:58, 1 February 2022 (UTC) No, that is not what I'm saying. There is no difference in the display between the sandbox and live modules. The purpose of this change is to make it easier for non-English wikipedias to add non-English parameter names to the list of parameters that switch {{citation}} into periodical mode which allows the use of |issue=. The |volume= list is a list of parameters that switch {{citation}} into periodical mode where |volume= would be inappropriate – |volume= doesn't make sense in {{cite web}} so the {{citation|website=...}}} equivalent should not support |volume=. This search times out and when I ran it returned 19 results. Iterate over the other parameters in the volume list. —Trappist the monk (talk) 12:24, 1 February 2022 (UTC)

i18n: live / sandbox selection

cs1|2 templates invoke either the live Module:Citation/CS1 module or the sandbox Module:Citation/CS1/sandbox. The invoked module then loads all of the other modules and the css style sheet, choosing the live or sandbox versions as appropriate. Some wikis do not use the term sandbox to identify their sandboxen so editors at those wikis must tweak their Module:Citation/CS1/sandbox so that it will load the appropriate sandbox modules. Until now that required changing seven lines of code. I have simplified that so that now, only one line of code needs to be changed.

It occurs to me to wonder if we might modify the sandbox cs1|2 templates (which we call ~/new) so that they pass in a parameter |SandboxSubpageName=.

{{#invoke:citation/CS1/sandbox|citation |CitationClass=book |SandboxSubpageName=sandbox }}

The module sees that and applies that name with preceding / to the names of the modules to be loaded. It means that other wiki would change 23ish sandbox templates once instead of one change to the sandbox module every time they update.

Opinions?

—Trappist the monk (talk) 16:03, 2 February 2022 (UTC)

That sounds like a kind thing to do. – Jonesey95 (talk) 16:36, 2 February 2022 (UTC)

title "Club not live"

There are currently 20 citations with the title set to Club not live, presumably because www.pitchero.com doesn't return a 404 error as it should. Can this be added to the list of useless titles? -- John of Reading (talk) 16:58, 2 February 2022 (UTC)

Website parameter being misused?

The {{Cite web}} docs clearly state that the website parameter should display the name of the site, and the examples back that up. Though for some reason, on lots and lots of articles that I see, it's used to display the domain name. For example, where I would think someone would put |website=] on a page on Microsoft's website, I often see |website=www.microsoft.com or something similar, instead. Have I misunderstood what the examples, docs, and templatedata say? Or is everyone using this parameter incorrectly. Thanks, ― Levi_OPTalk 16:37, 13 January 2022 (UTC)

You have not misunderstood. Unfortunately, the doc was not as clear as it should have been in the past, and it is not unusual for the incorrect format to appear in older citations. Also, perhaps editors do not pay proper attention to the current documentation. 65.88.88.68 (talk) 16:45, 13 January 2022 (UTC) Sooo should I fix this on any articles I see it on? This seems like a pretty big task that some bot could do instead considering just how many articles have this issue. ― Levi_OPTalk 16:50, 13 January 2022 (UTC) It's often bots and AWB that do it in the first place because they can easily determine via the URL but they can't know what the name should be. -- GreenC 16:54, 13 January 2022 (UTC) (edit conflict) Microsoft is not a website, so you should not find |website=]. Those should be replaced with |publisher=]. |website=www.microsoft.com is fine, thought not really needed if you have |publisher=]. Headbomb {t · c · p · b} 16:55, 13 January 2022 (UTC) Oh, thanks. I didn't know that this publisher option existed, so it would be better in this case. Although, it was just an example. I see it with other links where it is a website and not a company page or something of the sort. ― Levi_OPTalk 17:16, 13 January 2022 (UTC) In the case of websites, the publisher is the hosting entity, usually the domain-name owner. This applies when there is a different website creator/owner, as it happens with "free" websites offered by ad-supported web hosting services (actually such websites are usually sub-domains, but that's another story). However, the trade name or dba of the publisher is appropriate if different from the domain-name, so use |publisher=Microsoft rather than |publisher=microsoft.com. 65.88.88.75 (talk) 19:46, 13 January 2022 (UTC) @GreenC: How would AWB "easily determine via the URL" and create a malformed reference? Maybe you were thinking of tools like Reflinks and/or reFill? GoingBatty (talk) 20:40, 13 January 2022 (UTC) Well AWB by default can not, but users can create external scripts/programs that hook into AWB (Python, JS, PHP etc). Basically AWB handles the authentication, download and and upload of the page, and a user script processes the page to do whatever. Many bots run this way. Yes the user-initiated tools are also a factor. -- GreenC 20:45, 13 January 2022 (UTC) |website=www.microsoft.com is not fine. It is the name of the host where the title (and maybe not the whole web site) can be found. It is different from the name of the web site, which in this case happens to be the same as the name of the publisher, Microsoft (although you could spell out the publisher as "Microsoft Corporation" if you were feeling pedantic, and the name of the site would still just be Microsoft). In general, my philosophy for sites where the publisher is more informative than the whole-site name is to use the "work" parameter to give some context to the specific title being cited — is it part of a larger thing, and which level of larger thing would tell readers the most useful information about the citation? For the same reason we neither use street numbers nor "Earth" to quickly describe the residence of someone, we should often neither use the most specific description of a larger work containing the title nor the most general description ("World Wide Web") to describe the work it comes from, but something intermediate, chosen to be informative. Maybe that's the title of a magazine or newspaper, rather than the department within that publication, or the group of publications ("Times-Mirror Newpapers") it comes from. In the case of , for instance, (one of the references in Microsoft), the publisher is "Microsoft", and it is indeed somewhere in Microsoft's vast web site, so it is not wrong to put |work=Microsoft, but a more informative and therefore better choice would be |work=Official Microsoft Blog. To complete the analogy, putting a domain name in the work parameter would be like writing that someone lives in the 02134 zip code — it is informative, roughly at the level a city name might be, but in a format primarily intended for conveying information unambiguously to computers, rather than for communicating to people. The text of an encyclopedia article (and a citation is part of that text) should be for communicating to people. —David Eppstein (talk) 23:00, 13 January 2022 (UTC) Microsoft is not a website, it's a publisher. The name of the website, if anything is Microsoft.com. Headbomb {t · c · p · b} 04:12, 14 January 2022 (UTC) Looking at first principles, why add a website/publisher: to facilitate verification. Sometimes no archives exist, so additional metadata is useful in finding a copy in databases such as LexisNexis and others. The more 'fancy' one gets with naming, the more likely a mismatch. For example if LN saved it as "Microsoft.com" then searching on "Official Microsoft Blog" might not find it. But searching on only "Microsoft" would find it. Thus it would probably be preferable to have simply |publisher=Microsoft - given V as the consideration concision and common name is important, similar to our article naming conventions, ease of finding things. The idea that precision is better for verification makes sense, unless other websites (LN) have a different idea what to call the website/publisher, which is probably a common problem because there are no standards. -- GreenC 05:49, 14 January 2022 (UTC) If you're basing this on the principle that it should be useful for recovering sources whose address change, then encoding part of the address (the domain name) into the parameter value is exactly the wrong thing to do, because it doesn't provide you any information that you didn't already have in the address. Instead, if you give a textual name that the source uses (like "Official Microsoft Blog"), you are more likely to be able to use that name in searches to find it again. —David Eppstein (talk) 20:32, 14 January 2022 (UTC)

Can anything be done to give editors a clue where to look when "templates have maintenance messages; messages may be hidden" is reported with no supporting detail.

CS1 error analysis of the lead section of East West Rail reports Script warning: One or more {{cite web}} templates have maintenance messages; messages may be hidden (help). None of the citations has a specific error report. I have tried each paragraph individually in my sandbox: no errors. But as a group: error. No clues as to what is causing the problem.

My commmon.css reads

.harv-error {display: inline !important;} /* display Module:Footnotes errors */
.mw-parser-output .cs1-maint {display: inline;} /* display Citation Style 1 maintenance messages */ (second line added in the hope that it would help: it doesn't)

This is the second time today that I have spent a silly amount of time hunting for needles in haystacks (but at least the earlier one could be pinned down using the paragraph method. The faulty citation had author=Doe, John & Doe, Jane (2015) - if the code could identify that as an error, surely it could have let me into the big secret?

I'm not looking for someone to fix the error, what I want is a more useful error report if at all possible. --John Maynard Friedman (talk) 20:57, 3 February 2022 (UTC)

I think we should probably hide the top/preview maintenance message warning for people who do not have the maintenance message display CSS in their common.css files. – Jonesey95 (talk) 21:15, 3 February 2022 (UTC) Not possible. The preview panel apparently ignores css which is why the styling that we apply is done manually for each of the messages. —Trappist the monk (talk) 21:42, 3 February 2022 (UTC) Then we should probably hide the maintenance-related preview messages for all editors. IMO it is user-unfriendly to say "there's a maintenance message" but give no clue about where it is or how to address it. – Jonesey95 (talk) 22:13, 3 February 2022 (UTC) John Maynard Friedman, that CSS looks right to me. If you edit and Preview the lead section article, you should see a maintenance message in the citation containing "East West Rail Bedford to Cambridge Preferred Route Option Report". The message is "CS1 maint: url-status". I usually do a Find on the page for "maint" to jump to the error message. – Jonesey95 (talk) 21:21, 3 February 2022 (UTC) Someone edited the help text when they should not have. The correct css is: .mw-parser-output span.cs1-maint {display: inline;} /* display Citation Style 1 maintenance messages */ —Trappist the monk (talk) 21:42, 3 February 2022 (UTC) Thanks guys, that was it. When I have no or an invalid .mw-parser-output, I see "templates have maintenance messages; messages may be hidden" but nothing in the citations to suggest what the error is. With the correct .mw-parser-output, all is revealed. --John Maynard Friedman (talk) 23:36, 3 February 2022 (UTC)

Could somebody have a look at Christopher C. Kraft Jr.? I have no clue what the message refers to. Hawkeye7 (discuss) 21:39, 3 February 2022 (UTC)

This template has both |date= and |year=. Only one is needed. {{Cite magazine |last=Nystrom |first=Lynn |magazine=Virginia Spectrum |volume=24 |issue=31 |date=April 26, 2002 |title=Kraft selected 2002 Ruffner Medal recipient |publisher=Virginia Tech |year=2002 |url=http://scholar.lib.vt.edu/vtpubs/spectrum/2002/sp2002-0426.pdf |access-date=February 1, 2022 |ref=none}} Nystrom, Lynn (April 26, 2002). "Kraft selected 2002 Ruffner Medal recipient" (PDF). Virginia Spectrum. Vol. 24, no. 31. Virginia Tech. Retrieved February 1, 2022.{{cite magazine}}: CS1 maint: date and year (link) —Trappist the monk (talk) 21:45, 3 February 2022 (UTC) (edit conflict) @Hawkeye7:  Fixed in this edit. GoingBatty (talk) 21:46, 3 February 2022 (UTC) Thanks for that. While redundant here, I thought this was allowed so you could say |year=2002a to avoid duplicated references. Hawkeye7 (discuss) 23:15, 3 February 2022 (UTC) Only needed when the chosen date format is 2022-02-03. Otherwise, |date=3 February 2022a or |date=February 3, 2022a. Not an issue with this particular citation because |ref=none. —Trappist the monk (talk) 23:41, 3 February 2022 (UTC)

CS1 maint: url-status

Moved from Category talk:CS1 maint: url-status – that talk page now a redirect —Trappist the monk (talk) 12:14, 23 January 2022 (UTC)

Is this category working correctly? I see that articles gain tihs warning with url-status=live, unfit or usurped. With that setting, they don't need to have archive-url= or archive-date= values. What's the point? Seems more useful to only cause an error on references that set url-status=dead -- Mikeblas (talk) 00:54, 23 January 2022 (UTC)

Convenience link: Category:CS1 maint: url-status —Trappist the monk (talk) 12:14, 23 January 2022 (UTC) Yes, I think so. |url-status=<dead | live | unfit | usurped | deviated> (any valid value) without |archive-url= conveys no meaning to the template. It is |url-status= that controls how cs1|2 templates are rendered when |archive-url= is present and has an assigned value. All of these correctly emit the maintenance message and, when in a categorizable namespace, add the article to Category:CS1 maint: url-status. {{cite book |title=Title |url-status=live}} → Title.{{cite book}}: CS1 maint: url-status (link) {{cite book |title=Title |url-status=dead}} → Title.{{cite book}}: CS1 maint: url-status (link) {{cite book |title=Title |url-status=usurped}} → Title.{{cite book}}: CS1 maint: url-status (link) {{cite book |title=Title |url-status=unfit}} → Title.{{cite book}}: CS1 maint: url-status (link) {{cite book |title=Title |url-status=deviated}} → Title.{{cite book}}: CS1 maint: url-status (link) |url-status=dead is not a substitute for {{dead link}}. —Trappist the monk (talk) 12:56, 23 January 2022 (UTC) I think that url-status=live is used to indicate that the URL is live, and that an archive-url is not necessary. Why should that state place the article in a maintenance category? -- Mikeblas (talk) 22:27, 23 January 2022 (UTC) Which is not its purpose. Its purpose is to indicate when the URL is live and there is an archive, such that the live URL is displayed in the preferred position. Either add an archive or remove the parameter. Izno (talk) 22:54, 23 January 2022 (UTC) (edit conflict) You are misunderstanding the purpose of |url-status=live. The only purpose of |url-status=live is to specify which of |url= or |archive-url= links |title= when the citation is rendered: {{cite book |title=Title |url=//example.com}} Title. – |url= links |title= {{cite book |title=Title |url=//example.com |url-status=live}} Title.{{cite book}}: CS1 maint: url-status (link) – |url= links |title=; |url-status=live contributes nothing {{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23}} Title. Archived from the original on 2022-01-23. – |archive-url= links |title=; |url= links 'the original' static text {{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23 |url-status=dead}} Title. Archived from the original on 2022-01-23. – |archive-url= links |title=; |url= links 'the original' static text; |url-status=dead contributes nothing {{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23 |url-status=live}} Title. Archived from the original on 2022-01-23. – |url= links |title=; |archive-url= links 'Archived' static text because |url-status=live {{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2022-01-23 |url-status=usurped}} Title. Archived from the original on 2022-01-23.{{cite book}}: CS1 maint: unfit URL (link) – |archive-url= links |title=; |url= suppressed because |url-status=usurped cs1|2 adds articles to Category:CS1 maint: url-status when cs1|2 templates include non-contributing |url-status=live, |url-status=usurped, |url-status=unfit, |url-status=deviated. It is expected that a future cs1|2 update will categorize non-contributing |url-status=dead. —Trappist the monk (talk) 23:30, 23 January 2022 (UTC)

If a link is dead and there is no archive then an example could look like this:

{{cite web|title=Title |url=//example.com |access-date=2022-01-23 |url-status=dead}} –-> "Title". Retrieved 2022-01-23.{{cite web}}: CS1 maint: url-status (link)

In this case the url is dead but it is not possible to add a |archive-url=. What would be the correct thing to do there? Remove |url-status=?

I think often IABot would add {{Dead link}} but {{Cite web}} could do the same. So if statues is dead and there is an archive the template does at it do now but if there is no archive the template shows {{Dead link}}. If would have to be coordinated so that we do not have both templates. --MGA73 (talk) 10:17, 5 February 2022 (UTC)

Templates cannot see anything that lies beyond their {{ and }} so cs1|2 templates cannot know if they are already associated with an adjacent {{dead link}} template. It is not the responsibility of cs1|2 to handle the housekeeping duties of {{dead link}} or any other inline cleanup template. —Trappist the monk (talk) 12:21, 5 February 2022 (UTC) In your above example, the correct thing is remove |url-status= and add {{dead link}}. -- GreenC 14:58, 5 February 2022 (UTC) Thank you. Yes it is true templates can't see what is in other templates. But is there a good reason not to let cs1|2 templates controll it? It would ofcourse require that IABot is modified so it does the housekeeeping correct. --MGA73 (talk) 15:05, 5 February 2022 (UTC) I think you mean users set |url-status= and if IABot sees |url-status=dead then it acts, such as adding a {{dead link}}. There is no guarantee IABot will run on a page in a timely manner - IABot can be shut down for reasons, or not process a page for a long time. I suppose there could be a special purpose bot whose only job is to convert |url-status=dead to {{dead link}}, it will always be checking quickly; it's an added complication and raises the question why not use {{dead link}} instead of |url-status=dead to begin with. Maybe there could be both. If you want to do it on dawiki, it would be fine, but would be a special bot not rely on IABot. I can provide a daily dump of CS1|2 templates in any language (demonstration page). It's an interesting idea, the unknown is can you trust |url-status=dead means it is dead, or a user entry error. -- GreenC 15:32, 5 February 2022 (UTC) If IABot or a human user find out that a link is dead and there is no working link in the archive then today the correct would be to add {{dead link}}. Instead of that users and IABot could add |url-status=dead. I think both options would be just as fast (or slow). We also have {{Webarchive}} but instead of using that template we let the cs1|2 templates handle archive links. I see no benefits of having special templates and bots on dawiki. I think the safest is to make it as similar as possible across wikis. I just try to understand why its a good idea to use combine {{Cite web}}{{Dead link}} when it is not a good idea to combine {{Cite web}}{{Webarchive}}. --MGA73 (talk) 16:04, 5 February 2022 (UTC) {{Dead link}} is a universal flag that says the URL is dead. {{Webarchive}} contains an archive URL and is useful following a square or bare URL. There would normally be no reason to have {{Cite web}}{{Webarchive}} because the archive URL can be contained in {{Cite web}} thus {{Webarchive}} is redundant. There are some rare exceptions such as when using the |addlarchives= flag with {{Webarchive}}. But normally, it would be {{Webarchive}}. -- GreenC 16:41, 5 February 2022 (UTC) Thank you. I was just wondering why not change {{Cite web}} so it could make {{Dead link}} redundant. If you prefer not its fine with me. Lets just leave it with that :-) --MGA73 (talk) 18:23, 5 February 2022 (UTC)

Internationalisation_need #2

Continued from Help talk:Citation Style 1/Archive 81 § Internationalisation need originally posted by Arjunaraoc.

I have hacked Module:Citation/CS1/Configuration/sandbox so that it will fetch month names from MediaWiki using the native Scributu function formatDate(). That function takes the same format and date/time strings as the {{#time:}} parser function. Seemed to work here and at sq.wiki but I got surprising results at te.wiki. So I hacked a bit of test code that runs from the debug console with this command:

=p.main ('<lang tag>')

where <lang tag> is an ISO 639-1, -2, -3, or IETF-like language tag known to MediaWiki.

When I run the test at en.wiki for <lang tag> = te I get this:

=p.main ('te') జన | ఫిబ్ర | మార్చి | ఏప్రి | మే | జూన్ | జూలై | ఆగ | సెప్టెం | అక్టో | నవం | డిసెం జనవరి | ఫిబ్రవరి | మార్చి | ఏప్రిల్ | మే | జూన్ | జూలై | ఆగస్టు | సెప్టెంబరు | అక్టోబరు | నవంబరు | డిసెంబరు

That is the expected result. Compare the test's output against long names and short names in te:మాడ్యూల్:Citation/CS1/Configuration.

When I run the exact same test at te.wiki, I get this:

=p.main ('te') జనవరి | ఫిబ్రవరి | మార్చి | ఏప్రిల్ | మే | జూన్ | జూలై | ఆగష్టు | సెప్టెంబరు | అక్టోబర్ | నవంబరు | డిసెంబరు జనవరి | ఫిబ్రవరి | మార్చి | ఏప్రిల్ | మే | జూన్ | జూలై | ఆగస్టు | సెప్టెంబరు | అక్టోబరు | నవంబరు | డిసెంబరు

Long and short month names are the same except for month 10.

It is simple to test this at other wikis. Edit my sandbox. Copy the code into your clipboard. Change the domain in the url from en to some other valid tag (the WP code in the tables at List of Wikipedias). Paste the test code into the edit box and then, in the debug console, enter the =p.main ('<lang tag>') command with an appropriate language tag (doesn't have to be the same as the WP code in the url).

I'm inclined to keep this modification even though it won't work for all projects because it will work for some. At projects where it won't work, it is easy to disable because the functionality is controlled by a boolean:

local local_date_names_from_mediawiki = true

to disable, set that boolean false.

—Trappist the monk (talk) 23:14, 3 February 2022 (UTC)

@Trappist the monk, Thanks a lot for internationalising the template. I liked your approach. I tried on Tewiki and found the local Mediawiki messages such as "Mediawiki:Oct" as the reason for the difference. I deleted those messages which still existed and got the same result as you got for "te" on enwiki. Arjunaraoc (talk) 04:34, 4 February 2022 (UTC) @Arjunaraoc: In case there are other wikis with the same sort of issue, where is local Mediawiki messages? I assume that it is the same basic location at each wiki. —Trappist the monk (talk) 12:38, 4 February 2022 (UTC) @Trappist the monk, Yes. "Local Mediawiki message" is the localisation string that was used in the early days of Wikipedia, before Translatewiki usage for localisation. The pages for these messages can be found in pages "Mediawiki:Jan" ... "Mediawiki:Dec". Arjunaraoc (talk) 04:38, 5 February 2022 (UTC) On Danish Wikipedia I found da:MediaWiki:January-gen for example. I do not know if pages like that can also make a mess. --MGA73 (talk) 10:57, 5 February 2022 (UTC) @Trappist the monk, exactly now I convinced myself that SqWiki could adopt the short months given that Mediawiki and CLDR had already adopted them a long time ago and started editing the ~/Configuration page. After changing the first 2 months, I thought "If those names already exist in Mediawiki for each project, can't we find a way to make the process automatic instead of having to write them manually?". Remembering vaguely that you had already started a discussion about this topic in here and not wanting to overload your talk page even more, I thought I'd ask here. Now I see that the discussion was precisely for that. I'm glad we're following this road. In regard to the Mediawiki namespace discussion, SqWiki hasn't got messages like that. Mediawiki messages serve to modify the interface of the site, mostly being used for localization purposes (translation) and are automatically deleted once a translation for them is available at Translatewiki. The said messages used to serve precisely for that purpose: to determine how the short versions of the months would be rendered by the system. They were deleted en masse globally on January 7th 2007 by the Mediawiki default, (the bot that deals with that matter) the date translations for them were made available at Translatewiki. If you search for Mediawiki:Dec, you'll find the same notification in here, in SqWiki and I suspect in many other wikis as well. Of course, wikis reserve the right to recreate the pages at any time and those messages will override locally the Translatewiki version immediately. Admins usually do so when they don't know about Translatewiki, they don't yet have an account there or they don't want to go through the politics that Translatewiki may put you in because translations provided there go live for all projects of a said language and different projects (Wikipedia, WikiQuote, etc.) may have different opinions about a specific message. (I know because I've been one of those admins when I didn't know yet for Translatewiki.) The recreated pages will remain until an update happens at the corresponding Translatewiki message at which point Mediawiki default will come and delete the local Mediawiki message. For our case, if we want to go down that rabbit hole, we'd need to see how spread are those specific 12 Mediawiki messages globally but unfortunately I don't know of a way to do that; Mediawiki pages aren't connected in Wikidata. My guess is that they won't be many left and even in the projects that they are I'm not sure if this would be of great concern to the module's purpose itself. Maybe the best we can do is add a comment about this beside the corresponding lines when they do go live on the next update. - Klein Muçi (talk) 03:52, 6 February 2022 (UTC)

Newspaper sections

{{cite news|title=News article|section=2|page=3}} "News article". p. 3. {{cite news}}: |section= ignored (help) {{cite news|title=News article|page=2{{hyphen}}3}} "News article". p. 2-3. {{cite news|title=News article|department=Section 2|page=3}} "News article". Section 2. p. 3.

What is the proper way to denote a newspaper article on section 2, page 3, using {{cite news}}? It seems that I should be able to use |section=, but I get an error message. The doc page says to use 2{{hyphen}}3, but that just reads like pp. 2–3 to me. Using |department= points me in the right direction, but that doesn't seem intuitive. –Fredddie™ 21:50, 5 February 2022 (UTC)

I've used |at=§2, p. 3 myself. Imzadi 1979 → 21:55, 5 February 2022 (UTC) Or use |department=Section 2. 68.173.76.118 (talk) 13:50, 6 February 2022 (UTC)

Wikilink text inside of quotations?

Is it mandatory, permissible or prohibited to wikilink terms in the text of |quote= rather than giving the text as is? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:21, 7 February 2022 (UTC)

I don't think there's a specific guideline for this, except the general MOS guideline that suggests links within quotes should be avoided, as they may shift focus from the quote itself. Sometimes though I think linking an obscure term may clarify the quote. 71.247.146.98 (talk) 13:40, 7 February 2022 (UTC) MOS:LINKQUOTE. 71.247.146.98 (talk) 13:49, 7 February 2022 (UTC)

DOI inactive category

There is a desire to rename them https://en.wikipedia.org/wiki/Wikipedia:Categories_for_discussion AManWithNoPlan (talk) 12:29, 8 February 2022 (UTC)

"cite AV media notes" disallows "others="?

Hi guys. I'm a CSS total noob but can you tell me basically why this didn't work? Why does Template:Cite_AV_media_notes give a CSS error simply due to the presence of "others=" when the template's documentation says "others=" is fully supported? Why would any template disallow "others="? Did I write this diff correctly? I'm just kinda curious if this is a bug because it makes no sense. Thanks. — Smuckola(talk) 22:10, 5 February 2022 (UTC)

It's not that |others= is not supported, it's that it is unsupported when another authorship parameter (author or editor) is not provided. It has its own category relative to the same in other templates because over 60-70% of these cases are because of AV media (notes) issues. Izno (talk) 22:27, 5 February 2022 (UTC) What's the "right" way to cite AV media notes then when there's no listed author for the text? Providing, say, the musical artist associated with the CD under |others= will help readers locate the source, but they weren't the author of the text being cited. Umimmak (talk) 22:39, 5 February 2022 (UTC) Even though it was a maintenance message before it was wrapped up into its own category and maintenance message, it remained a maintenance message (as opposed to an error) when we split it from the 'parent' category because we don't know the best way to deal with it. That link is the last time we discussed what to do with cite AV media notes's generic "everyone" parameter (|people=), which is the parameter at issue. Izno (talk) 00:11, 6 February 2022 (UTC) @Izno: Okay so please check out this. Let me know which argument on the left side was originally conflicting with "others=". And on the right side, did I resolve it correctly or what? Is a music composer suited for "first= | last="? Or should I have done "people=], ]"? Thanks. — Smuckola(talk) 21:36, 6 February 2022 (UTC) Uh, on the left side, it's |others=. |people= would be as bad. As I said, I don't have an answer. For now, I honestly would recommend ignoring these maintenance messages. This is a topic where a discussion would be fruitful. :) Izno (talk) 21:53, 6 February 2022 (UTC) Oh, my, Varèse Sarabande – and Star Wars; a blast from the c. 1983 past. My name is in the credits for John Williams: The Star Wars Trilogy. I gotta wonder though, should Joel McNeely and Royal Scottish National Orchestra really be named as authors of liner notes? Yeah, they are the performers in the recording, but we aren't citing the recording. If McNeely and Royal Scottish National Orchestra actually contributed words to the liner notes, then sure, those names belong in the citation. When other written sources don't have author names (newspaper articles, items provided by news agencies, etc) the citation doesn't get names. If you cannot identify from the liner notes who the author is, omit the author parameters (or |author=<!-- not stated -->). No doubt someone will say "but the performers are essential for readers to locate the source". Really? You have the publisher and the title of the recording (presuming that en.wiki editors transcribe it correctly – which is it: Star Wars: Shadows of the Empire Official Soundtrack or Star Wars: Shadows of the Empire), and you could even include |id=UPC: 888072173637. With all of that, locating a copy of the source should not be that difficult. For a long time I have thought that this template and its compatriot, {{cite AV media}}, need reworking, primarily because of |people= and |others=. I have sometimes thought that a very carefully curated list of the various role parameters that we once had might be brought back as unique parameters for these two templates because we now have an infrastructure that might, with a little tweaking, support them properly. So, were it me, I would rewrite the citation at Star Wars: Shadows of the Empire (video game) like this: {{Cite AV media notes |author=<!-- not stated --> |title=Star Wars: Shadows of the Empire | title-link=Star Wars: Shadows of the Empire#Soundtrack |year=1996 |publisher=]}} Star Wars: Shadows of the Empire (Media notes). Varèse Sarabande. 1996. —Trappist the monk (talk) 23:13, 6 February 2022 (UTC) No doubt someone will say yeah I'll be that someone I guess. When the AV media in question has a unique title sure you don't need an additional name, but that's not always the case. How many compellation albums are just titled The Best or live albums are just Live at ? Or have popular titles like Closer ? Maybe there was only one album with that year from that record company, and maybe there is some sort of ID (is there precedent for citing UPC in a bibliography?), but it seems useful to have the option to provide the name of a person associated with the album if the person writing the citation thinks it is necessary to locate a source. FWIW CMoS says to cite liner notes just by citing the album (which they say can begin with the performer, conductor, or composer depending on which is most relevant in discussion), with "(liner notes)" at the end -- which I think I disagree with if there is a listed author, but I was just curious what other style guides said. Umimmak (talk) 23:48, 6 February 2022 (UTC) I have used |id={{UPC}} or |id=record-label-catalog-number (along with |publisher=record-label-name). As for the generic work titles, in my experience, the proper full title is always "Best of (Artist)" or "(Artist) Live at (Venue)" and the work can be found with this correct title. 68.173.76.118 (talk) 01:18, 10 February 2022 (UTC)

url-status having a value "live" in the absence of an archive-url

I am seeing this being reported as an error all over the place (I have the green error display enabled) and I think the problem with most of them is that the Visual Editor defaults the url-status to be "live" rather than omit it. It might be simpler to not regard it as an error, because at the point at which most people create a web citation, the url is live. And later it may be dead, but isn't it a statement of what's going on with the url independent of what's happening with the archive-url? Or ask the Visual Editor team at phabricator to omit the url-status in the absence of an archive-url value. For myself, I would see the opposite as a bigger problem, where there is an archive-url value but no url-status value. Kerry (talk) 06:04, 8 February 2022 (UTC)

Maintenance messages are not error messages. |url-status=<anything> has no meaning or value when |archive-url= is omitted or empty. |url-status= is a control parameter that tells the citation template how to link the value in |title= (and the archive-associated static-text) when the template also has |archive-url= with an assigned value: |url-status=live – use the value in |url= to link |title=; link 'Archived' static-text to the value in |archive-url= |url-status=dead or |url-status=deviated or omitted or empty – use the value in |archive-url= to link |title=; link 'the original' static-text to the value in |url= |url-status=unfit or |url-status=usurped – use the value in |archive-url= to link |title=; do not link to the 'original' static text Without |archive-url=, |url-status= does nothing except needlessly occupy space in wikitext and consume a few processor cycles. We can assume that a url is live when it is first inserted into a cs1|2 template so there is no need to state the obvious. Similarly, the presence of |archive-url= with an assigned value indicates that the value assigned to |url= is dead. Again, no need to state the obvious. —Trappist the monk (talk) 15:44, 8 February 2022 (UTC) I am pretty sure this has been fixed of late with a change to the TemplateData? Izno (talk) 19:27, 8 February 2022 (UTC)

VE would explain why they are so common. I've been deleting by bot for years, incidentally treated as cosmetic. If it's now producing a green message it's no longer cosmetic. The idea of a permanent bot to remove these is probably untenable as the number of edits would be so frequent as to cause certain backlash - they will keep showing up even in the same article over and over. The community won't abide by bot removal at the rate required, and they won't like the green message because it's so frequent. My initial thought is squelch the green message and enlist the help of bots and tools to add to their standard fixes while making other edits. -- GreenC 19:01, 8 February 2022 (UTC)

Also, some/many will use |url-status=dead to flag the URL is dead instead of {{dead link}}. This is wrong, but common. We could perhaps look at those more carefully for conversion to {{dead link}}. GreenC 19:06, 8 February 2022 (UTC) When |archive-url= is empty or omitted, and when |url-access= has been assigned one of its valid keywords (dead, deviated, live, unfit, usurped, or the bot specific bot: unknown) cs1|2 will add the article to Category:CS1 maint: url-status. —Trappist the monk (talk) 19:32, 8 February 2022 (UTC) If I understand how |url-status=live is ('was', I hope) added, it was only added by when ve added a {{cite web}} template and only because the TemplateData had "autovalue": "live",; see Wikipedia:TemplateData/Tutorial § Completing the TemplateData information. I removed the "autovalue": keyword from the {{cite web}} TemplateData so, if I'm right, ve should not continue to pointlessly add new instances of |url-status=live. —Trappist the monk (talk) 19:23, 8 February 2022 (UTC) That's good. A VE problem we can resolve. -- GreenC 02:22, 9 February 2022 (UTC) Well, it seems from the discussion above that "url-status" isn't a very good name for the field as it's not just about the status of the url (does it go to content expected or not) as much as a directive on how to present the archive-url so it's probably no wonder that people set the value manually wrongly to be live/dead. Maybe if the field name and the names of values are more reflective of the role it plays, it might be clearer to people what to do or not do with it. Kerry (talk) 04:31, 9 February 2022 (UTC) Could be. Something like |archive-display= (or -placement, -format, -render, etc.); keeps it in the archive-* family which cements the three together. Most arg names describe the data they hold ("title" contains the title), but there are a few display options that are comparable, determining how the template displays. For the value names, not sure what would be clear. |archive-display=first is pretty abstract as is |archive-display=dead. GreenC 05:21, 9 February 2022 (UTC) I agree that "url-status" could motivate users to add a status even when it is not needed. What would happen if we just ignore the status when it does not make the template do anything? Like |url-status=live? Meaning the template will not show an error/maintanance message/category? In most cases IABot will handle the status and I think it should be able to change "live" to "dead" if/when the url dies. On dawiki someone argued that even if the url is alive it could be a good idea to add a link to an archived version because then users could just click that link if the url dies tomorrow. --MGA73 (talk) 11:37, 9 February 2022 (UTC) We struggled to find a better name. If you know a better name, don't keep it to yourself. Here is some history: 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? Help talk:Citation Style 1/Archive 55 § Deprecated subscription= Help talk:Citation Style 1/Archive 57 § deprecate |dead-url= and |deadurl= —Trappist the monk (talk) 12:44, 9 February 2022 (UTC)

Semi-protected edit request on 12 February 2022

Ruf3346 (talk) 00:42, 12 February 2022 (UTC)  Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Izno (talk) 00:43, 12 February 2022 (UTC)

How to have multiple URLs for the same source (e.g., for discontinuous pages)

Sometimes multiple URLs are useful to direct the reader to multiple pages within the same source. I've found it useful mostly in early work in natural history when the reader might also want to see an associated plate for the text, e.g. (with irrelevant parameters removed):

This also is occasionally useful when citing articles in newspapers when an article is continued on a page very far from the initial one. I don't have an example off-hand, but for older newspapers there quite often isn't a single URL for the entire source, rather you're linking to individual scanned pages and if the article is on A1 and A42 it can be convenient to the reader to have a URL to both pages.

However neither putting a url in |page= or |postscript= seems to be approved so I was wondering what the way to cite sources like this would be in a way that doesn't require the reader to have to put in the effort to find a second page that can be quite far from the first. It seems when people fix "External link in |<param>=" they often just remove the URL which I think ends up being a net loss. Is there a "right" way I can include multiple links within a single citation parameter? Umimmak (talk) 04:53, 26 January 2022 (UTC)

URLs in |page= are still supported without error messages. URLs in |postscript= have never been supported, as far as I know. |postscript= Controls the closing punctuation for a citation, and the modules have gradually been adjusted to detect nonconforming text. Editors are always free to add more information after the closing braces of the citation template. – Jonesey95 (talk) 05:01, 26 January 2022 (UTC) Okay that makes sense. I wish people fixing these errors didn't just remove the URLs then but noted about the ways this can be resolved, thanks. Umimmak (talk) 05:11, 26 January 2022 (UTC)

Fails to display collaboration

* {{cite journal | collaboration=GBD 2016 Disease and Injury Incidence and Prevalence Collaborators | title=Global, regional, and national incidence, prevalence, and years lived with disability for 328 diseases and injuries for 195 countries, 1990–2016: a systematic analysis for the Global Burden of Disease Study 2016 | journal=The Lancet | volume=390 | issue=10100 | year=2017 | doi=10.1016/s0140-6736(17)32154-2 | pages=1211–1259}}

Displays as

instead of the expected

(which should generate a harv anchor)

Likewise

* {{cite journal |last=Smith |first=J. |last2=Smith |first2=K. |last3=Smith |first3=L. | collaboration=Foobar Collaboration |year=2020 | title=Article of Things | journal=Journal of Things | volume=1| issue=2| pages=3 }}

still erroneously display as

instead of the expected

Headbomb {t · c · p · b} 16:49, 12 February 2022 (UTC)

In the first case, there is a missing parameter "last"/"author" etc. which is apparently a requirement. Not familiar with the rationale behind it. The second case rationale would be (I guess) that 3 authors are not enough to be grouped as a "collaboration"? Again, what goes in an author-type parameter in the case of collaborations (groups) is expected to be the main or principal authors. Conjectures based on the current template doc. 68.132.154.35 (talk) 00:05, 13 February 2022 (UTC) You still did not show sufficient consensus for a change (and what change). You know the drill. Izno (talk) 00:24, 13 February 2022 (UTC) See WP:BURO. This is fricking common sense. If you specify 15 is that enough? What about 28 authors? In all cases you'll have a full list of authors and et al will be appended despite all authors being listed. The template does not need to override what is being inputted. Headbomb {t · c · p · b} 15:57, 13 February 2022 (UTC) No, no it's not common sense. Anyway, BURO would be a great link for someone who thought it had merit, but I don't, and it's trivial to point to recent discussions that have demonstrated these modules are the wrong place to cite it. As I said, get consensus. --Izno (talk) 18:26, 13 February 2022 (UTC) It is common sense, where's your consensus for the current behaviour? This wasn't the behaviour requested back then, and still is not the desired behaviour now. Headbomb {t · c · p · b} 18:39, 13 February 2022 (UTC) (edit conflict) History: I'm not seeing a clear consensus that |collaboration= should change. If that consensus exists and I'm just blind to it, I'm not seeing a clear determination of what should change and how it should be changed. —Trappist the monk (talk) 00:39, 13 February 2022 (UTC) It's simply, display |collaboration= if there's no author set, as an alias of |author=. And if there are authors set, don't append et al. automatically. Headbomb {t · c · p · b} 18:41, 13 February 2022 (UTC)

Supplemental material

Where to put the supplemental material of a source? In the article Dorfopterus (and in many others) there's a source, Lamsdell & Braddy 2009, which is cited alongside its supplemental material. I have commonly put this information on the |location= parameter but this now gives an error on the template. Is there any appropiate place to put this info, and if not, could it be given its own parameter? Super Ψ Dro 12:56, 13 February 2022 (UTC)

The parameter |location= refers to place of publication, it is not about an in-source lication. Where is the pertinent (verifying) information? If it is not in the supplement then this need not be cited. If it is in the supplement, you can cite the supplement in parameter |at= or |department= and insert that doi only. If there is verification info in both the article and the supplement, I would use for the supplement a short reference. In short refs the |loc= (location) is actually (and admittedly confusingly) referring to in-source location. You can insert the suplement doi there.68.173.76.118 (talk) 14:02, 13 February 2022 (UTC) Reading more carefully, I see that the supplement doi is actually cited at a short reference. That is sufficient, if it verifies the related wikitext. The supplement info at the full reference should be removed. If I may point out, citations are supposed to quickly and easily lead the reader to a single verifying source, they are not bibliographic references. 68.173.76.118 (talk) 14:18, 13 February 2022 (UTC)

i18n |script-<param>= error message supplements #2

Re: Help talk:Citation Style 1/Archive 79#i18n |script-<param>= error message supplements.

I said that I did that but apparently, I did not. So, now I have. See Special:Diff/1071711376.

—Trappist the monk (talk) 14:45, 14 February 2022 (UTC)

Lay-url

'Lay-url' is mentioned as deprecated (CS1 maint as well) however it's documented in the parameter list (cite book). Presumably should be removed? Neils51 (talk) 00:00, 23 January 2022 (UTC)

 Done. – Jonesey95 (talk) 00:18, 23 January 2022 (UTC) |lay-url= is also recommended in Wikipedia:Identifying reliable sources (medicine) (the WP:MEDPOP section). WhatamIdoing (talk) 16:44, 26 January 2022 (UTC) left a note at: Wikipedia talk:Identifying reliable sources (medicine) § |lay-url= etc —Trappist the monk (talk) 16:57, 26 January 2022 (UTC) Please see discussion at WT:MEDRS (and please avoid using pipes in section headings, since the rest of us mere mortals don't know how to link to them). SandyGeorgia (Talk) 19:21, 26 January 2022 (UTC)

Please point me to where the consensus was formed to remove this. SandyGeorgia (Talk) 17:29, 26 January 2022 (UTC)

Likewise, why was this parameter deprecated? Boghog (talk) 19:06, 26 January 2022 (UTC)

Out of curiosity, why was it considered to deprecate a parameter encouraged by a project without consulting said project beforehand? Hog Farm Talk 19:21, 26 January 2022 (UTC)

Particularly one that has been written into a very widely used and cited guideline, WP:MEDRS with

One possibility is to cite a higher-quality source along with a more-accessible popular source, for example, with the |lay-url= parameter of {{cite journal}}.

since at least the end of 2008 (that's a lot of years on a highly used guideline for a couple of editors to be undoing).WP:MEDRS has 389 page watchers, and has included the text about the lay source parameter, with text unchanged for all those years. When deprecating a parameter with such wide and long-standing acceptance, why is the page most affected not notified of the proposal? This de facto, fait accompli method of operating on citation templates should be addressed by the community more broadly. SandyGeorgia (Talk) 19:44, 26 January 2022 (UTC)

Went through WP:MEDRS carefully. Nowhere is it suggested that lay sources should not be cited by themselves. On the contrary it is suggested that such sources be cited alongside citations from "ideal" sources like peer-reviewed bio-medical journals. The document describes "ideal" sources but does not out of hand exclude others, including the popular press. To help non-expert readers (the vast majority of users, surely) find sources and verify wikitext, citations should be simple. A factor of simplicity is that a single citation should correspond to a single source (with one exception, for archived versions of the same source). Adding multiple sources to a single citation is confusing for both data entry editors and the citation consumers. It is also unwieldy. I suggest you look at this as someone who knows nothing of medicine, scientific literature, or citations. That will likely put you among the vast majority of this encyclopedia's readers. 68.174.121.16 (talk) 19:35, 26 January 2022 (UTC)

Nowhere is it suggested that lay sources should not be cited by themselves. It is equally true that nowhere it is suggested that lay source must be cited by themselves. Also, why is it unwieldy? I think bundling lay sources with the primary source is cleaner because it makes clear what is the primary citation, and what is layman's translation of the original source. And why is it confusing for editors? Quite to the contrary, the |lay-source= and |lay-url= parameters are self explanatory. Boghog (talk) 20:37, 26 January 2022 (UTC) While that's an interesting opinion about how MEDRS is applied, it doesn't address the core issue here, which is that one to three editors make broad changes that affect the entire encyclopedia, without bothering to even notice the page where this long-standing parameter is recommended. SandyGeorgia (Talk) 21:09, 26 January 2022 (UTC) Here are a few previous discussions: There may be more in the archives of this talk page. – Jonesey95 (talk) 19:55, 26 January 2022 (UTC) Thanks for all of that. Which all confirms the concern that wide-ranging decisions are being made by a couple of editors, who don't even consider notifying the page where the parameter has been recommended for more than ten years. This is so disrespectful of so many editors. SandyGeorgia (Talk) 21:08, 26 January 2022 (UTC) The above list of links omits the village-pump notice of this change that was part of this rfc (in the gray collapse box under: changes in Module:Citation/CS1/Whitelist/sandbox (last update 2021-05-25). —Trappist the monk (talk) 00:30, 27 January 2022 (UTC) Yes, we’ve seen that RFC. How/who gets consensus out of that ? Who closed the RFC? Who determined that amounted to consensus, with split opiners? SandyGeorgia (Talk) 00:39, 27 January 2022 (UTC) I also wonder if the use of English, rather than code and terminology, might allow more of us to access more of same. For example: RFC on proposal to change citation templates. SandyGeorgia (Talk) 00:40, 27 January 2022 (UTC) You mean the RfC that was closed with the comment there is no consensus on removal of deprecated parameters in this discussion? --Ahecht (TALK
PAGE) 16:36, 27 January 2022 (UTC) This change didn't remove any deprecated parameters. They're still there, and they still work. The only thing that's happened is that the template now adds a red warning message to the article. WhatamIdoing (talk) 16:49, 27 January 2022 (UTC) It does not seem acceptable to deprecate a parameter that is widely in use without gaining a broader consensus than was obtained in this case. Most of the people who have been using this parameter for years had no idea that there were discussions to remove it. Since it is recommended by the medicine wikiproject and considered useful by many medicine editors, I do not think it is permissible to remove it. (t · c) buidhe 21:52, 26 January 2022 (UTC) widely in use. Let us look at that. As I write this, there are: |lay-date=, |lay-format=, |lay-source= and |lay-url= may be in use, but widely in use, they are not. it is recommended by the medicine wikiproject and considered useful by many medicine editors. Of course, but that does not make use of |lay-url= and related parameters a proper thing to do. Cite bundling is nothing new and is a better way to provide a lay-source companion to a preferred source. All that is needed is to write a correct cs1|2 template for the lay source and bundle it with the preferred source citation (adding |type=Lay source (or some similar text) would serve to differentiate the pair. Bundling would allow more than one lay source were that desirable. I can imagine a {{cite lay source}} wrapper-template that accepts all cs1|2 template parameters plus one |template=book | magazine | news | journal | ... parameter and automatically sets |type= to the preferred indicator text or, perhaps, adds a 'Lay source:' prefix to the rendering. You-all should stop looking at change as a bad thing and recognize that your world could be better. —Trappist the monk (talk) 00:30, 27 January 2022 (UTC) Thanks for posting the statistics. That matches my impression that it is used in certain circumstances, but not very widely. I suspect that it is also used less now than it used to be, even though there have been some great lay summaries of COVID-related sources during the pandemic. WhatamIdoing (talk) 00:34, 27 January 2022 (UTC) Here is another number: 459. That number represent the total number of WP:MED articles that use |lay-url=. I got that number by using WP:AWB and the no-limits plug-in to fetch a list of all article talk pages listed in Category:All WikiProject Medicine articles (because the talk page is where an article's association with WP:MED is established). I used AWB to filter out all non-mainspace talk pages. That left me a list of 48,726 talk pages. I used an external text editor to strip the 'Talk:' prefix and to convert the list into a format that a Lua module would understand. Then I fetched the list of articles that use |lay-url= and used the external text editor to make a Lua acceptable list. The lists are in Module:Sandbox/trappist the monk/layurl/data. I wrote a simple lua function to one-after-another, fetch a title from the articles_using_layurl list and look for that title in the wp_med_articles list. The code to do that is at Module:Sandbox/trappist the monk/layurl. You can see the list of wp_med_articles_using_layurl with this: {{#invoke:Sandbox/trappist the monk/layurl|main|list=}}. —Trappist the monk (talk) 14:54, 27 January 2022 (UTC) And two more numbers: 2 and 22. These numbers represent the total number of FA- and GA-class WP:MED articles that use |lay-url=. The lists for these were taken from Category:FA-Class medicine articles and Category:GA-Class medicine articles. —Trappist the monk (talk) 15:35, 27 January 2022 (UTC) This change is one of many that happened in the latest update. There was an RFC at the village pump about it, which is generally considered a sign of gaining broader consensus, even if most of the discussion was about other aspects of the changes. (That might be a sign that CS1 updates should happen more frequently, so that each change is smaller.) WhatamIdoing (talk) 00:31, 27 January 2022 (UTC) It could be a sign that we should hold an RFC restricting changes to citation templates until/unless a broadly advertised community-wide RFC closed by independent closers and advertised at WP:CENT using plain English is held. We have thousands of errors now at the GA and FA level, no idea how many all over the Wikipedia, because someone’s personal preferences were installed. (PS the data above does not likely reflect those that editors have already spent the last few days changing). The attitude that 2,300 articles, and 300 FAs, and thousands of GAs are insignificant is … special. SandyGeorgia (Talk) 00:57, 27 January 2022 (UTC) Well, there are other ways of looking at this. These are some facts: WP:V is a cornerstone policy. Citation systems are tools to apply the policy. These tools should be as easy and simple to use as possible, for both the small minority of editors and the far greater majority of readers. It is no use trying to verify something if the verification process is confusing or convoluted, or in any case not immediately obvious as far as possible, to the non-expert reader. Please try to understand that people involved in this area look at the overall impact. I'm sure your project could devise a far more comprehensive data-entry form (that is what these templates are) that is well-tailored to your area of interest. If you are so inclined, please do design one, nobody is stopping you. However, this citation system is a general-purpose system that purports to help turn wikitext somebody wrote to fact verifiable by the average reader. The focus is on simplicity, ease and speed. Are you saying that a citation that guides the user to a multiple-choice of sources is more effective, efficient, and understandable than a simpler one that immediately leads the reader to the proving source? And as far as entering data in these templates is concerned, doesn't the probability of error increase with every additional piece of info the editor enters? Assuming that the editor can keep these sources in sync. If there is one RfC that perhaps should be initiated is one that largely decouples the development of the proving function from special interests such as your project. This is stated without any adversarial inclination or any intent to insult. Your input about citing medical sources is invaluable, and I believe everybody here would listen carefully, and try to apply it as much as possible. But experts in any field are comfortable with complexity in their field. The job of citation designers in Wikipedia should be to simplify. I would suggest you let them do that. 68.173.76.118 (talk) 02:02, 27 January 2022 (UTC) 68, someone from WP:MED did design a template. Their name was User:Eubulides, they were behind the lay parameter, and they helped write MEDRS. And it was recommended in MEDRS for more than ten years. And now it has gone poof from a widely respected guideline page as per the desires of about three editors and for reasons yet to be explained other than personal preferences. The parameters someone from WP:MED did design allowed for exactly what medical content sourcing needs, which is not to be adding full citations to lay press. Izno’s idea to add a second citation to the lay press, even if bundled is a) just as hard for novice editors to understand or implement, and b) likely to lead to encouraging citations to the laypress that breach MEDRS. SandyGeorgia (Talk) 02:32, 27 January 2022 (UTC) In June 2021 I said there were 2300 uses of the parameter. Today's number reflects that number fairly reasonably. Regarding "require an RFC for every change", the last RFC literally closed a week ago said "no, we don't want that". As Ttm has said, these can be supported today by filling out a second citation template using any of the available bundling mechanisms (including simply putting two templates inside one <ref> statement). This allows the editor to provide the full citation data for the lay source so that those sources can be assessed for their own quality of use (as they should be) as well as for their (re)findability. Izno (talk) 02:18, 27 January 2022 (UTC) Who is Tim? So you assume editors who can’t manage a parameter can manage a bundled citation, and you encourage citing medical content to the lay press? SandyGeorgia (Talk) 02:34, 27 January 2022 (UTC) Ttm. Do not put words in my mouth (see passive aggression). I did not say "cite medical content to the lay press", and you may trivially reread what I did say to confirm it. If anything, the lay-* parameters already encourage "citing medical content to the lay press". These parameters are apparently that MED wants their cake and to eat it too (both ban mediocre sourcing while also providing parameters... for mediocre sourcing). That is fundamental inconsistency on your part. (If in fact you did not mean to be passive-aggressive, here is some phrasing you can use instead to indicate that you have interpreted X as another statement Y: "I understand what you said (X) to mean 'Y'. Is that correct?") I have not made any point regarding whether an editor can manage a bundled citation, an unbundled citation, or otherwise, though if you wish to ask me about it: I would personally suggest that |lay-url= is so specialized that no average editor is going to use it regardless, so your point is essentially irrelevant. Hence why it's been used only some 2000 times in nearly 15 years. Izno (talk) 02:56, 27 January 2022 (UTC) Do not put psychiatric labels on other editors. My apologies for my eyesight on the Tim. Yes, your suggestion encourages sourcing to laypress, by writing a citation template to laysources; you appear to presume all/most editors understand citation bundling and the difference. Regarding the characterization of med editors having their cake and eating it, too, see the aformentioned reference to passive-aggressive discussion. And only is still disrespectful. SandyGeorgia (Talk) 03:02, 27 January 2022 (UTC) Citation bundling would look something like this: <ref>{{cite journal |last=Expert |first=Alice |url=https://www.example.com/extra-peer-reviewed-paper |title=Systematic Review of Scientific Papers |work=Journal of Imp. Sci. |date=December 2021 |pmid=1234567 |doi=10.1136/bmj-2021-066995}} Lay summary in: {{cite news |last=Journalist |first=Joe |url=https://www.example.com/news-article |title=Explainer: Latest Scientific Breakthrough |date=15 December 2021 |work=Big Times}}</ref> and it would look something like this to any reader who happened to look at the: You could add a line break or other formatting to separate the two more obviously if you wanted to, but I think it would not be a disaster. WhatamIdoing (talk) 03:40, 27 January 2022 (UTC) I know how to bundle citations. Most people reading this page probably know how to bundle citations, because we’re in a backwoods obscure part of Wikipedia. What do we accomplish with this besides a) removing an easier way to do the same, and b) obscuring the lines of acceptable medical sourcing to novice editors, and c) opening the door for those citations to later become unbundled and separated? We had a method perfectly tailored to MEDRS needs, and I’ve yet to see a logical reason for the removal. SandyGeorgia (Talk) 03:52, 27 January 2022 (UTC) I won't comment on the whether or not using lay-url is easier, as I don't know about this parameter. Solely on the question of what a newbie would do, personally I think putting two citations in one footnote is the obvious thing to do if you want to use two citations to refer to the same underlying source. The citation to the lay summary doesn't necessarily need to use a template: it could just be some plain text that links to the desired location. I appreciate there may be other reasons for wanting to have a specific parameter in the citation template. isaacl (talk) 04:24, 27 January 2022 (UTC) The entire point of WP:CITEVAR is that editors should be able to choose how they format their refs, while mass changes to references are disallowed. Deprecating parameters in this way is an end run around CITEVAR because it disallows certain ways that many editors format refs, and if implemented will force changes to thousands of articles based on the preferences of a few people in poorly attended discussions. (t · c) buidhe 03:29, 27 January 2022 (UTC) Except to the extent that CITEVAR discourages edit warring over the use of citation templates vs manually formatted citations, it is not meant to (read: "I did not mean to, and I wrote CITEVAR") control details such as, how, exactly, an editor achieves the thing that the reader sees. Also, CITEVAR currently contains a potentially relevant exception: "except when moving away from deprecated styles". WhatamIdoing (talk) 05:00, 27 January 2022 (UTC) Hence, the end run (don’t like a citation style, get it deprecated on no to minimal consensus). Game over. SandyGeorgia (Talk) 05:02, 27 January 2022 (UTC) The parameters were deprecated as part of a VPR RFC (VPR has 3,500 page watchers) that was linked from this page. – Jonesey95 (talk) 05:17, 27 January 2022 (UTC) Yes, but the expect behavior outlined at Wikipedia:Requests for comment#Publicizing an RfC includes From the comments that I am reading above, it seems many of the affected WikiProjects were not notified. It is all well & good that VPR has 3,500 watchers, but that's like 2.75% & 0.008% of active users & all users respectively. I would wager that there are far more active users who are part of affected WikiProjects. Peaceray (talk) 07:19, 27 January 2022 (UTC) Hmm, I can't help but notice that neither Template:Cite journal/doc nor its archived version mention that lay-summary is important to the medicine project, or even hint at it. Jo-Jo Eumerus (talk) 10:39, 28 January 2022 (UTC) It has almost always been sufficient to say that a proposal is sufficiently widely advertised when it is at one of our specific wiki-wide venues for such (WP:VPR), especially with a {{rfc}} tag. If you want to contest that, your best bet is at WT:RFC, not here. Izno (talk) 18:28, 29 January 2022 (UTC) What a twisted reading of WP:CITEVAR, deliberately or not. CS1/2 is its own templated style, and has always had the leisure of improvements to that style. This is functionally no different than when any other externally-published citation style itself says "we are changing how the format of our citations", such as when MLA decided that it would no longer require the specific URL in its web citations (instead preferring "Web" literally). The only difference is that we can effect the particular consensus change here near-instantaneously. Izno (talk) 18:33, 29 January 2022 (UTC)

A proposal

A med-specific wrapper to {{citation}} or any other appropriate CS1 template. The wrapper may add parameters more specific to medicine. Under the condition that native CS1 templates that lead to lay sources are not invalidated or considered "inferior". The rationale for this condition is as follows:

Assuming that such a wrapper template is designed and used alongside the native templates, I suggest that in keeping with the above, the template presents the lay source as the main source, and the expert source as additional: as the one the lay source is based on. 65.88.88.47 (talk) 15:29, 27 January 2022 (UTC)

This is pretty much what I was suggesting above when I suggested {{cite lay source}}. So, I've hacked {{lay source}}. Different name because these sources apparently do not want to be viewed as 'citable'. {{lay source}} requires its own parameter |template= which gets the name of the cs1|2 template that is appropriate to the lay source; defaults to {{cite web}} if omitted. Otherwise, {{lay source}} accepts any cs1|2 template parameter except |ref= (so that the rendered lay citation can't be linked-to from the article text by {{sfn}}, etc). Using Editor WhatamIdoing's example from above we would write: {{lay source |template=cite news |last=Journalist |first=Joe |date=15 December 2021 |title=Explainer: Latest Scientific Breakthrough |work=Big Times |url=https://www.example.com/news-article}} Lay summary in: Journalist, Joe (15 December 2021). "Explainer: Latest Scientific Breakthrough". Big Times. No pretty error checking yet. Not needed. I suck a documentation but there is some now. —Trappist the monk (talk) 17:01, 27 January 2022 (UTC) 19:23, 27 January 2022 (UTC) (documentation mention) This is pretty much what I was suggesting above when I suggested {{cite lay source}}. Indeed. However, I thought this proposal would be more readily accepted if the interested parties had the lead in designing the wrapper. Also, if a lay source is judged reliable after scrutiny (i.e. represents salient facts correctly and without bias) it is as eminently citable as any other so-judged reliable source. Including sources such as scientific journals. More so, I would think, if the source is more readily understandable and therefore more likely to prove the wikitext verifiable to the reader. 65.88.88.69 (talk) 18:22, 27 January 2022 (UTC) Inertia, I think, will keep interested parties from taking the lead in designing the wrapper. As for the eminently citable case: switch {{lay source |template=cite <whatever> ...}} to {{cite <whatever> ...}} and suddenly, a normal cs1|2 template. —Trappist the monk (talk) 19:23, 27 January 2022 (UTC)

I don’t think a help talk citation page is the place to rewrite, reinterpret, and redefine a 15-year-old guideline, which is what the entire discussion above is doing. SandyGeorgia (Talk) 06:23, 28 January 2022 (UTC)

Isn't this a bit dramatic? The only change is adding/substituting a reliable lay source as standalone. Which is half-a-change since the guideline does not expressly forbid it. And also conforms to the simple rule of one source per citation, as the most accessible sort of citation. 71.247.146.98 (talk) 13:32, 28 January 2022 (UTC) This proposal puts a lay source (non-peer-reviewed) on the same footing as a MEDRS-compliant source. If you want to propose that, the place is at WT:MEDRS, not here. SandyGeorgia (Talk) 15:58, 28 January 2022 (UTC)

B proposal

RestoreUn-deprecate |lay-url= and related parameters pending consensus on their deprecation per WP:BRD. Their deprecation was based on an all-or-nothing RFC where the closure specifically said there is no consensus on removal of deprecated parameters in this discussion, deprecating the lay- parameters was buried in a list of 60 other items, and the relevant talk pages (WT:MEDRS, WT:WikiProject Medicine) were not notified. While the RFC came to the conclusion that most typical changes to cs1/2 are uncontroversial and don't need to undergo routine VPR RfCs to be rolled out, it's clear from the above discussion that this particular change was non uncontroversial. --Ahecht (TALK
PAGE) 16:35, 27 January 2022 (UTC)

@Ahecht, we don't need to "restore" it, because it's still there and still working. WhatamIdoing (talk) 16:50, 27 January 2022 (UTC) "Restoring" here means to stop throwing red deprecation errors. Headbomb {t · c · p · b} 17:21, 27 January 2022 (UTC) @WhatamIdoing: That seems like a half-truth. Technically, they are still there, but the change in code is currently producing {{cite book}}: Cite uses deprecated parameter |lay-date= (help). Peaceray (talk) 17:38, 27 January 2022 (UTC) That seems to be a Catch-22: If they leave the code working, but they show you a red error, then we complain that they're telling us about plans to remove the code in the (perhaps distant) future. But if they don't show us a red error, then we will complain that they never told us about it. See also VPT last year, when Javascript that's been deprecated for seven years was finally removed, and script writers came out of the woodwork to complain that nobody had ever told them, and that they couldn't possibly be expected to read the many public notices, follow any of the discussions, or check for error messages themselves, because if their code worked in 2011, then it really ought to keep working until the heat death of the universe. As you can tell, I'm not impressed with their claims. WhatamIdoing (talk) 18:00, 27 January 2022 (UTC) That is true. This has produced a far different reaction the JavaScript situation, as this blow back has been immediate. We should be grateful that there are the deprecation errors to warn us. What is unclear is the path for backing out what appears to be an unpopular deprecation. I propose we change the language from: Restore |lay-url= and related parameters pending consensus on their removal per WP:BRD. to: Undeprecate |lay-url= and related parameters pending consensus on their removal per WP:BRD.
Peaceray (talk) 18:41, 27 January 2022 (UTC) I would emphasize appears to be ... unpopular. I would not expect supporters of the deprecation to raise banners across Wikipedia. Not wanting to minimize your concern, but several imo workable alternatives have been suggested. 65.88.88.69 (talk) 18:53, 27 January 2022 (UTC) Peaceray, I strongly recommend against trying to make anyone do anything "per BRD", as BRD is explicitly an optional process. Wikipedia:What editors mean when they say you have to follow BRD is quite different from what BRD actually is. The relatively low level of page views suggests that less than 1% of editors have actually read BRD, so I suppose we shouldn't be too surprised if people cite it as proof that you have to do the opposite of what it actually says. Otherwise, I think that's a not unreasonable request (i.e., un-deprecate until it's been discussed separately). I might emphasize request, though, as the citation templates are a serious piece of engineering these days (so it might not be as easy as I hope), and even if it is easy, Ops may not be happy if we change them every time someone dislikes a change. If the request isn't granted, we could have the discussion anyway. The order in which the two things happen isn't actually critical. WhatamIdoing (talk) 20:27, 27 January 2022 (UTC) All reference to the lay-*parameters could also be removed from the CS1/2 docs and helps to discourage usage, except in medical articles. AManWithNoPlan (talk) 20:33, 27 January 2022 (UTC) AManWithNoPlan, where are you seeing lay-* parameters in CS1/CS2 documentation, aside from notes about their deprecation? – Jonesey95 (talk) 21:05, 27 January 2022 (UTC) I meant "do not add them back to docs". Thank you for the clarifying question. AManWithNoPlan (talk) 21:23, 27 January 2022 (UTC) @WhatamIdoing: I was specifically swapping out the word Restore for Undeprecate while leaving intact the rest of Ahecht's original proposal. I am open to any alternative wording for the B proposal that moves us towards the goal of un-deprecating the lay summary parameters. Would you please suggest an alternative wording, if you are so inclined? Peaceray (talk) 23:31, 27 January 2022 (UTC) I think the proposal you want to make is just "Undeprecate |lay-url= and related parameters". Or even "Keep |lay-url= and related parameters". WhatamIdoing (talk) 21:47, 29 January 2022 (UTC) The talk about "blowback" and “pitchforks” and if you “know a fourth way” is unhelpful, since the whole problem could have been avoided by notifying relevant pages, which is the kind of courtesy that is commonly expected in all areas of Wikipedia. The justification for removal (or at least the only one I've seen) that the template was only used a few hundred or thousand times is a testament to how seriously MEDRS is taken; we don't add lay sources lightly, and when we do, they should not appear to be a citation, rather an adjunct. The parameter that was there was doing precisely what it needed to do. Whichever word is used (restore, undeprecate, undo, fix, correct this problem), please undo what was done, and please in the future find better ways of communicating. If this isn't undone quickly, please provide a list of articles at WT:MED so interested editors can remove the unsightly errors, affecting our readers, without having to interpret some code to generate the list ourselves. SandyGeorgia (Talk) 06:39, 28 January 2022 (UTC) Ttm, thank you for posting the list at WT:MED, but that means that the disputed remedy at the cite journal template now needs a disputed tag, lest editors start making those recommended changes. SandyGeorgia (Talk) 15:35, 28 January 2022 (UTC)

*::.... However, there may not be enough editors to get sufficient input. To get more input, you may publicize the RfC by posting a notice at one or more of the following locations:

The word is may and clearly used in the sense to find more editors, not to lay it down as a requirement. Even if we take it as an attempt at "requiring" language, it is neither the strong auxiliary verb must nor even the slightly-weaker should, it is framed entirely as an option. An option that was taken at WP:VPR where it was held. That is sufficient in either interpretation of the language. Izno (talk) 18:37, 29 January 2022 (UTC)
  • Support I happen to believe this extends beyond MEDRS. We often cite rather technical sources, & it is useful to users to have access to a lay summary of such a source. To separate the two into separate citations omits the linkage between the two. Peaceray (talk) 17:52, 29 January 2022 (UTC) What is a citation to you? Is it the text between a single <ref>? Is it the single use of a template? If it is the former, than having two descriptions <ref>{{cite journal|journal=Journal|title=Title}} Lay summary: {{cite news|title=Title}}</ref> or <ref>{{cite journal|journal=Journal|title=Title}} {{lay source|title=Title|url=https://example.com}}</ref> is clearly sufficient. If it is the latter, that comes up with a wider issue that your use of the templates does not describe the overall training objective that we stress here regularly and with which basically no people have had a real issue, and which is valuable for new- and old-comers alike: a single citation template covers a single source. It does not cover multiple. Right now you are trying to treat the lay source as part of the 'real' source, when you admit it is not by having the existence of these parameters. That's not good enough for what you should expect of the quality of your sourcing efforts. Izno (talk) 18:21, 29 January 2022 (UTC)
  • I have already expressed above my support for restoring this parameter, but I suppose I should formally lodge that here. SandyGeorgia (Talk) 17:55, 29 January 2022 (UTC)
  • Support I think the parameter has a function, and it's a bit of a hassle to replace it with an alternative which doesn't place undue emphasis on the less reliable lay source. Femke (talk) 20:14, 29 January 2022 (UTC)

    • Sample for discussion

    A good example, from the most recent medical FA, Menstrual cycle:

    The journal article is recent secondary review that complies with WP:MEDRS, and is what the text in the article is sourced to. The lay article from the BBC offers an overview in simpler language; an adjunct for the reader, but not something one would ever cite medical content to; even well written lay sources often have medical errors, and this one has a lot of opinion. But it serves to help the reader understand the terminology so they can then better digest the actual source should they care to (WAID is fond of reminding us that readers don't click on sources anyway). We provide it in a case like this for a simple overview, but we don’t source content to it. It's an adjunct, not a stand-alone, and not the source used.

    And while IP68 is stating that our sources have to be accessible; no they don't. The text we write based on our sources should be accessible; the statements about MEDRS above are reinterpretations of MEDRS, and if that is to be done, that should happen at WT:MEDRS. SandyGeorgia (Talk) 06:42, 28 January 2022 (UTC)

    After examining both sources, I would say that the lay source closely follows the journal article and seems much more understandable, without the technicalities of the expert source. The lay source seems reliable and informative, and verifies the wikitext where called to do so. Why not use it as the main source? Who is the audience for this? Bio-medical professionals? Don't they have extensive libraries of material they can consult easily? I believe that the compound citation is unnecessarily convoluted. If I want to verify the wikitext any one reliable source will do, assuming I can parse the cryptic citation. It could be, that this is just too much for the lay reader. Other than that, imo the article suffers from the same drawbacks like many other science-based articles as far as the expert source goes. It should be clearly stated in the article that this citation (and the wikitext supported by it) refers to a proposed model, that the authors argue explains the molecular origins, etc. In an encyclopedia targeting any reader such language is important; don't assume that readers implicitly know this is so. I must admit I don't give FA articles the benefit of the doubt. To me,FA status is a vanity project. 71.247.146.98 (talk) 12:47, 28 January 2022 (UTC) SandyGeorgia, thank you for providing this straightforward example of how to help readers by providing a link to a layperson's summary of a technical article. I think that the way you have formatted the link to the lay source is appropriate and helpful for readers, and it ensures that editors and bots will not confuse two URLs as intending to point to two versions of the same cited source. I would be happy to document this method on the tracking category page as an example of how to extract a lay-url and its title from an otherwise self-contained cite template, which is supposed to cite and link to a single source. – Jonesey95 (talk) 14:10, 28 January 2022 (UTC) Forgive me for interjecting here, but where is a "single" source? I see two sources, one a journal article and the other a rather incomplete something-or-other that is called a "lay summary", whatever that means to the "lay" user. Should I have a dictionary page open when I read Wikipedia? Seems so. 65.88.88.47 (talk) 16:42, 28 January 2022 (UTC) Thank you, Jonesey95; it’s a bit of an extreme example because the topic is so dense, but hopefully serves as a good example nonetheless. IP71, it is our job to make our content accessible. It is not our job to judge the accuracy of non-peer-reviewed sources or to make sure our sources are accessible to all education levels; we do that in our text. (And the source is used appropriately in the text, where four models and their drawbacks are explained; but that is off-topic for this discussion.) SandyGeorgia (Talk) 15:33, 28 January 2022 (UTC) I beg to differ. Anyone can make any content accessible. But editors have an obligation to make content verifiable by the people most likely to access it. Having understandable wikitext is one part of it only. Having understandable sources that verify the wikitext completes it. Otherwise, if the source is unintelligible, the text is for all purposes unverifiable to the reader. It is also the editors' job to gauge the accuracy, objectivity and pertinence of any source, peer-reviewed or not, since these properties largely define reliability. As for the use of the source, I agree that this is another discussion. But my original skepticism remains: I was not referring to the content of the article. If its authors consider it an (scientific) "argument" that is putting forth "propositions", that should be made clearer. I believe few Wikipedia readers know how peer reviews work, and how a paper can progress from hypothesis to theory to application and perhaps to generally accepted practice. 65.88.88.47 (talk) 16:19, 28 January 2022 (UTC) So you are saying that sources must be accessible and understandable by anyone who looks at an article - that goes against WP:RS and WP:CITE - sources do not have to be accessable, to all, just to be verifiable if the reader puts the effort in - that's why we allow offline sources. If sources on what may be highly technical subjects have to be understandable by anyone, then we will effectively be abandoning the requirement for any sort of reliable sourcing, never mind the more cautious approach to referencing required by the community for medical subjects at WP:MEDRSNigel Ish (talk) 16:38, 28 January 2022 (UTC) IP65, if you want to change MEDRS, please go to WT:MEDRS to do that; this discussion is off-topic here, where a significant problem needs to be resolved. As Nigel Ish explains, we use the best sources; if one of the best is more accessible than the other, we prefer it, but we don't cite to the non-peer-reviewed lay press. SandyGeorgia (Talk) 16:44, 28 January 2022 (UTC) How can I verify something when I don't understand the item that purports to verify it? That hardly makes it a "best" source. In actuality, only in theory makes it a source, except for a small minority. Imo, the fact that citations exist for the benefit of readers, not editors, cannot be overstated. Is Wikipedia an academic publisher? A textbook service perhaps? Yet another journal? The reason for not raising this at the project page is because I think this is fundamental, and not restricted to one project or another. It is not because I am snubbing the project. 172.254.222.178 (talk) 18:29, 28 January 2022 (UTC) In that case, you could take up the discussion at the broader WP:RS talk page. In either case, you are proposing a re-interpretation of reliable sources. SandyGeorgia (Talk) 18:31, 28 January 2022 (UTC) This is incorrect. What is proposed is not at all re-interpretation of reliable sources. What it has been proposed all along, in one form or other is this: Everything else follows from that statement. 65.88.88.127 (talk) 20:50, 28 January 2022 (UTC) I believe that Jonesey95's suggestion is an extremely bad idea. Opens a Pandora's box of issues, once you go down that road. 65.88.88.47 (talk) 16:23, 28 January 2022 (UTC) Because the best solution is to simply undo this non-consensual change, where a parameter was provided to do exactly what was intended; an adjunct to a MEDRS-compliant source. SandyGeorgia (Talk) 16:45, 28 January 2022 (UTC) The proof being that, in 15 years, the lay parameter did not cause a “Pandora’s box of issues”. SandyGeorgia (Talk) 19:06, 28 January 2022 (UTC)

    Please add disputed tag to cite journal template

    I strongly oppose any remedy that involves converting lay-urls to actual citation templates. This is not what we should be doing in support of WP:MEDRS, but it is what the cite journal template currently recommends (based on zero consensus). The text at Template:Cite_journal#Deprecated is disputed; will someone please add the disputed tag to the protected template, lest editors begin doing just that? We don’t usually cite medical content to lay sources, and this method leads to doing just that. Lay-urls are adjuncts to medrs sources only. SandyGeorgia (Talk) 15:30, 28 January 2022 (UTC)

    @SandyGeorgia: The template documentation is only semi-protected, so you should be able to edit it by going to Template:Cite_journal and clicking the "edit" link at the top of the green box, or you can go to Template:Cite_journal/doc#Deprecated and edit from there. GoingBatty (talk) 16:03, 28 January 2022 (UTC) I’ve tried … there are layers I can’t figure out how to get through. Will try again, SandyGeorgia (Talk) 16:04, 28 January 2022 (UTC) Can’t do it … perhaps you can go in to edit mode and drill down to help me find what page I can actually edit. (This is symptomatic of what happens when regular editor have to engage these discussions; it’s all designed in such a way that … we can’t.) SandyGeorgia (Talk) 16:06, 28 January 2022 (UTC) @SandyGeorgia: I added {{disputed}} to Template:Cite journal/doc#Deprecated in this edit. Feel free to tweak the wording so it makes more sense. GoingBatty (talk) 16:17, 28 January 2022 (UTC) Thank you ever so much; I see where I went wrong. I was attempting to place the tag on the actual wording under “replace with”, and I can’t figure out how to get to that place. Thanks again, most appreciated, as the concern is that editors will start adding citation templates to medical content using lay sources, which is not on with MEDRS. SandyGeorgia (Talk) 16:22, 28 January 2022 (UTC) But it still wasn't showing when directly viewing Template:Cite journal, so I had to make a separate addition. I hope I haven't broken something :( SandyGeorgia (Talk) 16:34, 28 January 2022 (UTC) @SandyGeorgia: If you don't see the templates on Template:Cite journal, then try purging the page and/or your browser cache. GoingBatty (talk) 18:37, 28 January 2022 (UTC) I don’t think it was caching; I went to a different computer. I am now iPad typing from a hotspot; is there a duplicate now? SandyGeorgia (Talk) 19:00, 28 January 2022 (UTC) @SandyGeorgia: I added the template to Template:Cite journal/doc#Deprecated as you requested, and then you added it to Template:Cite journal/doc#Lay summary. Do you see both of those? Do you see these at Template:Cite journal#Deprecated and Template:Cite journal#Lay summary? GoingBatty (talk) 19:20, 28 January 2022 (UTC) Purged cache on iPad. If I click on your links above, I see them, single. If I go to Template:Cite journal#Deprecated, I see only the one I added. I’m sorry to be causing a problem; if we delete mine, I don’t see it on the cite journal page at all, where it is needed. Does it work to delete yours instead? Besides my general technical issues, being on an iPad is not helping … SandyGeorgia (Talk) 19:30, 28 January 2022 (UTC) @SandyGeorgia: Feel free to delete the template I created if you like. GoingBatty (talk) 19:43, 28 January 2022 (UTC) Are you seeing double? SandyGeorgia (Talk) 20:08, 28 January 2022 (UTC) @SandyGeorgia: As I said before, I see two templates on Template:Cite journal: The one I added in the "Deprecated" section of the documentation, and the one you added in the "Lay summary" section of the documentation. GoingBatty (talk) 20:12, 28 January 2022 (UTC) OK, then I’ll delete yours, but if someone can figure how to put the inline directly on the disputed text (below) they an delete mine as well. SandyGeorgia (Talk) 20:15, 28 January 2022 (UTC) The better option might be to put a disputed-inline after the text “ if the source named by these parameters is important to the Wikipedia article, create a cs1|2 template for that source with all of the appropriate bibliographic information”, which is what I wanted to do to begin with, but I can’t drill down to that level. SandyGeorgia (Talk) 20:10, 28 January 2022 (UTC) @SandyGeorgia: Oh, you wanted to use {{dispute-inline}}. Try adding it at Help:CS1 errors in the "Cite_uses_deprecated_parameter_|<param>=" section. I'll delete the {{disputed}} tag I added. GoingBatty (talk) 20:19, 28 January 2022 (UTC) Strike that - you already deleted the {{disputed}} tag I added. GoingBatty (talk) 20:21, 28 January 2022 (UTC) Yes, I am so sorry. I removed yours, then had to revert as that left none visible. I don’t understand what’s happening here, but I guess it’s related to the levels of programming in the templates. Yes, what I originally intended was only an inline on the actual test below. Feel free to remove anything I’ve added, as I can’t seem to get this right. But I can’t risk following your instructions to add it at Help:CS1 errors line, because I don’t understand the code on that page and fear I will really mess up something if I try that well end up with a broader problem than duplicate templates. I’m sorry for the trouble, and appreciate your help. SandyGeorgia (Talk) 20:25, 28 January 2022 (UTC) This should not have been done only at this obscure venue, and changes made here should be overturned until they gain wider approval. Johnbod (talk) 04:22, 29 January 2022 (UTC)

    What is the cost ?

    If I am understanding correctly, one of the reasons for removing the lay parameters was “cost”. What is this cost being measured in terms of? That is, is it server load, load time, template limits, what? And how much is the cost? Specifically, in relation to some other costs, like the craziness of having to edit around 80 parameters when a citation has 40 authors, rather than using et al. (a burden promoted by the cite templates. That creates an editing burden, as well as resulting in horrible citations). I don’t mind waiting for the explanation to allow time for it to be put in language we non-tech editors can understand, but please explain the burden created by this parameter, how is it measured, and put it in the context of other cite template burdens. Thanks in advance; the heat is considerably lowered when one feels heard and respected, rather than labeled in psychiatric terms. I’d appreciate understanding what the precise burden is. My apologies for piecemeal iPad typing. Regards, SandyGeorgia (Talk) 19:00, 28 January 2022 (UTC)

    A pertinent question, and somewhat ironic, in the desire for an understandable lay answer without all the expert mumbo-jumbo. After all this is a layman's encyclopedia... I guess I could be considered an expert, as someone involved with technology professionally and as a hobby for almost 50 years. Although I am not a software developer/writer here I can offer some real-world observations for whatever they are worth. So I will eventually try to give a proper answer. 65.88.88.127 (talk) 20:58, 28 January 2022 (UTC) As I write this sentence, the word cost is used 7 times in this whole page; once in this section's heading (and so once in the TOC), four times in Editor SandyGeorgia's initial post, and once by me in this sentence. Where did the notion of 'cost' come from. Can anyone link to that discussion? —Trappist the monk (talk) 14:48, 29 January 2022 (UTC) Thanks for asking; here is one sample. This is what I understand WAID to be consistently stating about why this parameter needs to be removed. (In the same discussion, she says, “It's because some templates, especially citation templates, are ‘expensive’. They are trying to make the templates a little bit less ‘expensive’ ”.) If I am misunderstanding, perhaps WAID can clarify. Or even better, if it’s not some measure of “cost”, what is the reason for removing it? SandyGeorgia (Talk) 15:06, 29 January 2022 (UTC) If someone can demonstrate to me a high “cost” (particularly relative to other items allowed in the citation templates), I might reconsider the utility of the lay parameters. SandyGeorgia (Talk) 15:18, 29 January 2022 (UTC) I think that Editor WhatamIdoing is mistaken. It is true that every parameter in a cs1|2 template requires time and memory space to process; that's the server cost. That 'cost' is not why I think that the |lay-*= parameters should be deprecated and later withdrawn. My initial reasons for supporting deprecation and withdrawal: Subsequently, because of conversations elsewhere on this page, I have added these to my list: A lot of the rest of the discussion on your talk page appears to be a let's-beat-up-on-trappist-the-monk-fest. I'm not interested discussion with editors who apparently think that that sort of behavior is acceptable. —Trappist the monk (talk) 20:41, 29 January 2022 (UTC) Thank you for the detail and history. As the "cost" issue appears to have been incorrect, please do not expend any more time answering my query then. On the "parameters are claimed to have been created for WP:MED, but I can find no evidence to support that in the histories" part, as I stated several places, I was uncertain of how involved (or not) Eubulides was in that, but knew he had promoted the lay parameters as well as vancouver style formatting, and my real concern is that we not lose vauthor for similar reasoning as we are seeing on the lay parameters-- both advanced by Eubulides at MEDRS and MEDMOS. SandyGeorgia (Talk) 20:53, 29 January 2022 (UTC) You can expect |vauthors= to go nowhere until there is a Module:Citation/Vanc lying around, and even then I'm not sure we'd withdraw support. Izno (talk) 22:05, 29 January 2022 (UTC) I'm happy to hear that support for vauthors is unlikely to be removed, but I have no idea what "until there is a Module:Citation/Vanc lying around" means or how it relates to my question (code speak). SandyGeorgia (Talk) 22:11, 29 January 2022 (UTC) Essentially that I think there would need to be a series of templates powered by such a module replicating the Vancouver style in full before removing that parameter. Izno (talk) 22:15, 29 January 2022 (UTC) Re, the separate issue of "beating up on" anyone, one way to avoid that is to answer queries when they are raised, and recognize that we don't all speak the same (technical) language. (There is some "beating up" on this page which was not only inexcusable, but also sanctionable, but never mind.) As you can see, several of us have been operating on faulty notions of "cost", which to me, seemed extremely ironic considering some other parameters, so I'm glad that mistaken notion is put to rest. Communication is key. SandyGeorgia (Talk) 20:56, 29 January 2022 (UTC) And separately again, I have read both Help:Citation Style 1 and Help:Citation Style 2, and still don't understand the relevance of the shorthand, "cs1|2" often used here. I only "speak" what I use in building content, which is the application of cite journal, cite book, cite web, etc, and don't understand what cs1 or cs2 have to do with a parameter added specifically to cite journal. I now have a better understanding of why the removal of lay parameters is sought, but what you dislike about them to me is not a bug; it's the intent. They are not full citations and should never be confused with those. I suppose for me to understand why that is a problem, I may need a deeper understanding of ths cs1|2 thing. Or something. SandyGeorgia (Talk) 21:11, 29 January 2022 (UTC) I think a key point to understand is the plan to update the link to the lay summary when it goes stale. Should editors seek out a new lay summary that is currently accessible, or is it helpful to access the contents of original lay summary from another source such as a republisher or an archiving service? If finding another available copy of the original lay summary is considered to be a viable option, then it would be helpful to have more complete citation details for it. isaacl (talk) 22:06, 29 January 2022 (UTC) In the example I give above, the lay summary is from archive.org (that's how I solved it). If I understand correctly from my watchlist, there are armies of editors who go around making sure links are archived via some wayback tool. SandyGeorgia (Talk) 22:15, 29 January 2022 (UTC) Well, it works for web-based content (which of course is the starting assumption at present), while making the reference dependent on the existance of one archiving service. As I understand it, User:InternetArchiveBot asks the Internet Archive to archive pages, and fills in the archive URL parameter when URLs become stale, as well as adding links to archived copies of books for book references. I don't know if it checks the lay-url parameter; I don't believe it will replace its contents with a link to an archived version. isaacl (talk) 22:45, 29 January 2022 (UTC) IABot was, for a while, adding |archive-url= and |archive-date= to cs1|2 templates that only had |lay-url=. In cs1|2, |archive-url= requires |url= so the result was |archive-url= requires |url=. I think that that bug has been fixed. —Trappist the monk (talk) 23:17, 29 January 2022 (UTC) OK, so to check my understanding, at present, IABot does not process the lay-url parameter. It did once if there was no url parameter, but that caused an error message to be displayed. isaacl (talk) 23:25, 29 January 2022 (UTC) I cannot confirm that IABot no longer processes |lay-url= – I haven't seen this problem in a while. I do know that it used to: T285191 and T279268 (where it is marked as resolved). The error was caused only when |url= was empty or omitted; sort of suggests that |lay-url= was being treated as a fall-back parameter. —Trappist the monk (talk) 23:52, 29 January 2022 (UTC) My apologies; I misinterpreted your comment. So we know there was an error scenario where IABot would add an archive url parameter to a citation that had a lay-url parameter but no url parameter. Thanks! isaacl (talk) 00:04, 30 January 2022 (UTC) Maybe there is a serious reason I should be worried about this, but I'm not (feature, not a bug). The lay-url is an adjunct, not the source, and wise editors can add the archived version anyway. SandyGeorgia (Talk) 00:13, 30 January 2022 (UTC) Sure, I can appreciate how some editors don't think it's important to track additional citation details for a lay summary. However I can also appreciate how others would like to have this info in order to assist in keeping track of the summary. (Wise editors can add the lay summary information without a parameter, too, so I'm not sure that works as an argument either way.) isaacl (talk) 07:09, 31 January 2022 (UTC) Lack of support for an archive is another good reason to remove it and support this with its own dedicated template like {{lay source}} (the uses of which could be much more easily tracked and/or checked for issues). Izno (talk) 22:18, 29 January 2022 (UTC)

    Editing multiple articles, systematically, against consensus

    Ttm, with a disputed tag on the cite journal page, where did you get consensus to enact this preference across multiple articles (one sample provided) ? In the discussions above, and elsewhere, against this proposal are SG, @Boghog, Buidhe, Hog Farm, Nikkimaria, Ahecht, Peaceray, Femkemilene, Firefangledfeathers, and Johnbod:. For it are two IPs (don't know how to ping them), Guerillero, and I can't determine from the discussion where others stand, as their comments are generalized. (I think Colin agreed with this proposal, but unclear.) And yet you are systematically installing a cited lay source across medical content, in precisely the way most of us have objected to.

    Today, starting with the As, you have made hundreds of these edits, and this leaves the impression you intend to continue. Why and where is the consensus? Please stop. Also, please inform us as to when the unsupported change will be reverted. SandyGeorgia (Talk) 15:35, 12 February 2022 (UTC)

    It looks like those edits are replacing a URL without a title, date, or other information with full information about that URL. A citation template containing a URL without a title has generated an error for many years; how are these bare urls tucked into citations that point to a different source any different? – Jonesey95 (talk) 15:59, 12 February 2022 (UTC) They are specifically activating bundled citations using lay sources to cite medical content, which is explicitly what is disputed in the discussions above. Samples: The slippery slope of citing laysources for medical content has been activated by fait accompli, without consensus, and over explicit opposition. SandyGeorgia (Talk) 17:22, 12 February 2022 (UTC) Yes, please stop - to be fair the last edit was 15:27 today, just before Sandy's post. Johnbod (talk) 17:30, 12 February 2022 (UTC) Ttm, your edits here do not have consensus, despite your "RFC" with multiple procedural issues. I would strongly advise against continuing to make these edits. Hog Farm Talk 18:45, 12 February 2022 (UTC) I do so wish you would not exaggerate. In the discussion at WT:MEDRS, you wrote that this change (deprecation of the |lay-*= parameters) hundreds to thousands of articles, leaving in this case, thousands of error messages in Good and Featured articles. In the OP of this subsection you wrote you have made dozens of these edits but then changed that text to you have made hundreds of these edits. Earlier in this discussion I provided three numbers: I provided a list of WP:MED articles that use |lay-url= at Wikipedia talk:WikiProject Medicine § WP:MED articles using lay-url= (you fixed Leech and Water fluoridation) Clearly, it is not possible to have thousands of error messages in Good and Featured articles. The edits that I have made to fix |lay-url= errors all use {{lay source}}. At this writing, that template is used 73 times in mainspace so 73 is the maximum possible number of |lay-url= fix-edits that I could have made. While I have made most of these edits, there are other editors who have used {{lay source}}. It is, apparently, your contention that lay sources named in the |lay-*= parameters are not WP:MEDRS-citable sources. I do not dispute that. Yet, the very presence of a lay source inside a WP:MEDRS-citable-source citation makes it appear that the lay source has the imprimatur of WP:MEDRS by virtue of that intimate placement. That same intimate placement makes it appear that clicking the link will take the reader to the source named in the WP:MEDRS-citable source portion of the citation when that is (almost) always not true. This violates WP:ASTONISH and, particularly WP:EASTEREGG (yeah, I know, "not policy", but good advice nonetheless). That such links escaped FA scrutiny surprises me. At the time that you fixed them, FA article Leech had 64 WP:MEDRS citations, 1 with lay source and FA article Water fluoridation had 122 WP:MEDRS citations, 2 with lay source. At the time of your reverts, non-FA articles Alzheimer's disease had 312 citations, 1 lay source and Alexithymia had 103 citations, 1 lay source. Such low use ratios (1:64, 1:61, 1:312, 1:103) suggest that simple deletion of the |lay-*= parameters might be the best course. Of the 73-ish articles that I've fixed, the most templates with |lay-*= parameters that I remember fixing has been three in the non-WP:MED article Allison T56. The |lay-*= parameters are a bad design used in a very small fraction of all articles using cs1|2 templates (0.046% = 1,246 ÷ 5,116,342 × 100 – these numbers obtained 27 January 2022; see above). There is no need to perpetuate bad design so no need to un-deprecate these parameters. —Trappist the monk (talk) 18:51, 12 February 2022 (UTC) Those are your opinions (not shared by others, as very clearly expressed before you started making these edits); please cease making these mass edits until you have consensus for them. Are you making these edits manually or with a script? And why are you marking them minor ? SandyGeorgia (Talk) 19:17, 12 February 2022 (UTC) SandyGeorgia, aren't these edits essentially what you proposed in #Sample for discussion above? A bare URL with no information is being replaced by a link with a title and a date, almost exactly like the example you provided from an FA. What am I missing? If {{Lay source}} needs to be tweaked to provide a format that is more in line with wording about reliable sources, modifying that template's code seems like a good place to do it. Perhaps it could link to WP:RS or similar, where an explanation about lay sources could be provided. – Jonesey95 (talk) 20:05, 12 February 2022 (UTC) No, it's not; I'm not sure where we are misunderstanding each other, but thanks for asking (and please keep trying if I am not clear). In the first and second samples in this section, the lay summary is only an adjunct to the actual citation. It's intentionally partial. In the third example, using a new template, the lay source is creating what is essentially a stand-alone citation (easily unbundled to look like a "real" citation). Lay source doesn't need to be tweaked; it needs to be eliminated so this possibility doesn't exist, and a laysource is only used as a partial adjunct to a MEDRS-compliant source. By providing a means to make a lay source into a complete citation, we are opening a back door that can lead to weakening MEDRS. But the main concern here is, why is this happening at all when consensus is so clearly against this? These edits are being marked as "minor", and appear to be happening by script, and it appears that the intent is to continue (since they started with "A"). It is this kind of behavior that leads to the earlier lamentations relating to "pitchforks", and is so frustrating to others. SandyGeorgia (Talk) 20:20, 12 February 2022 (UTC) I think the above discussion is finally bringing out the tacit semantic assumptions that people are carrying in, which I hope will make this discussion more productive. The impression I get is that the intended meaning of one of these "lay sources" is something close to a link in a "See also" section, only to an external resource. It's an ancillary link which the author of the article thought would benefit the reader, but it doesn't, by itself, support the article. Furthermore (if I understand correctly) different authors looking at the original (non-lay) source being cited might choose different lay sources or none, so there's not an obligate 1:1 relationship between the "lay source" and the non-lay source (as there would be between, say, the full text of an article and an abstract). If we take the "lay source" to be a full-blown source, then "lay-url" would indeed be a "bad design"; trying to fit two sources into one citation is an obvious problem. However, I'm not convinced that is the case; if the "lay source" is more of a convenience than a "real citation", capturing its full bibliographic details isn't critical to the overall integrity of the article. The "lay source" template-bundling approach isn't necessarily bad, as a way of getting access to the full machinery of citation templates to format and detail the lay source. On the other hand, Sandy's point is that, basically, a citation is a citation; wrapping it in a lay source template may make it clear to the reader that this is ancillary, but is that true of automated bibliographic tools? Won't they scrape the lay source and treat it as a full citation? The bundling mechanism also looks fairly fragile in that there doesn't seem to be any mechanism to enforce the presence of a "real" source associated with the lay source. (I admit I've never used citation bundling personally so I may be missing something.) Overall, I think reverting to the "lay-url" mechanism might be healthier, because it seems like throwing away data about the lay source when an article is scraped will do less damage (since the secondary source is still there) than incorporating the lay source as a full-blown citation. But I'm not sure I understand the original claim of deficiencies in formatting that led to lay-url's deprecation, so there may be more there to unpack. The other thing that's conspicuously missing from this discussion is reference to external bibliographic practice. The closest thing I can think of in external practice is the need to cite references that are part of a larger work or series, which is rather different. But people have been working on the problem of encoding bibliographic semantics since before the PDP-11 was a thing; surely there are precedents we can look to? Choess (talk) 16:27, 13 February 2022 (UTC) No, I'm afraid there are no precedents that can inform this issue. Because a fact-checking system to be used by lay readers has never been attempted before. All citations in Wikipedia are to be utilized by such readers, and should be formatted and presented with such verifying audience in mind. The real problem has nothing to do with citations. It has to do with hobbyists or experts in some narrow or wide areas of knowledge who look at this through the prism of their hobby or expertise. For people with such narrow viewpoints, simplicity is a complicated matter. 68.173.76.118 (talk) 16:58, 13 February 2022 (UTC) Add: interesting you brought the PDP-11 up. One of the first apps ported from the 360 was IBM's text processing, which was geared almost exclusively to experts. Referencing systems still follow basically the same principle today. 68.173.76.118 (talk) 17:16, 13 February 2022 (UTC) The back door is already open. Inclusion of a lay source in or directly adjacent to a WP:MEDRS-citable scholarly or academic source, whether by |lay-*= or by external link or by some sort of template, opened that door because the pairing of the lay source with an academic or scholarly source will be interpreted by readers as a WP:MED endorsement of the lay source. If WP:MED are going to include, and by default, endorse a lay source, especially when so closely coupled to an academic or scholarly source, then the lay source should not be presented as a partial but as a whole that includes all of the appropriate bibliographic detail – just as is done for the paired scholarly or academic source. If WP:MED do not want to endorse lay sources, then none should appear in any WP:MED article where readers may assume a WP:MED endorsement. The duty and obligation to clearly and concisely summarize the scholarly and academic sources falls to WP:MED editors. Because of that duty and obligation, there is no need for WP:MED editors to rely on 'unendorsed' lay sources. If WP:MED want to close the back door, they should close the back door and disallow use of lay sources anywhere in a WP:MED article that lay readers might presume a WP:MED endorsement. Editor Choess' comment: something close to a link in a "See also" section, only to an external resource makes me wonder if a §§Lay sources subsection of a §Further reading section (perhaps with some sort of appropriate disclaimer), might be an appropriate place to list 'WP:MED-approved' lay sources with all of their proper bibliographic detail. —Trappist the monk (talk) 20:51, 13 February 2022 (UTC) Trappist: If you want to change MEDRS, changing the citation style behind the backs of the medical editors who use MEDRS, and then arguing about it on a page about that citation style, is a pigheaded and wrong way to do it. Go to the proper page for that sort of discussion, Wikipedia talk:Identifying reliable sources (medicine), and get consensus there. Until you do so, these changes should be reverted. —David Eppstein (talk) 21:43, 13 February 2022 (UTC) MEDRS does not control this citation style. Period and end of story. Izno (talk) 23:39, 13 February 2022 (UTC) When people make edits to medical articles, where there is a conflict between MEDRS and this citation style, MEDRS wins out. And agree with David: if you disagree the principles underlying any portion of MEDRS, the proper way to address that is via the guideline's talk page, not via citation style. Nikkimaria (talk) 00:28, 14 February 2022 (UTC) MEDRS does not control citation style. WP:CITESTYLE does. Izno (talk) 00:31, 14 February 2022 (UTC) And even if we were to take MEDRS as relevant (particularly WP:MEDPOP, which is the only place that mentions the |lay-*= parameters), for sake of argument, One possibility is to cite a higher-quality source along with a more-accessible popular source, for example, with the |lay-url= parameter of {{cite journal}}. does not say that you must use this parameter in these templates to provide the information of interest. So out goes the "MEDRS controls this specific parameter". Nor in fact does MEDRS even support any of the argumentation made here in regard to why it should get to control the exact presentation of the citation. Izno (talk) 00:36, 14 February 2022 (UTC) If we take CITESTYLE as the governing guideline, then this change still fails - it takes an established means of presenting lay sources and changes it. MEDPOP allows the use of lay- parameters to present lay summaries alongside the underlying scholarly research, not as standalone citations - so while it does not require the use of these parameters, it does not support the proposed replacement. Nikkimaria (talk) 02:20, 14 February 2022 (UTC) Which is a ludicrous position on CITESTYLE that you have broadly suggested exists as the correct interpretation. CITESTYLE means to protect a change from style X to Y at a level broader than a specific parameter of a specific series of templates. The other reason it's ludicrous is that it would imply these modules can never change. Ever. Even if they have, several times over, and sometimes in quite significant ways. That's even if there did not exist an RFC on the books that said "yes, we will take these changes in this module on this date". You don't get to invalidate the results of that RFC just because you weren't there for the RFC in question. (General you.) it does not support the proposed replacement It does not need to. If a guideline is silent on a topic, it's silent on a topic. There isn't magical text that exists in the guideline but doesn't actually exist in the guideline. Izno (talk) 03:17, 14 February 2022 (UTC) CITESTYLE means to protect a change from style X to Y at a level broader than a specific parameter of a specific series of templates. There is an obvious stylistic difference resulting from the use of |lay-url= etc versus {{lay source}} - it's ludicrous to suggest there isn't, even if you think the latter is better. The other reason it's ludicrous is that it would imply these modules can never change. Ever. Even if they have, several times over, and sometimes in quite significant ways. There have indeed been quite significant changes made. And then we get discussions like this, where people who use these templates in practice are surprised - for example, that what the guidelines suggest suddenly results in error messages. If a guideline is silent on a topic, it's silent on a topic. The guideline is not silent on the issue of lay sources - it makes clear they shouldn't be used as sole citations but only as adjuncts. Sandy and Choess point out that the switch from a parameter to a separate template results in that distinction being lost. Some argue that it should be - but that's not a discussion that belongs here, it's one they should take to the guideline talk page. Nikkimaria (talk) 03:50, 14 February 2022 (UTC) They point out: No, they have the opinion that the distinction is lost. Neither in the displayed text, nor in the wikitext, does {{lay source}} make it unclear it is a lay source. And I would suggest that if {{lay source}} appeared in its own distinct <ref></ref> that alarm bells would sound regardless. Anyway, I will attempt to post a summary of the discussion here later today or sometime this week that maybe can be used as a foundation for moving on. (Or someone else can I suppose.) Izno (talk) 04:53, 14 February 2022 (UTC) May I help with your summary? You may use all of the following without attribution. That's it for now, let me know if clarification is needed. 71.247.146.98 (talk) 14:12, 14 February 2022 (UTC) I started the discussion over there. The editors over there brought the discussion here. I don't care a whit about WP:MEDRS except that it should stop recommending the use of the deprecated |lay-*= parameters. How that is accomplished is up to the editors over there. —Trappist the monk (talk) 14:38, 14 February 2022 (UTC) And they don't care a whit about this page except that it makes their recommendations result in error messages. What leads you to believe that the wishes of editors here outweigh the wishes of editors there? Nikkimaria (talk) 01:42, 15 February 2022 (UTC) Ttm, lay-source is not deprecated, in the sense that there is no consensus for the change you implemented, regardless of where the discussion is held. Could someone please revert the non-consensual elimination of the lay source? Thanks, SandyGeorgia (Talk) 01:52, 15 February 2022 (UTC) Do you not have other options? CS1 is not compulsory... Use another system or devise your own, tailored to your corner. This will provide the added bonus of better isolating your project from the larger encyclopedia. Or, commit to CS1 by getting involved in its entire development, not just the minor aspects that may have bearing on your area. That may give you an idea of trying to apply a general-purpose citation system when editors are convinced that it is there to serve them and their hobbies instead of serving the readers. Can we get the readers' consensus, and find out what they think of this argument about lay sources? 71.245.250.98 (talk) 13:58, 15 February 2022 (UTC)

    url-access when original is paywalled, but archived is free

    About to update a reference by adding the archive.org version of the ref URL, but not sure what do put in url-access field. The archive.org version is free, but the article at original URL now available after paying $3.95 per article (which i assume is registration, rather than limited). Should the url-access be set to the archive.org access-status of nothing (ie. free without putting "free" in field), OR set to access-status of original URL? (i looked through archived Talk threads and didn't see a post about this issue.) --EarthFurst (talk) 23:49, 7 February 2022 (UTC)

    I wonder about the ethics of linking to a copyrighted source at archive.org when clearly, as in this case, the source is available from the publisher via their online presence and the copyright owner wants to, and is entitled to, control distribution of its intellectual property. When I stumble upon such things, in a surfeit of caution suggested by WP:ELNEVER, I delete |archive-url=, |archive-date=, |url-status=, and set |url-access=subscription because that is the closest thing that we have to a paywall access indicator. We might want to consider creating a paywall keyword for |url-access= – it would display the red-lock access indicator. —Trappist the monk (talk) 00:15, 8 February 2022 (UTC) If it was once offered freely by the publisher, and the publisher url is the one that was archived, I have no qualms about continuing to use a free archive link. ELNEVER should be applied when a link does not have proper provenance from the publisher or author, but that is not an issue for archived publisher links. —David Eppstein (talk) 00:50, 8 February 2022 (UTC) |url-access= is for whatever is in |url=. Izno (talk) 00:31, 8 February 2022 (UTC) As Izno an David Eppstein say. Open access articles vanish all the time from publishers' websites, even those with a free license, so it's generally good to add a link to a copy on an open archive to avoid link rot; if the "url" parameter is used, then url-access needs to reflect the archive's access status. I'll note that web.archive.org links are ok but might be superseded by a better archive.org copy in the future, so it might be better to use an identifier-powered link like https://fatcat.wiki/release/lookup?doi=10.3389/fnhum.2018.00037 , or its target URLs https://fatcat.wiki/release/kbfwh7ah2vcpfn2gf4uk6vuwoi / https://scholar.archive.org/work/4atoqn4rtbhfhebc2qckkmldbq , rather than their web.archive.org PDF link. (Though in this specific case I wouldn't add anything in the url parameter: the PMC ID already offers the best access venue possible.) Nemo 16:58, 16 February 2022 (UTC)

    Linking a journal article title behind a paywall

    Should a "cite journal" template include a "url=" link to the journal title when the article is behind a paywall? I've always assumed that the doi is sufficient - but I'm about to review a FA candidate and I cannot find any documentation on this. Once a link is included it gets archived and an access-date is needed. It all gets very cluttered. Where has this been discussed? Thanks - Aa77zz (talk) 12:28, 13 February 2022 (UTC)

    Best practice is to keep |url= for free resources. Headbomb {t · c · p · b} 13:43, 13 February 2022 (UTC) This is what |url-access= is for. See the Cite journal documentation for details. – Jonesey95 (talk) 15:45, 13 February 2022 (UTC) Yes, but if you have DOIs and other identifiers, don't clutter |url= with paywalled links. Headbomb {t · c · p · b} 15:50, 13 February 2022 (UTC) Yes, I agree - but is this written anywhere? I would like to be able to justify my opinion by pointing to some documentation. How about changing the documention for cite journal to include a recommendation not to (in general) provide url= to paywalled journal sites when the doi serves the same purpose? ("in general" because there may be special cases that I haven't thought of) (For open access articles the doi-acccess=free cleverly adds a link from the title.) - Aa77zz (talk) 17:21, 13 February 2022 (UTC) It's written in Wikipedia:Citing_sources#Convenience_links. Nemo 16:47, 16 February 2022 (UTC)

    How should a book series number be cited?

    There does not appear to be any parameter in CS1 for it. As has been pointed out in previous discussions (1, 2), there is a difference between a volume, which refers to a single work broken up into multiple bindings, and a series, which are multiple books on different subjects, but tied together by a common theme and published as an ongoing effort. For this reason, neither "volume", nor "issue" applies. There are a "number" and "series-number" parameter, but neither of them are used in {{cite book}}. (It is important to note that, despite being listed as being deprecated in April 2021 on {{cite book}}, "series-number" was technically not deprecated. Deprecated implies that it was once in use. However, "series-number" was actually only used by the {{cite episode}}. It seems to have simply been mistakenly listed on {{cite book}}.) I saw a suggestion to place the number at the end of the "series" parameter, but that appears to be incorrect, as it should be used to name only the title of the series, not the number. Therefore, it seems that a separate parameter is necessary. Note that widely used citation management software like Zotero have implemented such a field. However, if another parameter is not possible, a suggestion of where the series number should be entered would be

    For an example, consider US Air Force Historical Study No. 6. (While this might not be considered more of a {{cite report}} than a book, the point remains as no appropriate parameter is available in it either.) –Noha307 (talk) 02:19, 15 February 2022 (UTC)

    For our citation templates, the usual convention is to put this number in the |volume= parameter. Yes, it means two different things (a volume in a series is not the same as a volume in a multi-volume book) but that's what we use anyway. If you have a multi-volume book that is also part of a book series, I think it would be best to put the volume within the multi-volume book as text in the |title= parameter, leaving the series number in the |volume= parameter. —David Eppstein (talk) 02:31, 15 February 2022 (UTC) I am not sure I understand what you need to do, but something like |series=Series 4 |volume=# or/and title is perfectly acceptable, and used in the real world. The main thing is that the parameter should only be used when the publisher officially designates a series and publishes titles that again officially are designated as parts of it. We cannot make up our own series name/numbers. As you noted, your example doesn't seem to fit, unless again I am misreading it. 71.245.250.98 (talk) 14:23, 15 February 2022 (UTC) @Noha307: |series=USAF Historical Studies seems like a reasonable series identifier to me (referring to the list at https://www.afhra.af.mil/Information/Studies/Numbered-USAF-Historical-Studies/) (or perhaps just |series=Air Historical Studies, as stated in the paper). Even though it's not identified as volume, I'd probably mark it up as: {{cite report |last1= Dubuque |first1= Jean H. |last2= Gleckner |first2= Robert F. |date= 1951 |title= The Development of the Heavy Bomber, 1918–1994 |series= USAF Historical Studies |volume= 6 |publisher= USAF Historical Division, ] |type= Monograph |url= https://www.afhra.af.mil/Portals/16/documents/Studies/1-50/AFD-090602-028.pdf |via= ]}} Resulting in:

    Encyclopaedias with editors and contributors but no authors

    How do I correctly cite an article in a physical book, an encyclopaedia, which (like many other books of this nature) has editors and contributors but no authors? See International_Christian_College#External_links --PeterR2 (talk) 09:56, 15 February 2022 (UTC)

    Treat the encyclopaedia article as a chapter, named with |chapter= and using |author= (or |first= and |last=) for its author. Kanguole 10:40, 15 February 2022 (UTC) For this? {{cite book | editor=Cameron, Nigel M de S | contribution=Bible Training Institute, Glasgow | contributor=Grogan, Geoffrey W | title=Dictionary of Scottish Church History & Theology | location=Edinburgh | publisher=T & T Clark | year=1993 | isbn=0-567-09650-5}} write this instead: {{cite dictionary |editor-last=Cameron |editor-first=Nigel M de S |entry=Bible Training Institute, Glasgow |last=Grogan |first=Geoffrey W |dictionary=Dictionary of Scottish Church History & Theology |location=Edinburgh |publisher=T & T Clark |year=1993 |isbn=0-567-09650-5}} Grogan, Geoffrey W (1993). "Bible Training Institute, Glasgow". In Cameron, Nigel M de S (ed.). Dictionary of Scottish Church History & Theology. Edinburgh: T & T Clark. ISBN 0-567-09650-5. An alternate to |entry= is |article= though for dictionaries and encyclopedia I prefer |entry=. You should also replace the four &nbsp; with proper list markup either ** or *:. —Trappist the monk (talk) 12:22, 15 February 2022 (UTC)

    i18n: automatic date-names translation

    Other wikis can set date_name_auto_xlate_enable = true in their ~/Configuration to have the module automatically translate English month-names to local month-names. In recent discussion about another wiki's cs1|2 installation I noted that named dates (Christmas, Easter), season dates, and quarterly dates are not automatically translated. I have remedied that with tweaks to Module:Citation/CS1/Configuration/sandbox and Module:Citation/CS1/Date validation/sandbox.

    This new functionality is not supported at en.wiki so was tested at the other wiki.

    —Trappist the monk (talk) 15:18, 15 February 2022 (UTC)

    Adding spaces between parameters

    Right now, the citation filler in the 2010 wikitext editor adds spaces between parameters. The TemplateData for Template:Cite journal tells the visual editor to use editor-hostile wikitext instead. Would anyone mind if we changed the TemplateData so that the visual editor will use the same style that the 2010 wikitext editor is already using?

    (See Wikipedia talk:WikiProject Medicine#Suggestion for more background. No, I don't mind if we make this change for all CS1 templates; I'm only asking about {{cite journal}} because it's the one that causes the most problems for WPMED folks.) WhatamIdoing (talk) 03:13, 10 February 2022 (UTC)

    I think no one would object for any of the citation templates (change all of them!), but I am not sure anyone knows how off hand, else it would have been done. :) Izno (talk) 06:27, 10 February 2022 (UTC) See mw:Help:TemplateData#Custom formats. The next to last, minus the initial \n bit, should do it. (That \n style should probably be considered for infoboxes, the templates that create tables, and any other templates that we normally want to begin on a separate line.) WhatamIdoing (talk) 06:35, 10 February 2022 (UTC) To match the style suggested at Wikipedia:Bots/Dictionary § editor-hostile wikitext, wouldn't the format string be: {{_ |_=_}}? I don't (won't) use ve and am loath to play-around in TemplateData so I'll leave this to others to fix as they see fit. —Trappist the monk (talk) 13:04, 10 February 2022 (UTC) Yes, I think that would do it. (I very strongly recommend the visual editor if you ever find that you need to insert or delete a column from a wikitext table, or if you need to swap the order of columns in a table.) WhatamIdoing (talk) 16:56, 10 February 2022 (UTC) It's been a week. Any objections? If not, then I'm going to make this change. WhatamIdoing (talk) 16:45, 17 February 2022 (UTC)

    How to I use cite web to create inline citations?

    Like how it looks like in the examples. One of them is a news article, but I don't want the box, I want something like, "Jake, Paul (Jan 1 2022). 'Lorem Ipsum'. Is that possible? Tet (talk to me) 07:02, 17 February 2022 (UTC)

    @Tet: Hi there! You could use {{cite web}} without using the <ref>...</ref> tags, like this. Jake, Paul (Jan 1, 2022). "Lorem Ipsum". Is that what you're looking for? In what Wikipedia article would you want to use {{cite web}} without the box? GoingBatty (talk) 13:53, 17 February 2022 (UTC) @Tet If you're considering Parenthetical referencing (Harvard referencing) then please be aware this format is now deprecated on Wikipedia. So while it's ok to use it on articles that used this referencing style before 2020, it shouldn't be used on new articles. Nthep (talk) 15:22, 17 February 2022 (UTC)

    Deprecation questioned

    Why were the transcript= and transcript-URL= fields deprecated in this and the {{cite AV... templates? These are useful fields, and their recent removal from use forces editors to use other fields contrary to their designs in order to place transcript information. RSVP here, thanks. 2601:246:C700:558:E8D7:8CA7:35D3:40B6 (talk) 23:35, 17 February 2022 (UTC)

    You are mistaken. |transcript= and |transcript-url= are not deprecated. |transcripturl= (not hyphenated) is deprecated. —Trappist the monk (talk) 00:02, 18 February 2022 (UTC)

    "In"

    The template puts the word "In" before the name of the editors, which seems illogical. Instead, it seems like it should be the name of the encyclopedia. Is this correct?--Esprit15d • talk • contribs 16:09, 20 February 2022 (UTC)

    If it is illogical then it has been so since this 27 June 2007 edit at {{Citation/core}} (which has long-since been superseded by Module:Citation/CS1). I don't think that it is illogical. Encyclopedia are not cataloged by article-author name but by editor name so an author's article is in the editor's work. —Trappist the monk (talk) 16:34, 20 February 2022 (UTC)

    ERIC ID

    Good day. I ran across a reference using the cite report template that contained only a title plus some parameter errors. While fixing the parameters I looked up the title in Google Scholar and found it was in a US educational system called ERIC. ERIC has IDs that correspond directly to URLs. Example: ERIC ID ED148298 maps to https://eric.ed.gov/?id=ED148298 so I'm wondering if there should be a CS1 parameter for ERIC ID? I know id= exists. Thanks Jamplevia (talk) 16:42, 21 February 2022 (UTC)

    There is {{ERIC}}. If one believes this search, that template isn't used much in cs1|2 templates. Creating, maintaining, documenting an |eric= identifier for such a small number of uses doesn't seem worth the effort when |id={{ERIC|ED148298}} works. —Trappist the monk (talk) 17:04, 21 February 2022 (UTC) Thank you. Jamplevia (talk) 18:22, 21 February 2022 (UTC)