Jump to content

Template talk:Navbox/Archive 21

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

Proposal to change Module:Navbox

Per the discussions at #Row colour above, I propose updating the module from the sandbox.

For testing, I compared the output from {{navbox}} and {{navbox/sandbox}} for several cases—all good. Some other tests follow.

  • I made {{Beijing Subway Station/sandbox}} use {{Navbox/sandbox}} and previewed a couple of tests. They worked, and the striping was correct where it would previously fail to alternate correctly.
  • I previewed an edit to Module:Navbox with striping after changing it to use navbox/sandbox. Previewing with Angola showed that the navboxes at the bottom were unchanged.
  • When comparing results produced by the current navbox with those from the sandbox, it is seen that centering of the navbox title has changed. That is due to changes by Jc86035. The current navbox does some tricky padding to compensate for the V·T·E links but navbox/sandbox gives a better result IMHO.
  • The current navbox does some special processing for list1 which is mentioned in the template documentation as "For the image to display properly, the list1 parameter must be specified." Navbox/sandbox changes that so the special processing is done for the first listn which might not be list1. That seems more natural to me—if no image is wanted, it should not be included in the navbox.
  • I purged Template:Navbox/testcases and checked them. They all look good with some minor differences which are improvements:
    • At "Missing List1 Test", the current navbox starts with List2 having a gray background because 2 is even. However, navbox/sandbox starts with the normal white background because it does not use the list number to determine the color.
    • At "Missing List1 and List2 Test", the current navbox shows the two lists with white background because both numbers are odd, whereas navbox/sandbox applies the normal striping.
  • I previewed some tests with {{Navbox with columns}} and {{Navbox with collapsible groups}} as the outermost navbox, and with a list consisting of a subgroup (child) navbox. Using

    |list1 = {{Navbox/sandbox|subgroup

    did not stripe the subgroup navbox and the page was in Category:Navbox orphans. Fixing the subgroup to be the following made the striping work and removed the category:

    |list1 = {{Navbox/sandbox|subgroup|orphan=yes

    An orphan navbox is a subgroup (child) navbox which is not contained in a normal navbox—that is, the child navbox does not have the correct parent. The category will need monitoring to detect any problems. Adding orphan=yes makes the child navbox work like a normal navbox as far as striping is concerned, and removes the category.

@Jc86035 + Izno + Frietjes + anyone: Any thoughts? Johnuniq (talk) 04:40, 10 March 2017 (UTC)

Anyone wanting to examine the output from a navbox may like to try displaying the formatted html. Johnuniq (talk) 09:21, 10 March 2017 (UTC)

@Johnuniq: Obviously I'd like to have this implemented, though the header still requires some CSS changes (I think) and we need to update {{Navbar-collapsible}} from its sandbox version if any CSS changes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:09, 11 March 2017 (UTC)
@Jc86035: I don't know anything about that so I'll leave it to you. However, do you want to do your changes first (before the module is changed)? If it looks like I'll have a few hours where I can monitor any disasters, I was thinking of switching the module sometime from 12 to 24 hours from now. Should that be delayed? Johnuniq (talk) 06:42, 12 March 2017 (UTC)
@Johnuniq: I think the CSS should be changed after the module, as the current padding is necessary for centring the title text. The sandbox version is fine with both sets of padding in use, although there will be some minor display changes for multi-line titles (but not worse than the current display). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:12, 12 March 2017 (UTC)
Ah, I was thinking of something in the module but of course you are referring to changes to the CSS for what the module outputs. Johnuniq (talk) 07:15, 12 March 2017 (UTC)

I updated Module:Navbox. Revert if any problems seen, but also please record what the problems are and where they occur. Johnuniq (talk) 23:53, 12 March 2017 (UTC)

To be investigated

Some interesting problems are reported in Category:Navbox orphans:

  • Alphabet#Types has a navbox as the caption to an image. The navbox uses {{Navbox with columns}} as {{Navbox with columns|child|...}}.
  • Farmer v. Brennan Copy the infobox ({{Infobox SCOTUS case}}) to a sandbox then preview. The preview shows the above hidden category. Searching the html source for "_ODDEVEN" shows the broken style for "Chief Justice" and "Associate Justices".

The good news is that the articles do not show any problems. Previewing the article with the old module gives an identical display on my system. Johnuniq (talk) 01:05, 13 March 2017 (UTC)

I fixed the {{Infobox SCOTUS case}} issue with this edit to replace "child" with "border=none" in a navbox.
What can be done with the infobox {{Argentine state}}? Currently that page is displaying cached html from before Module:Navbox was updated and the page is not in the tracking category. Also, the headings such as "before 1500" are properly centered. However, my sandbox (permalink) is displaying the infobox using the updated module, and it is in the tracking category. That can be fixed but there is a problem: the headings are not properly centered. @Jc86035: Any thoughts about centering? Johnuniq (talk) 09:34, 13 March 2017 (UTC)
@Johnuniq: The headings are left-aligned, which obviously doesn't work very well with 4em padding on both sides. Maybe change it to use {{Sidebar with collapsible lists}}, which I think is a better fit (plus it renders on mobile). Not rendering on the mobile site could also be a problem for a lot more of these pages, so they would ideally use other templates. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:22, 13 March 2017 (UTC)
Fixed it. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:25, 15 March 2017 (UTC)

Following the recent change (above), several templates are, or will be, in Category:Navbox orphans and that puts around 140 articles in the category. There will be more as the job queue catches up. Templates with the problem are in the API list.

I need help to fix these since I'm just a Lua person!

Johnuniq (talk) 03:52, 15 March 2017 (UTC)

@Johnuniq: Fixed {{Dutch film list}} by removing the navbox, will fix Paris Métro templates by converting them to normal navboxes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:12, 15 March 2017 (UTC)
this tracking category has also help find broken navboxes like the one I fixed here. very useful code/category. Frietjes (talk) 13:34, 23 March 2017 (UTC)

Bug with collapsible navbox?

For example, if I go to Carbon_monoxide#Lasers, and click "show", it scrolls me up to the top of the page and the navbox is never open at all. What is wrong? Llightex (talk) 13:14, 16 May 2017 (UTC)

@Llightex: It works for me. Try clearing your cache or purging the page (add ?action=purge to the end of the URL). What browser are you using, and do you have any scripts enabled? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:29, 16 May 2017 (UTC)
@Jc86035: You're right, it was due to a script. Thanks!

Alignment

Is it possible to fix cases like this so that |image= content is automatically aligned to the right, |imageleft= content to the left, and main content always centered? --Obsuser (talk) 05:35, 19 May 2017 (UTC)

@Obsuser: What's the issue in the linked page? I'm not sure what the problem is. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:17, 19 May 2017 (UTC)
Right image is not aligned "totally" right (what looks better and is more intuitive to expect), and bigger issue – main content (block of hlist items) is not centered but pushed to the left. /Win7, Chrome/
This is not noticed maybe when there is more links but in this case it is.
Image alignment can be fixed by adding either |imagestyle=text-align:right (|imageleftstyle=text-align:left) or |right (|left) in the [[File:]] syntax. But is is case with every image i.e. chance that someone added this is smaller than that one didn't (as in my example). Main content is not centered in any case. I played in sandbox with previewing modification of adding the same image on the left if right is defined and left is not (and same image on the right if left is defined and right is not) with visibility:hidden in order to center content but column tags got mixed and it did not work...--Obsuser (talk) 09:39, 19 May 2017 (UTC)
@Obsuser: the common fix for centering the list in that case is to use |liststyle=padding-left:50px to offset the 50px width of the image on the right. Frietjes (talk) 14:04, 20 May 2017 (UTC)
Can this be fixed automatically? --Obsuser (talk) 15:21, 20 May 2017 (UTC)

Merging nowrap navbox

From the MfD, it is proposed that some features of the above module be merged into Module:Navbox. The proposal is that a new parameter be added. If the parameter is set to yes, each item in each list would be processed by the module to replace:

item

with:

<span class="nowrap">item</span>

The nowrap span would not be added if it is already present.

Module:Navbox with nowrap lists currently applies that processing to items in each listN parameter, and to parameters above and below (it would also process the seldom-used aboveclass + abovestyle + belowclass + belowstyle although I assume that is unwanted).

For the parameter name, a December 2014 discussion at Template talk:Navbox/Archive 18#Nowrap lists proposed:

  • |nowraplists=yes (from Frietjes; Edokter said that was ambiguous)
  • |nowraplistitems=yes (from Edokter)
  • |nowrapitems=yes (shorter alternative from Edokter; supported by Frietjes at MfD)

Questions:

  1. Is a parameter in {{Navbox}} doing the above wanted?
  2. Should the parameter be named nowrapitems?
  3. Should parameters above and below have the nowrap processing?

Johnuniq (talk) 04:47, 23 March 2017 (UTC)

@Johnuniq: Not sure; yes; and yes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:03, 23 March 2017 (UTC)
@Johnuniq: yes, yes, yes. note that this would allow for the merger of template:Team roster navbox / Module:Team roster navbox as well, and allow for the removal of explicit &nbsp; and {{nowrap}} markup from a large number of navboxes. I could see a case for |nowrapitems= for all items, and |nowraplistitems= for just the items in the lists parameters, but I think starting with just |nowrapitems= for all items would be a great start. Frietjes (talk) 13:19, 23 March 2017 (UTC)
I suppose my question: Edokter says the nowrap CSS in Common.css was removed because IE would not cooperate. Is that still the case? Is that still the case with modern browsers? If not, I would propose that we should re-instate the CSS that was removed instead. (Ref MediaWiki talk:Common.css/Archive 15#Horizontal lists: Default nowrap behaviour for list items disabled perhaps.) --Izno (talk) 16:22, 23 March 2017 (UTC)
Izno, the only potential problem is that we have gone so long now without nowrap for hlists, that turning it on by default could cause problems. I recall having to add {{allow wrap}} to long list items (e.g., footnotes) before the nowrap css was disabled. but, I wouldn't object if people feel that the good outweighs the potential problems. I think it would take longer to get nowrap for hlist back into MediaWiki:Common.css than it would to add something here. Frietjes (talk) 19:36, 23 March 2017 (UTC)
I'm skeptical. The principal objector in the previous case (and who was otherwise generally careful with site CSS, JS, and templates) is who-knows-where. I would guess that the majority of people here would be willing to sacrifice the offending browser(s). --Izno (talk) 19:46, 23 March 2017 (UTC)
How can this be moved forward? Would WP:VPT be the right place to ask about the technical issues such was whether restoring the nowrap CSS would be desirable, and which browsers might be affected, and whether that is a problem. First, it would be helpful to find a link to something specific about the "nowrap CSS" that I know nothing about. Hmm, perhaps 17 November 2013 is a diff showing Edokter removing the CSS that is now wanted. The edit summary was "hlist: removing default list item nowrap behaviour; it causes to many issues in IE, and each fix causes even more issues", and it was briefly discussed here. Johnuniq (talk) 03:04, 24 March 2017 (UTC)
I'd start at MT:Common.css and if no response, invite editors at VPT (as well as here, and perhaps TT:Sidebar). --Izno (talk) 14:23, 24 March 2017 (UTC)

and, the entire process has been torpedoed again, with the added bonus of having functionality removed this time (module was deleted with no solution added). I still don't understand why we can't just add something to this module as suggested above. Frietjes (talk) 14:40, 1 May 2017 (UTC)

OK I'll start on this and should have it in the sandbox soon. Will post here. Johnuniq (talk) 01:39, 2 May 2017 (UTC)
@Frietjes: I will never understand what all the css stuff is doing and fortunately I do not need to. However, I see that class="nowraplinks..." is in the output of a navbox (see my sandbox2 or permalink). Very briefly and only if you happen to know, what is that about and what would be the effect of nowrapitems=yes at say Atlanta Braves#Current roster? Is that article the kind of thing aimed at? If not, what is? I would feel more comfortable if I knew what the module changes should achieve in a sandbox test, so if you have an example demonstrating the issue, you might like to edit my sandbox2 to replace its contents. Johnuniq (talk) 04:23, 2 May 2017 (UTC)
I updated sandbox2 to show a navbox with a list. I think that is the issue? That means the module needs to break each listN item into lines, and put the nowrap around each line, but if there is an asterisk at the start of the line, do not include it in the nowrap? LOL, it's all coming back to me now because I looked at it before. Johnuniq (talk) 05:07, 2 May 2017 (UTC)
Relax everyone! I found my note where I had copied the now-deleted Module:Navbox with nowrap lists and that makes it clear what is wanted. Johnuniq (talk) 05:50, 2 May 2017 (UTC)

I updated the sandbox module to handle nowrapitems=yes. I will examine the code in the next day or two because it was rather rushed and is untested. Please use {{navbox/sandbox}} to try it out. It would be good if a few simple tests could be put somewhere, possibly my sandbox2. Johnuniq (talk) 11:50, 2 May 2017 (UTC)

Johnuniq, thank you, anything using Template:Team roster navbox would be a potential test case. other test cases include Template:US Presidents, and possibly Template:Orders, decorations, and medals of the United Kingdom (see note in the source). Frietjes (talk) 12:50, 2 May 2017 (UTC)
@Frietjes: I put a demo in my sandbox2 (permalink). Please carefully examine it, and preferably examine the html source, to check everything seems ok. If you confirm that it is ready, and no one sees any problems, I will update the main module. — Preceding unsigned comment added by Johnuniq (talk • contribs)
Ping for Frietjes, since John's post will not have pinged (missing sig). --Izno (talk) 12:00, 3 May 2017 (UTC)
Johnuniq, thank you, looks great. I diffed the HTML source and the only change is the addition of the "span nowrap" tags, which is exactly what we want. I also diffed the output from the live and sandbox version, and there were no differences when nowrapitems was not equal to yes. so, I would say it's ready to go. thank you again. Frietjes (talk) 13:11, 3 May 2017 (UTC)
OK, it's live. Johnuniq (talk) 01:49, 4 May 2017 (UTC)
Johnuniq, thank you. I tried it in Template:Champion shot medals and it appears to be working well. Frietjes (talk) 14:50, 4 May 2017 (UTC)
Here's a list of some to look at updating -- WOSlinker (talk) 18:48, 4 May 2017 (UTC)
WOSlinker, thank you! I updated most of the entries on the list. one interesting quirk that I found while working through the list is the following: 
{{Navbox | listclass = hlist | nowrapitems = yes | list1 =* {{MOSMETRO-bull|11|text=2}} }}
. Johnuniq, any ideas on what is going wrong with this one? otherwise, it looks like it's working great! Frietjes (talk) 20:01, 4 May 2017 (UTC)

@Frietjes: Special:ExpandTemplates gives the following result for {{MOSMETRO-bull|11|text=2}}: 

[[Third Interchange Contour|<span title="
#11 Third Interchange Contour"><span style="font-weight:bold"><span style="font-family:sans-serif;font-size:15px;color:
#fff;background-color:
#000000;;border-radius:15px;line-height:15px;"><span style="letter-spacing:-1px"> 11 </span></span></span></span>]]<span > [[Third Interchange Contour|Third Interchange Contour]]</span>

The above is four physical lines. The last three lines start with "#" and the module (when nowrapitems=yes is used) interprets them as forming a numbered list, so the module inserts the nowrap span around the rest of the physical line that follows each "#". I guess that MOSMETRO-bull should be fixed so it does not produce separate lines. Is that reasonably achievable? Johnuniq (talk) 22:49, 4 May 2017 (UTC)

Fixed with some edits to {{MOSMETRO-bull}} and {{font}} -- WOSlinker (talk) 07:42, 5 May 2017 (UTC)
looks like that fixed it, so the lesson here is to look for constructs like {{#if: ... | #00AABB }} since the parser inserts a newline before the # making it look like an ordered list item. Frietjes (talk) 13:50, 5 May 2017 (UTC)

Is there a way to stop separator middle dot from detaching from previous item? Sometimes it gets displayed at the very beginnig of the new line. It could be done in a similar way as external link icon is handled in CS1 modules. --Obsuser (talk) 15:43, 7 May 2017 (UTC)

Is this with the new nowrapitems=yes parameter, or is that irrelevant?
Navbox does not control middots in any way I can see. Given a list of three items, navbox outputs html for the list as follows:
<tr>
  <th scope="row" class="navbox-group">Three examples</th>
  <td class="navbox-list navbox-odd hlist" style="text-align:left;border-left-width:2px;border-left-style:solid;width:100%;padding:0px">
    <div style="padding:0em 0.25em">
      *Example 1
      *Example 2
      *Example 3
    </div>
  </td>
</tr>
Someone might have a suggestion how that could be tweaked. Johnuniq (talk) 01:53, 8 May 2017 (UTC)
In Russian Wikipedia we just use hlist-items-nowrap class in ru:MediaWiki:Common.css for nowrap items. Iniquity (talk) 19:22, 1 June 2017 (UTC)

Border-spacing instead of gutter rows

I'd like to propose using CSS border-spacing for layout rather than HTML gutter rows. I've made the relevant changes at Module:Navbox/sandbox. Template:Navbox/testcases should show no significant differences in modern browsers or IE ≥ 8. Matt Fitzpatrick (talk) 05:52, 17 May 2017 (UTC)

@Matt Fitzpatrick: The padding between groups and lists seems to too wide (especially for the odd-numbered/grey rows). The border-spacing might work better at 0.15em instead of 0.2em, although it doesn't fix the aforementioned issue. (Firefox 53.0.2.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:29, 17 May 2017 (UTC)
@Jc86035: Got it, thanks! I tweaked the border-spacing to be vertical, i.e. between rows, only. Matt Fitzpatrick (talk) 06:45, 17 May 2017 (UTC)
@Matt Fitzpatrick: There are also some issues with child navboxes, like in Template:Navbox/testcases#Subgroup tests and Template:Navbox/testcases#Container tests. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 06:55, 17 May 2017 (UTC)
@Jc86035: Phew! After much trial and error, it looks like the best solution might be to go back to basics. This sandbox diff just strips the gutter rows, nothing fancy. This CSS, once merged into the sitewide CSS, applies the new borders. :first-child is CSS 2.1, so this should work all the way back to IE 6. Matt Fitzpatrick (talk) 12:13, 17 May 2017 (UTC)
Got it down to one new CSS rule instead of two (diff). Tested on IE7 and 8, seems okay. Will put in a common.css edit request in a few days if no problems come up. Matt Fitzpatrick (talk) 06:32, 27 May 2017 (UTC)
FYI, I had to change navbox Canada to use box-shadows instead of borders after this change. there may be other templates which were using borders. but, the fix isn't that difficult. Frietjes (talk) 15:18, 3 June 2017 (UTC)
@Frietjes and Matt Fitzpatrick: There may be as many as 200 of them (although there might be more; example fix). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:21, 24 June 2017 (UTC)
@Jc86035 and Matt Fitzpatrick: it would be possible to automatically transform inside of navbox, but that might be a bit much. so, for now, I created Template:Box-shadow border to simplify the syntax. let me know if you see any problems with the implementation, or would like to change the parameter order, etc. thank you. Frietjes (talk) 14:49, 25 June 2017 (UTC)
@Frietjes: Works well; thanks for creating the template. I've fixed a few more templates, although they may need to be gone through again because many of the ones I've fixed are international sports navboxes which are supposed to use consistent colours across the series for each continent but don't due to arbitrary ordering of groups. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:10, 25 June 2017 (UTC)
@Jc86035 and Matt Fitzpatrick: in renderNavBar we have 'border:none' to stop the V-T-E links from inheriting border styling from the titlestyle / basestyle. if we are going to use box-shadow for the borders in the basestyle or titlestyle, we probably want to add something similar for 'box-shadow', '-moz-box-shadow', '-webkit-box-shadow'? I had to execute this revert since it was adding box-shadows to the V-T-E links. Frietjes (talk) 23:00, 28 June 2017 (UTC)
@Frietjes: Added a box-shadow test at Template:Navbox/testcases#Navbar and state tests. There's probably a nicer way to strip CSS declarations from the navbar, but this change seems to work for now. Matt Fitzpatrick (talk) 00:20, 29 June 2017 (UTC)
Matt Fitzpatrick, thank you. if you look at the extractstyle function in Module:Team roster navbox, I pull out only the color and background from the style to pass on to the span inside the links. that module could probably be merged with this one at some point. the only thing that it does that the standard navbox module doesn't do is automatically color links. Frietjes (talk) 13:35, 29 June 2017 (UTC)

Localization

Hello, can anybody help me? I want to move arguments from ru:Module:Navbox to a datatable (for example ru:Module:Navbox/data), is it possible? I am using local variables for localization now, but I think it is a bad way. Iniquity (talk) 23:56, 1 July 2017 (UTC)

Padding for images and width for Authority control cell

Could someone review and add these edits: 5px padding for images and removal of width:auto in Authority control template so that this cell does not get too wide? --Obsuser (talk) 17:25, 9 July 2017 (UTC)

I have too little context here to evaluate these changes. Please provide examples, argumentation etc. —TheDJ (talk • contribs) 17:48, 9 July 2017 (UTC)

Technical implementation of hiding on mobile site

How is the hiding of navbox templates on mobile implemented? I thought it was done through mediawiki:mobile.css, but it looks like that rule was removed in May 2016. --Ahecht (TALK
PAGE) 20:17, 31 July 2017 (UTC)

@Ahecht: skins.minerva.content.styles/hacks.less. phab:T124168 is the design task related to displaying them. --Izno (talk) 20:31, 31 July 2017 (UTC)
@Ahecht: Reping. --Izno (talk) 20:31, 31 July 2017 (UTC)

In the documentation, it states that It is recommended that one use {{Navbox subgroup}}, but the same result can be reached by using {{Navbox}} with border = child or the first unnamed parameter set to child.. can someone explain why it's recommended to use {{navbox subgroup}} instead of {{navbox|subgroup}}? I would think the recommendation would be the reverse since (1) using {{navbox subgroup}} is less efficient due to the additional wrapper later, and (2) {{navbox subgroup}} cannot support more than 20 groups/lists. I am guessing that this recommendation (which was added by CapitalR in this edit) was true in the past, but is no longer true? Frietjes (talk) 21:18, 14 July 2017 (UTC)

While working on Module:Navbox last March I wondered about {{Navbox subgroup}} but ended up ignoring it as what I was doing was already complex. A very quick look at the wikitext in {{Navbox subgroup}} suggests that it tries to pass all parameters to {{Navbox}} except that grouppadding defaults to 0em 0.75em;. Is {{Navbox subgroup}} useful? I have not followed the work done on the module recently regarding using css, but presumably any default padding should be set there. Johnuniq (talk) 23:24, 14 July 2017 (UTC)
I agree that we should be setting any padding for subgroups in MediaWiki:Common.css, and to avoid confusion we should have the same group padding for both {{navbox subgroup}} and {{navbox|subgroup}}. checking the current MediaWiki:Common.css I see padding: 0.25em 1em which is close to the 0em 0.75em value. if we really want to have less padding for groups in subgroups, I believe we can handle that in MediaWiki:Common.css as well. It would be great if {{navbox subgroup}} were a very thin frontend that was functionally equivalent to {{navbox|subgroup}}. Frietjes (talk) 23:40, 14 July 2017 (UTC)
for a comparison try
{{navbox| group1 = group1| list1 = {{navbox subgroup | group1 = group1a | list1 = list1a}}}}
{{navbox| group1 = group1| list1 = {{navbox|subgroup | group1 = group1a | list1 = list1a}}}}
Frietjes (talk) 23:42, 14 July 2017 (UTC)
I put an example in my sandbox (permalink). I can hardly see a difference. Does anyone know of cases where {{navbox subgroup}} should not be replaced with {{navbox}}? Johnuniq (talk) 00:37, 15 July 2017 (UTC)
I don't know of any. If I recall, we used to have Template:Navbox generic and Template:Navbox subgroup, so the slight difference may be something left over from the merge. Thanks! Plastikspork ―Œ(talk) 12:42, 15 July 2017 (UTC)

There are thousands of templates that link to Template:Navbox subgroup. Previewing what happens if the subgroup template is not used shows a very minor difference in spacing—if that difference is desirable, it should be in the main template. Any thoughts on how to proceed? The cautious approach would be to edit a couple of navboxes from the "what links here" list to replace
{{navbox subgroup|...}} with
{{navbox|subgroup|...}}
then see what happens. A faster strategy would be to replace {{navbox subgroup}} with a redirect to {{navbox}}. Johnuniq (talk) 04:34, 20 July 2017 (UTC)

Johnuniq, it would be great if we could make this work. Frietjes (talk) 19:55, 17 August 2017 (UTC)
That should be easy. I think the requirement is that the module should get the navbox parameters from the template, but use the border=... parameter if it is given in the module invoke. I'll ponder that later. Ping me if I go AWOL. Johnuniq (talk) 23:10, 17 August 2017 (UTC)
@Frietjes: I got distracted with some idiocy. I don't use Module:Arguments and so am not really aware of what's going on, but a quick look makes me think your {{#invoke:Navbox|navbox|border=...}} at Template:Navbox subgroup/sandbox (permalink) would have worked. That template is not listed as a "wrapper" so I would have thought the border parameter in the invoke would be accepted. Can you recall what made you decide it did not work? Johnuniq (talk) 11:36, 18 August 2017 (UTC)
Johnuniq, as far as I can tell, it still doesn't work, and Module:Navbox uses Module:Arguments. before this change and this change, it wasn't reading any of the parent args (as expected). after adding "navbox subgroup" to the list of wrappers, it now ignores the border parameter (see User:Frietjes/n). Frietjes (talk) 14:16, 18 August 2017 (UTC)
@Frietjes: I don't understand what's going on. Previewing lots of debugging tests showed that the border parameter never made it into the module but I could not work out why. I decided to remove the wrappers stuff, and now it's working. I will return to ponder what's going on another time.
Does Template:Navbox subgroup/sandbox appear to be working as far as you can see? Johnuniq (talk) 05:45, 19 August 2017 (UTC)
Johnuniq, as far as I can tell, that works. I don't know if there is any possibility of introducing new problems by not checking the invoking parent's name. I suppose we can always make the change and see if anything bad happens. Frietjes (talk) 13:47, 19 August 2017 (UTC)
Yes, I think you could put the sandbox code in the main module but when I get some time (soon!?) I plan to work out why the current code misses the parent border in the subgroups template. It shouldn't! What I'd really like to do is work out if Module:Arguments is doing anything needed by Module:Navbox because the arguments layer is obscuring what's going on. I probably won't do anything about that. Johnuniq (talk) 01:24, 20 August 2017 (UTC)

Bug report - Link to current page in a navbox not disabled when it is via a redirect.

Link to current page in a navbox not disabled when it is via a redirect. Example: Wickham Terrace, Brisbane is a redirect to Wickham Terrace. When a navbox link to Wickham Terrace, Brisbane is viewed in Wickham Terrace it is not disabled. Downsize43 (talk) 01:09, 22 August 2017 (UTC)

Downsize43, have you tried opening Template:Road infrastructure in Brisbane and fixing the link? as far as I can tell, that template is not protected. Frietjes (talk) 20:35, 22 August 2017 (UTC)
Frietjes, thanks for your reply. I have fixed the link, but that does not address the bug when a redirect is inadvertently used. In the example given the redirect page is the correct format for the article, while the article title is one of those special cases often found for a subject which is the first of, or the only one of, in the known universe, that has an article in WP (rather strange for a fairly insignificant street, I know) Cheers, Downsize43 (talk) 22:05, 22 August 2017 (UTC)
This is not a bug which can be fixed save by fixing the link in the navbox, or removing the link in the navbox (if the target of the redirect is no longer appropriate for the navbox). --Izno (talk) 02:08, 23 August 2017 (UTC)

In theory, couldn't this be fixed by checking the redirectTarget of each linked page with the mw.title library? But it might not be desirable because it could use up too much of the expensive parser function quota on a page with a lot of navboxes. Toohool (talk) 02:42, 23 August 2017 (UTC)

Probably could be, but the social practice of fixing the links is better anyway (and is suggested by WP:NAVBOX). --Izno (talk) 03:52, 23 August 2017 (UTC)

Import to lb.wikipedia.org

Hello I always get an error when using templates that rely on Module:Navbox. I get always this error: Lua-Feeler in Modul:Navbox, Zeile 241: attempt to index local 'listText' (a nil value). How can this bug be fixed? --Soued031 (talk) 11:50, 6 September 2017 (UTC)

Please link to a page (possibly a sandbox) which shows the error. Johnuniq (talk) 01:16, 7 September 2017 (UTC)
I did notice that Module:Arguments and lb:Modul:Arguments are different. -- WOSlinker (talk) 05:29, 7 September 2017 (UTC)
Thanks WOSlinker you were right the error happened because Module:Arguments and lb:Modul:Arguments are different. Thanks for the very fast answer. --Soued031 (talk) 08:52, 7 September 2017 (UTC)

Throw template calling this module into maintenance category under certain conditions

Is it possible to do the following? If a page directly invokes Module:Navbox, if the value at name= does not equal {{BASEPAGENAME}}, can the invoking template (but not the pages that transclude the template) be placed in a maintenance category? Steel1943 (talk) 22:33, 18 September 2017 (UTC)

That might be possible but I would have to do some serious thinking which won't happen for a while as I'm doing stuff at Commons. If no one else has ideas, consider pinging me in a week or two. You might mention an example of where the category would be useful, and briefly why. Any ideas on a category name (generic is best to allow re-use for something else)? Johnuniq (talk) 23:18, 18 September 2017 (UTC)
@Johnuniq: Here's an example. I just happened per chance to find this. I assume you know this, but since the two did not match, when I clicked the "E" in the "V - T - E" on the template transclusion, I was directed to edit the redirect instead of the template. If such mismatched were thrown into a maintenance category, they would be easier to detect. For the category name, possibly Category:Navbox templates with title and name parameter mismatch? Steel1943 (talk) 23:50, 18 September 2017 (UTC)
OK, I'll think about it later. Johnuniq (talk) 01:36, 19 September 2017 (UTC)
If possible, it might be preferable to implement in Module:Navbar so that Module:Sidebar can benefit also. --Izno (talk) 02:18, 19 September 2017 (UTC)
@Izno, Johnuniq, and Steel1943: Although it's not instantaneous, we do have Wikipedia:Database reports/Invalid Navbar links, which is updated once per month. Thanks! Plastikspork ―Œ(talk) 04:40, 19 September 2017 (UTC)
@Plastikspork: Interesting; I could be asking the wrong question ... and on the wrong talk page. Now, I wonder if there is a way to trigger all templates referenced on Wikipedia:Database reports/Invalid Navbar links to go into a maintenance category rather than use that database report page. Steel1943 (talk) 15:08, 19 September 2017 (UTC)
The database report does a monthly scan of the wikitext and generates warnings about problems it finds. It cannot and should not edit pages. My quick look of the report failed to find the page you mentioned—I don't have time to investigate. Adding tests to templates/modules causes the overhead to mount up and that expense is paid many, many times as affected pages are rendered in the future. There are over three thousand tracking categories so there are plenty of issues that need addressing. Johnuniq (talk) 22:34, 19 September 2017 (UTC)

Utterly disable category handling

I would like to have absolutely 100% control over all of the categories on my platform, but I cannot for the life of me prevent Navboxes from being automatically categorized. I have utilized |nocat=true, and while this has worked elsewhere, isn't doing a single thing to help on my created Navbox template. I would greatly appreciate any information on how to suppress these categories(or category handler altogether, if possible.) 2602:304:CF7D:A010:AC12:8F5E:4AC2:39B6 (talk) 02:16, 26 September 2017 (UTC)

your edit history shows only this page, so it's hard to tell what exactly you are talking about. Frietjes (talk) 19:19, 26 September 2017 (UTC)

language

Should there be e.g. |groupnlang= parameters? Are they necessary? I tried replacing an incorrect use of {{lang}} (which uses a span tag) in {{Irish names}} with |groupnstyle=" xml:lang="ga" lang="ga but it doesn't seem ideal. Jc86035 (talk) 14:24, 24 December 2017 (UTC)

Jc86035, creative, but it's the lists that are in Gaelic, not the group labels. couldn't you also fix it by using <div>...</div> instead of <span>...</span> with the lang tagging? Frietjes (talk) 14:37, 24 December 2017 (UTC)
@Frietjes: Thanks for catching that, though the span disappears from the source because of Tidy. Maybe {{lang}} could have a |div=yes? Jc86035 (talk) 14:40, 24 December 2017 (UTC)
Jc86035, yes, it appears tidy is distributing the spans to all of the list entries. this is nice, but since tidy is being replaced with lint, so who knows what will happen then. I have replaced it with divs for now. Frietjes (talk) 14:47, 24 December 2017 (UTC)
I think this is a limited-enough case that lang parameters for each list are unnecessary. I've also removed xml:lang since that is not conformant in HTML 5. The use of the div is how I would generally mark this up. --Izno (talk) 18:32, 24 December 2017 (UTC)
indeed, the backend software adds the xml:lang to the source. Frietjes (talk) 13:27, 25 December 2017 (UTC)
@Frietjes: Tidy does that and it should go away when Tidy does. phab:T46609. --Izno (talk) 14:23, 25 December 2017 (UTC)
sure, and according to the link you provided, it's looks harmless since it has "no effect on language processing". but, if it has no effect, there is also no reason to add it. Frietjes (talk) 14:42, 25 December 2017 (UTC)

I discovered that the wikipedia red link color on the standard navbox title color does not obey the WCAG 2.0 standards for text color contrast below 18pt. Not sure what to do about this. I started a discussion about this at WT:WikiProject Accessibility#Wikipedia red link on wikipedia standard navbox title violates WCAG 2.0, feel free to join in. —hike395 (talk) 07:33, 3 January 2018 (UTC)

Tracking old style borders

after changes to this module, the "old style" css borders no longer work as expected. The fix is to replace them with box-shadow borders like this. does anyone object to adding tracking to find these? I have put some code in the sandbox. Frietjes (talk) 19:03, 8 January 2018 (UTC)

This is above my head but I looked at the diff between the main and sandbox modules and it looks good. However, what is the pipe doing in:
args = getArgs(frame, {wrappers = {'Template:Navbox|subgroup', 'Template:Navbox'}})
I don't use Module:Arguments enough to know whether a pipe would do anything useful. I would have thought that each string in the wrappers table had to be the name of a template. Johnuniq (talk) 23:38, 8 January 2018 (UTC)
Johnuniq, thanks for spotting the error. I had been replacing 'navbox subgroup' with 'navbox|subgroup' and forgot to turn off the script before editing the module. now corrected. by the way, if you have time to figure out how to make Template:Navbox subgroup/sandbox work with the getArgs, that would be great. you can probably experiment with "Navbox subgroup" directly since the transclusion count is low. Frietjes (talk) 00:34, 9 January 2018 (UTC)
@Frietjes: What shows that it is not working? See test at sandbox2 (permalink). Johnuniq (talk) 02:13, 9 January 2018 (UTC)
Johnuniq, I added a comparison with the live version. basically, the only parameter being passed explicitly, the border, is not recognized. Frietjes (talk) 13:50, 9 January 2018 (UTC)
@Frietjes: So the problem is that Template:Navbox subgroup/sandbox invokes Module:Navbox/sandbox and passes a border parameter. The expected behavior is that the border parameter from the template would be merged with the parameters from the parent, that is, from the wikitext in User:Johnuniq/sandbox2. The reason that is not happening is due to the use of wrappers in the module:
args = getArgs(frame, {wrappers = {'Template:Navbox subgroup', 'Template:Navbox'}})
Edit the sandbox module and change the above line to:
args = getArgs(frame)
then paste User:Johnuniq/sandbox2 into the "preview page with this module" box and Show preview. The idea of Module:Arguments is to merge arguments from the invoking template and the parent wikitext, but that is usually unnecessary overhead. Therefore wrappers can be used to specify the templates which do not pass parameters (they merely wrap the module) and which therefore do not need merging. I can't understand the documentation for Module:Arguments so experiment would be needed to determine what would happen if a border parameter was passed in the parent wikitext as well as from the template. Johnuniq (talk) 02:30, 10 January 2018 (UTC)
Johnuniq, yes, I had experimented before with removing the wrappers parameter, and found that it worked. however, I have no idea why it doesn't work with the wrappers parameter. looking at Module:Arguments it should be looping over the entries in the table of wrappers and passing them to the "matchesTitle" function? assuming that part is working, then there must be a logic mismatch between the "wrapper" and "no wrappers" branches of the code. Frietjes (talk) 15:59, 10 January 2018 (UTC)
after reading the documentation for Module:Arguments some more, I see that if it is a wrapper, then it won't parse the parent args? so, if that is the case, we definitely don't want "navbox subgroup" to be listed as a wrapper. another option would be to have a separate "subgroup" entry point into the module, but that seems a little excessive considering how few transclusions there are of "navbox subgroup" at the moment. Frietjes (talk) 16:03, 10 January 2018 (UTC)
@Frietjes: We discussed this in July 2017 here. I forget all about that, but I see that my local copy of Module:Navbox had some code to get border from the template. I don't know if I ever tried that out last August, but I put it into Module:Navbox/sandbox just now. Does that work?
Re "if it is a wrapper, then it won't parse the parent args?": Module:Args always gets the parent args (that is, the arguments from User:Johnuniq/sandbox2 in our example). There may be a way to turn that off so "always" may be a bit strong, but the cases I have seen always involve getting the parent args. The purpose of wrappers is to avoid the overhead of merging arguments from the template—if it is a wrapper, then an argument in the wikitext of the template definition will be ignored. If the template might have various arguments that should be merged, you would omit the template from wrappers. In the case we are considering, the only template parameter is border so my edit checks for that only. It should work! Johnuniq (talk) 02:48, 11 January 2018 (UTC)
Johnuniq, looks good, I have updated the main template. by the way, I hope I didn't completely mangle Module:Football manager history. immediately after I turned on the tracking, pages using that module started popping up in the "uses basic css borders" tracking category, so I changed the borders to use the 'box-shadow borders'. unfortunately, the box-shadow borders (see {{box-shadow border}}) are more complicated, but without them you don't get the visual separation between the groups/above/below etc. please let me know (or correct it) if I screwed it up. Frietjes (talk) 13:14, 11 January 2018 (UTC)
In case it's not obvious, all I did in writing Module:Football manager history was emulate what the old template did. What you have done with the border is way over my head. Re the changes to the module, they look good. In addiflist it might be better to use ipairs for consistency—that's how a list should be iterated. Also, it would be a little more efficient to have addifsubst which takes a long string rather than a table. It would replace (substitute) each occurrence of %1 with item using gsub. However, your code is good and I am just mentioning my thoughts for completeness. By the way, your script might be doing more than wanted: check diff which changed "Carson–Newman" to "Carson to Newman". I might look at it more another time. There were quite a few problems when I converted a zillion articles using the system to the syntax preferred by {{Football manager history}}. I could see the template might be useful in other cases but I was exhausted by then. Johnuniq (talk) 06:53, 12 January 2018 (UTC)
I just had a look at my contributions. It was actually 1377 templates, not articles, OMG. I think I used a Python script to do the major edit (example), then manually checked if it had worked. Johnuniq (talk) 06:59, 12 January 2018 (UTC)
Johnuniq, the six or so conversions to Template:Football manager history were done by hand using search-replace, so it's not too shocking that I screwed one up. in any event, those changes were reverted, so it's not an issue at this point. the bigger idea would be to take the simplified colouring syntax from that module and make it generic. and, even better would be to take the automatic link colouring code from Module:Team roster navbox as well. Frietjes (talk) 13:24, 12 January 2018 (UTC)
Johnuniq, I simplified my changes to Module:Football manager history as suggested. hopefully it looks better now. thank you. Frietjes (talk) 18:11, 12 January 2018 (UTC)
The module changes are great, thanks. Later I could help with your "bigger idea" if wanted, and if I could see some simple examples of what is meant. Johnuniq (talk) 01:25, 13 January 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Navbox/Archive_21&oldid=889531677"