This template (like all templates) is within the scope of WikiProject Templates, a group dedicated to improving the maintenance of Wikipedia's templates. This particular template is especially important to the project because it is used in the maintenance of other templates. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TemplatesWikipedia:WikiProject TemplatesTemplate:WikiProject TemplatesTemplates
I’m having an issue with the navbox that’s quite frustrating. I’m unsure how to fix it, or if it’s an unresolved problem with the template.
The issue occurs when a page redirection is created. When you go to the redirected article, the title doesn’t appear in bold black in the navbox. You have to manually update the name to the new redirected title in the navbox for it to display correctly. Is there a way to resolve this? Perhaps a bot task or something similar? Thank you Riad Salih (talk) 12:18, 23 June 2025 (UTC)[reply]
This is not a problem with the navbox template. This appears to be basic rendering behavior in the Wikimedia software. You can submit a bug via Phabricator if you want. Until the behavior changes, the only way to make the link render in bold is to change the link to the actual title of the target article, like this. – Jonesey95 (talk) 18:52, 23 June 2025 (UTC)[reply]
I think it would be difficult to get consensus for a bot task. Some people are very particular about what links are presented.
Yes, this is something you have to fix when someone moves a page. I have some CSS that will illuminate redirects in navboxes. Izno (talk) 20:06, 23 June 2025 (UTC)[reply]
There seems to be a bug where autocollapse collapses the Navbox, even when (seemingly) no other collapsible elements are present on the page. Examples include: Amphibian, Aldous Huxley, Achilles.
Huwiki uses identical instances of the Navbox module and the autocollapse script. This bug was first noticed in the Algona (Iowa) article, where the removal of the Infobox makes the Navbox open. Is this a known issue? Pinging @TheDJ as the maintainer of the autocollapse script. ~ Boro (talk) 01:07, 6 August 2025 (UTC)[reply]
Authority control and similar templates are navboxes and have the relevant classes emitted. That even is relevant at hu. Izno (talk) 03:12, 6 August 2025 (UTC)[reply]
Is this the intended behavior though? With the rise of Authority control and other collapsible elements, even singular Navboxes will close off and can't fulfill their majestic purpose of showing related content to readers at a glance. ~ Boro (talk) 07:48, 6 August 2025 (UTC)[reply]
My first impression is to agree with Boro. Auth control doesn't *seem* like a navbox, regardless of its actual construction and inclusion (or not) as a navbox that could cause another navbox to autocollapse. Maybe auth should be under a different class? Mathglot (talk) 08:25, 6 August 2025 (UTC)[reply]
Authority control has been present for as long as navboxes have and probably about as long as we've supported autocollapsing. That people have added it everywhere seems to be more an issue with that behavior (sometimes via bot) and less with the functioning of autocollapse.
This is not the case on huwiki. The local implementation of Authority control was introduced 5 years after the navbox, and to add to that, up until today [1] it hasn't been emitting the collapse classes. I understand that this might be irrelevant for this wiki and that we could easily modify our instance. My goal right now is to understand your (that is, enwiki's) considerations, since the templates are more widely used and tested here, so we can proceed based on that knowledge.
When huwiki introduced the navbox, the reality was that no other elements were using the collapse classes, and autocollapse only activated when there were two or more navboxes adjacent to each other. Even the name “autocollapse” implies that the navbox should normally be expanded and only collapse in certain situations. These should not include situations in which templates distant from the navbox affect its behavior. My main argument is that the autocollapse feature in this template should only consider other collapsible navboxes. It should not account for navboxes in a plain/off state, sidebars, infoboxes, or any other templates having a collapse class.
In short, the expected behavior is this: a lone navbox at the bottom of the page should always remain open.
It's a separate discussion (and should not be the current one) whether 2 navboxes should remain open, as that would expand the current definition of autocollapse. Currently, the clear loser in this situation is Authority control, which I expect is more often paired with another navbox than not. However, whether Authority control should be collapsed or not, is not the point of this thread. I hope this makes it clearer what I meant when I said this is a bug, without getting sidetracked. ~ Boro (talk) 21:05, 6 August 2025 (UTC)[reply]
Also, I'm curious: what would you say if, in addition to excluding plain/off states, collapsed states were excluded as well?" ~ Boro (talk) 21:16, 6 August 2025 (UTC)[reply]
@Dabao qian For number 1, I don't see any reason why |listN= parameters shouldn't be counted as long as they have a string value, but I'll look into it sooner. As for #2, argHash is always automatically calculated, so it's not supposed to be passed from the template to the module (unless I'm misunderstanding what you mean). --Ahecht (TALK PAGE)03:55, 2 September 2025 (UTC)[reply]
@Dabao qian Actually, looking into it further, the entire first try at calculating argHash in p.navbox is now unnecessary given that code was later added to calculate it in p._navbox. There's a version in the sandbox that eliminates that redundancy, which also means that |listN= is now counted correctly. Try it out, and I can sync the changes over to the main module at some point. --Ahecht (TALK PAGE)04:26, 2 September 2025 (UTC)[reply]
Offtopic: ... I was there for when this hash got added and somehow didn't remember it. Good to know at least one thing is off the list. It does appear to be working; Template:Warcraft universe's accessibility properties identify the navigation region as "Warcraft", which is the title of the navbox. Izno (talk) 16:32, 2 September 2025 (UTC)[reply]
ARIA role
To be honest, I'm kind of on the fence as to what the ARIA role should've been here @Izno. I was onboard with navigation, but I've been reading ARIA more and more, and from what I saw at Robert_Redford#Citations as an example, was waaay too many navigation elements. The banner/toolbar from Wikipedia has three already I think, if not more. The article has over 20 navboxes, which leads to so many high-level DOM navigation elements that clutter the heading lists made by Voiceover for example. I've looked at the other roles available [2], [3] as it's sufficiently important that with an ARIA label pointing to the heading as a baseline, which should be possible to be overriden by the user, but the heading should be wrapped in a span+ID, and the ID referred to by the element given role=navigation aria-labelledby=ID waddie96 ★ (talk)13:52, 19 September 2025 (UTC)[reply]
I'm unsure if it possibly matches this 'Disclosure' example from the newest ARIA Authoring Practices Guide draft, if it's enough "high-level top domain links" because it really isn't for the most part... or if it's something else like role=region being a bit plainer waddie96 ★ (talk)13:55, 19 September 2025 (UTC)[reply]
Rfc: Deprecation of the image and imageleft parameters
Icons should serve an encyclopedic purpose and not merely be decorative. They should provide additional useful information on the article subject, serve as visual cues that aid the reader's comprehension, or improve navigation. Icons should not be added only because they look good: one reader's harmless decoration may be another reader's distraction. An icon is purely decorative if it does not improve comprehension of the article subject and serves no navigational function. Where icons are used for layout purposes only, consider using bullet points as an alternative.
Documenting what, if any, WP:RFCBEFORE has taken place, would be appreciated. Also, this discussion though named an RFC does not have a {{rfc}} and I do not know if that is intentional. Izno (talk) 23:44, 21 September 2025 (UTC)[reply]
