Module talk:WikiProject banner

Warnings

I would like to add some prominent warnings when people try to use the |class= parameter in a project banner instead of in the banner shell template

1. If {{WikiProject banner shell}} is already on the page (but without a |class= parameter), then the message will say something like
2. If {{WikiProject banner shell}} is not on the page yet, then the message will say something like

I'm sure the wording could be improved. What do you think? — Martin (MSGJ · talk) 12:08, 10 June 2024 (UTC)

Please add {{WikiProject banner shell}} to this page and add the quality rating to it. maybe something like this? Regardless, link the banner shell template. I'm in favor of the warning. Gonnym (talk) 21:38, 10 June 2024 (UTC)

Yep, probably a link a WP:PIQA somewhere in there too — Martin (MSGJ · talk) 21:39, 10 June 2024 (UTC)

This should be expended to any parameter we migrate to the shell, like |listas= do deal with redundant, duplicate or conflicting data. Gonnym (talk) 16:20, 11 June 2024 (UTC)

This is now coded on the sandbox. Example of the first message can be seen at Module talk:WikiProject banner/testcases#Globally unassessed. the second message below — Martin (MSGJ · talk) 10:24, 3 July 2024 (UTC)

Okay this is ready to go, but I will wait for Category:Pages using WikiProject banner shell without a project-independent quality rating (0) and Category:Articles with WikiProject banners but without a banner shell (41) to be emptied first to avoid ugly warnings on so many pages — Martin (MSGJ · talk) 09:35, 4 July 2024 (UTC)

Note: this is now deployed — Martin (MSGJ · talk) 12:17, 16 August 2024 (UTC)

Is it too late for me to object to this? As I said at the template talk page, something like this is just dumb; if we are going to force people to use the banner shell, then we should integrate it into every WikiProject banner automatically. I don't mind giving a warning if there's already a WPBS on the page, since it's a "hey, this is here, please put your banner in the right place", but for a page with no shell it shouldn't have a warning. (please do not ping on reply) Primefac (talk) 21:26, 17 August 2024 (UTC)

What Primefac said. On talk pages other than the main Talk: space, people should not be forced to use a WPBS, particularly when there is only one WP banner, because the autodetection of class is pretty much universal. --Redrose64 🌹 (talk) 07:29, 18 August 2024 (UTC)

