Module talk:WikiProject banner

WikiProject Higher education

I don't know if people are aware of the changes to Template:WikiProject Higher education which is now using a bespoke module to achieve some unusual behaviour (discussion here and here). The change allows editors to specify task forces by using a comma-separated list, i.e. |taskforce=cuny,uva instead of the more usual method of |cuny=yes and |uva=yes.

The problem is that some features are not working (e.g. quality assessment and unknown parameter checking) and it is permanantly in Category:Pages using WikiProject banner shell needing attention. So I was wondering if there is a better way to do this, or whether we should look at coding something similar more widely for other projects to use. — Martin (MSGJ · talk) 12:27, 5 June 2025 (UTC)

I have fixed the template — Martin (MSGJ · talk) 08:57, 10 June 2025 (UTC)

It seems that they wanted to store all their task forces in a configuration file instead of coding each one in the template. This allows the comma-separated list method of triggering each one, as well as keeping the configuration separate from the template code. I have mocked up an example of a config file at Template:WikiProject Higher education/config. It seems like a very neat way of working. The template would then become something as simple as

{{#invoke:WikiProject banner|main|project=Higher Education}}

Other advantages: we do not need to pass any parameters through the template, we could supply a list of parameter aliases instead of the horrible {{{a|{{{b|{{{c|}}}}}}}}} construct — Martin (MSGJ · talk) 13:28, 16 June 2025 (UTC)

I believe we have a working template for the moment, but we always had the vision of expanding this to other areas/uses, so would appreciate any support in making that happen..! Tduk (talk) 13:34, 17 June 2025 (UTC)

I'm still becoming familiar with this whole lua/template set-up. Would it be at all reasonable to have a parameter to WikiProject banner which points in some way to a helper lua module/function which can be passed the list of args, and return a modified list of args? (Sort of like what we ended up doing but in reverse). This would offer expandability in all sorts of ways. This might be what you've been angling towards yourself. Tduk (talk) 04:01, 18 June 2025 (UTC)

Please can you explain what you mean by "be passed the list of args, and return a modified list of args", preferably with an example? — Martin (MSGJ · talk) 09:23, 18 June 2025 (UTC)

Absolutely. If you took a look at my hokey lua module, you might see what I mean. But something like:

  if(args["ProjectArgs"]=="Higher Education") then
    args=HigherEducationArgParser(args)
  end

or, even better (if possible)

  if(args["ProjectArgs"]!=nil) then
    args=_G[args["ProjectArgs"]](args) -- or some other way to define the function name in the template
  end

placed somewhere appropriate in Wikiproject_banner, and written a bit more maintainably...

called like this:

{{#invoke:WikiProject banner|main|ProjectArgs=HigherEducationArgParser}}

If you wanted, this could be collapsed into how you were calling it:

{{#invoke:WikiProject banner|main|project=Higher Education}}

and the pseudocode might look like:

  local ProjectFunc=string.gsub(args["project"]," ","_") .. "_Argument_Function"
  if(ProjectFunc]!=nil) then
    args=_G[ProjectFunc](args) -- not sure this works in our framework 
  end

Apologies if there are errors, I never saw a line of lua until a few weeks ago, but I'd love to help in any way I can. Does this help explain what I mean? Tduk (talk) 13:51, 18 June 2025 (UTC)

I understand most of what you have written, but I still have no idea why you would want to do this, or what the end goal might be. What are you actually trying to achieve, that you can't do now? — Martin (MSGJ · talk) 16:46, 19 June 2025 (UTC)

Really, I'm thinking about the future. No one anticipated what @Pharos wanted to be able to do, but what he wants makes sense. I'm trying to think of a system by which others in the future can more easily sweeten the arguments (in lua rather than a cumbersome template) to WikiProject Banner. Does that make sense? Tduk (talk) 17:25, 24 June 2025 (UTC)

This looks really great to me, would be happy to adopt the Template:WikiProject Higher education/config system for that project, and then maybe see if other wikiprojects might be interested in it as well. Ideally this could go some way toward a simpler and more flexible system of wikiprojects/taskforces, especially if we're looking to consolidate more stuff as taskforces in the longer term. Pharos (talk) 17:12, 24 June 2025 (UTC)

I'll look at coding something in the sandbox — Martin (MSGJ · talk) 09:18, 25 June 2025 (UTC)

I coded a mock-up of my idea which I described above, so maybe you can see what it might accomplish if you see an example. See Template:WikiProject Higher education test2 (one additional arg, HELPER), Module:WikiProject banner ltest (small addition of code around line 150), Module:Higher education sweetener (essentially our original lua module but in reverse). Do you see how this might be useful down the road in ways we can't currently envision? Tduk (talk) 15:28, 25 June 2025 (UTC)

(anyone who wanted to add their own functionality would just need to provide the HELPER arg and their lua helper module - we could eliminate the arg and simply call it if an appropriately named one exists but that feels like asking for trouble). Tduk (talk) 15:34, 25 June 2025 (UTC)

conceivably the lua module could even read in the config file as spec'd above Tduk (talk) 15:37, 25 June 2025 (UTC)

Yes, that's what I had in mind. I have added some code to Module:WikiProject banner/sandbox and the effect can now be seen on Template:WikiProject Higher education/sandbox. Interested in your thoughts — Martin (MSGJ · talk) 11:13, 2 July 2025 (UTC)

Perfect, looks like you've solved the generalization problem entirely. Pharos (talk) 18:24, 7 July 2025 (UTC)

This does the job for this, but I would have liked to see a solution that was more expandable down the road by others that wouldn't require so much intervention into the actual banner lua code. (i.e. something less generic that wouldn't have a whole chunk of code just for taskforces in the global lua banner code) Does that make any sense? Tduk (talk) 02:05, 8 July 2025 (UTC)

No sorry, I can't understand your point. Can you give an example? I've put some of my thoughts below — Martin (MSGJ · talk) 15:30, 11 July 2025 (UTC)

Maybe I'm missing something; what happens when someone comes along with a new parameter they would like to be added to the configuration file? Tduk (talk) 17:28, 11 July 2025 (UTC)

My thoughts on the possible benefits to moving to the configuration page approach:

• Simplification of syntax so {{{parameter1|{{{parameter2|{{{parameter3|}}}}}}}}} is replaced with something like |trigger=parameter1, parameter2, parameter3
• Avoid having to pass through parameters completely, so things like |attention={{{attention|}}} will be removed
• Ability to do smarter things like comma-separated task forces (see above).
• Potentially add better support for projects like US Roads which uses |state=AL instead of |AL=yes and for Women in Red which uses an indefinite number of unnumbered parameters.
• More robust parameter checking and auto documentation which would include aliases. The current setup reads the wikicode of the template and attempts to work out what each parameter does. This has a performance impact.
• Significant simplification of module code which would make it easier for editors to maintain.

— Martin (MSGJ · talk) 15:29, 11 July 2025 (UTC)

I'm not sure I understand what you mean by "configuration page approach" - do you mean what you've implemented now? My concern is futureproofing it. My general approach though was basically coming from Object-oriented programming, specifically pointers to functions. I don't see a reason why both couldn't be implemented. Tduk (talk) 14:37, 1 September 2025 (UTC)

More populated category redirects

Category:NA-importance articles and Category:Unassessed List pages are being populated when they shouldn't be. Please can someone make the necessary code adjustments. Timrollpickering (talk) 21:10, 4 September 2025 (UTC)

The first one looks empty to me, except for an empty subcategory. For the second one, it seems that Template:WikiProject Lists/class is not detecting those two redirects, which is strange, because it does all of Category:Redirect-Class List pages (11,857) — Martin (MSGJ · talk) 21:35, 4 September 2025 (UTC)

Seems to be caused by slightly different methods of detecting redirects, which needs further investigation. In both cases the pages contained the word "#REDIRECT" but it was inside the RfD template which deactivates it. I have solved the issue for these two by closing to relevant RfD discussions — Martin (MSGJ · talk) 07:08, 5 September 2025 (UTC)

Deprecating the class parameter

The number of conflicts between project class and PIQA is rapidly approaching zero, thanks to Hawkeye7 and his bot. When these have been cleared, I would like to deactivate the class parameter for all banners except for projects which have opted out. In other words, setting |class= in these banners would have no effect, and it will be impossible to set a class locally and also impossible to create any more conflicted ratings. — Martin (MSGJ · talk) 22:19, 3 October 2025 (UTC)

Do we want that? I thought PIQA came with a promise that groups would always be able to disagree with the overall rating and use their own.

Side note: If we're going to make changes that are not strictly necessary, one of the things I'd like to see is |importance and |priority being aliases/interchangeable, and for both the rating scripts and the text of the banner to prefer 'priority' over time (but not necessarily the categories, because what a mess that would be). Nobody loves having the subject of their article declared to be "unimportant". WhatamIdoing (talk) 23:34, 3 October 2025 (UTC)

Groups can disagree and use their own scale by setting the |QUALITY_CRITERIA=custom parameter in their talk page template. Martin's suggesting we deactivate the class parameter for all banners except for projects which have opted out. Reading through the the proposal, and searching for the word "own" in the comments, it seems like this tacks with the consensus. It does go against one of the statements in the proposal:

• If the wikiproject banner supplies a class value that differs from the (non-blank) article class value, the talk page will be placed in a tracking category and the project class will be used to form categories like Category:C-Class Linguistics articles

but that kinda goes against the whole idea of PIQA. Also the last statement in the proposal says:

• A future project may consider bulk change to remove class= values from wikiproject banners where the value is the same as the article level class, and where the wikiproject uses the general Wikipedia:Content assessment approach. That is outside the scope of this proposal.

My vote is Agree, I think the class parameter should be deprecated where a project hasn't opted out.

Side note: Would you mind moving your notes about the importance ratings to their own topic? I don't think I agree with them and would like to discuss them separately. Cheers, Aluxosm (talk) 01:58, 4 October 2025 (UTC)

As long as we're not breaking any promises, then I think it'd be great. WhatamIdoing (talk) 03:50, 4 October 2025 (UTC)

Comment moved to new section below. — Martin (MSGJ · talk) 10:45, 4 October 2025 (UTC)

Importance and priority

If we're going to make changes that are not strictly necessary, one of the things I'd like to see is |importance and |priority being aliases/interchangeable, and for both the rating scripts and the text of the banner to prefer 'priority' over time (but not necessarily the categories, because what a mess that would be). Nobody loves having the subject of their article declared to be "unimportant". WhatamIdoing (talk) 23:34, 3 October 2025 (UTC)

This is certainly technically possible. Also there are no projects which use both importance and priority, so I can't see any likely confusion or clashes that this could cause. Personally I agree that "priority" is a much better word than "importance" for this — Martin (MSGJ · talk) 10:49, 4 October 2025 (UTC)

Protected edit request on 5 October 2025

Please replace the CSS at Module:WikiProject banner/styles.css with the text at this revision of my sandbox.

The diff is here.

This edit adds color:inherit to each CSS entry that declares a background-color: value, satisfying the requirements of the Linter described at mw:Help:Lint_errors/night-mode-unaware-background-color.

I have no way to test this code, since the template is a nest of modules and CSS files. If you know how to get the new code into a testing location, please do so. Looking at some complex instances of {{WikiProject banner shell}}, including the ones at {{WikiProject_banner_shell/testcases}}, in both light mode and dark mode, should tell you whether there are any major problems with the code.

If someone wants to get really fancy, they could propose some CSS variables for use in items like class-unassessed, which makes an incompatible background color at Template:WikiProject banner_shell/testcases#BLP in dark mode. That is beyond the scope of this request, however. – Jonesey95 (talk) 02:46, 5 October 2025 (UTC)

 Not done: The template works fine in its current state, but by using inherit, dark mode users are unable to see the text that tells users the importance rating provided by the wikiproject. This isn't fixing anything and instead making the situation worse. Sohom (talk) 03:55, 5 October 2025 (UTC)

The syntax errors remain. I hope that someone knows the right CSS to use to supply colors that work properly in dark mode. – Jonesey95 (talk) 18:17, 5 October 2025 (UTC)

Which syntax errors? You didn't mention any in your first post. --Redrose64 🌹 (talk) 19:59, 5 October 2025 (UTC)

I tried to, when I said "satisfying the requirements of the Linter described at mw:Help:Lint_errors/night-mode-unaware-background-color". For minimal dark mode compatibility, syntax requires that color: be set in every style= declaration where background: or background-color: is set. – Jonesey95 (talk) 21:07, 5 October 2025 (UTC)

I followed the link, but the word "syntax" doesn't occur there either. A syntax error would be using something like style="color:inherit;', color; inherit:, colour: black; or color:skybluepinkwithyellowspots; --Redrose64 🌹 (talk) 21:36, 5 October 2025 (UTC)

I'm not sure what you are on about, or how that helps us fix this problem. It is an error to have a background color specified without a color specified. I also provided details about an incompatible background color in one of the test cases. Ideally, someone with knowledge of the CSS design tokens that are referenced on the page I linked to above will be able to fix these problems. – Jonesey95 (talk) 23:59, 5 October 2025 (UTC)

Omitting a declaration for the foreground text colour might be an error of some sort, but it's not a syntax error. The syntax of CSS 2.1 is described here. --Redrose64 🌹 (talk) 20:40, 6 October 2025 (UTC)

OK, thanks for your help. Returning to the original request: if someone has the technical skills to improve the module to comply with the above-linked requirement, I would greatly appreciate it. The module has more than 11 million transclusions, so you'll be improving a lot of pages. – Jonesey95 (talk) 22:48, 6 October 2025 (UTC)