Jump to content

Template talk:Navbox/Archive 23

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 20Archive 21Archive 22Archive 23Archive 24

Request for an "experimental" parameter to allow innovation in getting navboxes to show up on mobile

Hi there! I come here from Template_talk:Taxonbar#Making_Taxonbar_mobile-friendly_and_serve_half_of_all_Wikipedia_readers. As you may be aware, many navboxes are unusable on mobile and break the reading experience and as a result are removed by brute force from the mobile site.

This was meant to be a short term solution, but as with most short term solutions has become long term (see phab:T124168. I'm keen to make steps to rectify this beginning with the Template:Taxonbar, however I need a slight adjustment here to allow me to do this.

My hope here is to provide a general solution that can be applied to other templates.

Any element with the `navbox` class will be removed from the HTML on mobile, so to workaround this issue and allow experimentation in the area, a temporary parameter is needed that will allow us to use a different class to e.g. `navbox-experimental`. Feel free to name this parameter/class anything that makes sense. It could also be mobile=1 and `navbox-mobile-friendly` for example. The important thing is the `navbox` class should not be added.

e.g. proposed change: 

		local nav = res:tag('div')
			:attr('role', 'navigation')
			:addClass('navbox')
			:addClass(args.navboxclass)

to 

		local nav = res:tag('div')
			:attr('role', 'navigation')
			:addClass(args.experimental ? 'navbox-experimental': 'navbox') # not sure if this is valid Lua code but hopefully it's clear what I'm trying to do here. The class should be navbox-experimental when the flag is set.
			:addClass(args.navboxclass)

Is this possible? If so I promise to report back when I have something cool to show. Jdlrobson (talk) 23:24, 24 November 2020 (UTC)

I actually recently just set everything to display block in a media query and it actually looks pretty reasonable as a first-try stupid solution. There's some white space that is showing up that's weird and I don't know how it will go with e.g. the image cell. Try it in Timeless or Minerva on the desktop domain while on mobile. (I haven't had a chance to look at Anonymous's solution yet since he put something on the task recently.)
I'm not really a fan of a parameter for it.... If it's successful it's a lot of cleanup of an unused parameter and if it's not successful it's a lot of cleanup of an unused parameter. --Izno (talk) 00:38, 25 November 2020 (UTC)
I'm not a fan of a parameter either TBH, but without the parameter, I see this as a little deadlocked as I don't have any intention of fixing all the navboxes right now. The alternative would be to fork the template e.g. Template:NavboxV2. Would that be better? Jdlrobson (talk) 02:04, 25 November 2020 (UTC)
You don't have to fork it, just use Module:Navbox/sandbox. I gather you plan to make a sandbox with some text and a modified navbox, then view the result on mobile? And experiment to see what is needed to make mobile work? Another approach would be to use Special:ExpandTemplates to get the output of whatever you are working on, then edit the raw html in a sandbox. As I recall, this module puts everything in one line which make editing a bit ugly. I think that's why I once used Module:Dump#Dumping a navbox. Lua uses "and...or" as a useful kludge for "?...:". I can put that in a module if needed. Johnuniq (talk) 05:58, 25 November 2020 (UTC)
It might just be preferable to write in a hard exception here as in 'if name = Authority control then navbox-exp else navbox'. That said, that particular template is a really simple example to try to work on these problems, and I'm fairly sure it will not extend. As for TemplateStyles, we still have not decided how to deal with TemplateStyles in these meta modules; the solution I'm coming around to supporting is something of the "for templatestyles..n parameters, add a templatestyles tag" so that multiple invoking templates (i.e. navbox -> intermediate navbox -> final navbox) can have access to their own tstyles. (This of course makes the special 'single border' CSS harder to write.)
In general, just spitballing and/or providing info. --Izno (talk) 18:37, 25 November 2020 (UTC)
(On an aside, I am not entirely certain Authority control needs to be written using navbox at all; it's such a simple template that it could reasonably be written in like 4 lines of Lua to remove the navbox dependency. I don't know what the collective thoughts are on such a thing. --Izno (talk) 18:39, 25 November 2020 (UTC))

Non-unique id

I noticed that this template uses the title of the navbox as an ID (:attr('id', mw.uri.anchorEncode(args.title))). However, it cannot be assumed that these IDs will always be unique, which creates invalid HTML. For an example of this, see the article Madame Nhu, which has a section titled Buddhist crisis, as well as a navbox Buddhist crisis. The fact that navboxes are usually present on related subjects makes such occurrences likely. I propose that when the ID is created, that it be prefixed with "navbox_" so it doesn't clash with any section headers or user-added anchors. Opencooper (talk) 17:01, 17 December 2020 (UTC)

Not sure what you mean by "invalid HTML"; what tangible effect is this having on the page? Primefac (talk) 17:08, 17 December 2020 (UTC)
For now, maybe none (though I noticed it because I have a userscript that does stuff with IDs and the elements ended up getting switched). However, the concern is that any CSS or code that targets this specific ID in the navbox will instead end up being applied to an anchor that comes before it (run document.getElementById("Buddhist_crisis") on the Nhu page and you'll only get the header). Currently I see the following inline style being applied: font-size:114%; margin:0 4em. Given that eventually the goal is to move inline styles to TemplateStyles, this might end up happening inadvertently.
And the HTML is invalid because IDs are supposed to be unique within a document. Here it is straight from the spec: When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree (note, "must"). Given that we could make our HTML valid just by prefixing the ID, I think this should be addressed. Opencooper (talk) 17:39, 17 December 2020 (UTC)
Yeah, I noticed this template was emitting an ID the other day and wasn't sure how to deal with it. Given its use for ARIA labelledby, I think tacking on a "_navbox_aria" in the string creation makes sense (or something to that effect). Still can't do much about the testcases page, but that's not exactly a use case envisioned by W3C/WHATWG regarding IDs. Best would be an overhaul of this template to not use tables, which may/not come around the time TemplateStyles get integrated. (I've slowly been working on the latter if you are interested at Mediawiki talk:Common.css/to do.) --Izno (talk) 18:06, 17 December 2020 (UTC)
I think it's fine if the testcases page has duplicates since that's not really reader-facing. Agreed with your proposed solution, though it might all be moot if the whole thing gets overhauled. Opencooper (talk) 18:45, 17 December 2020 (UTC)

Can |groupwidth = __ be used to narrow cells?

Using the "|groupwidth = #em " parameter appears to force extra whitespace and widen the group column of a subgroup, but is there a way to force the column to be narrower? I am asking because a long group name can force extra whitespace into all of the other group names. I can insert <br /> line breaks manually to adjust this, but I was wondering if there is a way to let auto-formatting take care of that via a fixed groupwidth. -2pou (talk) 19:54, 17 December 2020 (UTC)

@2pou: You have to override the nowrap, so |groupstyle=width:8em;white-space:normal; should do it, or whatever width is appropriate. Thanks! Plastikspork ―Œ(talk) 14:57, 18 December 2020 (UTC)
Thanks, Plastikspork! The white-space:normal worked like a charm: Special:Diff/994992577. I couldn't get the width part to narrow down any further, but this does what I was looking for. -2pou (talk) 16:53, 18 December 2020 (UTC)

Group without a child list item

Inside the template Template:Trade unions in Myanmar navbox for list2= item, I am forced to put something there, otherwise even the group2 won't show. Does anyone have a work around, besides for empty/invisible string? Shushugah (talk) 21:40, 25 February 2021 (UTC)

1, The navbox shouldn't exist with that many redlinks. 2, you shouldn't have group with no list items. 3, if you needed it you can use above/below to put that link. But once again, this navbox should only exist to navigate between existing pages. DLManiac (talk) 22:14, 25 February 2021 (UTC)
Agreed. If you're trying to have a navbox where only the group shows, you need to rethink and/or restructure your navbox. Personally, with that navbox I would use sequential indentation for |list1=, having what are currently your "groups" under * and all of the values in "list1" having ** indentation. That will still give you the necessary splits without having to bodge things up. Primefac (talk) 15:28, 26 February 2021 (UTC)

Parameter alias

I think that |status= would be a decent alias for the existing parameter |state=. Or at least, this seemed like an intuitive option to me, here; and templates should be more user friendly if possible. Now I don't know enough about template syntax to know what needs to be done, so asking nicely here in case somebody with more of a clue can help. RandomCanadian (talk / contribs) 14:18, 26 March 2021 (UTC)

 Not done for now: One name for the parameter seems quite sufficient to me. Izno (talk) 18:08, 26 March 2021 (UTC)
Thank you. Aliases cause confusion. If someone sees "status" in one article and "state" in another, they are going to waste time wondering what the difference is and which should be used. Johnuniq (talk) 22:55, 26 March 2021 (UTC)
Aliases make templates more user friendly - it's always possible and straightforward to mention them in the documentation... RandomCanadian (talk / contribs) 04:06, 27 March 2021 (UTC)
Even if status was added to the Navbox template, it would also need adding to every template that uses Navbox before it could be used as a parameter from an article. -- WOSlinker (talk) 11:46, 27 March 2021 (UTC)

Expanded by default

Would it be possible to set a preference or some CSS so that navboxes and their collapsed sections are all visible to me by default? NemesisAT (talk) 12:01, 9 May 2021 (UTC)

It can't be done in CSS alone, because the collapsing is done by means of JavaScript which alters the style="" attribute of table rows to add or remove the declaration display: none;. --Redrose64 🌹 (talk) 19:51, 9 May 2021 (UTC)
Thanks for this. Maybe that can be overwritten with !important;? I'll have to take a closer look. NemesisAT (talk) 15:05, 10 May 2021 (UTC)
No. --Redrose64 🌹 (talk) 22:51, 10 May 2021 (UTC)
You could probably write yourself some Javascript to run for yourself after the relevant Javascript has run that would remove the display: nones. But no, not CSS directly. Izno (talk) 06:07, 17 May 2021 (UTC)

"Purely decorative" images

The template documentation says of its image field that "Typically it is purely decorative"... yet MOS:DECOR says "Icons should serve an encyclopedic purpose and not merely be decorative." Should the documentation reflect that, and discourage images that only add decoration? If so, where's the line drawn for what's "decorative"?

I had the policy pointed out to me by someone removing a picture of a potato from Template:Potato dishes, which is maybe fair enough, but that kind of usage seems fairly common across navbox templates. --Lord Belbury (talk) 17:59, 12 January 2021 (UTC)

I've taken a bold approach and edited the doc. — Mike Novikoff 00:50, 16 January 2021 (UTC)
WP:DECOR is about icons, little national flags and that sort of thing, not images in general. Also it is a manual of style matter, offering guidance, not hard rules. The bold edit above saying most images should be removed on sight is grossly inappropriate and, in my view, should be reverted. DECOR does not apply and this discussion should not have been regarded as concluded. Thincat (talk) 11:10, 22 January 2021 (UTC)
WP:DECOR also talks about navigation and discourages images that serve no navigational purpose. I agree that images should be in navboxes only in exceptional circumstances. They take up space better used for navigational links, and they do that typically on many pages. WP:DECOR's They should provide additional useful information on the ... subject, serve as visual cues that aid the reader's comprehension, or improve navigation. is good advice. -- Michael Bednarek (talk) 12:10, 22 January 2021 (UTC)
Are we referring to different guidelines? By my understanding WP:DECOR is the section of the manual of style relating to icons. What you say may be the case but it isn't DECOR that says it. Thincat (talk) 13:03, 22 January 2021 (UTC)
WP:DECOR defines icons as any small images and it deals with navigational issues. This discussion start with concerns about Template:Potato dishes; what possible value does the small image in this version of that template have? -- Michael Bednarek (talk) 17:16, 23 January 2021 (UTC)
I'm not giving any opinion on its value. I'm saying it isn't an icon. And DECOR doesn't say either icons or small images should be removed on sight. Thincat (talk) 19:06, 23 January 2021 (UTC)
If pages with multiple navboxes collapse them all by default, which seems to be the case, I suppose there can be no possible navigational purpose to the image field - the user has to navigate to and open the box before they see the image. Stacked navboxes on an article like Knish would be quicker to navigate if they all had recognisable icons (the excessive example at File:Navboxes - Jennifer Doudna - en.Wikipedia - 2020-10-07.png has clear Nobel Prize sections even at illegible thumbnail size), but not if they all start off collapsed. --Lord Belbury (talk) 12:32, 4 February 2021 (UTC)
I find the image in Template:Jewish cuisine counter productive. Without it, there would be less wasted whitespace, and I wouldn't need to scroll to see all the links. The image in Template:History of biology is better because the aspect ratio is more compatible with the box content. Thanks! Plastikspork ―Œ(talk) 14:53, 4 February 2021 (UTC)
Template:History of biology's tall side image looks good, but seems just as "purely decorative" as any other example listed here: probably moreso, as I don't think the icon communicates "biology" at a glance to the average reader. It should be "removed on sight" if we're sticking with the bold instruction from January. --Lord Belbury (talk) 09:59, 17 May 2021 (UTC)
I agree that that image, in addition to not aiding navigation, doesn't convey anything about "biology". Its use in the article on its creator, Nicolaas Hartsoeker (who is not mentioned in the template), is a good illustration, but it's pointless in the template. -- Michael Bednarek (talk) 11:04, 17 May 2021 (UTC)

Localization

Would it be possible to make this module more localization friendly? Given that other wikis use it, it would be great if you could specify localized parameter names (and values like "autocollapse", "collapsed", "expanded", "plain", "off" etc.) so that they could be used alongside the original, English ones. – Srđan (talk) 09:56, 5 April 2021 (UTC)

I'm willing to help if there are no objections, although help from more experienced Lua editors would be great. bs:Modul:Infobox is a quite good take on how i18n can be implemented, although it could be improved to make it more generalizable. MarioGom (talk) 10:03, 5 April 2021 (UTC)
Module:Arguments which is used by Module:Navbox has an undocumented translate option for parameter names that could be used. -- WOSlinker (talk) 12:01, 5 April 2021 (UTC)
Any update on this? Do you know how to do it and would you be willing to implement it? – Srđan (talk) 17:37, 21 April 2021 (UTC)
@Srđan, MarioGom, and WOSlinker: I did a rough job in the sandbox. Does not support numbered parameters as it should but most of the relevant strings got pulled out. Please, uh, test. Also, I didn't use the module:arguments translate stuff given that it's not documented for idiots. Izno (talk) 06:24, 17 May 2021 (UTC)
@Izno: Re Module:Navbox/sandbox and comment "where is code set???": changer is a function and code is set as its parameter when changer is called. That occurs in the final gsub which calls the function for each match of REGEX_MARKER. That part of the module is extremely tricky, good luck!
Re needsHorizontalLists and your FIXME: I don't follow. The original code adds the tracking category Category:Navigational boxes without horizontal lists if parameter listclass is not one of the named classes (plainlist, hlist, etc.); same with parameter bodyclass. I guess you know the module wouldn't work at the moment because it would try to index a nonexistent variable (list_classes). Johnuniq (talk) 07:11, 17 May 2021 (UTC)
Right, my point is that listclass might in fact be something other than those listed while also including one of the usual list classes, so what the module should be doing is trying to find one of those classes, instead of checking for equality.
The relevant variable should exist now. :^)
I probably just don't get lambdas. heh Izno (talk) 07:17, 17 May 2021 (UTC)
Given that the category contains 1950 pages, perhaps it is not useful and could be removed? I don't know it's purpose, I just retained the logic of the original. Johnuniq (talk) 07:31, 17 May 2021 (UTC)
That category was useful when there were lots of navboxes that didn't use the hlist class but now, all that is left are ones that are all the exceptions that don't actually need a list converting to the hlist format. So i think that category could be removed. -- WOSlinker (talk) 07:53, 17 May 2021 (UTC)
Yeah, but we'll need an implementation that does find these things because when hlist and plainlist gets TemplateStyled I am not going to go around to the ~100,000 navboxes with an hlist class to switch to {{hlist}}, {{plainlist}}, and any other applicable templates, I'm just going to insert the relevant templatestyles invocation. Izno (talk) 15:59, 17 May 2021 (UTC)
The Navigational boxes without horizontal lists category was mainly to do with accessibility improvements - until hlist was introduced, most navboxes used bullets between entries, often using the {{•}} template, which was very bad for accessibility. Back in November/December 2011 we decided to sort this out, with edits like this. The category was used to find out what still needed fixing. WOSlinker was heavily involved. --Redrose64 🌹 (talk) 20:08, 17 May 2021 (UTC)

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § WikiProject links in navigational templates. --Trialpears (talk) 16:02, 8 July 2021 (UTC)