The error can probably be removed from the user space. Other than in user space (which the updated code isn't placing in Category:WikiProject banners without banner shells (pages there need to be purged to reflect the update), so will not be relevant here), almost all pages have already been placed inside the banner shell, so any change at this point is purely disruptive, in addition of course, to the fact that no ones owns project pages so no one is forced into anything. Having the shell, even for one template, provides a consistent look across the entire project and allows any future update (which might be relevant to pages with a single template), to have an immediate effect. Gonnym (talk) 07:43, 18 August 2024 (UTC)

no ones owns project pages so no one is forced into anything - by that logic, we should not be forced to use WPBS for a single banner by having big warning sign about it. And just to reiterate (and expand) on what I said above - I don't mind the warning if WPBS is already there (because that makes sense) and I don't care if a bot goes around adding WPBS (even for pages that have a single banner), my only concern is the massive warning given if WPBS isn't on the page already. Primefac (talk) 10:40, 18 August 2024 (UTC)

(No it's not too late to object!) We certainly can (and should) remove the message from non-article pages. For a start the message is incorrect, because these pages are detected automatically so don't even have a |class= parameter that needs transferring. What about mainspace though? We have no efficient method (that I know of) to detect the number of banners on a page, so we have to treat one banner the same as 8 banners. In mainspace we absolutely do want WPBS on every talk page. We are now 18 months into the new system, and it seems that a little editor education is needed, which is what the warning is trying to do. — Martin (MSGJ · talk) 19:26, 18 August 2024 (UTC)

We also have a bot that, once the backlog is cleared, will fix/update any new pages that aren't following PIQA. Just a thought. It probably makes editors complacent (look how many dated maintenance tags get tagged by AnomieBOT every day instead of folks just putting the date, which is piss-easy) but that's why we have bots like this in the first place. Primefac (talk) 20:10, 18 August 2024 (UTC)

Yeah, the bot is good when it works. For some reason it is not clearing Category:Articles with WikiProject banners but without a banner shell very quickly — Martin (MSGJ · talk) 17:30, 19 August 2024 (UTC)

I have removed the warning (numbered 2 above) in the sandbox. Hopefully the bot will catch up with these soon — Martin (MSGJ · talk) 17:41, 19 August 2024 (UTC)

Deployed to live — Martin (MSGJ · talk) 14:45, 2 September 2024 (UTC)

Thanks. Primefac (talk) 14:52, 2 September 2024 (UTC)

Tracking category proposed

There is a proposal to track uses of WikiProject banners which are placed outside the banner shell. The coding might be complex but I think this would be really useful — Martin (MSGJ · talk) 17:38, 29 June 2024 (UTC)

Originating discussion @ User talk:Kanashimi/Archive 1#Cewbot is moving WikiProject banners outside of WPBS.   ~ Tom.Reding (talk ⋅dgaf)  18:12, 9 July 2024 (UTC)

If there is such a tracking category, my bots will automatically repair them by default. Kanashimi (talk) 08:50, 10 July 2024 (UTC)

No progress on this, because I haven't figured out the code needed to achieve it — Martin (MSGJ · talk) 07:11, 28 August 2024 (UTC)

Could there be a check after Articles with WikiProject banners but without a banner shell is assigned, to getContent() on the current page and look for {{WikiProject banner shell}} and its redirects? If both those conditions are met, then the banner should be outside WPBS. If possible, Module:Template redirect regex can be used to centrally store/maintain that regex.   ~ Tom.Reding (talk ⋅dgaf)  12:31, 7 September 2024 (UTC)

How would you check if the template was inside or outside of the banner shell? That tracking category just checks for the existence of the banner shell on the page — Martin (MSGJ · talk) 12:57, 7 September 2024 (UTC)

I see. As luck would have it, I was testing Articles with WikiProject banners but without a banner shell on a probably-misbehaving {{WikiProject Occupations}} (no reason other than that's what was in the nearest browser window), which displayed the cat when outside of the WPBS. {{WikiProject Occupations}} in fact displays the cat (one way or another) regardless of its position relative to WPBS.

Yeah, I can't think of an easy & low-overhead way of doing this either, unless there's an easy way to transform all templates on a page to their canonical titles.   ~ Tom.Reding (talk ⋅dgaf)  17:06, 7 September 2024 (UTC)

I have asked for some help at User talk:Aidan9382 — Martin (MSGJ · talk) 21:55, 7 September 2024 (UTC)

I have written some code on my sandbox which might work. If you type {{#invoke:Sandbox/MSGJ|main|WikiProject Finland}} it will look at the content of the current page and return ...

• true if it finds {{WikiProject Finland}} anywhere outside of the banner shell,
• true there is no banner shell (so the template cannot be in a shell)
• false if it is inside the banner shell,
• false if {{WikiProject Finland}} is not found on the page (perhaps a template redirect has been used, but we have no way to check for these)

Some testing would be appreciated — Martin (MSGJ · talk) 09:04, 19 September 2024 (UTC)

1. %b{} very cool!
2. escaping %| in Lua is unnecessary
3. for mw.ustring.find(content_without_shell, '{{%s*' .. banner_name .. '%s*[%|}]') to work for all WikiProjects, escaping special characters in banner_name will be necessary to find {{WP New York (state)}}, {{WP C/C++}}, and the like. Periods shouldn't need escaping though, since they'll just match themselves.

  ~ Tom.Reding (talk ⋅dgaf)  16:58, 19 September 2024 (UTC)

Escaping these magic characters is beyond me, I'm afraid. I have tried and failed — Martin (MSGJ · talk) 21:16, 19 September 2024 (UTC)

Got it working! Check your sandbox for details.   ~ Tom.Reding (talk ⋅dgaf)  00:46, 20 September 2024 (UTC)

That's great. I just wish I understood what you've done there. Last time I did this on the authority control module, I had to use three % characters before the magic character (example) so I don't know how you have done it with just two — Martin (MSGJ · talk) 08:02, 20 September 2024 (UTC)

Ah, there are additional layers of evaluation to contend with in AC, which require more % (%%%% evaluates to %% evaluates to %).

Also, literal "%" need to be first in special_chars, or else you end up escaping them recursively an unexpected/unwanted # of times.   ~ Tom.Reding (talk ⋅dgaf)  11:10, 20 September 2024 (UTC)

Ah, good point. We should make the first character case insensitve, i.e. "wikiProject Biography" works the same as "WikiProject Biography" — Martin (MSGJ · talk) 13:51, 20 September 2024 (UTC)

 Done and Category:WikiProject banners placed outside the banner shell (4) created — Martin (MSGJ · talk) 09:19, 23 September 2024 (UTC)

I think we should restrict this to main talk namespace only, because there are lots of false positives in project space — Martin (MSGJ · talk) 11:16, 23 September 2024 (UTC)

You could maybe do something like @Galobtter did with Module:Is infobox in lead and check if the banner is at the start of the page. Maybe Galobtter could help with tweaking his previous code. Gonnym (talk) 11:20, 23 September 2024 (UTC)

Not sure how that would help in this case. Some of the banners were are trying to find are tucked further down the page (example) — Martin (MSGJ · talk) 11:25, 23 September 2024 (UTC)

Ah, then it won't help there indeed. Gonnym (talk) 11:41, 23 September 2024 (UTC)

That appears to have been a Cewbot bug, followed by an incomplete fix by Widefox (talk · contribs). --Redrose64 🌹 (talk) 16:07, 23 September 2024 (UTC)

Hmm, looks like WP:RATER didn't play well with the Cewbot buggy rating. Widefox; talk 18:16, 23 September 2024 (UTC)

Could we ignore just the namespace(s) with the most FPs instead?   ~ Tom.Reding (talk ⋅dgaf)  14:04, 23 September 2024 (UTC)

Let's ignore any namespace where there might feasibly be banners used as examples or for testing — Martin (MSGJ · talk) 15:34, 23 September 2024 (UTC)

Unmatched close-bracket error

Probably related to the recent update. This helped, sort of - it moved the error to a different location, but it's still present. The problem comes from [[]] in |comments=[[]]. The number in the error refers to the horizontal position of the error, and not a Unicode character #.   ~ Tom.Reding (talk ⋅dgaf)  15:37, 23 September 2024 (UTC)

This is bad, and I have no idea how to fix it. @Aidan9382 - any insight? The error can be seen on Talk:1993 in Lithuanian football and some other pages. We may have to remove this code if we can't find an urgent fix — Martin (MSGJ · talk) 07:38, 24 September 2024 (UTC)

@MSGJ: apologies, I've been busy. The page you link is no longer showing the issue - is the problem fixed, or is it still around in some other form, or was the change reverted? Aidan9382 _(talk) 16:29, 24 September 2024 (UTC)

I think we fixed it. It was a bit urgent so I didn't wait for your reply! Thanks — Martin (MSGJ · talk) 12:20, 25 September 2024 (UTC)

Your fix seems to have worked Tom. Where do you still see the error? — Martin (MSGJ · talk) 07:44, 24 September 2024 (UTC)

Oops, I forgot to create/check Template:WikiProject Lithuania/sandbox... Excellent!   ~ Tom.Reding (talk ⋅dgaf)  10:29, 24 September 2024 (UTC)

Simplification

@Tom.Reding: please check this possible simplification [1] — Martin (MSGJ · talk) 12:19, 25 September 2024 (UTC)

This version also has the advantage of not falsely flagging Talk:100% (band) — Martin (MSGJ · talk) 12:27, 25 September 2024 (UTC)

Interesting...using the loop method, banner_name_escaped:gsub() was the problem, since it's equivalent to string.gsub(), which returns a '�' when trying to match the literal '%'. mw.ustring.gsub() however, behaves as expected, returning '%%'. This distinction goes away when using a custom [set] though, and all of those 3 gsub calls return the desired '%%'.

I generally don't like using mystring:gsub(), since I can't be bothered to remember which .gsub it's calling, and sometimes it matters.   ~ Tom.Reding (talk ⋅dgaf)  14:24, 25 September 2024 (UTC)

The [set] method is definitely faster and less error-prone, so win-win.   ~ Tom.Reding (talk ⋅dgaf)  14:25, 25 September 2024 (UTC)

Processing pass done

I've done a pass through of Category:WikiProject banners placed outside the banner shell and have cut the number down by about half. Most of the remaining entries are pages where the syntax for a banner is inside <nowiki> tags (e.g. to use as examples in talk page discussions). Harryboyles 03:25, 29 September 2024 (UTC)

Thanks Harry. I think we can remove the ones inside nowiki or html comments, by using Module:Wikitext Parsing. I will experiment in the sandbox — Martin (MSGJ · talk) 18:03, 29 September 2024 (UTC)

 Done. This module is not so good on performance, so perhaps when we have cleared out this category we should stop checking for this — Martin (MSGJ · talk) 20:29, 7 October 2024 (UTC)

Category:WikiProject banners placed outside the banner shell has been cleared. Thanks guys! — Martin (MSGJ · talk) 11:42, 9 October 2024 (UTC)

auto doc category

Can |DOC=auto also add the template to the project category? Either Category:WikiProject project or Category:WikiProject project templates‎ category. Gonnym (talk) 11:27, 28 May 2024 (UTC)

Don't see any reason not to do this. Will sort in the next couple of days — Martin (MSGJ · talk) 15:35, 2 June 2024 (UTC)

Do you want it to check to see if Category:WikiProject project templates‎ exists first. If so use it, otherwise use Category:WikiProject project? — Martin (MSGJ · talk) 08:24, 4 June 2024 (UTC)

Yes, I think it's best to place it in the templates category if it exists. Gonnym (talk) 08:30, 4 June 2024 (UTC)

I agree. That is now coded in the sandbox, and will currently appear on sandbox templates for testing. When deployed it will only categorise the live templates. You can check Template:WikiProject Deaf/sandbox (which does not have a templates category) and Template:WikiProject Cycling/sandbox (which does have a templates category) — Martin (MSGJ · talk) 08:52, 4 June 2024 (UTC)

Great, looks good! Gonnym (talk) 09:19, 4 June 2024 (UTC)

Gonnym there are about 80 templates (see Category:WikiProject banners with errors) which are not able to populate the project category, because it either doesn't exist or because it is a category redirect. Would you like to review these? — Martin (MSGJ · talk) 12:09, 10 August 2024 (UTC)

Yeah I'm taking a look at these. So far some sent to CfD, RM, or MfD. Gonnym (talk) 12:20, 10 August 2024 (UTC)

@MSGJ most of the GLAM sub projects have a category titled: Category:Wikipedia-<project name> collaboration" (such as Category:Wikipedia-Philadelphia Museum of Art collaboration). So a template like Template:WikiProject Philadelphia Museum of Art that has a |PROJECT_LINK=Wikipedia:GLAM/Philadelphia Museum of Art can be placed there. That should remove most pages in the category. Gonnym (talk) 11:35, 11 August 2024 (UTC)

Or we can just leave them to add the categories manually, as they are currently doing? When you are done reviewing those, I can turn off the tracking — Martin (MSGJ · talk) 20:00, 11 August 2024 (UTC)

Are you finished reviewing these - and can I turn off the tracking, rather than keeping them in the error category indefinitely — Martin (MSGJ · talk) 19:23, 3 September 2024 (UTC)

Well I've added some code to the sandbox to support these (if we want), but you could turn it off. I've reviewed most, but I'm not a fan of reviewing categories that can never be cleared as it has me checking things I've already looked at before. Gonnym (talk) 23:02, 3 September 2024 (UTC)

Yes that is my concern too - that we can never resolve some of these issues, so they are not actually "errors" — Martin (MSGJ · talk) 07:38, 4 September 2024 (UTC)

Is Module:WikiProject banner/templatepage/sandbox ready to deploy or not needed? — Martin (MSGJ · talk) 23:04, 5 October 2024 (UTC)

CSS background colors need corresponding colors for dark mode compliance

CSS background colors need corresponding colors for dark mode. I inserted a fix for at least some of them, but apparently I did not follow process. Sorry about that. I'll leave it to others. If you are sandboxing and troubleshooting, you can see if you have resolved the problems by checking the bottom of the "Page information" page for "Background color inline style rule exists without a corresponding text color" Lint errors. To verify the visual appearance, you can go to the "Appearance" section of the right-hand sidebar in Vector 2022 and choose "Dark" under "Color (beta)". Using Special:ExpandTemplates is helpful for locating stray instances of CSS background-color defined without a color. – Jonesey95 (talk) 14:05, 20 August 2024 (UTC)

I don't know much about this, but I added this to Module:WikiProject banner/sandbox/styles.css and then checked at Template:WikiProject France/testcases but it is still showing as having 2 lint errors, so not sure if that has helped or not. I am using Vector 2022 but I don't see the Appearance section in my browser so can't check that. I notice that there are several other styles which define background-color but not color. Is it safe to use black for all these? — Martin (MSGJ · talk) 12:09, 21 August 2024 (UTC)

Thanks. If you copy the template call into Special:ExpandTemplates and then search the resulting wikicode for "back", you should see

<td class="assess import import-Unknown" style="background:#DCDCDC">[[:Category:Unknown-importance France articles|???]]</td>

(which renders the box to the left of "This article has not yet received a rating"). That background needs a corresponding color. There are many instances like this in the code, though some of them exist only with specific combinations of parameters and values. I don't think that all of the background colors are in the templatestyles page, but I could be wrong. Here are a couple of places in the code where I matched a "background" assignment with a "color" assignment and was reverted. Assigning "color:black" should be fine until someone wants something more sophisticated in dark mode. – Jonesey95 (talk) 14:13, 21 August 2024 (UTC)

Yes but I added color:black to the assess class so that should cover that particular part — Martin (MSGJ · talk) 18:14, 21 August 2024 (UTC)

I expect that the Linter is confused about |style= defining the background-color while the color is defined in the class. Can the background color be moved to the CSS, or the color be moved to the style? I will also ask our WMF staffer who has been communicating with us about this new Linter flag, because it looks to me as if the td element has both a color and background-color and should not register as an error. – Jonesey95 (talk) 20:39, 21 August 2024 (UTC)

Yes I expect we could define all the background colours in the stylesheet rather than in the config file. We would just need to define each class/importance as a separate class. I could look at this if you think it would help — Martin (MSGJ · talk) 15:50, 22 August 2024 (UTC)

I haven't had a response yet at WT:Linter, but it has been less than 24 hours, so some patience is still in order. If you think that moving more styles to the CSS stylesheet is a good long-term move anyway, your development time probably won't be wasted. – Jonesey95 (talk) 18:07, 22 August 2024 (UTC)

I received a response at WT:Linter. I am not sure if it helps; it's not a quick fix for me, but someone may want to have a go at it and fix dark mode for a few million pages. – Jonesey95 (talk) 23:36, 4 September 2024 (UTC)

Yes we can do this. I can work on it next week perhaps. I have followed up on that thread to clarify something — Martin (MSGJ · talk) 09:41, 6 September 2024 (UTC)

Just to note that I have made a start on this. The background colors for importance have now been moved into the stylesheet. I will continue with the class colors shortly — Martin (MSGJ · talk) 14:09, 27 September 2024 (UTC)

@Jonesey95 finished coding this on the sandbox. Would be grateful if you could test it works, and also advise on whether the linter errors have now gone away? — Martin (MSGJ · talk) 22:01, 27 September 2024 (UTC)

The sandbox version at Template:WikiProject France/testcases is reporting zero Linter errors. It appears to be using the sandbox version of all relevant modules and templates, so I think that the new coding is actually being used in the sandbox example cases. I do note a number of appearance changes, including a collapsed section in the sandbox that is not collapsible in the live version, and a note about importance in the sandbox version. I am assuming that those are also desirable changes, along with the color/background-color fixes. Thanks for working on this. – Jonesey95 (talk) 22:13, 27 September 2024 (UTC)

Thank you. Yes, the other changes you observe are due to (a) sandbox not in sync with live, and (b) changes to importance we are discussing below — Martin (MSGJ · talk) 07:32, 28 September 2024 (UTC)

Before deploying this, I would like to check a few details:

• Is a comma the correct way to give the same definition to two different classes, e.g. .class-fa, .class-fl {background-color: #BED3FF;}
• If a class is used but not defined in the stylesheet, will it give an error or will it just be ignored?
• If two different classes are used with conflicting styles, will the one which is applied later take precedence?

I might think of some more questions — Martin (MSGJ · talk) 07:36, 28 September 2024 (UTC)

Comma is correct, this is the syntax for a list of selectors - if either selector matches an element, the declaration-list is applied to that element.

Classes are merely ways of giving convenient labels to one or more elements. The HTML 5.2 spec isn't too good on this, but the HTML 4.01 spec is better:

The class attribute ... assigns one or more class names to an element; the element may be said to belong to these classes. A class name may be shared by several element instances. The class attribute has several roles in HTML:

• As a style sheet selector (when an author wishes to assign style information to a set of elements).
• For general purpose processing by user agents.

So a class name that is used in the page source has no requirement to be used in a style sheet, and vice versa. The same goes for ids.

Your third question is more complicated. It's partly down to the order in which HTML elements are nested, partly down to the order in the style sheet, and partly down to what is known as "specificity". Assume that we have a style sheet like this:

/* Style sheet example 1 */
.bar { background-color: pink; color: black; }
.foo { background-color: lightblue; color: black; }

and HTML like this:

<!-- HTML example 1 --><span class=foo><span class=bar>Some text</span></span>

the words "Some text" will show on a pink background because the element of class bar is nested inside the element of class foo, and the order of the two rules in the style sheet is immaterial. But if we have HTML like this:

<!-- HTML example 2 --><span class="foo bar">Some text</span>

and style sheet example 1, the words "Some text" will show on a lightblue background; and if we exchange the rules in the style sheet:

/* Style sheet example 2 */
.foo { background-color: lightblue; color: black; }
.bar { background-color: pink; color: black; }

the words "Some text" will now show on a pink background because the second rule overrides the first. For these two cases, whether we use HTML example 2 or this:

<!-- HTML example 3 --><span class="bar foo">Some text</span>

makes no difference, because the order of class names in a class= attribute is immaterial. Now assume that the style sheet is now:

/* Style sheet example 3 */
span.bar { background-color: pink; color: black; }
.foo { background-color: lightblue; color: black; }

and using HTML example 2 or 3, the words "Some text" will show on a pink background because the selector of the first rule has higher specificity than the selector of the second rule.

HTH. --Redrose64 🌹 (talk) 12:45, 28 September 2024 (UTC)

Interesting! I had always assumed that <span class="foo"><span class="bar"> was equivalent to <span class="foo bar"> — Martin (MSGJ · talk) 18:33, 28 September 2024 (UTC)

Sometimes, but not always. Consider the rule added in this edit. It will be applied to

<!-- HTML example 4 --><span class=wpb><span class=assess>HTML example 4</span></span>

which emits "HTML example 4", but not to

<!-- HTML example 5 --><span class="wpb assess">HTML example 5</span>

which emits "HTML example 5", or to

<!-- HTML example 6 --><span class=assess><span class=wpb>HTML example 6</span></span>

which emits "HTML example 6". This is because the space in the middle of .wpb .assess is a descendant combinator: in HTML example 4 we have one span that is the descendant of the other, but in HTML example 5 we have only one span, that is of class assess but is not the descendant of any element of class wpb. --Redrose64 🌹 (talk) 20:12, 28 September 2024 (UTC)

Modifying the module so default values aren't needed to be set

The advantage of invoking the module directly from banner templates is that we don't need to add default values for many of the parameters, so code like |category = {{{category|}}} isn't needed as the module knows it received a parameter with that name. Removing the need to add default parameters like this will make the long and complex banner code easier (and cleaner) to read.

Currently we have 4 types of parameters (if I'm not mistaken):

1. Parameters that all banners have and use the same parameter name.
2. Parameters that all banners have but use various names.
3. Parameters that some banners have but use the same name.
4. Parameters that some banners have but use various names.

The change needed would be like this:

• Group 1 is the ideal and easiest candidate to convert. Parameters in this group probably include |category= and |listas=.
• Group 3 is also easy to convert. Instead of doing something like |class = {{{class|}}}, we can change to |class = yes. Parameters in this group probably include |class= and |importance=.
  • In some cases where the parameter is almost always used, the default can be yes anyways so only when it isn't needed, the banner should set |class = no, reducing the banner code even more.
• For group 2 and 4, this change will make things more consistent across all banners so instead of something like |image-needed = {{{image|{{{image-needed|{{{needs-image|}}}}}}}}} it will be |image-needed = yes with only one of these names (or we could still leave all versions, messy but works).

Gonnym (talk) 11:13, 3 September 2024 (UTC)

Nice ideas. Just a few comments at this stage.

• These templates follow a long-standing convention of using upper-case parameter names for configuration settings and lower-case parameter names for passing values. So perhaps |CLASS=yes would be more respectful of that convention, if we wish to retain it.
• I would prefer to default to "no" in almost every case. There are already plenty of cases of editors using features that they don't actually need.
• I can't think of any examples of group 2?
• I suppose the module could check for all reasonable variants of parameter names, e.g. image, imageneeded, image-needed, etc. Or are you suggesting a harmonisation effort?
• For group 4, we could do something like |TF_1=utah which would tell the module to check the |utah= parameter and link it to task force 1.
• Currently the module does not look at any of the parent frame arguments (i.e. parameters passed from a page), it only looks at the frame arguments (i.e. parameters passed from the template), so this would need a fairly major restructure of the code

— Martin (MSGJ · talk) 11:25, 3 September 2024 (UTC)

• #1: That can work and would also make the conversion smoother as both parameters can work until all banners are converted.
• #2: A blanket no would be counter-productive here. class is used in almost all banners but a few. Having this line added to all of them instead of only the handful that don't need it is less ideal.
• #3: Probably one word parameters, so something like |attention=.
• #4: I'd prefer we harmonize on one name, yes. But that's my personal preference here. Having the module know all versions can work, but will be ugly and messy.

Gonnym (talk) 11:34, 3 September 2024 (UTC)

Ha, your edit to the sandbox will definitely not work without significant other changes! For example it would allow you to use features that the project does not even use. Let's start on a small scale with group 1.

• listas - I would prefer to move all these to the banner shell and then delete from the banners. So let's work on tracking these instead?
• substcheck - I have a feeling there is now a much better way to detect if a template has been substituted. So maybe look into that, and hopefully we can do without this parameter altogether.
• category - this would be a good one to start with, and would prove the concept.
• demo_page - this is undocumented, but very useful when testing to see how banners behave on different pages. It would be useful if we could use this parameter directly without having to pass through the template.

— Martin (MSGJ · talk) 19:22, 3 September 2024 (UTC)

The edit was just to see if the basic thing breaks (which it didn't so that's good news). If a project banner doesn't support a parameter (as in, the parameter isn't one of the default parameters, or isn't set to "on") then using it from a talk page shouldn't do anything other than place that parameter in the unknown parameter category. Gonnym (talk) 23:01, 3 September 2024 (UTC)

If we start using |CLASS=yes then it might be a good time to stop using |class= altogether, because all of the ratings should now be in the banner shell so this parameter is not needed. The only barrier to this is Category:Articles with conflicting quality ratings which is a massive barrier, and we have made almost no progress in resolving ... — Martin (MSGJ · talk) 07:42, 4 September 2024 (UTC)

Could you in the code sort the pages by the conflicting class? That would probably make it easier to see what issues can be solved with a bot run. Gonnym (talk) 08:34, 4 September 2024 (UTC)

Could sort by class, or alternatively the number of classes that it differs from the PIQA rating (e.g. if class=start and PIQA=B then difference=2). Or we could put use subcategories like Category:Articles with conflicting quality ratings that differ by 1 class, etc. — Martin (MSGJ · talk) 09:40, 4 September 2024 (UTC)

I'd prefer not a number as that doesn't give us any information to work with. A class can show us patterns. This Talk:1876 United States presidential election in Rhode Island, for example, is not a list. If we can single these out then we can start clearing them. Gonnym (talk) 09:58, 5 September 2024 (UTC)

Okay that's fine. But sorting by class is problematic before start/stub and fa/fl start with the same letters. What sort keys would you like to use? — Martin (MSGJ · talk) 11:32, 5 September 2024 (UTC)

It doesn't matter to me, as long as they are different. I'm also quite sure we won't have more than a handful of articles with FA/FL issues, if at all. Maybe place stub as 0. Gonnym (talk) 11:40, 5 September 2024 (UTC)

With this edit we could split out the category into different classes? — Martin (MSGJ · talk) 16:23, 7 September 2024 (UTC)

The subcategories of Category:Articles with conflicting quality ratings have now populated — Martin (MSGJ · talk) 14:36, 12 September 2024 (UTC)

Looking at the 3k pages at Category:List-Class articles with conflicting quality ratings. I think we can safely have a bot run and remove the pages marked as list from all pages except those in the format of "x in y" (Talk:1962 in anime). There might be some false positives, but that isn't something that can't be fixed manually when someone sees it. All the others aren't lists, but low-quality articles.

The pages in Category:GA-Class articles with conflicting quality ratings seem to be Military History articles tagged as "A". So in this case (and probably also in all other categories) we can decide to go with the higher tagged page, as an editor intentionally decided that article was that level (it's not our job here to check if we agree or not, just to fix the conflict). The stub pages can be double checked if the article itself still has a stub template, if it doesn't, it's not a stub. Gonnym (talk) 16:28, 12 September 2024 (UTC)

I like these suggestions — Martin (MSGJ · talk) 17:34, 12 September 2024 (UTC)

The code for using parent arguments for category and demo_page is now coded on sandbox, if you'd like to check it — Martin (MSGJ · talk) 21:09, 5 September 2024 (UTC)

Tested the category=no at Draft talk:Template:Test banner and looks good. Gonnym (talk) 15:47, 6 September 2024 (UTC)

Category:Pages using WikiProject [insert project] with unknown parameters

In Special:WantedPages, a lot of the most wanted pages are empty categories for pages that use a WikiProject with unknown parameters. In fact, the most wanted page, with nearly 120,000 pages (most appear to be talk pages) linking to it, is the empty category "Category:Pages using WikiProject Lepidoptera with unknown parameters". Why is that? BombCraft8 ^{(talk) (contributions)} 00:26, 4 September 2024 (UTC)

Okay I know why this is happening. This module uses Module:Check for unknown parameters and we have to tell it a category to use if it finds any unknown parameters. The default category is Category:Pages using WikiProject PROJECT with unknown parameters where PROJECT is the name of the project. But not all these categories exist, so the module checks if it exists first, and if not it will use the generic Category:WikiProject templates with unknown parameters instead. The link to these categories occurs when it checks for existence. I can't change this behaviour at this module, but I will make a suggestion at Module talk:Check for unknown parameters to see if there is something that can be done there — Martin (MSGJ · talk) 14:12, 4 September 2024 (UTC)

Ok BombCraft8 ^{(talk) (contributions)} 01:19, 5 September 2024 (UTC)

A fix for this is now in the sandbox — Martin (MSGJ · talk) 09:07, 5 September 2024 (UTC)

Thanks BombCraft8 ^{(talk) (contributions)} 13:07, 5 September 2024 (UTC)

This is now deployed, so they should start clearing out of the wanted categories page soon — Martin (MSGJ · talk) 11:37, 7 September 2024 (UTC)

Ok, thanks BombCraft8 ^{(talk) (contributions)} 21:00, 7 September 2024 (UTC)

Moving listas to banner shell

I have coded some tracking categories to help us ensure that all listas values are moved into the banner shell template. I have created the following tracking categories:

1. Category:WikiProject banners with redundant listas value (11)
2. Category:WikiProject banners with listas value which needs moving to banner shell (106)
3. Category:WikiProject banners with conflicting listas value (0)

My plan to deal with these is:

1. Parameter removed by bot (User:Qwerfjkl has offered to use his bot)
2. Parameter moved by bot (I think User:Cewbot should already do this)
3. Human review needed. (These should already be tracked in Category:Pages with DEFAULTSORT conflicts and possibly cleared out by other editors working through this category.)

Any comments? — Martin (MSGJ · talk) 21:57, 5 September 2024 (UTC)

When completed and categories emptied, I think the code can be simplified to just have "Category:WikiProject banners with listas value which needs moving to banner shell", when listas is used. Gonnym (talk) 21:38, 6 September 2024 (UTC)

Absolutely. And after a while, we could just remove the parameter entirely and then they will turn up in the unknown parameter categories — Martin (MSGJ · talk) 11:22, 7 September 2024 (UTC)

Planning to remove Category:WikiProject banners with conflicting listas value because they will be picked up by Category:Pages with DEFAULTSORT conflicts — Martin (MSGJ · talk) 19:55, 22 September 2024 (UTC)

Martin, I don't understand this. Listas and defaultsort refer to the article page but the banner shell is on the talk page. Hawkeye7 (discuss) 00:29, 23 September 2024 (UTC)

You can sort any page, including talk pages. The banner sorts the page it's placed on. Gonnym (talk) 06:11, 23 September 2024 (UTC)

Category:WikiProject banners with listas value which needs moving to banner shell now just has some user pages in it. So we should be ready soon to remove the listas parameter entirely from this module. Then any remaining uses would be picked up by Category:WikiProject templates with unknown parameters Never mind, it is still populating — Martin (MSGJ · talk) 12:51, 25 September 2024 (UTC)

False positive demo

@MSGJ: I think your recent edits to this module might have caused it to treat real transclusions as demo. A box with the text

Categories:

• Articles with WikiProject banners but without a banner shell

is showing up underneath WikiProject banners on talk pages, e.g. WT:NFC. (This includes banners that are inside a banner shell, but tracking category issues aren't as urgent.)

jlwoodwa (talk) 06:11, 8 September 2024 (UTC)

Looks like a problem with the inactive banners. I'll check ... — Martin (MSGJ · talk) 07:15, 8 September 2024 (UTC)

Think I've fixed it — Martin (MSGJ · talk) 08:05, 8 September 2024 (UTC)

The inactive banners seem to be populating the quality categories now. For example see Talk:By the Way Tour. -- WOSlinker (talk) 10:28, 8 September 2024 (UTC)

Arghh noted. Fix in sandbox — Martin (MSGJ · talk) 12:47, 8 September 2024 (UTC)

Inactive banners are now missing categorization completely. Talk:Sudbury school should be in at least Category:Articles with WikiProject banners but without a banner shell. Gonnym (talk) 22:36, 9 September 2024 (UTC)

Actually I'm not sure that category ever worked on inactive banners. It probably should, but turning categorisation on selectively is going to be a pain — Martin (MSGJ · talk) 08:07, 10 September 2024 (UTC)

It did work, as that page was (currently still is) in the category (that's how I found it). Gonnym (talk) 08:28, 10 September 2024 (UTC)

I can't explain this. Will have to dig deeper into the code. The problem arises because of a compromise to display the quality assessments on these banners but without the categories. It would be much simpler if we could remove all the assessments from inactive banners, but some people found them useful. Perhaps this is less of an issue now with PIQA. — Martin (MSGJ · talk) 09:54, 10 September 2024 (UTC)

I reverted to the 5th September version of the code in the sandbox and Talk:Sudbury school is still not in that category. So I don't understand why you found it in that category, unless it was from a much older version of the code. I agree it would be better if it was in that category, but the way the code is currently set up is either no categories work or all of them work. The category opt-out mechanism would get rather messy otherwise. So this is my proposal: we stop displaying the class on inactive banners. Then I won't need to suppress the categories on inactive banners, and these tracking caegories should then work properly — Martin (MSGJ · talk) 21:41, 17 September 2024 (UTC)

Fix is on the sandbox — Martin (MSGJ · talk) 14:00, 20 September 2024 (UTC)

 Fixed. I have tested this as much as I can, and it seems to work now — Martin (MSGJ · talk) 09:17, 23 September 2024 (UTC)

living/blp on categories

Is Template talk:WikiProject banner shell/Archive 11#living/blp on categories not valid anymore? I see categories have started filtering into Biography articles without living parameter when living/blp parameters are not present. Do we really want/need to add living/blp to the ~500k cats under Category-Class biography articles?   ~ Tom.Reding (talk ⋅dgaf)  18:05, 9 September 2024 (UTC)

Seems a bit pointless to add that parameter to a category. Gonnym (talk) 19:17, 9 September 2024 (UTC)

And templates. The maintenance burden will be massive.   ~ Tom.Reding (talk ⋅dgaf)  19:24, 9 September 2024 (UTC)

Should we also exclude disambiguation pages and redirects? — Martin (MSGJ · talk) 22:37, 10 September 2024 (UTC)

No, I don't think mainspace dabs & #Rs should be excluded. If they were excluded, then they could slip through to an easy circumvention of WP:NOINDEX.

Now that you mention it...ideally, it'd be nice from a maintenance perspective if dabs & #Rs inherited their target's status, if it exists (for cases where both the dab/#R and its target are tagged with {{WP Bio}}).   ~ Tom.Reding (talk ⋅dgaf)  08:07, 11 September 2024 (UTC)

You mean that if an article is a GA, then the dab page should be set to GA? Gonnym (talk) 08:48, 11 September 2024 (UTC)

Gonnym, we're talking about the |blp= or |living= parameters here. I'm not sure inheriting the status of the target would be appropriate. For example Matt Doherty Jr. redirects to the article on his father Matt Doherty Sr.. The former is alive but the latter is not — Martin (MSGJ · talk) 08:50, 11 September 2024 (UTC)

Inheritance could be the weak default, as long as |blp=/|living= are blank, but perhaps able to be forced with |blp=inherit/|living=inherit. Values of yes|no etc. would override any inheritance.   ~ Tom.Reding (talk ⋅dgaf)  09:15, 11 September 2024 (UTC)

I can't understand why you would want to use the living parameter on a disambiguation page. In almost every case there will be some people living and some not. There is also no content on a dab page, so little cause for BLP concerns — Martin (MSGJ · talk) 07:59, 19 September 2024 (UTC)

I may be straying out of my depth, but any dab with a living main/1st target could/should conceivably use |blp=yes, for example Talk:Joey Lawrence (disambiguation), Talk:Sai Kumar, etc. I'm surprised Talk:Madonna (disambiguation) doesn't even use {{WP Bio}}, but so be it.   ~ Tom.Reding (talk ⋅dgaf)  13:12, 19 September 2024 (UTC)

This was an unintended consequence of a new module to check parameters Module:Check blp parameter. It should be fixed now — Martin (MSGJ · talk) 19:43, 9 September 2024 (UTC)

If a page has |blpo=yes then presumably it should not be in Category:Biography articles without living parameter, correct? — Martin (MSGJ · talk) 08:55, 11 September 2024 (UTC)

The wording of Template:WikiProject Biography#Living people, active politicians and other BLP issues under |blpo= says "It can only be used if |living=no", so I don't think |blpo=yes on its own is enough to exclude it from Category:Biography articles without living parameter. I don't know if that dual requirement is a requirement of the previous template coding/logic, or if it was intended to be that way regardless. It does seem redundant to supply |living= for either |living=no|blpo=yes or |living=yes|activepol=yes, but I've never asked nor looked through WT:Biography/{{WP Bio}} about this.   ~ Tom.Reding (talk ⋅dgaf)  10:03, 11 September 2024 (UTC)

Can anyone help wit Category:Pages using WikiProject Biography with conflicting living parameter? I took the weekend off, and now it's got 260 pages in it — Martin (MSGJ · talk) 07:38, 16 September 2024 (UTC)

I've fixed a few but I noticed that a bot can easily fix most if not all of these and just needs to check if a page is in that category and also in Category:Living people. Gonnym (talk) 09:12, 16 September 2024 (UTC)

DOC=auto and inactive banners

|DOC=auto does not work with inactive banners (see Template:WikiProject University of Florida). Gonnym (talk) 10:23, 11 September 2024 (UTC)

That is true. Would you care you write some documentation for inactive banners that we can use? It would not be very long because most features are disabled. Perhaps some information about inactive projects and how to revive? — Martin (MSGJ · talk) 16:39, 11 September 2024 (UTC)

Yeah I'll muse over this weekend. But at the very least, the categorization should still happen for the template. An inactive banner is not placed in the project's category. Gonnym (talk) 16:43, 11 September 2024 (UTC)

See also {{WikiProject Reenactment}}. Same problem, I think. It needs documentation and a category. – Jonesey95 (talk) 14:55, 14 September 2024 (UTC)

Yes I know this needs sorting. Just need some time to look at it ... — Martin (MSGJ · talk) 08:18, 15 September 2024 (UTC)

The categorisation is now fixed (I hope!). If someone can write some documentation for inactive banners, this can be added to /templatepage — Martin (MSGJ · talk) 09:15, 23 September 2024 (UTC)

Override importance to NA on non-articles

There is a suggestion (link) that importance ratings e.g. |importance=mid should be ignored on non-articles, like redirects. At the moment the module will automatically apply NA-importance to these pages if no importance is specified, but it will not override a specified importance. What do people think? — Martin (MSGJ · talk) 07:33, 16 September 2024 (UTC)

The suggestion makes sense, and overridden pages can be filtered into Category:Pages with conflicting importance ratings. As long as any WikiProjects that wish to use their own importance scheme can use a custom importance mask, I don't see a problem. I would just be careful about not emptying that category too quickly, to give WikiProjects that do importance-rate #Rs, cats, templates, etc., time to make their own masks.   ~ Tom.Reding (talk ⋅dgaf)  11:26, 16 September 2024 (UTC)

If the rating is ignored, then it doesn't create a conflict. For example if you type |class=C on a redirect, then that will be ignored and it will still be classified as a redirect, and it does not trigger the conflicting ratings category. Should that be the same for ignored importance ratings? — Martin (MSGJ · talk) 11:50, 16 September 2024 (UTC)

If any and all WikiProjects that currently use importance on non-articles (idk what that # is) have their importance masks in place, then sure, importance ratings can be ignored.   ~ Tom.Reding (talk ⋅dgaf)  12:38, 16 September 2024 (UTC)

Are there any projects that currently categorize their redirects by importance? Gonnym (talk) 12:37, 16 September 2024 (UTC)

None intentionally, as far as I am aware. The only ones I have encountered have been left over from a move or merge of a page. If we did this, it would affect all non-articles, i.e. disambiguation pages, templates, portals, etc. would all get NA-importance automatically. So we should consider projects like Template:WikiProject Templates, Template:WikiProject Portals, etc. which may be tracking the importance of these pages. If they are, then a custom importance mask can be used — Martin (MSGJ · talk) 13:49, 16 September 2024 (UTC)

What is a custom importance mask? · · · Peter Southwood ^(talk): 04:00, 30 September 2024 (UTC)

Yes, WikiProject Underwater diving classifies redirects with the potential to become full articles with the importance the full article would have, thereby giving anyone who might be considering converting to a full article some idea of whether it would be worth the effort. · · · Peter Southwood ^(talk): 04:47, 30 September 2024 (UTC)

If we are going to do this, then we need the check all possible projects which are tracking non-articles by importance. If there are any, then they need to be switched to a custom importance mask. I will add candidates to check to the table below — Martin (MSGJ · talk) 08:05, 19 September 2024 (UTC)

Project	Notes
WikiProject Flag Template	Does not have any categories
WikiProject Templates	Does not have any categories
WikiProject Inline Templates	Category:WikiProject Inline Templates pages does not use sub-categories
WikiProject template sharing	Dead project
WikiProject Disambiguation	Category:WikiProject Disambiguation pages does not use sub-categories
WikiProject Redirect	Category:WikiProject Redirect pages does not use importance sub-categories
WikiProject English Numeral Royalty Redirect	Dead project
WikiProject Portals	Category:Portal pages by importance. Uses custom code, should not be affected.
WikiProject Categories	Category:WikiProject Categories pages does not use its own importance sub-categories
WikiProject Category sorting	Defunct
WikiProject Wikipedia essays	Category:Wikipedia essays articles by importance. Already using custom mask.
WikiProject Policy and Guidelines	Defunct
WikiProject Images and Media	Category:WikiProject Images and Media does not use importance sub-categories
WikiProject User Help	Defunct
WikiProject Abandoned Drafts	Category:WikiProject Abandoned Drafts does not use importance sub-categories
WikiProject Manual of Style	Defunct
Help Project	Category:Help articles by importance has sub categories

Okay so we can do this - will look at coding it next week. It will be an opportunity to move away from using {{importance mask}} and use a Lua version instead — Martin (MSGJ · talk) 13:59, 20 September 2024 (UTC)

Proposed code in sandbox — Martin (MSGJ · talk) 14:34, 24 September 2024 (UTC)

Just to confirm. The new version will force NA importance on any non-article, but it will still permit NA to be used on an article. Is this correct? Would it be better to prohibit NA in article space, in which case NA would resolve to Unknown? — Martin (MSGJ · talk) 12:24, 25 September 2024 (UTC)

NA on an article sounds strange. I'd like to see an actual usage where one would set this. It would seem that if an article is NA then it's pretty much not notable for inclusion in Wikipedia (or that the project shouldn't have tagged it). Regarding the other namespaces, any project that wants to give importance to non-articles should have a custom mask? Gonnym (talk) 09:09, 26 September 2024 (UTC)

I tend to agree. NA on an article would not make much sense, and if any project wanted to do that, they should set up a custom mask. — Martin (MSGJ · talk) 09:28, 26 September 2024 (UTC)

NA importance (break)

Pages like List of storms named Ningning which is a set index article, are often assessed with NA-importance. These will become unknown importance if we change this. Is that a problem? — Martin (MSGJ · talk) 21:53, 26 September 2024 (UTC)

Set index pages should probably be treated like disambiguation pages, unless some projects are actually setting different importance to them. Gonnym (talk) 22:39, 26 September 2024 (UTC)

Couldn't agree more. I have long argued that set index articles should be classified as disambiguation pages, because that is what 99% of them are. There may be a few real SIAs with actual content, but most are just a collection of links. The easiest way to do this, is make an edit like this, which would convert all the list articles on surnames into disambiguation pages in one swoop. But as you can see I was reverted back in 2023, and many kB of discussion ensued which did not reach a satisfactory conclusion — Martin (MSGJ · talk) 10:42, 27 September 2024 (UTC)

Another option is to have a list like Module:Disambiguation/templates for Category:Set index article templates so the module can detect them. Gonnym (talk) 10:54, 27 September 2024 (UTC)

We already have that list and can detect them. But the problem is that set index articles are supposed to be articles and shouldn't be getting NA importance — Martin (MSGJ · talk) 11:05, 27 September 2024 (UTC)

Well in that case, an article shouldn't get NA importance and should get categorized as unknown (though again, I personally think they should be detected as set index and set to NA). Gonnym (talk) 11:27, 27 September 2024 (UTC)

If we make this change I anticipate some queries/complaints along the lines of "why can't I set NA importance for this set index article?" I think we are taking the reasonable and appropriate action, but the mis-classification of SIAs continues to cause problems ... To reduce confusion, let's keep the possibility of assessing articles with NA-importance for now. If the SIA/disambig issue is ever sorted properly, we can revisit this — Martin (MSGJ · talk) 14:04, 27 September 2024 (UTC)

 Done — Martin (MSGJ · talk) 21:57, 28 September 2024 (UTC)

Hang on a bit here. WikiProject Underwater diving uses importance on redirects to indicate which could/should reasonably be converted to full articles some day, and how important the topic is to the project. Are you classifying redirects as non-articles? How will we visibly indicate which redirects are potentially articles and which are not? · · · Peter Southwood ^(talk): 03:45, 30 September 2024 (UTC)

Yes, all redirects are classified as non-articles. We can set up a custom importance mask for your project, and you can continue to assess importance in any way you wish — Martin (MSGJ · talk) 07:56, 30 September 2024 (UTC)

That seems an entirely reasonable option, thanks for your response. My template coding skills are rudimentary, so I may have to come bck with some questions about how it works if I don't manage to get it to do what is needed. Cheers · · · Peter Southwood ^(talk): 14:54, 30 September 2024 (UTC)

It's already done. So you won't need to edit it, unless you want to make any other changes — Martin (MSGJ · talk) 15:12, 30 September 2024 (UTC)

Yes, thanks, I understand, and don't expect any problems or need for changes, but you never know... · · · Peter Southwood ^(talk): 15:29, 30 September 2024 (UTC)

 Done at Template:WikiProject Underwater diving/importance. This should now be handling importance the same way it was before — Martin (MSGJ · talk) 08:02, 30 September 2024 (UTC)

It looks like the change has caused some issues with WP:RATER, in that it is now impossible for the script to assign values to importance other than NA to all articles, not just set index and redirects (see talk page discussion there). Reconrabbit 17:38, 30 September 2024 (UTC)

Articles should not be given NA. If it's NA for your project, then your project shouldn't tag that page. Gonnym (talk) 17:43, 30 September 2024 (UTC)

That's not what they are saying. They are saying that Rater will only allow them to rate NA. I can confirm that I am seeing this too, but need to look into why this might be — Martin (MSGJ · talk) 20:28, 30 September 2024 (UTC)

The change to this module does seem to have mucked up rater. I have no idea why, because the module is working just fine. But perhaps we should consider a partial revert to allow time for @Evad37 to look into this and apply a fix — Martin (MSGJ · talk) 10:17, 1 October 2024 (UTC)

That seems a prudent response, Rater is quite heavily used and there in no great urgency for this change, Cheers, · · · Peter Southwood ^(talk): 12:28, 1 October 2024 (UTC)

I have reverted the change to the importance mask (although I still can't think of any way this could have an impact). Please let me know if you notice an improvement to rater? — Martin (MSGJ · talk) 17:38, 1 October 2024 (UTC)

It allows an importance to be allocated to a redirect for Wikiproject underwater diving, so OK on that count. · · · Peter Southwood ^(talk): 05:29, 2 October 2024 (UTC)

I'm just going to toss in a general comment that supports allowing projects to tag the importance of Drafts and Redirects. In the former situation, I will find drafts from the New Article reports and tag them appropriately with all of the desired details. Then when someone reviews it, that editor only has to assign a quality rating. I find that well-meaning people don't always know what importance to assign when they aren't active members of a project, and I'll have to go tweak the rating later. Also, the importance rating can serve as an indicator of which drafts should get attention to push them across the finish line as articles.

As for redirects, it's similar. Some redirects have possibilities for expansion into future articles, and if we can rate them by importance now, it gives some indication on which should be prioritized over others. Not every project may see the utility in this, but some will. Removing this possibility across the board disallows projects to use this potential tool. Imzadi 1979 → 18:27, 2 October 2024 (UTC)

I agree on both counts, but this tends to be different for different projects. Some do not allocate an importance at all, others find it a useful tool. I would suggest that only non-articles that have the potential to become articles can usefully be allocated an importance, and all others should probably be rated as NA, while all actual articles should have a non-NA rating if the project allocates importance. If the project does not allocate importance, then no importance should be the only and automatic rating, and no options are needed. · · · Peter Southwood ^(talk): 04:08, 3 October 2024 (UTC)

Importance for drafts and redirects (and userspace drafts?) sounds reasonable for the reasons stated. I guess it depends on how many projects are actually doing this. If it's common, then we should support this as standard. It it's niche, then those projects can easily use a custom mask — Martin (MSGJ · talk) 17:29, 3 October 2024 (UTC)

We now have the green light to reimplement this change. So we need to decide whether to allow importance ratings for certain non-articles, e.g. redirects and drafts, or treat all non-articles as NA. Does anyone else have any opinions on this, or should we try WT:COUNCIL? — Martin (MSGJ · talk) 22:58, 5 October 2024 (UTC)

NA importance (break 2)

Just to make sure that everyone is board with this change, the table below clarifies the proposed output in different scenarios, as I understand it — Martin (MSGJ · talk) 09:33, 6 October 2024 (UTC)

looks ok to me. · · · Peter Southwood ^(talk): 13:01, 6 October 2024 (UTC)

This is now coded on the sandbox — Martin (MSGJ · talk) 12:01, 7 October 2024 (UTC)

 Done. Diving should now be able to go back to the standard importance mask (unless there is anything else non-standard that you want to do) — Martin (MSGJ · talk) 20:31, 7 October 2024 (UTC)

Does that require any action from us? · · · Peter Southwood ^(talk): 05:39, 9 October 2024 (UTC)

Page type	Valid input, e.g. "mid"	Invalid/blank input	Input "na"
Articles	Mid	Unknown	NA
Redirects & drafts	Mid	NA	NA
All other pages	NA	NA	NA

Notes

Template:WAP

Not sure about Template:WAP since the project isn't on this wiki, but if this should be kept, it should probably be converted to use this module (and renamed). Gonnym (talk) 19:38, 1 October 2024 (UTC)

Perhaps soft-redirects off-wiki should be set up at the standard WPP locations -- 65.92.246.77 (talk) 22:46, 19 October 2024 (UTC)

Do you mean on-wiki? — Martin (MSGJ · talk) 13:32, 20 October 2024 (UTC)

Yes, otherwise, the module wouldn't find the correct pages. -- 65.92.246.77 (talk) 18:06, 20 October 2024 (UTC)

listas

Is there a way to set separate sort keys for different wikiprojects? I get the general sortkey from {{WPBS}}, but that doesn't always seem the best for each wikiproject contained within -- 65.92.246.77 (talk) 20:26, 2 October 2024 (UTC)

No, it just uses DEFAULTSORT which sets the sort key for all categories — Martin (MSGJ · talk) 20:48, 2 October 2024 (UTC)

The standard doc follows below. --Redrose64 🌹 (talk) 21:34, 2 October 2024 (UTC)

• listas – This parameter, which is the equivalent of the DEFAULTSORT sortkey that should be placed on all biographical articles, is a sortkey for the article talk page (e.g. for John Smith, use |listas=Smith, John so that the talk page will show up in the S's and not the J's of the various assessment and administrative categories). This is important because it is one source used by those who set DEFAULTSORT on the article; consider also setting the DEFAULTSORT for the article when setting this parameter. For more information about this, please see Wikipedia:Categorization of people § Ordering names in a category.
  If the article is using {{WikiProject banner shell}} then it is preferable to add |listas= to that template instead of a project banner template. Putting the parameter on more than one template is not required.

Is there a way to set a task force as inactive within this module?

See Template talk:WikiProject Cricket#edittemplateprotected, where an editor says The Wikipedia:WikiProject Cricket/Somerset cricket task force is inactive now. Should be marked as inactive in the banner as well. I did not see a way to do this in the documentation. – Jonesey95 (talk) 17:14, 3 October 2024 (UTC)

I have seen this done in a variety of ways, but not sure what the neatest method is — Martin (MSGJ · talk) 11:56, 4 October 2024 (UTC)

invert parenthesis on inactive WikiProject bubble

User:Matrix made this edit without any discussion whatsoever. Can you explain what this does, and can you ensure you discuss changes to widely used modules in future? — Martin (MSGJ · talk) 18:11, 9 October 2024 (UTC)

@MSGJ: wait I thought I did that in the sandbox module... sorry for being stupid. It was supposed to invert the parenthesis on the text "(inactive)" in the banner for inactive wikiprojects. —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 18:13, 9 October 2024 (UTC)

I don't think it works. —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 18:13, 9 October 2024 (UTC)

You want Module:WikiProject banner/sandbox/styles.css then. We don't play around on a module with 11 million transclusions! — Martin (MSGJ · talk) 18:26, 9 October 2024 (UTC)

@MSGJ: calm down mate it was an honest error :/ —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 18:41, 9 October 2024 (UTC)

@MSGJ: All right, I got it working now and checked with testcases, everything looks fine to you? —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 19:03, 9 October 2024 (UTC)

Please explain what "invert parenthesis" means? I cannot see any difference on the testcases — Martin (MSGJ · talk) 12:03, 10 October 2024 (UTC)

I'm curious as well. I created {{WikiProject Occupations/sandbox}}, since that was the first inactive WP that came to mind.   ~ Tom.Reding (talk ⋅dgaf)  13:37, 10 October 2024 (UTC)

@MSGJ and Tom.Reding: you can't see any difference between the sandbox and live versions because the templatestyles on the sandbox version also applies to the live version on that page. At the bottom of the testcases you can see the parenthesis saying "(inactive)" is correctly coded as white, whilst on WT:Logos it's black during dark mode, because usually the WikiProject bubble is not inverted in dark mode. However in this case it should be black. —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 16:34, 10 October 2024 (UTC)

I see no difference between the testcase & Wikipedia talk:Logos. Which skin(s) does your change affect?   ~ Tom.Reding (talk ⋅dgaf)  17:27, 10 October 2024 (UTC)

@Tom.Reding: Are you using Vector 2022 dark mode as was specified earlier? —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 18:18, 10 October 2024 (UTC)

@Matrix: I'm using Vector 2010, but I opened those pages in Vector 2022 and still see no change between any of those banners in both light and dark modes.   ~ Tom.Reding (talk ⋅dgaf)  17:34, 11 October 2024 (UTC)

@Tom.Reding: I created an Imgur for you. Look carefully at the parenthesis saying "inactive". First is WT:Logos, second is testcases. —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 17:39, 11 October 2024 (UTC)

I'm using Vector 2022 and I went to dark mode but what I'm seeing does not match the image on that link. On mine the brackets are white (just like your second image) and it looks fine — Martin (MSGJ · talk) 07:47, 12 October 2024 (UTC)

@MSGJ: Any objections to implementing this edit? —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 19:11, 11 October 2024 (UTC)

implementing now —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 16:00, 16 October 2024 (UTC)

You still haven't explained what this does. We can't see any difference on the test cases — Martin (MSGJ · talk) 16:47, 16 October 2024 (UTC)

I see you went ahead with this change, despite unanswered questions from myself and Tom.Reding on this talk page — Martin (MSGJ · talk) 17:12, 17 October 2024 (UTC)

Importance assessment

Would it be possible to make a way to suppress the importance assessment of List-class articles to Low-importance irregardless of the parameter. Vestrian24Bio (TALK) 16:25, 25 October 2024 (UTC)

For info, this would implement the standard stated at WP:CRICIS, as also discussed at CFD Oct 20. – Fayenatic London 14:17, 27 October 2024 (UTC)

Yes, in principle you can do this via Template:WikiProject Cricket/importance but you would need to write your own code, because no other project does anything like this. Do you mean whenever |class=list you will automatically assign low importance, and it would be impossible to override that? — Martin (MSGJ · talk) 21:40, 27 October 2024 (UTC)

Yes, that's the desired outcome. I think the intended question was whether the meta template includes any features to facilitate this, and you have given us the answer to that: No. At least that's clear now, thanks. – Fayenatic London 21:05, 28 October 2024 (UTC)

What we can arrange is for the normalised class value to be passed to the importance mask, then it will be simple enough to write the code to produce the desired result — Martin (MSGJ · talk) 21:12, 28 October 2024 (UTC)

Should be working on Template:WikiProject Cricket/sandbox, if you'd like to test it. A small change to the meta module will be needed, then we can deploy to your live template — Martin (MSGJ · talk) 21:21, 28 October 2024 (UTC)