Wikipedia talk:Manual of Style/Layout

Adding a line/space between top templates and Infobox template or article beginning

I think with the added amount of hidden templates, article information notices, maintenance tags and other notices that precede the article, that a space/line break should be made standard separating all the normal and accessory notices from the Infobox, to better differentiate between what the reader/editor sees as the article and the numerous templates placed above the article beginning. I believe his helps in editing, especially in vector, and makes it easier to add other, less used templates such as Merge, Split, Copyedit, Cleanup, etc. While editing, this area can then be pretty much ingnored and you can get right into the article. In other words, this would put a line break between position #7 and #8 in the Wikipedia:Manual of Style/Layout#Order of article elements on the project page. I appreciate any comments or suggestions. Thanks, GenQuest ^"scribble" 02:01, 9 March 2023 (UTC)

I'm slightly concerned that we will get more unwanted blank lines if a template on either side of this newline doesn't generate any content. I don't believe there are any high use templates susceptible to this issue, but I know it's a risk from when I messed up with {{Short description|none}} generating thousands of excess newlines a couple years ago. If this occurs it would be very difficult for most editors to diagnose and would likely be reintroduced later by well meaning editors trying to follow the guideline. --Trialpears (talk) 02:16, 9 March 2023 (UTC)

I'm really talking about a break between the top-templates, and the Infobox/article beginning, such as:

{{Short description|American phlebotomist (1951–2020)}}
{{Use American English|date=March 2023}}
{{Use mdy dates|date=March 2023}}

