Jump to content

Wikipedia talk:Manual of Style/Lead section

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style

This is an old revision of this page, as edited by L235 (talk | contribs) at 01:04, 29 November 2020 (→Sidebars (navboxes) should NOT be used in the lead: Closing discussion (DiscussionCloser v.1.7.3)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style articles
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a consensus against an absolute ban on the use of navboxes (sidebars) in the lede. However, there is a moderate consensus in favor of introducing guidance that in general, editors are discouraged from placing navboxes in the lede, with about two thirds of participants in support. This consensus does not authorize the mass removal or deletion of sidebar navboxes. Several participants emphasized the need to make case-by-case determinations; if editors seek the deletion of a particular navbox, it should be brought to TfD as usual.
To bring this consensus into effect, the following text in MOS:LEAD should be changed: Sidebars are sometimes placed in the lead, especially when no infobox is present. If an infobox is present, the navigation sidebar may be moved to either the top or bottom of any other section in the article.. I suggest that to implement this RfC the text be changed to Sidebars are often placed at the top of bottom of any section of an article. The placement of sidebars in the lead is discouraged. This specific text is not consensus-backed, however, so it may be changed through the normal editing process as long as it is consistent with the consensus articulated above.
A procedural matter: RfCs are required to be written neutrally. This RfC (with a section title Sidebars (navboxes) should NOT be used in the lead) should have been put on hold until it was replaced with a neutral question like "Should editors be prohibited from adding sidebars (navboxes) to the lead?" In closer cases, or where the non-neutral question clearly prejudiced one perspective, a closer might determine that an RfC is invalid for failing to present a neutral question, and close the discussion without finding consensus.
Best, KevinL (aka L235 · t · c) 01:04, 29 November 2020 (UTC)[reply]


Navigational sidebars should not be used in the lead.

Technical note: Navigational sidebars are not visible on mobile versions of Wikipedia representing approximately 60 percent of readers. (i.e. Desk top vs Mobile version)

Rationale: The MOS should strongly reject the use of navboxes (sidebars) in the lede. There are many reasons, such as

  • The top right corner should be reserved for an image related to the article's topic.
  • Wikilinks are the best way for readers to navigate between aticles. Few if any readers will want to hop between articles by topic. Practically none will do so by using the sidebars.
  • As a rule, an article belongs to many general topics. Which one gets to put its sidebar there?
  • Editing and inserting sidebars uses a lot of editor brainpower that could be used in more productive ways.
  • Sidebars imply a division of knowledge into topics that is at best artificial, at worst misleading and mind-limiting.
  • Readers who want to read broadly on articles about a given topic are much better served by a regular article on that topic, that points to specific articles trough wikilinks. The "tab" feature and back" button of most browsers makes it unnecessary to have a sidebar on every article with that topic.
  • Sidebars tend to split Wikipedia into a federation topical encyclopedias, each "owned" by a Wikiproject -- which inevitably tends to be dominated by a few editors who create their own rules of style and contents, and are unconsciously hostile to "outsider" editors.

For these and other reasons, the MOS should say "no" to navboxes in the lede. Existing sidebars should be merged into the articles about the respective topics, or, at worst, turned into navbars at the bottom of the article.--Jorge Stolfi (talk) 23:06, 15 August 2020 (UTC)[reply]

The RFC guidelines require a neutral heading and introductory paragraph posing the question to be answered. This most definitely does not have either. SpinningSpark 07:26, 10 September 2020 (UTC)[reply]

Discussion

Jorge Stolfi, can you give me an example of an article (or several) where there are active disputes over a sidebar? WhatamIdoing (talk) 21:37, 17 August 2020 (UTC)[reply]
If there aren’t, it’s partly because I don’t put up a fuss about how much I hate them. For all the reasons mentioned by Jorge. Navigational sidebars in article space should be horizontal, at the bottom ... we have enough clutter at the top with infoboxes. Actually, I have put up a fuss before about these, even on a FAC once, but with so many years, who knows where to find those now. And we are even getting navigational templates IN infoboxes, at hurricane articles. See hurricane Dorian. These are See also, and WP:LAYOUT tells us See alsos go in an appendix, so we already have a guideline on it, that is never enforced (unless at FAC, as I did oppose them in my day) or followed. SandyGeorgia (Talk) 22:01, 17 August 2020 (UTC)[reply]
There probably aren't, because these are added by prolific drive-by nuisances editors who probably don't even watchlist the articles they add them to. I've removed or moved down large numbers, with few complaints that I remember. But plenty will be left, and one shouldn't have to do this work. Frankly, many of these should just be deleted, but who can bother? Johnbod (talk) 12:45, 23 August 2020 (UTC)[reply]
@WhatamIdoing: @SandyGeorgia: Amen...
A big meta-problem of Wikipedia is that complaints about bad rules and features are either wasted, for being posted on general forums that hardly anyone reads, or are read only by the same editors who created those rules and features, who naturally dismiss all complaints. Sigh...--Jorge Stolfi (talk) 01:40, 18 August 2020 (UTC)[reply]
And no one reads this page, either. SandyGeorgia (Talk) 01:43, 18 August 2020 (UTC)[reply]
I've long wondered how much readers use the end-of-page navboxes. They don't appear on the mobile site, and I don't recall ever seeing a complaint about that, which suggests that they're not missed too often.
Hi - here is a complaint about the lack of end-of-page navboxes on the mobile site. They are useful on desktop, and I miss them on mobile. Newystats (talk) 09:33, 9 November 2020 (UTC)[reply]
I think the problem with 'just remove it' as an approach is that the navbox page is interpreted as requiring that if the article is present in the navbox, then the navbox must be present in the article. I don't know if that is enforced as strongly for the sidebars, which are usually more general. WhatamIdoing (talk) 04:31, 18 August 2020 (UTC)[reply]
They are typically used to advance a POV. I suspect they are much more used by editors than readers ... the links are typically all in articles anyway, but editors use navbox lists when they need to make across-the-board changes. Another reason why I think they disrupt article space. It would be nice of me to find an example ;) SandyGeorgia (Talk) 13:23, 18 August 2020 (UTC)[reply]
(to both the last) I don't really agree with the POV poinrt. They are imo typically done by people who like coding them, often perhaps because English language skills are not required. They are one example of what unfortunately constitutes the majority of our "editing" today. As I've said, I don't get comeback from removing them - I doubt the placers are aware, & I think most other editors approve. Only their creators love them. Johnbod (talk) 17:13, 23 August 2020 (UTC)[reply]
Johnbod, I think that parts of {{Alternative medicine sidebar}} might count as a sort of POV pushing. WhatamIdoing (talk) 20:02, 25 August 2020 (UTC)[reply]
No doubt - Template:Humanism has had issues in the past, as have related articles. But these are local fires to put out. Not I think typical of the general problem. Johnbod (talk) 20:07, 25 August 2020 (UTC)[reply]
@SandyGeorgia, Johnbod, and Jorge Stolfi: WhatamIdoing wrote, a few levels back: I've long wondered how much readers use the end-of-page navboxes. They don't appear on the mobile site, and I don't recall ever seeing a complaint about that, which suggests that they're not missed too often. ...I think that's largely accurate, but it may be more correct/complete to say that they're not often missed by mobile users.
Speaking for myself, I find reading on my phone far more tedious and unproductive than on my desktop (due largely to the vast disparity in both the size and format of the two screens involved), so when I read articles using a mobile device I'm far more focused on a goal-oriented "get in, get what I need, and get out" approach where I'm not really looking for distractions, tangents, or information on related topics — the sort of connections infoboxes are meant to facilitate. But that doesn't mean I wouldn't miss those infoboxes on the desktop site, where I'm far more interested and likely to make use of them. Seems as though, even if only by accident, we may have actually gotten the balance pretty much correct on that with the way things already stand. -- FeRDNYC (talk) 22:58, 30 August 2020 (UTC)[reply]
FeRDNYC, do you mean Wikipedia:Infobox (white at the top) or Wikipedia:Navboxes (blue at the bottom)? WhatamIdoing (talk) 16:15, 2 September 2020 (UTC)[reply]
@WhatamIdoing: ...Yes? Navboxes for sure are pure distraction, I think I'd actively dislike if they appeared on mobile. (Especially in their current HTML-tables design, which is completely unresponsive and looks comical on a mobile screen.) But even Infoboxes, while nice to have on the desktop, are mostly "enhanced content" that doesn't translate well to the smaller screen. Having what's basically the built-in equivalent of mobile browsers' "Simplified view" of the article can be a welcome relief from the distractions of additional data and links, no matter how relevant. -- FeRDNYC (talk) 16:31, 2 September 2020 (UTC)[reply]
I believe that infoboxes are displayed on mobile, underneath the first paragraph. WhatamIdoing (talk) 19:02, 2 September 2020 (UTC)[reply]
@WhatamIdoing: Indeed they are! And not even, as I'd had it in my head they'd surely have to be, in any sort of stripped-down form. They're pretty much fully intact. Even embedded content like maps and charts are included, where present. Which makes sense, I suppose, since unlike navboxes the standard infobox layout is almost inherently mobile-friendly. (In fact, since the box is shown full-page-width in the mobile form factor, it gets slightly more room to spread out than in its corner of the desktop page layout and looks a bit less busy and cluttered.) It's still an opportunity for distraction, but at least an attractively-laid-out one with a reasonable signal:noise ratio for the actual article topic (again unlike navboxes). -- FeRDNYC (talk) 01:01, 4 September 2020 (UTC)[reply]
Middle ground wording might be best for moving this forward? ...." Navigational sidebars should not be placed in the lead section if an infobox is present to avoid clutter."--Moxy 🍁 02:02, 18 August 2020 (UTC)[reply]
There should also not be more than one. Frankly, if the MOS merely warned against including sidebars in article bodies, that would be an improvement. CMD (talk) 14:23, 18 August 2020 (UTC)[reply]
Agree with mid body templates and with main article infoboxes that get stuffed in the body of articles as seen at China#Names that only need to be at the lead of Names of China.--Moxy 🍁 17:08, 23 August 2020 (UTC)[reply]
After looking at some samples, I became more concerned about how they are used to advance a POV. Most likely, there have been disagreements over which template comes first if someone wants to dig back in article talk archives. For example, does Discrimination or the anti-Catholic screed take priority in the Catholic articles? I would wager that, with the Hurricane articles aside, and setting aside the mostly abandoned Psychology WikiProject, an examination would reveal that many of these are for advancing a POV, giving them a prominent position within articles. SandyGeorgia (Talk) 15:06, 18 August 2020 (UTC)[reply]
@WhatamIdoing: As for examples of disputes about alternative navboxes, I cannot give one that is active right now. But there seems to be frequent contention, for example, between infoboxes {{chembox}} and {{Infobox drug}}. The article on ascorbic acid apparently had to be split in two (vitamin C and chemistry of ascorbic acid) because of that reason. I personally had that dispute with another editor over chlorine-releasing compounds.
The current style of infoboxes is a problem too, for that reason. But at least infoboxes contain important information, so we can discuss that problem separately. Navboxes in the lede have no such excuse...--Jorge Stolfi (talk) 18:03, 23 August 2020 (UTC)[reply]
I think this discussion warrants an alert to editors that these boxes are being discussed for mass deletions. I don't know how to place an alert near every sidebar (sidebox) on Wikipedia.
A consideration that needs to be appreciated is that sideboxes are useful on articles that are about concepts or abstractions. Articles that are about events, people, things (physical objects), and places can rely upon infoboxes or simple images. A case-by-case approach seems better to assess the usefulness of the sidebars. Or a small group of questionable sidebars can be examined at a time. Mitchumch (talk) 06:03, 23 August 2020 (UTC)[reply]
This would also affect our odd guide that encourages indiscriminate template spam at WP:BIDIRECTIONAL that some academic topics (such as Wikipedia:Manual of Style/Military history#Navigation templates ) have already tackled. Left a notice and turned this into an RFC--Moxy 🍁 16:48, 23 August 2020 (UTC)[reply]
Can we codify that WP:MILMOS#NAV templates are exempt (perhaps as an exemption for the {{military navigation}} base template)? Templates such as {{campaignbox}} are not merely navboxes and it's bad enough that many of these campaignbox templates are routinely nominated for deletion for having "too few links for a navigational template" (as here), even though that's how many battles were in the campaign. Mojoworker (talk) 16:45, 24 August 2020 (UTC)[reply]
Mojoworker, that could be done, but why does MILHIST want {{Campaignbox Iraq War}} to be vertical and collapsed, instead of horizontal and open? WhatamIdoing (talk) 20:09, 25 August 2020 (UTC)[reply]

Perhaps a bit of a tangent: Would you recommend limiting the size of a sidebar somehow? Like normally no more than 10 links, or saying that everything linked must be very closely related (e.g., about a single person/book/business)? WhatamIdoing (talk) 20:14, 25 August 2020 (UTC)[reply]

Template:Rembrandt (a bottom of the page one) is something to chew over in that context! Johnbod (talk) 20:33, 25 August 2020 (UTC)[reply]
@Johnbod, the bottom-of-the-page navboxes aren't sidebars. This is about the Category:Sidebar templates, such as Template:Sociology. WhatamIdoing (talk) 14:39, 29 August 2020 (UTC)[reply]
I know, I know. But, as many have said above, large sidebars should be converted into bottom-dwellers, they come into it as well. Johnbod (talk) 14:54, 29 August 2020 (UTC)[reply]
Sidebars are okay for conceptual topics (that wouldn't usually be served by an infobox, per Mitchumch's above observation) covering a very limited set of closely related articles (that wouldn't overlap with other topics). However, as Wikipedia has long trended towards the proliferation of infoboxes as well as bloat of navigational templates, the number of usable sidebars has plummeted. It's not necessarily the size or number of links included that matters, but the tightness of their relation. Template:History of Western art music, for example, works (mostly) well as it covers a well-defined series of chronologically related articles (though it still has some clashes e.g. in Postmodern music). --Paul_012 (talk) 21:11, 25 August 2020 (UTC)[reply]

One problem with them that I don't see mentioned here is the problem they cause in the mobile app. If the article does not have a top image and, like {{History of the United States}}, the sidebar does have one, then the mobile app, not the mobile web, shows the sidebar image. Currently the Prehistory of the United States has the great seal of the United States as the top image. Odd but not as bad as last week when Pre-Columbian era was showing it. It's not a major problem as the use of the app is still low compared to other views. CambridgeBayWeather, Uqaqtuq (talk), Huliva 16:29, 28 August 2020 (UTC)[reply]

@Power~enwiki:It's like cancer, right? Nothing but propaganda in the case you mentioned. WP:NOT: "Wikipedia is not a directory of everything in the universe". Well maybe not... yet. Ponor (talk) 06:23, 17 November 2020 (UTC)[reply]

Samples

Survey

  • Oppose. I don't object to them in principle, although their use in some of the examples is cluttering—and in the case of Controversies in autism just wrong—but I think these issues should be managed at the articles rather than by a blanket ban. Shhhnotsoloud (talk) 11:23, 19 August 2020 (UTC)[reply]
  • Support They should not absolutely be banned but the MOS should say they should be lower than an infobox and/or lead picture, and should generally not be high on pages with several useful images. Johnbod (talk) 12:45, 23 August 2020 (UTC)[reply]
  • Support as a preference rather than an absolute ban. MOS should say that in general navboxes should be footers rather than sidebars. —David Eppstein (talk) 16:34, 23 August 2020 (UTC)[reply]
  • Support no need to jam the lead with navigational aids when we have infoboxes in place. Part of a series...type templates should only be included if there is no infobox or lead image in place and only one is needed.--Moxy 🍁 16:58, 23 August 2020 (UTC)[reply]
  • Support because of everything mentioned by Jorge Stolfi and especially this: "Wikilinks are the best way for readers to navigate between aticles." Things need to be put in context, not in endless lists. Ponor (talk) 17:04, 23 August 2020 (UTC)[reply]
  • Support, they are often used to further POV (see some samples in section below), all navboxes should be horizontal at bottom of article, they should never be in the lead, and rarely in the first section. For the same reason, I also support a complete ban of these dreadful things. SandyGeorgia (Talk) 17:28, 24 August 2020 (UTC) Updated, SandyGeorgia (Talk) 12:57, 25 August 2020 (UTC)[reply]
  • Support. In short, I agree with Johnbod, with David Eppstein, and with the nom and Jorge Stolfi simultaneously; their suggestions should be merged in final revision language. I can't concur with SandyGeorgia; the solution for PoV-pushing navboxes is to fix the PoV in them, or if the inclusion of one at all in a particular article is a PoV issue, RfC it on the talk page. That has nothing to do with this proposal, which is about navboxes clouding up the lead section, a concern that is completely agnostic as to the content-appropriateness of any implied labeling being done by the content of the navbox.  — SMcCandlish ☏ ¢ 😼  21:46, 24 August 2020 (UTC)[reply]
  • Oppose ban, but support guidance: a complete ban is irrational. Thousands of sidebars exist for a reason. A better approach is to challenge each sidebar on a case-by-case basis or small groups of sidebars that share similar features or issues at Wikipedia:Templates for discussion. New guidelines surrounding their existence seems more reasonable. Mitchumch (talk) 22:00, 24 August 2020 (UTC)[reply]
  • support as guidance Navigation in the lead can be an exception justified where warranted. —¿philoserf? (talk) 22:55, 24 August 2020 (UTC)[reply]
  • Oppose ban...but support guidance on not having them above the lead image or infobox. One issue I have with navboxes is redundancy, meaning when we have this box in the lead and then essentially the same thing (with a few differences) at the bottom. We don't need both. If the second one actually adds anything, maybe keep it. I prefer that the navbox not be in a section. Unless what it's doing is better covered by a box at the bottom, I prefer that the navbox be in the lead beneath an image or infobox...if either of those are there in the lead. Flyer22 Frozen (talk) 03:48, 25 August 2020 (UTC)[reply]
For wider input, I alerted WP:Village pump (policy) to this discussion. I see that Wikipedia talk:Manual of Style has already been alerted. Flyer22 Frozen (talk) 03:59, 25 August 2020 (UTC)[reply]
  • Oppose ban, support as guidance per above. · · · Peter Southwood (talk): 11:01, 25 August 2020 (UTC)[reply]
  • Oppose ban but support guidance per Mitchumch. A blanket ban is over the top; some articles have no infoboxes or pictures, so that's not an issue, and having one underneath is fine anyway. POV issues can be handled by editing the article, the template, or at TfD. Crossroads -talk- 04:51, 26 August 2020 (UTC)[reply]
  • Support I am struggling to find a reason why a navbox would ever make sense in the main body of text, especially if they do not show up on mobile devices. --Enos733 (talk) 16:48, 28 August 2020 (UTC)[reply]
  • Support as guidance preferably not in the lead, and if so, below the lead image and/or infobox, per above. Lev!vich 06:00, 30 August 2020 (UTC)[reply]
  • Support as guidance I would suggest to ban adding sidebars to at least articles with an existing infobox. There are certain short-sized articles with three/four or even more sidebars along with an infobox, needless to explain the layout disaster it causes. --Zayeem (talk) 19:19, 5 October 2020 (UTC)[reply]
  • Support In almost all cases, articles should use a lead image if one is available. (t · c) buidhe 01:03, 25 October 2020 (UTC)[reply]
  • Oppose per Mitchumch. Gog the Mild (talk) 20:14, 5 November 2020 (UTC)[reply]
  • Oppose I likewise fully agree with the points Mitchumch has raised.--Catlemur (talk) 11:28, 6 November 2020 (UTC)[reply]
  • Support as guidance (second choice: support ban). Almost always, this sort of content is better presented in a navbox at the bottom of the article. I can think of a few potential exceptions -- it possibly could be useful in series on the history of a country where different chronological portions of history have different names (e.g. history during a certain time period is in an article under the title of a former colony). This can be helpful for the reader to understand whether they made it to the right article (though the same might be achieved using a hatnote?). But the vast majority of the time, these are cluttery and unhelpful, and like others have noted above, it's awful when articles fall into the scope of more than one side-navbox and 2+ are used. Calliopejen1 (talk) 18:44, 6 November 2020 (UTC)[reply]
  • Oppose - Fix the mobile version, don't limit the primary version. I agree that images are better, but many times subjects do not lend themselves to an image. Beyond My Ken (talk) 20:40, 6 November 2020 (UTC)[reply]
  • Oppose If an article has no image, then a navbox is a perfect thing to put there. Many articles cannot or do not have relevant images, and I think having a navbox should be allowed. Plus, this is unnecessary creep. If it looks bad, change it. If its not a problem, keep it. No need for formal guidance. CaptainEek Edits Ho Cap'n!⚓ 02:59, 7 November 2020 (UTC)[reply]
  • Oppose per CaptainEek. If it aids the reader in finding related topics to the article that they're looking up, then I would argue that there's a clear benefit to its inclusion in articles. Whether a navbox is appropriate for an article or not is really something that would be better handled on a case-by-case basis, rather than a blanket ban on them. OhKayeSierra (talk) 06:17, 7 November 2020 (UTC)[reply]
  • Oppose Sure they can be used poorly, but the same can be said about just abut every other element here. I could find lists of examples of articles with poor images, infoboxs, see alsos etc. However they do have a place and in some cases are a better alternative than infoboxes or a lead image. Just get rid of the poor ones on a case-by-case basis, there is no need to provide overreaching guidance one way or the other. AIRcorn (talk) 16:56, 7 November 2020 (UTC)[reply]
  • Oppose ban as it's simply not useful for a large number of articles especially those on technical subjects. Phonetics for example has a navigation box that guides readers to other, more specialized topics so that they don't need to scroll to the bottom to find them. An image would be largely useless for readers; a navigational aid to further content is far more useful there than a picture of someone talking. — Wug·a·po·des​ 02:08, 8 November 2020 (UTC)[reply]
    • I'm neutral on guidance. While (for example) Power~enwiki's suggestions below are reasonable, I'm not really sure how widespread a problem this is or why sidebars are somehow the problem. It seems like the issue is "don't clutter the upper right corner of the page with a bunch of floating content", and that's a problem with images, infoboxes, and sidebars, not just sidebars. — Wug·a·po·des​ 04:50, 8 November 2020 (UTC)[reply]
  • Support as guidance there are a lot of very bad navboxes, but enough good ones that a full-on ban isn't justified. Discouraging them when an infobox/photo is present is worthwhile; discouraging (or prohibiting) having 3 navboxes at the top of articles would also be good. Some limit on the number of links in a navbox would also be good, but that's probably out-of-scope for this RFC. power~enwiki (π, ν) 03:15, 8 November 2020 (UTC)[reply]
  • Support ban. We know from various reader research studies that 1) the top of a page gets much more attention than the rest of the article, 2) in articles with a TOC and an infobox, readers tend to look first at those two elements first (as found in eyetracking experiments), and they are also strongly drawn to images. So we can assume that in articles where there is a sidebar navbox on top instead (frequently containing a prominent image as well), it will also be one of the very first things that enters the reader's mind after opening the page. In other words, this off-topic information crowds out the more relevant information that is directly about the topic that the reader came for, and is thus detrimental to the reading experience. The bottom of the article is a much more suitable place to provide suggestions about related articles, after the reader had a chance to focus on the present article and decide whether they got enough information out of it. Regards, HaeB (talk) 16:04, 10 November 2020 (UTC)[reply]
  • Weak oppose a ban, after some flip-flopping. I would like to see sidebars used sparingly and only on topics that meet a "super-defining" criterion: the sidebar topic should be the unique primary subject area under which the article scope falls. For instance, on Anti-Catholicism this would be "Persecutions of the Catholic Church". Plenty of SandyGeorgia's list are good examples of cases which cause issues, but I believe these could be argued against on a case-by-case basis, as it would cause too much collateral damage to see all sidebars removed. Phonetics is a good exception. There are dryer, more concept-based subject areas where sidebars can be useful, such as Social democracy/{{social democracy sidebar}}. These are not well-suited to images or infoboxes, and I believe it's good to have something visual on the right-hand side.
    I share HaeB's concerns that we are sometimes leaving readers with impressions of marginal facets of a topic, but I believe the solution is to make sidebars more defining and more sparingly used, not to deprecate them fully. I also support only using sidebars on articles without infoboxes or lead images, and only then if there is reason to beyond "this page is linked in the sidebar" (but this is often current practice). One thing that we could improve at is to much more substantially limit the number of articles linked in a sidebar (we're better, but not perfect, with doing this for navboxes at the bottom). As this comment might be hard to categorise in terms of the ideas posed above, I'll tell the closer that I am weakly in support of guidance to avoid sidebars where possible. — Bilorv (talk) 02:34, 16 November 2020 (UTC)[reply]
    • I also support only using sidebars...if there is reason to beyond "this page is linked in the sidebar" (but this is often current practice). I strongly agree with this, and it's one of my pet peeves. The practice of requiring two-way navigation with sidebars is probably why we have the issues you and others raise. Browsers have a back button. — Wug·a·po·des​ 20:58, 19 November 2020 (UTC)[reply]
  • Oppose both on articles I edit, and articles I read, I've found quite useful sidebars. I think the harms from a blanket ban are likely to be outweighed by the benefits to readers of having the sidebars. --Tom (LT) (talk) 02:41, 16 November 2020 (UTC)[reply]
  • Oppose per Wugapodes. There are a lot of templates that mobile users can't see, so therefore the justification that users can't see such sidebars I believe is not a valid justification. Perhaps we should also get rid of {{tmbox}} while we're at it. Sidebars are also useful as navigational aids, perhaps more useful than navboxes given sidebars will more easily be noticed. Sidebars are also useful for articles without an infobox/lead image. P,TO 19104 (talk) (contribs) 22:30, 16 November 2020 (UTC)[reply]
  • Oppose. These are useful for navigation, banning them would probably make some articles worse, and add unnecessary instruction creep. If they get too cluttered, just remove some of them. Danski454 (talk) 22:33, 17 November 2020 (UTC)[reply]
  • Oppose Echoing the above sentiments that this thing is better off looked at page-by-page. A blanket ban and the prosposal smells like WP:IDONTLIKEIT, just because you don't like it doesn't mean it can't be useful.No need to kill of everything in one go. Swordman97 talk to me 09:42, 22 November 2020 (UTC)[reply]
