Module talk:WikiProject banner
| If you wish to discuss the behaviour of the project banner inside the banner shell, then you may wish to post at Template talk:WikiProject banner shell instead. |
| This module does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||
| ||||||||
|
Assessment issue with "inactive" WikiProjects
[edit]| → Module talk:WikiProject banner/Archive 15#PROJECT_STATUS parameter |
If I understand this correctly, when you set a project as "inactive" (by replacing main in the template), most of the the arguments from child templates are discarded (around line 900). This means that if you mark a WikiProject as inactive, then it and all of its task-forces will lose their assessments, as the assessment categories are ignored and not applied.
I know that having a load of seemingly useless categories around isn't great, but the problem is that it's a bit of a death sentence for further collaboration if they disappear; mark a template as inactive and the project page ends up looking like this (lots of empty/broken templates due to unpopulated/deleted categories). If someone wants to revive a WikiProject then they'd likely have to go through the process of recreating the assessment system, assuming they made it that far.
Ideally, I think it'd be good to have two levels: Inactive where assessments are kept, and Defunct where the categories aren't added. Pretty sure that'd be a huge change though. In the meantime, or as a fix entirely, could a check be added so that existing categories are populated so they don't get deleted?
This is quite relevant due to a recent discussion at the WikiProject Council where they discuss labeling a load of WikiProjects as inactive using {{WikiProject status}}; this itself won't effect the assessments, but if anyone sees it then changes the status on the talk page banner, bad times. One of the comments on that thread from Psychastes says, Inactive projects still retain all the assessments and article alerts, it's not like an inactive project goes away!
If that's not actually the case, it needs to be made clear with a big ol' warning in the docs.
...again, assuming I've got this right. Cheers, Aluxosm (talk) 06:56, 9 July 2025 (UTC)
- You have understood the situation pretty well. There is a
|PROJECT_STATUS=parameter, which accepts values like "inactive" and "defunct", but currently the only effect is a slight change in wording and a microformat. Yes it would be possible to change in the way you suggested, if there was consensus for this. The current situation rests on rough consensus from 2022; please see Wikipedia:Village pump (miscellaneous)/Archive 73#Improper handling of assessment for inactive WikiProjects for more — Martin (MSGJ · talk) 08:26, 9 July 2025 (UTC)- Good stuff, cheers for the link! Fun to see the origins of WP:PIQA, and thanks again for all of your work on it. Thinking about it, a more resilient fix (and one that is beneficial in all cases) would be to make the creation of the assessment categories easier; I might take a look at rewriting this bot, as well as fixing the templates so that they display a warning about running the bot instead of just erroring out. Aluxosm (talk) 03:43, 13 July 2025 (UTC)
- For reference, there are only 54 templates using the
|PROJECT_STATUS=parameter, and all of them havedefunctas the value. Aluxosm (talk) 05:03, 24 October 2025 (UTC)- Do you still want to change
|PROJECT_STATUS=inactiveto mean that assessments are kept? What about other features of the banner? What should the wording be? — Martin (MSGJ · talk) 13:41, 24 October 2025 (UTC)- I think so, in order to bring it more in line (or ideally somehow in sync) with {{WikiProject status}}. Before that though, it would be good to at least go through the templates in this list and add
|PROJECT_STATUS=defunctto the properly defunct ones (see my comments at the end of this thread first), as well as work out a way to make the assessment category creation easier, otherwise Special:WantedCategories will be flooded with entries and the people who frequent it will be quickly overwhelmed. I plan on making my way through the unprotected templates first (hence my question about the #QUALITY_SCALE param) before potentially heading over to WP:RFP/TE. - Note to self: Wikipedia:Inactive WikiProjects needs updating/deleting. Aluxosm (talk) 15:26, 24 October 2025 (UTC)
- If it helps consensus-wise, I concur with not messing with assessments for inactive projects. Reactivating an inactive project (as opposed to a defunct one) shouldn't be made to be difficult. Stefen 𝕋ower's got the power!!1! Gab • Gruntwerk 18:59, 24 October 2025 (UTC)
- I would also support not messing with any inactive project's assessments. sjones23 (talk - contributions) 06:54, 25 October 2025 (UTC)
- I think so, in order to bring it more in line (or ideally somehow in sync) with {{WikiProject status}}. Before that though, it would be good to at least go through the templates in this list and add
- Do you still want to change
More populated category redirects
[edit]Category:NA-importance articles and Category:Unassessed List pages are being populated when they shouldn't be. Please can someone make the necessary code adjustments. Timrollpickering (talk) 21:10, 4 September 2025 (UTC)
- The first one looks empty to me, except for an empty subcategory. For the second one, it seems that Template:WikiProject Lists/class is not detecting those two redirects, which is strange, because it does all of Category:Redirect-Class List pages (11,960) — Martin (MSGJ · talk) 21:35, 4 September 2025 (UTC)
- Seems to be caused by slightly different methods of detecting redirects, which needs further investigation. In both cases the pages contained the word "#REDIRECT" but it was inside the RfD template which deactivates it. I have solved the issue for these two by closing to relevant RfD discussions — Martin (MSGJ · talk) 07:08, 5 September 2025 (UTC)
Deprecating the class parameter
[edit]The number of conflicts between project class and PIQA is rapidly approaching zero, thanks to Hawkeye7 and his bot. When these have been cleared, I would like to deactivate the class parameter for all banners except for projects which have opted out. In other words, setting |class= in these banners would have no effect, and it will be impossible to set a class locally and also impossible to create any more conflicted ratings. — Martin (MSGJ · talk) 22:19, 3 October 2025 (UTC)
- Do we want that? I thought PIQA came with a promise that groups would always be able to disagree with the overall rating and use their own.
- Side note: If we're going to make changes that are not strictly necessary, one of the things I'd like to see is
|importanceand|prioritybeing aliases/interchangeable, and for both the rating scripts and the text of the banner to prefer 'priority' over time (but not necessarily the categories, because what a mess that would be). Nobody loves having the subject of their article declared to be "unimportant". WhatamIdoing (talk) 23:34, 3 October 2025 (UTC)- Groups can disagree and use their own scale by setting the
|QUALITY_CRITERIA=customparameter in their talk page template. Martin's suggesting wedeactivate the class parameter for all banners except for projects which have opted out.
Reading through the the proposal, and searching for the word "own" in the comments, it seems like this tacks with the consensus. It does go against one of the statements in the proposal: • If the wikiproject banner supplies a class value that differs from the (non-blank) article class value, the talk page will be placed in a tracking category and the project class will be used to form categories like Category:C-Class Linguistics articles
- but that kinda goes against the whole idea of PIQA. Also the last statement in the proposal says:
• A future project may consider bulk change to remove class= values from wikiproject banners where the value is the same as the article level class, and where the wikiproject uses the general Wikipedia:Content assessment approach. That is outside the scope of this proposal.
- My vote is
Agree, I think the class parameter should be deprecated where a project hasn't opted out. - Side note: Would you mind moving your notes about the importance ratings to their own topic? I don't think I agree with them and would like to discuss them separately. Cheers, Aluxosm (talk) 01:58, 4 October 2025 (UTC)
- As long as we're not breaking any promises, then I think it'd be great. WhatamIdoing (talk) 03:50, 4 October 2025 (UTC)
- Comment moved to new section below. — Martin (MSGJ · talk) 10:45, 4 October 2025 (UTC)
- Groups can disagree and use their own scale by setting the
@MSGJ: I assume this edit is part of testing implementing what was discussed in this thread. It's causing errors when testing with {{WikiProject Military history/sandbox}} (category at Line 412 is undefined), specifically when there's a Talk: demo_page specified and the template is being tested from outside article space (e.g. try previewing {{WikiProject Military history/sandbox|demo_page=Talk:World War II}} on a user page). Aidan9382 (talk) 15:52, 17 October 2025 (UTC)
- Thanks for letting me know. I have not started testing it yet so will definitely check that out — Martin (MSGJ · talk) 07:24, 18 October 2025 (UTC)
Code is now in the sandbox (testing still in progress). Changes include:
- Class parameter ignored in non-opt-out projects
- Class conflicts are not tracked or categorised (local class is simply ignored). Category:Articles with conflicting quality ratings can therefore be deleted.
- Category:WikiProject banners with class parameter that needs moving to banner shell is no longer populated. Adding a local class parameter will simply be ignored.
- Proposal to rename Category:WikiProject banners with redundant class parameter to Category:WikiProject banners with ignored class parameter as this will now also include conflicting values (so not strictly redundant). In future we could stop using this category and instead use the tracking of unknown parameters in Category:WikiProject templates with unknown parameters which will be processed in the usual way.
- Quality rating will never be displayed in project banner (only in banner shell).
Please check and make any comments — Martin (MSGJ · talk) 09:54, 18 October 2025 (UTC)
Done. Please let me know if you see anything unexpected. One thing I have noticed is that when a banner is added to a redirect page (example) it populates a NA-class category. When the banner shell is added (example), it then correctly populates the Redirect-class category. I will look at this in more detail — Martin (MSGJ · talk) 21:44, 19 October 2025 (UTC)
Importance and priority
[edit]If we're going to make changes that are not strictly necessary, one of the things I'd like to see is |importance and |priority being aliases/interchangeable, and for both the rating scripts and the text of the banner to prefer 'priority' over time (but not necessarily the categories, because what a mess that would be). Nobody loves having the subject of their article declared to be "unimportant". WhatamIdoing (talk) 23:34, 3 October 2025 (UTC)
- This is certainly technically possible. Also there are no projects which use both importance and priority, so I can't see any likely confusion or clashes that this could cause. Personally I agree that "priority" is a much better word than "importance" for this — Martin (MSGJ · talk) 10:49, 4 October 2025 (UTC)
- @Aluxosm: did you want to comment on this? — Martin (MSGJ · talk) 11:33, 7 October 2025 (UTC)
- While I do also prefer 'priority', I think that ship has sailed; WikiProject Mathematics seems to be the only one using this identifier (Quarry 97858). I know the suggestion here is to leave the categories alone, but I think that even adding it as an alias would end in confusion and make maintenance trickier; I'm not sure how transitioning to 'priority' as the primary variable, while having those articles end up in a category that doesn't have the word in the title really serves anyone. Sorry, especially if I've misunderstood. Aluxosm (talk) 05:44, 8 October 2025 (UTC)
- So we all seem to agree that the word "priority" is preferable over "importance". We can take baby steps in that direction, and who knows we might one day make a full transition. By template and bot, big categorisation changes are not impossible (see Wikipedia:Categories for discussion/Log/2024 December 7#Category:Category-Class articles for a good example.) — Martin (MSGJ · talk) 10:36, 18 October 2025 (UTC)
- Very good point! Okay, sold haha. Aluxosm (talk) 01:06, 20 October 2025 (UTC)
- So we all seem to agree that the word "priority" is preferable over "importance". We can take baby steps in that direction, and who knows we might one day make a full transition. By template and bot, big categorisation changes are not impossible (see Wikipedia:Categories for discussion/Log/2024 December 7#Category:Category-Class articles for a good example.) — Martin (MSGJ · talk) 10:36, 18 October 2025 (UTC)
- While I do also prefer 'priority', I think that ship has sailed; WikiProject Mathematics seems to be the only one using this identifier (Quarry 97858). I know the suggestion here is to leave the categories alone, but I think that even adding it as an alias would end in confusion and make maintenance trickier; I'm not sure how transitioning to 'priority' as the primary variable, while having those articles end up in a category that doesn't have the word in the title really serves anyone. Sorry, especially if I've misunderstood. Aluxosm (talk) 05:44, 8 October 2025 (UTC)
- Changes made to the sandbox:
- Change of wording from "importance" to "priority" in all cases, while retaining current category names for now
- Accept priority parameter in all banners that currently support importance
- Remove link to Wikipedia:Version 1.0 Editorial Team/Release Version Criteria. If a project does not have its own scale, then unlinked "priority scale" will be used
- — Martin (MSGJ · talk) 16:09, 21 October 2025 (UTC)
- On the wording part, I would suggest a wider community discussion before changing. WikiProjects have used the term 'importance' for a very long time, and one project I'm involved with uses both terms (importance in the template as usual, priority for articles being focused on to move to good/featured), meaning different things. Stefen 𝕋ower's got the power!!1! Gab • Gruntwerk 19:18, 24 October 2025 (UTC)
- To be fair, that is exactly what I said in 2015 (see previous discussion linked above) and here we are in 2025 still discussing the same thing. Whenever the topic comes up everyone seems to agree that "priority" is a better term than "importance", but the change has never been made. If you like I can start a discussion at WikiProject Council to make sure we have consensus. and we can certainly look at your project to make sure there will not be any confusion — Martin (MSGJ · talk) 08:38, 27 October 2025 (UTC)
- Per the results of that module talk and at any rate per process expectations, there should be a discussion at the WikiProject Council since this may be seen as ultimately affecting any WikiProject infrastructure and reports (not to mention the database) that refer to the term 'importance', which in order to avoid potential confusion would ultimately have to be changed to use 'priority'. I think we should prefer that WikiProjects are not surprised by a change but instead are in on it.
- As for terminology confusion within a project I'm involved with, we should not assume that I'm the only one who would raise that kind of concern. In the galaxy of WikiProjects, there could be others that use both terms.
- In adapting projects to use 'priority' internally, I submit that the effort would be largely straightforward but also tedious, with many WikiProjects (esp. those with little participation) slow to adapt, which could cause some confusion. (A lot of WikiProjects have yet to adapt away from the membership model to the new participation model, which I believe was also a consensus change.)
- Last, to get in the weeds a bit, that previous module talk refers to a guideline I have been unable to locate. But what I could find is a lot of Council guidelines that still use the term 'importance'. At any rate, I vaguely understand the reason for a change, although I honestly can't recall a complaint of a biography subject complaining they were being labeled as "low importance" by a non-Biography project. Stefen 𝕋ower's got the power!!1! Gab • Gruntwerk 16:32, 27 October 2025 (UTC)
- I think it refers to [1] which has since been updated — Martin (MSGJ · talk) 17:01, 27 October 2025 (UTC)
- That is probably why I can't find it in currently existing guidelines. :) Apparently someone wanted to trim and say "find this elsewhere". After some additional poking around, I realized we also have to contend with the Wikipedia:Version 1.0 Editorial Team and their current unquestioning inclusion of 'importance' in their deliverables.
- I certainly will accept a community decision, but I hope there is strong evidence of "a problem" that we're fixing. What you link to really just makes assertions toward that end, you know, that editors/readers may be upset with this word we've been using for quite a long time. Stefen 𝕋ower's got the power!!1! Gab • Gruntwerk 22:14, 27 October 2025 (UTC)
- Sounds fair. @WhatamIdoing: would you like to start the discussion at Council, as this was your proposal? — Martin (MSGJ · talk) 06:56, 28 October 2025 (UTC)
- I'd be happy to leave it to someone else. WhatamIdoing (talk) 03:50, 29 October 2025 (UTC)
- Sounds fair. @WhatamIdoing: would you like to start the discussion at Council, as this was your proposal? — Martin (MSGJ · talk) 06:56, 28 October 2025 (UTC)
- I think it refers to [1] which has since been updated — Martin (MSGJ · talk) 17:01, 27 October 2025 (UTC)
- To be fair, that is exactly what I said in 2015 (see previous discussion linked above) and here we are in 2025 still discussing the same thing. Whenever the topic comes up everyone seems to agree that "priority" is a better term than "importance", but the change has never been made. If you like I can start a discussion at WikiProject Council to make sure we have consensus. and we can certainly look at your project to make sure there will not be any confusion — Martin (MSGJ · talk) 08:38, 27 October 2025 (UTC)
- On the wording part, I would suggest a wider community discussion before changing. WikiProjects have used the term 'importance' for a very long time, and one project I'm involved with uses both terms (importance in the template as usual, priority for articles being focused on to move to good/featured), meaning different things. Stefen 𝕋ower's got the power!!1! Gab • Gruntwerk 19:18, 24 October 2025 (UTC)
I see we are still linking to Wikipedia:Version 1.0 Editorial Team/Release Version Criteria for the importance/priority scale when a project does not have their own. This is an obsolete page and it would be good to have a link to somewhere more appropriate. I will mention this on WT:COUNCIL in case anyone has ideas — Martin (MSGJ · talk) 12:00, 20 October 2025 (UTC)
Protected edit request on 5 October 2025
[edit]This edit request to Module:WikiProject banner/styles.css has been answered. Set the |answered= parameter to no to reactivate your request. |
Please replace the CSS at Module:WikiProject banner/styles.css with the text at this revision of my sandbox.
The diff is here.
This edit adds color:inherit to each CSS entry that declares a background-color: value, satisfying the requirements of the Linter described at mw:Help:Lint_errors/night-mode-unaware-background-color.
I have no way to test this code, since the template is a nest of modules and CSS files. If you know how to get the new code into a testing location, please do so. Looking at some complex instances of {{WikiProject banner shell}}, including the ones at {{WikiProject_banner_shell/testcases}}, in both light mode and dark mode, should tell you whether there are any major problems with the code.
If someone wants to get really fancy, they could propose some CSS variables for use in items like class-unassessed, which makes an incompatible background color at Template:WikiProject banner_shell/testcases#BLP in dark mode. That is beyond the scope of this request, however. – Jonesey95 (talk) 02:46, 5 October 2025 (UTC)
Not done: The template works fine in its current state, but by using inherit, dark mode users are unable to see the text that tells users the importance rating provided by the wikiproject. This isn't fixing anything and instead making the situation worse. Sohom (talk) 03:55, 5 October 2025 (UTC)
- The syntax errors remain. I hope that someone knows the right CSS to use to supply colors that work properly in dark mode. – Jonesey95 (talk) 18:17, 5 October 2025 (UTC)
- Which syntax errors? You didn't mention any in your first post. --Redrose64 🌹 (talk) 19:59, 5 October 2025 (UTC)
- I tried to, when I said "satisfying the requirements of the Linter described at mw:Help:Lint_errors/night-mode-unaware-background-color". For minimal dark mode compatibility, syntax requires that
color:be set in everystyle=declaration wherebackground:orbackground-color:is set. – Jonesey95 (talk) 21:07, 5 October 2025 (UTC)- I followed the link, but the word "syntax" doesn't occur there either. A syntax error would be using something like
style="color:inherit;',color; inherit:,colour: black;orcolor:skybluepinkwithyellowspots;--Redrose64 🌹 (talk) 21:36, 5 October 2025 (UTC)- I'm not sure what you are on about, or how that helps us fix this problem. It is an error to have a background color specified without a color specified. I also provided details about an incompatible background color in one of the test cases. Ideally, someone with knowledge of the CSS design tokens that are referenced on the page I linked to above will be able to fix these problems. – Jonesey95 (talk) 23:59, 5 October 2025 (UTC)
- Omitting a declaration for the foreground text colour might be an error of some sort, but it's not a syntax error. The syntax of CSS 2.1 is described here. --Redrose64 🌹 (talk) 20:40, 6 October 2025 (UTC)
- OK, thanks for your help. Returning to the original request: if someone has the technical skills to improve the module to comply with the above-linked requirement, I would greatly appreciate it. The module has more than 11 million transclusions, so you'll be improving a lot of pages. – Jonesey95 (talk) 22:48, 6 October 2025 (UTC)
- Omitting a declaration for the foreground text colour might be an error of some sort, but it's not a syntax error. The syntax of CSS 2.1 is described here. --Redrose64 🌹 (talk) 20:40, 6 October 2025 (UTC)
- I'm not sure what you are on about, or how that helps us fix this problem. It is an error to have a background color specified without a color specified. I also provided details about an incompatible background color in one of the test cases. Ideally, someone with knowledge of the CSS design tokens that are referenced on the page I linked to above will be able to fix these problems. – Jonesey95 (talk) 23:59, 5 October 2025 (UTC)
- I followed the link, but the word "syntax" doesn't occur there either. A syntax error would be using something like
- I tried to, when I said "satisfying the requirements of the Linter described at mw:Help:Lint_errors/night-mode-unaware-background-color". For minimal dark mode compatibility, syntax requires that
- Which syntax errors? You didn't mention any in your first post. --Redrose64 🌹 (talk) 19:59, 5 October 2025 (UTC)
- The syntax errors remain. I hope that someone knows the right CSS to use to supply colors that work properly in dark mode. – Jonesey95 (talk) 18:17, 5 October 2025 (UTC)
This category contains a number of pages in userspace. The bot apparently does not process pages in userspace, so should we filter out these pages or should we change the bot's settings?
It seems that no user pages are looked at except from a few select bots listed below.
I can't remember why these exceptions were coded — Martin (MSGJ · talk) 14:50, 20 October 2025 (UTC)
- The configuration page also specifies
PIQA_page_filteras/^User talk:(?:WP 1\.0 bot|AlexNewArtBot|InceptionBot|SDZeroBot|TedderBot|UBX)/. @Gonnym: can you give any background to this, why these users were specifically included, and why we cannot process all pages in this namespace? Thank you — Martin (MSGJ · talk) 16:31, 22 October 2025 (UTC)- As Gonnym did not reply, I have removed the PIQA_page_filter so that these pages will be dealt with. If there are unforeseen consequences then please revert — Martin (MSGJ · talk) 08:41, 27 October 2025 (UTC)
QUALITY_SCALE
[edit]| → Module talk:WikiProject banner/Archive 7#More on QUALITY_SCALE |
The |QUALITY_SCALE= parameter was seemingly removed in Special:Diff/1181725872. I just want to double check that this parameter can safely be removed when updating/working on templates that use this module (standard and custom)? There are currently 1,351 uses of this parameter, broken down like this:
Aluxosm (talk) 13:08, 24 October 2025 (UTC)
- Yes it is completely redundant now. (Can explain more if needed.) — Martin (MSGJ · talk) 13:39, 24 October 2025 (UTC)
- Module talk:WikiProject banner/Archive 14#Deprecation of QUALITY_SCALE parameter might help — Martin (MSGJ · talk) 13:48, 24 October 2025 (UTC)
- Ooh, missed that. Thanks! Aluxosm (talk) 15:27, 24 October 2025 (UTC)