Template talk:Navbox

Possible feature upgrade?

I was thinking about The Template Transclusion Check earlier today, and wondered if there was a way to enable (opt-in, of course) a tracking cat in the navbox directly to check if the page a template is transcluded on is included in the navbox? I feel like I've seen similar things before in other modules, but if it's not possible that's fine I guess.

For example, a navbox {{example}} does not link to Example but that article transcludes the template. I was thinking this might be useful for "squad" navboxes where the navbox links may change but the transclusions often do not get updated to match. Primefac (talk) 09:35, 24 August 2023 (UTC)

Are you looking for {{Check completeness of transclusions}}? Try it at {{Watford F.C. squad}}, for example. – Jonesey95 (talk) 12:33, 24 August 2023 (UTC)

No, I want it to be part of {{navbox}} itself. To give a specific example - at the moment {{Top British male singles tennis players}} is transcluded at Paul Jubb but he is not listed in the template; I would like the option to have the navbox populate a category to indicate that the template should be removed from Jubb's page (e.g. Category:Tennis player biography with unnecessary navbox or something equally specific). Primefac (talk) 12:47, 24 August 2023 (UTC)

This sounds like a job for a report. The "check completeness" tool lives on toolforge. I wonder if someone clever could set up a periodic report that ran a check on every template whose doc page transcludes {{Check completeness of transclusions}} and then listed "Transclusion but no link" items from those checks. – Jonesey95 (talk) 13:39, 24 August 2023 (UTC)

autocollapse vs. mw-collapsed

It seems this module adds the autocollapse class. autocollapse is defined in MediaWiki:Common.js. It's unclear to me why it doesn't add mw-collapsed instead which is part of MediaWiki?
Edit: just noticed this note in Common.js: "deprecated Since MediaWiki 1.20: Use class="mw-collapsible" instead which is supported in MediaWiki core. Shimmable since MediaWiki 1.32"
Edit2: I'm not reading right and I get it now. For reference: collapsible is deprecated in favor of mw-collapsible and collapsed is deprecated in favor of mw-collapsed. The function of autocollapse in common.js is specifically to collapse the element only if more than one collapse element exists on the page. So if a page has only one navbox and no other collapsible elements, the navbox will be uncollapsed by default. But if another navbox is added, both will be collapsed by default.
While I see why this can be desired, I think it's also rather confusing, making navboxes act differently depending on the presence of other elements on the page. — Alexis Jazz (talk or ping me) 20:27, 4 September 2023 (UTC)

FWIW, it's how they have worked for a long time. I'm not saying it's good or bad. – Jonesey95 (talk) 22:36, 4 September 2023 (UTC)

Jonesey95, I was testing some stuff and found a navbox to not collapse by default on one article, but collapse by default on another. I thought it was a bug or oversight in something I wrote, only to finally figure out what "autocollapse" actually does.
I suppose we could discuss whether navbox should use autocollapse or not. From what I understand, if an article has one navbox and one collapsible list is added somewhere in the infobox with the autocollapse class that'll also cause the navbox to autocollapse.
Having the navbox as the only collapsible item uncollapsed by default would sometimes make sense. But on a short stub it would look a bit silly. My thought is that editors would be best suited to decide on a per-article basis which (if any) navboxes should be uncollapsed by default. — Alexis Jazz (talk or ping me) 00:57, 5 September 2023 (UTC)

IMO the autocollapsing is a generally a good thing if more than one navbox is present. I wasn't aware that this behaviour is also influenced by other collapsible elements in the body, which are discouraged. I suppose we have to leave it to editors to decide whether overriding |state= is appropriate sometimes (e.g. having one navbox closely related to the the article's subject and several others only loosely related). -- Michael Bednarek (talk) 01:35, 5 September 2023 (UTC)

Alexis Jazz, if I understand your desire correctly: any navbox can be expanded in a given article by adding |state=expanded to its transclusion. You can see this in action at Wikidata#External links or U.S. state#External links. If it doesn't work for a given navbox template, the template's code might need a bit of adjustment; sometimes people delete the standard collapsing code. If you want or need a demo, link to an article and suggest a navbox to be expanded. – Jonesey95 (talk) 03:22, 5 September 2023 (UTC)