To the contrary, the proposal contains a well-argued rationale listing several specific arguments, as do many of the support !votes. It's rather !votes like Swordman97's own "echoing" of "sentiments" which fail to engage with such arguments and carry a strong smell of WP:ILIKEIT. Per WP:CRFC, less weight should be given to such comments when closing this RfC. Regard, HaeB (talk) 10:55, 23 November 2020 (UTC)[reply]

Close

I saw this discussion at WP:ANRFC and I assess that there is a consensus to discourage the use of sidebars, especially when other elements, such as images or infoboxes are present in the lead. The question then is what text should be added to the guideline, which wasn't discussed much. The current sidebar section says:

Sidebars are a collection of links used in multiple related articles to facilitate navigation between those articles. Sidebars are sometimes placed in the lead, especially when no infobox is present. If an infobox is present, the navigation sidebar may be moved to either the top or bottom of any other section in the article.

From my reading something like the following seems to be desired.

Sidebars are a collection of links used in multiple related articles to facilitate navigation between those articles. Sidebars may be placed in the lead, but its utility should be considered before doing so. If an infobox or image is present in the lead, a sidebar should not be placed there, instead it can be placed at the top or bottom of any other section in the article or omitted entirely. In general, horizontal footer navboxes are preferred to sidebars.

If there aren't any major complaints about this proposed wording, I plan to formally close the discussion and implement the change to MOS:LEAD and WP:SIDEBAR. --Trialpears (talk) 14:35, 5 November 2020 (UTC)[reply]

