Template talk:Navbox

In template Template:Bilasuvar District I disambiguated one item. I know ity usually takes some time to propagate the backlinks, it usually takes a couple hours. But in this case nearly 24h passed, and still wrong "pages that link to". When I click on the chanhed item in template, [Ashim, Azerbaijan|Ashim] it opens correct page, but this page is not linked from other artiicles tgaht contain this template. Any suggestions? --Altenmann >talk 20:33, 22 December 2025 (UTC)[reply]

Patience is the best answer. The job queue will get to it in somewhere between a few hours and a few days, usually. If you are impatient, you can null-edit the affected pages. I have done so for you. – Jonesey95 (talk) 15:55, 24 December 2025 (UTC)[reply]

Mobile view wanted

Hello, when I asked earlier on the help desk (Special:PermaLink/1342484613#Navigation template doesn't show up in mobile view) about the fact that navboxes don't show up in the mobile view, I learned from another Wikimedian that this is by design. He also hinted at the possibility of using personal CSS to enable it. So far, I found mentions of why that design was made in a way to be hidden on mobile views in Template talk:Navbox/Archive 18#Not visible in App from 2015, Template talk:Navbox/Archive 22#Navbox not displaying on mobile sites from 2018 and phab:T124168 from 2024, summarising, it's apparently due to the intent of reducing the amount of transmitted data and possibly also issues with screen sizes. Well, wouldn't it be time to reconsider it, now, in 2026?
Usual mobile devices now have a screen resolution equal or better to full HD and even in Germany with its comparatively high priced mobile data transfers, a few KB of additional HTML per page would be imperceptible within the common data flat rates of several GB per month (the tracking ad pestilence is much more data hungry). Anyway, I'd be glad if at least somebody could tell me what CSS is needed to enable these navboxes for me in mobile view! I didn't see any instruction for it either in the TP archive nor on Phabricator. Regards, Grand-Duc (talk) 06:25, 9 March 2026 (UTC) (PS. Please ping me in any answer as I'm actually more of a regular on Commons and DE-WP)[reply]

There is no CSS which enables them in mobile view. As noted, the intent is to reduce the HTML load, and it happens the way this is done is to remove the HTML entirely from the page. (Which is realistically the only way such a thing could be implemented.)

Remember that you, as a contributor from a developed country, do not have the same restrictions on hardware and data infrastructure as people in developing countries. Izno (talk) 16:24, 9 March 2026 (UTC)[reply]

And it turns out it is not a "few" KBs, the price is substantial for a construct which has little to no benefit for the vast majority of mobile readers. Izno (talk) 16:25, 9 March 2026 (UTC)[reply]

My "developed country" is, in fact, in my opinion somewhat behind when speaking about mobile internet. Our local right-wing parties already stoke ressentiment against refugees also because they usually own quite high-end smartphones - but that's disregarding that we autochthones have access to landlines, desktop computers and public authority offices, whereas immigrants do rely upon their device for everything: communicating, banking, organising everyday life, etc. So, it's no wonder that they have a single device fit for holding an entire life.

Additionally, navboxes are things that would likely benefit readers much more than editors: in a book, we're turning pages, on Wikipedia, we're clicking navigation links. For casually browsing, reading and learning, navboxes are important, I'd say. Regards, Grand-Duc (talk) 10:58, 31 March 2026 (UTC)[reply]

On my Android tablet in Chrome I can turn on desktop view (bottom of screen). That makes navboxes visible though I am glad they are at the end of articles where I can easily ignore them. Thincat (talk) 11:06, 31 March 2026 (UTC)[reply]

The importance of navboxes as maps to their Wikipedia topics remains a key component feature of original Wikipedia. Mobile readers are missing these maps, and one present-time solution may be to add a line on each mobile view that the maps exist and can be viewed on desktop/laptops. Randy Kryn (talk) 11:11, 31 March 2026 (UTC)[reply]

@Thincat: I certainly know about the mobile/desktop view switch. Actually, the desktop view of the watchlist (for me: on Commons) is a bit more comfortable, as it condenses category changes (e.g. for c:Category:Media requiring renaming, where you have an item for each change in "mobile", but a summary like "14:34 / Category:Media requiring renaming 52 / changes" in "desktop"). On the other hand, the font size and page layout for an article body makes for a more comfortable reading in the mobile view. I still maintain that the best of both worlds would be having the navboxes in the mobile view, too. Regards, Grand-Duc (talk) 12:39, 31 March 2026 (UTC)[reply]

@Randy Kryn: Here's an idea. We have the link as you suggested, but it takes the reader to the navbox template, exactly as if a normal user had clicked the "v" link of the "v-t-e" group. The navbox in the template either has (a) an additional class inside <noinclude>...</noinclude> which makes the navbox visible for mobile users, or it has (b) modified behaviour in Module:Navbox/styles.css for the existing navbox class so that it's visible on the template page, but still not in articles. --Redrose64 🌹 (talk) 15:43, 1 April 2026 (UTC)[reply]

I don't know the ideal solution, but I do know that the current arrangement (navboxes are simply ignored completely on mobile, invisible, non-navigable, not even affecting SEO) is plainly a mistake. For one thing, all the thought that has gone into making Wikipedia navigable through navboxes is lost to as much as 70% of the audience. That navigability goes with the indexing effect of a good navbox: here is what we have to say on this whole topic, and here is how this article fits in. In addition, many articles (hundreds of thousands, probably) were written assuming that readers could navigate using navbox links; many still certainly do not contain all the links provided in the navboxes that desktop readers can see and use. Could we please have something practical for mobile use? A single link to the template would be much better than nothing. Another view would be that mobiles today have way more memory, way faster processors, and way quicker access to the Internet than in 2016 (1000 times more in each case, maybe?), and that the old decision urgently needs revisiting. Heck, users could even be given a switch to turn navboxes on (default) or off (if their gadget really is s-l-o-o-o-w). Time to think again, please. Chiswick Chap (talk) 13:06, 26 May 2026 (UTC)[reply]

Bug in anchors for navboxes with markup in title

There's a issue at Template talk:Authority control § Odd HTML anchor due to Module:Navbox using the navbox title to produce anchors even when the title has complex markup. Perhaps Module:Navbox needs an optional anchor parameter to use instead of the navbox title? Daask (talk) 19:32, 23 April 2026 (UTC)[reply]

It seems this was first added in 2016 — Martin (MSGJ · talk) 20:57, 23 April 2026 (UTC)[reply]

This is now implemented in the sandbox and tested at Template:Navbox/testcases#Custom id attribute — Martin (MSGJ · talk) 11:17, 21 May 2026 (UTC)[reply]

Kind of meh on having another parameter possible. (Not per se opposed today since this one is not going to cause much in the way of heartburn but not really supportive since it's another potential dimension for incorrect use.)

I've previously mused about just supporting authority control directly in some ways so as to limit the general need for Stuff Like This. Would make this module slightly impure. Izno (talk) 17:14, 21 May 2026 (UTC)[reply]

I guess it depends on whether any other templates are likely to need this "id" argument. If not, then we can indeed hard-code a variant for authority control — Martin (MSGJ · talk) 21:20, 21 May 2026 (UTC)[reply]

Unless you have further thoughts on alternative methods, I will implement this today — Martin (MSGJ · talk) 10:25, 1 June 2026 (UTC)[reply]

I mean, my personal POV is that people.... shouldn't make "complex" titles. Izno (talk) 16:22, 1 June 2026 (UTC)[reply]

How else can we produce the pencil icon in the authority control template? — Martin (MSGJ · talk) 17:08, 1 June 2026 (UTC)[reply]

This is the correct way to do so.

I guess ultimately I'm stuck at "the purpose of the ID is to be targeted by aria-labelledby" and not anything else. Is this broken from that perspective? If not, then I don't think a change is ultimately needed here. One should not be linking to this ID because it is not always present (today at least, see mobile), and in general I would see as generally bad to point a user at a navbox containing authority control: they'll either find it or they won't (on desktop). Izno (talk) 21:56, 1 June 2026 (UTC)[reply]

The change is also incomplete. The ID is solely there to support aria-labelledby (people should not be linking to it). You've now added an ID parameter which changes the ID but you have not corrected the target of the aria-labelledby. Izno (talk) 21:55, 1 June 2026 (UTC)[reply]