Wikipedia talk:Categories, lists, and navigation templates

I recently came across the advice here that Every article that transcludes a given navbox should normally also be included as a link in the navbox. The way I've thought about navboxes is that they're part of an article and therefore subject to the same DUE considerations as the rest of it, and that this can mean that sometimes it makes sense for niche topics to have navboxes that don't link back. For instance, for a professor or administrator who spent their entire career at a university, it might make sense to have the navbox for the university at their article, but it wouldn't make sense to add them to that navbox.

What do others think of this guidance? Should we loosen it? {{u|Sdkb}} ^talk 18:41, 7 August 2023 (UTC)[reply]

In my view the advice or guideline as you've quoted it is sort of backwards, or sideways maybe. It should say something like Only include the navbox on articles that are linked to by the navbox. In general I think it's good to follow this guideline. The purpose of a navbox is to provide a handy way to click through to articles on a related topic. If you include it in an article that it doesn't link to, then when you click away from that article, you can't click back using the navbox. That said, it might be best to allow exceptions in some circumstances. — Mudwater ^(Talk) 00:58, 8 August 2023 (UTC)[reply]

I'm with you on that! --woodensuperman 11:11, 22 August 2023 (UTC)[reply]

• Some exceptions should apply, especially for items on lists included in the navbox. For instance, I once spent days adding {{
  U.S. National Zoo I'd appreciate the logical assortment of closely associated pages on the navbox. Randy Kryn (talk) 05:22, 8 August 2023 (UTC)[reply
  ]
• Generally the advice is simply bad.....academic type topics ignore this and consider it harmful. Last thing we want is vital type articles to look like pop culture articles Elizabeth Taylor#External links. United States is linked in 27 templates....that we simply dont spam on that page. Moxy- 12:05, 22 August 2023 (UTC)[reply]

  I think that these award navboxes are an issue, and they do fail on the fact that the articles do not generally meet point 3 of the guideline. Maybe awards navboxes are okay for the films, etc, but not for the individuals.

  Personally, I think a tightening up of the

  WP:BIDIRECTIONAL guideline is in order and links should be removed from the navbox if the navbox is not suitable for transclusion on the page. Take your United States example. Why should it be included in the {{Houston}} navbox? --woodensuperman 12:44, 22 August 2023 (UTC)[reply

  ]

'United States' should not be included in the 'Houston' navbox. Doesn't mean that a full purge of navboxes should occur on Wikipedia. Randy Kryn (talk) 01:34, 8 December 2023 (UTC)[reply]

This guideline should at least state that sidebars are excluded from

WP:BIDIRECTIONAL. As commonly interpreted, it encourages sidebar bloat, with excessive articles added to sidebars to avoid their removal from those articles. The flaw in that logic is that while, say, Islamophobia might be a major element of an article (making the sidebar due), the article may be too minor to belong in the sidebar. Sidebars also have less space for links than navboxes at the bottom. And the need to be able to "click back" is minimal because all browsers have back buttons. DFlhb (talk) 23:55, 7 December 2023 (UTC)[reply

]

• Given the discussion above, it seems that the present language (Every article that transcludes a given navbox should normally also be included as a link in the navbox, so that the navigation is bidirectional.) is not supported by consensus. How does this sound for somewhat looser language?

  Most articles that transclude a given navbox should be included as a link in the navbox, enabling bidirectional navigation, but exceptions may be made when inclusion would be undue.

  {{u|Sdkb}} ^talk 04:44, 8 December 2023 (UTC)[reply]

  A few exceptions does not necessarily mean that the existing "should normally" is incorrect. And anyways,

  WP:IAR, subject to consensus, is always an option for anything. —Bagumba (talk) 10:17, 8 December 2023 (UTC)[reply

  ]

  I'd be in favor of a merged version that puts back in "normally", and keeps the new UNDUE clarification. I think that'll solve the issue without breaking anything.  — SMcCandlish ☏ ¢ 😼  10:38, 8 December 2023 (UTC)[reply]

   Done here. Sdkb ^talk 07:05, 29 February 2024 (UTC)[reply]

  I've undid the change for now. It seems there was still consensus that the includer should still be in the navbox. There was perhaps some leeway for an item in the inbox to not actually have to transclude it per UNDUE. I suggest proposing the modified wording here, and discussing further. Also notifying earlier participants Mudwater, Woodensuperman, Randy Kryn, Moxy, DFlhb and SMcCandlish. Thanks. —Bagumba (talk) 08:14, 29 February 2024 (UTC)[reply]

  As I've said before, I think the navbox rules should be tightened, not loosened. If it's causing an

  WP:UNDUE issue, then we have to question whether the presence of the link in the navbox is the problem. --woodensuperman 09:50, 29 February 2024 (UTC)[reply

  ]

  Should be worded like

  MOS:INFOBOXUSE. Waste of time for editors to deal with having to explain why we dont need 12 nav templates in one articles. Just because someone add a link to a nav template .... should not imply it has to be used everywhere. Moxy- 13:00, 29 February 2024 (UTC)[reply

  ]

  Or we should remove the link from navbox. My take is, if it's not appropriate to put the navbox on the page, the link shouldn't be in the navbox. --woodensuperman 13:35, 29 February 2024 (UTC)[reply]

  The problem is content editors dont want to waste time having to debate what links to include in templates that 65%+ (mobile viewers) dont even see, Or waste time debating the need for a template in the first place ..again for a nav aid that the majorty dont even see. Our example at Elizabeth Taylor#External links as seen blelow is overwhelming on any page.Moxy- 13:41, 29 February 2024 (UTC)[reply]