Autocollapse

Hello. I added a navbox to Web testing, with no state, so I assume it is defaulting to autocollapse. Interestingly, it is choosing to fully collapse, despite there being no other navboxes on the page. Any idea why? Is this expected behavior? Thanks. –Novem Linguae (talk) 06:49, 14 May 2021 (UTC)

I'm pretty sure it's because of the {{multiple issues}} box on that page, which is also collapsible. – Jonesey95 (talk) 13:20, 14 May 2021 (UTC)
Definitely {{multiple issues}}; the two templates that it encloses have no bearing on the matter. --Redrose64 🌹 (talk) 17:40, 14 May 2021 (UTC)
Wouldn't it be a good idea to tweak {{multiple issues}}, or probably rather {{Ambox}} which does the work, so this doesn't happen? -- Michael Bednarek (talk) 00:38, 15 May 2021 (UTC)
It's not {{ambox}} itself, it's the mw-collapsible class that is applied to the <div>...</div> enclosed by the ambox. --Redrose64 🌹 (talk) 09:11, 15 May 2021 (UTC)
TheDJ has previously suggested on MediaWiki talk:Common.css and/or MediaWiki talk:Common.js that perhaps how autocollapse works should be limited to certain templates like navbox. Izno (talk) 18:29, 20 August 2021 (UTC)