Jonesey95, thanks, I think I understand how it works. What mostly bothers me is that this template is essentially depending on the code in Common.js, which is kinda odd and makes it more confusing for any other project to import this template/module. It also confused me when I was testing navboxes on the mobile site where Common.js doesn't get loaded. I've resolved that issue though.
I think I'd personally support changing the default from "autocollapse" to "collapsed", but unless others feel the same I don't expect it to happen. — Alexis Jazz (talk or ping me) 03:47, 5 September 2023 (UTC)

We could of course just change this to be something like. If this is the main namespace, then if there is one navbox have it open, but if there is more than one navbox, collapse them all. and get rid of the entire old auto collapse behaviour. The one problem I see is that I'm not entirely sure where else auto collapse is used. —TheDJ (talk • contribs) 08:26, 27 September 2023 (UTC)

TheDJ, I'm guessing many editors use autocollapse because they confuse it with mw-collapsed, thinking it just means "always automatically collapse this". I only figured out what autocollapse means after analyzing Common.js. If I had no idea it's pretty much guaranteed a new editor has no clue either. (sure it's in the template documentation, but editors often learn by copying existing wikicode) Take a look at Geographic coordinate system: the navbox has the autocollapse state specifically set as a parameter and the navbox gets collapsed due to the presence of {{Geodesy}}. No way that was the intention of any editor. It was added by an IP editor in Geographic coordinate system (Diff ~675689024) btw. This is largely a running theme when looking at Special:Search/insource:autocollapse. My personal opinion is still that it would be clearer if state=collapsed was the default for navboxes and editors would have to set the parameter state=expanded where appropriate. But that's merely my 2 cents.
That being said, changing autocollapse to only react to navboxes would make its behavior a bit easier to understand, more logical and less likely to be triggered accidentally as it is on Geographic coordinate system. The end result on that article may or may not be desirable, but the presence of {{Geodesy}} has no bearing on that. — Alexis Jazz (talk or ping me) 15:47, 27 September 2023 (UTC)

@TheDJ the other notable location for autocollapse is Template:Sidebar with collapsible lists and probably that one's mother-template-by-time of Template:Collapsible list (which ends up in infoboxes). Izno (talk) 18:17, 7 October 2023 (UTC)

Rather late to the party, but I've added an anchor to the state documentation, with the appropriate redirect shortcut WP:AUTOCOLLAPSE, to hopefully help with future confusion. 「ディノ奴千？！」^{☎ Dinoguy1000} 01:09, 16 December 2023 (UTC)

Doesn't properly handle linebreaks at the start of a sublist

{{navbox
|group1=Foo
|list1=
* Lots of items...
* Numbers
** 1
** 2
}}

has (at least) 5 possible places to create a linebreak:

• Between
  Lots of items...
  and
  • Numbers (1 • 2)
  Y
• Between
  Lots of items... •
  and
  Numbers (1 • 2)
  Y
• Between
  Lots of items... • Numbers (1
  and
  • 2)
  Y
• Between
  Lots of items... • Numbers (1 •
  and
  2)
  Y
• Between
  Lots of items... • Numbers
  and
  (1 • 2)
  N

The last version is bad, because the context for the sublist is lost by the time the reader drags their eyes over to it. Nevertheless, navbox lines can (and do) break there.

{{hlist}} may suffer from the same problem (or even originate it). I think some clever CSS hackery can prevent a linebreak before the sublist, but I know neither how to do it, nor how to read/write Lua.

Thanks, Bernanke's Crossbow (talk) 15:22, 24 September 2023 (UTC)

Can you give an example of #5? -- Michael Bednarek (talk) 04:30, 25 September 2023 (UTC)

@Michael Bednarek: Groupings "Phosphorus" and "halo" in {{Functional groups}} (default skin, Firefox 117.0.1/Windows 11 build 22621.2283 on a 1920x1080 screen at 125% scale). Bernanke's Crossbow (talk) 03:08, 27 September 2023 (UTC)

That happens at any screen resolution and is how hlists are intended to work. I suspect the reason is to avoid unsolvable problems if the sublist itself is wider than the display window, which can easily happen in your example for Haloalkalenes. If you want to force, say, Phosphine and Phosphonium to stay together, you could avoid that behaviour of hlist and bind those two with *[[Organophosphine|Phosphine]] ([[Phosphonium]]). Other editors of that template might later be puzzled by that construct and restore standard syntax. Good luck. -- Michael Bednarek (talk) 04:59, 27 September 2023 (UTC)

Multiple languages of parameters

Helloo! I want to ask one question about parameters which appear in Navbox and written in Module:Navbox/configuration. I wanted to localise it to KazWiki, and I did it, it's work with kazakh parameters, but i want to add English parameters too, because we have templates which use english parameters also. I tried do, but it's not work, you can watch it here. --Amangeldi Mukhamejan (talk) 09:52, 8 October 2023 (UTC)

@Amangeldi Mukhamejan: What I did on norwegian wikipedia was to just use the module directly in no:Template:Navbox, but create a new translated template no:Template:Navboks where I used both english and norwegian parameters. This way you can use no:Template:Navboks with both norwegian and english parameters, and it will also be very easy when you need to update the module. If you do the same with kk:Template:Шолғы you can use english and kazakh parameters. Tholme (talk) 17:51, 5 December 2023 (UTC)

#invoke:Navbox

The two navboxes at Family tree of Japanese monarchs are not displaying correctly, and are just showing up as anchor links to #invoke:Navbox --Yodin^T 13:32, 13 October 2023 (UTC)

That is because of WP:PEIS. Note that Category:Pages where post-expand include size is exceeded appears in the category list. – Jonesey95 (talk) 15:32, 13 October 2023 (UTC)

Thanks 👍 --Yodin^T 18:47, 13 October 2023 (UTC)

Can you patch line 452? gfind is obseleted in Lua 5.1

Would it be possible to request an edit to line 452, to change local gfind = string.gfind to local gfind = string.gmatch?

It seems that string.gfind is obsoleted in Lua 5.1 (though obviously still available functioning 5.1.5 that the wiki farm is running) and has been renamed to string.gmatch.

While the code works under Lua 5.1.5, it fails under luajit (which a number of large MW installations use), which is (I believe) 100% compatible with Lua 5.1, though I guess the "obsoleted" features aren't considered in that context? Mahmoud (talk) 20:43, 27 November 2023 (UTC)

@Mqudsi: Line 452 where? This template doesn't have that many lines - it has just three. --Redrose64 🌹 (talk) 09:50, 28 November 2023 (UTC)

I suppose the poster meant Module:Navbox#L-452. (No opinion here on the merit.) -- Michael Bednarek (talk) 09:59, 28 November 2023 (UTC)

Yes, I did. I don’t know how I ended up making the comment on the Template page instead! Mahmoud (talk) 20:00, 28 November 2023 (UTC)

Oh, if you go to the talk page on the module you get redirected to the talk page for the template. Mahmoud (talk) 20:01, 28 November 2023 (UTC)

WCAG Compliance - Contrast

Hello, It would be Good if the Colors used in the Navboxes are following Web Content Accessibility Guidelines Compliance. J.Stalin S ^Talk 04:21, 30 November 2023 (UTC)

I might be mistaken, but I do not think that is anything that the navbox itself can handle - problematic navboxes are (as far as I am aware) dealt with on a case-by-case basis. Primefac (talk) 07:23, 30 November 2023 (UTC)

evenodd?

Is the evenodd parameter actually still needed for anything after this edit to the module in 2017 (relevant discussion)? 「ディノ奴千？！」^{☎ Dinoguy1000} 11:29, 15 December 2023 (UTC)

I don't remember but evenodd is still supported and has an effect. I don't think it is needed. Johnuniq (talk) 23:10, 15 December 2023 (UTC)