SG has just listed this at T:CENT. Given the prevalence of these things I think it's worth a period of centralised discussion advertisement before closure, to see if any more comments spring in. Btw, if these end up at TfD there's nothing stopping people from just opposing each outright, though some formal summary of the discussion here of what people felt is/is not a valid reason to have them would help closers assigning more/less weight for deletion. ProcrastinatingReader (talk) 15:46, 6 November 2020 (UTC)[reply]
Trialpears, this looks mostly good. The one tweak I'd make is to change If an infobox or image is present in the lead, a sidebar should not be placed there to If an infobox or image is present in the lead, a sidebar should generally not be placed there. I can think of exceptions where having both might make sense (for instance, at contra dance, the sidebar is extremely short and fits perfectly well alongside the video), and we don't want to hamstring ourselves for those situations. Agreed with Procrastinating Reader that we should wait a bit before closing now that this is at CENT. {{u|Sdkb}} talk 17:26, 6 November 2020 (UTC)[reply]
Disagree, contra dance is precisely the kind of clutter this RFC seeks to avoid. The first thing readers encounter is a navigational template ?! And to terms that should simply be linked in the article. Where does that logic end? How much clutter do we need in leads that is only replacing wikilinks and navigational templates at the bottom of articles? SandyGeorgia (Talk) 17:33, 6 November 2020 (UTC)[reply]
Also disagree. A sidebar with only two items isn't worth having anyway. The two links could and should be worked into the (far too short) lead. Johnbod (talk) 17:39, 6 November 2020 (UTC)[reply]
Ok with the User:ProcrastinatingReader version, or further discussion. Johnbod (talk) 17:39, 6 November 2020 (UTC)[reply]
If sidebars are needed, they should always go to the bottom, as horizontal footer navboxes, so readers would know where to find them. But the fact that they are shown only to desktop users proves them at most half-necessary. So if a sidebar is about, say, Electromagnetism, the lede should point to Electromagnetism where whatever is in the sidebar should be listed, wikilinked and put in context. The recommendation proposed by Trialpears is too weak. Ponor (talk) 17:32, 10 November 2020 (UTC)[reply]
Nothing should be inferred from the layout of the mobile version because there was no discussion of it, and no consensus for it. The MOS does not apply to the mobile version. Hawkeye7 (discuss) 18:36, 10 November 2020 (UTC)[reply]
@Hawkeye7: All I am saying is: were it important, it would be shown everywhere. That's line #2 of Jorge Stolfi's initial post. But let's say all this is irrelevant: sidebars are growing bigger and bigger, pushing on-topic material out of their way (yes, talking of you, Electromagnetism), and should not be in the lead. Ponor (talk) 19:10, 10 November 2020 (UTC)[reply]
I don't see consensus for Sidebars may be placed in the lead. Even many of the "oppose" !votes don't seem to endorse the MOS providing such an explicit permission. Regards, HaeB (talk) 19:20, 10 November 2020 (UTC)[reply]
Hi, I just saw this and was planning on closing it but I see that Trialpears has begun work on a closing statement. I think this has been up at CENT long enough that a closure is not inappropriate, especially considering this was opened in mid-August, over three months ago. Trialpears, let me know if you still plan on closing this discussion. Please note that the discussion has shifted somewhat from the time that you posted your proposed closure statement, so it's worth taking into account any changes that might be appropriate in the closing statement. Best, KevinL (aka L235 · t · c) 09:22, 28 November 2020 (UTC)[reply]
L235, I do not plan on closing it anymore because I do not feel a nac would be appropriate anymore. Feel free to close! --Trialpears (talk) 09:27, 28 November 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Help?