How to use {{Navbox}} for a different Template namespace (4010 custom site-specific namespace instead of default 10)

Hi! I am using this template on my MediaWiki site and it's in the default Template namespace (10), however, I also have an additional namespace for templates (4010), the site is configured to allow everyone to edit 4010, but not 10 (which is reserved for synchronized from latest versions of widely used templates). I noticed the V T E links at top-left corner of the navbox links to Template (10) namespace, but I want to configure it to use the custom site 4010 namespace. Is there a way to do this in the {{Navbox...}} wikitext markup? I see the Navbar module appears to have a configuration for the template namespace to use Module:Navbar/configuration#L-4 but I don't think the Navbox template passes this to also be configurable. Jasonkhanlar (talk) 04:26, 3 May 2022 (UTC)

Solved! The `name` argument should be the path of the template including the namespace. All links work now. Jasonkhanlar (talk) 05:12, 3 May 2022 (UTC)

i18n and TemplateStyles improvements

Thanks to Frietjes and Plastikspork's recent work, the navbox class is no longer used in the wild unless through a template driven by Module:Navbox. As such, I've sandboxed changes (see also Module:Navbox/configuration and Module:Navbox/styles.css) to the module which enable TemplateStyles in the template in preparation for removal from Common.css.

I've also finalized the improvements listed in the localization discussion earlier this year.

