Module talk:WikiProject banner/Archive 11

Archive 5

←

Archive 9

Archive 10

Archive 11

Archive 12

Archive 13

→

Archive 15

Adding PageAssessments parser function

The WMF Community Tech team just finished developing a small new extension called PageAssessments whose purpose is to store page assessment metadata in a database table and make that data available via an API. We would like to enable this functionality for English Wikipedia by adding the #assessment parser function into the {{WPBannerMeta}} template. This will not change anything about the output of the template and will be a completely invisible change to end users. All it will do is cause the 'project', 'class', and 'importance' parameters for each project assessment to be recorded in a database table for each page that includes this template (or subtemplates). This will improve the efficiency of pretty much any query or report that is WikiProject-related and make it easier to build WikiProject-related tools (like WikiProject X). The change would basically be adding something like {{#assessment:{{{PROJECT|}}}|{{{class|}}}|{{{importance|}}}}} to the template code. Are you guys OK with this change to the template? Do you have any questions or concerns about it? Ryan Kaldari (WMF) (talk) 00:15, 8 September 2016 (UTC)

@MSGJ, WOSlinker, Happy-melon, Harej, and Isarra: Pinging some folks who might be interested. Ryan Kaldari (WMF) (talk) 00:23, 8 September 2016 (UTC)

I strongly support this. Currently the reports bot maintains its index of WikiProjects and articles through a database table it generates anew every 24 hours. This process takes over an hour and is very inefficient because it has to do a complicated database query that accounts for all the different category names WikiProjects use. This new database table makes this process much more efficient. If you're a bot or gadget developer you will find this useful. And there are no changes to the interface in the process. Harej (talk) 02:49, 8 September 2016 (UTC)

I can't see any reason not to do this. Would you mind sandboxing the code so we can see exactly where this will be inserted? — Martin (MSGJ · talk) 08:06, 8 September 2016 (UTC)

Don't forget there's also some banner templates that don't use WPBannerMeta. A list is at Template:WPBannerMeta/Conversion. -- WOSlinker (talk) 12:43, 8 September 2016 (UTC)

Thanks for the tips. I will definitely sandbox the code first and let people take a look at it. I'm not sure exactly when we will be ready to move forward with this, but probably sometime in the next few weeks. It's already deployed on some other wikis, but there is concern about it flooding the database connections on enwiki since this template is included on so many pages. I'll let you know when we're ready to push ahead. Ryan Kaldari (WMF) (talk) 17:40, 8 September 2016 (UTC)

• So this would only pull from the templates and there would be no writing the database directly? I posted at Template talk:WikiProject banner shell#Class once about how it would be nice to rate the article's class once per article. I imagine it would be even easier if it was a click in Wikidata rather than template code... czar 19:25, 11 September 2016 (UTC)
  • I believe that is correct, for now. At Wikipedia_talk:WikiProject_Council#Some_relevant_technical_changes_in_the_pipeline I remarked on how I have some ideas for centralizing article assessments through a new interface, but that's a long term plan. Harej (talk) 10:34, 12 September 2016 (UTC)

@WOSlinker, MSGJ, and Harej: I've added the new code to the sandbox template. Please let me know if that looks correct or if anything needs to be changed, as I'm hoping to only do this once (since it's a huge load on the servers). Kaldari (talk) 08:42, 31 October 2016 (UTC)

No not really. You seem to be imposing FQS on every project when not every project uses the full scale. A lot now have their own bespoke quality scales. It would make more sense to put your code into /core where the class and importance have already been normalised. I can have a tinker if you wish. Regards — Martin (MSGJ · talk) 08:48, 31 October 2016 (UTC)

@MSGJ: Sure, any help would be great. Ideally we want the data in PageAssessments to match what is output by the template. Kaldari (talk) 16:22, 31 October 2016 (UTC)

I assume you mean tinkering with /core/sandbox rather than /core itself. Just want to make sure we aren't making any unnecessary edits to the main templates. Kaldari (talk) 17:04, 31 October 2016 (UTC)

I assume that if a project does not use assessments then the whole tag will be omitted? What if a project uses class but not importance? Can the tag be used with just the class? What if assessments are used but class and/or importance are unassessed? Should this be passed as a blank parameter to the tag or should "Unassessed" be used? — Martin (MSGJ · talk) 21:41, 1 November 2016 (UTC)

@MSGJ: If a project doesn't use assessments, but still tags articles, we would still want to capture that information, i.e. that the WikiProject has "claimed" an article, so {{#assessment:WikiProject NoAssessments||}}. If no class or importance are given, those should just be passed as blank parameters, e.g. {{#assessment:WikiProject NoAssessments|FA|}} or {{#assessment:WikiProject NoAssessments||Low}}. Kaldari (talk) 22:46, 3 November 2016 (UTC)

Is there any distinction between an "unassessed rating" by a project that uses assessments and a "claim" by a project that doesn't use assessments? (You didn't answer the question above on whether "unassessed" or "unknown" was allowed as a class/importance rating.) — Martin (MSGJ · talk) 08:57, 4 November 2016 (UTC)

There is a distinction: some projects consciously do not have ratings, see for example Template talk:WikiProject Women#Importance. --Redrose64 (talk) 12:24, 4 November 2016 (UTC)

Indeed. My question was whether there is any distinction in the PageAssessments database. — Martin (MSGJ · talk) 12:51, 4 November 2016 (UTC)

@MSGJ: "unassessed" or "unknown" (or any value) is allowed as a class/importance rating in PageAssessments. I don't, however, see any value in an assessment of "unassessed". I would prefer that any unknown or unassessed ratings just be passed as empty parameters to PageAssessments (unless that makes things substantially more difficult). It will make things much easier to query if anything besides an actual assessment rating is recorded as null. As far as PageAssessments is concerned, there is no distinction between an empty assessment from a project that doesn't do assessments and an empty assessment from a project that does. Basically all assessment data is treated as optional for all projects. Kaldari (talk) 01:24, 6 November 2016 (UTC)

The present setup is that if a project banner is set up to recognise class and importance parameters, but in a given usage those are not set (whether the param is absent or present but blank is immaterial), then it's passed through from {{WPBannerMeta}} to {{WPBannerMeta/core}} and subtemplates as a null value - an empty string, if you like; so the page gets categorised in e.g. Category:Unassessed Computing articles or Category:Unknown-importance Computing articles. However, if a project banner is set up to not recognise class and/or importance params, then there is nothing to pass through, and the special character "¬" is used as a placeholder by {{WPBannerMeta}}. This is not interpreted as either "unknown" or "unassessed", but instead it denotes "meaningless" - as in "this concept has no meaning", like zero divided by itself is meaningless. So there is no class/importance processing, and no categorisation since there is no meaningful category in which to place the page. --Redrose64 (talk) 14:44, 6 November 2016 (UTC)

That makes sense. In the case of the assessment class being "¬" (or absent), it would be best to pass a blank parameter to PageAssessments. Perhaps in the future we could have it handle those cases differently, but right now there is no practical way to handle such a distinction in the PageAssessments data. Kaldari (talk) 20:41, 8 November 2016 (UTC)

PageAssessments: code ready

Okay I have put the code in Template:WPBannerMeta/core/sandbox and there are some tests on Template talk:WPBannerMeta/testcases. (Obviously the lower box is just for testing and will not appear on the deployed version!) A couple more questions:

• I assume you are interested in all the extended class ratings used by various projects such as Template-class, Redirect-class and NA-class?
• If a project has subprojects or task forces, do you want to record each task force's interest in the article as well? For example should we be calling {{#assessment:Crime task force|B|High}}?

— Martin (MSGJ · talk) 09:39, 7 November 2016 (UTC)

@MSGJ: Thanks! Yes, definitely interested in the extended class ratings. Adding assessment data for subprojects and task forces would be great, but I'm also OK with leaving these out if its too complicated. The format you suggest, {{#assessment:Crime task force|B|High}}, would be correct. Kaldari (talk) 20:34, 8 November 2016 (UTC)

Code for setting task force assessments is in Template:WPBannerMeta/taskforce/sandbox. However it can only work if the TF_n_NAME parameter is defined. (You will see that in the first example the military task force does not currently use this parameter so the assessments will not be set.) It would be possible to go through the templates filling in these missing parameters if necessary. I could even add a tracking category for it. — Martin (MSGJ · talk) 09:35, 9 November 2016 (UTC)

@MSGJ: That looks great! A tracking category for the missing parameter would also be helpful. Do you think it would be possible to put this into place in the main template late Friday night or Saturday (so that it can populate the database over the weekend). It would be good to avoid adding this during peak hours (16:00 to 04:00 UTC) since it's going to create a huge number of database queries (although they will all be low-priority in the job queue). Also, will it require editing more than 1 subtemplate? Kaldari (talk) 22:05, 10 November 2016 (UTC)

Probably won't be available Saturday but can make the change on Sunday. Yes the two affected subtemplates are /core and /taskforce. — Martin (MSGJ · talk) 22:35, 10 November 2016 (UTC)

@MSGJ: We may want to stagger the two changes to give the databases and job queue some time to breathe. Like maybe doing the /core change Sunday and the /taskforce change next weekend. At this point I'm assuming that you would prefer to make the changes yourself, but if not, let me know. Kaldari (talk) 02:07, 12 November 2016 (UTC)

I've deployed to /core and tested on a few articles by making a null edit to the talk page and then checking the API output. Seems to be working well at the moment. — Martin (MSGJ · talk) 07:45, 13 November 2016 (UTC)

The code in Template:WPBannerMeta/taskforce/sandbox is ready to deploy when needed, and there is now Category:WikiProject banners with missing task force name to track the templates which are missing the TF_n_NAME parameter. — Martin (MSGJ · talk) 09:59, 18 November 2016 (UTC)

@MSGJ: Actually, let's hold off on adding the taskforce code for now. I think I want to add a way for PageAssessments to differentiate between WikiProjects and taskforces/subprojects before we add the taskforce assessments. I'll let you know when it's ready to move forward. Thanks again for all your help with this! It's been extreme valuable. Kaldari (talk) 23:04, 19 November 2016 (UTC)

No problem — Martin (MSGJ · talk) 11:46, 20 November 2016 (UTC)

