Wikipedia talk:Citing sources


Should list-defined references be discouraged?

[edit]

List-defined references are a pain for VisualEditor users. It displays "This reference is defined in a template or other generated block, and for now can only be previewed in source mode." instead of the actual content of the reference when using the VisualEditor. Modifying the references requires switching to the source code editor, but not everyone is familiar with its syntax. I don't know why the VisualEditor doesn't handle them better, it doesn't seem unsolvable from a programming perspective and I would be fine with list-defined references if it did, but unless there are plans to fix this, perhaps we should discourage it? I'm curious to know what more experienced contributors think. Alenoach (talk) 20:44, 1 March 2025 (UTC)[reply]

VisualEditor is crap. It's VisualEditor that should be discouraged. Jc3s5h (talk) 21:10, 1 March 2025 (UTC)[reply]
Two notes on this:
  1. The VisualEditor (VE) can preview a list-defined reference. Check out police jury in the VE. When I rewrote that, I used list-defined references, but no templates. In the VE, you can preview, modify, and reuse the list-defined references. You cannot add new list-defined references, delete existing ones, comment out existing ones, or replace existing ones. The VE will treat any template used within another template as just text. I don't think there is anything in the pipeline to fix that.
  2. Sub-referencing is meant to be the official solution to citing different pages and it is meant to be built on list-defined references, although it looks like that is causing problems for the team.
