Module talk:WikiProject banner/Archive 14

Latest comment: 2 months ago by Hawkeye7 in topic More page types
Archive 10 Archive 12 Archive 13 Archive 14

  You are invited to join the discussion at Wikipedia talk:Content assessment § Proposal: Reclassification of Current & Future-Classes as time parameter. There is a proposal to split "current" & "future" classes into a new parameter "time", in order to standardise article-rating across Wikipedia (per RfC), while also allowing simultaneous usage of quality criteria and time for interest projects. Thanks! CX Zoom[he/him] (let's talk • {CX}) 07:28, 2 July 2023 (UTC)

Red links for inactive projects

See Talk:Hoekstra, the class List is red for Frisia because it does not have a category because its an inactive project. Christian75 (talk) 09:05, 29 June 2023 (UTC)

That's not even supposed to appear. Will check it out ... — Martin (MSGJ · talk) 09:12, 29 June 2023 (UTC)
I think such categories should be tracked and created. We did reach a consensus to retain inactive WikiProject banner, but not much work has been done yet on that front. CX Zoom[he/him] (let's talk • {CX}) 09:21, 29 June 2023 (UTC)
I am trying to work out if this rating has just appeared with the module conversion, or whether it has been like that since 10 May? — Martin (MSGJ · talk) 09:23, 29 June 2023 (UTC)

Just to clarify that the template is working as expected. This was a compromise after the long discussion at Wikipedia:Village pump (miscellaneous)/Archive 73#Improper handling of assessment for inactive WikiProjects. If you don't like the red links, would you prefer this to be de-linked, or would you prefer the whole row is hidden in the banner? Personally I don't think there was consensus to recreate all those categories, but any WikiProject being "revived" can of course do so — Martin (MSGJ · talk) 13:35, 2 July 2023 (UTC)

Script errors

Template:WikiProject Portals seems to be generating script errors, e.g. on Wikipedia talk:Featured portal review but the errors are not visible on the page, they are just populating the category — Martin (MSGJ · talk) 09:13, 3 July 2023 (UTC)

Another thing, {{WikiProject Portals|historical=y}} doesn't populated the "historical" category, but {{WikiProject Portals}} does. CX Zoom[he/him] (let's talk • {CX}) 09:29, 3 July 2023 (UTC)
Seems a bit of a mess. User:MJL has worked on this template in the past, maybe he/she can help? — Martin (MSGJ · talk) 09:49, 3 July 2023 (UTC)
It was an issue with note 4. Now fixed. -- WOSlinker (talk) 12:15, 3 July 2023 (UTC)
Thanks WOS! — Martin (MSGJ · talk) 13:34, 3 July 2023 (UTC)
@MSGJ: [Thank you for the ping] For the record, I use they/them pronouns rather than he/she.
Glad this got solved. While I did attempt to work on that template in the past, I self-reverted all my changes when I broke something. I probably wasn't going to be much of a help here. –MJLTalk 17:12, 3 July 2023 (UTC)

minor comment on Module:WikiProject banner

Just a minor comment: the invocation of banner_rows:allDone() on line 614 is essentially a no-op, as the return value isn't being stored. isaacl (talk) 21:22, 4 July 2023 (UTC)

Understood. When I first coded this I assumed the done() were required in order to close the tags. Then I noticed that none of your examples on WT:LUA had them so guessed that tags were closed automagically. — Martin (MSGJ · talk) 21:26, 4 July 2023 (UTC)
Sure, if you had a mental model of an ongoing string of text being built up, I understand how you might think this. What happens though is that the function calls build a tree of objects representing the HTML. When tostring() is invoked on the banner variable, the tree is rendered into HTML, and thus as the tree is traversed, the corresponding start and end tags will be generated. isaacl (talk) 22:00, 4 July 2023 (UTC)

Script error if no image

@MSGJ: If a banner has no image set then it's displaying a script error at the moment. For example: {{WikiProject Dictionary of National Biography}} or {{WikiProject Anatolian Civilizations task force}}. -- WOSlinker (talk) 06:36, 7 July 2023 (UTC)

Thanks, this should now be fixed — Martin (MSGJ · talk) 07:44, 7 July 2023 (UTC)

Adding redirect class

At Wikipedia talk:WikiProject Council#Proposed changes to extended quality scale I proposed adding redirect-class to the standard extended scale, because lots of projects use it. There has been no opposition in nearly a month so I will look at implementing this shortly.

In order to avoid creating lots of new categories, while also avoiding red categories appearing on pages, I suggest we add an existence check to the module code so that:

This will give projects a choice: if they want to track redirects then they can just create the category. If this approach works, we could roll it out to other non-article classes like Portals too. — Martin (MSGJ · talk) 13:21, 27 June 2023 (UTC)

Now coded on the sandbox — Martin (MSGJ · talk) 22:09, 4 July 2023 (UTC)
This is now deployed. FWIW I think we could now use the "full quality scale" aka the "extended scale" for all projects. Based on the same logic the class will only be used if the category exists, otherwise it will just use NA-class. — Martin (MSGJ · talk) 12:14, 7 July 2023 (UTC)

Appearance of nested version

There are some interesting ideas/proposals being discussed at Template talk:WikiProject banner shell#How project banners should look which would affect the nested display of this template. You are encouraged to add your thoughts ... — Martin (MSGJ · talk) 11:47, 7 June 2023 (UTC)

Consensus is starting to emerge. Any other comments would be welcome at Template talk:WikiProject banner shell#Moving ahead? — Martin (MSGJ · talk) 11:43, 30 June 2023 (UTC)
New design has been deployed! — Martin (MSGJ · talk) 12:28, 6 July 2023 (UTC)

Why are all banners white when collapsed instead of the usual beige?

This is jarringly awful. Please restore the previous colour scheme. Headbomb {t · c · p · b} 18:51, 6 July 2023 (UTC)

The left-alignment is also similarly jarring. Having things centered was so much better. Headbomb {t · c · p · b} 18:53, 6 July 2023 (UTC)
There was a discussion at WikiProject banner shell. -- WOSlinker (talk) 19:02, 6 July 2023 (UTC)
In which the four choices presented were white, white, white, and white. Some discussion. —David Eppstein (talk) 20:20, 6 July 2023 (UTC)
I honestly could not see anything on the page after looking at the banner on this talk page. All the text swam, I saw dots and my head is still pounding. Way too many bright colors and far too much sensory input. SusunW (talk) 20:37, 6 July 2023 (UTC)
It both looks terrible and is just painful on the eyes in various ways. SilverserenC 22:19, 6 July 2023 (UTC)
That's a glitch caused post-deployment, because a project banner transcluded further up the page is overriding the CSS of the mockups. This is how they looked.
Anyway, the consensus for a white background was only slim, so feel free to join the discussion there. DFlhb (talk) 00:03, 7 July 2023 (UTC)

Notification for everyone above (Headbomb, WOSlinker, David Eppstein, SusunW, DFlhb): An RfC was started at Template_talk:WikiProject_banner_shell#RFC_on_WikiProject_Banner_shell_redesign. SilverserenC 18:10, 9 July 2023 (UTC)

Script error complaining about "quality" function

  Resolved

Template talk:Airport destination list is displaying [[Category:Script error: The function "quality" does not exist.-Class airport articles]]. I did a null edit, but I haven't tried to troubleshoot it. I'm assuming that it is related to the changes here. – Jonesey95 (talk) 12:31, 7 July 2023 (UTC)

This is also happening at Talk:Agra, and there are a few thousand pages in Category:Pages with script errors (increasing rapidly!), where there are usually only a few hundred pages. Most of the pages in the category are some flavor of Talk page. – Jonesey95 (talk) 12:35, 7 July 2023 (UTC)
That'll probably be this edit, which removed the function. Cant undo it since its an admin protected page. Aidan9382 (talk) 12:40, 7 July 2023 (UTC)
Yes, I came here to say just that and to ping MSGJ. – Jonesey95 (talk) 12:42, 7 July 2023 (UTC)
Thanks to MSGJ for the quick response. This change has been reverted. The script error category population is decreasing now. Affected pages may require a null edit. – Jonesey95 (talk) 12:51, 7 July 2023 (UTC)

Apologies. All those functions were moved to Module:WikiProject banner but I forgot there were a few bespoke banners that were still calling them there. I wish there was an easy way to find which templates were calling certain functions in modules. — Martin (MSGJ · talk) 12:52, 7 July 2023 (UTC)

{{WPBannerMeta/hooks/qualimpintersect}} appears to call {{#invoke:Class mask|quality. That might be a clue. This list doesn't look too bad. – Jonesey95 (talk) 12:58, 7 July 2023 (UTC)
Here's another clue. – Jonesey95 (talk) 13:00, 7 July 2023 (UTC)
Thanks I will catch them all before deploying that again — Martin (MSGJ · talk) 10:22, 10 July 2023 (UTC)

Script error at Talk:Ch'p possibly related to changes

Talk:Ch'p is currently displaying Lua error in Module:WikiProject_banner at line 583: attempt to perform arithmetic on local 'hook_collapsed' (a nil value).Jonesey95 (talk) 19:11, 11 July 2023 (UTC)

This is a correct report of a bug in the code, which I have now fixed in the sandbox. Thanks — Martin (MSGJ · talk) 22:07, 11 July 2023 (UTC)
Thanks for undeleting my message. I had fixed this instance with a hammer instead of a screwdriver. Your way is better. – Jonesey95 (talk) 11:19, 12 July 2023 (UTC)

Too many expensive function calls

Now that we support an indefinite number of task forces, the category checks on /templatepage are getting too expensive. For example see Template:WikiProject Caribbean/sandbox which has 28 task forces, each one checking for 12 quality and 7 importance categories. It is easy to see how the limit of 500 is passed. We could limit the category checks to the first 10 task forces, or perhaps we could be clever and check a random selection of 10 task forces. — Martin (MSGJ · talk) 22:08, 12 July 2023 (UTC)

What differs from the status quo and this? The maximum number of taskforces might be infinite, but the number actually in use remains the same. CX Zoom[he/him] (let's talk • {CX}) 22:25, 12 July 2023 (UTC)
Before the module we could only check categories for 5 task forces, but now it's trying to check for all of them. — Martin (MSGJ · talk) 22:27, 12 July 2023 (UTC)
Oh, I see. These things might actually be more suited to a bot Database Report if expensive calls are causing issues. But until such time your solution also works. CX Zoom[he/him] (let's talk • {CX}) 22:32, 12 July 2023 (UTC)
Maybe just keep a count of how many checks and don't check once close to 500 and add another note below the banner on the template page saying not all category existance has been checked? -- WOSlinker (talk) 22:40, 12 July 2023 (UTC)
That's not a bad idea. I've limited the check to tf1-10 for the moment until we figure this out properly. — Martin (MSGJ · talk) 22:45, 12 July 2023 (UTC)
Random idea coded and the result can be seen on Template:WikiProject Caribbean/sandbox. An advantage is that a different set of categories are checked each time the page is loaded, rather than the same ones each time. — Martin (MSGJ · talk) 23:10, 12 July 2023 (UTC)
I'm not sure that's an advantage; if I understand correctly, it means the page's quality and importance ratings can change randomly from load to load. I think that would be a more confusing reader experience. isaacl (talk) 00:58, 13 July 2023 (UTC)
May be we can use a way where the category check is chosen by UTC date. On 1st, the first 5 tf are checked, on 2nd, the next five, and so on until looping back? The template code should have instructions about the same. Maybe also add a debug=yes mode for those trying to debug the template irrespective of the date. It should not be part of the permanent template code though. If possible a preview-only effect would be appreciated. CX Zoom[he/him] (let's talk • {CX}) 05:02, 13 July 2023 (UTC)
I still think that would be confusing for readers. isaacl (talk) 06:35, 13 July 2023 (UTC)
There is nothing we are discussing which would affect readers. These are about some warnings that appear on the template page if certain required categories do not exist. — Martin (MSGJ · talk) 07:08, 13 July 2023 (UTC)
I apologize for misunderstanding. Personally, I still am not a fan of non-deterministic behaviour; perhaps the page can be placed in a tracking category that can be used by a bot or user script to perform full validation. isaacl (talk) 16:22, 13 July 2023 (UTC)
Bot idea is preferable, but that would need a bot operator willinf to take up this recurring task. CX Zoom[he/him] (let's talk • {CX}) 16:30, 13 July 2023 (UTC)
I agree with both points; I suggested a user script as an option if no one volunteers to run a bot. isaacl (talk) 16:35, 13 July 2023 (UTC)
Let's ask at WP:BOTREQ and see if anyone takes it up. Here is my draft message. Feel free to modify it in any way that makes the message concise, clearer, and correct.
"For every WikiProject banner, {{WPBannerMeta}} detects whether the quality/assessment categories required for its taskforces are created or not, and creates a warning and also populates Category:WikiProject banners with formatting errors. Until recently, this template check was limited to the first 5 taskforces. But several banners already use more than 5 taskforces. Recently, the banners were switched to module, it is able to run a category check on any number of taskforces, but leads to too many expensive function calls. Thus, a bot that runs regularly to generate a report of category checks is required. The relevant code is already available in wikitext/Lua format. Thanks!"
CX Zoom[he/him] (let's talk • {CX}) 18:32, 13 July 2023 (UTC)
Daily changes sounds good - do you want to code that? Not sure how your debug option would work, but feel free to sandbox that as well — Martin (MSGJ · talk) 12:21, 13 July 2023 (UTC)

Add a warning that messing with categories could affect bots that make use of those categories, like WP:AALERTS and WP:RECOG.

I was sure we had such a warning before, but I can't find it anywhere. Basically, on the main template page, e.g. Template:WikiProject Sweden, in the box that says "This WikiProject banner uses...", add the following text

  • Several workflows and processes on Wikipedia depend on the configuration of the WikiProject banner. When merging, renaming, or updating your banners, categories, projects or taskforces, you may have to update the configuration of your WP:AALERTS, WP:CLEANUPLISTINGS, WP:RECOG, etc. When in doubt, ask on your WikiProject's talk page or at WT:AALERTS, WT:CLEANUPLISTINGS, WT:RECOG, etc.

Headbomb {t · c · p · b} 14:04, 15 July 2023 (UTC)

I'm not crazy, we did have such a warning before. Headbomb {t · c · p · b} 14:04, 15 July 2023 (UTC)
Yeah, this is a reasonable warning that should be shown to editors because lots of stuffs can break if changes aren't done correctly. CX Zoom[he/him] (let's talk • {CX}) 21:00, 18 July 2023 (UTC)

Note parameter change in behaviour

It appears that the |note n= parameters have changed behaviour during or after the recent conversion to Lua. Previously, non-blank values that didn't evaluate to no would be treated as if they were yes but now an explicit yes seems to be required. Consider Template:WikiProject UK geography which has

|note 2={{{photo|}}}
 |NOTE_2_TEXT        = This article needs a photo.
 |NOTE_2_IMAGE       = Icon tools.svg
 |NOTE_2_CAT         = Wikipedia requested photographs in {{#ifexist:Category:Wikipedia requested photographs in {{{photo}}}|{{{photo}}}|the United Kingdom}}

which is documented as

and this worked just fine until the recent conversion to Lua. Now, setting |photo=England does nothing, it only recognises |photo=yes. Can the previous behaviour please be restored? --Redrose64 🌹 (talk) 18:44, 18 July 2023 (UTC)

You are right, we are using Module:Yesno for this logic now. It can be restored to previous behaviour. Just to check though, do we want |attention=no to trigger or not? Would a trigger for any non-negative value be a good implementation? — Martin (MSGJ · talk) 21:49, 18 July 2023 (UTC)
This is now implemented in the sandbox. To be clear no, n, false, f, off, 0 and blank will not trigger but any other input will trigger. This change will apply to the attention note, the infobox-needed note, all the custom notes and all the task forces. Does that sound right? — Martin (MSGJ · talk) 07:29, 19 July 2023 (UTC)
No other comments so this is   Done — Martin (MSGJ · talk) 07:17, 20 July 2023 (UTC)
  Thank you --Redrose64 🌹 (talk) 17:48, 20 July 2023 (UTC)

Merge tracking categories

I am thinking about merging Category:WPBannerMeta templates with missing assessment categories with Category:WikiProject banners with formatting errors so there is just one category to check. It might be simpler just to call it Category:WikiProject banners with errors actually. Any thoughts? — Martin (MSGJ · talk) 09:47, 19 July 2023 (UTC)

I have no issues with it, as long as there is a discernable letter code to distinguish one issue from the other. CX Zoom[he/him] (let's talk • {CX}) 11:49, 19 July 2023 (UTC)

Old error category still being triggered

This edit added {{album}}, which put Scriptures (Benediction album) into Category:WikiProject banners with formatting errors instead of Category:WikiProject banners with errors. This suggests that Module:WikiProject banner still has some code to trigger the old error category, but I don't know enough about Lua to fix it. --Redrose64 🌹 (talk) 09:37, 22 July 2023 (UTC)

Yes I had that fix in the sandbox and deployed yesterday so that should (maybe) be all of them now. — Martin (MSGJ · talk) 07:50, 24 July 2023 (UTC)

To-do list

I've put code in Module:WikiProject banner/auxiliary/sandbox to support to-do lists at the bottom of the banner, a feature used by many projects. This would make the corresponding hook unnecessary and simplify code — Martin (MSGJ · talk) 10:37, 21 July 2023 (UTC)

  Deployed — Martin (MSGJ · talk) 22:40, 24 July 2023 (UTC)

A lot of these to-do lists haven't been updated in years. I'm not sure if this is technically possible, but I think a warning would on the template would be appropriate if the to-dolist hasn't been touched in a year, and to suppress it completely if it hasn't been touched in two years. — Martin (MSGJ · talk) 10:46, 21 July 2023 (UTC)

Banners with disabled categories category

Do we have categories like Category:WikiProject Korea banners with categories disabled for all WikiProjects? If yes, they should be appropriately categorised within a single parent category. CX Zoom[he/him] (let's talk • {CX}) 17:57, 25 July 2023 (UTC)

No, it seems to be a 2-off * Pppery * it has begun... 17:58, 25 July 2023 (UTC)
Ah, I see. CX Zoom[he/him] (let's talk • {CX}) 18:20, 25 July 2023 (UTC)

B-class checklist

I am thinking about adding the B-class checklist to the module so the hook will not be required. This could automatically display whenever the parameters |b1=, |b2=, etc. are passed. It will need to be a bit clever in order not to display twice on banners which are using the hook, e.g. do not display the checklist if |HOOK_ASSESS= is defined. — Martin (MSGJ · talk) 12:48, 23 June 2023 (UTC)

Could anyone who is good with CSS tell me what I need to do to get the [show] buttons to align in the example below? It's driving me crazy. — Martin (MSGJ · talk) 14:03, 28 June 2023 (UTC)
{{WPBannerMeta/test|category=no|class=c|b1=|b2=n|b3=y|b4=y|b5=na|b6=jo|attention-needed=y|needs-infobox=y}}
It's the margin and padding, but the two rows do it in different ways - one via style= attributes, the other through classes and stylesheets. --Redrose64 🌹 (talk) 20:41, 28 June 2023 (UTC)
I've tried to harmonise them and it looks slightly better (on my browser) — Martin (MSGJ · talk) 20:47, 28 June 2023 (UTC)
This is now coded in the sandbox. Some testcases. I had to rename MAIN_CAT to B_MAIN_CAT because we already have that parameter in use. Given its function I wonder if something like B_INCOMPLETE_CAT would be clearer? @WOSlinker: I think you were involved in adding these features so it would be great if you could take a look. — Martin (MSGJ · talk) 07:34, 1 July 2023 (UTC)
Deployed to live code — Martin (MSGJ · talk) 21:00, 2 July 2023 (UTC)

Autodemoting

Not related to above, but it seems the banner is not autodemoting to C if the B-class checklist is not completed. Need to check why this is not working ... — Martin (MSGJ · talk) 21:09, 2 July 2023 (UTC)

 Albums
 This article is within the scope of WikiProject Albums, an attempt at building a useful resource on recordings from a variety of genres. If you would like to participate, visit the project page, where you can join the project and/or contribute to the discussion.
Fixed in sandbox. The module needed to pass the raw arguments to the class mask so that blank b1 was not treated the same as nil b1, etc. — Martin (MSGJ · talk) 12:14, 5 July 2023 (UTC)

Article not able to be rated B-class

 – CX Zoom[he/him] (let's talk • {CX}) 15:39, 30 June 2023 (UTC)

There is some technical problem on Talk:Tornado outbreak of February 12, 1945. The article’s code says B-class, but the visual content is still rating it C-class. The Weather Event Writer (Talk Page) 15:29, 30 June 2023 (UTC)

I think it's fixed now. -- WOSlinker (talk) 17:40, 30 June 2023 (UTC)
Thank you! The Weather Event Writer (Talk Page) 18:44, 30 June 2023 (UTC)
Out of interest, is this something related to my new version of the code, or has this been an error in the weather template for a while? — Martin (MSGJ · talk) 07:30, 1 July 2023 (UTC)
I just compared some of the other templates that do the b class checklist and noticed that this was missing in the weather one. -- WOSlinker (talk) 08:07, 1 July 2023 (UTC)

Projects that use the checklist but do not use it to autodemote

I've noticed there are quite a few projects that use the B-class checklist but do not use the results to alter the quality rating in anyway, i.e. if |class=B but not all the criteria are satisfied then it still classifies as B-class. At the moment we don't have a way to do this in the core module code but I'm wondering if this would be useful. — Martin (MSGJ · talk) 12:17, 7 July 2023 (UTC)

I propose to use the |QUALITY_SCALE= parameter to select this somehow, perhaps |QUALITY_SCALE=ignore checklist would use the standard scale but will not auto-demote based on the checklist. — Martin (MSGJ · talk) 07:49, 21 July 2023 (UTC)
I wouldn't bother, despite switching WP:APPLE to do this. What does the code below do?
{{WikiProject Computing|class=B}} {{WikiProject Apple Inc.|class=B}}
Computing shows B-class. Apple shows C-class, because it supports B-criteria. WikiProjects sometimes get confused questions about it, and it might put off some from doing assessments. The banner should explain that B-criteria need to be filled for the rating to be accepted. For example, This article has been rated as B-class, but has not been checked against the B-class criteria, so it is treated as C-class on Wikipedia's content assessment scale. (with a C-class "box" to the left).
But I prefer removing pointless complexity by letting people rate things as B-class without jumping through hoops. If someone changes a C rating to B, we should trust they know what B-class requires. This would also reduce "conflicting" banner ratings that don't really conflict. All this requires is to stop treating unset criteria as failing criteria, which I recommended earlier. DFlhb (talk) 08:59, 21 July 2023 (UTC)
So to be clear, you think these templates should never demote (or promote) the quality class of the article based on the inputs of the checklist? This would have a significant impact on assessments (a lot of C-class articles would suddenly become B-class) so perhaps we should advertise this proposal at least at WT:COUNCIL. But I agree it would remove complexity and one of the barriers to WP:PIQA deployment — Martin (MSGJ · talk) 10:31, 21 July 2023 (UTC)
I'm only proposing to not treat unset as equivalent to failing. If any criteria is set and is a 'fail', autodemote. If all the criteria are set and are a 'pass', autopromote. If no criteria is set, respect the class parameter. I see quite a few banner shells with all projects displaying "B-class" except one, because no B-checklist had ever been added and the 'drive-by' re-assesser forgot to add one. DFlhb (talk) 13:34, 21 July 2023 (UTC)
Okay this change will need to be made in Module:Class mask. Should WT:COUNCIL be notified first? — Martin (MSGJ · talk) 23:04, 25 July 2023 (UTC)
Feel free to, but I'd recommend reaching out to WP:FILM and maybe 1-2 more of the biggest projects that use B-criteria, since few people watch WP:COUNCIL DFlhb (talk) 23:42, 25 July 2023 (UTC)

Padding on right image

 Seventh-day Adventist Church
 This article is within the scope of WikiProject Seventh-day Adventist Church, a collaborative effort to improve the coverage of Seventh-day Adventist Church on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. 
To-do list:
  • Expand "Glacier View Controversy" section, to include more background, history, theological issues, and details of the Glacier View meeting itself
  • Add to "Adventist Responses to Criticisms" section, ideally with material from Adventist scholars etc.

Not many banners use |IMAGE_RIGHT= but I noticed yesterday on Template:WikiProject Seventh-day Adventist Church that this is no padding on the right side of the image. Anyone know how to fix? — Martin (MSGJ · talk) 06:20, 27 July 2023 (UTC)

At Module:WikiProject_banner/styles.css#L-44: .wpb-main { padding: 3px 0 3px 5px; }, so there is a top/bottom-padding=3px, left-padding=5px, right-padding=0. At Module:WikiProject_banner/styles.css#L-60: .wpb-image { padding: 2px 0; }, so top/bottom-padding=2px, left/right-padding=0. Both the images use .wpb-image class, so on the left of left-image, we have 5+0=5px padding, on the right of right-image 0+0=0px. CX Zoom[he/him] (let's talk • {CX}) 07:04, 27 July 2023 (UTC)
Lack of right-padding on .wpb-main is also visible when you expand the To-do list. The left border is thicker than the right. CX Zoom[he/him] (let's talk • {CX}) 07:08, 27 July 2023 (UTC)
So changing Module:WikiProject_banner/styles.css#L-44 to .wpb-main { padding: 3px 5px 3px 5px; }, should do it then? Looks like it (sandbox shown above)! That was an easy fix ... — Martin (MSGJ · talk) 12:50, 27 July 2023 (UTC)
.wpb-main { padding: 3px 5px; } would render the same results (and is shorter). By the way, I've noticed that .wpb-imageright is a class defined in L-64 of the css, but this class is not applied on the right-image. Is there any element using it, or may it be removed from stylesheet? CX Zoom[he/him] (let's talk • {CX}) 13:17, 27 July 2023 (UTC)
A search in the code for wpb-imageright does not bring anything, so I guess it's not being used at the moment. Do we need it? — Martin (MSGJ · talk) 15:44, 27 July 2023 (UTC)
Perhaps not, because nothing is assigning this class as far as I see. CX Zoom[he/him] (let's talk • {CX}) 18:13, 27 July 2023 (UTC)
Okay I've removed it — Martin (MSGJ · talk) 18:31, 27 July 2023 (UTC)

Mobile version

There are a number of presentation issues with WPBM/WPBS on mobile version. So, let's take an example to go through them: Open Talk:Salimata Diarra. Banners are found in the "Learn more about this page" option.

  1. As long as banners are collapsed, their headers are nicely aligned. Upon exanding, some header texts stay where they were, others jump around forward or backward. This behaviour is unique to portrait mode. Landscape mode reflects the desktop behaviour.
  2. The css defining width of WPBS should be modified to use whatever css its |blp=yes note is using. If you try the talk page in landscape mode, you would realise that it's 80% width is clearly not enough for the amount of text a banner carries. Further, it is left-aligned, unlike center-alignment as in desktop. It is also very disturbing that some banners (like |blp=yes, {{old move}}, etc.) have 100% width, while this one, out of everyone, has just 80%.
  3. Some banners are just weirdly incomplete in their collapsed versions (again, portrait mode problem; it is fine in landscape mode). See WikiProject Africa & WikiProject Romania examples in the pics attached.

CX Zoom[he/him] (let's talk • {CX}) 07:14, 26 July 2023 (UTC)

.#3 probably happens because the header cell is automatically forced to fit-content. In WP Africa & WP Romania, header has so few content that the table-row needs not fill the entire space allotted to it. The others have so much content that it necessitates a line-wrap, in such case it chooses to take the whole 100% of the space. This behaviour is unseen on landscape mode though. CX Zoom[he/him] (let's talk • {CX}) 12:24, 26 July 2023 (UTC)
I have no suggestions, only a comment that the documentation currently says "This template does not display in the mobile view of Wikipedia; it is desktop only." — Martin (MSGJ · talk) 22:13, 26 July 2023 (UTC)
That was true for all tmboxes once upon a time, but now they all display. {{requested move/dated}} is another example. CX Zoom[he/him] (let's talk • {CX}) 22:34, 26 July 2023 (UTC)
Have you noticed these issues recently or has it been like this for a long time? — Martin (MSGJ · talk) 21:22, 27 July 2023 (UTC)
I don't remember the exact date of tmboxes becoming visible, but it happened sometime after 8 June 2022 (when I had asked a certain question on VPT). I think this discussion from September has some context. As far as I remember the issues have been there ever since they became visible on mobile. CX Zoom[he/him] (let's talk • {CX}) 07:56, 28 July 2023 (UTC)
@Izno: Do you know when tmboxes started to be visible on mobile? CX Zoom[he/him] (let's talk • {CX}) 07:58, 28 July 2023 (UTC)
December 2022 or January 2023. Discussions like this one for article history and this one for WPBM were due to it. Izno (talk) 15:16, 28 July 2023 (UTC)
You identified the issue with #3: mw-collapsible tables that do not have an explicit (minimum) width set, so the box collapses. (Memory says this doesn't happen with divs, so it would be fixed in a divification of tmboxes. Which is on the todo list somewhere.) This can be fixed trivially in WPBS CSS for the moment since you always want these to be 100% width.
1. is caused by the difference in width caused by the words show and hide (seriously; it's even worse with the default names expand and collapse). This is possible to fix using some margin on a second container for the title (IDK if that already exists). This is how Navbox currently does it, because Navbox needs things to be centered. It might also be fixable if we set show/hide in this template to display: inline-block and give it a reasonable width (4ems is the amount of margin Navbox uses), but I haven't tried that. (NB this is why some templates like Article history's show/hide as well as a few of our collapse templates cause some flicker when collapsing/uncollapsing, since they're using text-align: center rather than what Navbox does, which is more involved. I'm just lazy since the solution requires enough work in multiple templates that like to support different locations for the title of the collapsed content.)
2. is something that honestly can't be fixed without divification. I have tried multiple times to get it the way everyone wants it for all tmboxes as tables. Tmbox divification is non-trivial because of the fact there are multiple templates using the styles that aren't a function of Module:Message box. This search has a list of the ones that need adjustment (and some false positives), but it's not a large number. I got started with a more incremental step somewhere about whether a message box uses divs or tables for layout that allows each type to opt in, which would at least get us toward deploying it for some places, but I seem to have misplaced the sandbox. I'll look for that. Izno (talk) 15:36, 28 July 2023 (UTC)

Unknown parameters checking

An user recently added the ability to check for unknown parameters to a banner template: See Special:Diff/1157384999. Is it possible to incorporate that functionality directly into the meta template? CX Zoom[he/him] (let's talk • {CX}) 20:28, 28 May 2023 (UTC)

No, because Lua modules can't access more than 1 level of parent frame. * Pppery * it has begun... 20:30, 28 May 2023 (UTC)
I actually have a plan for this. It involves reading the content of the template page to work out the names of the parameters that are being used. Will post here if I get it working. — Martin (MSGJ · talk) 06:58, 23 June 2023 (UTC)
I now realise that Pppery is correct. Perhaps the best we can do is with a solution that calls the module directly, i.e. the template uses {{#invoke:WikiProject banner|main|...}} rather than {{WPBannerMeta|...}} Then we will be able to access the parameters used on banner instances. — Martin (MSGJ · talk) 20:52, 26 June 2023 (UTC)

@CX Zoom and Pppery: I think I've got this working on the sandbox. Available to test on Template:WikiProject National Football League/sandbox. Let me know what you think — Martin (MSGJ · talk) 14:54, 21 July 2023 (UTC)

It seems to me that it works. CX Zoom[he/him] (let's talk • {CX}) 07:23, 23 July 2023 (UTC)
Okay I will look at deploying this shortly then. The module will populate categories of the form Category:Pages using PROJECT_NAME with unknown parameters, if it exists, otherwise the default category Category:WikiProject templates with unknown parameters — Martin (MSGJ · talk) 11:34, 24 July 2023 (UTC)
  Deployed — Martin (MSGJ · talk) 22:41, 24 July 2023 (UTC)

I have updated the documentation to recommend using {{#invoke:WikiProject banner|main|...}} so that projects can benefit from the automatic parameter checking — Preceding unsigned comment added by MSGJ (talkcontribs) 08:54, 26 July 2023 (UTC)

@MSGJ: Category:Pages using WikiProject Food and drink with unknown parameters seems to be filled up with articles with b-class review and task force parameters, is that an issue with {{WikiProject Food and drink}} or the meta template itself? Taavi (talk!) 17:16, 28 July 2023 (UTC)
Okay I think I can see what is going wrong there. There are multiple parameter variants accepted for each task force. I will have to upgrade the code to recognise though ... — Martin (MSGJ · talk) 19:59, 28 July 2023 (UTC)
This should be fixed now, although the category may take some time to empty itself — Martin (MSGJ · talk) 11:47, 29 July 2023 (UTC)

Task forces no longer inherits importance

I have just noticed that WikiProject banners no longer automatically categorises importance for task forces and other sub-groups if no specific value is set for those. This one for example: Talk:Sweden women's national football team. For all task forces, the article is put into unknown importance. They used to mimic the importance set for the parent project unless there was a specific value set for the task force. Is it a bug or a new feature? --Mango från yttre rymden (talk) 22:26, 24 July 2023 (UTC)

This feature may have got missed when converting the template to Lua. Is this still something which would be useful to the football project? Shouldn't be too hard to fix. — Martin (MSGJ · talk) 22:46, 24 July 2023 (UTC)
If this was the past behaviour, I'd support reinstating it. But, there should be an option for opt-out, because importance to individual task forces might not always align with its parent. CX Zoom[he/him] (let's talk • {CX}) 07:00, 25 July 2023 (UTC)
I see. It's not just for WP Football, it's the same for WP:Computing and WP:Television and a few more that I've forgot now. I would assume that most, if not all, other banner templates are affected as well.
It's a known feature, most people assume that task forces get the same importance as the parent project. So yes, it was the past behavior. Most people don't even know that task forces can have a separate importance assessment, that feature is very ill documented in the rare cases it's mentioned at all. I guess people can learn if we start informing properly about it, but I think it would severely undermine task forces if they had to start all over on that, a feature/institution that is already suffering from dwindling commitment. Literally tens of thousands of articles would need to be assessed again. To have task forces inherit importance assessment from the parent project is a good baseline and perfectly fine in most cases. So yes, I think it would be very useful.
I think an opt-out feature is unnecessary, because it can always be set specifically anyway. But sure, there is a point to have an opt-out if a task force really want to have it that way and make their own importance assessments from scratch. --Mango från yttre rymden (talk) 09:50, 25 July 2023 (UTC)
Even before the recent changes, taskforces didn't inherit importance unless they were explicitly coded to do so. For example, Template:WikiProject Cryptography has
 |tf 1={{{computing|}}}<!-- see Computer Science Project template -->
  |tf 1 importance={{#if:{{{computing-importance|}}}|{{{computing-importance}}}|{{{importance|}}}}}<!-- Inherit importance if not specified -->
  |TF_1_ASSESSMENT_CAT = Computing articles
which means that when |computing=yes is set, if |computing-importance= is blank or absent, the value set by |importance= is used instead; and if that is also blank or absent, the page is added to Category:Unknown-importance Computing articles. Compare Template:WikiProject Ancient Egypt which has
|tf 1={{{religion|}}}
  |tf 1 importance={{{religion-importance|}}}
  |TF_1_ASSESSMENT_CAT = Egyptian Religion articles
which means that when |religion=yes is set, if |religion-importance= is blank or absent, the page is added to Category:Unknown-importance Egyptian Religion articles - |importance= is ignored. As regards Template:WikiProject Football, this has e.g.
  |tf 1={{{Africa|{{{africa|}}}}}}
  |tf 1 importance     = {{{Africa-importance|{{{africa-importance|}}}}}}
  |TF_1_ASSESSMENT_CAT = football in Africa articles
and similar code for the other taskforces, there are aliases but in no case is inheritance of |importance= coded for. --Redrose64 🌹 (talk) 22:27, 25 July 2023 (UTC)
Redrose, you are right this was never supported as standard but it was a feature of taskforce hook which apparently a lot of projects made use of. So I will code the |inherit importance= parameter in the new version. — Martin (MSGJ · talk) 22:59, 25 July 2023 (UTC)
Ah, I see that you removed it in this edit; setting
 |inherit importance={{{importance|}}}
is another way of explicitly coding for it. I know of no WikiProject banners that would inherit the importance without using one or the other of these methods of explicit coding. --Redrose64 🌹 (talk) 05:33, 26 July 2023 (UTC)

Okay I think I have this coded in the sandbox. There is no longer any need to pass through the importance parameter again, so |inherit importance={{{importance|}}} is unnecessary. Instead a straightforward |INHERIT_IMPORTANCE=yes could be used for this. I have some questions about this below. — Martin (MSGJ · talk) 09:57, 26 July 2023 (UTC)

@Mango från yttre rymden: just waiting for your thoughts on the questions below (and anyone else) — Martin (MSGJ · talk) 18:32, 27 July 2023 (UTC)
This feature is now deployed and I added |INHERIT_IMPORTANCE=yes to the football banner — Martin (MSGJ · talk) 11:48, 29 July 2023 (UTC)

Display

The template will state something like

What should it display if the importance is inherited? We can no longer say it has been "marked as High-importance". Should this part be omitted or should we note in some way that the importance has been automatically inherited? — Martin (MSGJ · talk) 09:57, 26 July 2023 (UTC)

Currently, absence of importance marker denotes "unassessed importance", but at the same time the project has actively chosen to inherit the importance, so it is not "unassessed". I support some text along the lines of "(marked as High-importance)". I can suggest "inherited as High-importance", and can't think of any better way of doing it. CX Zoom[he/him] (let's talk • {CX}) 18:44, 27 July 2023 (UTC)
Perhaps we just say "assessed as High-importance". I don't think "inherited as High-importance" is grammatical but I can't think of a better way of expressing that — Martin (MSGJ · talk) 21:21, 27 July 2023 (UTC)

Invalid importance

What should happen if |sweden-importance=fhdjfh - should Sweden inherit the parent project's importance or should "fhdjfh" be used, which will resolve to "Unknown" — Martin (MSGJ · talk) 10:00, 26 July 2023 (UTC)

Inherit parent's importance, if garbage is inputted. Have a category track these, because sometimes there might be genuine mistakes like misspelling "mid" as "mis" due to erroneous keystroke, which should be tracked and fixed. CX Zoom[he/him] (let's talk • {CX}) 18:46, 27 July 2023 (UTC)
So basically anything that resolves to Unknown (blank or invalid) will inherit. Yes that makes sense to me. — Martin (MSGJ · talk) 21:19, 27 July 2023 (UTC)

Nested image

Some templates use images which include text. When we use the small versions of these images on the nested version of the template, the text is unreadable. (See example below.) Should we add a new parameter |NESTED_IMAGE= or |IMAGE_NESTED= to allow editors to specify a different image for the nested version? — Martin (MSGJ · talk) 11:11, 5 August 2023 (UTC)

I'm not opposed. CX Zoom[he/him] (let's talk • {CX}) 20:19, 8 August 2023 (UTC)
Or perhaps we should just change the image to something that works at different sizes? — Martin (MSGJ · talk) 21:08, 11 August 2023 (UTC)

Discussion at Template talk:WikiProject Russia § Broken with B-class

  You are invited to join the discussion at Template talk:WikiProject Russia § Broken with B-class. CLYDE TALK TO ME/STUFF DONE 07:02, 19 August 2023 (UTC)

To save you a click: I managed to fix it. CLYDE TALK TO ME/STUFF DONE 07:23, 19 August 2023 (UTC)

How to ignore quality and importance on draft articles

Is there any way for the {{WikiProject Ireland}} banner template to be set to ignore any |class= and/or |importance= on pages in the draft namespace?

{{WikiProject Ireland}} uses {{WPBannerMeta}}, and {{WikiProject Ireland}} it has now started adding draft pages to the table at Wikipedia:Version 1.0 Editorial Team/Ireland articles by quality statistics. This is understandably irritating the wonderful editors who do a huge lot of the assessment work, @Sarah777 and Ww2censor ... and I think that the solution is ignore these params in the draft namespace. But how? BrownHairedGirl (talk) • (contribs) 13:01, 15 August 2023 (UTC)

@Sarah777, Ww2censor, and MSGJ: in this edit[1] to {{WikiProject Ireland}}, I have done a crude hack to Force all {{WikiProject Ireland}} banners on pages in the draft talk namespace to be processed as if they have |class=Draft ... and no value for |importance=
Any values supplied for those parameters will be ignored unless the page is moved to another namespace.
This is a working solution, but not an elegant solution. If the same result can be achieved via some parameters for the module, please implement that. BrownHairedGirl (talk) • (contribs) 19:11, 15 August 2023 (UTC)
Wow, that looks like a cool solution for now. It's way above my pay grade. Thanks ww2censor (talk) 21:18, 15 August 2023 (UTC)
The correct way to do this is to create a custom class mask at Template:WikiProject Ireland/class which can implement whatever logic the project decides is best. But I do have to question the wisdom of deviating from the standard practice, as it may confuse editors. Are you quite sure that you will never want to indicate that a draft article is of high importance to the project? — Martin (MSGJ · talk) 21:08, 23 August 2023 (UTC)

Module:WikiProject banner protection

I have applied full protection over at Module:WikiProject banner even though there is a declined RFPP. This is mostly to match protection level with {{WPBannerMeta}} which uses this module meaning that it is at least as high risk as that page. If someone believes we should allow template editors to edit both these pages I won't object, but do disagree. This module is currently one of the 20 most used templates and if it isn't deemed high risk enough for full protection I believe it's time to have a serious discussion about ending the use of full protection for HRT. Pinging RFPP participants @Pppery, EdJohnston, ClydeFranklin, and Courcelles:. --Trialpears (talk) 18:25, 9 August 2023 (UTC)

I honestly thought full protection for high risk templates was essentially depreciated? Courcelles (talk) 18:27, 9 August 2023 (UTC)
Has there been a problem with template editors incorrectly editing the module? If not, it should probably be at template-editor protection. One of the requirements, stated or not, for being granted the TE right is knowing when you are in over your head and should not edit. I have been editing templates for many years and have many thousands of edits, but I would certainly think long and hard before making anything other than a trivial edit to that module. In my experience, my fellow template editors behave in the same way. (Edited to add: I don't care about full protection on the Template, since all it does is call the module.) – Jonesey95 (talk) 18:35, 9 August 2023 (UTC)
It's long been the case that some of the highest-risk templates on the project are fully-protected, although the standard for that is a bit fuzzy. * Pppery * it has begun... 18:47, 9 August 2023 (UTC)
I have also full-protected Module:WikiProject banner/styles.css and Module:WikiProject banner/config, since they are used by every call of the base module so clearly should have the same protection level as it. I have not full-protected Module:WikiProject banner/auxiliary, which is only used by about half of all calls, but IMO it also should be full-protected, especially since its equivalents in the pre-Lua system (Template:WPBannerMeta/hooks/bchecklist and Template:WPBannerMeta/hooks/todolist) were fully-protected.
I think full protection is correct here - there are enough admins watching this page that any edits to it should get handled rapidly and it makes sense that the level of trust required to edit this page is significantly greater than the level required to edit templates with a mere 5,000 calls. * Pppery * it has begun... 18:47, 9 August 2023 (UTC)
The reason that those templates were fully protected rather than template protected is simply that in most cases they pre-date the arrival of template protection and no one has bothered to lower the protection. Therefore it should not be used as a rationale for increasing the protection. — Martin (MSGJ · talk) 18:57, 11 August 2023 (UTC)
I guess I should articulate why I think full protection is preferable over template protection for our most high risk pages. It's not at all about me not trusting that template editors are competent. It's just that doing imperfect edits to pages with millions of transclusions can do so much damage that this small burden is warrented even though the probability is small. Even if you have good testcases and miss something affecting just 0.1% of transclusions you would have issues over thousands of pages and the fix may take weeks to propagate out. Ideally I believe all significant changes to templates with over say a million transclusions should get a second opinion if feasible and with full protection we come a long way towards that. Speaking from experience I did some edits with minor bugs to {{Short description}} in my early days as a template editors and if a second person had checked it we could probably have avoided a significant amount of confusion over the next week. If we regularly get something productive like that from these protections I believe they are well worth it.
Also I'm sorry that this wasn't the best way to start the conversation. I should probably just have just sent a ping and not changed the protection level. --Trialpears (talk) 19:42, 9 August 2023 (UTC)
Getting other editors to double-check code is certainly good practice, but there is no reason why that person needs to be an admin. Indeed the number of Lua-competent admins is quite low and using full protection is likely to make maintaining modules harder. — Martin (MSGJ · talk) 19:01, 11 August 2023 (UTC)
Complaining about the number of Lua-competent admins in a discussion in which three Lua-competent admins (myself, you, Trialpears) have participated is really not convincing. * Pppery * it has begun... 21:09, 23 August 2023 (UTC)
I personally think that given the circumstances here Template-protection is enough for now, mostly because DFlhb who is a template editor (but not admin) has made (had to make) a number of constructive edits to the base module and its sub-modules recently, none of which seem to have triggered an undesirable result. Since the work is still in progress, it could've been at TPE, and when it all gets settled down, it may have been upgraded to full protection. CX Zoom[he/him] (let's talk • {CX}) 21:55, 9 August 2023 (UTC)
Though I am the admin who declined full protection originally I no longer object if people who know about the template consider the protection necessary. Any admin who does apply the full protection should probably have a suitable rationale to offer, since at RFPP people often want similar files protected similarly. EdJohnston (talk) 02:58, 10 August 2023 (UTC)
I don't see this extra protection as necessary and it will probably hamper future development of the module — Martin (MSGJ · talk) 16:39, 10 August 2023 (UTC)
I have reinstated template protection on these modules, mainly for the following reasons:
  • The guideline Wikipedia:High-risk templates does not stipulate that full protection is preferred over template protection even for very widely used templates.
  • The reason that Template:WPBannerMeta and some of its subtemplates are fully protected is most likely because they predate template protection, rather than any deliberate decision.
  • The module is actively being developed, including by one editor who is not an admin.
  • The discussion above and the declined RFPP does not show consensus that the increased protection is warranted.
— Martin (MSGJ · talk) 21:05, 23 August 2023 (UTC)
You also need to reduce the protection of Module:WikiProject banner/styles.css, and remove the template from Wikipedia:Cascade-protected items/content to achieve a consistent state. But I find this conclusion disappointing as there have been zero edit requests in the time since this discussion started, indicating that the harms you and others claimed would happen above have not borne out. * Pppery * it has begun... 21:09, 23 August 2023 (UTC)
Done both of those things myself, given the lack of response here. * Pppery * it has begun... 14:02, 25 August 2023 (UTC)
Full protection seems a bit much. Template-editor protection is probably sufficient.  — SMcCandlish ¢ 😼  16:45, 25 August 2023 (UTC)

Hook conversion

The project of converting all the hooks into the Lua version continues, with support for |image-needed= added today. The status of the others are:

  • aclass –   Done
  • article todolist –   Not done only used by one banner, will probably hardcode it
  • bchecklist –   Done in /auxiliary, except for those projects which use a checklist but do not use it to automatically demote the class of an article to C-class if it doesn't meet the criteria. Some discussion of this in the archives and there was a proposal to change the way incomplete checklists are handled.
  • cats – to do, but notes can be used instead with blank |NOTE_n_TEXT=
  • collaboration –   Done
  • collapsed – to do
  • image needed –   Done in /auxiliary
  • notecounter – may not be needed when all hooks converted
  • notes – not needed anymore as infinite number of notes are now supported, except for those projects which hook this in a different place or have an additional collapsed section.
  • peerreview –   Done
  • qualimpintersect –   Done in /auxiliary, but need to add support for |UNASSESSED_APPENDIX= to convert the few remaining projects using this
  • qualitycats –   Done using task forces with |TF_n_TEXT=none
  • taskforces – not needed as infinite number of task forces are now supported, except for those projects which are putting their task forces in a collapsed section.
  • tfnested – will not be needed when all task forces are converted
  • todolist –   Done in /auxiliary

— Martin (MSGJ · talk) 10:58, 7 September 2023 (UTC)

Parameter rename

Propose renaming B_MAIN_CAT to B_INCOMPLETE_CAT as a more accurate description of its actual purpose (a category for B-class checklist which are incomplete) — Martin (MSGJ · talk) 14:55, 11 September 2023 (UTC)

Additional taskforce categories

Several of the large projects use extra categories inside taskforces, which they hook using TF_n_HOOK parameters with Template:WPBannerMeta/hooks/cats. I'm wondering if we could add better support for this, e.g. |tf 1 cat 1= and |TF_1_CAT_1= — Martin (MSGJ · talk) 08:09, 13 September 2023 (UTC)

This is now coded in the sandbox — Martin (MSGJ · talk) 09:03, 14 September 2023 (UTC)
  Done - deployed and documented — Martin (MSGJ · talk) 11:52, 15 September 2023 (UTC)

Needs-infobox by task force

Greetings. Most pages in Category:Physics articles needing infoboxes are also members of Category:Physics biographies articles. Would it be possible to create the intersection, Category:Physics biographies needing infoboxes, please? Notice bio is a task force of WP Phys (Template:WikiProject_Physics#Usage). Thanks! fgnievinski (talk) 04:09, 15 September 2023 (UTC)

This very timely request can now be implemented using the new "additional taskforce category" feature. It is so new that I haven't even documented it yet — Martin (MSGJ · talk) 07:43, 15 September 2023 (UTC)
Very nice! Could you give me some pointers so that I can try to implement it in WP Phys, please? fgnievinski (talk) 01:26, 17 September 2023 (UTC)
Already done here. You just need to create the category — Martin (MSGJ · talk) 19:29, 17 September 2023 (UTC)
Created: Category:Physics biographies needing infoboxes -- thanks! Would it be possible to diffuse Category:Physics articles needing infoboxes, please? I'd like to isolate the non-biography articles needing infoboxes, especially physical quantities and physical units needing infobox. fgnievinski (talk) 04:02, 19 September 2023 (UTC)
You can create categories based on the task forces that you have defined in your template. For example, for relativity articles needing an infobox you could add the code |tf 1 cat 1={{{needs-infobox|}}} and |TF_1_CAT_1=Name of the category — Martin (MSGJ · talk) 07:55, 19 September 2023 (UTC)

Collapsed taskforces

Some projects have their taskforces in a separate collapsible section. Currently this is not possible without using an complicated method with Template:WPBannerMeta/hooks/collapsed and Template:WPBannerMeta/hooks/taskforces. I am proposing parameters |TF_COLLAPSE= and |TF_HEADER= that would do this instead. — Martin (MSGJ · talk) 08:12, 13 September 2023 (UTC)

Suggested implementation. If either |TF_COLLAPSE= or |TF_HEADER= is defined then taskforces will be put in a collapsible section. In that case,
  • if |TF_COLLAPSE= is not specified then it will default to zero, i.e. section will always collapse
  • if |TF_HEADER= is not defined then it will default to "Associated task forces"
Any input welcome — Martin (MSGJ · talk) 21:31, 17 September 2023 (UTC)
This now coded on the sandbox and there is a demo on Template:WikiProject France/sandbox — Martin (MSGJ · talk) 09:30, 18 September 2023 (UTC)
That page, and a few others that use the /sandbox module, are currently showing Linter errors, specifically misnested table and tr elements. Special:ExpandTemplates should be able to show you the expanded code. Ping me if you need help with diagnosis. – Jonesey95 (talk) 12:59, 18 September 2023 (UTC)
Thanks for the note. Seems to be fixed now — Martin (MSGJ · talk) 13:43, 18 September 2023 (UTC)
Yes, all cleaned up. Thanks. – Jonesey95 (talk) 14:34, 18 September 2023 (UTC)

I propose two default thresholds for collapsing:

  • 0 if |TF_HEADER= is defined (i.e. we assume that task forces should always collapse if the header is defined)
  • 5 if |TF_HEADER= is not defined (i.e. any banner with 5 or more task forces will collapse by default, to take up less space on the page)

The default can be changed with the |TF_COLLAPSE= parameter — Martin (MSGJ · talk) 07:58, 19 September 2023 (UTC)

Auto for unassessed articles

auto=yes does not work for talk pages which do not have class/importance. e.g. Talk:Benzoate degradation via hydroxylation. I do not know if it worked with the old version of WPBannerMeta. Christian75 (talk) 00:44, 23 September 2023 (UTC)

@Christian75: No, it did not. Its purpose was purely to show that the |class= parameter had been filled in automatically by a bot. There were three ways that |class= could be filled in: (i) based on the length of the article (very short articles would be given |class=stub), in which case you got |auto=length; (ii) by copying the value for |class= from another WikiProject banner on the same page, in which case you got |auto=inherit - clearly if there were two or more with ratings, they would need to be the same rating otherwise the bot wouldn't do anything; (iii) if the article uses a stub template, in which case you got |auto=yes (or |auto=stub) and also |class=stub.
Hence, if the WikiProject did not recognise |class=, it was pointless for it to recognise |auto=. Importance had nothing to do with it. --Redrose64 🌹 (talk) 10:43, 23 September 2023 (UTC)
But the recent bot which tagged a lot of pages automatically added auto=yes. Just like the example i gave where WP Science should be removed. IMHO all talk pages with auto=yes (or similar) should be checked and therefore, should be in a auto-category Christian75 (talk) 12:16, 23 September 2023 (UTC)
The bot concerned is Qwerfjkl (bot) (talk · contribs), which is very buggy - see the numerous threads at User talk:Qwerfjkl and its archives, going back months, e.g. User talk:Qwerfjkl/Archive 32#auto. Your example edit is dated 1 July 2023 - do you have any recent examples? --Redrose64 🌹 (talk) 15:48, 23 September 2023 (UTC)
Strange. So adding class=something to a talk page which have auto=yes - will also make the article be in the Automatically assessed Chemistry articles (example: [2]) . I suggest adding all articles with auto to the automatically assessed categories and not just after they have been tagged with class. Christian75 (talk) 12:23, 24 September 2023 (UTC)
|auto=inherit or |auto=length will work for any class (as long as the article has been assessed otherwise it would make no sense!) And |auto=stub only works when |class=stub — Martin (MSGJ · talk) 16:58, 24 September 2023 (UTC)
@Redrose64, I wouldn't say it's very buggy - after all, that's what I coded it to do. There were a few problems when running it (mostly the ORES thing which is only tagentially related to this). Anyway, I switched to using an invisible comment pretty much because of this issue. I have no problem going over previous edits and fixing them, I just figured that it wasn't a huge issue.
There won't be any recent edits, because the bot task finished some time ago. — Qwerfjkltalk 15:45, 25 September 2023 (UTC)

Template:WikiProject Mammals/Bats Task Force

Will you just look at the horrendous code on this template? I think someone (or a bot) needs to go around and convert all the unnamed parameters to the standard named parameters "class", "importance" and "photo" — Martin (MSGJ · talk) 13:06, 25 September 2023 (UTC)

Category:Bats articles using unnamed parameters - see what turns up — Martin (MSGJ · talk) 13:57, 25 September 2023 (UTC)
I did a null edit on every page transcluding Template:WikiProject Mammals/Bats Task Force (just over 2,000 pages), so anything that could have ended up in the category should be there now. The category is empty. It should be safe to remove the excess code. You could leave the tracking category code in for a while if you are not confident in my work. – Jonesey95 (talk) 18:29, 25 September 2023 (UTC)
Thank you! Of course I am confident in your work ... — Martin (MSGJ · talk) 19:30, 25 September 2023 (UTC)

Slight change to behaviour of task forces on non-article pages

I've got code on the sandbox which will improve how the banner handles task forces on non-article pages. There are projects that use exotic extended classes like FM-class and Portal-class, but sometimes the separate task forces do not support the full range of these classes.

For example, Category:FM-Class mammal articles‎ exists but Category:FM-Class Pocket pets articles‎ does not. The proposed version will automatically use NA-class for the task force if the category does not exist or is blank. This involves a few more ifexist checks, but hopefully will not cause any performance issue. — Martin (MSGJ · talk) 15:21, 27 September 2023 (UTC)

This is deployed and seems to be working okay — Martin (MSGJ · talk) 08:35, 29 September 2023 (UTC)

Category:WikiProject banners with non-standard names

Do we still need this tracking category? — Martin (MSGJ · talk) 09:50, 26 September 2023 (UTC)

Having a non-standard name inhibits AWB from moving these into the banner shell as part of its general fixes and/or in general putting them in the place they're supposed to be on talk pages. So, yes, we should still have a tracking category. Izno (talk) 18:33, 26 September 2023 (UTC)
I'm not sure how the remaining ones can be "fixed" but okay — Martin (MSGJ · talk) 18:42, 26 September 2023 (UTC)
I mean, I don't know why some of those pages have non-standard names, but for the ones that obviously do, the correct thing to do is rename them. Izno (talk) 19:45, 26 September 2023 (UTC)
Some are incorrect task forces that should be converted to use the main WikiProject template. Others can maybe be added to an exclude list (like Template:WikiProject C/C++ and Template:WikiProject Hinduism/Shaktism, though really per MOS:SLASH the name of the project should use "and" and as an added benefit, these probably won't be added to the category). Gonnym (talk) 17:15, 29 September 2023 (UTC)

usages of |BANNER_NAME= in talk pages

There should probably be some code added to catch usages of |BANNER_NAME= in talk pages so usages like Talk:Basshunter videography can be added to a category and fixed. Gonnym (talk) 18:41, 29 September 2023 (UTC)

Wow, never seen that before! There doesn't seem to be any banner template for Basshunter — Martin (MSGJ · talk) 21:55, 29 September 2023 (UTC)
I am fairly certain there was at some point. WP:WikiProject Basshunter exists and is a redirect to a task force. Izno (talk) 00:44, 30 September 2023 (UTC)
@Gonnym I have had to revert a few of your changes (example). The BANNER_NAME is needed for these wrappers because otherwise the template thinks it is being used incorrectly and gives warnings — Martin (MSGJ · talk) 10:05, 2 October 2023 (UTC)
It is used incorrectly. It should be subst, as the template says it should. Gonnym (talk) 10:07, 2 October 2023 (UTC)
Okay, but I don't like the warnings on the template. How does the current version of Template:WikiProject Syracuse, New York work? — Martin (MSGJ · talk) 10:18, 2 October 2023 (UTC)
I'm unclear what is special about these 5 templates that requires that, while Template:WikiProject American Old West and the others at Category:WikiProject United States banner wrapper templates don't? Your edit re-added those templates to Category:WikiProject banners with non-standard names. Gonnym (talk) 10:23, 2 October 2023 (UTC)
My edit removed them from Category:WikiProject banners with errors though :)) Your example uses includeonly, so I guess that is another valid approach. — Martin (MSGJ · talk) 10:27, 2 October 2023 (UTC)

A few more banners you might be interested in cleaning up Gonnym:

— Martin (MSGJ · talk) 17:10, 4 October 2023 (UTC)

Template:WikiProject U.S. Roads uses a |type= system which I'm not familiar with and unclear if it works with the system (categories, pages, etc). Template:WikiProject Music/Music genres task force I'm not sure is fixable because there isn't a WikiProject Music template. Gonnym (talk) 18:58, 4 October 2023 (UTC)
Imzadi1979 has confirmed that you can use {{WikiProject U.S. Roads|type=US66}} in place of {{Template:WikiProject U.S. Roads/U.S. Route 66 task force}} but only for things directly related to the road and not gas stations, motels or museums, etc. — Martin (MSGJ · talk) 21:00, 4 October 2023 (UTC)
So Talk:Summit Inn should still be tagged with the task force version? Gonnym (talk) 03:21, 5 October 2023 (UTC)
That seems to be correct, although I don't understand the reason for the distinction — Martin (MSGJ · talk) 07:49, 5 October 2023 (UTC)

Quality/importance intersection categories for task forces

I've added support in the sandbox for quality/importance intersection categories for separate taskforces via parameters of the form TF_n_QII. This will significantly reduce overheads for the few projects that use it. — Martin (MSGJ · talk) 09:44, 3 October 2023 (UTC)

I randomly noticed while looking at Talk:Golconda diamonds for other reasons that it shows two redlinked categories: "A-Class Telangana articles" and "A-Class Telangana articles of Top-importance". My understanding is that red-linked categories are generally frowned upon. I don't really know whether the above change caused these cats to appear, whether these red-linked categories are new to this page, or whether it is a problem, or what change(s) might fix it. Pinging Bearcat and Liz, who tend to know about categories. – Jonesey95 (talk) 04:34, 4 October 2023 (UTC)
Yes, those would have been caused by this change. Redlinked categories are indeed frowned upon, but are impossible to remove if they're template-generated except by either creating the category or reverting whatever template change generated it — so if the categories are desired, then somebody needs to create them right away, and if they're not, then whatever change caused them to happen has to be undone. Bearcat (talk) 04:51, 4 October 2023 (UTC)
Well, when one makes use of a complex, categorizing template, one is accepting that one will create the categories it auto-generates. And a red internal maint. cat. is not a very real concern anyway; what we actually care about is readers being confronted with red content categories in the actual article. But seriously, part of the basic process of setting up and maintaining a wikiproject is creating the various class and importance categories used by the project banner to quietly sort articles for us, for maintenance purposes (even if a few of them may not seem personally important to some of the individuals doing the maintenance).  — SMcCandlish ¢ 😼  08:32, 4 October 2023 (UTC)
Actually, we very much do care about redlinked maintenance categories, because they're detected by the same redlinked category report that detects redlinked content categories — and even more importantly, that maintenance report has a hard size cap beyond which it will not detect any additional redlinked categories beyond that number, meaning that every redlinked maintenance category that fails to get treated the same as a redlinked content category pushes us that much closer and closer to being unable to detect redlinked content categories until the list is cleaned up, because each individual unresolved category gets us closer and closer to that size cap. So in theory it's not as important from a reader perspective, but in actual practice it is every bit as important from a how the tools we have to fix the problem actually work perspective, so redlinked maintenance categories absolutely do have to be taken every bit as seriously as the content kind.
Just as an example, the latest run of the redlinked category report features almost five times as many redlinked categories as usual — 441 redlinked categories where there should be less than 100, with the difference accounted for almost entirely by template-generated quality-importance crosscat maintenance categories likely caused by the changes that inspired this discussion — but 441 categories means that if this continues, we will trip that size cap in just 11 more runs of that report if they aren't all cleaned up now. It runs every three days, which means that every category on it has to be cleaned up immediately, with absolutely no category ever carrying over to the next new run because it failed to be resolved within three days of its first appearance. So maintenance categories aren't of lesser importance than content categories are when it comes to resolving the report.
In truth, I have deep doubts that any categories of the quality-x-importance type are necessary at all, but it's beyond my pay grade to mount any sort of campaign to have them kiboshed across the board — but at the very least, there needs to be significantly more effort made to make them stop flinging 441 categories of redlinked crap at my face. If they're genuinely desired, then there needs to be a mechanism in place to make sure that either they get automatically created the moment they're needed or they just don't happen in the first place, because it's not my responsibility to put up with repeatedly having to fix hundreds of these over and over again. These need to stop becoming WantedCategories problems that land on my plate to deal with. Bearcat (talk) 17:02, 4 October 2023 (UTC)
You sound very upset about this - maybe keep things in perspective? I have already proposed a solution to this issue (below). I will deploy it tomorrow. — Martin (MSGJ · talk) 20:20, 4 October 2023 (UTC)
Not guilty! To check, I restored an old version into the sandbox and the same red categories appear on Talk:Golconda diamonds. What happened yesterday is someone changed its rating to A-class, and obviously the A-class categories do not exist. We could (a) revert the change in rating (because I don't think it went through any kind of A-class review, (b) create the required categories, (c) disable the categories for WikiProject Telangana, and/or (d) add some code to check whether the category exists before using it — Martin (MSGJ · talk) 08:48, 4 October 2023 (UTC)
I have reverted the change in ratings and left a note for the editor. That solves the immediate problem, but we can also add the exist check to stop this happening in future? — Martin (MSGJ · talk) 09:03, 4 October 2023 (UTC)
That explanation makes sense. As I said above, I just stumbled upon the red links and didn't dig in to figure out what was causing what; I do that a few times per day with other template issues and know that it can be a rabbit hole, and I didn't have the energy for this one. – Jonesey95 (talk) 14:23, 4 October 2023 (UTC)
Code on the sandbox will only categorise if the category exists and is non-empty — Martin (MSGJ · talk) 15:01, 4 October 2023 (UTC)
"and is non-empty" seems circular - just existence checking should suffice. * Pppery * it has begun... 23:14, 4 October 2023 (UTC)
This is how we've done it previously. It allows non-admins the ability to reverse the change - just blank the page and it will then not be used and can be tagged for deletion. Even for admins, populated categories can't be deleted, so there would be no way to stop using a particular category that is no longer needed. — Martin (MSGJ · talk) 07:54, 5 October 2023 (UTC)

Missing closing p tag after updates

MSGJ, there is a missing </p> after "as follows:" in Module:WikiProject banner/templatepage. Can you (or someone) please adjust the code to close that tag? I'm pretty sure it needs to be immediately after the colon, as opposed to after the ul list. – Jonesey95 (talk) 15:02, 12 October 2023 (UTC)

How's that? — Martin (MSGJ · talk) 15:09, 12 October 2023 (UTC)
Much better, thanks. I'm still seeing an unclosed p tag at {{WikiProject Medicine/sandbox}}, which probably does not use the live module. That's less of a concern than live pages, though. – Jonesey95 (talk) 17:38, 12 October 2023 (UTC)

Error on Template:WikiProject Military history

Just dropping this here because I don't know how to fix it yet. Template:WikiProject Military history has an unrecognised parameter error. This is because |list= and |A-Class= are passed for the benefit of the custom mask, but the banner is not expecting those parameters. Ideally we would not pass those parameters, and instead tweak the call to Module:Arguments so it looks at the parent frame arguments. — Martin (MSGJ · talk) 18:15, 17 October 2023 (UTC)

Task force text

I think it would be useful to have a |TF_TEXT= option which would define how the text for each task force is formatted. It would have access to the name, link, and normalised taskforce importance via special strings _NAME_, _LINK_, _IMPORTANCE_ which will be substituted by the module. In most banner templates it would save having to define TF_1_TEXT, TF_2_TEXT, etc. separately. For example it could be used as follows:

TF_TEXT = This article is supported by the [[_LINK_|_NAME_ task force]] (rated as _IMPORTANCE_-importance)

— Martin (MSGJ · talk) 07:31, 18 October 2023 (UTC)

Inactive banners

I've got a conversion of Template:Inactive WikiProject banner on Module:WikiProject banner/sandbox, with a test on Template:WikiProject The KLF/sandbox. We could now customise the inactive project banners further if wanted. — Martin (MSGJ · talk) 21:08, 20 October 2023 (UTC)

This has now been implemented, and inactive project banner templates can use the "inactive" function of Module:WikiProject banner, i.e. replace the top line of code with {{#invoke:WikiProject banner|inactive — Martin (MSGJ · talk) 12:25, 23 October 2023 (UTC)

Deprecation of QUALITY_SCALE parameter

At some point in the future, this parameter may not be needed anymore. The four options are:

  • standard: this can be omitted anyway as it is the default.
  • extended: this is the standard scale plus a few extras for non-articles. Since July we only use these extra classes if the categories actually exist. So this can become the default behaviour.
  • inline: there are no more of these left in the wild.
  • subpage: any project using a custom mask should also be using |QUALITY_CRITERIA=custom so these parameters will mean the same thing, and therefore |QUALITY_SCALE=subpage is redundant.

— Martin (MSGJ · talk) 09:32, 18 October 2023 (UTC)

This parameter has now been deprecated, so the method to use a custom class mask is now |QUALITY_CRITERIA=custom — Martin (MSGJ · talk) 21:47, 24 October 2023 (UTC)
Is this change the reason why a few hundred "/class" template subpages, such as {{WikiProject Bible/class}}, just showed up on Wikipedia:Database reports/Unused templates (filtered)/1, a report that lists template pages with no transclusions? – Jonesey95 (talk) 15:33, 26 October 2023 (UTC)
No, not caused by this change directly, but all part of the drive to harmonise ratings across WikiProjects. Please see Wikipedia:Templates for discussion/Log/2023 October 26#Unused wikiProject custom class masks — Martin (MSGJ · talk) 16:22, 26 October 2023 (UTC)
Ah, very good. Thanks for the link. – Jonesey95 (talk) 17:23, 26 October 2023 (UTC)

Lua "The time allocated for running scripts has expired." error at Portal talk:Jakarta

{{WikiProject Portals}} is causing a Lua The time allocated for running scripts has expired error at Portal talk:Jakarta. I don't know why it would have cropped up just recently. My only guess is that some change to this Module has caused the page to use too much Lua time. I notice also that the template is trying to transclude Portal talk:Jakarta/Related portals, Portal talk:Jakarta/Topics, and Portal talk:Jakarta/box-header, which do not exist. That the latter is missing appears to cause a Linter unclosed table error. I created a redirect there, which solved the Linter error on a similar page. – Jonesey95 (talk) 13:03, 30 October 2023 (UTC)

Seems to be related to Module:Portal maintenance status because when I removed this on the sandbox it then loads okay — Martin (MSGJ · talk) 14:58, 30 October 2023 (UTC)
Fixed - the template's documentation says not to put it inside tables or other templates, so I moved it to the top of the page. Perhaps something about WOSlinker's edit on 28 Oct triggered this — Martin (MSGJ · talk) 15:08, 30 October 2023 (UTC)
Nice work. So why did fixing something on the Portal page fix a script timeout error on the Portal talk page? It appears that Portal talk:Jakarta transcludes Portal:Jakarta in some way. Is that transclusion necessary? – Jonesey95 (talk) 16:03, 30 October 2023 (UTC)
It's Module:Portal maintenance status - I'm not sure of the details — Martin (MSGJ · talk) 16:09, 30 October 2023 (UTC)
That module was also causing issues on Portal talk:Somaliland with the layout of the banners, so I removed it from Portal:Somaliland a couple of days ago as I couldn't find any better fix for it. -- WOSlinker (talk) 18:27, 30 October 2023 (UTC)

Nomination for deletion of Template:WPBannerMeta

 Template:WPBannerMeta has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. — Martin (MSGJ · talk) 08:52, 2 November 2023 (UTC)

Nomination for deletion of Template:Inactive WikiProject banner

 Template:Inactive WikiProject banner has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. -- 65.92.247.90 (talk) 13:02, 3 November 2023 (UTC)

Auto parameter

Noting here: we can now remove support for the {{auto|}} parameter from all PIQA projects; the bot should also remove it en masse from talk pages. DFlhb (talk) 11:18, 6 November 2023 (UTC)

Are you proposing to move this note to the banner shell, or remove completely from all banners? — Martin (MSGJ · talk) 12:58, 6 November 2023 (UTC)
Remove completely, as moot - DFlhb (talk) 13:10, 6 November 2023 (UTC)
I'm not sure I follow. Are you saying that articles will not be automatically assessed in the future? Because I doubt that is true — Martin (MSGJ · talk) 21:02, 7 November 2023 (UTC)
AFAIK it was only ever used by bots, copying class ratings from projects that had one, to projects that didn't, adding |auto= so the rating could be manually reviewed (which no one did) in case projects disagreed with each others' assessments. Was also used in bot runs tagging a WikiProject onto all talk pages in a category tree, also involving the same class copying/inheritance. With PIQA 'inheritance' is the goal and doesn't require manual review. Not aware of another it was used by bots, except copying assessments across projects. Am I missing anything? DFlhb (talk) 21:30, 7 November 2023 (UTC)
I agree that once PIQA is rolled out, automatically assessing by inheritance will not be necessary. I believe there are other bots that do/did automatic assessments based on other crtieria, e.g. stub-class based on the length of the article. — Martin (MSGJ · talk) 09:54, 9 November 2023 (UTC)

collaboration parameters missing from auto documentation

I've set Template:WikiProject Zimbabwe to |DOC=auto which works, but it doesn't show the 3 collaboration parameters that the template uses. Gonnym (talk) 09:22, 10 November 2023 (UTC)

I also noticed that the documenation for the infobox parameter under "Notes and alerts" thinks the parameter name is |infobox= while under "Full usage" (and in the actual code), the name is |needs-infobox=. Gonnym (talk) 09:25, 10 November 2023 (UTC)
It is true, I have not yet added the collaboration parameters to the auto doc. Some other rarely used parameters are also still to be included. I've fixed the issue with the infobox parameter in the sandbox. — Martin (MSGJ · talk) 10:51, 10 November 2023 (UTC)
I created Category:WikiProject banner templates using undocumented features to find which features most urgently need documenting. I am working on image-needed at the moment, and will get to collaboration later, unless anyone else can help with this — Martin (MSGJ · talk) 10:39, 15 November 2023 (UTC)

Auto doc code style request

While testing (in preview) the auto doc withTemplate:WikiProject Television I saw a difference that I think the auto doc could benefit. In Module:WikiProject banner/config#L-379 section and below, can you replace:

  • set _PARAMETER_ to "yes", which produces a text like set needs-infobox to "yes", with
  • set {{para|_PARAMETER_|yes}}, which produces a text like set |needs-infobox=yes

If using the {{para}} there is problematic then even manually creating a similar style would be good. Gonnym (talk) 07:49, 15 November 2023 (UTC)

Could we encode this as something like _PARAMETER_|yes so that gsub can be told to put what comes after the pipe as the argument of the parameter — Martin (MSGJ · talk) 10:38, 15 November 2023 (UTC)
So going by what you asked, this should work:
local doc = "_PARAMETER_|yes"
local parameter =  doc:gsub('|yes', ''):gsub('_PARAMETER_', 'needs-infobox')
local value = doc:gsub('_PARAMETER_|', '')
local code = "<code>|%s=%s</code>"
local result = code:format(parameter, value)
print(result)
For readability I would split line 2. Gonnym (talk) 11:50, 15 November 2023 (UTC)
Another option would be to make the auto_doc table another level deep, so that you just store the value. That way you have config.auto_doc.infobox.value. Not sure which is better though. Gonnym (talk) 11:54, 15 November 2023 (UTC)
Should be possible to do this more efficiently with capture, e.g. '_PARAMETER_%|(%a+)' ? — Martin (MSGJ · talk) 12:33, 15 November 2023 (UTC)
Possible code on the sandbox. Not convinced it will work for _PARAMETER_ without value, but need to test it — Martin (MSGJ · talk) 16:43, 15 November 2023 (UTC)
I've tested in on Template:WikiProject Television/sandbox and it works good. Gonnym (talk) 17:07, 15 November 2023 (UTC)
Unrelated to the above changes, the |needs-ref= bullet uses _PAGETYPE_ in the text description, which is shown like that (instead of a page type) with the auto doc. Any idea what a fix might be here? Gonnym (talk) 17:11, 15 November 2023 (UTC)

Linter error in sandbox invocation

At Template:WikiProject Algeria/sandbox, the code expands to:

Will be categorised into Category:Wikipedia requested photographs in {{{<code class="tpl-para" style="word-break:break-word">|image-location=</code>}}}

which then evaluates to

Will be categorised into Category:Wikipedia requested photographs in image-location=</code>

and does not render correctly in the documentation. I don't think any of that is what was intended. – Jonesey95 (talk) 17:38, 15 November 2023 (UTC)

An unintended consequence of the changes discussed one section above. I'm still working on this code anyway, so it will be fixed somehow — Martin (MSGJ · talk) 17:57, 15 November 2023 (UTC)
If local code = "<code>|%s=%s</code>" is being used, you might just need <nowiki>...</nowiki> tags inside the <code>...</code> tags. There is probably a more sophisticated solution. – Jonesey95 (talk) 18:43, 15 November 2023 (UTC)

B-class checklists

Please see the discussion at Wikipedia talk:WikiProject Council § Determining the future of B-class checklists which may involve changes to this module — Martin (MSGJ · talk) 22:43, 8 November 2023 (UTC)

I have closed this discussion with consensus to remove the B-class checklist from any banner which has not opted out of PIQA, i.e. has not set |QUALITY_CRITERIA=custom — Martin (MSGJ · talk) 15:03, 14 November 2023 (UTC)
Updated code on sandbox. B-class checklist will not be displayed unless |QUALITY_CRITERIA=custom — Martin (MSGJ · talk) 08:17, 16 November 2023 (UTC)

Dab being generated to Wikipedia:Lists

@MSGJ: but it's fixed in the sandbox! But I'm not familiar with rest of the code at all, so there might be a better solution. Plus there're 10e7 transclusions, so I'd rather someone more knowledgable take a look at it.   ~ Tom.Reding (talkdgaf)  21:28, 18 November 2023 (UTC)

Is there an example page with a banner but no direct links to Wikipedia:Lists on the rest of the talk page? I looked at a few and all had a direct link somewhere on the page. -- WOSlinker (talk) 21:50, 18 November 2023 (UTC)
@WOSlinker: see Talk:Meanings of minor planet names: 599001–600000.   ~ Tom.Reding (talkdgaf)  22:06, 18 November 2023 (UTC)
I went to [3] but didn't see that page in the list. Am I looking in the wrong place? -- WOSlinker (talk) 23:01, 18 November 2023 (UTC)
This edit, which added {{WikiProject Lists}}, was automatically tagged with "Disambiguation links added", but this edit, which added {{WikiProject Lists/sandbox}}, did not.   ~ Tom.Reding (talkdgaf)  00:48, 19 November 2023 (UTC)
When I added the sandbox version to a page, with this edit, it showed that tag as well, so I'm not sure your sandbox fix fully works. -- WOSlinker (talk) 09:41, 19 November 2023 (UTC)
Fixed!   ~ Tom.Reding (talkdgaf)  10:51, 19 November 2023 (UTC)
I've had a look at this in a bit more detail and it wasn't the project link causing the issue. It wasn't looking at Wikipedia:Lists at all. What it was doing was looking at Lists (which is also a disambig page). The code that is causing the issue is on line 191 and is checking for the existance of the Lists page. I've done an update in the sandbox that avoids the checking if the MAIN_TEXT parameter is set which seems to fix this. MSGJ, would you be able to check that this change works ok? -- WOSlinker (talk) 12:25, 19 November 2023 (UTC)
Looks good - thanks for looking into this! — Martin (MSGJ · talk) 21:29, 19 November 2023 (UTC)

Rating non-articles

Following a discussion at Template talk:WikiProject banner shell I have proposed a change in the logic of Module:Class mask so that all non-articles be rated automatically without regard to the |class= parameter. In other words, a non-applicable |class=stub on a Template would be ignored and the rating will be Template-class not Stub-class. This would apply to all non-articles, e.g. redirects, drafts, files, disambiguation pages, portals, etc. The only exception (I think) is that |class=FM is allowed in the File namespace. Please direct any comments to Template talk:Class mask#Rating non-articles — Martin (MSGJ · talk) 21:53, 25 November 2023 (UTC)

demo_page parameter

As more of the class assessments are now set automatically based on namespace and what templates are used on the page, I'm planning to add a demo_page parameter in order to test how the module will behave on different pages. Template:WikiProject banner shell already has such a parameter. — Martin (MSGJ · talk) 18:33, 4 December 2023 (UTC)

Highlight conflicting ratings

I would like to propose a red border, or similar, when a rating is given which conflicts with the project-independent quality assessment. See Old revision of Talk:Freemasonry in Montenegro for an example of how it could look. — Martin (MSGJ · talk) 21:31, 3 December 2023 (UTC)

Other suggestions:
  1. Apply red border to the quality rating in the expanded version of the banner. The idea is that this should be a copy of the bubble in the collapsed version, so should convey the same information ideally.
  2. Add a note in the banner to explain that the rating conflicts with the PIQA rating, perhaps with a link to an information page with details on PIQA and how to update the article's rating.
None of this will apply to projects which have opted out of PIQA. — Martin (MSGJ · talk) 12:41, 4 December 2023 (UTC)
I agree in principle. I have no thoughts on how it would look though. -Kj cheetham (talk) 18:37, 5 December 2023 (UTC)
I added the red border to the bubble. Regarding other suggestion 1, this will take more work as Module:Class needs to be modified. That might expedite the proposed merge of that module into this module. Other suggestion 2 probably makes sense to do at the same time. The usual wording could be replaced by This article has been given a rating which conflicts with the project-independent quality rating in the banner shell. Please resolve this conflict if possible. See XXX for more information. — Martin (MSGJ · talk) 15:37, 6 December 2023 (UTC)
I have added the code for this to the sandbox, and there is a test on Module talk:WikiProject banner/testcases to show what it would look like. — Martin (MSGJ · talk) 13:05, 18 December 2023 (UTC)

Listing of draft articles as unassessed

  Moved from User talk:MSGJ

Sorry to bother you once again, Martin, but I have just noticed that today for the first time draft articles in WP Italy are now being listed as unassessed. See here. Do you happen to know if this is intentional and if so, why? You will see they are not listed under Category:Unassessed Italy articles (but that's logical as they're drafts, not articles).--Ipigott (talk) 12:12, 18 December 2023 (UTC)

Just dropping this here in case anyone has time to look into this issue — Martin (MSGJ · talk) 16:56, 18 December 2023 (UTC)
I see the problem has now been fixed.--Ipigott (talk) 06:46, 19 December 2023 (UTC)
No idea what caused it, but don't think it was template-related — Martin (MSGJ · talk) 09:19, 19 December 2023 (UTC)

Merge of B-class checklist

I am planning to make this change tp the B-class checklist code, to allow the deprecation of Template:WikiProject Military history/bchecklist. Pinging @DFlhb for any comment. — Martin (MSGJ · talk) 17:02, 18 December 2023 (UTC)

Looks fine to me - DFlhb (talk) 18:57, 19 December 2023 (UTC)

Discussion at Template talk:WikiProject banner shell § Duplicate banner templates category

  You are invited to join the discussion at Template talk:WikiProject banner shell § Duplicate banner templates category. ‍—‍a smart kitten[meow] 01:23, 26 December 2023 (UTC)

WP US not hooking into PageAssessments

Template:WikiProject United States appears to use this banner template, but it doesn't seem to be hooking into PageAssessments for its subprojects. I started a discussion at the appropriate spot three months ago, but nobody is answering it. This is causing incomplete data in the CleanupWorklistBot-generated lists, specifically importance and class aren't showing up. Can this be fixed somehow, or am I going to have to consider withdrawing projects I maintain from WP US just to get a banner that performs as it should? Stefen Towers among the rest! GabGruntwerk 18:58, 4 January 2024 (UTC)

I believe it is working correctly. I chose a random example Digital Equipment Corporation and you can see the subproject Massachusetts at the bottom of this. If you still think there is an error, can you provide an example that does not work? — Martin (MSGJ · talk) 20:01, 4 January 2024 (UTC)
I linked to the example. They're not showing up in the CleanupWorklistBot results, which draws from PageAssessments. Stefen Towers among the rest! GabGruntwerk 20:02, 4 January 2024 (UTC)
A random example from that page is 1792 Bourbon and the output is here. I suspect the problem is with that tool, not with this module. — Martin (MSGJ · talk) 20:04, 4 January 2024 (UTC)
Hrrrm, thanks. I had no idea how to check this area as it's completely outside my knowledge set. Well, back to the bot developer. :) Stefen Towers among the rest! GabGruntwerk 20:07, 4 January 2024 (UTC)
I would ask the question whether User:CleanupWorklistBot is designed to work with subprojects, and if not could that functionality be added — Martin (MSGJ · talk) 20:08, 4 January 2024 (UTC)
OK, this is now cleared up and bot's code has been changed to cover this. Thank you for your assistance! Stefen Towers among the rest! GabGruntwerk 20:38, 5 January 2024 (UTC)

Class colours

We are currently using two sets of colours for the quality classes. The main set comes from Module:Class and a separate set of paler colours which were developed in response to concerns about contrast and accessibility, and are used for the assessment "bubbles", which you see in the nested version.

Class Standard Pale
FA
A
GA
B
C
Start
Stub
List
NA
Unassessed

I was going to suggest that we settle on using the pale set for both? — Martin (MSGJ · talk) 19:51, 17 December 2023 (UTC)

Examples below show current and proposed.
— Martin (MSGJ · talk) 13:09, 18 December 2023 (UTC)
Colours have now been updated. Should be do the same for the importance colours? — Martin (MSGJ · talk) 17:34, 19 December 2023 (UTC)
I'd support that. The accessibility reasons that drove paler colours for the bubbles, also apply to other places those colours are used - DFlhb (talk) 14:25, 20 December 2023 (UTC)
I was also wondering whether we could just put "Start" and "Low" in the bubble, rather than "Start-class" and "Low-importance". The full wording is available in the expanded version of the banner anyway. — Martin (MSGJ · talk) 15:28, 20 December 2023 (UTC)
No opinion, I'll let others chime in on that DFlhb (talk) 17:26, 20 December 2023 (UTC)

Importance colours

Importance Standard Pale
Top
High
Mid
Low
Bottom
NA
Unknown

I notice that Bottom-importance is indistinguishable from Low-importance in the pale colours. Can a paler version of Bottom be used? — Martin (MSGJ · talk) 11:16, 3 January 2024 (UTC)

These paler importance colours are now in use — Martin (MSGJ · talk) 07:48, 6 January 2024 (UTC)

Possible room for improvement in the unknown parameter check

I don't know why I had to do this (add pipes to parameter names) to have the template recognize the parameters as valid in the parameter check. See this discussion. Is there any documentation about how this module determines which parameters are valid? – Jonesey95 (talk) 23:38, 11 January 2024 (UTC)

Coincidentally, a change was made to the sandbox earlier today which should resolve this — Martin (MSGJ · talk) 23:40, 11 January 2024 (UTC)
Groovy. Thanks. – Jonesey95 (talk) 00:15, 12 January 2024 (UTC)
Super. I'll note that the /doc currently has both (piped and un-piped) as examples, which led to my own confusion (see the edits previous to Jonesey's). Primefac (talk) 07:24, 12 January 2024 (UTC)
The unpiped form is generally not a good idea.
First consider the situation when the template code has the pipe in a line like
 |tf 1 importance={{{Andorra-importance|}}}
If that template is transcluded, it makes no difference whether the |Andorra-importance= parameter is absent from a transclusion, e.g. {{WikiProject European Microstates}} with no parameters, or is present but blank, e.g. {{WikiProject European Microstates|Andorra-importance=}} - in both cases the |tf 1 importance= parameter inside the template is fed an empty string.
Now consider the situation when the template code lacks the pipe - i.e.
 |tf 1 importance={{{Andorra-importance}}}
If that template is transcluded, it does make a difference whether the |Andorra-importance= parameter is absent from a transclusion, or is present but blank. When it is present but blank, the |tf 1 importance= parameter inside the template is fed an empty string, as expected. But when the |Andorra-importance= parameter is absent from a transclusion, e.g. {{WikiProject European Microstates}} with no parameters, the literal value {{{Andorra-importance}}} is passed through |tf 1 importance=. --Redrose64 🌹 (talk) 18:09, 12 January 2024 (UTC)

PageAssessments on banners not using assessments

There is some discussion on User talk:Community Tech bot with suggestions that banners should be populating the PageAssessments database even if they are not using any quality or importance ratings. This is the first I've heard of this. Does anyone know about this? — Martin (MSGJ · talk) 11:07, 19 January 2024 (UTC)

This would be an easy fix - I'm just not convinced that we ever did this in the previous version of this template. Any reasons not to do this? — Martin (MSGJ · talk) 11:18, 19 January 2024 (UTC)
I was wrong. The previous code was {{#assessment:{{{PROJECT}}}|{{#ifeq:{{str right|{{{class|¬¬}}}|1}}|¬||{{str right|{{{class|}}}|1}}}}|{{#ifeq:{{{importance|¬}}}|¬||{{{importance}}}}}}} so we did call this for every project. I will make the fix — Martin (MSGJ · talk) 19:26, 19 January 2024 (UTC)
  Done — Martin (MSGJ · talk) 21:05, 20 January 2024 (UTC)
@MSGJ Thanks for making this change! I see now Special:PageAssessments has results for 'Classical music'. WikiProject U.S. Roads now does too, but evidently not the subprojects such as U.S. Roads/California. This issue seems to date back to March 2023, not August, so it's likely a separate issue. At quick glance, this series of edits (and possibly the subsequent use of the module) could be the cause. Any ideas? Also pinging @Fredddie. Thanks and regards, MusikAnimal talk 23:28, 24 January 2024 (UTC)
I think I've fixed U.S. Roads with the following edit. -- WOSlinker (talk) 23:59, 24 January 2024 (UTC)
PageAssessments will not be used for task forces unless the TF_n_NAME parameter is defined for each task force, so I guess this is missing for the U.S. Roads project. This project's banner is on my to-do list as it contains lots of outdated stuff, so I will hopefully get to it soon. In the meantime WOSlinker's kludge should work — Martin (MSGJ · talk) 08:55, 25 January 2024 (UTC)
Sounds great. Thank you all! MusikAnimal talk 19:03, 25 January 2024 (UTC)

Alternative way of triggering task forces

Some projects, including US Roads discussed above, have a different way of triggering task forces, where the value of a parameter defines the task force rather than the name of the parameter. For example |AL=yes uses the name of the parameter "AL" to define the task force; this is the way that most banners work. US Roads uses |state1=AL or |state2=AL, etc. and the value of the parameter "AL" defines the task force. This is currently really hard to code using this module, so I am thinking about other possibilities.

For example we could use |TF_PARAMETER_PREFIX=state with |tf 1=AL (or maybe a different parameter like |tf 1 value=AL would be more sensible). Then the module could check all parameters of the form |state1=, |state2=, |state3=, etc. and if any of those have value "AL" then the task force is triggered.

I'm just brainstorming at the moment, so any ideas would be good — Martin (MSGJ · talk) 10:08, 31 January 2024 (UTC)

In that specific template, is there anything that is blocking converting |staten= uses (|state20=AL) to just use |AL=yes? Gonnym (talk) 15:32, 31 January 2024 (UTC)
Do you mean a bot run to change these over? Yes, that could be possible alternative if the project was okay with that. — Martin (MSGJ · talk) 15:54, 31 January 2024 (UTC)
Yes. It seems much more trouble adding and supporting code that only one project uses instead of fixing that project's code to use the same style that every other project does. Gonnym (talk) 18:18, 31 January 2024 (UTC)
I've made the suggestion at Template talk:WikiProject U.S. Roads — Martin (MSGJ · talk) 18:31, 31 January 2024 (UTC)
An unpromising response over there. I feel it wouldn't be difficult to add this functionality to the module, without adding any overhead to existing uses. It could also be useful in other banners, e.g. Canada Roads — Martin (MSGJ · talk) 19:00, 2 February 2024 (UTC)

More page types

Now Module:Pagetype has the ability to detect two more types of page: soft redirects and set index articles. I proposed to make use of this by:

  • Automatically assessing soft redirects as Redirect-class, in any namespace;
  • Automatically assessing set index articles as List-class in article space, if no valid class is defined. (There are sometimes SIAs which are mischaracterised, so it would be useful to be able to override the default.)

Thoughts? — Martin (MSGJ · talk) 18:59, 2 February 2024 (UTC)

Code for this is now on Module:WikiProject banner/sandbox and Module:Banner shell/sandbox. Requested by @PARAKANYAA and @Hawkeye7. Have also taken the time to merge in the code from Module:Class mask. Needs a lot more testing though ... — Martin (MSGJ · talk) 20:11, 25 February 2024 (UTC)
Switching to use the sandbox version moved the article from Category:Unassessed articles to Category:NA-Class articles but I think it should be in Category:Redirect-Class articles. Hawkeye7 (discuss) 20:43, 25 February 2024 (UTC)
Please tell me which page you are testing on? Redirect-class will generally be used if the project has created the corresponding category, otherwise it falls back to NA-class — Martin (MSGJ · talk) 20:45, 25 February 2024 (UTC)
The page in question is -izzle. I have left it using the sandbox version so you can see it. Originally it had the banner shell but was not tagged for a project; I don't know how many of these are out there. As noted, Sandbox version switched it from Category:Unassessed articles to Category:NA-Class articles. Then, in response to your comment, I added a project template, {{WikiProject English Language}}. This is a standard template that uses Module:WikiProject banner. This caused a switch. It is now listed as Category:Unassessed English Language articles despite the fact that the {{WikiProject banner shell/sandbox}} template has a Class=Redirect card. No error is reported. I think it should have gone into Category:NA-Class English Language articles although it would be better still to create the Redirect category. Hawkeye7 (discuss) 21:03, 26 February 2024 (UTC)
It's because {{WikiProject English Language}} is using the live code and not the sandbox code that I have changed. If you have a look now, I have added the sandbox version and it is using Category:NA-Class English Language articles. (If Category:Redirect-Class English Language articles existed then it would use that, but it doesn't so falls back to NA-Class.) Hope this all makes sense — Martin (MSGJ · talk) 22:14, 26 February 2024 (UTC)
Most tests are working well (see Module talk:WikiProject banner/testcases). There is one apparent issue. I proposed above that set index articles could be manually assessed but will default to List-class. This is indeed possible, but this manual assessment would not be inherited by banners inside the banner shell (inheriting only happens if the article is otherwise unassessed by the banner, but in this situation it will not be unassessed because it will default to list-class). So I think the only two options are:
  • Automatic assessment of SIAs as list-class: no ability to override manually
  • No auto-assessment of SIAs: each one will need to be assessed individually (this is the status quo)
Not sure if anyone has an opinion of this? — Martin (MSGJ · talk) 19:30, 26 February 2024 (UTC)
I suspect the status quo is better (manual is better than incorrect automatic), but the cost of such errors appears to be low, so I don't hold the opinion strongly. — hike395 (talk) 09:08, 27 February 2024 (UTC)
I don't really mind either way. A few comments:
  • Wikipedia:Content assessment makes it clear that a SIA should be assessed as List-class.
  • If editors are trying to change that, it's probably because it's not really an SIA, in which case the template on the article should probably be changed.
  • A common issue is that editors try to rate them as Disambig-class instead. This causes issues because Disambig-class is automatically detected, and only when specific disambiguation templates are used on the article. Auto-assessing these as List-class might prevent this issue.
So we can either keep status quo (probably more straightforward) or we can start auto-assessing and be ready to revert if any problems/complaints arise. If no complaints, then it means it was the correct thing to do. — Martin (MSGJ · talk) 12:28, 28 February 2024 (UTC)

No further comments so I have implemented the code (without the SIA detection for now) — Martin (MSGJ · talk) 12:49, 1 March 2024 (UTC)

This is fine by me. My concern was articles being marked as unassessed when they were not. I think at redirect and disambig should be standard grades, but that a a debate for another place and time. Hawkeye7 (discuss) 21:00, 1 March 2024 (UTC)