For what it's worth, the auto-updating WikiProject Directory does not distinguish between WikiProjects and task forces. Harej (talk) 21:14, 8 December 2016 (UTC)

@MSGJ: Since some project templates use PROJECT_NAME instead of PROJECT, PageAssessments is recording the project name as {{{PROJECT}}} for those. Since none of these non-WikiProject projects actually use assessments, can we just change the code to {{{PROJECT|}}} in the core {{#assessment}} code? (PageAssessments will ignore any records with blank project names.) IMO, it seems like non-WikiProject projects should use their own templates rather than piggybacking on the WikiProject meta template, but I suppose that's a separate issue. Kaldari (talk) 16:41, 6 December 2016 (UTC)

PROJECT is a required parameter so those templates should really be fixed up. Could you give me some examples so I can see if there is a sensible way of defining that parameter for those templates? — Martin (MSGJ · talk) 17:15, 6 December 2016 (UTC)

@MSGJ: It looks like the main offender is {{WikiTown banner core}}, which is a meta template for other templates such as {{Freopedia}} and {{Toodyaypedia}}. Kaldari (talk) 23:27, 6 December 2016 (UTC)

Okay I'll take a look. In the meantime there is certainly no harm in putting the pipe in — Martin (MSGJ · talk) 09:11, 7 December 2016 (UTC)

I have added the PROJECT parameter for the WikiTown projects, so these should now be recorded as Freopedia and Toodyaypedia in your database. I have also added a pipe to prevent the error happening in future, and I have added a check for this which will populate a tracking category. Any progress with the task forces? — Martin (MSGJ · talk) 09:38, 7 December 2016 (UTC)

@MSGJ: Still working on it: T154216. Kaldari (talk) 06:14, 28 December 2016 (UTC)

Subprojects

@MSGJ: OK, we are finally ready for subprojects. The format that the subproject data needs to be in is: {{#assessment:Medicine/Neurology task force|GA|low}}, in other words: {{#assessment:{{{PROJECT}}}/{{{NAME}}}|class|importance}}. This is slightly different than the sandbox code that you wrote up earlier. Kaldari (talk) 01:37, 10 February 2017 (UTC)

Will need to rewrite some of the code - currently PROJECT is not passed to the taskforce template. Will also require the same update to any project template using taskforce hooks. — Martin (MSGJ · talk) 09:50, 10 February 2017 (UTC)

I've made a few tweaks to the code and the page assessments should be filtering through. There's a lot of work to do at Category:WikiProject banners with missing task force name though. Basically every taskforce hook needs (a) PROJECT parameter and (b) TF_n_NAME parameters to be defined. — Martin (MSGJ · talk) 15:21, 13 February 2017 (UTC)

@MSGJ: Thanks! I'll see what I can do to get the parameters added. Kaldari (talk) 17:58, 13 February 2017 (UTC)

@MSGJ: Do we need to update {{WPBannerMeta/hooks/tfnested}} as well? I'm not sure I understand what that template is for. Kaldari (talk) 18:45, 13 February 2017 (UTC)

No, that code is just for producing the label which appears when the banner is collapsed inside a banner shell. No impact from this change. — Martin (MSGJ · talk) 13:17, 14 February 2017 (UTC)

@MSGJ: Seems to be working. One problem that I've noticed is that about half of the task force names are of the form "the something task force" and the other half are just "something task force". "Something task force" works a lot better for my purposes, but it causes the grammar in the template to be a bit awkward: "This page is supported by Beekeeping task force." And unfortunately we can't just hard-code "the" into the template since a lot of task forces are actually WikiProjects, which would yield: "This page is supported by the WikiProject Beekeeping." It's unfortunate that setting up WikiProjects as task force parameters has become a normal practice as it leads to lots of inconsistencies in PageAssessments. Anyway, do you have any suggestions for how to handle the "the" situation? I could add some code in PageAssessments to explicitly strip it out, but that seems a bit hacky (and English specific). Kaldari (talk) 20:51, 14 February 2017 (UTC)

If it's always the case that a preceding "the" should be removed, then I think it should be fairly easy to use a template to do that. Shall I look into it? — Martin (MSGJ · talk) 21:46, 14 February 2017 (UTC)

@MSGJ: Yes, a preceding "the " should always be removed from the assessment record. That would be great if it could be removed by a template. Kaldari (talk) 17:59, 15 February 2017 (UTC)

Something like the code below should do it, but I am worried about any valid projects that start with "the" (e.g. theology) as I'm not sure how the template will handle the space. Will do some proper testing shortly. — Martin (MSGJ · talk) 18:12, 15 February 2017 (UTC)

{{#ifeq:{{ Str left | {{{NAME}}} | 3 }} |the|{{str right|{{{NAME}}}|4}}|{{{NAME}}}}}

@MSGJ: Unless we can detect for the space, I think it will be safer for me to chop it off on the PageAssessments side. I can also filter out bold markup while I'm at it (which a lot of NAME parameters use for some reason). Kaldari (talk) 18:28, 15 February 2017 (UTC)

New code for cleaning up project titles at https://gerrit.wikimedia.org/r/#/c/337963/. Kaldari (talk) 21:54, 15 February 2017 (UTC)

As you prefer. It's an ugly hack wherever the code goes ;) We're basically using a parameter for a purpose it was never designed for. If building this from scratch we probably would have taken a different approach, such as |TASKFORCE_NAME=beekeeping from which the name "the beekeeping taskforce" could be automatically used, and |SUBPROJECT_NAME=Beekeeping could give "WikiProject Beekeeping". — Martin (MSGJ · talk) 09:03, 16 February 2017 (UTC)

Kaldari, by the way all the banner templates should now be updated to produce the correct code for subproject page assessments. I've deleted the tracking category because all were fixed. — Martin (MSGJ · talk) 10:00, 10 March 2017 (UTC)

@MSGJ: It seems that the taskforces defined by the tf X parameters are working correctly, but the task forces defined via {{WPBannerMeta/hooks/taskforces}} are not being recorded by PageAssessments. For example, the only task force being recorded for {{WikiProject Medicine}} is the Dermatology task force, since all the other task forces are defined via {{WPBannerMeta/hooks/taskforces}}. (You can look here for the current list of what task forces PageAssessments has records for.) Any idea why it might not be working? Kaldari (talk) 03:31, 11 March 2017 (UTC)

Yes, found another subtemplate which needed the parameter passing through. Should be working now?! — Martin (MSGJ · talk) 22:02, 12 March 2017 (UTC)

@MSGJ: Looks like it's working now. Thank you! Kaldari (talk) 01:27, 13 March 2017 (UTC)

Template:Substcheck

Is Template:Substcheck still in use? I can't find the logic which applies that template. Jo-Jo Eumerus (talk, contributions) 12:57, 25 March 2017 (UTC)

Yes, it is in nearly every WikiProject * template. They all include the line |substcheck=<includeonly>{{subst:</includeonly><includeonly>substcheck}}</includeonly>. Which only ever transcludes the Substcheck template when the WikiProject template is substituted, which is the reason for the substcheck. -- WOSlinker (talk) 17:55, 25 March 2017 (UTC)

Wonder if it merits template protection then. Jo-Jo Eumerus (talk, contributions) 18:16, 25 March 2017 (UTC)

It has this effect. --Redrose64 🌹 (talk) 19:29, 25 March 2017 (UTC)

Let automatic categorization ignore the Importance parameter

WP:VG doesn't classify redirects by importance (I imagine most projects do the same). Is there a way to set the template, even project by project if necessary, to ignore |importance= when the article is classified as "Redirect"? It would be easier than having to manually remove the parameter each time. czar 18:19, 1 March 2017 (UTC)

@Czar: The template will automatically classify NA-importance for any redirect, unless the importance has been set manually. It sounds like you are asking for the parameter to be ignored completely if the page is a redirect. If there is consensus for this, we might be able to make this change to Template:Importance mask. Otherwise you can set up a custom importance mask for your project. (Ask if you want to know more.) — Martin (MSGJ · talk) 17:14, 7 March 2017 (UTC)

@MSGJ, yes, there is consensus that WPVG's redirects, drafts, etc. non articles should drop recognition of the "importance" param (easier to ignore it than to manually set each to NA). Can you help with the mask? czar 21:10, 7 March 2017 (UTC)

@Czar: Please check if {{WikiProject Video games/sandbox}} is doing what you desire — Martin (MSGJ · talk) 09:02, 13 March 2017 (UTC)

Late response: yes, that seems to do what we needed. Thanks! --PresN 15:03, 5 April 2017 (UTC)

Proposal to add quality criteria to WikiProject templates

See Wikipedia:Village pump (proposals)/Archive 138#Add quality criteria to WikiProject templates. The proposal was to add a show/hide link to the right of the quality rating so editors could more easily see what the rating actually meant. A mock-up:

	This page is supported by WikiProject Ecoregions, a collaborative effort to help develop and improve Wikipedia's coverage of ecoregions. The aim is to write neutral and well-referenced articles on these topics. See WikiProject Ecoregions and Wikipedia:FAQ/Contributing.
Start	This article has been rated as Start-Class on the project's quality scale. Detailed criteria: The article has a usable amount of good content but is weak in many areas. Quality of the prose may be distinctly unencyclopedic, and MoS compliance non-existent. The article should satisfy fundamental content policies, such as BLP. Frequently, the referencing is inadequate, although enough sources are usually provided to establish verifiability. No Start-Class article should be in any danger of being speedily deleted. Reader's experience: Provides some meaningful content, but most readers will need more. Editing suggestions: Providing references to reliable sources should come first; the article also needs substantial improvement in content and organisation. Also improve the grammar, spelling, writing style and improve the jargon use.
Low	This article has been rated as Low-importance on the project's importance scale.

Notes:

• The [show] link will apply only to projects that have accepted the standard assessment scheme defined in {{Grading scheme}}, and will be implemented in {{WPBannerMeta}}. Projects with non-standard quality scales or criteria will not be affected
• The [show] criteria will be in one place only, the {{WPBannerMeta}} template, not replicated in all the project templates.
• The standard quality scale criteria defined in {{Grading scheme}} are extremely stable (i.e. cast in stone), but to ensure the criteria in the {{WPBannerMeta}} template are in sync with those in {{Grading scheme}}, we will make them both share the same text files.
• Addition of the [show] criteria will cause an increase in page size for a talk page with just one project banner from about 30,000 characters to 30,500 characters on a desktop, and from about 21,000 to 21,500 characters on a mobile device. Since the main target is editors, and they will usually not use a mobile device to edit, we may suppress this feature on mobiles.

The response at the village pump was 4–2 in favor if the author gets a vote. Reasons against were that the template already provides a link to the quality scale, so this is pointless clutter, and it would increase message size. The reason for supporting is that editors would be more likely to click on the [show] link, so assessment quality would improve. Given the many pages that would be affected and my lack of coding skills, I do not propose to make the change myself, but would hope for a volunteer. Are there serious technical difficulties or concerns? Aymatth2 (talk) 15:25, 20 April 2017 (UTC)

What about those with the extended scale? In my experience, those outnumber the ones with the standard scale. Also, what about those which have set up a custom scale, but the only actual customisation is to either disable one (often A-class), or to add one or two (such as Book-class or Redirect-class). --Redrose64 🌹 (talk) 20:17, 20 April 2017 (UTC)

I would be fine with supporting the extended scale as long as it does not add much complexity. If there are simple ways to support more customized scales and definitions, that would be good too. Maybe there is a way to pick up any available definitions, so X class [show] is supported if X_detailed_criteria, X_readers_experience and/or X_editing_suggestions have defined values in the project context. But I would prefer to keep it simple to start with. Aymatth2 (talk) 00:28, 21 April 2017 (UTC)

More informative optional text for categories of Wikiprojects

Hello, when I will use the template {{WikiProject Academic Journals}} or {{WikiProject Plants|class=Category}} at some category talkpage, it will show text:

Category  	This category does not require a rating on the project's quality scale.

It is not much useful. Could it be possible to change the text to more descriptive according to certain Wikiproject needs? For example the mentioned Wikiprojects can have texts:

Category  	This Wikiproject follows Categorization of journals.

or

Category  	Recommendations for categorizing plants.

Or something like a wikilink to guidelines or to recommendations. I know that there is optional BOTTOM_TEXT for each Wikiproject template, but optional text would be useful for categories of Wikiprojects. How to do that? Snek01 (talk) 12:46, 21 May 2017 (UTC)

@Snek01: I have moved your question here because it is relevant to this template. The text you mention is produced by Template:WPBannerMeta/qualityscale. It is currently not possible to change this (and to my knowledge no one has ever asked for this before). However you could probably copy that code somewhere and make the changes you want and then implement your customised code using HOOK_ASSESS. It may be complicated because you are adjusting such an intrinsic part of the template (i.e. the class ratings part). Alternatively if there was demand for this feature from multiple projects we could look at adding the functionality here. — Martin (MSGJ · talk) 20:44, 21 May 2017 (UTC)

Removing the "importance" parameter

Following the discussion at WP:Village pump (technical)/Archive 155#Removing the "importance" parameter from a WikiProject banner, I followed the advice given by Redrose64 and have done the required edit to {{WikiProject Disability}}. In the same discussion Iridescent mentioned that a bot could go around to all the existing banners to remove the Importance parameter. What do I need to do to get such a bot task done? If there's anything else I've missed or done wrong please let me know. Roger (Dodger67) (talk) 11:18, 9 June 2017 (UTC)

AnomieBOT is the bot you want (Anomie I assume it falls under WikiProjectWorker and wouldn't need a separate BRFA?). I'd strongly advise leaving the assessments in situ but invisible for at least a couple of months before a bot run to remove them—if people object to the removal it's a lot easier to just make the existing assessments visible again, than to re-add an assessment to every page. ‑ Iridescent 11:31, 9 June 2017 (UTC)

Yes, leaving |importance=low etc. on every talk page is harmless - nothing is displayed, no categorisation is performed. --Redrose64 🌹 (talk) 11:41, 9 June 2017 (UTC)

Does anyone know where the discussions on removing priority/importance ratings are for {{WikiProject Disability}} and {{WikiProject Visual arts}}. I would like to summarise typical reasons in Wikipedia:Assessing articles. Is there an easy way to find other projects that skip the ratings? Aymatth2 (talk) 12:06, 9 June 2017 (UTC)

Aymatth2 See WT:WikiProject Disability#Proposal to remove the Importance parameter from the project banner and the article assessment system where I proposed the removal a month ago, nobody responded at all so per "silence = agreement" I've gone ahead. "Importance" is often a subjective personal opinion and subject to dispute. It's also of little to no actual value in the project's article improvement system - the Stub/C/B/GA/FA says everything we need to know about the article's quality, regardless of what it is about or how "important" anyone thinks it is. Roger (Dodger67) (talk) 13:18, 9 June 2017 (UTC)

Some projects follow one the two "standard" schemes, which give reasonably objective criteria, and some follow tailored schemes, like {{WikiProject Iran}}. Most effort should be given to improving articles on the most central aspects of the project's subject area. But with some areas it may be unavoidably subjective, like the difference between low- and mid-importance visual artists. I hoping for ideas on when importance ratings don't work to use in the Wikipedia:Assessing articles essay. Aymatth2 (talk) 14:42, 9 June 2017 (UTC)

You might consider taking a look at WP:VG/A#Importance scale. I don't think anything there is out-of-step with your essay--I think it might be good to point out that breaking down a field into subsections and then providing assessments for those subsections can help with good assessment. --Izno (talk) 15:54, 9 June 2017 (UTC)

@Izno: Thanks for pointing that out. I have added a note on it to the essay. An interesting approach that others might want to follow. Aymatth2 (talk) 16:50, 9 June 2017 (UTC)

As regards Visual Arts, a conscious decision was made not to include "importance" when the template was originally created a decade ago, so there's never been a "decision to remove it" as such. Occasionally people will suggest adding one, but it never finds any support. "Importance" really doesn't work on arts topics; someone interested in 19th century English history painting, someone interested in traditional Chinese porcelain, and someone interested in pre-Colombian architecture will each have a completely different idea of what "high importance" means.

As I often point out, what editors feel ought to be the important topics rarely correlate with what the readers consider important topics; in terms of what the readers are actually reading, Darth Vader consistently gets more pageviews than United States and World War II combined. To take the disability project as an example, if you look at what the readers are actually looking for there's not actually a very strong correlation between pageviews and "importance"—ultra-core topics like Speech and language impairment get fewer views than trivia like I've fallen, and I can't get up!. ‑ Iridescent 17:14, 9 June 2017 (UTC)

@Iridescent: Good points. I have added them to the essay. The pageviews difference makes sense: Darth Vader has galactic importance while the other two articles just cover minor details about one species on a small green planet. Aymatth2 (talk) 11:55, 10 June 2017 (UTC)

And old idea, revisited, part 2

This is a follow up to Template_talk:WPBannerMeta/Archive_10#An old idea, revisited, related to discussions with Nihiltres (talk · contribs) and Dispenser (talk · contribs) at Wikimania 2017.

• Mockup 1 was the original idea. Tried to include "vital" articles in there, but for 10,000 articles, this is really flagging this at the completely collapsed level.
• Mockup 2 effectively treats vital articles as another Wikiproject, with vitality replacing importance. It's quite neat, but discussions at Wikimania led me to a third mockup
• Mockup 3 the main thing is we separate type (article, list, category, media) from assessment, and can offer all levels of assessments for things that require assessments. I've also re-designed the issue-flagging so it's actually clear what the icons mean. Some of the links would have to be updated / some pages created, but you get the general idea.

Now of course, there is currently no B-class topics, or C-class media, so if consensus is against having those, we could easily restrict assessments to partial lists depending on type. I don't see support for anything but featured media, but on topics or lists? I absolutely see a demand for those. Headbomb {t · c · p · b} 14:27, 15 August 2017 (UTC)

There have been several proposals for a Good List class. They failed (see for instance Wikipedia talk:Good article nominations/Archive 22#Request for comment on stand-alone lists being nominated as Good Articles or Wikipedia:Village pump (proposals)/Archive 123#Good Lists - others exist as well); so any other graduations for lists are not likely to succeed either. That's with the exception of MILHIST which already has AL, BL and CL, see WP:MHA#SCALE. --Redrose64 🌹 (talk) 22:18, 15 August 2017 (UTC)

I know for a fact that WP:PHYS would make use of B/C/Start/etc... lists. I suspect most projects would too, were it actually easy to set up. I'm not proposing we extend this systematically and create new reviewing process when there's no demand for such (e.g. Good lists, Good media, Good portals, etc...), just that we extend the scheme to support such assessment when needed. Projects that have no desire to assess lists could easily continue not doing so, but from my experience there is an appetite to keep track of how lists perform. Reading from the RFC, it seems most people objected because no solid criteria for a good list have been put forward. Headbomb {t · c · p · b} 22:35, 15 August 2017 (UTC)

As I noted above, that RfC was not the only proposal. But we already have the mechanism for any WikiProject to add AL/BL/CL if it wants to, it is {{class mask}}, see for example Template:WikiProject Plants/class. --Redrose64 🌹 (talk) 07:37, 16 August 2017 (UTC)

The class mask is a real pain in the ass to setup, and most don't want to bother dealing with that. Nihiltres (talk · contribs) is working on externalizing the classes to a json file however, it looked real promising from what I saw of it. Headbomb {t · c · p · b} 10:47, 16 August 2017 (UTC)

@Redrose64 and Headbomb: I've written up a little of my plans in the section below. Specifically, {{class mask}} would be replaced with WikiProject-specific JSON files that extended or overwrote parts of the "default" class set. This would help implement "type" separation from assessments. I do think, though, that we'd be better off implementing the design improvements first before we tackle the headache of disentangling "type" assessments from quality assessments. I'm going to start writing up code to reimplement most of WPBannerMeta in Lua, so the most helpful thing at this point would be to get the main design improvements solidified so that I can get them out. {{Nihiltres |talk |edits}} 00:02, 29 August 2017 (UTC)

To keep this discussion going: I've been eyeing the implementation details here and it looks like a lot of the functionality of the redesign is applicable to {{WikiProject banner shell}}; it'd be really helpful if someone could itemize the features of this redesign as they'd be applicable to each template. Some support will happen in this template—or Lua reconstruction thereof—but some major features, like including a "master" rating, would have to happen in the banner shell. {{Nihiltres |talk |edits}} 20:52, 7 September 2017 (UTC)

• Would this make sense to wrap into {{article history}}? It already covers the status rating of the article (GA/FA, could extend down to Start for unified/"master" rating), and the template could also house a condensed listing of the relevant WikiProjects (I would go multi-column with shorter line heights, compared to the mockups). My gut tells me that WikiProjects create a lot of needless work for themselves (esp. relative to their editor capacities) by tagging talk pages rather than generating, say for WP:VG, database readouts of all articles of "instance: video game, video game developer, etc." These templates are supposed to improve editor productivity, so wouldn't it better to generate readouts for any grouping of WP articles, e.g., topics related to Ursula Le Guin or financial companies in Iceland without necessitating a separate Ursula Le Guin (etc.) WikiProject with infrastructure and all? (Again, let the projects who actually use their custom features keep them—Milhist, Chem, anyone who actually uses their "importance" ratings—I'm thinking more of the vast majority of WikiProjects that have simple needs or are altogether dormant, where we should try to reduce editor maintenance costs while refining this template, if possible. czar 06:18, 10 September 2017 (UTC)

Suppressing class categories

I would like to add "class = Disambig" to Template:WikiProject Disambiguation so that all the tools that rely on PageAssessments data (XTools, CopyPatrol, Popular Pages Bot, etc.) will recognize these pages as disambiguation pages (as most of them don't have any other WikiProject banners). However, this would needlessly categorize all of these pages into a new NA-Class Disambiguation articles category, which would be silly. Is there any way to suppress the creation of class categories (besides not passing a class)? If not, could a way be added? Kaldari (talk) 20:27, 8 December 2017 (UTC)

I rather think that XTools etc. recognise pages as disambig-class by their being in a subcategory of Category:Disambig-Class articles, and not by the presence of parameters in WikiProject banners. That being the case, here is what I would do:

1. Modify {{WikiProject Disambiguation}} to have two new lines:

   |QUALITY_SCALE=inline
   |class={{class mask |dab|disambig=yes}}
   

2. Create Category:Disambig-Class Disambiguation articles with the following content:

   {{CategoryTOC}}
   [[Category:Disambig-Class articles]]
   

After a while, the category will populate. There should be no need to create any other categories. --Redrose64 🌹 (talk) 15:59, 9 December 2017 (UTC)

Or instead of step 1, you could add the category to the banner without displaying the class type. <includeonly>[[Category:Disambig-Class Disambiguation articles]]</includeonly> -- WOSlinker (talk) 20:13, 9 December 2017 (UTC)

You'd need to be careful how you did that, so that |category=no would still be honoured. --Redrose64 🌹 (talk) 23:39, 9 December 2017 (UTC)

True. <includeonly>{{#ifeq:{{lc:{{{category|}}}}}|no||[[Category:Disambig-Class Disambiguation articles]]}}</includeonly> -- WOSlinker (talk) 13:28, 10 December 2017 (UTC)

Overhaul: moving to Lua & JSON

I'm planning to rewrite this template's functionality as a Lua module. As part of that, the plan will be to incorporate some design tweaks (as suggested earlier/above by Headbomb) and move class definitions and class masks to a JSON-file model. I've already prototyped a JSON file covering the "standard" set of classes over at Template:Class/definition.json, and there's Lua covering the functionality of {{class}} and related over at Module:Class. I never pushed those live because they are bad at supporting custom classes; this upgrade will get us around that problem. Individual WikiProjects will be able to define their own JSON files to extend or override the default set.

Besides Lua generally producing faster, cleaner, and more maintainable code, the upgrade to use JSON files in place of class masks has a very specific advantage: it'll be very easy for other tools to "discover" custom classes defined by individual projects. For example, I maintain the metadata gadget that brings assessments from the talk page to the title and tagline of the article namespace. That gadget currently must hardcode every custom class used by every WikiProject in order to support it, and that's not practical. By moving to JSON, both wiki-side Lua scripts and external (whether client-side gadgets in JavaScript or third-party code like bots) can access the same definitions without the need for one central file containing every custom definition used on the wiki. This will also make practical some future tools I'd like to develop, specifically focusing on exposing data about article quality over time and ORES.

I'm only human, so I'm probably missing some details here and there. Specifically, I'd appreciate input into the schema used for the JSON: for example, am I missing details that should be supplied in class definitions? More broadly, are there issues that this change would cause in places? I'd like to preempt problems as much as possible. {{Nihiltres |talk |edits}} 23:54, 28 August 2017 (UTC)

Highest support from me. This is a long term project, which will need a lot of testing and collaboration with other project/bots, but the goals are excellent and desirable. Headbomb {t · c · p · b} 00:29, 29 August 2017 (UTC)

Would the format used by the parameters in {{ReleaseVersionParameters}} be a good starting point for the schema? Titoxd^(?!?) 00:45, 29 August 2017 (UTC)

Indeed, ReleaseVersionParameters already had this goal in mind: the WP 1.0 bot does not hard code any custom quality or importance classes, but is able to parse them directly from the info in this "template". Really, it is not a template, just a way to format information in a way that can be parsed by a bot and hidden on the wiki. The main theoretical issues is if different projects have different custom classes on the same article, in which case there may be no easy way to tell the single "authoritative" rating for the article. It is necessary to have information on the relative position of each custom class with respect to the standard classes, which the template achieves with a numerical parameter. — Carl (CBM · talk) 01:24, 29 August 2017 (UTC)

My thought on "multiple custom classes" was that if there's more than one WikiProject involved in an article, the "authoritative", "standard" rating should be picked strictly from the standard set. We'd accomplish that not with numerical ratings—those are best for ranking qualities, rather than picking from them—but with a "maps to" property. For example, a WikiProject that implemented a "B+" rating could give it a property mapping that rating to the ordinary B-class rating for standardization purposes. If the mapping property wasn't provided, then by default we could map to the quality rating with the nearest lower numeric quality rating … which might mean having to be tricky about list-type ratings, but that's manageable. {{Nihiltres |talk |edits}} 14:04, 29 August 2017 (UTC)

That's great; I wasn't aware of that. Where bits overlap, it'd definitely be worth using the same patterns or values. For example, I've been thinking that a numerical value should be added to the class definition schema so that tools can insert custom classes into an overall order, and so that the "overall rating" of the page can be selected sanely—we can use the same scale as ReleaseVersionParameters. As mentioned, I started Template:Class/definition.json as the prototype schema; my current thinking is that it might make sense to expand the schema to use two inner objects ("quality" and "importance") or even three ("quality", "importance", and "WikiProject definition") so that we can put everything in the same place. {{Nihiltres |talk |edits}} 14:04, 29 August 2017 (UTC)

• Oppose Moving to Lua will make my long-term project (adding documentation to all WikiProject banners, ensuring that existing docs are accurate and up to date) much more difficult. It's OK when a banner uses one of the standard parameters in a standard way, but several use weird fiddles, and for these I need to trace through the code to see exactly what happens when a given permutation of parameters is in use. Lua code is untracable. --Redrose64 🌹 (talk) 20:10, 29 August 2017 (UTC)

  Could you be more specific with the problem, or give examples, please? I'd like to think that this project will help us smooth out "weird fiddles" somewhat, and I'm willing to write a variety of debug/testing tools into the code if that's something that you need. {{Nihiltres |talk |edits}} 03:41, 30 August 2017 (UTC)

  Couldn't a Lua version possibly auto-generate the documentation page as well? -- WOSlinker (talk) 07:57, 30 August 2017 (UTC)

  It may be possible to autogenerate some documentation in Lua, I don't know. Don't expect me to do it: Lua is a total enigma to me (when templates get converted to Lua, this is against the spirit of "the free encyclopedia that anyone can edit"). I have been documenting WikiProject banners since April 2010 and have developed a set of templates (see for example {{WPBannerDoc}}) that cope with most cases of standard parameters used in standard ways; examples include

• small – this parameter is no longer supported and can safely be removed from the template.

• category – set |category=no if, and only if, a banner is being used for demonstration or testing purposes, to prevent unnecessary or undesirable categorization. Otherwise, omit this parameter.

  and some cases of standard parameters used in non-standard ways, also some cases of non-standard parameters. My task is not complete: for example, I have not yet fully worked out the code for |A-Class= used by some banners (e.g. {{WikiProject Cricket}} used it until July 2016). --Redrose64 🌹 (talk) 09:43, 30 August 2017 (UTC)

I don't really see why LUA code in the background would prevent any of this working as is, or with small modifications. Not an expert on LUA, but to my understanding how you create specific instance of a banner like {{WP Physics}} should very much look the same as they do now, with a bit of streamlining for the class/importance code. Headbomb {t · c · p · b} 12:21, 30 August 2017 (UTC)

@Redrose64: There are (at least) two different ways we could roll this Lua/JSON update out:

1. Include a superset of existing functionality, move the new code into place in a single edit, then migrate deprecated functionality ("weird fiddles") to new functionality (i.e. the WikiProject-specific JSON file). Remove deprecated functionality as it's eliminated in the wild.
2. Write a new, cleaner template that significantly cleans things up but has a few breaking changes, then migrate project banners individually. Strictly speaking, we can write the JSON files that allow external-tool support for projects before migrating the project banners—just then we need to update things in two places any time a project wants to change its assessment system at all, with the risk that the two places become out of sync. This does have the advantage that it can be done even if the project members are cranky and don't want their project banner updated for whatever reason.

Either way, a focus will be on straightforward, single-document configuration for WikiProject assessment systems, and getting rid of complex multi-template systems (like A-class review hooks) in favour of integrated code that produces stuff that's more standard across WikiProjects. Either way, we'll have dozens of edge cases to resolve, and people that resist change for no good reason.

I understand the concern of Lua being opaque to you, but either way—multilevel-transclusion conditional wikitext or Lua—we've got complexity that's excluding someone. We should work on making it so that most people don't have to deal with the complicated stuff, of course, and I think that this project is in line with that through its design goal of moving "adding support for custom processes" (like A-class reviews) away from weird systems and so on into "just specify some extra properties for the class definition".

I think that our goals synergize well: we both want these systems to be easy to use and well-documented. My approach is just more dramatic, mostly by pushing things from "implement stuff yourself in wikitext" to "use the standard systems the banner module offers". My personal preference would be that we just force every WikiProject to use only a single standard set of classes and processes—that would give us site-wide consistency at a stroke—but I know that that's not politically feasible. As an alternative, I'm trying to make a system that offers support for custom classes and processes but makes them machine-readable so that we can deal with them (and yes, presumably document them) mostly automatically. {{Nihiltres |talk |edits}} 17:32, 30 August 2017 (UTC)

OK, here's an example. I've just improved Template:WikiProject Libraries/doc; whilst doing so, I found an unusual line in Template:WikiProject Libraries:

|INFOBOX             = yes

Wondering what the effect of that might be, I looked in the source of Template:WPBannerMeta for the sequence {{{INFOBOX and not finding it, I knew straightaway that the parameter was unrecognised, and I could safely ignore it. If Template:WPBannerMeta had been converted to a module, there would have been no way for me to find out whether that parameter is recognised or not, regardless of the difficulty in determining (if recognised) exactly what it does. --Redrose64 🌹 (talk) 08:47, 3 September 2017 (UTC)

If that's a desired feature, we could easily implement a parameter check like several templates do, and put out an error message when previewing the results. Headbomb {t · c · p · b} 12:20, 3 September 2017 (UTC)

Parameter checks which display error messages on preview - such as the one that I recently added to {{Infobox London station}} - are fine if the person adding that check knows what the valid parameters actually are. Once a template has become a module, you no longer know this. You are then dependent upon the module writer to keep the valid parameter list up to date, something which we cannot guarantee will be done, just as we cannot guarantee that those who amend templates will also amend the documentation. Any computer programmer will tell you that fully-documented functions are an ideal that is never achieved. --Redrose64 🌹 (talk) 12:48, 3 September 2017 (UTC)

(←) Module:Citation/CS1/Whitelist is updated each time a parameter is added or removed. You can also inspect Lua code in the same way as you inspected the template code for banner meta--it only seems opaque to you because you are unfamiliar with the language, not because it is impossible to do so. To any programmer, or anyone not versed in arcane template syntax programming language (and it is arcane, for a number of reasons), your use case is just as opaque. If you don't want to learn Lua, that's your prerogative. But right now, I personally find the current template completely opaque, and would much prefer a Lua representation. --Izno (talk) 14:09, 3 September 2017 (UTC)

Agreed. I've started in on the work of converting the module, but almost all of my work so far has been assembling personal notes on how the template works to make sure I match functionality reasonably well (for example, I need to look more into how the hook system is used in practice). The wikitext-vs.-Lua concerns are not a sufficient counterargument to my plan. That said, I do appreciate Redrose64's concern of documentation quality, and we can keep it in mind moving forward. {{Nihiltres |talk |edits}} 20:43, 7 September 2017 (UTC)

• The vast majority of WikiProjects use the simple/base banner, right? So I'd be less concerned about fitting the edge cases (let them continue to use the old banner innards, if necessary, if those projects even still actively use those extra features) than making the majority more efficient czar 05:58, 10 September 2017 (UTC)

  • Handling the edge cases is one of the goals of this change, though. I'm already maintaining a gadget that needs to be able to handle custom classes—that was a big inspiration for this—and right now it has to have extra styles, strings, etc. hardcoded into the gadget to support custom classes, which is untenable. I'm planning to make some tools that help surface progression of quality metrics over time and highlight ORES data for comparison, and for those tools it'll also be highly desirable to at minimum be able to automatically normalize custom classes to values from the standard set—let alone the portability and maintenance benefits of not hard-coding quality/importance classes in general. Handling edge cases well is one of the key benefits here. We can offer partial support by creating project configuration files for projects before they're properly updated, but that trick increases maintenance costs because it requires that any updates be mirrored in two places (the actual project banner, and the configuration file).

    The fact that most WikiProjects use "simple" options does offer us an easy migration path, though: once the code's in a usable state we can start migrating "simple" banners and whittle the problem down to the tricky projects. {{Nihiltres |talk |edits}} 19:55, 12 September 2017 (UTC)

    Sounds good. Just wanted to note that it's possible that some edge-case projects are no longer even active and therefore might not care if their edges are preserved. Perhaps someone can generate a list of edge cases and the rest of us can help by investigating czar 20:34, 12 September 2017 (UTC)

    Right, good call! I figure that we can proactively update most projects assuming there are no breaking changes. Few projects should have breaking changes; the nature of Lua means that it should be easy to cover most of the custom stuff with native functionality. Most of the edge cases should be easy to detect: they'll be using a class mask and/or the hook system, so they'll have non-empty values defined in relevant parameters. Many of those will be simple cases like "supporting extra parameters" that Lua can handle with negligible effort; a few might be more complicated. First things first, though: I've got to rewrite most of the core functionality. I'm planning to deprecate the hook system entirely: people who want that level of flexibility can instead just require() the main Lua module and reuse its functions in their own module. {{Nihiltres |talk |edits}} 21:31, 12 September 2017 (UTC)

• Support. WikiProject banners are a contentious area for many historical reasons, but I'm committed to moving the technology forward in a way which doesn't step on anyone's toes too much. @Nihiltres: Feel free to reach out if you'd like to collaborate. @Redrose64: Your documentation goals are extremely important, and we should make sure they are supported throughout this process as much as possible. TheDragonFire (talk) 10:45, 11 February 2018 (UTC)

Coloured blocks may be too large

On many pages (for example Talk:Deterrence (legal)) the coloured blocks for class and importance come out ridiculously large on zooming in, or when the page width is reduced, like jumping from a width of 5 em to 45+ em. Can something be done to keep the size constrained?  --Lambiam 11:45, 4 May 2018 (UTC)

Can't see this myself. What browser are you using? Maybe post a screenshot to show the problem? — Martin (MSGJ · talk) 12:41, 4 May 2018 (UTC)

@MSGJ: I was able to repro on Windows 7 with Firefox 59.0.3 (on Timeless skin, if that matters). That said, it was at a zoom level that I think is generally not a workable one, but I suppose could be used by readers with poor or failing eyesight. --Izno (talk) 12:58, 4 May 2018 (UTC)

For me it happens with Firefox 59.0.2 on macOS (using MonoBook), already at relatively modest zoom levels (5 times command-+, corresponding to a magnification of about 171% compared to the default) – or by a window size reduction to 58% of the screen width (1/1.71 = 0.58) at the default zoom level.  --Lambiam 22:55, 4 May 2018 (UTC)

This is very odd, because a WikiProject banner is essentially a table having three rows of three columns (in this case the third column isn't used). In a table, columns are of constant width all the way down, and so the the first cell of every row in the same table should be the same width as all the other cells in that column.

In the WikiProject law banner displayed at Talk:Deterrence (legal), the first column comprises one image and two items of text (the two coloured blocks under discussion). The width of the column is determined by the widest cell, which is File:Scale of justice 2.svg displayed 55px wide, and the two others are widened to match that one.

When text is left-aligned within a cell, the second cells of each row should have their left edges aligned vertically; that is to say, the text "This article has been rated as Start-Class on the project's quality scale." and "This article has been rated as Top-importance on the project's importance scale." should not be displayed any further to the right than the text "This article is within the scope of WikiProject Law, ...". The screenshot shows that such vertical alignment is failing, which to me suggests a browser problem.

Looking at that column-two text beginning "This article is within the scope ..." shows that the text is flowing around the image - the words "encompassed by it." are below the image and left-aligned with the image's left edge. This cannot happen if they are in different cells, so to my mind, something is merging two cells that should be distinct.

Another odd feature in that screenshot is the "Law portal" box - the white background should entirely fill the border of that box, instead of stopping short of the bottom border. --Redrose64 🌹 (talk) 20:03, 4 May 2018 (UTC)

The portal box is probably an artifact of using Timeless--every portal box appears so in that skin, though I can confirm Vector and Monobook are fine. I suppose it's plausible that it's related and may indicate an error in the portal box module/metatemplate, but I am skeptical. I think Timeless is more likely missing some skin coloring or border manipulation that can be found in the vector/monobook themes. And it's that the border isn't shrinking to the background, not that the background needs to fill in the shape delineated by the border. --Izno (talk) 20:31, 4 May 2018 (UTC)

Protected edit request on 12 May 2018

Request: Please change this template (or the other one; see below) so that the categories "Project-Class sociology articles" and "Top-importance sociology articles" are no longer invoked from every page transcluding it.

Background:

There is an error, either in this template, or in {{WikiProject Sociology}}, I'm not sure which. The undesired behavior is that pages including the latter template, get categorized into two article categories. One example is the Talk page for WikiProject Sociology at WT:SOCIO, which has two categories listed which are incorrect for a Talk page.

An example completely stripped of all excess cruft to make it easier to see the problem, and which also contains justification for the "undesirable" characterization, is here: User:Mathglot/sandbox/Test pages/Sociology Header noinclude thing. Thanks. Mathglot (talk) 03:00, 12 May 2018 (UTC)

What exactly is the problem here? You've tagged the Wikipedia talk:WikiProject Sociology page with {{WikiProject Sociology|class=Project|importance=Top}}. "Project-Class sociology articles" is simply an artefact of the underlying structure for the page categoriation. You could rename that to pages if that particularly annoys you, but nothing is broken here. Headbomb {t · c · p · b} 04:15, 12 May 2018 (UTC)

'Pages' or 'articles' is irrelevant, it's still wrong. A project page is not rated on a quality scale, and thus is not a 'Top-importance sociology articles' [or 'pages']. The talk page should be responsible for declaring its own categories, and not inherit them blindly, especially not if they aren't defining characteristics of the page. In any case, 'Top-importance sociology articles' [or 'pages'] is not a defining characteristic of a Project Talk page. I'm not a categorization honcho, I made need to page some folks that can explain this better than I can. Stand by... Mathglot (talk) 11:13, 12 May 2018 (UTC)

@Mathglot: If you do not want WT:SOCIO to appear as a top-level article, you need to remove the rating. Nothing was being inherited "blindly". --Izno (talk) 13:13, 12 May 2018 (UTC)

As for the class, that appears to be set correctly as it is indeed a project "article" (that it is called an article is an artifact more than anything--we don't care enough to change however many millions of project talk pages tagged as such just for article -> page). --Izno (talk) 13:15, 12 May 2018 (UTC)

If you object to the page being classified into top-importance aritcles, just don't set |importance=top in the banner. Headbomb {t · c · p · b} 13:20, 12 May 2018 (UTC)

In fact, you can safely remove the |class=Project as well as the |importance=Top since the class is detected automatically for all non-article talk namespaces (Category talk, File talk, Template talk, Wikipedia talk, etc.); the importance similarly defaults to NA (putting the page into Category:NA-importance sociology articles) in those namespaces. So all that you really need on Wikipedia talk:WikiProject Sociology is {{WikiProject Sociology}} with no parameters at all. --Redrose64 🌹 (talk) 21:12, 12 May 2018 (UTC)

Ah, I see now, I didn't realize it was coming from the parameters, and not directly from the template. You can mark this closed. Thank you one and all. 03:25, 13 May 2018 (UTC)

Either I'm really dense, or there's something I'm missing. I've removed both project class and quality scale params, leaving only {{WikiProject Sociology}} in both the project page, as well as on my test page. Both pages continue to show two categories at the bottom of the page, although not the same ones as before. In the case of the test page, the two categories shown are NA-Class sociology articles and NA-importance sociology articles. In the case of the actual project page (Wikipedia talk:WikiProject Sociology), it shows Project-Class sociology articles and |NA-importance sociology articles. What am I missing? Can I say, |class=none |importance=none or something? Mathglot (talk) 07:15, 13 May 2018 (UTC)

This is normal behaviour for all WikiProject banners that recognise |class= and |importance= parameters. When one or the other of these parameters is blank or absent, a default value is used. As noted at Template:WikiProject Sociology#Optional parameters:

• class – valid values are listed in the custom class mask. See the project's quality scale for details. Setting an explicit value of NA is rarely necessary; for this, either leave |class= blank or omit the parameter.

If you don't want Wikipedia talk:WikiProject Sociology to appear in Category:Project-Class sociology articles and Category:NA-importance sociology articles, remove {{WikiProject Sociology}} entirely. You cannot keep the banner and also suppress the categories other than by removing recognition for the parameters entirely (as is the case with {{WikiProject Classical music}}), which would defeat the FA/A/GA/B/C/Start/Stub grading scheme as well. --Redrose64 🌹 (talk) 07:47, 13 May 2018 (UTC)

(edit conflict) Okay, that was my question (keeping the banner and suppressing the categories) but as you say, we don't want to defeat the grading scheme. Thanks again. Mathglot (talk) 08:06, 13 May 2018 (UTC)

FYI

I added a WP:AALERTS-related warning concerning mergers and moves in

• {{WPBannerMeta/locwarning}}

• {{WPBannerMeta/templatepage}}

Headbomb {t · c · p · b} 16:46, 14 August 2018 (UTC)

Infobox No

Wanted to see if someone could help me out. I've noticed a few pages with infobox=no that are still getting categorized into "Needs infobox" categories. In looking at the source code, it seems that these should not be categorized but I think I'm missing something... Anyone able to provide some insight? --Zackmann (^{Talk to me}/_{What I been doing}) 22:34, 3 October 2018 (UTC)

@Zackmann08: Which pages are these? It will depend upon the coding within the individual infobox template. --Redrose64 🌹 (talk) 22:58, 3 October 2018 (UTC)

@Redrose64: thanks for the response. One example would be Talk:Battle, East Sussex which uses {{WikiProject UK geography}}. Sounds like what you're saying is that the issue doesn't actually lie here with {{WPBannerMeta}} but with the way that particular template (in this case {{WikiProject UK geography}}) is calling the template? --Zackmann (^{Talk to me}/_{What I been doing}) 23:04, 3 October 2018 (UTC)

Read the Deprecated parameters section of the documentation for {{WikiProject UK geography}}. The parameter is behaving as described in the docs. -- WOSlinker (talk) 23:11, 3 October 2018 (UTC)

@WOSlinker: ah ok! Thank you for pointing me to that. It is a bit bass-ackwards, but really appreciate you pointing me to the right place. I figured I was just missing something so thank you much! --Zackmann (^{Talk to me}/_{What I been doing}) 23:22, 3 October 2018 (UTC)

@Zackmann08: That's probably why it was deprecated. There's only seems to be about 38 that need updating to the needs-infobox parameter format or removing if the infobox is there now. -- WOSlinker (talk) 08:44, 4 October 2018 (UTC)

Links from redirects?

Special:WhatLinksHere/Canadian Open Wireless and Mobile Communications Engineering Journal shows that Talk:Canadian Open Wireless and Mobile Communications Engineering Journal links to Canadian Open Wireless and Mobile Communications Engineering Journal.

However, I can't find any such links on either Talk:Canadian Open Wireless and Mobile Communications Engineering Journal, or {{WP Journals}}. What gives?

Does something in the metabanner need to make use of {{linkless exists}}? Possibly Module:Pagetype? Headbomb {t · c · p · b} 23:09, 12 October 2018 (UTC)

@Headbomb: Thanks for the ping. The talk page uses {{WikiProject Academic Journals}} which uses {{WPBannerMeta}}. That and its subpages do a few #ifexist: checks but only on pages such as WP:WikiProject Academic Journals, and there's no #invoke: for a direct module call. Those subpages do use several other complex templates which may record a spurious wikilink. I agree that {{Pagetype}} is the most likely candidate. Someone could test that theory by pretending to edit the module and previewing the talk page with the pagetype call removed. (I can't do this myself, as the modules are protected.)

As you've noticed, Module:Linkless is currently up for deletion. If done carefully, that could still allow {{linkless exists}} to keep working, but deleting the module-level interface would prevent other modules such as Pagetype from calling it.

However, I don't think that Linkless can help us here. Pagetype is not just checking for existence but reading the page to find out whether it is, for example, a redirect. I don't know any way to do that without recording a wikilink. Even if we found a way, I'm not sure that it would be a good idea: we do want the talk page banner to update if its counterpart in the main namespace changes type. Certes (talk) 23:58, 12 October 2018 (UTC)

Well, ideally, we'd want the banner to update, but without creating a link record. Because that's pretty annoying. Headbomb {t · c · p · b} 00:07, 13 October 2018 (UTC)

Sadly, I don't think that's possible. Updating the banner requires the link record. As I understand it, when a page (such as the redirect in main namespace) changes, MediaWiki runs a query similar to "what links here" to work out which other pages depend on it, and updates them. No link means no update. Certes (talk) 00:51, 13 October 2018 (UTC)

It's not possible. --Izno (talk) 01:03, 13 October 2018 (UTC)

At least not until T14019 is dealt with. Headbomb {t · c · p · b} 01:17, 13 October 2018 (UTC)

Proposed extension to usage of project banners

Comments please, on Wikipedia:Village pump (idea lab)/Archive 26#Semi-automate DELSORT based on Project tags. Thanks, Cabayi (talk) 14:10, 31 October 2018 (UTC)

Template:WikiProject Japan seems to be suppressing TOCs

I'm not sure if this is the right place to ask, but it seems that the template is blocking TOCs from being displayed unless __TOC__ forces the page to show it. See for example Talk:Japanese battleship Yamato, which has an apparently suppressed TOC. All of the project templates except for Japan are at Talk:German battleship Bismarck, where there is no problem with the TOC displaying. I looked at the template, but there's nothing I can see that's causing the problem (though I by no means know what I'm doing). Can anybody take a look? Thanks. Parsecboy (talk) 13:04, 19 November 2018 (UTC)

@Parsecboy: It's not, if you look in the Todo section of the banner on that page, you'll find the toc there. It's because Wikipedia:WikiProject Japan/ToDo as sections. If these were replaced with just bolded text then the toc would appear after all the banners. -- WOSlinker (talk) 16:27, 19 November 2018 (UTC)

Ah, that would explain it - the sections were added here, but I've reverted them. Thanks. Parsecboy (talk) 16:34, 19 November 2018 (UTC)

Protected edit request on 29 March 2019

Like Module:Documentation, this template should automatically sense the protection level of a template and then transclude the proper icon and category - currently, there are almost 20 template-protected wikiproject templates, and likely many more with other protection levels. I don't know how this is implemented, and don't want to try and mess around with something transcluded so heavily. Thanks, --DannyS712 (talk) 00:18, 29 March 2019 (UTC)

It certainly can be worked on by anyone, once a sandbox has been validated feel free to reactivate the edit request. — xaosflux ^Talk 01:44, 29 March 2019 (UTC)

It can be added to the Template:WPBannerMeta/templatepage page. -- WOSlinker (talk) 08:38, 29 March 2019 (UTC)

Why is this necessary? Which WikiProject banners are protected (to any level) but have no protection icon at top right? --Redrose64 🌹 (talk) 14:57, 29 March 2019 (UTC)

@Redrose64: Eg {{WikiProject Fencing}} --DannyS712 (talk) 16:07, 29 March 2019 (UTC)

Easy. Next? --Redrose64 🌹 (talk) 23:35, 29 March 2019 (UTC)

@Redrose64: I had a list, and put it somewhere. I'll ping you if I find it, but anyway thanks for the help. --DannyS712 (talk) 23:36, 29 March 2019 (UTC)

@Redrose64: {{WikiProject Rowing}}, {{WikiProject Running}}, and {{WikiProject Mixed martial arts}} all have hardcoded move and edit protection templates, as well as categories, that should be moved to documentation subpages. Can you help? --DannyS712 (talk) 23:39, 29 March 2019 (UTC)

Done, done and done; but if you examine the doc pages that I have created, none of them now have a pp template. It's built in to the core code of {{documentation}}, so there's no need to move any pp templates - just get rid of them. --Redrose64 🌹 (talk) 00:38, 30 March 2019 (UTC)

@Redrose64: yeah. I know that documentation automatically adds the icon and stuff, and thats what I wanted to do here (or at the /templatepage page). Thanks, --DannyS712 (talk) 00:47, 30 March 2019 (UTC)

Redirect categories

How do I modify Template:WikiProject Civil Rights Movement to allow Talk:Whites only to register in Category:Redirect-Class Civil Rights Movement articles? I am not familiar enough with this type of template to modify it. Mitchumch (talk) 01:03, 8 April 2019 (UTC)

Issue fixed. Mitchumch (talk) 22:20, 8 April 2019 (UTC)

Weird trailing indent causing excessive whitespace

Can someone make the text expand to the full width so it doesn't look like this?   ~ Tom.Reding (talk ⋅dgaf)  13:22, 2 June 2019 (UTC)

@Tom.Reding: Please don't upload Wikipedia screenshots to imgur. My browser takes several minutes to display anything, and then it's the cookie information box which I am obliged to "accept" before I can see anything useful. Even when I have exited the website, my computer slows to a crawl necessitating at the very least close and restart the browser. In the past, my antivirus software has warned me about imgur and I don't want to reboot every time.

Instead, we have guidance at WP:WPSHOT. --Redrose64 🌹 (talk) 19:12, 2 June 2019 (UTC)

@Redrose64: screenshot migrated to commons. Wow, if you don't mind, what browser & antivirus do you use?   ~ Tom.Reding (talk ⋅dgaf)  20:11, 2 June 2019 (UTC)

I have occasionally seen WikiProject banners used on talk pages where the text is confined to the left-hand half like that. Sometimes, a WP:PURGE will fix it; failing that, a WP:BYPASS. I think that it happens when some of the stylesheets or scripts were not fully processed by your browser. --Redrose64 🌹 (talk) 20:58, 2 June 2019 (UTC)

Unfortunately, neither a purge nor a bypass resolved the issue on Chrome (currently up-to-date: Version 74.0.3729.169 (Official Build) (64-bit)), but both Firefox and IE display normally.   ~ Tom.Reding (talk ⋅dgaf)  21:51, 2 June 2019 (UTC)

Is this on the template page itself? I am unable to reproduce, and I am using Chrome too — Martin (MSGJ · talk) 11:00, 3 June 2019 (UTC)

Multiple portals

Is there an easy way of displaying multiple portals in a WikiProject banner? I've taken a stab at this at Template:WikiProject Korea/sandbox but it seems like a bit of a hack and I'm not happy with the alignment of the main text. PC78 (talk) 12:33, 13 July 2019 (UTC)

@PC78: Please see my reply at Template talk:WikiProject Amphibians and Reptiles#Template-protected edit request on 9 April 2019. --Redrose64 🌹 (talk) 12:46, 13 July 2019 (UTC)

@Redrose64: Yes, what I've done is based on the WP Trains banner. I don't like how it aligns the main text at the top rather than in the middle, though. Is there any way to bypass this? PC78 (talk) 13:10, 13 July 2019 (UTC)

Could be a browser issue, I get this with Firefox but it looks fine using Edge. PC78 (talk) 16:37, 13 July 2019 (UTC)

I don't understand what "it aligns the main text at the top rather than in the middle" relates to. Please provide a WP:WPSHOT. --Redrose64 🌹 (talk) 19:16, 13 July 2019 (UTC)

Well, it's this. I've had a play around and it seems like it's always there, regardles of browser. The enlarged portal box has made it more pronounced but it otherwise seems to be unrelated. PC78 (talk) 23:27, 13 July 2019 (UTC)

A WikiProject banner is a table, tables have rows, and the top edge of each row cannot be any higher than the bottom edge of the row above, even when there are no visible borders between the rows. In the case of Template:WikiProject Korea/sandbox, the first row is the image, main text and portal box; the second row is the class information. Since the portal box is usually the tallest item in the first row, it governs the height of that row; on narrower screens (or when using high zoom settings) the main text will be the tallest item. You get the same thing happening at Talk:Elmers End station. --Redrose64 🌹 (talk) 00:01, 14 July 2019 (UTC)

Ah-ha, thanks for the explanation. PC78 (talk) 00:15, 14 July 2019 (UTC)

Lowercase class

Please see Wikipedia:Categories_for_discussion/Log/2019_July_24#Category:List-Class_articles which, if agreed, would require a change to this template. – Fayenatic London 12:14, 24 July 2019 (UTC)

Note size?

Does the main template not have individual parameters to set the size of a note image, i.e. |NOTE_1_SIZE= etc.? From the doc it looks like there is only a single parameter that applies to all notes. Is it therefore necessary to use the note hook if I want to do this? PC78 (talk) 16:34, 5 August 2019 (UTC)

@PC78: The non-hooked method of setting up a note does indeed restrict you to |NOTE_SIZE=, for a variant size you do need to use the hook form, |HOOK_NOTE={{WPBannerMeta/hooks/notes|...}}. --Redrose64 🌹 (talk) 22:13, 5 August 2019 (UTC)

Cheers, I guess I'll have to do that. Is there a reason why the template is set up this way? PC78 (talk) 22:15, 5 August 2019 (UTC)

Should we maybe hide the importance-rating when an article is classified as "low-importance"?

Importance ratings are helpful for categorizing in the project, and the vast majority topics are of low importance, but I do feel a bit mean rating a biography or a well-written article as being "low-importance". I'm wondering if we should maybe just hide the importance rating when set to "low"? It doesn't seem like something that would affect the projects and might be more encouraging than seeing your article marked as being of little importance. – Thjarkur (talk) 14:07, 4 August 2019 (UTC)

I don't see why we would do that. Headbomb {t · c · p · b} 15:36, 6 August 2019 (UTC)

rater-data.js subpages

There seem to be a lot of rater-data.js subpages for various WikiProject banners, all I've looked at are unused as far as I can see. Do anyone know about their purpose? Please respond at the related TfD to avoid discussion forking. --Trialpears (talk) 06:43, 4 September 2019 (UTC)

To-do list for task forces?

Hi, is there a way to list the to-do pages for task forces? For example, on the Template:WPUSA? Funandtrvl (talk) 00:14, 27 August 2019 (UTC)

@Funandtrvl: Have you looked at the /todolist hook? But perhaps you are not asking about that. In any case, transcluding large amounts of text of thousands of pages is somewhat discouraged I think, because it can adversely affect page loading times for the benefit of very few editors — Martin (MSGJ · talk) 06:28, 18 September 2019 (UTC)

Portal links not showing?

Looks like the main portal link isn't showing, all banners appear to be affected, e.g. {{WikiProject Japan}}. PC78 (talk) 14:42, 14 September 2019 (UTC)

Was this edit, which I've just undone for now. -- WOSlinker (talk) 16:42, 14 September 2019 (UTC)

It looks like there was an extra pipe in the code. BrownHairedGirl should be slapped with a wet trout for not testing in the sandbox ;) — Martin (MSGJ · talk) 06:25, 18 September 2019 (UTC)

Oops! Sorry, @Martin. Trouting accepted. --BrownHairedGirl (talk) • (contribs) 10:07, 18 September 2019 (UTC)

If there is a need for such a check it would probably be more efficient to put some code on Template:WPBannerMeta rather than in /core. What precipitated that change? — Martin (MSGJ · talk) 11:00, 18 September 2019 (UTC)

Formatting error?

I recently updated the code for {{WikiProject Korea}} and inadvertently placed it in Category:WikiProject banners with formatting errors under code "N". This was caused by the removal of the TF_n_NAME parameters from {{WPBannerMeta/hooks/taskforces}} which I did because the documentation suggests that they are optional and redundant when TF_n_TEXT is also used. Restoring these parameters has fixed the problem but this looks like a false postive to me. PC78 (talk) 13:28, 1 September 2019 (UTC)

@PC78: You shouldn't need to use |TF_n_TEXT= if you are using |TF_n_NAME= and |TF_n_LINK= - when |TF_n_TEXT= is present, it completely overrides |TF_n_LINK=; and largely overrides |TF_n_NAME=, but there are certain parts of the code that rely on |TF_n_NAME= being set even when |TF_n_TEXT= is used. IIRC, using |TF_n_TEXT= is an old method that is retained for legacy reasons; if a template already uses |TF_n_NAME= and |TF_n_LINK=, don't switch it over. --Redrose64 🌹 (talk) 22:14, 1 September 2019 (UTC)

Hmm, the banner was already using |TF_n_TEXT= but removing it might simplify the code somewhat; on the other hand, the ability to define custom text seems useful and is not documented as a legacy feature. The banner appeared to be working fine without those parameters but I might just leave it now it's "fixed". PC78 (talk) 22:26, 1 September 2019 (UTC)

@PC78: Haven't looked in detail yet, but I think the TF NAME parameter is used for the default text when the banners are nested. — Martin (MSGJ · talk) 06:21, 18 September 2019 (UTC)

No, you're thinking of the {{WPBannerMeta/hooks/tfnested}} hook. I ended up making the change anyway, because the meagre benefits of maintaining custom text were outweighed by the simplification of the banner code. PC78 (talk) 10:47, 18 September 2019 (UTC)

You're right, but now I remember why the NAME parameter is mandatory - it is used by PageAssessments — Martin (MSGJ · talk) 10:53, 18 September 2019 (UTC)

The collapsed banner displays |TF_n_NESTED= whether tf hooks are used or not. --Redrose64 🌹 (talk) 14:41, 18 September 2019 (UTC)

Auto assess icon

Could someone please change the following in {{WPBannerMeta/core}}:

|{{WPBannerMeta/note
 |IMAGE=Robot icôn.svg
 |SIZE=30px

to:

|{{WPBannerMeta/note
 |IMAGE=Robot icôn.svg
 |SIZE={{{NOTE_SIZE|}}}

I don't see any reason why the auto assess icon should be handled differently to any other note icon, especially when the rest default to a diferent size. PC78 (talk) 01:00, 18 September 2019 (UTC)

Yes, that makes sense to me too — Martin (MSGJ · talk) 06:23, 18 September 2019 (UTC)

@PC78: please update in sandbox and validate testcases. If there is a missing test case for this condition, please make one and validate. — xaosflux ^Talk 13:49, 18 September 2019 (UTC)

@MSGJ: A little help? :) I've made changes to {{WPBannerMeta/core/sandbox}} and {{WPBannerMeta/sandbox}} and switched {{WikiProject Biography/sandbox}} over to the sandboxed meta... What am I missing? PC78 (talk) 15:37, 18 September 2019 (UTC)

If you tell us where your testcases are, we can look at what is happening. --Redrose64 🌹 (talk) 18:08, 18 September 2019 (UTC)

Ah... looks like it is working with the testcase at User talk:PC78/test banner; what's throwing me is why the change isn't visible at Template:WikiProject Biography/sandbox. PC78 (talk) 18:12, 18 September 2019 (UTC)

Testcases shouldn't be in a sandbox or in user space, they should be in Template: space - but for templates that are only used in a talk space, such as a WikiProject banner, they need to be in Template talk: space. Also, shey should be in a subpage whose name ends /testcases.

If your primary change is going to be made to Template:WikiProject Biography, the testcases should be at Template talk:WikiProject Biography/testcases; and if your primary change is going to be made to Template:WPBannerMeta or Template:WPBannerMeta/core, the testcases should be at Template talk:WPBannerMeta/testcases. More at WP:TESTCASES. --Redrose64 🌹 (talk) 18:57, 18 September 2019 (UTC)

None of that should make the slightest bit of difference... however, see test banner at {{WPBannerMeta/testcases}} and transclusion of test banner at Template talk:WPBannerMeta/testcases. Perhaps I'm being obtuse, but I don't see any other way of testing the code. PC78 (talk) 20:01, 18 September 2019 (UTC)

Tests at Template:WikiProject Biography/testcases check out fine — Martin (MSGJ · talk) 20:25, 18 September 2019 (UTC)

@MSGJ: Why does one from the sandbox have the auto row in a collapsed "More information:" section, whilst the live one has it exposed? Aside from that, does the robot head need to be that big? I thought we usually set the heights of note icons to be consistent. --Redrose64 🌹 (talk) 21:19, 18 September 2019 (UTC)

Cheers Martin, I'd just got there on my own but I see you beat me to it – that's what I get for trying to rush things at work when I should have done it properly at home! @Redrose64: That's exactly what this change will fix, the auto symbol will be handled like all other note icons. As for being collapsed, that depends entirely on the number of notes in the banner and the |COLLAPSED= setting. PC78 (talk) 22:36, 18 September 2019 (UTC)

The testcase at Template:WikiProject Biography/testcases#Auto assess uses exactly the same parameters for live and sandbox, therefore it should have exactly the same number of notes, therefore either both should collapse, or neither should. --Redrose64 🌹 (talk) 22:48, 18 September 2019 (UTC)

The sandboxed version of {{WikiProject Biography}} is not the same as the live version. PC78 (talk) 22:50, 18 September 2019 (UTC)

Yes! We Have No Bananas – Hopefully this constitutes a sufficient test? @Xaosflux: Can you please make this change to {{WPBannerMeta/core}}, assuming there are no further concerns? PC78 (talk) 00:37, 19 September 2019 (UTC)

@Xaosflux: (or someone else) I think we're good to implement this change now. PC78 (talk) 20:18, 23 September 2019 (UTC)

Haven't had time to review this yet - of course anyone else may. I will get to it eventually (always working the PERT queues). — xaosflux ^Talk 00:33, 24 September 2019 (UTC)

 Done @PC78: this has been done. Anyone should revert without consulting with me if this causes an immediate problem. — xaosflux ^Talk 13:01, 24 September 2019 (UTC)

How about adding FP as a class option?

Since it's getting widely used on file pages now, it might be useful to handle Featured pictures gracefully.... Thoughts? Adam Cuerden ^(talk)_{Has about 6.9% of all FPs} 21:39, 18 September 2019 (UTC)

We've got FM already, for Category:FM-Class articles: it can be used by setting |fm=yes inside {{class mask}}. This of course requires either |QUALITY_SCALE=inline or |QUALITY_SCALE=subpage in the {{WPBannerMeta}}. --Redrose64 🌹 (talk) 22:01, 18 September 2019 (UTC)

I think there's a case for renaming it FP-Class since it's used exclusively for Featured Pictures. Maybe that's a discussion for WP:VP though? PC78 (talk) 22:41, 18 September 2019 (UTC)

I would suggest leaving it at FM class just in case Wikipedia:Featured sounds ever gets restarted — Martin (MSGJ · talk) 11:21, 30 September 2019 (UTC)

What does ¬ do?

What does the ¬ character do in this template? Why is it important to use

{{{category|¬}}}

and not

{{{category|}}}

? I am asking because I was having trouble with Category:NA-Class Animals in media articles ( 0 ) depopulating after adding a class subpage to {{WikiProject Animals in media}}. I noticed that the ¬s were missing, added them, and the category emptied. --Nessie (talk) 19:11, 1 October 2019 (UTC)

It helps the template to spot the difference between |category= being present but blank, and being completely absent. --Redrose64 🌹 (talk) 20:13, 1 October 2019 (UTC)

It basically tells that whatever has ¬ in it isn't desired. So

{{{category|¬}}}

means 'don't categorize'. Headbomb {t · c · p · b} 20:14, 1 October 2019 (UTC)

Importance params - undiscussed change

Wugapodes, where was this edit discussed? I don't even see it in the sandbox, so it can't have been tested either. --Redrose64 🌹 (talk) 20:56, 5 May 2020 (UTC)

Nowhere, and it wasn't. Having a single parameter that uses a completely different naming scheme from the rest of the parameters is a horrible design, so—assuming editors will expect a consistent naming scheme—we should at least accept the dominant naming scheme as an option. Seemed pretty obviously uncontroversial. It's an alias, so it doesn't break templates that use the idiosyncratic name for this parameter; I've created a parameter alias before, so I didn't feel the need to test that the software still does aliases the way it always has. — Wug·a·po·des​ 21:14, 5 May 2020 (UTC)

Thanks for starting this discussion Redrose, I have reverted this change. The naming scheme is actually very logical and I see no reason to change it without proper discussion. You will notice that uppercase parameter names are ones defined by the banner template whereas lowercase parameter names are defined at the article level. So the banner templates just pass these through |class={{{class|}}} etc. — Martin (MSGJ · talk) 21:30, 5 May 2020 (UTC)

That's great for developers but incredibly unintuitive for end users who are using the template. I didn't just make the change on a whim, it's a problem I actually ran into while editing. — Wug·a·po·des​ 21:36, 5 May 2020 (UTC)

WPBannerMeta isn't intended for general use, it should only be used within WikiProject banners, where we expect a certain level of competence in the art of template editing. That said, its doc page does give a full list of parameters that if copied and pasted will already be in the correct form. --Redrose64 🌹 (talk) 22:04, 5 May 2020 (UTC)

(edit conflict) It's not "a horrible design", it's a deliberate design. There are two kinds of parameters, distinguished in two parallel ways: by having their names in upper or lower case, and by using underscores or spaces. Those in upper case (with underscores) are configuration parameters, setting characteristics that, regardless of the talk page that the WikiProject banner is used on, do not change themselves - |TF_1_LINK= for the page to link to, |TF_1_NAME= for the text to show for that link, |TF_1_IMAGE= for the image, params for the categories and so on. By contrast, those in lower case (with spaces) are used to pass values through from the individual talk pages: |tf 1= and |tf 1 importance=, etc. Since there are two of these for each task force, your claim "a single parameter that uses a completely different naming scheme from the rest of the parameters" is incorrect.

Please revert your change, sandbox it and obtain consensus. --Redrose64 🌹 (talk) 21:34, 5 May 2020 (UTC)

RfC on parameter alias

Should the tf n importance parameter of {{WPBannerMeta}} accept an alias that makes it consistent with the other TF_N_DESCRIPTION parameter names? — Wug·a·po·des​ 22:14, 5 May 2020 (UTC)

Background

Currently, {{WPBannerMeta}} has some parameters that use ALL_CAPS_UNDERSCORED style, and others that use all lower spaced style. The style difference is due to how the inputs are handled by the meta template. Configuration parameters use the all-caps style, while those passed from the article are in the lowercase style. For wikiprojects that have task forces, this leads to code such as:

|tf 1={{{floridiae|}}}
 |TF_1_LINK           = Wikipedia:Wikiproject Tulips/Task forces/Floridiae
 |TF_1_NAME           = the Floridiae task force
 |TF_1_NESTED         = Floridiae
 |TF_1_TEXT           = 
 |TF_1_IMAGE          = Tulipa florenskyi 4.jpg
 |tf 1 importance={{{floridiae-importance}}}
 |TF_1_ASSESSMENT_CAT = Floridiae articles
 |TF_1_MAIN_CAT       = Floridiae articles

If a template uses TF_1_IMPORTANCE the meta template fails silently. In this edit I added an alias so that the template will accept either tf 1 importance or TF_1_IMPORTANCE, and it was reverted.

Rationale

Allowing either style is more intuitive for editors who create wikiproject banners. While the wider style is consistent, for those maintaining or adding functionality to task force sections of banners, the most obvious parameter name given the data above is TF_1_IMPORTANCE. Should an editor make that assumption, the meta template gives no indication that something is wrong, and the reason why this task force parameter is different from the others is not obvious. Using an alias so that the template accepts either style makes the interface more intuitive and prevents silent errors when an editor assumes the naming scheme is like the other TF_N_DESCRIPTION parameters. The change is backwards compatible, and no existing transclusions will be broken.

— Wug·a·po·des​ 22:14, 5 May 2020 (UTC)

• No please do not. The current naming of the parameters is sensible and logical. Adding additional aliases for parameters which are not even used by article editors is not helpful, may cause confusion and template bloat — Martin (MSGJ · talk) 22:34, 5 May 2020 (UTC)
• Oppose There is no demonstrable need. WikiProject banners are not created frequently, and are sufficiently complex that the documentation should be checked each time - it is bad practice to guess at the name of any parameter. This is why we have provided boilerplates that may be copied and pasted. --Redrose64 🌹 (talk) 22:37, 5 May 2020 (UTC)
• It does seem to me that at least the lower case param should not be in the middle of the all caps params but should rather come after the other lower case param, tf 1 (in the boilerplate). Grouping params by their type makes it less likely to use the wrong naming convention. Galobtter (pingó mió) 23:12, 5 May 2020 (UTC)

  I have no opposition to that. People normally just copy and paste from the boilerplate. — Martin (MSGJ · talk) 11:12, 6 May 2020 (UTC)