Rjjiii (talk) 21:24, 1 March 2025 (UTC)[reply]
Ah indeed, your way of doing it outside the "reflist" template works better with the VisualEditor. I still believe that inline references are more beginner-friendly, but your approach is a clear improvement compared to putting it in the reflist, thanks. Alenoach (talk) 21:42, 1 March 2025 (UTC)[reply]
Entirely agree with Jc3s5h. If the problem is that VisualEditor can't hack it, then the problem is VisualEditor. We should not warp our usage of helpful article-source organizational tactics because of bad tooling foisted on us by Wikimedia. —David Eppstein (talk) 21:37, 1 March 2025 (UTC)[reply]
I'm disappointed that m:WMDE Technical Wishes/Sub-referencing is going off in a weird direction because VE doesn't do LDR well and they don't want to work on fixing that. Anomie⚔ 11:43, 17 March 2025 (UTC)[reply]
It is so disappointing. I raised the issues that VE would cause for their plans over a year ago and they were dismissive about it then, seeming to frame it as beyond the scope of their project. But then like, who is it in scope for? Is there a team or even a person working for the WMF that has a long-term vision for how to improve referencing, or is the long-term plan to just hope we figure it out? There are limitations to what can be done with the current system; that's why using {{sfn}} feels like putting a puzzle together and {{rp}} is so basic. Rjjiii (talk) 00:40, 18 March 2025 (UTC)[reply]
I've tried WP:LDR on a couple of articles, and I find it to be inconvenient, especially if you're using section editing. I think we should discourage it. WhatamIdoing (talk) 06:30, 16 March 2025 (UTC)[reply]
LDR is the preferred method for many editors. It has pros and cons, but it should not be discouraged. -- Michael Bednarek (talk) 06:36, 16 March 2025 (UTC)[reply]
I wonder whether we could find out what percentage of articles actually uses it. There is a cost (in editor's time to learn about yet another different system) to maintaining unpopular arrangements. WhatamIdoing (talk) 02:34, 17 March 2025 (UTC)[reply]
Template {{Use list-defined references}} has >5300 transclusions. Nobody has to learn about it; as with other citations, other helpful editors will convert citations non-conforming to an article's established style. -- Michael Bednarek (talk) 03:08, 17 March 2025 (UTC)[reply]
So it's used in less than one in a thousand articles. That's barely any use at all.
Yes, people do have to learn about it – if they want to be able to fix the citation formatting problem that brought them to the page; if they want to be able to remove a citation without getting an ugly red error message on the page; if they want to understand what's going on with the page so they don't have to rely on "other helpful editors", especially the ones whose "helpfulness" manifests in the form of yelling at them for not doing everything perfectly the first time. WhatamIdoing (talk) 03:16, 17 March 2025 (UTC)[reply]
@Michael Bednarek, that seems too low? At least one list-defined reference is used in at least 179,000 articles, based on the "ref" parameter in {{reflist}} transclusions. Rjjiii (talk) 04:26, 17 March 2025 (UTC)[reply]
I suspect that many of those uses occur in articles with mixed citation styles. But that number further clarifies that discouraging LFDs is impractical. -- Michael Bednarek (talk) 04:43, 17 March 2025 (UTC)[reply]
Well... "discouraging" is usually a long-term and largely inactive/passive process. You just write something in some documentation and leave it for five or ten years, and let community members make individual choices. You could write something as strong as "being discouraged but not banned", but you could also write something like "relatively unpopular" or "less popular than shortened footnotes". WhatamIdoing (talk) 05:11, 17 March 2025 (UTC)[reply]
That suggests that about 1 in 40 articles is using that, at least partially. That feels like a more plausible estimate to me. WhatamIdoing (talk) 05:08, 17 March 2025 (UTC)[reply]
Just cruising thru, not reading the arguments: I use {reflist|refs= cos you can better read the text in source mode. Putting the refs in the body text looks like spaghetti code and can make a passage almost unreadable. And a key point: it's rare for someone editing to want to change the ref. Editors usually want to do things to the text. If you need to read the ref that's better done in reader mode. You might want to delete the ref; that is different. Wanting to make changes to ref itself are rare and are are usually like to add the date or something -- important but not usually key; you're not going to change the title or the author etc. Sometimes I have to find the ref tags in all that text, do linefeeds to get the refs out of the way to even read the text, then put them back -- not a huge deal but not excellent. Sometimes I'm like "Jeez this's a dog's breakfast, I'll just not do the edit I was intending to do." Herostratus (talk) 02:24, 24 March 2025 (UTC)[reply]
I suggest using "<references>" rather than "{{reflist|refs=", as shown here. The difference is not significant for source editor users, but "<references>" will not make references hidden for the VisualEditor users. Alenoach (talk) 02:37, 24 March 2025 (UTC)[reply]
Huh, it's odd that you describe straight-through wikitext as spaghetti code, because I think that the jumping-back-and-forth style of LDR is much more spaghetti-like. WhatamIdoing (talk) 04:43, 24 March 2025 (UTC)[reply]
@Herostratus, Are you confident about "And a key point: it's rare for someone editing to want to change the ref. Editors usually want to do things to the text"?
A while ago, an article appeared on my watchlist. I hadn't looked at it in years. There were something like 50 edits over five years. Not a single word of text was changed. WhatamIdoing (talk) 01:04, 21 April 2025 (UTC)[reply]
Well what were all those editors doing, not seeing the connection.
Well I would be pretty confident EXCEPT I now realize that adding the archive url etc, is probably pretty common. So I have to back off from that. Herostratus (talk) 02:59, 21 April 2025 (UTC)[reply]
All of those editors were fiddling with non-content stuff, including but not limited to ref formatting.
I increasingly wonder whether we could do a decent study about who writes Wikipedia's contents. High-volume editors do a lot of reverting/blanking, and we do a lot of fiddling with wikitext (some of which is actually useful to the occasional person, e.g., adding archive URLs), but I wonder whether newbies add more content. If a new paragraph is added (and sticks), who added that? WhatamIdoing (talk) 17:50, 21 April 2025 (UTC)[reply]
Almost 20 years ago, Aaron Swartz made a study in which he found that Wikipedia's actual content is indeed largely written by the newbies and non-regulars. Whether that's still the case is an open question, but it sounds plausible to me. Gawaon (talk) 07:52, 22 April 2025 (UTC)[reply]
That would be interesting and might even be useful. I know that my own editing patterns tend to shift around a lot, with bursts of content creation interspersed with assorted gnomery of many types. A lot depends on chance. I see something that needs to be fixed, and if I am in the right mood I fix it if I can, and it often leads to something else related or of a similar type. Other times I fixate on cleaning up or improving something on a larger scale, and then there are policy discussion.... Cheers, · · · Peter Southwood (talk): 12:26, 22 April 2025 (UTC)[reply]
No, list-defined references are cleaner and more elegant than the mess you get when the reference details are embedded in the article's prose. The Visual Editor issue is best addressed by enhancing the Visual Editor and/or avoiding the {{reflist}} template as suggested below. Andrew🐉(talk) 20:31, 8 May 2025 (UTC)[reply]

New proposal: deprecate {{reflist|refs= in favor of <references>?

[edit]

Per Alenoach above, <references> handles list-defined references in exactly the same manner as {{reflist|refs=, but with the benefit of VisualEditor support. Should we discourage or deprecate {{reflist|refs= in situations where there are no other parameters passed to {{reflist}} and use a bot to replace all such occurrences with <references>? Dan Leonard (talk • contribs) 12:49, 29 April 2025 (UTC)[reply]

Isn't there, at the very least, a difference in font size? Gawaon (talk) 13:05, 29 April 2025 (UTC)[reply]
Originally that was true, but since 2010 the font sizes have been the same. Compare angle, which uses {{reflist|refs=, versus Sheetz–Wawa rivalry, which directly uses <references>. Both their reference lists have font-size: 90%;, albeit the former is styled by the CSS class .reflist in addition to .references. Dan Leonard (talk • contribs) 13:13, 29 April 2025 (UTC)[reply]
It would be good to have the software engineering perspective, so I opened a discussion here. I hope we will get an answer about whether the VisualEditor can be improved, or otherwise the design rationale. Alenoach (talk) 13:37, 29 April 2025 (UTC)[reply]
Oppose breaking our markup because of limitations in VE. If VE is broken the solution is to stop using VE, not to break more things. —David Eppstein (talk) 17:02, 29 April 2025 (UTC)[reply]
Might be good to wait for a deeper understanding of the problem before taking a decision. Alenoach (talk) 17:10, 29 April 2025 (UTC)[reply]
Ok, apparently this is the main page where the software developers handle it: T52896. It's a major issue that has been there for more than 10 years, and the inability to parse references inside templates also seriously impacts translation tools and infoboxes. One software engineer said in 2014 that fixing it would be too hacky and that there is no good and generic solution, and complained about the templates. No one is working on it, so I guess they don't plan to address the issue. Alenoach (talk) 19:57, 29 April 2025 (UTC)[reply]
This is essentially just substing a somewhat-redundant template. When called in LDR contexts without other parameters, {{reflist}} appears to just call <references /> and are already listed in the documentation as equivalent, so I don't see what you think would break. Dan Leonard (talk • contribs) 18:16, 29 April 2025 (UTC)[reply]
Oppose I love love love using the LDR, if it were a kitten I would carry it in my pocket with me everywhere. If visual editor is the problem, then fix visual editor. Sgerbic (talk) 17:21, 29 April 2025 (UTC)[reply]
@Sgerbic: Note the proposal in this subsection is to require doing LDR using <references>...</references> rather than {{reflist|refs=...}}, not to deprecate LDR. Anomie⚔ 18:09, 29 April 2025 (UTC)[reply]
Sorry, all this coding language is confusing to me as I am only a general editor. I love using reflist|refs, all the articles I write use this style and would hate to see something so tidy and easy to use to be replaced with something so messy and awkward. Sgerbic (talk) 18:41, 29 April 2025 (UTC)[reply]
@Sgerbic It shouldn't be any more complicated. You can write your LDRs as you would, but instead of wrapping them in the reflist template, add <references> tags on either end. Cremastra talk 01:34, 1 May 2025 (UTC)[reply]
That is very old school, I want to continue using reflist|refs it is so much neater. I'm not understanding why continuing as I have for the last few years is a problem. If there is a problem with visual editor then that should be fixed. Possibly I am not explaining myself well, this is an article I just rewrote a couple days ago Jotham Johnson. Sgerbic (talk) 03:15, 1 May 2025 (UTC)[reply]
The only difference is that where you currently type:
{{Reflist|refs=
<ref name="NYT Obit">{{cite web |title=Prof. Jotham Johnson, 61, Dies; Chairman of Classics at N.Y.U. |url=https://
(etc., all the way down, and then ending with a closing }}), you would instead type:
<references>
<ref name="NYT Obit">{{cite web |title=Prof. Jotham Johnson, 61, Dies; Chairman of Classics at N.Y.U. |url=https://
(etc., all the way down, and then ending with a closing </references>). Or, more realistically, you would do the same thing that you're doing now, and every now and again, a bot would replace the unnecessary template with the original wikitext code.
Do you understand how small the recommended change is? It's literally just a few characters difference in the whole page. WhatamIdoing (talk) 03:37, 1 May 2025 (UTC)[reply]
The problem with every script in recognizing reflist template LDRs has existed and been investigated for over a decade. If you could fix it without hacky tape, that would be nice. Aaron Liu (talk) 10:57, 1 May 2025 (UTC)[reply]
I opened a bug report here. Alenoach (talk) 18:01, 29 April 2025 (UTC)[reply]
Strong support In addition to better visualeditor support, using <references>...</references> means that most of the citations will still display even if the WP:PEIS limit is exceeded. All the old reasons to use {{reflist}}, such as font sizes or responsive columns, have long since been overcome by the software. Nothing about using <references>{{cite foo|...}}</references> for list-defined references is harder or less "tidy" than using the template, and in fact I'd argue that bracketing a long list with tags is more "tidy" than encapsulating it into a template parameter. The only thing holding us back is inertia from the days before the raw tag had feature parity with the template. --Ahecht (TALK
PAGE) 18:50, 29 April 2025 (UTC)[reply]
Oppose: visualeditor is broken, not |refs=. Boghog (talk) 19:37, 29 April 2025 (UTC)[reply]
I worry that deprecating the reflist template, but only for LDR is going to cause confusion. Good faith editors are likely to use reflist, as it's what they will see commonly elsewhere and only after being told of the situation understanding that the common method shouldn't be used in this specific case. LDRs are not common, so many editors could go a long time before coming across this situation. It would seem the better solution would be either to move away from using the reflist template (if it's true that <reference> tags now have all the same functionality), or from using LDRs. -- LCU ActivelyDisinterested «@» °∆t° 20:02, 29 April 2025 (UTC)[reply]
There's no reason for anyone to use {{reflist}} in 99% of cases, LDR or not. It should be deprecated across Wikipedia, not just for LDRs. --Ahecht (TALK
PAGE) 20:24, 29 April 2025 (UTC)[reply]
I think @Ahecht is right. Most of the times, using {{reflist}} instead of <references /> is like using a template to make text bold instead of using the ordinary ''' wikitext code. Back in the day, there were several differences (importantly, the template could do columns ~15 years ago, before the wikitext code had that built in), but those differences are few and far between now, and IMO the template should only be used when non-default features are actually wanted.
BTW, when we started using the template, we had the same arguments: Using the template is going to cause confusion, because people are used to the wikitext code. It's not actually a big deal. People figure out it. WhatamIdoing (talk) 20:56, 29 April 2025 (UTC)[reply]
My point about confusion was in regard to a situation where reflist would be used for the vast majority of articles, but not on the few that use LDRs. A situation that would be quite different from when editors started using the template. This wouldn't be the reverse, but a janky halfway solution. -- LCU ActivelyDisinterested «@» °∆t° 08:19, 30 April 2025 (UTC)[reply]
There is still a reason: if we ever want to add extra coding to references beyond the basic formatting that the references tag provides, having it in a template makes it easy and avoids having to persuade Wikimedia to maybe do it someday if they ever find the interest to listen to us. That is, it is more flexible and more robust.
Beyond all that, there is another reason: changing existing reflists to references tags in millions of articles would represent an enormous clog-up of everyone's watchlists for however long it would take to do so. —David Eppstein (talk) 23:44, 29 April 2025 (UTC)[reply]
Bots are hidden from watchlists by default, I think. Aaron Liu (talk) 03:21, 30 April 2025 (UTC)[reply]
Yes, it's quite trivial to hide bot edits, either through preferences at Preferences → Watchlist → Changes shown → Tick Hide bot edits from the watchlist, or ad-hoc using the filter button on the watchlist itself. Dan Leonard (talk • contribs) 03:55, 30 April 2025 (UTC)[reply]
Hiding bots means never seeing all the damage the bots sometimes do. I regularly check edits by bots and report on bad edits by bots. 99% of the time they are ok but that remaining 1% needs checking. I cannot do that if my watchlist is overwhelmed by thousands of bot edits.
Also, this issue goes far beyond list-defined references: it appears to be a general issue with VE not handling templates nested inside other templates. Working around it in this case will merely take pressure off the VE developers to make VE work without doing anything about the broader problem. —David Eppstein (talk) 04:58, 30 April 2025 (UTC)[reply]
Is that pressure having any effect anyway? Anomie⚔ 11:28, 30 April 2025 (UTC)[reply]
Just mark everything as seen right after the fixbot does things; in the worst case you can always just filter out the fixbot (which will probably be a one-off ish bot used to answer Wikipedia:AWB/R). And the pressure with reflist has been on to ten years; no one has found a non-hacky (without making up a list of hack templates that each wiki uses, which is a WONTFIX if ever there was one which I agree with) solution. Aaron Liu (talk) 12:27, 30 April 2025 (UTC)[reply]
  • Support : the problem seems unlikely to be solved any time soon (T52896). Maybe they underestimate how impactful the problem is, or maybe we underestimate the technical obstacles. But the VisualEditor is not a minor feature, so we should do what we can to accommodate its users. I don't see a good reason for using {{reflist}} instead of <references>. Alenoach (talk) 20:31, 29 April 2025 (UTC)[reply]
  • Support I use list-defined references as the most convenient way of handling citations. I wasn't familiar with the technicalities which have been presented here but they seem to make good sense. I'll start using <references> to see how it goes.
Note that this discussion has technical issues because of embedded tags which need considerable effort to decativate. I've just fixed Alenoach's post to turn off template bracketing which was messing up my post. We need some clerking to keep everything well-organised.
Andrew🐉(talk) 06:51, 8 May 2025 (UTC)[reply]
Dan, I'm not sure what would have been wrong with leaving the RfC here and simply advertising it. Since I'm commenting I'll mention that I use VE by preference; I never use LDR but would prefer to be able to edit those articles with VE if I come across them. I agree with some of David's points above, though; I don't think anything should be implemented that would flood watchlists, and I don't see any benefit in changing usages of reflist that are not implementing LDR. If you're going to reword this RfC, I think it should be narrowly defined. I'd specify that no bot edits should be done except when the edit accompanies an edit that would have been made anyway, to keep this off watchlists; and it should only affect LDR articles. David, the one point of yours I don't agree with is that we should leave reflist usages in place just in case someone finds them useful for parameter addition in the future. I think present value (to VE users, of whom there are many) is better than some possibly non-existent future value. Mike Christie (talk - contribs - library) 01:24, 30 April 2025 (UTC)[reply]
One of the most basic use cases of {{reflist}} is to allow multiple columns in the reference section on sufficiently wide screens and to control how wide these columns shall be. How does the <references/> tag handle this? Sorry if this is a noob question, but I didn't find it by a quick look at the docs. Gawaon (talk) 06:43, 30 April 2025 (UTC)[reply]
It doesn't handle it, and in those cases the reflist tag should be left in place. Though as far as I know one would never use the columns parameter with refs=, so it would be out of scope of this proposal. Mike Christie (talk - contribs - library) 11:33, 30 April 2025 (UTC)[reply]
That's not entirely correct. <references /> and {{reflist}} both use 30em columns when there are more than 10 refs. This can be disabled with <references responsive=0 /> and {{reflist|1}}. OTOH, reflist has more options: {{reflist|2}} and {{reflist|30em}} do columns without the "more than 10 refs" condition, and other widths besides 30em can be passed to {{reflist}} too. Anomie⚔ 11:45, 30 April 2025 (UTC)[reply]
This (having multiple columns without using the template) was implemented in 2017. WhatamIdoing (talk) 17:11, 30 April 2025 (UTC)[reply]
Including widths besides 30em? Aaron Liu (talk) 17:23, 30 April 2025 (UTC)[reply]
Aaron, I don't know the answer to your question (regardless of whether your question is a "When was widths besides 30em added?" or "Was support for widths besides the site-defined default ever added?"), but I wonder whether it matters in practice. I've never seen someone combining narrower column widths with LDR, because {{sfn}} is the main use case for narrower column widths, and those aren't put into LDR. Nobody's talking about an absolute requirement to do this without exception. A bot/AWB script that's capable of detecting whether an article is using LDR could trivially be programmed to leave it alone if other parameters are being used. WhatamIdoing (talk) 19:24, 30 April 2025 (UTC)[reply]
What about {{reflist-talk|refs=}}? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 08:26, 30 April 2025 (UTC)[reply]

Since I think this would be a very controversial and thorny RFC if proposed, I've started a proposal below for discussion. Dan Leonard (talk • contribs) 02:52, 30 April 2025 (UTC)[reply]

Working proposal (please edit)

Rationale

Reflist no longer needed in most cases

Early features of {{reflist}} included a different font size (90%) and automatic column handling. Today, both of these features are built into the Cite extension. As a result, the template, when called alone, is effectively a basic wrapper for <references />. Usage of {{reflist}} where the |colwidth= parameter is given are outside the scope of this proposal. Editors are still free to use the template where its features are actually desired.

VisualEditor support

VisualEditor cannot handle list-defined references when those references are defined inside of a template like {{reflist}}; however, it can handle <references><ref>...</ref></references> properly due to its closer integration with MediaWiki. Almost 200,000 pages have references defined inside of {{reflist}} and thus those entire articles cannot be contributed to by VE users (parameter usage report).

Documentation on this is lacking. Help:List-defined references says VE doesn't support the referencing style at all, and treats both methods as equivalent.

The VisualEditor war has been going on for a decade now and it's now used by a not-insignificant number of editors. While I think we'd all love if it worked well and didn't dump horrible <ref name=":0"> tags everywhere, "WMF should fix it, we shouldn't have to touch our templates" has gotten old.

Sub-referencing

WMDE is developing a Wikitext-based reference reuse handling they're calling sub-referencing. This should benefit editors of list-defined references by allowing page numbers to supplement citations to such references. Templates like {{reflist}} were cited as a major hurdle in the development of this tool.

Better handling of template limits

When the WP:PEIS limit is reached within an article before the references section, the reflist template will just render as Template:Reflist, whereas the <references /> tag will still function (although some citation templates may not render properly).

Sister projects have managed this

The Polish Wikipedia editors routinely check if {{Przypisy}} includes a list of references and, using pl:MediaWiki:Gadget-sk.js#L-575, replace it with <references />. One sticking point to keeping {{Przypisy}} without a list of references on that project was the replacement of a Polish word with an English one; however, this isn't relevant on the English Wikipedia.

Proposal

Change to documentation

The following pages will need to be updated to remove the equivalence between {{reflist}} and <references /> and encourage use of the latter by new editors:

Bot replacement

Uses of the {{reflist}} template that do not rely on its <div>-based formatting features should be replaced by a functionally identical <references /> tag.

−
{{reflist}}
+
<references />
−
{{reflist |refs=...}}
+
<references>...</references>
−
{{reflist |group=lower-alpha |refs=...}}
+
<references group="lower-alpha">...</references>

Discussion of proposal re deprecate {{reflist|refs= in favor of <references>?

[edit]
  • Some parts of the proposal above are impossible to read in dark mode because they have white text on white background. See mw:Recommendations for night mode compatibility on Wikimedia wikis for suggested fixes. -- Beland (talk) 10:07, 30 April 2025 (UTC)[reply]
  • What's the point of this proposal? I doubt it has more than a snowball in hell's chance of making it due to the flexibility of {{reflist}} to be used with or without a colwidth parameter making it too useful to give up without a good reason (which doesn't seem to exist), and spurious RfCs are a waste of editors' time. Why not rather focus on the original idea of deprecating the use of {{reflist}} with refs=, which seems to be the only actual problem anyway? Gawaon (talk) 11:50, 30 April 2025 (UTC)[reply]
    I don't see how specifying per-article column widths is that useful. Aaron Liu (talk) 12:32, 30 April 2025 (UTC)[reply]
    Well, following the recommendations in Template:Reflist, I tend to use the default setting when most references are "long" and there is no extra Bibliography section, while setting the colwidth to 20em for articles that use mostly short author–year references ({{sfn}} and friends) resolved in a Bibliography section. I also use 25em in articles that mix both styles more or less evenly. It's not essential, but it gives articles a nicer look. Gawaon (talk) 13:01, 30 April 2025 (UTC)[reply]
    Hmm, that does makes sense. Would a template that just applies a pre-set column width of either 20em or 25em on the <references/> fix that? Would not be hard to script if it just applies 20em or 25em every time, though it wouldn't support user-specified custom column widths. Aaron Liu (talk) 13:14, 30 April 2025 (UTC)[reply]
    Well it's in any case slightly more annoying and less intuitive to replace <references/> with a template than just adding or modifying a parameter to an existing template. Plus the idea of getting rid of {{reflist}} in favour of a tag is a solution looking for a problem, as far as I can tell. Hence I doubt it's going to fly. Gawaon (talk) 13:50, 30 April 2025 (UTC)[reply]
    solution looking for a problem the real problems with the template are listed above. {{reflist}} was created specifically to extend the parser tag and met very similar opposition fifteen years ago, it's worth considering now whether it's still needed in most cases. Dan Leonard (talk • contribs) 14:30, 30 April 2025 (UTC)[reply]
    I'm not saying that, I'm saying something like this:
    ==References== {{thincols}} <references />
    Aaron Liu (talk) 15:28, 30 April 2025 (UTC)[reply]
    @Aaron Liu, the Visual Editor wouldn't be able to handle that due to a different limitation. Try editing pages with the VE that use {{refbegin}} & {{refend}} for a list of full citations. Rjjiii (talk) 00:34, 2 May 2025 (UTC)[reply]
    There's no <references /> under refbegin, though. What I propose is just CSS templatestyles—it doesn't even change the DOM. There's no way it would break VisualEditor unless VE uses computer vision. Aaron Liu (talk) 00:56, 2 May 2025 (UTC)[reply]
    But to get the CSS to apply, won't you have to wrap the <references> with a div or some other element? Rjjiii (talk) 01:35, 2 May 2025 (UTC)[reply]
    No. It's done through a stylesheet that will apply to all invocations of <references /> on the entire page. You're thinking inline styles. Aaron Liu (talk) 01:41, 2 May 2025 (UTC)[reply]
    TemplateStyles can affect classes like reflist and reference-text? Rjjiii (talk) 02:01, 2 May 2025 (UTC)[reply]
    Yes. Just put the inline style you mentioned below into a selector for those classes. Demonstrated at User:Aaron Liu/sandbox#References using User:Aaron Liu/Refwidth using Template:TemplateStyles sandbox/Aaron Liu/refwidth-20em.css. Aaron Liu (talk) 11:38, 2 May 2025 (UTC)[reply]
    Wow, this is a really cool development and completely changes the whole proposal. I had no idea TemplateStyles was this powerful. Dan Leonard (talk • contribs) 17:05, 2 May 2025 (UTC)[reply]
    @Aaron Liu, I was mistaken; I just assumed they did not work that way. I tested something similar out in {{refbegin/sandbox}}. The first real issue I see is that they both do something to the effect of style="column-width:{{{any value}}}" which I don't think can be done with separate CSS. The first workaround that comes to mind is to create CSS classes for each width and maybe round the values down (so that 22em becomes 20em) to avoid having too massive a number. That still seems kind of wonky though Rjjiii (talk) 03:17, 2 May 2025 (UTC)[reply]
    @Aaron Liu, okay I did this in a way that feels goofy but seems to work? Check out this sandbox version of Open-source license in the VisualEditor. You should be able to see, edit, add, remove, and replace all references without any issues. You will not any styling affects unless you save the page. Regardless of changes to {{reflist}}, I may propose some version of this for {{refbegin}}. I think reflist deprecation may get limited traction though, because even without the template, the VE can't add or remove a LDR. Rjjiii (talk) 07:21, 2 May 2025 (UTC)[reply]
    This proposal specifically exempts uses of the template where editors feel a need for specific column widths. Many, if not the majority, of our articles use the default (blank or 30em) parameters. <references> now supports 30em columns as the default, so there's no difference between it and the template's default setting. Dan Leonard (talk • contribs) 14:32, 30 April 2025 (UTC)[reply]
  • As a purely practical measure, I suggest updating Help:List-defined references first. Also, we can probably get numbers on how commonly the visual editor is used here. The total was over 25,000,000 edits a couple of years ago. WhatamIdoing (talk) 17:17, 30 April 2025 (UTC)[reply]
  • I would strongly support this -- I use the visual editor and while I don't run into list-reference articles much, I wouldn't mind pasting in <references/> rather than {{reflist}} when I make an article. Every RfC gets "solution in search of a problem" comments, some more than others, but there definitely is a problem here to be solved. Mrfoogles (talk) 23:25, 3 May 2025 (UTC)[reply]
    (If you're in the visual editor, then you don't have to paste in that code. It's in the menu under Insert > References list.) WhatamIdoing (talk) 00:24, 4 May 2025 (UTC)[reply]
  • Hi, I'm Johannes from Wikimedia Deutschland's Technical Wishes team. I noticed this discussion mentioned sub-referencing, the feature we are currently working on. Some thoughts on {{reflist}} and <references>:
    • As far as I know one major reason for creating {{reflist}} was the desire to render reference lists in multiple columns. Some projects (e.g. itwiki [1]) decided to deprecate their local reflist equivalent when responsive reference lists got introduced to MediaWiki in 2017 [2]. The feature works for both inline reference lists (<references responsive />) and list-defined references (<references responsive> ... </references>).
    • We initially based sub-referencing (our upcoming MediaWiki feature for re-using references with different details) on list-defined references, but moved away from the initial concept because we haven't been able to make it work with templates like reflist in VisualEditor. The new approach for sub-referencing is primarily based on in-line references [3], to avoid issues for VisualEditor users. Using list-defined references and sub-referencing will still be possible, but leads to the existing issues for VE users when using {{reflist}}.
    • We've investigated the use of templates like reflist on several wikis and documented our findings in phab:T377043, perhaps it's useful for future discussions.
    --Johannes Richter (WMDE) (talk) 12:59, 9 May 2025 (UTC)[reply]
    I think it would be better if the references tag would automatically minimise vertical space. If you have an article which is essentially all short citations it's too sparse even on default two-column. Ifly6 (talk) 15:55, 9 May 2025 (UTC)[reply]
    I think one of the problems with LDR is for wikitext editors. Adding a sentence and a source requires two edits: the first to the ==Section== where the content belongs, and the second to the ==References== to add the source. WhatamIdoing (talk) 16:38, 9 May 2025 (UTC)[reply]
    For wikitext editors, I see it as a tradeoff; having to make two edits, versus having to pick out the references from the running text. For me, making the two edits is easier. Jc3s5h (talk) 17:20, 9 May 2025 (UTC)[reply]
    I exclusively edit wikitext and find LDR particularly suited to the task. LDR massively reduces clutter in the editing window and allows me to just work on the prose. The Visual Editor masks the content of <ref> tags regardless of the referencing style, but when I use wikitext and LDR I don't have to deal with templates and reference text filling up the window. Compare the wikitext of Sheetz–Wawa rivalry with Pope Leo XIV, for instance. I can easily discern the prose in the former but the latter is a complete mess. Having to make a second edit is trivial compared to the massive readability benefit. It's also analogous to writing scholarly papers: I'd add a sentence to my paper and then separately go into my reference management software and add the reference. Dan Leonard (talk • contribs) 17:58, 9 May 2025 (UTC)[reply]
    Agree with Leonard. Only reason I don't use it is I'm too lazy. It's not like it's super-hard to just edit the entire article or make the edit to /* References */ first. Aaron Liu (talk) 21:00, 9 May 2025 (UTC)[reply]

" The use of citation templates is neither encouraged nor discouraged"

[edit]

Really? Maybe long, long, ago, but isn't now the consensus that citation templates use is best practice? Semi-random ping to @SandyGeorgia - are modern FAs allowed to have no citation templates? Piotrus at Hanyang| reply here 05:53, 1 April 2025 (UTC)[reply]

I prefer citation templates, and I don't know if the requirements at FA are different, but text based references are still somewhat commonly used. -- LCU ActivelyDisinterested «@» °∆t° 08:31, 1 April 2025 (UTC)[reply]
The lack of a uniform citation style is the most glaring style problem in Wikipedia. What we permitted years ago to encourage the expansion of the encyclopedia under the banner of "everyone can edit" now makes us look embarrassingly amateur. We should decide on a preferred style and make plans, with the help of intelligent bots, for adopting it universally in the long term. Zerotalk 10:27, 1 April 2025 (UTC)[reply]
I have used citation templates exclusively for years, so yeah, so I will support anything that moves WP to more use of templates. A plan to gradually adopt templates as the standard for citatons is more likely to reach consensus. Donald Albury 14:29, 1 April 2025 (UTC)[reply]
I would also support a default for switching to CS1 citation templates with default short citation formas in {{sfn}} – imo {{rp}} is just bad – with explicit proviso that custom anchors are permitted. Custom anchors are needed to deal with sources that don't have years (eg Suetonius, Augustus) as is common in classical studies. They can similarly can be used if an article benefits from shortened anchors (eg CAH2 9) or general short cites by title.
One of the huge benefits of the {{sfn}} "ecosystem" is the ability to produce full listings of missing anchors and sources. You simply can't do this with the text-based anchors. A text version of the citation Smith 2000, § 3.14 with no corresponding bibliographic entry for Smith 2000 is nonsense and we really need ways to track this automatically. Then we can actually go and solve those problems. Though, for some certain self-contained corpuses of citations this can be unnecessary. Eg Plutarch, Marius is evident by convention. A tag here is useful mostly for people who don't know that convention and I usually try to provide it for such sources cited more than once or if translated.Ifly6 (talk) 15:17, 1 April 2025 (UTC)[reply]
We should consider the new parameter, details, being developed for the <ref> tag, currently under development. See my example on the Beta-Cluster. Also see m:Talk:WMDE Technical Wishes/Sub-referencing#Request for feedback. If successful, this could eliminate the need for {{sfn}} and its ilk. (For the Beta Cluster you might have to sign up for an account. Also, it isn't always working.) I am not a developer; maybe one of these days they will officially designate me as a pest. Jc3s5h (talk) 15:46, 1 April 2025 (UTC)[reply]
That seems a bit restrictive in terms of narrative footnotes which say something like Gruen 1995, p. 123, however notes that Dio, 3.14.15, contradicts the narrative in Suetonius, Julius, 1.2.3 or But see Woodman 2021 for alternative views on blah blah. While {{sfn}} is somewhat inherently restrictive, ref + {{harvnb}} essentially solves. One of the developers notes that those notes automatically merge, though, which is a must-have. I'm also not a huge fan of the anchors; imo anchors should match display text. Ifly6 (talk) 15:53, 1 April 2025 (UTC)[reply]
I'm afraid a talk page is not the right medium for Ifly6 to convey their point. Jc3s5h (talk) 15:57, 1 April 2025 (UTC)[reply]
I would strongly oppose any push to require citation templates, because (1) the citation templates more and more over the years have been pushed into a rigid format that makes it very difficult for human editors to edit by hand and get right, (2) this rigid format makes it frequent that what you want to cite does not fit into that format and should not be distorted to make it fit, and (3) we have bots running rampant over our articles repeatedly massaging templated citations into what they think is the corrected version of the same citation, but the bots often misunderstand citations (especially when the citation is to a review of another citation or to a reprint of another citation) and formatting a difficult citation manually can be a deliberate defense against those bots. —David Eppstein (talk) 16:23, 1 April 2025 (UTC)[reply]
Can you show an example of this for illustration? Ifly6 (talk) 16:36, 1 April 2025 (UTC)[reply]
Just trawl through the history of User talk:Citation bot and you will find many errors of these types. Often they get fixed, meaning that the exact circumstances that caused this behavior will not immediately trigger the same error. This does not fix the general issue. (The same issue extends to gnomes as well as bots; I had to today revert a gnome who tried to insert repeated fake titles on a collection of book reviews that had no title and were properly formatted using citation templates using title=none, presumably because that parameter value lists the article in CS1 maint: untitled periodical. Manually formatting the book reviews would have avoided that problem and in part because of that I have been manually formatting book reviews more often recently.) —David Eppstein (talk) 23:29, 1 April 2025 (UTC)[reply]
Making a {{cite book review}} would help bots and people distinguish between an author incorrectly being put in the title vs. the name of the author being reviewed being part of a correct title. Using a template like that would make it easier for downstream machine consumers (like sites that aggregate references to a work or an author across many sources) to parse these weird cases as well.
I expect most people prefer to use HTML forms or wizards to make citations rather than raw wikitext, unlike us long-time editors. It is difficult to implement that without machine-writable templates. If templates don't support pretty much the full universe of cases, then we're discouraging a lot of editors from properly citing their work, so we should make an effort to flesh them out. Personally, I find it's a big pain to remember what punctuation to use where; it's much easier to use templates that tidy up after me. It also would be soooo much easier to change the output later across millions of pages if consensus changes about the punctuation and formatting.
-- Beland (talk) 09:43, 30 April 2025 (UTC)[reply]
The current status is one may follow a printed style manual (like The Chicago Manual of Style (CMOS), and other editors will respect that choice. (Actually respect, not just tolerate). If an editor makes up a style just for a certain article, theoretically it's allowable, but in practice other editors can't follow it because they can't read the original editor's mind. The nearest thing we have to a style manual for citation templates is Help:Citation Style 1, but it has problems.
  1. It doesn't purport to be complete. On many points it defers to the style in a particular article, such as sentence case or title case for titles of works cited, giving full first names for authors or just initials, etc.. It is only 25 pages long when exported to PDF, compared to 177 pages for the relevant chapters in CMOS 18th ed.
  2. There is no policy that the implementation of the citation templates follow the documentation. If a graduate student at a US university submitted a paper that was required to follow a published style manual, but the citation software used by the student flagrantly deviated from the manual, the student would fail the course. In Wikipedia, some comments would be put on some talk pages and nothing would happen.
  3. It is absolutely fundamental that a reliable source should never be disqualified because there isn't a citation template to support it. Hand-written citations must always be allowed in this case. But there is no manual to follow when writing such a citation.
  4. Since 2020 parenthetical referencing has been deprecated on Wikipedia. As a result, the only acceptable remaining style is endnotes. Respectable published style guides that recommend endnotes or footnotes separate citation elements with the comma, as in "James II of England". But most Wikipedia articles separate them with periods, as in "Nato phonetic alphabet". This should be fixed.
Jc3s5h (talk) 16:27, 1 April 2025 (UTC)[reply]
If we want to change the "neither encouraged nor discouraged", then we probably need an RFC.
I suggest keeping it simple and focused. For example, despite what @Ifly6 says, mentioning {{sfn}} will provoke opposition (because it is not used in ~98% of articles and is not wanted in subject areas that rely primarily on short articles instead of books/sources that need to give specific page numbers), and it is largely irrelevant, so it shouldn't be mentioned.
The simplest is probably to use the "change X to Y" format. For example:
  • Should we change "neither encouraged nor discouraged" to "gently encouraged but not required"?
  • Should we change "neither encouraged nor discouraged" to "preferred but not mandated"?
  • Should we change "neither encouraged nor discouraged" to "by far the most popular choice, but not required"?
I have, in other areas (e.g., MOS:APPENDIX), had good success with declaring a given option to be "popular" rather than "preferred". Editors tend to choose the popular/normal/usual approach. WhatamIdoing (talk) 17:00, 1 April 2025 (UTC)[reply]
When wording the RFC, keep in mind that if it succeeds, some editors will try to interpret the new wording as license to change articles to citation templates without seeking consensus, just as one may now change an article from parenthetical referencing to endnotes without seeking consensus. Jc3s5h (talk) 17:14, 1 April 2025 (UTC)[reply]
Perhaps the entire WP:TEMPLATEREFS sentence (or even the whole/short paragraph) should be in the RFC. The specific sentence currently says: The use of citation templates is neither encouraged nor discouraged: an article should not be switched between templated and non-templated citations without good reason and consensus – see "Variation in citation methods", above.
That could be changed to something like "The use of citation templates is popular, though not required. However, an article that predominantly uses a non-templated style should not be switched without prior discussion – see "Variation in citation methods", above" (example text only; write whatever you think would be helpful). WhatamIdoing (talk) 17:39, 1 April 2025 (UTC)[reply]
(1): I don't see much ambiguity about when to use sentence vs. title case; the CS1 page has guidance for which fields use which. For the "first initial vs. first name" question, it seems to me we should always put the full name, unless only the initial is available, for disambiguation purposes - especially given that Wikipedia citations have machine consumers that correlate authors. Are there only a few remaining questions we could easily answer? Or would we want to pick the third-party style guide closest to general Wikipedia practice as a default? Or provide a short list of third-party guides and let articles pick one?
(2): Isn't it common sense that if a template does not match its documentation (or the MOS), one or the other should be changed? Making that common sense into a policy wouldn't magically summon volunteer labor to do the implementation work.
(3): If we decided to go full-template, presumably if there are situations not covered we'd add parameters or additional templates. Situations not covered in the meantime would simply remain non-compliant. We could, if we wanted, designate a third-party style guide as a default or allow an article to choose from a short list of popular third-party styles.
(4): I think what you are describing is Citation Style 2? I would support merging these two styles so that there is more site-wide consistency, but I have no opinion as to the most "respectable" punctuation. -- Beland (talk) 09:25, 30 April 2025 (UTC)[reply]
FAs are allowed to have any consistent citation style, whether produced by templates or handwritten. Nikkimaria (talk) 00:34, 2 April 2025 (UTC)[reply]
Pinged here ... agree with Nikkimaria. I don't see a need for any change; not broken, doesn't need fixing. SandyGeorgia (Talk) 01:32, 2 April 2025 (UTC)[reply]
I would support changing guidance to say templates are "preferred" and letting people change articles to use them without any further discussion. This makes formatting more consistent because there's less room to be sloppy, automates the process of finding some incomplete or bogus citations, makes it possible to write user-friendly GUI tools that hide the raw wikitext, significantly simplifies the parsing downstream consumers have to do thanks to COinS (e.g. citation aggregation sites, author profile builders, archive.org). Clarifying badly-formatted citations will probably help with the enormous task of fact-checking all our content. This process will probably also shake out some citation styles that should not be used on Wikipedia because they are so radically different from what is done on the rest of the site. And maybe one or two we want to keep but give them their own templates. -- Beland (talk) 10:01, 30 April 2025 (UTC)[reply]
Does the community actually want to be "letting people change articles to use them without any further discussion"? WhatamIdoing (talk) 18:32, 30 April 2025 (UTC)[reply]
I would support doing an RFC to find out. I often do so for one or a handful of citations at a time, and I don't remember anyone reverting that on the grounds the article doesn't use a template-compatible citation style. (I do remember some confusion about how to cite web pages that are only accessible from archive.org.) Often I'm switching to templates because they handle square brackets in titles without awkward escaping. -- Beland (talk) 19:26, 30 April 2025 (UTC)[reply]
I suggested a couple of possible alternative wordings above. Do any of those appeal to you? WhatamIdoing (talk) 19:30, 30 April 2025 (UTC)[reply]
I would go for the full throated version - change "neither encouraged nor discouraged" to "preferred", not "preferred but not mandated" or the other suggestions which seem to leave a lot of wiggle room for arguments to break out. -- Beland (talk) 19:42, 30 April 2025 (UTC)[reply]
I realized another benefit of going full template - just as we have the ability to set "mode=cs2" once for an entire article, we could add "mode=chicago" or "mode=mla" or whatever alternative styles the community can't bear to part with. This would let us change styles for an article very easily (except perhaps if downcasing is needed?) if consensus changes about which articles need which style, and it would also strongly enforce per-article consistency without forcing any particular citation style. I like the idea of having a short list of approved styles, because readers encountering a very rare citation style are likely to be confused or maybe assume it's the result of sloppiness. The fewer citation modes the better in my opinion, but this might be a compromise of the sort you're looking for in order to widen support. -- Beland (talk) 19:48, 30 April 2025 (UTC)[reply]
All I can say is that if we go “full template”, I will no longer be able to contribute to Wikipedia. Perhaps I am too old. I still think in terms of sentences and paragraphs, not data parameters and fields. I never learned how to use templates, and don’t really have any interest in learning now. I still format citations by hand. I am fine with others following along after me and inputting my citations into a template, but I’m never going to create a new citation using one. Oh well… time to catch the early bird special at the Golden Corral and then go watch Matlock. Blueboar (talk) 20:25, 30 April 2025 (UTC)[reply]
@Blueboar:All I can say is that if we go “full template”, I will no longer be able to contribute to Wikipedia. You appear to be assuming that you'd have to type these templates out by hand, which has never been true. Polygnotus (talk) 01:44, 2 May 2025 (UTC)[reply]
There's no reason for you to quit Wikipedia; even if the MOS says templates are preferred, I (and I hope all other editors) will be happy to accept your hand-formatted citations, and leave converting them to templates to a wikignome. -- Beland (talk) 20:55, 30 April 2025 (UTC)[reply]
I've inquired about the prevalence of citation templates at Wikipedia:Village pump (technical)#Prevalence of citation templates, and it looks like ~80% of articles use the main citation templates.
I hope that if the community decided to officially "prefer" citation templates, they would also choose to reiterate the main behavioral goal: While you should try to write citations correctly, what matters most is that you provide enough information to identify the source. Others will improve the formatting if needed. Or, to put it more simply, do your best. Nobody should get hassled about how they format a citation so long as (a) we have enough information to identify the source and (b) they don't revert if someone comes along after to "fix" it. WhatamIdoing (talk) 23:20, 30 April 2025 (UTC)[reply]
If the community decides to officially "prefer" citation templates, it should only do so at a time when the citation templates are capable of fully formatting all citations. That time is not now; the citation templates are too inflexible, and too prone to raising errors in common use cases (such as that we wish to cite the original publication of a book source but include the isbn of a reprinted copy of the same book). —David Eppstein (talk) 00:17, 1 May 2025 (UTC)[reply]
Isn't that already possible? There's no validation of ISBNs, but you could always do {{cite book |title=Original book |year=1901}} etc. for the original copy, followed by a separate {{ISBN|1234567890}} if you wanted to keep them apart. WhatamIdoing (talk) 00:39, 1 May 2025 (UTC)[reply]
@Blueboar Few thoughts (speaking as someone who remembers time before the Internet, too...). First, I'd expect that "old geezers" from my and older generations are familiar with forms to be filled in. Templates are just that. I don't think filling in a form takes longer than writing a citation by hand. (I am assuming, of course, the use of VE or such, doing this by typing the code is painful, please don't). Second. Templates enable various uses of metadata. They make citations better just like hyperlinks makes text better, or computers enable Wikipedia. They are a step in the right direction. That third, my third point - frankly, conversion of citations from free flowing whatever written format into templates is something that AIs should be able to handle. I don't know when we will have a bot or gadget for that, but just run ChatGPT or such in a window where you run a task telling it to turn it into Wikipedia citation template code, and voila, you should get a well formatted code to paste back into wiki in a second. So, errr, there's no need to leave or such. Learning how to use the better system (and yes, because of metadata, it is strictly better, no ifs and buts) in this case is not hard - just fill in a simple form, or have AI give you a code. Look, I understand the issues (annoyances) of unfriendly new interfaces well, but in this case, it's easy to move from old, inferior output to the new, superior one. Really. Try it. Piotrus at Hanyang| reply here 04:47, 2 May 2025 (UTC)[reply]
Forms work great for a database… not an encyclopedia. Blueboar (talk) 12:13, 2 May 2025 (UTC)[reply]
Huh? They work perfectly fine for me and all others who use VE, or tools like TWINKLE... Piotrus at Hanyang| reply here 13:25, 5 May 2025 (UTC)[reply]
There have been similar entertainings regarding other styles in the CS1 module (MLA and Vancouver particularly), and they've either just gotten nowhere or I suspect more commonly were not friendly to integrate with the current structure of the module set and so were given up on. Were something like this to be done, I suppose it would be possible to place them in their own modules and then call those only when a certain parameter is provided to the CS1 module, but even today there are some checks that CS1 makes very early in the execution of the module which may be inapplicable in other older/recognized citation styles. So you might as well start your own module. Module:Cite LSA used to exist as one attempt at this, and there are a few Bluebook style citation templates that have a bare minimum of centralization. For what code sharing might be possible because arbitrary style does ask for a review, I've mused before on the CS1 help talk page, but I suspect those have gone nowhere for time and little or no known potential users. (For example, the ID and access date checking that CS1 does. Of course, then we're imposing some burden both on CS1 and external users of CS1, primarily at our sister and sister language wikis.) Izno (talk) 23:04, 30 April 2025 (UTC)[reply]

@David Eppstein: you mentioned above that the current set of citation templates are not ready to be preferred because not all works can be cited with these templates. It seems to me they're really not ready for use at all, because at any time a need to add a new citation to an existing article that already has a long list of citations, but no existing template is suitable for the work to be added. The problem is all the existing template documentation is focused on which template to use, and how to set the parameters. It's hard to find examples of how citations should look when they are rendered; any such examples are scattered and disorganized in the documentation.

If proper documentation existed, an editor who had to add a citation for something that isn't supported by any existing template could decide which template is the closest fit, and hand-write a template that generally resembles one of the existing templates. Jc3s5h (talk) 01:05, 1 May 2025 (UTC)[reply]

It's a fair point that existing templates don't handle all use cases, but that may be because there is no guideline pushing people to use them in all cases. My expectation if templates are "preferred" would be that unhandled cases would be left hand-written until someone created a template to handle them. Based on this feedback, maybe we need to say that explicitly. How about:
The use of citation templates is preferred for situations the templates are designed to handle. Templates should be expanded or created to cover the remaining situations that would otherwise need to be manually formatted.
"Situations" might include the need to support rare citation styles, though I hope this is not the case. I see templates supporting CS1, CS2, Vancouver, Bluebook, and Harvard. Do we know of any articles that consistently use a style that is not one of these?
I don't see why extensive documentation is needed, though some basic points are helpful. But if you need to create a new template and you want to see how e.g. the CS1 templates render something close to your use case, just plug the relevant parameters into a template and preview it or put a copy in your sandbox. Adding too much documentation increases the risk that the code and the documentation get out of sync, which will not help someone trying to expand the system.
In any case, I think the existing templates cover 80-90% of what is needed, and I'm sure we have plenty of work converting those to keep us busy while template builders expand support. -- Beland (talk) 02:23, 1 May 2025 (UTC)[reply]
There are plenty of FA-level articles that use nontemplated styles. Many people who do scholarly work off-wiki can comfortably format citations consistently by hand, so I don't know why we would do "plenty of work" to change them. And it's trivially easy to create inconsistently formatted citations using templates. Nikkimaria (talk) 02:47, 1 May 2025 (UTC)[reply]
Those scholars can continue to contribute hand-formatted citations, and if you don't want to do any work on this, you don't have to. A good reason to change them is that they are not emitting COinS metadata, and thus are slightly less useful to downstream consumers. It's easier for scripts to validate the contents of individual fields than it is to make sure that all the punctuation and italics and everything in a hand-formatted citation is done correctly. I mean, how would a script be able to tell the difference between a chapter in a book and an article in a journal if the formatting can't be trusted because it's what's being checked? Featured articles are about 0.1% of the overall encyclopedia. The fact that they're nice and tidy should be celebrated, but that doesn't obviate the problem of the millions of untidy articles. -- Beland (talk) 08:18, 1 May 2025 (UTC)[reply]
I personally think that millions of articles looking untidy is a feature, not a bug. What a focus on compliance with the MoS even for poorly written articles that cite unreliable sources does is put a huge amount of precisely defined lipstick on pigs. Unifying the citation style of articles should not be done before checking the actual content of the citations. —Kusma (talk) 08:42, 1 May 2025 (UTC)[reply]
I see your point, and I do actually use poor formatting as a proxy to automatically identify articles with dubious content, though that's usually a pile of unreferenced strings. But it would be awkward to try to preserve this potential signal as long as possible by making a rule that wikignomes aren't allowed to clean up spelling, punctuation, citation formatting, etc. without verifying the claims being made in the prose they are tidying and that the sources are cited accurately. Often that happens naturally, and it's easy to catch glaring problems when doing that, but fact-checking takes so much longer than tidying up, it lags by decades. We also don't have a way of checking which passages have already been fact-checked, which would lead to a lot of redundant work. At the very least I do tag prose I've just made from a pile of dubiousness into a clean, grammatical flow as needing citations if it doesn't have any.
The Guild of Copy Editors does actually reject unreferenced passages; these do tend to change a lot when the first sources are added, which is extremely healthy. But after that, as soon as someone has put in enough effort to make plausible footnotes, the text is considered stable enough to deserve tidying.
If I had to guess, I'd say we have greater problems with claims not matching cited sources with mature citations rather than when the citation is first added. People tend to edit article prose without verifying that the new claim is still supported by the footnote at the end of the sentence, and sometimes sentences get combined or split and footnotes wander around. -- Beland (talk) 09:38, 1 May 2025 (UTC)[reply]
Jc3s5h, can you give me an example of a work for which "no existing template is suitable"? WhatamIdoing (talk) 02:58, 1 May 2025 (UTC)[reply]
{{Cite map}} requires a title. Suppose a map doesn't have a title. Style guides typically say to give a description of the map where the title would usually go, but not use quote marks around the description, and not use italics, so readers can tell it's just a description. Jc3s5h (talk) 04:32, 1 May 2025 (UTC)[reply]
@Trappist the monk, what would you recommend for a CS1 template that doesn't require a title when the work is untitled? WhatamIdoing (talk) 05:24, 1 May 2025 (UTC)[reply]
Jumping in randomly here...my first thought would be we could add a "no-title-desc" parameter to {{cite map}}? I would also be tempted to put parens instead of quote marks like, (untitled map of Massachusetts Bay Colony) but perhaps this is not common practice in professional citations. I'm also wondering if this has actually come up or if this is speculative? Text works with no title (as used to be common practice) are named by the first few words; see MOS:INCIPIT. -- Beland (talk) 08:27, 1 May 2025 (UTC)[reply]
cs1|2 journal templates support |title=none which suppresses the rendering of the article title. That was intended to be used for en.wiki articles that followed the citation tradition wherein the title of the cited article is not made part of the citation. I suspect that most if not all uses of |title=none are not used to maintain that traditional substyle.
I once suggested that cs1|2 might support a |description-in-lieu-of-title= sort of parameter (in need of a better name) that would render an unstyled description in place of |title=. That suggestion died aborning.
—Trappist the monk (talk) 13:30, 1 May 2025 (UTC)[reply]
@Trappist the monk, are you sure about that? This: "none". doesn't look like suppressing the rendering of the article title to me. WhatamIdoing (talk) 20:55, 1 May 2025 (UTC)[reply]
cs1|2 journal templates support |title=none
{{cite journal |title=none |journal=Journal}} → Journal.{{cite journal}}: CS1 maint: untitled periodical (link)
—Trappist the monk (talk) 21:27, 1 May 2025 (UTC)[reply]
Perhaps that feature should be extended to {{cite map}} (or generally; there are webpages with no titles, too). WhatamIdoing (talk) 22:06, 1 May 2025 (UTC)[reply]
Journal templates do not support title=none when there is a url present. In general, webpages are going to have urls and urls are going to block the citation templates from supporting title=none even if that support is extended to non-journal templates. —David Eppstein (talk) 22:28, 1 May 2025 (UTC)[reply]
That makes sense because we need a title for the link.
Not putting the title of the article being cited in the citation to the article...sounds crazy when I say it out loud? Is there an article with an example of this? -- Beland (talk) 01:10, 2 May 2025 (UTC)[reply]
Sometimes there just isn't a title. Consider a sign: Maybe it will have a title, and maybe it won't. A letter is another source that often doesn't have a title. WhatamIdoing (talk) 01:39, 2 May 2025 (UTC)[reply]
Sure, but a sign is not an journal article. What I'm scratching my head over is why a citation wouldn't have the title of a journal article when one exists. I feel like I need an example for context. -- Beland (talk) 02:46, 2 May 2025 (UTC)[reply]
There's plenty of solutions for this, see Help talk:Citation Style 1/Archive 98#Handle title=none with url better.
Why those aren't implemented is beyond me. Headbomb {t · c · p · b} 00:53, 7 May 2025 (UTC)[reply]
Another example that I run into all the time is book reviews, which don't usually have titles, or are labeled with things formatted as titles that are not really titles like "Reviews - Euler’s gem, by David S. Richeson. Pp. 336. £16.95. 2008. ISBN 978 0 691 12677 7 (Princeton University Press)". When the review is published in a journal and has only a doi link, then the cite journal template can handle it with title=none, but most other formats of book reviews cannot be handled by the templates without making up a nonexistent and therefore false title. We should not be putting false information into the encyclopedia, not even in references and not even because the template doesn't work without it. And the bots that run around "improving" citations will often get confused by citations to reviews and mix them up with citations to the thing being reviewed or vice versa (an egregiously bad example from today: [4]). To avoid both problems I've taken to frequently formatting references to book reviews manually instead of with the templates. —David Eppstein (talk) 04:53, 1 May 2025 (UTC)[reply]
It's unclear to me if the example you link to is a problem with the bot or the human operating it? It's also unclear to me what the thing being cited is. Is it a book or an article or a review of a book or ?
If a journal publishes a book review just titled "War and Peace by Herman Melville" then I agree it might be confusing and arguably incorrect to put "title=Review of War and Peace by Herman Melville". It seems better to have output like:
"[Review of] War and Peace by Herman Melville". Archimedes Syracuse.
or
"War and Peace by Herman Melville" (review by Archimedes Syracuse).
or whatever the professional style guide specifies for these situations. It might be useful to have separate fields like "reviewed_title" and "reviewed_author" if we need to fabricate strings but make it clear they are not a word-for-word title the reader should be looking up. Or a separate template like {{cite review}} to take the same fields as e.g. {{cite journal}} but produce different output with "review" in there somewhere. -- Beland (talk) 08:50, 1 May 2025 (UTC)[reply]
The example I link to was a perfectly good and perfectly normal citation to a book. Until Citation bot got to it. Citation bot somehow discovered the existence of a review of that book in the journal Nature and half-converted the citation into a Frankenstein citation half about the book and half about its review.
It is useful to cite things that have reviews. It is also, separately, sometimes useful to cite the reviews of those things (for instance in articles about the things being reviewed). Many humans are capable of distinguishing which kind of citation is intended and keeping them distinct from each other. The bots have demonstrated themselves to be incapable of this. This bot misbehavior makes it problematic to have templated citations to reviews because the bots are likely to misinterpret them and break them. —David Eppstein (talk) 16:47, 1 May 2025 (UTC)[reply]
Huh. I would expect citations to books to use {{cite book}}. Still unclear to me if there is a human review step that should have caught this? -- Beland (talk) 01:13, 2 May 2025 (UTC)[reply]
If you're referring to the fact that the bot citation damage involved a {{citation}} template rather than a {{cite book}} template: that is one of the key differences between Citation Style 1 and Citation Style 2. In Citation Style 1 editors have to figure out which of many different citation templates to use and the automatic tools frequently get it wrong calling them all cite web. In Citation Style 2, everything uses one template, {{citation}}. The other difference is. That Citation Style 1. Has many periods. That break up. The flow. Of the citation. Citation Style 2 uses commas, instead.
I'm surprised you wouldn't know this already. Am I misinterpreting your reply? —David Eppstein (talk) 07:46, 2 May 2025 (UTC)[reply]
Either template can produce either output style with the "mode" parameter if the default output is not desired. I guess I'm just not in the habit of using {{citation}}; it seems a bit more vague, but of course it's not wrong to use it.
That really wasn't the important part of my comment. Since no one was answering my question, I went ahead and tested the Fundamental theorem of calculus scenario. Citation bot does not give humans a chance to preview its changes before it makes them, it only gives them a link to the diff afterwords. Though in this case, even if I had manually checked the source, it's unclear I would have noticed that it was a review and not the original work. Both the bot and the humans can be confused because the review has all the same metadata as the original work (with the complication that two authors are usually mentioned rather than one). I can't think of a good way to distinguish the two automatically, so humans just need to look out for this. It's possible looking for key phrases on the page (in this case, "review" isn't used, but "Books Received" is) could be used as a trigger to put up a red flag for the human user. This isn't 100% reliable because e.g. "reviews" would also show up on literature review articles. It's also possible the review is in fact what is being cited, so it's not great to use as an automatic exclusion. For now, I have added a note to User:Citation bot flagging this for humans generally.
The point of Citation bot is to provide readers with easier access to sources, gets get quite a bit of use, saves a lot of work, and works well in the vast majority of cases - so I would be reluctant to try to revoke its bot approval. Even this error will bring readers to a review of the source they are looking to read, which has a relatively straightforward recovery since they still have access to all the correct metadata once they realize what has happened.
There is no need to use hand-formatted citations to prevent the bot from altering a citation. Its documentation shows how to exclude the bot from an entire page or from a single citation known to be problematic (I would prefer the latter for ease of long-term maintenance). -- Beland (talk) 22:04, 2 May 2025 (UTC)[reply]
And then the people who maintain the bot go around removing these exclusions when they think they have fixed the very specific issue that caused the bot to misbehave once and be tagged for exclusion. But the problem is not specific bugs; it is that certain classes of issue require human understanding that the bot lacks. We have just this month had a Citation bot user blocked after an ANI thread because they thought the bot could be run without supervision and were blowing off complaints about the resulting bad edits. The bot is usually useful but occasionally causes problems, and needs checking. —David Eppstein (talk) 18:20, 3 May 2025 (UTC)[reply]
I've not seen people removing nobot exclusions, but if they do, it could help to put in the exclusion comment what to check after removal. But people could just as easily go around switching hand formatted citations to templates and not know that the reason they were hand coded was bot danger, rather than simply laziness. It seems better to explicitly declare bot incompatibility than lay a trap of a secret workaround. -- Beland (talk) 01:50, 4 May 2025 (UTC)[reply]

I have started Wikipedia talk:Citing sources#RFC on preferring templates in citations. -- Beland (talk) 23:54, 6 May 2025 (UTC)[reply]

RFC on consistent styles and capitalization of titles

[edit]

Is consistently using the capitalization used by sources (except for all-caps titles) considered an acceptable reference formatting style? WhatamIdoing (talk) 17:27, 1 April 2025 (UTC)[reply]

  • No. "Matthew Stafford Voted Comeback Player Of The Year By PFW/PFWA" is leading case. "League's 1st championship game, draft highlight NFL in 1930s" is sentence case. "1976 Detroit Lions Rosters, Stats, Schedule, Team Draftees" is title case. Putting all three of these capitalization styles into the same article would not be "a consistent style" within the meaning of WP:CITESTYLE. WhatamIdoing (talk) 17:28, 1 April 2025 (UTC)[reply]
    • I want to add: The most important thing about citation formatting is that you do your best to identify the source. That has been a key point in the lead of this guideline for many years. So what this really means is: If you copy/paste from the sources or use a ref filling tool (which most of us do), and someone else decides to WP:VOLUNTEER their time to capitalize all the titles one way or the other, you shouldn't revert them back to a mishmash of styles. But if you don't think capitalization is all that important, then IMO you are still free to focus on the things you believe are important, and leave the capitalization question to people who care about it. WhatamIdoing (talk) 17:33, 1 April 2025 (UTC)[reply]
      Instead of running around and changing the style it sounds like that's something that should be discussed on a case by case basis, as we would normally do when changing the style of citations in an article. Many people, myself included, prefer to preserve the capitalization used by sources, keeping a source to reference integrity in a sense. Additionally, how do you deem what the better style is? All sentence case? All title case? Either way, it's something that would be discussed on a per case basis instead of something that should be mass changed across articles. Hey man im josh (talk) 17:36, 1 April 2025 (UTC)[reply]
      Some readers find inconsistent capitalization in footnotes on the same article looks sloppy or jarring or unpleasant. If "retain the capitalization of each source" is banned as a "consistent" style because of that sort of objection, the style that each article adopts would be controlled by WP:CITEVAR. Which mostly means, whichever style arrives first, if one is not already dominant. There is no need for a source-by-source or article-by-article discussion, unless an editor wants to change an established style to a different one - for example if a specific style is common in the field the article is describing. -- Beland (talk) 19:28, 29 April 2025 (UTC)[reply]
    With apologies to WAID (I'm not trying to nitpick), the title case in your example should read: "Matthew Stafford Voted Comeback Player of the Year by PFW/PFWA". Boghog (talk) 18:54, 1 April 2025 (UTC)[reply]
    Leading case upcases every word, not just the ones your (and my) English teacher approved of.
    Those three examples were all taken from a real article. Josh's claim is that since the source – https://www.prideofdetroit.com/2012/1/16/2712497/matthew-stafford-pfw-pfwa-awards – has chosen a headline style that upcases every word in their headlines, then the Wikipedia article should upcase every word in the title for that source (and use ordinary title case if the source uses title case, or sentence case if the source uses sentence case, etc.). @Dicklyon made the corrections you suggest, and Josh reverted them, saying that having a mismatched capitalization scheme is consistent, because they're consistent with the various sources. That dispute is why we're here.
    NB that the question at hand isn't whether using leading case for every single citation in an article would be an abomination. It's whether "consistent" means that whatever case scheme you choose has to be used in all of them, or if visually mismatched capitalization, if consistently taken from the individual sources, is consistent in its own way. WhatamIdoing (talk) 22:07, 1 April 2025 (UTC)[reply]
    @Boghog: It was my correction of that citation title to title case as you suggest that got reverted and started this discussion. To me, all those capitalized little pronouns just look so out of place on Wikipedia that I hard a hard time imagining that someone would fight for them, but here we are. Dicklyon (talk) 23:16, 1 April 2025 (UTC)[reply]
    And to me forcing our personal preferences is just straight up wrong. But I don't try to stand in the way of others applying a consistent style (which you did not do with your edit, changing it away from consistency). Hey man im josh (talk) 23:44, 1 April 2025 (UTC)[reply]
    I don't see anyone forcing anything. You're right that I didn't move that article's citation style to a consistent style; I only fixed what looked like a glaring outlier, as I was not aware that anyone thought it would be OK the way it was. You objected, so now we're trying to get a better idea how to interpret the idea of a consistent style. Dicklyon (talk) 02:14, 2 April 2025 (UTC)[reply]
    It is forcing a specific style, it's taking away the option to preserve the titles of works and articles when promoting content. Many of us believe it's important to preserve the title of the work's capitalization, instead of having people change it based on what they like. It's also creating a lot more work for those who are promoting content. Hey man im josh (talk) 15:52, 8 April 2025 (UTC)[reply]
  • Yes: Consistently using the capitalization used by sources (aside from an all capitalized word) is clearly appropriate. If we decide that it's not, then it sounds like our citation tools need to be changed to reflect this, since that's what they do. Hey man im josh (talk) 17:32, 1 April 2025 (UTC)[reply]
    Realistically, this discussion is about whether only title and sentence case are acceptable for reference titles. We explicitly do not have a defined allowable citation style. This will create insane amounts of busy work that does nothing to improve the site, will result in countless additional fights over whether specific terms should be capitalized, restricts editors' freedom, and will only do more to harm the integration of new editors. For what? Because people like certain things and don't like the style others choose to apply consistently? There's plenty of styles I don't like which I recognize as being okay and acceptable. I stand on the side of logic, and what best allows Wikipedia to continue to grow and be improved upon. If we keep forcing ridiculous nitpicky rules like this it just adds more barriers and rules for people to get involved and contribute. Hey man im josh (talk) 23:42, 1 April 2025 (UTC)[reply]
    Also asking, what makes this a not consistent style, if the style is applied consistently? Keep in mind this is WP:NOTAVOTE, and I've personally not been convinced this does anything to improve the site. Truth be told, it makes me more likely to go back to gnoming instead of content. Hey man im josh (talk) 15:25, 4 April 2025 (UTC)[reply]
    What makes a quasi-random collection of styles imported willy-nilly from sources with divergent styles not be consistent is: It doesn't look consistent to the reader of the Wikipedia article.
    Compare "My clothes match because they are all the same color" vs "My clothes match because they were all bought on the same day". There is an underlying logic to the second one, but that logic is not visible to someone who is looking at a person wearing a pink shirt, a blue jacket, brown trousers, a black belt and white shoes. Someone looking at a person dressed that way would think "Wow, he's wearing mismatched clothes today. I wonder if he's color blind". Someone looking at such a person would not think "I'm sure that's totally consistent and everything matches according to some perfectly logical system that just isn't apparent to me". WhatamIdoing (talk) 17:48, 5 April 2025 (UTC)[reply]
    It doesn't matter what looks consistent, it matters what is consistent. There are plenty of styles that I don't personally like the looks of, but I recognize are applied consistently. I've learned about a lot of different styles while doing source reviews at content promotion avenues.
    As for your example, someone's personal style, which is subjective, is your argument here? There are so many things that people would say are a consistent look but look awful. For instance, head to toe camo, I don't think that looks good, but a lot of people may, and it doesn't mean it's not consistent. Additionally, what you perceive as matching colours may not be perceived as such by others in the world, as I've learned from some of the people in my life who have told me things don't match. Hey man im josh (talk) 15:50, 8 April 2025 (UTC)[reply]
    It's not about whether it "looks awful"; it's about whether it matches. You can have mismatched capitalization, but you can't call it matching. You can wear mismatched color combinations, but you can't call it matching. This is a matter of "you are entitled to your own opinions, but not to your own facts". The fact is that using mismatched capitalization schemes for the different sources listed in the ==References== section is not "consistent" because it's mismatched. It might have many other virtues, but using a visibly consistent style is not one of them. WhatamIdoing (talk) 02:31, 15 April 2025 (UTC)[reply]
    I can and do call it matching. What one perceives as matching does not have to fit what others perceive as such. I also absolute consider it consistent to respect and use the same capitalization used by the title of the work being cited, but I also respect your right to disagree. Hey man im josh (talk) 11:46, 15 April 2025 (UTC)[reply]
  • No. No printed style manual I've ever seen recommends importing style decisions of a cited source into an article one is writing, on a source-by-source basis. One always chooses a citation stye for one's article and sticks to it. It is only within direct quotes where one defers, to some extent, to the style of the source. Jc3s5h (talk) 17:35, 1 April 2025 (UTC)[reply]
  • I think the section title should be changed to "RFC on whether using capitalizations from sources is a consistent reference style". It's more direct and straight forward. The current title of this section implies this might be related to article capitalizations instead of reference capitalizations. Hey man im josh (talk) 17:39, 1 April 2025 (UTC)[reply]
    I don't want this confused with Wikipedia:Naming conventions (capitalization), about which there is a completely unrelated discussion open. But that's twelve words long, which is a bit much for a section heading. We're already at eight words, which is already on the long side of normal. WhatamIdoing (talk) 22:09, 1 April 2025 (UTC)[reply]
  • Yes This is common practice, so at least it needs to be an acceptable option. As others have pointed out this is how citation tools import titles, very few editors are likely to care enough to change the titles in the articles they are creating. All that's not to say it should be encouraged or that something like the FA process can't require a more formal style. -- LCU ActivelyDisinterested «@» °∆t° 18:07, 1 April 2025 (UTC)[reply]
  • Yes No with the following clarification: The available options should be limited to "Sentence case" or "Title Case." Capitalizing every word should be discouraged. Boghog (talk) 18:38, 1 April 2025 (UTC)[reply]
    The options should not be limited to sentence case or title case. This isn't what respected published style guides do. As an example, IEEE Reference Style uses title case for book titles and names of journals, but sentence case for journal articles and chapters of books. Unfortunately, editors of Wikipedia articles almost never record what style is being used, so style must be deduced from existing citations. Jc3s5h (talk) 19:44, 1 April 2025 (UTC)[reply]
    You're right that different respected style guides, like IEEE, apply both sentence case and title case depending on context. However, I think that you misunderstood my original point. My suggestion isn't to require one style across all uses, but rather to clarify that the available options should be limited to sentence case or title case, not an arbitrary mixture that includes capitalizing every single word. This kind of inconsistent and nonstandard capitalization should be discouraged, as it doesn't follow any major style guideline. It is entirely reasonable to have both sentence case and title case within an article, just as IEEE does across different reference types. But each instance should conform to one of these recognized styles—not a third, ad hoc style. Boghog (talk) 20:35, 1 April 2025 (UTC)[reply]
    Agree. Jc3s5h (talk) 20:52, 1 April 2025 (UTC)[reply]
    Agreed: No, + options should probably be limited to title case or sentence case.
    An editor taking the time to fix a jarring source title (e.g., any of: I Think This Guy Is Player Of The Year, I THINK THIS GUY IS PLAYER OF THE YEAR, i think this guy is player of the year) ought be thanked, not reverted!
    Himaldrmann (talk) 15:43, 16 April 2025 (UTC)[reply]
  • <YesNo(see below) if you feel that some form of consistency is required. I am not happy about imposing any such requirements on reference titles rather than just getting the complete information in there. I come from a field where references are unhelpfully abbreviated to Aller H. D. and Reynolds S. P. 1985 ApJL 293 L73. This RFC as worded seems to imply that the alternative will be to require changing book titles to War and peace and Little women to match journal titles in sentence case. Please be more specific. — Preceding unsigned comment added by StarryGrandma (talk • contribs) 18:58, 1 April 2025 (UTC)[reply]
    @StarryGrandma, the question is whether a Wikipedia article is allowed to combine multiple different capitalization styles. It's not whether to have "War and peace"; it's whether you can have both "War and peace" and "Little Women" in the same Wikipedia article.
    The three examples I gave in my comment above are all taken from the same Wikipedia article. One editor tried to "fix" one of them. Another editor wants those three examples left untouched, because they're already perfect as they stand. Which approach do you think is appropriate? WhatamIdoing (talk) 22:14, 1 April 2025 (UTC)[reply]
    It's not combining capitalization styles. The style is preserving the proper title used by the source. Hey man im josh (talk) 23:12, 1 April 2025 (UTC)[reply]
    It is combining capitalization styles, in the sense that the articles ends up containing multiple capitalization styles in it: leading caps for the one ref's title, title case for the next, and so forth. All of these styles are combined ("intermixed", to give the definition from Merriam-Webster) in the Wikipedia article.
    The opposite of combining capitalization styles is requiring that only one (1) capitalization style be visible to readers of the article: the Wikipedia editors choose title case or sentence case or leading caps or (*shudder*) even all caps, but every news article cited in the Wikipedia article gets the same approach to capitalization. WhatamIdoing (talk) 00:46, 2 April 2025 (UTC)[reply]
    @WhatamIdoing, I believe this page is a guideline. By "allowed" are we talking about an RFC on policy. However I sympathize with the problems caused when some editors want it some way and some another. And I will grant that book titles are already covered by the section of the MOS, Wikipedia:Manual of Style/Titles of works#Capital letters, stipulating that "major works" in English use title case and so won't be affected by choices for journal articles, newspaper articles, or chapter titles. And on further reading of that section I see it seems to cover the issues here.
    I would rather see titles as published, because it simplifies creating references. However the same section says: WP:Citing sources § Citation style permits the use of other citation styles within Wikipedia, and some of these expect sentence case for certain titles (usually article and chapter titles). Title case should not be imposed on such titles under such a citation style consistently used in an article. I interpret this to mean that the guideline is saying editors at each article can decide whether the article's citation style uses sentence case or title case for "minor works" like journal article, chapter titles, etc. And probably means the issue is subject to WP:CITEVAR, follow the first major contributor. The section also contains the specifications for Wikipedia's own version of title case to be used in converting a sentence case title to title case. We do have a house style for this and are not dependent on external style guides.
    As to leading case, the section says Other styles exist with regard to prepositions, including three- or even two-letter rules in news and entertainment journalism, and many academic publishers call for capitalization of no prepositions at all. These styles are not used on Wikipedia, including for titles of pop-culture or academic works I interpret that as emphasizing that the choice is between Wikipeida's title case or sentence case, not title as published. So capitalizing all words in a title is against the guideline.
    So I guess the answer to the question at the top of the RFC is No, the current guidelines say this is not acceptable. Sadly. Though I think we can avoid having infobox-type arguments over, how to format reference titles. StarryGrandma (talk) 01:12, 2 April 2025 (UTC)[reply]
    Do you think it would be desirable for WP:FAs to have the title of one newspaper article written in sentence case, and the title of the next newspaper article written in Title Case?
    I'm having trouble understanding why picking one capitalization style for the whole Wikipedia article is something we should view with sadness. WhatamIdoing (talk) 01:35, 2 April 2025 (UTC)[reply]
    I come from a field that capitalizes article titles. I would hate to have to reduce them to sentence case when adding them to an existing article. This RFC isn't about featured articles, its about guidelines for citing sources anywhere. References should be easy to add and the current tools are very helpful. But I have already changed my response to the RFC to No. The guidelines I quoted are pretty clear. An article can use sentence case for minor titles if the citation style is consistently used in the article. Using "should", not "must" but FAs follow "should". And titles with all words capitalized are not used in Wikipedia as a definite statement - "are not used". StarryGrandma (talk) 02:32, 2 April 2025 (UTC)[reply]
    I come from a field that capitalizes article titles. I would hate to have to reduce them to sentence case when adding them to an existing article. Why? The publisher is simply applying a style guide to their titles. I don't see a need to import theirs into ours in a piecemeal way. — HTGS (talk) 20:44, 2 April 2025 (UTC)[reply]
    @StarryGrandma: You asked about "allowed", a loaded word for sure. This RFC is about "acceptable", probably also not the best choice of word for a guidline. The question is really about whether the "style from sources" style is consistent with the guideline or not (and maybe about whether we should clarify the guideline if we come to a consensus on that question). Nobody is going to be chastised or punished for not following guidelines, but for gnomes like me that like to move things in directions supported by guidelines, it would be good know a consensus interpretation, to avoid arguments there and there. Dicklyon (talk) 02:10, 2 April 2025 (UTC)[reply]
    @Dicklyon, the "style from sources" is not consistent with the guidelines at Wikipedia:Manual of Style/Titles of works#Capital letters (MOS:TITLECAPS). The information on titles is scattered quite a bit, and I did not find it until I had initially said Yes above (now No). I think this page should refer editors to MOS:TITLECAPS for more information on titles as well as MOS:ALLCAPS. Or maybe one section somewhere should say it all. StarryGrandma (talk) 03:02, 2 April 2025 (UTC)[reply]
    Good work—it seems like this might already be covered by the guidelines, then?
    Himaldrmann (talk) 15:47, 16 April 2025 (UTC)[reply]
  • Yes. It is consistent to defer to the capitalisation as provided for in the thing being cited. Whether that is what should be done is a related but different issue; inasmuch as we're keeping the current thing that says consistent is acceptable that feels clear to me. Ifly6 (talk) 19:59, 1 April 2025 (UTC)[reply]
    I disagree. If we review several respected style guides, we see they require consistency throughout the work. See for example Chicago Manual of Style ¶ 2.55, 18th ed. But they also specify rules about capitalization of source titles that have nothing to do with how the source wrote the title. So your definition of consistent is just wrong. Jc3s5h (talk) 20:58, 1 April 2025 (UTC)[reply]
    That's the funny thing about personal definitions, to me yours is wrong. Preserving the capitalization used by the source is not actively harmful in any way, and to me is actually an active improvement over modifying all of the titles to fit whatever one's personal preference is. We also don't follow any one specific style guideline, so citing what one does isn't particularly relevant. Hey man im josh (talk) 23:16, 1 April 2025 (UTC)[reply]
    In a way it is consistent, in that it is a mechanistic rule that cam be followed by an algorithmic process, but is it reasonably practicable? The only reliable way to be sure what the source uses is to check the source. In a significant proportion of cases it is not reasonably possible for the average editor to check the source. This impractcability makes this option unsuitable for Wikipedia, without even considering other stylistic and aesthetic aspects. · · · Peter Southwood (talk): 06:41, 15 April 2025 (UTC)[reply]
  • No (where by not acceptable we mean not aligned with guidelines, therefore up for improvement). The guideline page whose talk page hosts this RFC has in the lead "Each article should use one citation method or style throughout". The section WP:CITESTYLE further details what some consistent styles are, by referencing style guides. It says "nearly any consistent style may be used", but gives no hint that copying an inconsistent bunch of styles could be considered a consistent style. Furthermore, it is pretty much impossible for an editor to tell from looking at an article what style is being used in an article if it looks like a jumble of styles. In general, when there are strange outliers from the usual standards of reference title capitalization (sentence case and title case), I tend to fix those, in the direction of being consistent with most others in an article. This never makes the sources hard to identify, just as using any of the styles recommended in style guides does not. Dicklyon (talk) 23:12, 1 April 2025 (UTC)[reply]
    The guidelines simply state to be consistent, they do not state we must edit the reference titles to match what Wikipedia uses for capitalization.
As one example, the NFL and all 32 teams consistently capitalize "NFL Draft" and each event, treating the names of the events as proper names. Are we to then apply the style that we personally see fit? What happens when one person doesn't like it? Does it then become we MUST adhere to whatever Wikipedia uses for capitalization? It's forcing specific citation styles on people who are consistent in what they do, and for what? To create busy work that actively slows down improvement of the site for no gain?
The goal appears to be to force Wikipedians to use either sentence or title case specifically, when there are countless styles which are consistent and differ drastically. Hey man im josh (talk) 23:17, 1 April 2025 (UTC)[reply]
Countless styles of capitalization? So far, we've only found five:
  1. Title case: On War and Peace: A Few Thoughts
  2. Sentence case: On war and peace: A few thoughts
  3. Leading caps: On War And Peace: A Few Thoughts
  4. All caps: ON WAR AND PEACE: A FEW THOUGHTS
  5. Library style: On war and peace : a few thoughts
WhatamIdoing (talk) 01:30, 2 April 2025 (UTC)[reply]
I'm not sure I'd agree that sentence case means use sentence case for subtitles, too, but maybe it does; I hadn't heard of Library style, but that does look a lot like what I see from Library of Congress (minimal capitalization). I expect there's no precedent in Wikipedia for using either all caps or leading caps as a consistent ref style in Wikipedia; it would be quite contrary to our general practice of avoiding unnecessary capitalization. I doubt that anyone would complain if we said not to do leading caps generally. That's orthogonal to the present question though. Dicklyon (talk) 02:20, 2 April 2025 (UTC)[reply]
The listed styles are visibly consistent. A reader can inspect a small sample and work out the pattern. A "style" that is not visibly consistent leaves the reader at a loss as to how to add another item consistent with the existing material. The likely consequence is that they just make a wild-assed guess, or use whatever capitalisation they like best, and the probability of achieving consistency by WAG is low, so there is a drift to inconsistency. This is about as good or bad as "do whatever" Cheers, · · · Peter Southwood (talk): 08:29, 22 April 2025 (UTC)[reply]
Wikipedia does have a house style on capitalization of titles including those used in citations at MOS:TITLECAPS, For subtitles see MOS:TITLECAPS#Subtitle. StarryGrandma (talk) 03:18, 2 April 2025 (UTC)[reply]
This comment does not correctly summarize MOS:TITLECAPS. The phrase there is "In titles (including subtitles, if any) of English-language works (books, poems, songs, etc.), every word is capitalized except for the definite and indefinite articles, the short coordinating conjunctions, and any short prepositions. This is known as title case." But if you read the whole section yo see this means mentioning a title in a Wikipedia article, outside of the reference section. It also doesn't apply to titles of journal articles, although it does apply to the title of the journal. it goes on to say

WP:Citing sources § Citation style permits the use of other citation styles within Wikipedia, and some of these expect sentence case for certain titles (usually article and chapter titles). Title case should not be imposed on such titles under such a citation style consistently used in an article.

Jc3s5h (talk) 14:40, 2 April 2025 (UTC)[reply]
  • Yes (while fixing all-caps and isolated glaring outliers should be allowed and encouraged): Copying from the source is simple to do and it preserves the integrity of the source, and it is what happens from automatic tools. There have been several times when some question arises (usually in an RM discussion) about about someone's "Favorite Theory" or "Infamous Incident", leading me to take a look at the citations for evidence of what is in them, and I notice that many of them refer to the "Infamous Incident" in their headlines, but when I actually open a few of the links, I see that the citations are not accurately representing what the sources have in them. With a little sleuthing, I sometimes find that just a week or two (or 5 minutes) before suggesting to rename the page, someone has edited the page to change the capitalization of that one phrase in many cited headlines and quotes and the article body. I don't like it when I see they have altered the cited titles to support their agenda. I want to be able to see whether a source referred to the topic as Il bidone or Il Bidone or I clowns, or as the EDGE Group or the Edge Group or EDGE Foundation. I also tend to find that if I get an itch to clean up some citations, I find no lack of other, more useful things to do – like add and correct author names, correct the usage of the |publisher= parameter, add |url-access= indications to help readers avoid wasting their time, adding {{dead link}} tags, adding links to author articles, adding links to articles about the publications, merging duplicate citations to the same source, changing POLITICO and TIME to Politico and Time, adding publication dates, making the date format more consistent, and tagging or removing citations to low-quality promotional or biased sources. All of those things help the reader, while I've never noticed anyone being especially worried about establishing a consistent styling of the capitalization in the cited headlines. —⁠ ⁠BarrelProof (talk) 03:38, 2 April 2025 (UTC)[reply]
  • Yes - Accurately reflecting the casing of sources has been the de facto reference formatting style since Wikipedia began, which is why all of the citation tools that have accumulated over two decades follow it. --PresN 03:59, 2 April 2025 (UTC)[reply]
    That's completely and utterly wrong. Going into an article that has a consistent style (e.g. title case for major works like journals and book titles and sentence case for minor, like articles and chapters, one of the more common styles) and imposing instead the exact case-spellings used in the original sources, all written to completely different style guides or not at all (it's common enough to encounter things like "Across A Gulf Of Time" due to no-smarts content management systems that auto-capitalize after after space character) would be against WP:CITESTYLE by changing from a consistent style to random chaos.

    Various half-baked citation tools (many of which have not been updated in years and nearly all of which introduce at least one kind of citation template formatting error that we have to clean up latter), generally do nothing with case because their coders haven't figured out how to do it. It's very simple to create code to copy string X and reuse it verbatim, but quite challenging to create one that transforms particular strings, depending on their template-parameter destination, through a carefully crafted title-case rule (e.g. one following our MOS:5LETTER system and not some off-site variation (of which there are many). But it's a moot point anyway: The tail does not wag the dog – citation tools are to be written to conform to our citation needs (and abandoned if they will not be repaired to do so); we do not shape our guidelines or our practices to suit limitations of third-party tools.  — SMcCandlish ☏ ¢ 😼  04:42, 2 April 2025 (UTC)[reply]

    Across A Gulf of Time or Across A Gulf Of Time? (Not that it's important, heh; just figured you may have meant to give the latter as an example—unless I've misunderstood!)
    Himaldrmann (talk) 15:52, 16 April 2025 (UTC)[reply]
    Yes, fixed. But odds are you can find examples capitalized like "Across A Gulf of Time" due to poorly coded scripts, anyway.  — SMcCandlish ☏ ¢ 😼  19:12, 20 April 2025 (UTC)[reply]
    I disagree that all of the citation tools that have accumulated over two decades follow it: correctly applying sentence casing algorithmically to an article title is effectively impossible. BibTeX attempts this, but any long-term user will attest that it often requires quite a bit of escaping capitals ("DNA" becomes "dna" sometimes without escaping). Zotero, probably the most-used GUI reference management software, explicitly does not sentence-case its entries automatically, and its reference document on this topic explains that it's functionally impossible to translate from title to sentence case. Wikipedia's much-less-powerful citation tools could not be expected to do this and it should be on editors to ensure consistency when an article approaches featured content status. Dan Leonard (talk • contribs) 19:09, 24 April 2025 (UTC)[reply]
  • Absolutely not. This idea is completely counter to the entire purpose of WP:CITESTYLE and its WP:CITEVAR. This is the third time we've been over this already in the space of a few weeks.

    WP:STYLEVAR requires a consistent style of citations in output for readers. It has absolutely nothing to do with a particular person's WP:NOTGETTINGIT and WP:1AM weird notion of "consistent way of entering citations, by just copy-pasting them as found". It is entirely fine for someone to do that (no editor has to comply with any style guideline of any kind to add content and citations). What is not permissible is WP:STONEWALL editwarring against other editors normalizing such a person's chaotic input to conform to our guidelines. These guidelines require consistent presentation of citations to our readers, with no regard for whether editors are "consistent" in how they (individually or collectively) go about producing that result; there is of course no way for WP to magically determine from a distance whether someone is being consistent in their data gathering and entry practices, and no reason to care.

    The entire notion that "consistent/consistency" in this guideline could have anything to do with how an editor likes to handle text on their end is nonsensical, and aside from being an obvious WP:WIKILAWYER / WP:GAMING tactic, is a classic fallacy of equivocation: trying to change the clear meaning of a term on-the-fly to a contradictory one to try to get a cogently indefensible result that they desire for subjective reasons (mostly often convenience AKA laziness, but occasionally as with PresN's strange notions above some idea of "obeying" external publisher's style preferences, which is the exact opposite of why we have a style guide at all).  — SMcCandlish ☏ ¢ 😼  04:42, 2 April 2025 (UTC)[reply]

  • No – It must be permissible to correct a cited title like … Voted Comeback Player Of The Year By PFW/PFWA to … Voted Comeback Player of the Year by PFW/PFWA – preferrably in the context of a more substantial edit. -- Michael Bednarek (talk) 04:47, 2 April 2025 (UTC)[reply]
    Who determines what the "corrected" version of the title is though? Must we use what Wikipedia uses as the capitalization for articles, or cam we use what sources treat as a proper name? Hey man im josh (talk) 14:23, 2 April 2025 (UTC)[reply]
    It's determined by an editor who is cleaning up the article. Ideally the cleanup-editor owns at least one printed style guide. The procedure is to look through the citations to see if it's apparent which style is being followed. If no pattern is evident, the cleanup editor can do what they want as long as it's consistent. In case of disagreement it's discussed on the article talk page. Jc3s5h (talk) 14:46, 2 April 2025 (UTC)[reply]
    The problem with that idea is that Wikipedia's guidelines for capitalization very often do not match other guidelines. This is one step towards "Every capitalization used by titles must be used in references as well". Hey man im josh (talk) 19:33, 2 April 2025 (UTC)[reply]
    To be clear, I meant the first step would be to look through the talk page and see if there is a discussion. If not, look at the early versions in the edit history; if most of the book titles are title case and most of the journal and newspaper article titles are sentence case, then that's the style. If the styles are wildly inconsistent until a cleanup 8 months ago, go with the style in the 8-month-old cleanup. If the style has always been wildly inconsistent, right up to the current version, the cleanup editor can choose any consistent style. Jc3s5h (talk) 20:55, 2 April 2025 (UTC)[reply]
  • No – The only purpose of keeping capitalisation the same as the source is to help web searches when the source disappears. Luckily, most web search engines totally ignore capitalisation. And like all other aspects of references, we are not bound by the source's choice of ordering, date format, etc. Therefore capitalisation can be treated the same as font choice - ignore it totally. I have a strong preference to sentence case but can live with capitalising every major word (typically skipping "the", "and", etc). All-caps is the same as SHOUTING - which is the source's intent to grab your attention but I don't want references to MOLEST me. But I'm not too fussed if some of the references use sentence case and others capitalise every major word - as said above, that's just busy work and too onerous to demand on volunteer editors. And I doubt if the majority of our readers even notice.  Stepho  talk  05:46, 2 April 2025 (UTC)[reply]
    I expect that some of the automated citation-creation tools will grab a title that does not reflect the real title that's found when reading the work on paper or in a PDF. For example, I used the Cite tool in the Visual Editor and entered the ISBN for the The Chicago Manual of Style EIGHTEENTH EDITION (that's how it appears on the title page, the ISBN is 978-0-226-81797-2). The Cite tool rendered the title as The Chicago manual of style (Eighteenth edition ed.) Jc3s5h Jc3s5h (talk) 16:53, 2 April 2025 (UTC)[reply]
    Many web pages have sentence case in the HTML source but use CSS rules to display it as uppercase. So it displays as uppercase but copy/paste and scrapping tools see sentence case. This is also common for author files for web news articles.  Stepho  talk  23:46, 2 April 2025 (UTC)[reply]
  • No, per various above, including Whatamidoing and Jc3s5h. Mike Christie (talk - contribs - library) 18:15, 2 April 2025 (UTC)[reply]
  • No. The title of any work as published is conforming to some style guide. It is not our job to import a dozen different style guides into our own. In saying that, it is quite "acceptable" to import citations quickly, via copying and pasting or other tools, and as BarrelProof has said, there are a multitude of other things to fix before capitalisation of citations. BUT, where someone has chosen to fix titles, this should be in one direction (towards a unified citation style) and not in a dozen different directions (towards every publication's unique style guide). We are our own publication, not merely an online depository, as many still seem to think. Following that philosophy, we should and do have our own style guide. — HTGS (talk) 20:56, 2 April 2025 (UTC)[reply]
  • No. I don't care much what capitalization rule is used, but adopting this as a rule would make it very tedious to verify and impose consistency. An automatically generated citation is fine as a starting point, but often needs improvement in many ways, not limited to capitalization. (I'm also puzzled by the arguments being put forward by proponents, which seem contradictory - if "correcting" source capitalization is an integrity problem, why is it not an integrity problem to change all-caps titles?) Nikkimaria (talk) 01:56, 3 April 2025 (UTC)[reply]
  • No CITEVAR, unfortunately, results in lower-quality citations than a proper style guide, but a key positive function of the guideline is resolving disputes. To cut short a debate about formatting any particular citation, we can say "Make it consistent." The borrowed capitalization interpretation subverts that benefit. It introduces several potential ways to string along or exacerbate a dispute. What if only one or even zero editors can access the source? What if two editors access the source in two different ways, and find two different styles used? What if the method to access the source does not make it clear what the original capitalization was? It's okay to ignore CITEVAR when the citation can be made more functional by maintaining consistency with the source rather than the other citations in an article. For example, having ISBNs formatted with different numbers of digits and hyphens could help a reader determine if they have the same copy of the book by seeing the same ISBN. You can argue that better aligns with WP:V. That doesn't apply to capitalization though. As another editor pointed out above, search engines ignore capitalization, so it doesn't help locate the source either. Rjjiii (talk) 03:03, 3 April 2025 (UTC)[reply]
  • No, per WhatamIdoing, Dicklyon, SMcCandlish, Nikkimaria, and others above. It would also be annoying and potentially discouraging if someone fixes the capitalization of cited works (e.g. by correcting overcapitalizations in title style) and then gets reverted despite doing what was arguably an improvement, if a minor one. Gawaon (talk) 07:32, 3 April 2025 (UTC)[reply]
    I find it discouraging to go against the actual title used by the source, and to actually have to fight about what should and shouldn't be capitalized. What I consider a proper name others may not, and I KNOW that fight will happen. Hey man im josh (talk) 15:35, 4 April 2025 (UTC)[reply]
    Another issue that hasn't been considered so far but that should be considered before this RfC closes it that a Yes outcome would be absolutely unworkable in practice since nobody will know any more whether citations use a consistent style. Consider an article with 50 references, some of them printed books and articles, the rest web articles. Some use Sentence case, some Title Case, and some All Words Are Capitalized Even Articles And Prepositions Style. Is that a consistent reference formatting style? Nobody can know without having clicked on all the web references and having manually verified the case form of the title, as well as having retrieved all the cited books from libraries and verified their title page or table of contents. Nobody will do that, of course. So nobody would know any more what's consistent and what isn't. Gawaon (talk) 15:05, 10 April 2025 (UTC)[reply]
    How on earth would a yes outcome be unworkable? That simply means not blindly changing capitalization, which is super easy and workable. Hey man im josh (talk) 17:57, 14 April 2025 (UTC)[reply]
    It could perhaps be made workable if articles could be tagged with a "Citation case copied from sources" tag, to distinguish from articles that use a more conventional capitalization style. But as it stands, there's no way to know without looking at most of the sources whether that's the intended style, and no way to know it's consistent with that intent without looking at all the sources. Dicklyon (talk) 18:15, 14 April 2025 (UTC)[reply]
    (edit conflict) I was about to say the same thing: Corresponding templates could be created such as {{Use capitalisation from sources in citations}}, {{Use title case in source citations}} and {{Use sentence case in source citations}}, similar to other templates we already use, like {{Use dmy dates}} and {{Use Oxford spelling}}. —⁠ ⁠BarrelProof (talk) 18:24, 14 April 2025 (UTC)[reply]
    It's already workable, just don't needlessly change citation cases. Hey man im josh (talk) 18:59, 14 April 2025 (UTC)[reply]
    If you and I are working to develop an article, and you add citations with capitalization matching the sources and I add citations in title case, that is inconsistent whether this closes as Yes or No, and one or the other would have to be changed either way. This RfC is not "let's decide not to care about capitalization at all"; it's only "which of those would have to change?".
    I fully understand that copying and pasting is easy from a just-get-a-reference-in perspective. But as a frequent source reviewer at FAC, I'd have to agree that from that perspective a Yes outcome is unworkable, or at least massively more tedious. And that's before we get into any additional complicating factors, for example different versions of a source having different capitalizations (eg accessing via a database vs directly from a publisher site). Nikkimaria (talk) 01:57, 15 April 2025 (UTC)[reply]
    A book's cover will be capitalized differently from its title page. A wire services article will appear with different capitalization in different newspapers. The HTML title property might use different capitalization than the displayed title. Which one is the One True™ Capitalization for that source? WhatamIdoing (talk) 02:40, 15 April 2025 (UTC)[reply]
    We should try to avoid tedious requirements where there is no clear benefit to the reader or the majority of editors. · · · Peter Southwood (talk): 07:04, 15 April 2025 (UTC)[reply]
    In addition to what Nikkimaria and WhatamIdoing said: The problem with a "Use capitalisation from sources in citations" template is that it still leaves editors clueless about which existing citations already comply with this style and which doesn't. Everyone who has edited more one very few articles will know that "Use DMY dates" doesn't mean that every existing date in the article already does so. It means that any existing date that deviates from this pattern should be adjusted to adhere to it, and very often that is indeed necessary, since less than 100% of all editors will read that note and follow what is says. Likewise "Use capitalisation from sources in citations" would only express an ideal, but which of the existing citations actually follow it is impossible to know without following up every single citation, which I have pointed out is entirely impractical, if not impossible in practice. That's the huge difference to "Use DMY/MDY dates" and hypothetical "Use title/sentence case in source citations" templates which can be easily verified by editors by just looking through the content of the page. And going beyond that is frankly not something we can and should expect editors to do. Gawaon (talk) 07:17, 16 April 2025 (UTC)[reply]
    The problem with needing manual checking of sources is broader than questions about capitalization. The primary way we know whether any information in citations is correct (and whether a provided URL is broken or not) is for people to go look at the sources and see what they have in them. Anyone who has bothered to do that kind of gnoming will know that there's no shortage of things needing checking and correction or addition of missing information in Wikipedia article citations. Yet we don't consider the practice of citing sources as generally unworkable. Indeed, it's a core principle. And automated tools (e.g. Wikipedia:reFill) seem to copy the capitalisation from the sources by default anyway, AFAIK. —⁠ ⁠BarrelProof (talk) 15:43, 16 April 2025 (UTC)[reply]
    There's a huge difference between editors collectively checking the sources of an article, and one individual editor being able to check all the sources of an article. Using "Date of Easter as an example, I was able to check some dates which the article implied came from Astronomical Algorithms 2nd ed., because I own that book. (It turned out the dates in question weren't in the book.) But if I wanted to check the capitalization of the title of Handbuch der mathematischen und technischen Chronologie I wouldn't be able to, because I don't own that, and I doubt any library near me has it. Since article cleanup is usually done by a single editor, we should use styles that can be checked by a single editor who doesn't have access to many of the sources. Jc3s5h (talk) 16:10, 16 April 2025 (UTC)[reply]
    This is true, but I think the artument—that adding (in effect) a requirement to check the source (to determine if formatting is correct) will likely lead to more incorrect formatting—might be sound; a guideline that requires only looking at the article itself, on the other hand, enables lots of lazy people with OCD (such as myself) to ensure that at least the formatting is correct.
    Of course, adopting a guideline that says "sources don't have to actually support what they have been adduced to support" would also make things easier, so "easier" isn't a bulletproof (or BarrelProof! heh! heh...) argument...
    Himaldrmann (talk) 16:14, 16 April 2025 (UTC)[reply]
    I think Gawaon is correct in two ways:
    • You can't know whether mismatched capitalization is intentional merely by reading the article. This could be mitigated by adding an invisible template.
    • Even if you know that mismatched capitalization is intentional (e.g., you saw the hidden template in the wikitext), you can't know whether any specific ref is "correctly" capitalized without checking each source individually. This cannot be mitigated by anything we do on wiki. Making all the titles follow a standard scheme is easy; some of us can do it practically in our sleep, and if you want proper Title Case, there's a script to automate it. But if you want to use mismatched styles, then there is no way to find or fix any errors without manually checking each source individually.
    WhatamIdoing (talk) 02:36, 15 April 2025 (UTC)[reply]
  • No, per Nikkimaria, WhatamIdoing, SMcCandlish, etc. Consistency is one of the key factors for the output for readers, rather than a jumbled mess of different styles. - SchroCat (talk) 03:43, 5 April 2025 (UTC)[reply]
  • Yes. This never should have had a standard at all per WP:CREEP. There is just no value add; the whole point of CITEVAR is to let major editors use whatever consistent style they prefer, and it's fine. It's not worth edit warring over, it's not worth telling them they're "wrong". Wikipedia is not a monograph collection where all the chapters use the same formatting style; it's closer to a library where it's not surprising if one book uses one style, and another a second style. That's fine. Standardizing all books in a library would be madness and counterproductive - if an editor wants to use a style (whether it be title case, original case, sentence case), let them. As far as Gawaon's comment, the whole point of this proposal is to deem original casing an accepted style. So messing with it would not be a "fix" at all. SnowFire (talk) 07:11, 5 April 2025 (UTC)[reply]
    • Side comment: Looking up, there is a lot of ...questionable... claims here, but to weigh in on one claim in particular: the whole accusation that the pro-honoring-the-sources side is really just about auto-formatted citation tools is completely irrelevant and should be discounted by the closer. It is of course correct that the tools should serve the policy, not the other way around. But A) formatting a title is a solved problem, don't trust a tool that can't handle this anyway, and B) Even if it wasn't, it is a principled and reasonable style for an editor to prefer to honor the original casing, even if this was somehow more work for the editor. I'm not thinking website links here, I'm thinking more like old-fashioned books from the 1800s which used capitalization liberally. If someone wants to do this - let them. Just as if someone wants to format everything in sentence case - also let them do that. It doesn't matter. Most editors will be happy to seek advice from the guidelines anyway, it's fine, but we trust them to make the call at the end of the day. That is the Wikipedia way. SnowFire (talk) 07:33, 5 April 2025 (UTC)[reply]
      Freedom to preserve the capitalizations used by sources and freedom to utilize sentence or title case, it's how it should be, and it's absolutely a consistent style. Hey man im josh (talk) 13:20, 7 April 2025 (UTC)[reply]
      I don’t think “Freedom” is a useful argument here. We don’t encourage freedom-to-write-whatever-you-want on Wikipedia, nor freedom-to-cite-whatever-you-want, and likewise, I see no benefit to being “free” from any cohesive style guide. — HTGS (talk) 21:45, 7 April 2025 (UTC)[reply]
      @HTGS: That's not a useful comparison. The argument is that some perceive the style of preserving the actual title used as being a consistent style. Being allowed to preserve the title is a freedom when it comes to writing and improving content. Hey man im josh (talk) 12:37, 8 April 2025 (UTC)[reply]
      @Hey man im josh And being allowed to change the title is a freedom when it comes to writing and improving content. My point is that “freedom” is not a useful lens here. — HTGS (talk) 05:10, 10 April 2025 (UTC)[reply]
  • The problem with this argument is that most articles have more than one author, and no chief editor coordinating style. Nobody is penalised for adding content or references that are inconsistent, but nobody should be stopped from editing to make them consistent within guidelines. · · · Peter Southwood (talk): 07:09, 15 April 2025 (UTC)[reply]
  • No. Book titles should consistently be in title case, article and chapter titles should consistently be in either title or sentence case. In both cases regardless of how they appear in their original. Gog the Mild (talk) 14:57, 5 April 2025 (UTC)[reply]
  • No YesWhy should we spend our time enforcing a policy that reduces (however slightly) the reader's ability to find sources? If It Is Written Like This, Then It Should Be Presented Like This. JuxtaposedJacob (talk) | :) | he/him | 20:22, 7 April 2025 (UTC)[reply]
Did you mean "yes"? —⁠ ⁠BarrelProof (talk) 20:33, 7 April 2025 (UTC)[reply]
Looks to me like they did. Pinging @JuxtaposedJacob for clarity. Hey man im josh (talk) 12:38, 8 April 2025 (UTC)[reply]
Yes, sorry for the error. Thanks for the note. JuxtaposedJacob (talk) | :) | he/him | 15:06, 8 April 2025 (UTC)[reply]
Preferred but not mandatory, and this shouldn't be forced on the editor adding the citations. Editors should be allowed to input citations in the way they are capitalized in the sources, and other editors should be allowed to change them to a preferred consistent style. This way, we don't add an unnecessary barrier to entry, but we still allow editors who want it to make the citations more consistent. Chaotic Enby (talk · contribs) 10:30, 8 April 2025 (UTC)[reply]
So, in the context of this RFC, I suppose you argue for No (since "other editors should be allowed to change them")? Gawaon (talk) 11:18, 8 April 2025 (UTC)[reply]
Mostly, but I don't want the result of the RfC to be interpreted as editors not being allowed to input the original formatting used by sources, which was brought up by multiple users on the "yes" side as a potential barrier to editing. Chaotic Enby (talk · contribs) 11:21, 8 April 2025 (UTC)[reply]
Consistency is always just an option, never a requirement, so I don't know how a "No" result of this RfC could be interpreted as forcing anyone to do anything. All it does is giving other editors the possibility of further improvements by making reference formatting more consistent. Gawaon (talk) 06:55, 9 April 2025 (UTC)[reply]
@Gawaon: Saying it's "never a requirement" is incorrect. Consistent reference styling is a requirement at WP:FAC and WP:FLC. Hey man im josh (talk) 16:29, 9 April 2025 (UTC)[reply]
True, but FAC and FLC are themselves optional activities, and so is reverting someone who voluntarily corrected the capitalization in an article. WhatamIdoing (talk) 02:45, 15 April 2025 (UTC)[reply]
"Corrected" is subjective, I believe it to have made the references worse. That's the fun thing about opinions and perspectives. Hey man im josh (talk) 12:11, 15 April 2025 (UTC)[reply]
No. It is by far not the most important thing to get right, but a mish-mash of capitalisation styles looks sloppy and unprofessional. Respectable journals and books don't do this, since style manuals recommend to apply the publication's own style to the formatting of reference lists (not just capitalisation, but italics, etc.). So if someone cares enough to correct this, I don't want someone else saying that it is not an improvement, because copying the original is an approved style. JMCHutchinson (talk) 12:06, 8 April 2025 (UTC)[reply]
  • Yes. edited to clarify: Any capitalization other than all-caps or all-lowercase should be acceptable. The last thing we need is to throw up more obstacles to getting the source cited at all in the first place. Personally, I give few to zero hoots about citation capitalization. I'm fine with describing a preferred style that editors are encouraged to apply and is a legit cleanup task; I could even live with it as a requirement for FAs. But adhering to a specific capitalization style should absolutely not be a requirement for a citation to be correct. Let's not add to the number of details an editor must know and understand to comply with basic expectations. Or nitpicky rules for crabby, territorial editors to use as bludgeons against one another. It's difficult enough onboarding people and getting good, cited contributions as it is. -- Avocado (talk) 13:57, 8 April 2025 (UTC)[reply]
    I would pretty much agree, which makes me realize something curious – rather than a simple "Yes/No" binary question, this discussion appears to really have three possible options: making casing consistency mandatory for citations, making it a "preferred" style but not a mandatory one, and not making it preferred at all. I've seen good arguments for all three, but people supporting the second option have !voted both "Yes" and "No" (with @Gawaon telling me above that he considered my similar opinion to be a "No" vote), and this does add to the complexity of a future close. Chaotic Enby (talk · contribs) 16:26, 8 April 2025 (UTC)[reply]
    The wording of the question sort of lends itself to this confusion. I'll clarify my response. -- Avocado (talk) 17:22, 8 April 2025 (UTC)[reply]
    I don't think anyone has voted or argued for making casing consistency mandatory for citations. As I stated above, consistency is always just an option, never a requirement, and inconsistencies give an opportunity for further improvement. Gawaon (talk) 07:00, 9 April 2025 (UTC)[reply]
    As mentioned above, saying it's "never a requirement" is incorrect. Consistent reference styling is a requirement at WP:FAC and WP:FLC. Only replying here as well in case anybody just gleams this comment, and I don't want it to be incorrectly assumed that consistency is never a requirement. Hey man im josh (talk) 16:31, 9 April 2025 (UTC)[reply]
    I think people are using "requirement" and "mandatory" in two different ways here. It's not a mandatory requirement in the sense that editors can make contributions that are non-compliant, and they should not be reverted. It is a mandatory requirement in the sense that inconsistent capitalization is non-compliant, not one of several compli