An editor is deleting material from a lede, on his understanding that since it is a BLP, it should not contain any negative information in the lede. The related talk page discussion is here. Can someone take a look? Thanks. --2604:2000:E010:1100:3CC4:95F3:F526:24C0 (talk) 08:24, 6 October 2020 (UTC)[reply]

Use of the lead section in article translation

Hi, the following sentence has been removed as 'misplaced':[8]

'This section also gets most frequently translated and included in non-English Wikipedias.'

@Flyer22 Frozen: and other editors: I'd like to provide my rationale for including this sentence.

The lead section is due to time constraints often the only section that gets translated when translating articles to other Wikipedias. The sentence contributes to the understanding of the lead section from this viewpoint and as such provides another reason to structuring it as a short article summary and with a balanced point of view. I find this reason important enough to include the sentence in the guideline, specifically in the paragraph that provides the reasons why the lead section should be "written in a clear, accessible style with a neutral point of view". For this reason, I don't consider it misplaced there.

I appreciate any comment on this issue. -TadejM my talk 22:35, 26 October 2020 (UTC)[reply]

I don't think that belongs in the introduction, at least not in its previous form. If not covered lower, it especially doesn't belong in the introduction. All of that is why I reverted.
Let's wait and see what others state...if they state anything. Flyer22 Frozen (talk) 23:30, 26 October 2020 (UTC)[reply]
Hi, Flyer22 Frozen. Thanks for your comment. To move on here, I would appreciate if you provided the rationale (why don't you consider this sentence to belong in the intro). What form would you consider suitable? --TadejM my talk 10:28, 27 October 2020 (UTC)[reply]
I already gave a rationale. I stated that it's misplaced, especially if not covered lower in the guideline. Why should it be in the introduction if it's covered lower in the guideline? And either way, it doesn't fit where you originally placed it or where you moved it. Flyer22 Frozen (talk) 20:27, 28 October 2020 (UTC)[reply]
Dear Flyer22 Frozen, you're simply repeating what you stated in the beginning (that's it's misplaced, especially if not covered lower), without providing a clear explanation why you think so. I'll ask for a third opinion as I consider this discussion to have come to a standstill. --TadejM my talk 11:16, 1 November 2020 (UTC)[reply]
The above reasoning by me is my rationale. And I feel that I've been clear. Flyer22 Frozen (talk) 02:28, 6 November 2020 (UTC)[reply]

3O Response: I don't think this is worth adding here. Less is more. It already says what style to use, i.e., clear, accessible, etc. Adding the sentence about being translated doesn't really strengthen that guidance. Just because it is more likely to get translated doesn't make the policy more important. It's already important and should be done for its own sake. In contrast if you were to suggest that because it is likely to be translated you should avoid idiosyncratic regional vernacular idioms or some such, then that might make sense. As written, this sentence perhaps adds a little weight, but not much. If someone doesn't know enough to make a lead clear, accessible, etc., then telling them it might be more likely to get translated won't tip the balance and convince them to take the guidance more seriously. Since it doesn't add much, leave it out. Less is more. Coastside (talk) 08:00, 8 November 2020 (UTC)[reply]


RfC: MOS:LEADSENTENCE in "History of X" articles

What does the ideal first sentence of "History of X" articles look like?

MOS:LEADSENTENCE requires a statement of "what, or who, the subject is", which is not easy to apply to these articles. Across the project it is interpreted in different ways, such as:

  1. Stating how broad the history is (e.g. History of Slavery, History of saffron)
  2. Stating when the history started (e.g. History of the United States, History of Baltimore City College)
  3. Stating what X is (e.g. History of Gillingham F.C. or History of the British farthing)
  4. Stating X's notability (e.g. History of the Wales national football team (1876–1976) or History of Israel)

Onceinawhile (talk) 15:19, 27 October 2020 (UTC)[reply]

  • Comment: This RfC is unnecessary. Each example gives a statement of "what, or who, the subject is". The MOS doesn't need to clarify more specifically how to do so. This is just WP:CREEP. The fact that each option has a Featured Article as an example shows that this simply is not a problem.  Bait30  Talk 2 me pls? 22:12, 3 November 2020 (UTC)[reply]
@Bait30: thanks. The problem is that each example does not gives a statement of "what, or who, the subject is". That would mean a tautological sentence along the lines of "This article covers the history of X." or "The History of X refers to the past events in X", which we try to avoid. Instead we randomly settle on some of the options above. WP:CREEP is not relevant here as we are not talking about an instruction, just some soft advice. Onceinawhile (talk) 22:30, 3 November 2020 (UTC)[reply]
Soft advice belongs in essays, not in the MOS. We do not need to prescribe robotic madlib templates for our article content. —David Eppstein (talk) 22:51, 3 November 2020 (UTC)[reply]
Hi David Eppstein, I agree, we should not be prescribing anything. Just soft advice. I did not suggest in the original post that we should put advice directly in the MOS. Or even in an essay. It could just sit here on a talk page RFC discussion. Rather than being negative, perhaps you could share your view on the actual question? That would be appreciated. Onceinawhile (talk) 23:22, 3 November 2020 (UTC)[reply]
The fact that these articles have a variety of styles for the opening sentences and are all WP:FA suggests that there is no need for any sort of clarification or advice needed and that "randomly settling on some of the options above" is perfectly acceptable. If there is any issue in any article (for example, if the lead sentence in a hypothetical "History of ballpoint pens" article began with "Ballpoint pens have history."), then editors can WP:BRD and come to a consensus on the talk page.  Bait30  Talk 2 me pls? 02:34, 4 November 2020 (UTC)[reply]
  • Not really a suitable issue for an Rfc, as others have said. I don't see it would be a good idea to mandate, or even give soft advice, for any general contents for a first sentence. The best form will vary. Some subjects are obscure and need more basic introduction, & others don't. Johnbod (talk) 17:44, 6 November 2020 (UTC)[reply]

Break

@David Eppstein, Bait30, and Johnbod: honestly guys I find these comments very disappointing. This is a good faith effort to think through something that has been unclear for at least 15 years, and you are rushing to shut it down without engaging.

On reflection, perhaps my question was too narrowly worded, and perhaps putting it as an RfC seemed to serve only to raise the temperature rather than encourage outsiders to comment as I had hoped. I don't understand it, but here we are.

If I haven't lost you already, can I try this a different way? Perhaps my real point is that I have been here for more than a decade and I am still entirely unclear on how the first sentence of an article with a "descriptive title" is supposed to be. Currently this page says: "The first sentence should tell the nonspecialist reader what, or who, the subject is... If possible, the page title should be the subject of the first sentence. However, if the article title is merely descriptive... the title does not need to appear verbatim in the main text."

...So the page explicitly points to the scenario where the "article title is merely descriptive", but it does not give any sense of what to do with the first sentence in that situation. I put all these WP:FAs as examples, and Bait30 did the same, to point out the situation in the best areas of our encyclopaedia. But if you think that is all over the place, try looking at the same but in lower quality articles.

Onceinawhile (talk) 23:40, 6 November 2020 (UTC)[reply]

Your question has the same character as asking what format the first sentence of a novel should take. It is not a situation where boilerplate is appropriate. The guidance you quote, asking for a description of the topic and warning against trying to shoehorn the exact title into the sentence, seems adequate to me. —David Eppstein (talk) 23:45, 6 November 2020 (UTC)[reply]
But we are not writing novels. We are supposed to have some structure.
Do you consider there should be any difference between the first sentence of a subject-article subsection (e.g. United States#History) and the first sentence of a descriptive article lead (History of the United States)? Personally I do – I think all articles should have an overview in the first sentence, not least because that is what shows up in search engines.
Onceinawhile (talk) 00:14, 7 November 2020 (UTC)[reply]
Maybe it would help if you said which of the many examples now given above you don't like, and why? Johnbod (talk) 04:25, 7 November 2020 (UTC)[reply]
Hi Johnbod, the ones I think are plain wrong are examples 3 and 4 in the list at the top of this thread. They are not giving an overview of the History of X, but rather telling us what X is or what is notable about X. I believe this is because the guidance here is confusing: "The first sentence should tell the nonspecialist reader what, or who, the subject is" is ambiguous when "the article title is merely descriptive" – some editors clearly consider that by subject we mean X rather than History of X. Onceinawhile (talk) 07:30, 7 November 2020 (UTC)[reply]
I don't much like History of Israel, but the others seem fine - the first sentence briefly defines the subject, then it's straight into the history. Really it's usually better to look at paragraphs rather than sentences. Johnbod (talk) 16:39, 7 November 2020 (UTC)[reply]
So why have a manual of style at all? Onceinawhile (talk) 14:32, 7 November 2020 (UTC)[reply]

Single-sentence "paragraphs"

Recently I have increasingly noticed articles which begin with a single-sentence "paragraph", and I have noticed editors specifically separating out the opening sentence from the rest of the paragraph (eg this). I think this is really poor style, and nothing in the current MOS supports it. Indeed, MOS:PARA says "The number of single-sentence paragraphs should be minimized, since they can inhibit the flow of the text", while WP:PARAGRAPH says "One-sentence paragraphs are unusually emphatic, and should be used sparingly." Should some text be added to MOS:BEGIN to address this? I'd suggest something like:

The first paragraph should define or identify the topic with a neutral point of view, but without being too specific. It should establish the context in which the topic is being considered by supplying the set of circumstances or facts that surround it. If appropriate, it should give the location and time. It should also establish the boundaries of the topic; for example, the lead for the article List of environmental issues succinctly states that the list covers "harmful aspects of human activity on the biophysical environment". The first paragraph should indeed be a paragraph; do not start an article with an isolated sentence.

46.208.152.69 (talk) —Preceding undated comment added 12:05, 9 November 2020 (UTC)[reply]

MOS:PARAGRAPHS discourages single-sentence paragraphs. And that's what I point to when arguing against single-sentence paragraphs. But using them is sometimes unavoidable. Flyer22 Frozen (talk) 19:33, 9 November 2020 (UTC)[reply]

Discussion at Module talk:Lang-zh § MOS compliance

 You are invited to join the discussion at Module talk:Lang-zh § MOS compliance. — Goszei (talk) 03:02, 23 November 2020 (UTC)Template:Z48[reply]

I posted this back in May and it was abandoned, so I thought I would post it here to get some fresh eyes on it.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Lead_section&oldid=991238102"