The sandboxes are currently 'passing' (behavior is replicated between old and new), so please take a look at those and any favorite navboxes you might have to see if behavior has changed in those as well.

Some potential improvements for this release besides the TODOs in the sandboxes would be:

  1. Remove the inline styles totally from the module into the stylesheet

Other major improvements that could be done but I'm not doing now:

  1. Work on allowing some modules like Module:Taxonbar to display on mobile
  2. Converting from table-based template to div-based template (see also User:Izno/Sandbox/Navbox)

Questions/concerns welcome. Izno (talk) 01:29, 16 November 2021 (UTC)

Impressive work. It looks good although I don't know about the styles. Re "we have infinite now, so why is this limited to 20?": There is no good way to enumerate all the template parameters in the wanted order, and there is no way to know when you have reached the end. A loop with pairs would normally be used but that could read arguments in a strange order conflicting with the comment that the intention is to make reference numbers appear in the right order. Johnuniq (talk) 03:37, 16 November 2021 (UTC)
Right, using iterators won't work in this context. Still leaves me wondering if we couldn't still bump 20 up a bit (maybe 50ish? -- I idly wonder what our numbers are for groups globally), or at least leave a note that we know this is a limited case I guess. Izno (talk) 04:41, 16 November 2021 (UTC)
No one is likely to notice if references after 20 are numbered in a strange order, and it's not even certain that a strange order would occur. Johnuniq (talk) 05:50, 16 November 2021 (UTC)
"People won't notice" is how you get that chunk of code in the first place. :P It's fine, I added a note there to skip future questions. Izno (talk) 05:53, 16 November 2021 (UTC)
On the configuration page, there is a slight inconsistency in the category table with orphan being a different format to all the others. Would be nice to be the same as the others. -- WOSlinker (talk) 09:01, 16 November 2021 (UTC)
The category is being used both to add to the page and then to be removed from the page. There's really not another way to handle it unless we split it into two keys (which might be safer tbh). Izno (talk) 17:09, 16 November 2021 (UTC)
looks great. it would be cool to replace lines like fontstyle = (args.basestyle or '') .. ';' .. (args.titlestyle or '') .. ';background:none transparent;border:none;box-shadow:none;padding:0;' with something that just extracted the last "color:" parameter. the reason for the background:none transparent;border:none;box-shadow:none; is to override prior values potentially set in basestyle and/or titlestyle, so we end up sending a bunch of extraneous styles to navbar. but, what we have works, so maybe it's not worth the extra processing. Frietjes (talk) 15:10, 16 November 2021 (UTC)
That seems easy enough actually if the color is really all we want in that context (is it?). Maybe post-release.
Another way to handle that would be to move the overrides to the stylesheet and drop a bunch of !important on them. Izno (talk) 17:08, 16 November 2021 (UTC)
Frietjes, I've edited Module:Navbox/sandbox to remove the styles we don't want. Testcases specifically for that function are in Module:Sandbox/Izno/testcases, with a few navbox test cases (a box-shadow one particularly) on Template:Navbox/testcases. Right now we are sending a style=";" which it would be nice not to send if we can avoid it. Izno (talk) 02:06, 18 May 2022 (UTC)
Izno, nice work. I would replace sanitizeCSS with something that extracts the last color from the css like this. I don't think there is any other css that we should allow for styling the navbar. Frietjes (talk) 14:43, 18 May 2022 (UTC)
Frietjes I don't really want to make an assumption about what CSS ends up in that parameter, but honestly can't see a reason not to do something like that.
I do think yours makes an assumption about the presence of certain semicolons, particularly the end semicolon, which may not be true. Hence the mw.text.split in my copy. Izno (talk) 17:21, 18 May 2022 (UTC)
Izno, if you check line 85 you will see that I enclose the string with ';' before parsing, so no assumptions about any trailing semicolons. but please let me know if there is something that I am missing. Frietjes (talk) 18:22, 18 May 2022 (UTC)
I looked at that several times and somehow didn't remember to actually consider it in my response. Sigh.
I've made an adjustment to return nil out of the color function. Izno (talk) 19:34, 18 May 2022 (UTC)
yes, I agree, returning nil is even better in this case. Frietjes (talk) 19:40, 18 May 2022 (UTC)
Deployed this round. I also added a check for titlegroup, which doesn't look like it exists meaningfully. Izno (talk) 00:07, 27 November 2021 (UTC)

TemplateStyles followup

Some followup!

I have removed the Lua that deals with titlegroup out of the sandbox. The category dragged up nothing in the past month. I'll remove this when I sync the module later.

Separately, I have adjusted the CSS in the TemplateStyles page due to this series of edits. Neveselbert identified that the .navbox th style, when appended with the .mw-parser-output and subsequently embedded into a page by TemplateStyles, would override the table header styles of wikitable tables, which apparently impacted succession boxes in particular.

What this second change means is that handcrafted tables in navboxes will no longer be styled after removal from Common.css some time from now while the TemplateStyles styles are updated by the job queue again. (Neveselbert, please leave a talk page note in the future with an appropriate ping so that we can get this sorted quicker rather than a month down the road.) I see in the history of MediaWiki:Common.css that this has caused some consternation in the past, but with so few templates, the majority now using at least the same 'external' appearance via the module (i.e., the table header/title), and the fallback being fairly graceful to uncolored embedded tables, I feel comfortable fixing the CSS this way.