{{Infobox person
| image = {Placeholder}.png
| caption = joe performing in 2011
etc...

GenQuest ^"scribble" 02:34, 9 March 2023 (UTC)

I sometimes insert linebreaks in this frontmatter stuff to improve source code readability. I haven't seen this affect layout. Some editors undo it anyway. I do not fight them. Not a big deal. Why do you think it is necessary to create a layout policy for this? ~Kvng (talk) 22:33, 21 March 2023 (UTC)

Because it makes it easier to edit the mark-up/source code in the header (hidden template) area with the inserted line break. (They don't affect the readability at all.) I add them also, but they are constantly removed or reverted. Since they don't affect what the reader sees, why not make it easier on us gnomes and article editors, and just leave the break? . GenQuest ^"scribble" 00:03, 22 March 2023 (UTC)

Blank lines above the infobox can cause an extra-tall gap to appear above the lead section text. This is because {{Short description}}, {{Use American English}} and {{Use mdy dates}} are themselves treated as a blank line. --Redrose64 🌹 (talk) 00:18, 22 March 2023 (UTC)

Redrose64 A single line break/separator has zero-effect on top-space or where the article begins on any of my devices. Try it out. GenQuest ^"scribble" 00:32, 22 March 2023 (UTC)

@GenQuest:I notice you've removed some line breaks between infobox and lead. Why not leave a break there to help editors find the lead? Dicklyon (talk) 06:45, 23 March 2023 (UTC)

It has been pointed out to me on my talk page that sometimes when I put a blank line between an infobox or such template and the lead, extra space appears in the rendered article, and that that's because the template source has a "noinclude" section at its end, with a newline before the noinclude tag. If those templates were fixed to not have that newline (as many templates are already), the problem goes away. So, is it OK if I fix a bunch of templates? I find 6900 college football templates that transclude Template:CFB Standings End and follow that by a noinclude; I haven't yet checked how many have a newline between; looks like most or all do. Example fixes: [1], [2]. Not pretty in the template source, but allows prettier article source without creating a visible problem in rendered articles. Dicklyon (talk) 09:48, 27 March 2023 (UTC)

Of those 6900 templates I mentioned, about 230 don't need to have a newline removed. So about 6570 to fix... Dicklyon (talk) 11:24, 27 March 2023 (UTC)

@Dicklyon: I agree that removing the newline in the template source code is not pretty. A large portion of relevant edits on those 6000+ templates are mine. I put the newline in there for readability. Is there an elegant way to make it so the newline doesn't get transcluded into article? I suspect this may require some sort of change to the fundamental coding of Wikipedia? If we have to go the brute force route, should we get a bot to run though these and remove all those newlines? We may want to consider doing the same for sports other than football; cf. Category:American college sports standings templates. Jweiss11 (talk) 17:37, 27 March 2023 (UTC)

Yes, I'd be happier to see it done in a better and more automated way. I've just done a bunch of football edits where I was putting a blank line before the lead, which is something I had done in lots of other areas before, when a couple of editors noticed this unusual side effect. I've stopped adding such spaces, but for fixing the existing problems, taking blank lines out of the article source seems like the hardest and most unsatifying approach. It would be nice if the this kind of noinclude placement wouldn't bring in the extra newline, but I bet it's hard to change that in the underlying code, too. I can do this football batch with JWB in a few hours. Dicklyon (talk) 20:40, 27 March 2023 (UTC)

When a template is transcluded, the whole of the template code is copied. Only then are the <noinclude>...</noinclude>, <onlyinclude>...</onlyinclude> and <includeonly>...</includeonly> tags processed. So if a template has newlines before a <noinclude>, those newlines will be included in the transcluding page, see WP:NOINCLUDE (the part just after the table). To suppress them will require a fundamental change to the MediaWiki template parser, and you would need to file a feature request at phab:. --Redrose64 🌹 (talk) 21:19, 27 March 2023 (UTC)

Yeah, I figured it would be too hard to fix something so deeply ingrained. I just checked, and found that the pattern }}<noinclude> followed by newline is quite common (JWB stops enumerating at 10000). So this approach of not putting a newline before the noinclude tag seems to be a pretty standard way to avoid the problem. Dicklyon (talk) 09:12, 28 March 2023 (UTC)

So, for clarity, where are the hidden "noinclude" tags? GenQuest ^"scribble" 17:09, 28 March 2023 (UTC)

Who mentioned hidden "noinclude" tags? --Redrose64 🌹 (talk) 19:08, 28 March 2023 (UTC)

Not hidden exactly, but at the end of the source code for the templates, such that putting a blank line after the template invocation turns into two blank lines. See my recent contribs. Dicklyon (talk) 08:31, 29 March 2023 (UTC)

@GenQuest: In which case, tags like these. --Redrose64 🌹 (talk) 20:15, 29 March 2023 (UTC)

I made a test-case example to illustrate the problem, using a pair of adjacent templates that I have not modified, one of which has the problem (due to this edit that put a newline before the noinclude tag): User:Dicklyon/Template_test. I also did a search through 10,000 templates with the noinclude tag at the end of a line, and found only 12% of them had a newline before the tag. So it seems to be a widespread practice, though not universally appreciated, to not put a newline before a noinclude tag (at least at the end of a template's source). I've done ahead and removed the extra newlines from the 6900 college football templates I mentioned, so that particular corner of wiki template space won't cause us more trouble. Dicklyon (talk) 08:03, 30 March 2023 (UTC)

Request update to Wikipedia:Manual of Style/Layout#Links to sister projects

After a discussion on my talk page, I realized that Wikipedia:Manual of Style/Layout#Links to sister projects should be updated slightly. The current wording states:

Links to Wikimedia sister projects and {{Spoken Wikipedia}} should generally appear in "External links", not under "See also". If the article has no "External links" section, then place sister links at the top of the last section in the article. Two exceptions: Wiktionary and Wikisource links may be linked inline (e.g. to an unusual word or the text of a document being discussed).

More precisely, box-type templates (such as {{Commons category}}, shown at right) have to be put at the beginning of the last section of the article (which is not necessarily the "External links" section) so that boxes will appear next to, rather than below, the list items. Do not make a section whose sole content is box-type templates.

If box-type templates are not good, either because they result in a long sequence of right-aligned boxes hanging off the bottom of the article, or because there are no external links except sister project ones, then consider using "inline" templates, such as {{Commons category-inline}} in the "External links" section, so that links to sister projects appear as list items, like this:

• Media related to Wikimedia Foundation at Wikimedia Commons

...and I propose that this section should be replaced with (main points/changes in bold):

Links to Wikimedia sister projects and {{Spoken Wikipedia}} should generally appear in "External links", not under "See also". If the article has no "External links" section, then place the sister link(s) in a new "External links" section using inline templates. If there is more than one sister link, a combination of box-type and "inline" templates can be used, as long as the section contains at least one "inline" template.

• Box-type templates (such as {{Commons category}}, shown at right) have to be put at the beginning of the "External links" section of the article so that boxes will appear next to, rather than below, the list items. (Do not make a section whose sole content is box-type templates.)
• "Inline" templates are used when box-type templates are not good, either because they result in a long sequence of right-aligned boxes hanging off the bottom of the article, or because there are no external links except sister project ones. "Inline" templates, such as {{Commons category-inline}}, create links to sister projects that appear as list items, like this:
  • Media related to Wikimedia Foundation at Wikimedia Commons

If an external link is added and/or exists in the "External links" section, the "inline" templates linking to sister projects can be replaced with their respective box-type templates.

These wording changes remedy a few issues:

• Placing a box-type template in the "References" section (which could be the last section of the article) causes the reference list to be formatted improperly if width customization options are used in the {{Reflist}} template. With the new wording, there's instruction that box-type templates are only placed in an "External links" section where there is a very low chance of there being such issues.
• This ensures clearer instruction about how and when to add sister link templates to the article by always having the templates in an "External links" section, preventing the need for moving links to an "External links" section in the event the section is created later (which is the case with the current instruction, even if it is not stated specifically.)
• The new instruction reduces WP:INSTRUCTIONCREEP by not specifying which sister projects are allowed to be linked "inline" by themselves. (Currently, the passage states that only links to Wiktionary and Wikivoyage can be by themselves as inline templates in an "External links" section).
• The new formatting and wording more clearly defines what "box-type" and "inline" templates are by making their descriptions list items with definitions.
• Instruction has been added stating the circumstances when "inline" templates can be replaced with "box-type" templates, which currently is not present in the section.

...Thoughts? Steel1943 (talk) 21:03, 13 July 2023 (UTC)

Took a nice large dose of fukitol after this edit/revert. Good luck, ya red tape-wrapping bummers. Steel1943 (talk) 21:36, 22 July 2023 (UTC)

TL;DR. Maybe make these changes, one a day, and include the explanation for each in your edit summaries. - Butwhatdoiknow (talk) 16:17, 17 July 2023 (UTC)

The "TLDR" can disappear if the first passage is ignored; it's just the current state of the text for reference. Steel1943 (talk) 19:40, 17 July 2023 (UTC)

Okay, it's been over a week with no "support/oppose"-style feedback, so I'm going to assume this is uncontroversial per WP:SILENCE and make the changes. Steel1943 (talk) 15:45, 21 July 2023 (UTC)

I'm late to the party, but I support the change, as I prefer consistency in article order, and would also welcome a similar change for Portal templates/See also sections. I also don't mind sections whose sole content is box-type templates, but I avoid making them since others object. —DocWatson42 (talk) 11:02, 22 July 2023 (UTC)

Maybe there was no feedback for a week because your post is TL;DR. As I suggested above, I'm okay with you making bold edits to find out what folks think of your changes. - Butwhatdoiknow (talk) 14:30, 22 July 2023 (UTC)

Well, they found out, but couldn't handle the revert of their work. Too bad, but if that's how they react when someone disagrees with them, then it's probably a good thing they've decided to leave. It saved themself from warning for incivility. BilCat (talk) 22:22, 22 July 2023 (UTC)

Well, I'm not at all happy at how that played out – I had just no idea that the user felt so strongly about this rather trivial matter, and greatly regret having contributed, even unwittingly, to the departure of a valued long-term editor. That said, I oppose the proposed changes, both on the grounds of instruction creep and because creating a whole extra section for one sister-project link is quite excessive. Unfortunately, EL sections have a tendency to attract spam, so are probably best avoided unless actually necessary. If we absolutely have to have yet more rules, I'd suggest something along the lines of "Do not create an external links section just for sister-project links". Oh, I see that my revert was undone by Butwhatdoiknow on the grounds that consensus was not required; I disagree – once a bold edit has been challenged, consensus is indeed required to re-instate it. Justlettersandnumbers (talk) 13:13, 28 July 2023 (UTC)

@Justlettersandnumbers - You and I agree that when an edit is reverted for a substantive reason, such as you have provided above, the editors should resolve the challenge before the change is reinstated. WP:QUO. Where we diverge is whether it is appropriate for an editor to revert without giving a substantive reason. I believe it isn't. WP:DRNC.

In this case, User:Steel1943 first provided a lengthy explanation of their proposal on talk. They then waited a significant period of time and received two responses. One neutral and one positive. Finally, they make their non-bold edit, only to see their thorough and patient work undone by a substance-free hit-and-run revert. I can see how frustrating the experience must have been for them. - Butwhatdoiknow (talk) 16:35, 28 July 2023 (UTC)

• Comment: This discussion was brought to my attention following a revert. While some of WP:MOSSIS seems pretty clear, some of it is left a bit ambiguous. That may be intentional (speculation), to allow for situations in which a hard rule would not be a good idea; instead of an exception to a hard rule, it's left a bit ambiguous. I agree that perhaps WP:MOSSIS needs a clarification update, but I wouldn't advise going at a thumbtack with a maul. Personally, I don't mind § External links containing only one sister project, provided it's the bulleted inline-type. Sister projects are external to Wikipedia as their own project, with their own set of rules and templates (though I find this annoying at times). The reasoning against the box-type in such a situation is the excessive white space it creates. I would suggest (my personal guide) that a box-type sister project template is a good idea in §El if there is at least three bulleted external links, or when it's otherwise necessary/unavoidable (taking font/zoom/platform into account). Again, I would write that as a guide, not a strict policy. — CJDOS, Sheridan, OR (talk) 19:19, 29 July 2023 (UTC)
  Note: I'm specifically mentioning Wikipedia:Wikimedia sister projects#Where to place links (WP:MOSSIS), while this discussion has called Wikipedia:Manual of Style/Layout#Links to sister projects. — CJDOS, Sheridan, OR (talk) 19:43, 29 July 2023 (UTC)

Proposed modification to further reading sections

In 2014, we added the following line to MOS:FURTHER: "Any links to external websites included under "Further reading" are subject to the guidelines described at Wikipedia:External links."

I'd like to tighten that requirement by pointing to Wikipedia:Reliable sources instead of external links. My understanding of what differentiates further reading sections from external links is that they are intended to hold reliable sources anyway ("publications that would help interested readers learn more about the article subject", my emphasis).

This change would also allow paywalled sources in further reading sections, which seems fair given that we currently allow editors to list offline sources that may or may not require money to acquire, and WP:PAYWALL allows their use elsewhere in articles. Ed ^{[talk] [OMT]} 01:22, 9 October 2023 (UTC)

Just so it is clear in my head, your proposal would not change the criteria for publications to appear, just the criteria for when links may be placed within a listed publication entry. Do I have that right? - Butwhatdoiknow (talk) 15:51, 9 October 2023 (UTC)

@Butwhatdoiknow: The change would require "further reading" entries to be reliable sources, and remove the requirement that they meet the "external links" guideline. (I don't believe EL would add any benefit above RS, and it would maybe even conflict because EL doesn't apply to references.) Ed ^{[talk] [OMT]} 02:13, 10 October 2023 (UTC)

But the sentence you propose to change only applies to "links to external websites" (it doesn't include other entries). Maybe the RS link should appear elsewhere in the FURTHER - perhaps in a new sentence? - Butwhatdoiknow (talk) 07:08, 10 October 2023 (UTC)

• Oppose. Many articles don't require literature to be "reliable sources" because they are not "sources", just literature the reader may be interested in that is related to the topic. Let's not fix what is not broken and let's WP:NOTCENSORED be taken into account also. Regards, Thinker78 (talk) 04:12, 10 October 2023 (UTC)

  NOTCENSORED does not apply to every removal of anything; it has a specific meaning that isn't relevant to the rationale for the proposed change. Nikkimaria (talk) 04:27, 10 October 2023 (UTC)

  In your opinion but I respect that you disagree with me. Regards, Thinker78 (talk) 04:51, 10 October 2023 (UTC)

  @Thinker78: Thanks for your thoughts! Do you have examples of articles that use further reading sections for non-reliable sources? I imagine it would be for self-published sources that aren't available online? I don't believe I've seen this before. I'd be open to tweaking this proposed change to allow for what I'm thinking is an edge case. Ed ^{[talk] [OMT]} 04:31, 10 October 2023 (UTC)

  I don't have examples of articles at hand. But I would imagine one benefit of not restricting it is if someone wants to know more about a fringe theory that is not supposed to be treated extensively in the article body (specially maybe the author of it which may not be reliable source), the Further Reading section could be the appropriate place to go. Regards, Thinker78 (talk) 04:57, 10 October 2023 (UTC)

• Support. There is already an external links section that can hold external links per the external links guidelines. This clarification for this section seems quite reasonable, and as noted allows informative publications that otherwise are technically not permitted. Nikkimaria (talk) 04:27, 10 October 2023 (UTC)
• Support – Maybe "(and) reputable/scholarly" captures the spirit of help interested readers learn more about the article subject. -- Michael Bednarek (talk) 04:36, 10 October 2023 (UTC)
• Oppose - WP:RS would exclude WP:PRIMARY sources which I see as acceptable Further reading material. I do support lifting the current implied restriction on paywalled material. I suspect that was an unintentional consequence of adoption of WP:EL in 2014. ~Kvng (talk) 15:01, 15 October 2023 (UTC)
  • @Kvng: I don't see the proposal as excluding primary source material. WP:SCHOLARSHIP says that secondary sources are preferred, and not that they are barred. Perhaps, though, this proposal needs to be made wider than a link swap -- will think. Ed ^{[talk] [OMT]} 20:48, 17 October 2023 (UTC)
• Oppose. WP:PRIMARY sources may usefully go there, as Kvng points out. Another option might be partially fictionalized accounts of historical events – clearly not WP:RELIABLE, but may nevertheless be good for this section, if identified accordingly. Or even biased or otherwise problematic accounts, again provided they are clearly labelled as such and no undue weight is given to them. "Further reading" content is not actually used as sources, hence we can afford to be a bit more tolerant in what we accept there. Gawaon (talk) 16:28, 17 October 2023 (UTC)

Notes

"Mos:FURTHER" listed at Redirects for discussion

The redirect Mos:FURTHER has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 October 11 § Mos:FURTHER until a consensus is reached. Utopes _{(talk / cont)} 23:45, 11 October 2023 (UTC)

Periods at ends of links in see-also sections

Maxeto0910 (talk · contribs) has been adding periods to the end of see-also links when the short description provided in the link happens to resemble a grammatically complete sentence. Example: the link to Immerman–Szelepcsényi theorem in Savitch's theorem, provided using {{annotated link}} to incorporate the short description of the linked article, currently "Nondeterministic space complexity classes are closed under complementation" (but significantly too long and in need of shortening). My position is that see-also entries in general, and the ones generated by annotated links in particular, are more often than not only sentence fragments, and that for consistency we should use a format for see-also sections in which the period is omitted from all entries. I don't see any guidance on this issue in MOS:SEEALSO, but this is consistent with all examples provided there, including the "Joe Shmoe" example which happens to resemble a grammatically complete sentence. Should this be addressed more explicitly there? —David Eppstein (talk) 22:39, 22 October 2023 (UTC)

In your edit summary, you wrote "As a general rule see-also links do not use periods and I see no exception for this case."

I'm just asking for that general rule because I couldn't find any guideline which states that. That's why I requested a link to a corresponding guideline in my edit summary.

The Joe Shmoe example in MOS:SEEALSO is merely a sentence fragment, as the description lacks the subject because it's obvious from the context to which it refers — "[He] made a similar achievement on April 4, 2005".

If there's no guideline regulating this Wikipedia-specific issue (yet), which it seems like, I'd argue that the general rules of the English grammar should apply, after which every complete sentence should end with a period. Maxeto0910 (talk) 23:26, 22 October 2023 (UTC)

Are "References" sections obsolete in light of Citation lists?

Perusing the Nationalism article, I couldn't help but feel its reference section felt obsolete, in light of the much more complete citation list above it. I'm sure this applies to (probably) every article with such a section, given all citations automatically go into the citation list. In most cases, reference lists only repeat the relevant information of the citations ad tend not to be updated in line with them either. It seems they just bog articles down, with the obvious exception of when those citations are not full citations. But perhaps I'm missing some other function they provide? Yr Enw (talk) 09:21, 1 November 2023 (UTC)

That article is no good. The citation list is poor and incomplete. It lists books but not the relevant page numbers. When you have books, you either need the reference section along with cite templates, or you need to supply the page references next to the footnote references with rp templates. Hawkeye7 (discuss) 09:35, 1 November 2023 (UTC)

It looks to me like somebody began to use WP:CITESHORT but gave up partway through. --Redrose64 🌹 (talk) 21:47, 1 November 2023 (UTC)

Proposed definition of 'body'

The Wikipedia:Glossary did not have an entry for the body of an article, nor is there one here at MOS:LAYOUT. The definition at MOS:LAYOUT is merely implied negatively by what it isn't; namely, it's what's left after defining everything else: i.e., it's not the lead or table of contents, and not the Appendixes or bottom matter. Of course, not all articles have a lead, table of contents, or appendixes, and anyway, a negative definition isn't appropriate for a glossary entry. So I've attempted a positive definition. Here's what I came up with:

Body – The part of an article containing detailed content about the article topic, as defined by its title, excluding the lead, if any. The body follows the lead and may be followed by optional appendix section(s). For short articles with no lead or appendixes, the body may be the entire article, with any end matter following after.

Note that MOS:BODY points to Wikipedia:Manual of Style/Layout#Body sections, and nothing there disagrees with this definition, although it never actually defines it. I've added this definition to the Glossary just to have something, but will adjust it to conform to any consensus reached here. Your feedback would be appreciated. Mathglot (talk) 01:33, 17 November 2023 (UTC)

All good except for "appendix sections". I've not seen or used that term around here. I prefer "end matter". ~Kvng (talk) 16:02, 22 November 2023 (UTC)

Thanks for your comment. The term appendix is used in the major section heading § Standard appendices and footers at Wikipedia:Manual of Style/Layout, and in the shortcut MOS:APPENDIX that links to it. It is also point #3 in the ordered list at § Order of article elements (a.k.a., MOS:SECTIONORDER), where "End matter" is point #4, and comes after "Appendices". Appendices is also used in other pages, such as WP:Perennial proposals. That said, I think that all three terms (appendices, bottom matter, end matter) are often understood interchangeably, and we should go with whatever most people are familiar with. Maybe we could just finesse the whole issue and not use any of them, and just end the definition with, "... and may be followed by supplementary, non-content material", or use both, and say "...appendices and end matter"? Mathglot (talk) 20:14, 22 November 2023 (UTC)

I would avoid "appendix" because to me it means a textual section appearing after the main body of a written work. We don't have those in Wikipedia articles. —David Eppstein (talk) 20:45, 22 November 2023 (UTC)

Of course we do, in millions of articles. Your understanding of appendix is not how it is used in numerous locations at MOS/Layout as just linked above. The sense in which Wikipedia uses it aligns well with definitions at American Heritage, Merriam-Webster, OED^{[via TWL]} and other dictionaries. If you want to avoid the use of appendix, that would have to be a separate proposal on this page, and imho would be a steep mountain to climb, as this meaning goes back decades; even the shortcut MOS:APPENDIX goes back to 2009.

However, I don't want to get sidetracked, as this discussion is about what to write in the Glossary for the entry Body, which should merely reflect what it means here. The fact that there isn't a clear definition for it on this page, is what prompted it. I'm just looking for agreement for (or objections to) the glossary definition for body. Mathglot (talk) 21:17, 22 November 2023 (UTC)

@Mathglot, your finesse is good. I was obviously not aware that we had so many terms in play for the stuff at the end of an article. ~Kvng (talk) 14:57, 25 November 2023 (UTC)

The "supplementary, non-content material" will not solve disputes; in will probably increase them, as editors will disagree over whether the citations to reliable sources are "content". Duplicating terms ("appendices and end matter") will make editors believe that these are different things (==See also== is the appendix, and ==References==, where the endnotes are located, must be the end matter?). If we need to define this thing at all (which I doubt), we probably need to use the word appendix and link to MOS:APPENDIX for anyone who doesn't know what that bit of wikijargon means.

About the definition: I'm not sure that larger tables are always included when editors talk in "the body of the article". Sometimes "the body" seems to get used to indicate "the paragraphs of text" (as opposed to tables, long lists, or perhaps images). Also, WP:ELBODY includes the lead of the article (but not infoboxes) as "the body". WhatamIdoing (talk) 17:58, 25 November 2023 (UTC)

I'm not the one calling appendices and end matter two different things; this guideline is. "Appendices" are listed as major bullet #3 in section § Order of article elements and lists 5 items; "end matter" is bullet #4 lower down, and lists ten. As fn 6 points out, this is largely unchanged since 2003, so that's what they mean, for the last 20 years. It's not asking too much to define "body" here as well. Mathglot (talk) 07:24, 26 November 2023 (UTC)

Thanks.

About excluding the lead from the body, consider ELBODY: "With rare exceptions, external links should not be used in the body of an article." I think that if we add this definition, a wikilawyer will eventually come along to say that the lead isn't part of the body of the article, and therefore external links are fine in the lead. WhatamIdoing (talk) 17:40, 26 November 2023 (UTC)