There are approximately 900 affected templates, which are now probably mostly using Module:Navbox top and bottom in case anyone should care to fix those in the future. Fixing the 900 templates involves probably 1 or 2 possible paths:

  1. Adding appropriate navbox classes to the headers of interest in each of those templates (not recommended).
  2. Converting those templates to use navbox or one of its derivatives fully rather than the navbox top and bottom solution.

Please let me know if you have significant heartburn. I will leave a pointer about this change at VPT and at Common.css. Izno (talk) 22:23, 21 December 2021 (UTC)

Izno, if I recall, the primary reason for using Module:Navbox top and bottom or the top and bottom in Module:Navboxes is that either (a) you want to embed a wikitable inside the navbox without heaving use of pipe templates or nowiki hacks, or (b) the post-expand size is exceeded from embedding a group of navboxes inside of another navbox. Would it be possible to merge the top/bottom functions with Module:Navbox? Thanks! Plastikspork ―Œ(talk) 16:07, 23 December 2021 (UTC)
correct me if I am wrong, but this isn't an issue with Module:Navbox top and bottom per se, but could be a problem if you are expecting a table embedded inside a navbox to inherit the styling of the navbox? I spot checked a few, and I don't see any issues with the ones I checked. but, I do agree that adding a top/bottom feature to Module:navbox could reduce the complexity of Module:Navbox top and bottom, but I don't know if the reduction would be significant. thank you. Frietjes (talk) 16:41, 23 December 2021 (UTC)
Yes, this is the correct read Frietjes, but also if you're expecting the table headers (a la navbox with columns, which will be fine after this change) of the top level thing called a navbox to get colors.
I honestly don't want top and bottom to be anything more than 'it's a workaround', and if we could it would make more sense to get all those using it to use some more official form of module supporting them. I suspect that will be a long/lengthy/complex task of figuring out exactly why each of the 900 or so are using that module. What was your read on it? Izno (talk) 19:07, 23 December 2021 (UTC)
Izno, I agree that the top/bottom templates should only be used when nothing else works well. many of the top/bottom templates could probably be replaced with Template:Timeline, but that would take some effort to convert them. Frietjes (talk) 19:10, 23 December 2021 (UTC)
Styles are now solely in Module:Navbox/styles.css. |titlegroup= and related parameters have also been removed. :D :D :D Izno (talk) 04:42, 10 January 2022 (UTC)
Very nice work Izno ! —TheDJ (talk • contribs) 10:02, 10 January 2022 (UTC)

question re horizontal bar

hi everyone. I have a simple formatting question, about our template:navbox. how would I put a simple horizontal bar across the navbox, with some text inside it, to delineate a separate section?

please note, this bar does not need to be the top of a collapsible section; it is simply for visual purposes only, in separating one part of the navbox from the other parts.

appreciate any help. if you want, you can simply link me to an existing navbox which would have this feature. thanks! --Sm8900 (talk) 13:47, 16 June 2022 (UTC)

You could add a <hr /> tag before the |groupn= parameter. --Redrose64 🌹 (talk) 14:41, 16 June 2022 (UTC)
Sm8900, do you mean something like this?
-- Dr Greg  talk  15:27, 16 June 2022 (UTC)

Invisibility of Premier League

I have learnt in another discussion that there was a deliberate decision by the developers that Navbox is not supposed to be displayed on mobile devices, because they don't work properly. But the problem slowly increases as the percentage of mobile users has reached 65% of pageviews and even more critical as the Premier League is affected. Imagine a premier league match is streamed on mobile devices with only one team visible because the other team doesn't work properly. {{Tottenham Hotspur F.C.}}, {{West Ham United F.C.}}, {{Manchester United F.C.}}, {{Chelsea F.C.}}, {{Liverpool F.C.}} and all the others are beautiful creations based on hard work using Navbox but they are invisible on mobile devices. No substitute is available on the template bench of Wiki for the incomplete {{navbox}}. How can we kick off a new discussion to vote for the development of a technical solution of this problem? Ruedi33a (talk) 16:38, 30 August 2021 (UTC)

@Ruedi33a, I fully support your goals as expressed above. how about if we bring this to the Village Pump for some creative discussion and problem-solving? would you like to do that? full disclosure; my own technical knowledge about items like this is about nil. however, I'm in favor of interested editors helping each other and working together, on items such as these. feel free to advise. thanks!! --Sm8900 (talk) 13:49, 16 June 2022 (UTC)
@Sm8900, thanks a lot for your support. But I have invested already a lot of work with no significant results. You can look at Ca' Pesaro and the change with the comment "The sequence enables mobile users to click the previous or the next landmark listed in the navbox Venice landmarks below, although a navbox is invisible in mobile view". Ruedi33a (talk) 21:14, 16 June 2022 (UTC)

Image parameter

Should we depreciate the use of |image = parameter from the navbox, as a result for Wikipedia:Navigation_template#Navigation_templates_are_not_arbitrarily_decorative. 112.204.221.155 (talk) 16:43, 11 September 2022 (UTC)

No. "images are rarely appropriate in navboxes" means that sometimes they are appropriate. – Jonesey95 (talk) 17:00, 11 September 2022 (UTC)
When are they appropriate? I wondered about this last year at Template_talk:Navbox/Archive_23#"Purely_decorative"_images. I'm in favour of the images aesthetically, on most navboxes, but beyond basic visual design (relevant subject, distinguishable at a small size, maybe a transparent background) still don't have a clear idea of what a good, non-decorative navbox image would be.
Somebody else boldly updated the template documentation at the start of that discussion to say that, in their opinion, most of such images don't comply with MOS:DECOR and should be removed at sight, which is still there, and I've stopped trying to add images to navboxes since. --Lord Belbury (talk) 19:20, 11 September 2022 (UTC)
The second bullet point literally gives an example of when it is acceptable. Primefac (talk) 19:36, 11 September 2022 (UTC)

TemplateStyles for plainlist

I've gotten to the point where I'm implementing plainlist as TemplateStyles (see MediaWiki talk:Common.css/to do#Plainlist for details) and I've done some work on Navbox to support it, since Navbox mentions the class. The consolidated diff is this change.

Part one of the change makes it so that when Navbox sees the class plainlist in one of its class parameters (and later, hlist, when I'm to that point), it will emit plainlist TemplateStyles inside the navbox-styles div. I hope this will be a fairly limited function for this module in the interest of limiting how much this module needs to know about arbitrary styles as basically a big workaround for how many uses of this module invoke the raw list class, but it could be extended to arbitrary TemplateStyles classes with consensus. A version of it has been deployed at MediaWiki wiki for a while. The test case at Template:Navbox/testcases#Horizontal/plain lists should give an idea of what happens.

Part two of the change is something I've had on my mind for a bit. Right now, phab:T303378 happens: in brief, MobileFrontend removes initial definitions of TemplateStyles if they're found there (as well as later references, but those are not an issue as they become <link>), at least in the mainspace (my personal test case page doesn't work any more because MobileFrontend seems to have stopped removing the div there entirely, at least in user space). The second change finds TemplateStyles strip markers and moves them to the navbox-styles div so that Navbox can guarantee styles haven't disappeared from mobile. (As a result, I have to remove nomobile from that div.) While Navbox particularly doesn't have a lot of worry about it (Module:Military navigation is probably the large exception in non-wide mode which most-often appears near the tops of articles; it should probably be using Module:Sidebar), I also plan to implement this in Module:Sidebar, which currently does appear early in the document in most cases. I'm asking for someone to take a look and see if there's another way this could be done more efficiently than find_hiding_templatestyles() does now. (I am pretty sure I cannot avoid gsubbing the arg as this would introduce the literal same strip token twice.)

This second part is demonstrated at Template:Navbox/testcases#Save the TemplateStyles.

I'd like to entertain adding one more change (cc @Frietjes) which is the change discussed earlier regarding sanitizing the inputs to the style parameters for Navbar. That was in the context of Template talk:Navbox/Archive 23#i18n and TemplateStyles improvements. It would be the reversion of this removal from the sandbox. We had not deployed it for some reason I don't know and I think it would be a benefit.

There's probably a fourth change which should happen in the near term, which is getting all the rest of the styles out of the module and into the TemplateStyles page. You see a few of them there in the output of the testcases for change 2. Izno (talk) 00:48, 15 December 2022 (UTC)

Parts 1 and 2 are now live for plainlist, though currently there's a bug on that front that I'll correct when I do hlist Soon. Izno (talk) 05:39, 26 December 2022 (UTC)

Groupstyle vs Groupwidth

@Izno: I would expect these to give the same result

but they don't. we should either fix the css order, or add a tracking category to find/fix these? Frietjes (talk) 20:05, 5 January 2023 (UTC)

@Frietjes, some thoughts, in a jumbled order, roughly progressing from easiest to hardest (but also toward most desirable):
  1. The fix for this is trivial, just move :css('width', args[cfg.arg.groupwidth] or '1%') below the other declarations on the cell. (I don't understand why the ordering there is as it is or why groupCell is there a second time.)
  2. We probably shouldn't have groupwidth. (There's an argument to keep groupwidth until #4 is done, which is that we can just turn support off somewhat arbitrarily when this template handles small resolutions.)
  3. We probably shouldn't have the 1% inline style either. That's change 4 in #TemplateStyles for plainlist. (Take a look at change 3 while you're looking.)
  4. We should mark all inline styles as deprecated in favor of TemplateStyles. :) That's blocked on #2. And should probably not be done until this template supports low resolution better, which is blocked on a grid version of this template. Which I have experimented with in User:Izno/Sandbox/Navbox.
So, yes is the answer to your question. :^) Izno (talk) 23:29, 5 January 2023 (UTC)
@Izno: the reason for groupwidth is to align the widths of groups in different subgroups, but otherwise, I agree there is no need for it. of course, that could also be potentially fixed with templatestyles. can we add tracking for "width" in groupstyle or liststyle (including groupXstyle and listXstyle)? I have cleaned up about 500 of them today using various regular expressions to find them. thank you. Frietjes (talk) 23:33, 5 January 2023 (UTC)
I don't think we need to do any tracking, item 1 just fixes it (for now). I was imploring that you revisit your change (which is change 3 above) and/or that we should get all of the in-module styles out of the module as in change 4 (up there) and then we can make a marginally wider ranging change at the same time which also fixes the issue.
NB of course if those cases have survived without the parameter which avoids this bug and haven't caused complaints here, does this really need changing? :) Izno (talk) 23:41, 5 January 2023 (UTC)
when |groupwidth= is set, width:100% is omitted from the adjacent list cell. if you put the two examples in Special:ExpandTemplates you will see the difference. by "change 4" in #TemplateStyles for plainlist, I am assuming you mean "extractcolor" for passing the color to navbar? if so, yes, we should add that to reduce unnecessary css in the navbar. it would also be fun to clean duplicate css (e.g., "background:white; background:black;" -> "background:black;") but I am not sure if it's worth the effort. Frietjes (talk) 18:20, 6 January 2023 (UTC)

Formatting issue

Not sure this is worth fixing or can be fixed, but we came across a formatting issue. The following code: 

{{Navbox 
| title  = [[Barrie]]
| below = '''[[List of municipalities in Ontario]]'''
* [[:Category:Barrie|Category]]
}}{{Authority control|qid=Q4863550}}

looks like this:

You'll see the problem with the formatting in the authority control template spread over 5 lines — Martin (MSGJ · talk) 08:12, 14 February 2023 (UTC)

I don't think this is necessarily a problem with navbox. The authority control template, like many templates of its type, needs to be on a new line. – Jonesey95 (talk) 15:44, 14 February 2023 (UTC)
Unfortunately there is at least one script which removes these newlines, thus breaking the display. --Redrose64 🌹 (talk) 16:16, 14 February 2023 (UTC)
It sounds like we're having this discussion at the wrong talk page. – Jonesey95 (talk) 16:49, 14 February 2023 (UTC)
Indeed, I don't see any reason why a script should be removing these lines, but that is not an issue for this page specifically. Primefac (talk) 11:02, 16 February 2023 (UTC)
It might even be VE, see this VE edit that removed a newline whilst inserting a banner. --Redrose64 🌹 (talk) 14:04, 18 February 2023 (UTC)
If it's VE, then we're pissing into the wind if we try to get it fixed. I'm still finding pages with nowiki tags all over the place and that's been a known issue for years now. Primefac (talk) 15:19, 19 February 2023 (UTC)
Unfortunately, that is probably true. It appears that the team that left Visual Editor in a perpetual beta state has moved on to Vector 2022 as the next big software project that they will leave 85% done. Oops, sorry, my cynicism is showing! How embarrassing. – Jonesey95 (talk) 19:37, 20 February 2023 (UTC)

Initial visibility

The initial visibility seems to be stuck in the expanded state, as seen in articles with multiple navboxes (e.g. articles Safeway, Star Wars, etc). Forcing the parameter with |state=collapsed appears to do nothing, as multiple navboxes are still displayed fully expanded; the default autocollapsed is similarly ignored. I'm viewing the pages in desktop mode at 90% zoom (because at 100% zoom, Reflist no longer autodivides into columns). — CJDOS, Sheridan, OR (talk) 12:28, 6 April 2023 (UTC)

I am unable to reproduce this problem. At Safeway, the Albertsons navbox is appropriately expanded, and the rest are collapsed. At Star Wars, all of the navboxes are collapsed. As for Reflist, you are seeing the consequences of the Vector 2022 skin's excessive white space. I have modified my personal CSS to allow for wider content, which results in a three-column reflist for me on those (and most) pages. If you can't stand it, you could always change your Preferences (under Appearance) to go back to Vector 2010. – Jonesey95 (talk) 14:25, 6 April 2023 (UTC)
I wish to add that when I signed in just now, the Preferences page is no longer listed in a tab-like format, but instead as vertical boxes down the page. It didn't display like that previously (this year), even using the default Vector 2022 skin. So, there has indeed been some changes. I kept the default Vector 2022 appearance so that I would see what most people would see. I would like more input from editors who have not modified their selected skins, and I will give switching back to Vector Legacy serious consideration. Is there a list of editors who are critical of the Vector 2022 skin? — CJDOS, Sheridan, OR (talk) 17:18, 6 April 2023 (UTC)
It works fine for me. Either your browser is not processing the JavaScript properly, or you have some custom setup which is incompatible with these pages. --Redrose64 🌹 (talk) 21:13, 6 April 2023 (UTC)
Answering my own question, yes, there is a page at mw:Talk:Reading/Web/Desktop Improvements for discussing the changes, and the 2022 skin. — CJDOS, Sheridan, OR (talk) 02:34, 7 April 2023 (UTC)
Based on Redrose64's suggestion, I tried viewing one of the exampled pages on an entirely different machine—everything seems to appear as it should, nothing weird of note. I haven't modified my skin nor added script, so it seems Wikipedia no longer supports my system. This thread may thus be disregarded; thank you for the replies. — CJDOS, Sheridan, OR (talk) 02:17, 7 April 2023 (UTC)
@CJDOS, what OS and browser version are you using? Izno (talk) 18:59, 13 April 2023 (UTC)

Short-circuit in ternary expression at line 143

This module has a mistake at line 143 (:attr('id', args[cfg.arg.title] and nil or mw.uri.anchorEncode(args[cfg.arg.above]))); this line attempts to output nil if args[cfg.arg.title] is truthy and otherwise mw.uri.anchorEncode(args[cfg.arg.above])), but because nil is falsy, the or always triggers, and as such the line always short-circuits to :attr('id', mw.uri.anchorEncode(args[cfg.arg.above])). {{Lemondoge|Talk|Contributions}} 00:37, 13 April 2023 (UTC)

@Lemondoge: Presumably you mean Module:Navbox. If not, please be specific. --Redrose64 🌹 (talk) 06:52, 13 April 2023 (UTC)
Yes, it's Module:Navbox#L-143 added in diff on 15 June 2018 and then tweaked on 27 November 2021. @Matt Fitzpatrick and Izno:, the OP is correct. Code x and nil or y is (x and nil) or y which is nil or y which is y. I remember trying to handle this operation somewhere—that is, trying to find a clean way of making :attr(...) add an attribute if a certain condition applied, but otherwise add nothing. I can't find what I did and don't have any suggestions at the moment. Johnuniq (talk) 07:54, 13 April 2023 (UTC)
Should be fine just to invert the logic which should short circuit correctly.
:attr('id', !args[cfg.arg.title] and mw.uri.anchorEncode(args[cfg.arg.above]) or nil)
Izno (talk) 17:30, 13 April 2023 (UTC)
 Done (:attr('id', (not args[cfg.arg.title]) and mw.uri.anchorEncode(args[cfg.arg.above]) or nil)) {{Lemondoge|Talk|Contributions}} 13:49, 17 April 2023 (UTC)

Colour accessibility of show/hide when using non-default background colour

Is it possible to change the navbox so that the show/hide option has sufficient colour contrast in cases where the navbox uses a non-standard background colour? There are many navboxes where it is hard to see it, for example with {{Everton F.C.}}, where it would be helpful to either have a different text colour as has been done for the VTE links and title, or for show/hide to be displayed within a separate white/pale background. EdwardUK (talk) 00:19, 25 April 2023 (UTC)

I suspect that you'd need to modify Module:Navbar amend the JavaScript that handles the mw-collapsible class rather than Module:Navbox. But have a look at how refs are handled by Module:Episode table, see for example the last two column heders of Doctor Who (season 1)#Serials.
Alternatively, use a coloured border rather than a coloured background, see my comments at Wikipedia talk:WikiProject Geology/Archive 5#Colors. --Redrose64 🌹 (talk) 07:01, 25 April 2023 (UTC)
I have had a look at the manual for collapsible elements on mediawiki and I can just about understand the coding for modules, but I think I would need to do a lot more research to work out the exact changes necessary. Though this may still be easier than suggesting to some (mostly sports) editors to make any changes to their navbox. However, for now the coloured borders seem like a good option that I can use. EdwardUK (talk) 13:56, 25 April 2023 (UTC)
@TheDJ: it looks respective styling in MediaWiki:Common.js needs to be adjusted in relation to phab:T333357. 2001:7D0:88D7:B880:58B7:B8B8:B652:7E50 (talk) 10:19, 28 April 2023 (UTC)
Related: Template talk:Infobox station#"Collapsible" feature not working and Wikipedia:Village pump (technical)#I need help! --Redrose64 🌹 (talk) 17:15, 28 April 2023 (UTC)

Standalone navbox which can double as a child navbox

 Courtesy link: fr:Modèle:Palette Shoah en France

This is both a question, and a note to self: we already have the ability to have a navbox which can either be used stand-alone in an article, or be transcluded as a child navbox of another nav template and work appropriately in both guises, but imho the feature is underused because the how-to isn't documented, and people aren't aware of the possibility. Does anyone know if there is a standard or conventional way already in use to format such a double-duty navbox? If so, we could just describe that. Either way, something should be added to the doc about it imho, because it is a very useful feature, but would probably be difficult for the occasional template coder to figure out on their own.

I think we could cover it in a new section, probably a subsection of Template:Navbox/doc § Child navboxes called "Transclusion of child navbox" or some such. For a live example in the wild, see French navbox Modèle:Palette Shoah en France (wd-linked to our Template:Holocaust in France, which does not use the feature) which has two child navboxes (*/Victimes and */Survivants), each of which may stand alone as a nav template, or be transcluded in another one. As nothing new needs to be created to do this, it's exclusively a documentation issue to help those who wish to take advantage of the feature. In that regard, this is a "note to self", or to anyone else who feels like tackling it in the doc, as I have no idea when I'll be able to get back to it and wanted to record it here. Mathglot (talk) 19:27, 28 April 2023 (UTC)

When will mobile visibility be fixed?

Please, please, it drives me close to tears with frustration every time I'm driven to the point of desperately changing every setting in my profile to no avail just to try to find a way to avoid the misery of switching my browser to desktop view, changing the URL to match, fiddling around with zooming and diagonal scrolling and everything to try to be able to click on the links, and then switching back to mobile to make the linked article actually readable which guarantees I'll have do the same thing again in ten minutes, every time I try to use a group of articles connected by navbox, or even every time an article seems like it might have one since there's no indication. What is the purpose of this nightmare? To avoid some relatively vastly less significant "problem" like horizontal scrolling or weird formatting? You'll notice that the forced desktop/mobile switching still involves the former, so you haven't even managed that. Whose terrible idea was this? Elliefint (talk) 01:36, 3 June 2023 (UTC)

This is Phabricator feature request T124168 from 2016. From my reading of the objections, they are that navboxes increase the page size (in bytes) by about 10%, which was a problem in 2016. I don't see why it would still be a problem in 2023. Surely the capacity of everything that transmits bytes has increased by more than 10% in the intervening seven years. – Jonesey95 (talk) 05:20, 3 June 2023 (UTC)
It looks like many navboxes disappear when the screen is narrower than about 70 characters. Try https://wiki.riteme.site/wiki/Michelle_Obama?useskin=minerva#External_links on a laptop/wider screen, and then change the screen width. The navboxes are visible until the screen gets too narrow, and then they disappear.
A 10% increase in page size will disproportionately affect people in developing countries. Whether it's worth it depends primarily on how much benefit people get from the navboxes. I don't use navboxes much, and I found it irritating just to scroll down far enough to find them in the Obama article.
@Elliefint, there's a compromise option that might work for you. It will require you to be logged in (and maybe also require keeping cookies).
Here are the steps:
  1. Scroll to the bottom of the page and switch to desktop mode.
  2. Scroll to the top. If it says "Create account Log in" then log in.
  3. When you're logged in, you'll see your username and a few icons. Find Preferences in the menu.
  4. Inside the preferences page, find the "Appearances" tab. (It's the second one.)
  5. At the top of the "Appearances" tab, there's a list of skins. Pick "MinervaNeue". (This is the name of the appearance normally used for the mobile view. You're in desktop view [so navboxes won't be suppressed completely], but telling it to look like mobile view [so you can have almost the same appearance for reading].)
  6. Scroll all the way to the bottom of the preferences page to find the blue button to save your change to your preferences.
  7. Scroll back to the top and use the search box to go to a new article (anything you haven't seen today that seems like a big enough subject to have a navbox, such as a popular musician or a different country).
  8. Now for the test: Scroll to the bottom where the navbox should be. If you don't see it, turn your phone sideways and check again. If the navbox doesn't appear, use your browser controls to shrink the font size way down. On my (small) iPhone, I have to set the font size to 50% if I'm holding my phone in the usual vertical position, or 85% if it's horizontal ...and the navboxes magically appear. They don't disappear with a pinch-to-zoom maneuver, so I can then zoom in to read them. After clicking, I can switch back to a normal font size.
While this won't be perfect, it's possible that this will be less bad than what you're doing now. If you decide that you don't like it, then of course you just undo the steps: reset your preferences in the desktop mode, switch back to the mobile view, and carry on like you were doing it before. WhatamIdoing (talk) 16:06, 3 June 2023 (UTC)
Thank you so much! I'm going to try this! (As for the point about the effect on users in developing countries, that's fair and definitely an important concern, but I do have to wonder if it's a more significant negative effect than that of blocking access to parts of articles for users on certain devices without these kinds of elaborate workarounds -- I'm thinking in particular of cases where the navboxes convey valuable information about the relationships between the current article and the articles linked therein, like the IPA chart navbox on phonetics articles. I don't know the answer to that without having the input of the users who would be most affected by larger page sizes and/or who don't have access to desktop devices, but I would be interested to hear that input.) Elliefint (talk) 16:32, 3 June 2023 (UTC)
It worked, thank you! Elliefint (talk) 16:35, 3 June 2023 (UTC)

"Template:Navboxrugby" listed at Redirects for discussion

The redirect Template:Navboxrugby has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 July 5 § Template:Navboxrugby until a consensus is reached. SWinxy (talk) 18:40, 5 July 2023 (UTC)

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)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Navbox/Archive_23&oldid=1191288280"