Module talk:WikiProject banner/Archive 7

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 ← Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10

Strange thing with project links

There's something odd going on with the project links in this template and its children: when a template links to WikiProject {{{PROJECT}}}, it's showing up in the Whatlinkshere for the article named "PROJECT".

For instance, Template:WikiProject Science Fiction links to Wikipedia:WikiProject Science Fiction, but it also appears in Special:Whatlinkshere/Science Fiction. Another example, Template:WikiProject Health and fitness links to Wikipedia:WikiProject Health and fitness, but it also appears in Special:Whatlinkshere/Health and fitness. (And there is no article Health and fitness, so it ended up being listed for Red Link Recovery, which is how I came to notice.)

I'm not up to wading through the code for this template to figure out what's going on – can somebody look into it? —Paul A (talk) 06:33, 8 July 2009 (UTC)

Well, the science fiction banner has a link to Science Fiction in the banner text which is why it shows up in Special:Whatlinkshere/Science Fiction. For the Health and fitness banner, if no |MAIN_TEXT= or |MAIN_ARTICLE= is specified then the banner code does an ifexists check on the value of the PROJECT parameter to see if that should be linked to or not which is why it's showing up in the Whatlinkshere. I've now set a MAIN_ARTICLE on that banner without any link so Whatlinkshere should clear out in a while. -- WOSlinker (talk) 06:45, 8 July 2009 (UTC)

I see. (Let me try that with another template that's been listed for Red Link Recovery – yes.) Thanks! —Paul A (talk) 08:46, 8 July 2009 (UTC)


...but it doesn't seem to be the reason why Template:WikiProject Amateur radio is appearing on Special:WhatLinksHere/Suomen_Radioamatooriliitto. Any suggestions? —Paul A (talk) 09:01, 9 July 2009 (UTC)

Never mind. It's because it transcludes Wikipedia:WikiProject Amateur radio/To Do List. —Paul A (talk) 09:03, 9 July 2009 (UTC)

SHOW?

The hook {{WPBannerMeta/hooks/priorityscale}} has a SHOW option, but I don't see what it does. I've set it to No, but I didn't see a change. Due to confusion regarding "importance", we're trying to transition to "priority", but would also like to hide the priority if no priority is defined. Morphh (talk) 12:19, 09 July 2009 (UTC)

It's an internal parameter, which shouldn't have been exposed. I'm not sure why you'd want to hide the scale if it's not been set (it automatically hides itself on non-articles, but surely if no priority has been assigned, that's an issue that needs to be resolved?); but you can achieve it with something like this:
|HOOK_ASSESS   = {{#if: {{WPBannerMeta/importance|{{{priority|}}}|{{{class|}}}}}
                   |{{WPBannerMeta/hooks/priorityscale
                      ...
                    }}
                   |{{WPBannerMeta/hooks/cats
                      |category={{{category|¬}}}
                      |cat 1 = yes
                      |CAT_1 = Unknown-priority Tulips articles
                    }}
                 }}
That will display the priority rating if one is set, or just add the category otherwise. Hope this helps, Happy‑melon 12:36, 9 July 2009 (UTC)
Thanks. I'm going to get clarification on what the project wants to do with the hiding as you make a very good point. Perhaps they want to hide it after it is assigned. Editors are getting into too many disputes over the "importance" of an article, so we're trying to make it more apparent that this is only a project priority. Morphh (talk) 12:58, 09 July 2009 (UTC)

qualimpintersect

This quality / importance intersect template {{WPBannerMeta/hooks/qualimpintersect}} does not have the ability to configure it for "Priority". Perhaps someone could fix. Thanks, Morphh (talk) 1:56, 10 July 2009 (UTC)

It does, although the docs don't quite show it. Just set |IMPN=priority -- WOSlinker (talk) 05:36, 10 July 2009 (UTC)
Ok, this worked on the article itself, but for some reason none of the articles are updating the categories. For example, if you go to Talk:Economics, which shows Category:B-Class, Top-priority Economics articles at the bottom, but when you click it, it is not in that category. It's still in the Category:B-Class, Top-importance Economics articles. I've waited approx 24 hours, thinking maybe a bot would move it, but nothing has changed. They only seem to move if someone edits the talk page of the article. Morphh (talk) 11:58, 11 July 2009 (UTC)
You'll just have to wait for the job queue to catch up. Yes, any edit to the page (including a null edit) will force recategorisation. — Martin (MSGJ · talk) 13:30, 11 July 2009 (UTC)

Notes with no text

lens Review /note/sandbox -> /note Using notes without text is a really useful way to add support for conditional categories without using unnecessarily complicated things like /hooks/cats. At the moment, it produces some vertical space. This will fix this. — Martin (MSGJ · talk) 00:00, 23 July 2009 (UTC)

Won't that play havoc with our new collapsing automagic? I can't see anything wrong with the code itself, but I anticipate problems there. (also)Happy‑melon 09:35, 23 July 2009 (UTC)
Yes it will and that's next on my list to try and sort out! — Martin (MSGJ · talk) 10:18, 23 July 2009 (UTC)

lens Review This might work. Some testcases on Template:Fishproject/testcases. — Martin (MSGJ · talk) 21:26, 25 July 2009 (UTC)

and could someone check my code on Template:WPBannerMeta/hooks/collapsed/sandbox as well please. — Martin (MSGJ · talk) 13:47, 26 July 2009 (UTC)
I've check it and it all looks fantastic ! -- WOSlinker (talk) 18:14, 26 July 2009 (UTC)
Thanks for that.  All implemented, hopefully without any problems. — Martin (MSGJ · talk) 23:01, 26 July 2009 (UTC)

One of the supposed improvements to /collapsed was that the text indentation would be consistent (it now uses IMAGE_LEFT_SIZE). However, when I put a ruler on my monitor, it seems to be a pixel or two out. I assume this is because the inner table has some padding. Is there a hack for this that will work on all browsers? If not it doesn't matter because it's pretty hard to tell they're not aligned. — Martin (MSGJ · talk) 10:14, 27 July 2009 (UTC)

Auto creation of "Foo" articles by quality error

When the template creates "Foo" articles by quality, it uses {{catmore1}}, but that template requires the page name to be surrounded by double square brackets to make a link, and when it creates the fill-in, the double square brackets are not there, so many times I've seen a dead link for the catmore line on those Foo articles by category categories. Is there a way to fix this? --Funandtrvl (talk) 07:02, 23 July 2009 (UTC)

Not quite sure what you mean. It's Template:WPBannerMeta/templatepage/qualheader which passes the square brackets to catmore1. Can you give an example of it not working? — Martin (MSGJ · talk) 07:58, 23 July 2009 (UTC)
Yes, when you click on a red-linked category, like: Category:Travel and Tourism articles by quality, then the following code displays, note the first line, it doesn't display the double "[" and "]" brackets after the pipe link:
{{catmore1|Wikipedia:WikiProject **PROJECT**}}
[[Category:WikiProject **PROJECT**]]
[[Category:Wikipedia 1.0 assessments]]
Is there a way to make it display like below, so the 'catmore' template will actually work and not just be a dead link that is in bold text? (I've seen many instances where editors just filled in the "Project" word & didn't realize it needed double brackets or else it would be a dead link):
{{catmore1|[[Wikipedia:WikiProject **PROJECT**]]}}<!-- NOTE THE DOUBLE '[' BRACKETS -->

--Funandtrvl (talk) 08:20, 23 July 2009 (UTC)

Another note, you need to click the red-linked T & T articles by quality cat from this page: Template:TourismProject/sandbox --Funandtrvl (talk) 08:23, 23 July 2009 (UTC)
That was an issue in Template:WPBannerMeta/templatepage/preloadmeta. Now  Fixed — Martin (MSGJ · talk) 08:28, 23 July 2009 (UTC)
Thanks for fixing it! --Funandtrvl (talk) 19:40, 23 July 2009 (UTC)

Customized comments

Hey, can someone help me with Template:WikiProject Lithuania? There used to be a customized comment section, which does not go onto subpage, but directly into template. It was mostly used for signatures of reviewer. I cannot figure out how to make it work with the meta banner. Help? Renata (talk)

I've added a note on the banner for it (example on /testcases). However you also have the subpage feature enabled - do you need this as well? .... — Martin (MSGJ · talk) 07:24, 26 July 2009 (UTC)
Great! Thank you. No, the subpage feature was not needed -- I deleted it. Renata (talk) 00:33, 30 July 2009 (UTC)

Question about td

Is there any reason to use the {{td}} template in WPBannerMeta/core rather than just using the contents of the td template directly? -- WOSlinker (talk) 12:45, 24 July 2009 (UTC)

No, especially not now the styles can be applied through CSS (mbox-empty-cell, which I need to apply on {{td}}, actually). (also)Happy‑melon 13:10, 24 July 2009 (UTC)
Would get rid of 2,000,000 transclusions if the 3 occurrences were replaced. -- WOSlinker (talk) 17:08, 24 July 2009 (UTC)
 Done Happy‑melon

Could the two {{td}}s in Template:WPBannerMeta/bchecklist be changed as well? Thanks. -- WOSlinker (talk) 15:03, 1 August 2009 (UTC)

 Done I was wondering why the transclusion count was still sky-high. Any more? Happy‑melon 22:34, 1 August 2009 (UTC)
None I can see in the WPBannerMeta templates but there are some in other templates & I've already put in a few {{editprotected}} requests for those. -- WOSlinker (talk) 22:51, 1 August 2009 (UTC)

Template:WikiProject Central America

Please see the sandbox for the above template, the TFs are redirects to the WPs, and there were no nested parameters, so I've added that to the sandbox version. Please update the code for us. Thanks --Funandtrvl (talk) 21:57, 3 August 2009 (UTC)

Task force naming and categorization

I'm trying to convert WikiProject LA into one of the task forces of Category:WikiProject California articles and have a minor issue with the category naming on the Category:WikiProject Los Angeles articles by quality. The articles all have the WikiProject prefix in front of them and wanted to drop that on the rename. Can somebody take a look at my last edit to Template:WikiProject California/sandbox and make sure that it will rename Category:B-Class WikiProject Los Angeles articles → Category:B-Class Los Angeles articles, etc. Also does anyone know any adjustments will be needed for User:WP 1.0 bot to get the statistics correctly. -Optigan13 (talk) 05:52, 29 July 2009 (UTC)

Yes, that looks fine. As long as you put them in Category:Wikipedia 1.0 assessments the bot should find them. You might like to use this version which prompts you for the categories which need creating. — Martin (MSGJ · talk) 07:14, 29 July 2009 (UTC)
Thanks, I think I've pulled it off, but can you double check my work at both the template and at the task forces of Category:WikiProject California. I want to make sure before I fire off a bot request to replace the templates. The 1.0 assessment fired correctly for Los Angeles. As long as Foo by quality and Foo by importance have the WP 1.0 category that it will work, right? -Optigan13 (talk) 02:28, 5 August 2009 (UTC)
Everything looks fine to me. — Martin (MSGJ · talk) 10:42, 5 August 2009 (UTC)

Comments page TOC issue

This problem was brought up at Template_talk:WPAVIATION#Comment_subpage and can be viewed at Talk:UH-1_Iroquois. If the comment page included a header, the whole talk page toc is also embedded into the banner. Can this be fixed? - Trevor MacInnis contribs 02:21, 11 August 2009 (UTC)

Not in the banner code as far as I'm aware. The way to fix it is to add __TOC__ below all the banners on the affected talk pages. -- WOSlinker (talk) 06:36, 11 August 2009 (UTC)

B-class checklist help

I've noticed that Template:WPAVIATION no longer displays the text showing how to add the b-class checklist (see:Talk:Bahrain International Airport). Is this an error? I'd like to get it back. - Trevor MacInnis contribs 18:44, 8 August 2009 (UTC)

To fix it, in Template:WPBannerMeta/core, the following code should be changed to pass through the BANNER_NAME parameter:
{{#if:{{{B_CHECKLIST|}}}|{{WPBannerMeta/bchecklist
  |class={{{class|}}}
  |b1={{lc:{{{b1|}}}}}
  |b2={{lc:{{{b2|}}}}}
  |b3={{lc:{{{b3|}}}}}
  |b4={{lc:{{{b4|}}}}}
  |b5={{lc:{{{b5|}}}}}
  |b6={{lc:{{{b6|}}}}}
  |ASSESSMENT_LINK={{{ASSESSMENT_LINK|}}} }}

to 

{{#if:{{{B_CHECKLIST|}}}|{{WPBannerMeta/bchecklist
  |BANNER_NAME={{{BANNER_NAME}}}
  |class={{{class|}}}
  |b1={{lc:{{{b1|}}}}}
  |b2={{lc:{{{b2|}}}}}
  |b3={{lc:{{{b3|}}}}}
  |b4={{lc:{{{b4|}}}}}
  |b5={{lc:{{{b5|}}}}}
  |b6={{lc:{{{b6|}}}}}
  |ASSESSMENT_LINK={{{ASSESSMENT_LINK|}}} }}

-- WOSlinker (talk) 20:12, 8 August 2009 (UTC)

Will that work for WPAVIATION, which only has 5 b-class parameters? - Trevor MacInnis contribs 20:20, 8 August 2009 (UTC)
Should do but I haven't been able to fully test. If you look at Template:WPBannerMeta/bchecklist, you'll see that it uses the BANNER_NAME parameter but Template:WPBannerMeta/core isn't passing that parameter through. WPAVIATION uses a custom class template at Template:WPAVIATION/class which handles that part, but since BANNER_NAME is not being passed through to Template:WPBannerMeta/bchecklist it is looking at Template:WPBannerMeta/class instead of Template:WPAVIATION/class. -- WOSlinker (talk) 20:38, 8 August 2009 (UTC)

{{editrequest}}

Sounds good, but I don't know enough about the template and its various subpages to do this edit myself. Can someone more familiar with its workings do it? - Trevor MacInnis contribs 02:23, 11 August 2009 (UTC)
 Done and seems to be working. —TheDJ (talk • contribs) 11:35, 11 August 2009 (UTC)

Hmm, was this an error of mine? I thought I/we had tested this one thoroughly before changing it ... — Martin (MSGJ · talk) 15:46, 14 August 2009 (UTC)

Somehow it got removed in this edit. — Martin (MSGJ · talk) 16:14, 14 August 2009 (UTC)

Suggestions for A-Class and Peer Review hooks

A few minor suggestions to make these two hooks more visually consistant... 

   |TEXT     = This article '''[[{{{SUBPAGE_LINK}}}|is undergoing]]''' an [[{{{REVIEW_LINK}}}|A-Class review]].

...

   |TEXT     = This article '''[[{{{SUBPAGE_LINK}}}|{{#switch:{{lc:{{{a class|}}}}}|pass=has passed|fail=has failed|current=is undergoing}}]]''' an [[{{{REVIEW_LINK|}}}|A-Class review]].

to: 

   |TEXT     = This article '''[[{{{SUBPAGE_LINK}}}|is currently undergoing]]''' an [[{{{REVIEW_LINK}}}|A-Class review]].

...

   |TEXT     = This article '''[[{{{SUBPAGE_LINK}}}|{{#switch:{{lc:{{{a class|}}}}}|pass=has passed|fail=has failed|current=is currently undergoing}}]]''' an [[{{{REVIEW_LINK|}}}|A-Class review]].

This one is just an idea, but why not use the different icons for current/pass/fail, e.g. 

   |IMAGE    = {{#if:{{{IMAGE|}}}|{{{IMAGE}}}|{{#switch:{{lc:{{{a class|}}}}}|pass=Symbol a class|fail=Symbol unsupport A vote|current=A candidate}}.svg}}

|TEXT  = This {{#if:{{SUBJECTSPACE}}|page|article}} is [[{{{LINK}}}/{{SUBJECTPAGENAME}}|currently]] being [[{{{LINK|}}}|peer reviewed]].

...

|TEXT  = This {{#if:{{SUBJECTSPACE}}|page|article}} has had a [[{{{LINK}}}|peer review]] which is now [[{{{LINK}}}/{{SUBJECTPAGENAME}}|archived]].

...

|TEXT  = This {{#ifeq:{{{class|}}}|NA|page|article}} is [[{{{LINK}}}/{{SUBJECTPAGENAME:{{#if:{{{title|}}}|{{{title}}}|{{FULLPAGENAME}}}}}}|currently]] being [[{{{LINK|}}}|peer reviewed]].

...

|TEXT  = This {{#ifeq:{{{class|}}}|NA|page|article}} has had a [[{{{LINK}}}|peer review]] which is now [[{{{LINK}}}/{{SUBJECTPAGENAME:{{#if:{{{title|}}}|{{{title}}}|{{FULLPAGENAME}}}}}}|archived]].

to: 

|TEXT  = This {{#if:{{SUBJECTSPACE}}|page|article}} '''[[{{{LINK}}}/{{SUBJECTPAGENAME}}|is currently undergoing]]''' a [[{{{LINK|}}}|peer review]].

...

|TEXT  = This {{#if:{{SUBJECTSPACE}}|page|article}} has had a [[{{{LINK}}}|peer review]] which is '''[[{{{LINK}}}/{{SUBJECTPAGENAME}}|now archived]]'''.

...

|TEXT  = This {{#ifeq:{{{class|}}}|NA|page|article}} '''[[{{{LINK}}}/{{SUBJECTPAGENAME:{{#if:{{{title|}}}|{{{title}}}|{{FULLPAGENAME}}}}}}|is currently undergoing]]''' a [[{{{LINK|}}}|peer review]].

...

|TEXT  = This {{#ifeq:{{{class|}}}|NA|page|article}} has had a [[{{{LINK}}}|peer review]] which is '''[[{{{LINK}}}/{{SUBJECTPAGENAME:{{#if:{{{title|}}}|{{{title}}}|{{FULLPAGENAME}}}}}}|now archived]]'''.

Also (I've mentioned this elsewhere) add a |SIZE= parameter as per the A-Class hook by changing all instances of: 

|SIZE  = 30px

to: 

|SIZE  = {{#if:{{{SIZE|}}}|{{{SIZE}}}|30px}}

Thoughts? PC78 (talk) 23:01, 27 July 2009 (UTC)

The {{#ifeq:{{{class|}}}|NA|page|article}} part of the peerreview template should be changed to {{pagetype}} as class isn't even a parameter in the peerreview template. -- WOSlinker (talk) 06:37, 28 July 2009 (UTC)

 Done I like all of these suggestions. Happy‑melon 11:00, 28 July 2009 (UTC)

Thanks! Not sure if it was intentional or not, but you missed the bold text in the peer review hook... ;) PC78 (talk) 21:17, 28 July 2009 (UTC)
It was accidental, but I'm not sure which I prefer. {{ChicagoWikiProject}} has both in play; what do people think? Happy‑melon 21:28, 28 July 2009 (UTC)
I don't mind terribly whether you opt for bolded or unbolded text, I just think it should be consistant across the two hooks. But personally I would say the bold because it highlights the most relevant link. PC78 (talk) 22:02, 28 July 2009 (UTC)

*bumped out of archive* If there is no objection here can we get this finished up and make these two hooks consistant on their use of bolded text? PC78 (talk) 16:25, 14 August 2009 (UTC)

 Done — Martin (MSGJ · talk) 21:09, 14 August 2009 (UTC)

Placing notes into the banner

I noticed there is code to add a link to a page of notes, but what if I want to just have the ability to put {{Template}} and have the text "There are notes on improving this article: Needs references" appear below the quality/importance. Is this possible? - ʄɭoʏɗiaɲ τ ¢ 18:52, 23 August 2009 (UTC)

Of course. Is this a to-do list or something? — Martin (MSGJ · talk) 19:01, 23 August 2009 (UTC)
No just on an individual article basis. My "needs references" was just an example of what I could type in. Basically having notes="blah blah blah" as a parameter would make "blah blah blah" appear in the template. Sorry if I'm confusing, I don't even know how to word something like this. I don't want a predetermined list of notes to call upon, but rather the ability to add a note individually to each article (if that makes sense) - ʄɭoʏɗiaɲ τ ¢ 19:43, 23 August 2009 (UTC)
I'm guess, looking at your contributions, that you are talking about the progressive rock template? I've put some possible code in the template sandbox. So for example {{WikiProject Progressive Rock|class=C|note=needs references}} would produce:
WikiProject iconProgressive Rock
WikiProject iconThis article is within the scope of WikiProject Progressive Rock, a collaborative effort to improve the coverage of Progressive rock on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Progressive RockWikipedia:WikiProject Progressive RockTemplate:WikiProject Progressive RockProgressive rock articles
Note icon
The following has been noted regarding this article: needs references
Is this what you had in mind? If not you might be able to work out how to tweak the code. — Martin (MSGJ · talk) 19:52, 23 August 2009 (UTC)
Thats exactly it :) Thank you once again for your awesome template knowledge Martin!.. If-then conditionals in wiki syntax are really strange. - ʄɭoʏɗiaɲ τ ¢ 20:22, 23 August 2009 (UTC)
Great, another satisfied customer. You're welcome :) — Martin (MSGJ · talk) 20:30, 23 August 2009 (UTC)

Question regarding task forces

Is it possible to set up the banner in such a way that an article can be assessed for two different work groups while displaying only the name, etc., of one work group? John Carter (talk) 15:58, 25 August 2009 (UTC)

Sure. Tell me which banner and work group you have in mind? — Martin (MSGJ · talk) 23:00, 25 August 2009 (UTC)

Feature request for A-Class hook

The coding for A-Class review in a number of non-meta project banners (specifically {{WPBiography}}, {{Film}} and {{WPMILHIST}}) includes a number of checks to ensure that articles are tagged correctly. To facilitate the conversion of {{WPBiography}} (and perhaps in time those other two) I would like to request that the necessary support for this feature be added to the A-Class hook here.

I've prepared some code at {{WPBannerMeta/hooks/aclass/sandbox}} and tested it with {{WPBiography/sandbox}}. This adds two one optional parameters to the existing hook:

  • |CHECK_SUBPAGE= which should be set to "yes" to perform an ifexist check for {{{SUBPAGE_LINK}}}, and
  • |INVALID_CAT= which both activates the check and sets the category for incorrectly tagged articles.

What this does:

  • If |a class= is set to pass/fail/current but a review subpage does not exist, then {{{PASS_CAT}}}, {{{FAIL_CAT}}} and {{{CURRENT_CAT}}} will be ignored in favour of {{{INVALID_CAT}}}.
  • If |a class= is not set but a review subpage exists, then an article is added to {{{INVALID_CAT}}}.

Thoughts on the above? PC78 (talk) 23:52, 26 August 2009 (UTC)

Support in principle. Last feature is unlikely to work because the hook is not even called if the parameter is not defined. — Martin (MSGJ · talk) 06:19, 27 August 2009 (UTC)
I think this stuff ought to just be enabled by default. No need to have to specifically request it. Certainly it should be done if |INVALID_CAT= is defined. (also)Happy‑melon 11:02, 27 August 2009 (UTC)
Good call, I've removed |CHECK_SUBPAGE= and the checks are now enabled if |INVALID_CAT= is defined. The last feature seems to work fine in the testing I've done. You guys should of course check over the code I've written, though. :) PC78 (talk) 17:44, 27 August 2009 (UTC)
Looks ok to me. -- WOSlinker (talk) 19:47, 27 August 2009 (UTC)
lens Review I tweaked the code a little to remove redundancy: can you confirm that it still does what it should? AFAICT it does... Happy‑melon 19:46, 29 August 2009 (UTC)
Hmmm, for the most part yes. However, if I preview {{WPBiography/sandbox|A-Class=pass}} at Talk:Milla Jovovich it tries to add the page to Category:Wikipedia:WikiProject Biography/A-class review/Milla Jovovich. PC78 (talk) 00:13, 30 August 2009 (UTC)
Ah-ha, you inadvertantly replaced PASS_CAT with SUBPAGE_LINK. Fixed, and does indeed work as intended. PC78 (talk) 11:24, 30 August 2009 (UTC)
Lol oops! Anything else? Happy‑melon 12:48, 30 August 2009 (UTC)
No, I think we're good here. :) PC78 (talk) 13:38, 30 August 2009 (UTC)

...and for Peer Review

For the same reasons I've added the same feature to {{WPBannerMeta/hooks/peerreview/sandbox}}; again this will need someone to check over it, but it appears to work OK. Incidentally, this would be required for {{Comicsproj}} if anyone is still working on converting it. PC78 (talk) 18:37, 29 August 2009 (UTC)

lens Review I made similar changes to the logic in that one. Do they work? Happy‑melon 13:45, 30 August 2009 (UTC)
No, the last check isn't adding to INVALID_CAT if the parameter is used and a review subpage exists. PC78 (talk) 14:13, 30 August 2009 (UTC)
Oh, I see what the point of that check is; I thought it was redundant at first, then went barking up the wrong tree (and left in some triple logical negation, which didn't help!). Fixed? Happy‑melon 15:36, 30 August 2009 (UTC)
No. You fixed the last problem, but now it's not adding to INVALID_CAT if the parameter is used and the review subpage doesn't exist. (Just noticed I said "is" when I meant "isn't" in my last comment. Sorry if that caused any confusion!) PC78 (talk) 16:18, 30 August 2009 (UTC)

Just to clarify how the checks are supposed to work in case I've muddied the waters:

  • If |peer review=yes and review page exists, add to CAT
  • If |old peer review=yes and review page exists, add to OLD_CAT
  • If |peer review= or |old peer review= are unused (or set to "no" etc.) and review page exists, add to INVALID_CAT
  • If |peer review=yes or |old peer review=yes and review page does not exist, add to INVALID_CAT

-- PC78 (talk) 16:22, 30 August 2009 (UTC)

Hehe, you made me break one check to fix another! Nm, we can do that easily enough: xor is my favourite logical statement, after all :D Yay! First smiley after coming back! How does that look? Happy‑melon 16:40, 30 August 2009 (UTC)
Argh, now I'm not getting INVALID_CAT at all! ;) PC78 (talk) 16:59, 30 August 2009 (UTC)
Where are you testing these? It's rather lazy of me to expect you to do all my debugging :D Happy‑melon 17:37, 30 August 2009 (UTC)
{{WPBiography/sandbox}} is rigged up with the sandboxed meta code. I don't have any tests saved anywhere. Typically I test the banner on a page like Talk:qhekwqjehj by previewing without saving, and on Talk:Jada Pinkett Smith for an example of an article with a peer review. :) PC78 (talk) 18:18, 30 August 2009 (UTC)
Fixed I believe (just a missing |). However it might be preferable to use CAT and OLD_CAT regardless of whether INVALID_CAT is used. For example, it is quite possible that the |peer review= parameter is to the template before creating the subpage for it. Due to the nature of categorising pages by template it would then be necessary to make another edit to the talk page before the category was updated. — Martin (MSGJ · talk) 10:14, 2 September 2009 (UTC)
I've just done a quick test; it's currently working in the manner you suggest, I'm not sure if that was intentional or not. It's possibly a good idea though, I was just going by how these things are currently coded elsewhere. PC78 (talk) 10:36, 2 September 2009 (UTC)
Okay, shall I do the same thing with the A-class hook then and keep it consistent? — Martin (MSGJ · talk) 11:06, 2 September 2009 (UTC)
Sure, why not. :) PC78 (talk) 11:11, 2 September 2009 (UTC)
Could you have a final check of these two sandboxes again please and then I'll implement them. — Martin (MSGJ · talk) 11:51, 2 September 2009 (UTC)
Both of them are fine. :) PC78 (talk) 13:03, 2 September 2009 (UTC)
 Both implemented — Martin (MSGJ · talk) 13:47, 2 September 2009 (UTC)

More thoughts on peer review

May as well post these here while we're on the subject. :)

  • Not that I mind as long as it works, but why is the review subpage defined as {{{LINK}}}/{{SUBJECTPAGENAME:{{#if:{{{title|}}}|{{{title}}}|{{FULLPAGENAME}}}}}} as opposed to {{{LINK}}}/{{#if:{{{title|}}}|{{{title}}}|{{{PAGENAME}}}}}
  • Would it be better to use File:Searchtool.svg as the default icon? I'm thinking it would be more visually consistant with File:Bclass-checklist.svg. PC78 (talk) 13:03, 2 September 2009 (UTC)
  • I believe that these equalities always hold so it makes little difference. It's only because of a quirk that we need it at all.
    {{SUBJECTPAGENAME}} = {{SUBJECTPAGENAME:{{PAGENAME}}}} = {{SUBJECTPAGENAME:{{FULLPAGENAME}}}}
  • No strong opinion. — Martin (MSGJ · talk) 13:47, 2 September 2009 (UTC)

Default image sizes

Hi - Are the default image sizes 40px & 80px now? What are the default sizes for the TF link images? Please update the doc page under simple options and task forces, if the values have changed. Thanks --Funandtrvl (talk) 06:05, 9 September 2009 (UTC)

I've done it (but why didn't you just fix it?). The taskforce picture still defaults to 30. — Martin (MSGJ · talk) 10:34, 9 September 2009 (UTC)

Support for priority

For projects using "priority" instead of "importance" it is necessary to set |IMPORTANCE_SCALE_NAME=priority in {{WPBannerMeta/hooks/priorityscale}} to ensure that categories are named correctly. However, if the project uses task forces with priority ratings, the categories appear to use "importance" regardless. As far as I can tell, this is because neither {{WPBannerMeta/core}} or {{WPBannerMeta/hooks/taskforces/core}} have an option to set |IMPN= when transcluding {{WPBannerMeta/taskforce}}. Assuming I'm right, can the necessary parameters be added? PC78 (talk) 01:50, 29 August 2009 (UTC)

OK, I've run a quick test by adding |IMPN={{{IMPORTANCE_SCALE_NAME|}}} to {{WPBannerMeta/core/sandbox}} and |IMPORTANCE_SCALE_NAME={{{IMPORTANCE_SCALE_NAME|}}} to {{WPBannerMeta/sandbox}}. It seems fairly straightforward and has the desired effect. Can this change be implemented? PC78 (talk) 14:33, 29 August 2009 (UTC)
The Template:WPBannerMeta/hooks/taskforces should have a IMPORTANCE_SCALE_NAME option but it doesn't. That needs fixing. -- WOSlinker (talk) 14:52, 29 August 2009 (UTC)

I've been tinkering in the sandbox and have made all the changes necessary (that I can see) to fix this issue and (assuming there are no objections) implement my request below. Can someone please review the changes I have made at the following templates:

As an aside, can anyone tell me why {{WPBannerMeta}} supports ten task forces when {{WPBannerMeta/core}} only defines five? PC78 (talk) 19:57, 29 August 2009 (UTC)

What's with the |TF_1_HOOK_CAT= parameters??
WRT your last point, ask Martin; he added them IIRC. Something to do with /templatepage? Happy‑melon 20:57, 29 August 2009 (UTC)
See below for |HOOK_CAT=. ;) FWIW I think it would be a good move to increase the number of task forces in the main banner code to ten. PC78 (talk) 07:30, 30 August 2009 (UTC)
Then I would use the format |HOOK_TF_1_CAT=, to clarify that it's a hook. Although I'm still not 100% sure that it's necessary... Happy‑melon 09:28, 30 August 2009 (UTC)
I merely named it after the existing TF parameters; I don't know about greater clarity, but I'm unconcerned about how they are named. This is more about usefulness rather than necessity, though I do think it allows for a better way of doing things. PC78 (talk) 10:05, 30 August 2009 (UTC)

Yes TF6-10 were added for the convenience of those constructing banner templates. They will give the category prompts on /templatepage but will not operate in any other way. I would support increasing the number of taskforces supported by the main banner to 10. — Martin (MSGJ · talk) 09:23, 2 September 2009 (UTC)

This discussion is getting derailed somewhat (largely my own fault). Can the required fix for IMPORTANCE_SCALE_NAME be implemented? PC78 (talk) 10:28, 2 September 2009 (UTC)
Yes, you've been mixing two different requests I think. Supporting a custom IMPN in the main banner would be quite a big change, but would have with several advantages. I guess one of the disadvantages is that it could be seen as encouraging each project to have a different name for their importance scale, which is anti-standardisation. Overall though I think this might be a good idea. — Martin (MSGJ · talk) 10:53, 2 September 2009 (UTC)

For information, apart from all the biography workgroups, the following projects use "priority". — Martin (MSGJ · talk) 11:00, 2 September 2009 (UTC)

  • British royalty
  • Economics
  • Kingdom of Naples
  • mathematics
  • Sheffield
  • Sicily
  • Spooks
  • Square Enix
  • strategy game
  • taxation
  • WikiProject Business
I'm not entirely sure I follow. It's necessary in the main banner so that the task forces can use the custom name (i.e. priority), but it doesn't do anything else. Defining the parameter in the main banner without using task forces doesn't do anything, you still need the priority hook for that. I don't share your anti-standardisation concerns, though I don't see how this change would increase them. However, if necessary I assume it would be possible to recode the meta so that priority was the only valid alternative to importance? I'm certainly not aware of any projects using anything else. PC78 (talk) 11:10, 2 September 2009 (UTC)
Currently the projects above have to hook Template:WPBannerMeta/hooks/priorityscale onto HOOK_ASSESS or similar in order to get their priority scale. Adding an IMPN option would allow this to be implemented more easily by just using something like:
|importance={{{priority|}}}
|IMPN=priority
Now, as for taskforces, out of the list above only Business has any and that one doesn't use priority, so it wouldn't affect any of them. — Martin (MSGJ · talk) 14:04, 2 September 2009 (UTC)
I'm still not entirely with you there. So far as I can see, you would still need to define |importance= and |IMPORTANCE_SCALE_NAME= in {{WPBannerMeta/hooks/priorityscale}}, so the extra parameter in the main banner would offer no advantage in that respect. Likewise, if a banner didn't use the priorityscale hook or task forces, then the parameter wouldn't do anything.
Granted, this isn't a problem that affects any existing uses of the meta. However, is it not logical that if a banner is set to use priority as opposed to importance, then you need some way of passing that onto the task forces? In that respect I'm still inclined to view this as a bug. As with my other recent requests here, this is something that will facilitate the conversion of {{WPBiography}}. PC78 (talk) 22:54, 2 September 2009 (UTC)
Sorry for my lack of clarity. What I'm saying is this. If we added the IMPN option to the main template, then the projects listed above would no longer need to use the /priorityscale hook as it could be done by the main template. And yes, I guess it makes sense for taskforces to use the same scale-name as their parent project by default. So I suppose I am supporting this proposal. What do others think? — Martin (MSGJ · talk) 12:45, 3 September 2009 (UTC)
OK, now I'm with you. :) Is that basically all the hook does then? PC78 (talk) 12:50, 3 September 2009 (UTC)
Yes, /qualityscale just calls Template:WPBannerMeta/importancescale with a custom value of IMPN. — Martin (MSGJ · talk) 13:21, 3 September 2009 (UTC)

Given that there are exactly two importancescale terms being used, |importance= and |priority=, do you think we should admit defeat and build the "priority" version into the main banner? That is, passing the |priority= parameter instead of the |importance= parameter makes that switch automagically? It would probably be easier to clean up this issue if we did that. Happy‑melon 14:15, 3 September 2009 (UTC)

That's an interesting idea, and would avoid the need to define an extra parameter. The only consideration is that maths use Priority with a capital P, but that could be changed if they ever convert ... So I suppose we can use some code like the following on Template:WPBannerMeta? — Martin (MSGJ · talk) 15:27, 3 September 2009 (UTC)
|importance={{{importance|{{{priority|¬}}}}}}
|IMPN={{#if:{{{importance|}}}|importance|priority}}

Code review

lens Review Would anyone care to check my changes to the following pages?

There is also the /templatepage stuff:

(This stuff isn't working fully yet. It will correctly deduce the priority, but it won't use {{cat priority}} instead of {{cat importance}} yet. Hmm.)

There are some examples:

Thanks, — Martin (MSGJ · talk) 13:28, 4 September 2009 (UTC)

I think the change in layout on /core/sandbox was necessary, but it does make for a very messy diff. Looks ok though. I don't think it's a good idea to expose |IMPN= on WPBM, though: it destroys our Zero One Two Inifinity rule on scale names, isn't necessary AFAICT given that there are only two scales in use, and is going to make life even more difficult on /templatepage... Is there a reason to expose it?
I'm not surprised the /templatepage stuff isn't working; the substitution stuff desperately needs string functions. I once tried adding optional subst to {{str sub}}, it was a complete disaster :D Happy‑melon 09:34, 7 September 2009 (UTC)
I think it is necessary to expose it. (You'll notice it was added as an after-thought.) The main reason for supporting this is to aid the conversion of WPBiography, and they use priority for their taskforces but do not have an "overall" priority scale. The only way to do this (I think) is to pass IMPN but not to pass importance or priority. — Martin (MSGJ · talk) 09:44, 7 September 2009 (UTC)
You could get around that issue by only using the hooks to add taskforces for WPBiography. -- WOSlinker (talk) 10:06, 7 September 2009 (UTC)
Or apply the same switching logic independently to each tf, and have WPBio use |tf 1 priority=, etc. I don't know if there are any banners (presumably not now that there are so few left) that have mixed importance/priority scales, but we could support them if we did it that way. Happy‑melon 11:46, 7 September 2009 (UTC)
Isn't that overcomplication? It might be a good method if there were likely to be any uses of mixed importance/priority. I don't think I've ever come across this. — Martin (MSGJ · talk) 12:14, 7 September 2009 (UTC)
The only banner I've seen with both is Template:Christianmusic -- WOSlinker (talk) 12:25, 7 September 2009 (UTC)
Could do. A bit of a shame that the largest potential user of this feature won't be able to use it though :( — Martin (MSGJ · talk) 12:14, 7 September 2009 (UTC)

To help us towards closure of this little discussion, my thoughts are as follows:

  • I don't really want to add separate importance/priority parameters for each taskforce. This would add to the complexity with very little benefit. It's reasonable that a project that wants mixed ratings, e.g. Christian music, should need to use a hook.
  • I accept that this will then be inconsistent with the use of the main importance/priority parameters.
  • I personally can't see the harm in allowing IMPN to be set from project banners, but if you two think that's a "bad idea" then I don't mind disabling it.
  • WPBiography taskforces are now all hooked, so this issue won't affect them at all.

— Martin (MSGJ · talk) 08:11, 8 September 2009 (UTC)

 All done. I even remembered to remove /sandbox from the code this time :) — Martin (MSGJ · talk) 22:10, 8 September 2009 (UTC)
Well you're certainly doing better than me :D Looks nice... Happy‑melon 22:17, 9 September 2009 (UTC)
Aww, is that the equivalent of being rolled back? — Martin (MSGJ · talk) 07:23, 10 September 2009 (UTC)
Yeah, essentially; Brion said to work it up in a branch so any creases could be ironed out. Essentially I broke the login form on translatewiki for 12 hours; people had to log in using the API because the regular login form just looped the cookie check ad infinitum... :S Happy‑melon 08:59, 10 September 2009 (UTC)

SMALL_TEXT?

Any thoughts on adding a |SMALL_TEXT= parameter to the main banner? It might help encourage projects using |MAIN_TEXT= to add more concise wording for small banners, and for those that already do it would eliminate the need to use parser functions in |MAIN_TEXT=. Just an idea. PC78 (talk) 14:33, 11 September 2009 (UTC)

Last discussed here. If this option was used widely, then it would be a good idea. But it's hardly used at all I think. — Martin (MSGJ · talk) 18:03, 11 September 2009 (UTC)
A whopping 0.02% of banners, in fact. I hate the small parameter, and the small tmbox style in general (as opposed to the small ambox, which I think is adorably cute :D). I remember having a cleanout of that category once, and found a lot of 'small' banners also inside shells; so many that I tweaked the tmbox CSS to ensure that the nesting automagic overrides the small parameter. I just ran a Toolserver DB query: 141 of those 513 pages also transclude {{WikiProjectBannerShell}}. So some of those 'small' banners could actually not be small at all... Happy‑melon 21:15, 11 September 2009 (UTC)

Listy. Sorry for the text explosion, can't think of a better place to put it... Happy‑melon 21:46, 11 September 2009 (UTC)

Pages which contain a WPBM banner with |small=yes and {{WikiProjectBannerShell}}

Ah well. I'll get my coat... :) PC78 (talk) 00:08, 12 September 2009 (UTC)

Quite a few on that list have a {{FAOL}} or {{Talk Spoken Wikipedia}} with the small=yes parameter outside of the {{WikiProjectBannerShell}} though. -- WOSlinker (talk) 09:42, 12 September 2009 (UTC)

Auto=yes is a bit intrusive

It claims to be a "small notice" per the doc but it's actually quite big. When more than one project has auto-assessed, it tends to embiggen the talk page top business quite substantially (e.g.) What about having "auto=yes" make a change to the assessment line? Something like...

This article has been automatically assessed and rated as Stub-Class on the project's quality scale. [FAQ]
If you disagree with the assessment, please re-rate and remove the auto=yes parameter. Please also remove the auto=yes parameter if you agree.

Thoughts? –xenotalk 14:03, 26 July 2009 (UTC)

I agree, I've always found it too big. I would also keep the message as short as possible. Something like "Automatically assessed as [link|Stub-Class] on the [link|quality scale]. Please remove the |auto=yes parameter from the banner, and [link|re-assess] if needed." Headbomb {ταλκκοντριβς – WP Physics} 14:23, 26 July 2009 (UTC)
Certainly I'd have no problem losing the 'separate box' concept; the accessibility issues in the fact that the display is duplicated and hidden with CSS has always concerned me. At the least, I'd like to make it always display in 'note' format within the banner. Happy‑melon 15:33, 26 July 2009 (UTC)
Yep, that's even better. Hows this:

"This article has been [[WP:Automatic assessment|automatically assessed]] as [link|XX-Class] on the [link|quality scale]. Please remove the |auto=yes parameter from the banner, and [link|re-assess] if needed."

(I've just penned WP:Automatic assessment, feel free to tweak as desired.) While we're here, we should add the ability for it to function for FA and FL as well, which can be auto-assessed by checking for the {{featured article}}/list template. –xenotalk 18:15, 26 July 2009 (UTC)
If it helps at all, this is an example of what I coded for |auto=yes in the WikiProject Films banner. PC78 (talk) 15:26, 31 July 2009 (UTC)
An elegant placement. Much less intrusive. I dare not touch this beast, could you implement this Happy-melon? –xenotalk 23:00, 1 August 2009 (UTC)
I'll have a look at implementing this in the next day or two. I love that robot icon! — Martin (MSGJ · talk) 15:45, 14 August 2009 (UTC)

I've put some code in Template:WPBannerMeta/core/sandbox. Here's an example: — Martin (MSGJ · talk) 17:04, 14 August 2009 (UTC)

WikiProject iconNorway
WikiProject iconThis article is part of WikiProject Norway, an attempt to better organize information in articles related to Norway. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.NorwayWikipedia:WikiProject NorwayTemplate:WikiProject NorwayNorway articles
If the feature requests I've asked for at WT:Plugin++ are implemented, my bot may begin auto-assessing as other ratings. Can we have it be more general? –xenotalk 17:08, 14 August 2009 (UTC)
This will require slightly more caution because it may affect existing uses. At the moment, auto=yes has no effect unless class=stub. — Martin (MSGJ · talk) 17:38, 14 August 2009 (UTC)

I suggest that as a first step we could implement this just for Stub-Class (i.e. to match existing functionality) and then continue the discussion about adding support for other auto assessments. Perhaps someone could double-check the sandbox code? — Martin (MSGJ · talk) 08:08, 16 August 2009 (UTC)

I'm fine with that. Someone else should double check the code, I'm not too familiar with the inner workings of this beast of a template. –xenotalk 16:45, 17 August 2009 (UTC)
Perhaps WOSlinker is around? — Martin (MSGJ · talk) 18:22, 17 August 2009 (UTC)
Hi, I've had a look through the changes in the core sandbox and it all looks fine for auto Stubs. -- WOSlinker (talk) 11:38, 18 August 2009 (UTC)
Thanks, I've now implemented this. Just a few minor things which occur to me:
  • It says "automatically rated" but it doesn't mention "by a bot" - perhaps it should.
  • Perhaps "rated" doesn't need to be linked to the assessment scale, as it is already linked earlier in the banner.
  • WP:AUTOASSESS is not linked to yet; maybe "automatically rated" should point there?
— Martin (MSGJ · talk) 12:00, 18 August 2009 (UTC)
That sounds like a plan, link to WP:AUTOASSESS. –xenotalk 12:25, 18 August 2009 (UTC)
You could also unlink rated as it's already linked to on the Stub assessment line above the auto assessment note. So not really a need to link twice, especially if you are going to add a link to WP:AUTOASSESS. -- WOSlinker (talk) 12:42, 18 August 2009 (UTC)
 Done — Martin (MSGJ · talk) 13:07, 18 August 2009 (UTC)
I'd suggest linking "bot" to WP:BOT as well. PC78 (talk) 13:03, 18 August 2009 (UTC)
We don't have "bot" yet. Which is more grammatical - "automatically rated by a bot as Stub-Class" or "automatically rated as Stub-Class by a bot"? — Martin (MSGJ · talk) 13:07, 18 August 2009 (UTC)
Prefer the latter. –xenotalk 19:13, 25 August 2009 (UTC)
plus Added — Martin (MSGJ · talk) 22:59, 25 August 2009 (UTC)

need change in auto= verbiage

My bot is now taking requests for projects to inherit classes from other wikiprojects (see User:Xenobot Mk V/process). Can we start accepting an "inherited=yes" and use the following wording? -

"This article has been automatically rated as XX-Class by a bot because other project(s) had used this rating. Please ensure that the assessment is correct before removing the |inherited=yes parameter."

If you want to save on parameters we could use "auto=yes" vs. "auto=inherited" (or just remove any mention of why the bot did what it did...) –xenotalk 04:12, 7 September 2009 (UTC)

I think it is just WikiProject Chicago that you are tagging for at the moment? It would be much easier to just add this as a note to {{ChicagoWikiProject}}. If it ever becomes more widely used we can look at supporting it here. — Martin (MSGJ · talk) 06:43, 7 September 2009 (UTC)
I've added some code to the /sandbox for consideration by the project. — Martin (MSGJ · talk) 06:50, 7 September 2009 (UTC)

I definitely prefer |auto=inherit(ed) to a new parameter. Happy‑melon 09:22, 7 September 2009 (UTC)

  • (reply to both) This is fine with me (using note). How does using "auto=inherited" jive with Martin's usage of "note"? –xenotalk 14:48, 7 September 2009 (UTC)
You would have to disable the default behaviour of auto, and add a note for it. Something like this perhaps. — Martin (MSGJ · talk) 14:53, 7 September 2009 (UTC)
I c what u did thar. I'll play around with it and confer with the sponsoring project. Thanks again, both. –xenotalk 14:54, 7 September 2009 (UTC)
I can sort this out locally, but I was wondering if anyone had any ideas for cases where the bot has assessed both class and importance (in the latter case using a default lowest importance). I was thinking autoimport=, but I was also thinking perhaps it could be passed through the auto= parameter. With a big switch statement it could just say things like "GAlow" "GAmid" etc. What would be best, in terms of forward looking if this were to be eventually provided through the banner? Is there a smarter way to do it? –xenotalk 00:24, 9 September 2009 (UTC)
Anyone? Anyone? Beuller? –xenotalk 14:35, 11 September 2009 (UTC)
Although I can't understand how importance could be successfully rated by a bot, I would plump for using a separate parameter for this, as trying to put it together would make it harder to encode and decode. — Martin (MSGJ · talk) 07:53, 13 September 2009 (UTC)
The wikiproject will sort categories by the default lowest importance. –xenotalk 14:55, 15 September 2009 (UTC)

Deprecated?

Am I right in thinking that {{WPBannerMeta/autoassess}} is now deprecated and no longer in use? PC78 (talk) 18:01, 13 September 2009 (UTC)

Yes, that's correct. — Martin (MSGJ · talk) 07:09, 14 September 2009 (UTC)

Portal elements by month-year to simpler yes/no

I was wondering if someone could point me to an example, or even update Template:WikiProject California/sandbox with an example of the selected portal elements to use a simple yes/no as opposed to the month-year variation. It appears Portal:California used it in the past, but is currently using a set of articles in random rotation. -Optigan13 (talk) 09:32, 12 September 2009 (UTC)

Yikes, can the task force icons not be made a wee bit smaller in that banner? PC78 (talk) 12:00, 12 September 2009 (UTC)
Sorry, I don't really understand what you're asking here. — Martin (MSGJ · talk) 13:49, 13 September 2009 (UTC)
At some point in the past Portal:California was using a monthly selection and was being updated (See Portal:California/Selected picture/Archive). Now the pictures and other elements are simply included or not, and don't have a meaningful date associated with them (See Portal:California/Selected picture/Archives). I was looking to switch from past-picture=March 2008 to something like selected-picture = yes for the picture, bio, and article elements. I'm only noticing this because I'm moving images to commons out of Category:Images of California and noticed the confusing sub-pages on the portal elements. I've tweaked the task force image size to 60px, but those maps are the best representation of the task forces scope, and they don't scale down well. -Optigan13 (talk) 21:35, 13 September 2009 (UTC)
I get what you're asking. I've made some changes in your sandbox. PC78 (talk) 22:10, 13 September 2009 (UTC)
Thanks, I've also tweaked to add an option for selected panorama since they have a seperate page. I'm a bit surprised that the portal elements don't have some standard split out page. -Optigan13 (talk) 06:05, 14 September 2009 (UTC)

More on QUALITY_SCALE

Following the discussion earlier in the year which didn't lead anywhere, I would like to present a more concrete proposal about how I think this parameter could behave.

value behaviour notes
standard or blank or anything else Uses the standard 11 quality classes. If |class= is not passed then no quality scale is used.
extended Uses the full 17 quality classes, currently employed by FULL_QUALITY_SCALE. If |class= is not passed then no quality scale is used.
subpage A custom mask held in the /class subpage is used. If /class doesn't exist, no quality scale is used and a warning and tracking category are triggered on /templatepage.
inline An inline mask (e.g. using {{class mask}}) is used, so no further class mask is needed. Suitable for custom masks that differ slightly from the standard ones and by projects which do not use large numbers of taskforce hooks.
yes If /class exists then use it. Otherwise if FQS=yes use the extended scale, otherwise use standard scale. I.e. current behaviour. Will be deprecated eventually.

The idea is to:

  • Avoid redundant parameters. It it more logical to use QUALITY_SCALE=extended rather than QUALITY_SCALE=yes, FULL_QUALITY_SCALE=yes.
  • Remove the possibility of disruption to high-risk templates by creating /class inappropriately.
  • Simplify the custom class masks of many projects, with the use of an "inline mask". Using something like {{class mask}} is more user-friendly and easier to understand at a glance than using a subpage. For example for a project that requires the use of Template- and Category-Class, it might be a lot easier for them to use
QUALITY_SCALE=inline
class={{class mask | {{{class|}}} | Template=yes | Category=yes }}

This would not be suitable for more specialised class masks or banner templates that use a lot of taskforce hooks.

  • The existing behaviour of QUALITY_SCALE=yes would not alter.

Opinions welcome. — Martin (MSGJ · talk) 09:18, 6 September 2009 (UTC)

Sounds good, but if this is implemented then all the banners currently using custom classes should then be changed to use QUALITY_SCALE=subpage and then whenever the yes or default options are then used, the banner code would no longer use /class if exists. -- WOSlinker (talk) 09:51, 6 September 2009 (UTC)
Looks good. Some thoughts:
  1. "subpage" and /class mask doesn't exist → what behaviour? I'm tempted to say "no quality scale at all". This was something we discussed last time but didn't conclude on.
  2. I love {{class mask}}! Another one to add to WPBM's growing harem of templates :D Not sure I'd be happy turning off WPBM's own masking in favour of a semi-protected template, though. We might have to bump up the protection (and attention) on that 'offshoot' if we integrate it this deeply.
  3. Do we want to try and work on some automagic for |class=?? That is, if |QUALITY_SCALE= is not defined but class is passed through, automagically switch to the default scale? Again, something we thought about in April but never really decided on.
Glad to see this moving again. Happy‑melon 11:39, 6 September 2009 (UTC)
  • WOSlinker: no strong opinion on that. Another approach would be to retain the same behaviour for |QUALITY_SCALE=yes and gradually migrate over to =standard and =extended. I don't really mind either way though.
  • I would agree that having no quality scale might be the best option in this case.
  • Agreed. {{class mask}} will certainly need full protection when it starts being used significantly. At the moment though, it's more useful to be able to have WOSlinker working on it :)
  • Hmm, yes maybe. By "default scale" do you mean the standard 11-class scale? — Martin (MSGJ · talk) 16:47, 6 September 2009 (UTC)
  • I agree with Martin: we should retain the current behaviour of |QUALITY_SCALE=yes - that is, full automagic, nothing assumed. If we implement automagic on |class= then that value becomes deprecated in favour of no |QUALITY_SCALE= at all.
  • That was easy :D
  • Well there's always a way to get around that...
  • Yes, the 'short' WP1.0 scale.
Happy‑melon 20:39, 6 September 2009 (UTC)
Okay good, I think we're getting there. I've updated the table above to what I think we're saying. Perhaps everyone could check that again. Now, I just need someone to check my priority-scale code in the sandboxes and I can start playing with this! — Martin (MSGJ · talk) 09:36, 7 September 2009 (UTC)

So I'm assuming everyone's happy with the above then?! Question: do we want to enable taskforce-specific quality scales. For example |TF_1_QUALITY=standard |TF_2_QUALITY=extended, or should these parameters stay as YES/NO? — Martin (MSGJ · talk) 10:38, 9 September 2009 (UTC)

Whenever I've come across a banner that required a different quality scale for the taskforces, I just used hooks/taskforces to add the taskforces. You could still add the option if you want to but it's easy enough to do already. -- WOSlinker (talk) 10:58, 9 September 2009 (UTC)
Thinking about it a bit more, it's probably worth doing to be consistent with the main QUALITY_SCALE parameter, but the value of yes has a slightly different meaning for taskforces which is "Inherit the value set in QUALITY_SCALE". -- WOSlinker (talk) 11:04, 9 September 2009 (UTC)
Good idea, but wait. On the main banner we have the QUALITY_SCALE parameter. But the hook doesn't have a "overall" QUALITY_SCALE which it can inherit ... — Martin (MSGJ · talk) 11:08, 9 September 2009 (UTC)
There are other issues to look at for this, such as if QUALITY_SCALE=inline then all the builtin taskforces would need to be inline as well as class is only passed through once, so while it seems logical to have the options for individual task forces, in practice it's a bit more complicated to get it all to work easily. Might be best just to keep the option as yes initally for the builtin taskfocres and for the hook, just add the QUALITY_SCALE option (similar to how it will be added to the main template). And then once QUALITY_SCALE has been implemented, could come back and see if any changes should then be made for task forces. -- WOSlinker (talk) 16:02, 9 September 2009 (UTC)
This is starting to take shape. Few thoughts:
  • I agree. Each taskforce in the main template or in a hook must use the same value of class.
  • Instead of passing QUALITY_SCALE to /core, |class=¬ can be used to switch off the quality scale.
  • Is it a good or bad idea to have alternative names of parameters, e.g. B_CHECKLIST / BCHK and FULL_QUALITY_SCALE / FQS? To me this seems to invite confusion.
— Martin (MSGJ · talk) 09:10, 11 September 2009 (UTC)
So you're saying that we only use |QUALITY_SCALE= in the mask? Yes, sounds viable to me. I don't think the alternative parameter names were a good idea in hindsight, I think I made a mistake in forcing those through. I stand by my original position (which is that custom masks shouldn't get these data) but I think the compromise we came to was the worst of both worlds, in retrospect. Happy‑melon 09:24, 11 September 2009 (UTC)

I agree (although I wasn't going to say it so bluntly ;). Any help in testing and debugging this would be appreciated. The templates I've changed are:

— Martin (MSGJ · talk) 14:18, 11 September 2009 (UTC)

Just done a quick test. Seems to be ok apart from on the templatepage, the category missing warnings are only working for the yes/standard scale. Also, {{Class mask}} needs expanding to support B_CHECKLIST I think. -- WOSlinker (talk) 23:03, 12 September 2009 (UTC)
Thanks for the check. I've got a few tests of my own to complete yet. What should we do about the category warnings? They are impossible/difficult to check for the inline and subpage options ... We could maybe add a |topic= parameter to {{class mask}} and put category warnings on the /class page. By the way, I'm coming round to your idea of treating yes the same as standard, once templates with subpages have been converted over. — Martin (MSGJ · talk) 08:17, 13 September 2009 (UTC)
For the inline scale, the banner could provide the same warnings as the standard scale since if inline is only going to be used with class mask then it's going to have at least the standard scale. A topic parameter on class maks for /class pages would be a good addition as well. -- WOSlinker (talk) 09:24, 13 September 2009 (UTC)
Another thought, we could actually set QUALITY_SCALE = subpage now, (already tried it on one banner. And then you could simplify your WPBannerMeta/class/sandbox a little. -- WOSlinker (talk) 09:26, 13 September 2009 (UTC)
At the moment it contains at least the standard scale, but I foresee a possibility of allowing some to be turned off (e.g. A-class) in the future. Yes, QUALITY_SCALE = subpage makes good sense. — Martin (MSGJ · talk) 10:01, 13 September 2009 (UTC)
I've changed all those banners to use QUALITY_SCALE = subpage, apart from the protected ones. -- WOSlinker (talk) 11:14, 13 September 2009 (UTC)
Pages which need QUALITY_SCALE = subpage setting
  1. {{Album}}
  2. {{WikiProject Architecture}}
  3. {{WPAstronomy}}
  4. {{WPAVIATION}}
  5. {{WikiProject California}}
  6. {{WikiProject Canada}}
  7. {{WikiProject Caribbean}}
  8. {{Chemicals}}
  9. {{WikiProject College football}}
  10. {{WikiProject Cycling}}
  11. {{D&D}}
  12. {{D&D/core}}
  13. {{WikiProject Ecuador}}
  14. {{WikiProject Florida}}
  15. {{WikiProject Formula One}}
  16. {{WikiProject Germany}}
  17. {{WikiProject Greece}}
  18. {{WikiProject Green Bay Packers}}
  19. {{WikiProject Illinois}}
  20. {{WikiProject Israel}}
  21. {{WikiProject Japan}}
  22. {{WikiProject Law}}
  23. {{WikiProject Minnesota}}
  24. {{WikiProject Molecular and Cellular Biology}}
  25. {{WikiProject National Register of Historic Places}}
  26. {{WikiProject New Zealand}}
  27. {{WikiProject Norway}}
  28. {{NovelsWikiProject}}
  29. {{WikiProject Plants}}
  30. {{WikiProject Romania}}
  31. {{WikiProject Texas}}
Nice work. What's the best rule to get AWB to change these? — Martin (MSGJ · talk) 13:55, 13 September 2009 (UTC)
I've changed all these. I've also added a tracking category just in case you've missed any in the list above, or any of our changes get undone. — Martin (MSGJ · talk) 09:08, 14 September 2009 (UTC)

Section break

  • So shall we move over to using the full parameter names consistently, i.e.
    • FULL_QUALITY_SCALE
    • B_CHECKLIST?
  • And can we decide whether class should be passed as a named or unnamed parameter to the class masks? (I have a slight preferece for using unnamed.) — Martin (MSGJ · talk) 09:08, 14 September 2009 (UTC)
  • I can't work out where is the best place to normalise the B-checklist criteria. If we do it on /class, it won't work with inline class masks (of course, we could decide not to use inline masks with the checklist). If we do it on {{class mask}}, then it won't benefit other custom class masks ... — Martin (MSGJ · talk) 12:09, 14 September 2009 (UTC)
Don't mind either way for the parameter names. -- WOSlinker (talk) 18:01, 14 September 2009 (UTC)
lens Review Okay I'm ready for a last check please. Every test I have carried out seems to work fine. I'm testing the B-class checklist on /class but also passing the raw b1-6 parameters for the use of custom masks. Hopefully this is the best method. — Martin (MSGJ · talk) 15:19, 15 September 2009 (UTC)

Well we seemed to resolve the last few remaining niggles, and this has now been implemented. Let me or WOSlinker know of anything unexpected please. — Martin (MSGJ · talk) 09:00, 17 September 2009 (UTC)

Wikipedia Signpost article

Hello, everyone! I'd like to do a report on the development of this template and the conversion of WikiProject banners for an upcoming edition of the Wikipedia Signpost. Would anyone here be willing to answer a few questions on those topics? Kirill [talk] [pf] 00:43, 11 September 2009 (UTC)

Sure, no problem. — Martin (MSGJ · talk) 09:03, 11 September 2009 (UTC)
Certainly, fire away. Happy‑melon 09:05, 11 September 2009 (UTC)
If I'm not too late to this, I might be able to provide some insight in the conversion process for one case that really didn't work out. 「ダイノガイ千？！」? · Talk⇒Dinoguy1000 19:11, 22 September 2009 (UTC)

Missing pagetypes

{{pagetype}} needs to be added in a few places:

Neither of these should be non-articles though. — Martin (MSGJ · talk) 21:07, 13 September 2009 (UTC)
Sure, but you have pagetype everywhere else (actually, it's missing at {{WPBannerMeta/hooks/aclass}} too), so this is for consistancy more than anything else. You wouldn't tag a non-article as needing an infobox, yet pagetype is used there. It should be fixed for peer review, if nothing else. PC78 (talk) 21:26, 13 September 2009 (UTC)
I think I deliberately didn't add it to those. It seems pointless to add extra parser functions for no purpose. I take your point about the infobox, and would be happy to put it back to "article". — Martin (MSGJ · talk) 06:58, 14 September 2009 (UTC)
Well... whatever. :) But I'd still like peer review to be fixed. You can see how it shows "page" instead of "article" at {{WPBiography/sandbox}}, for example. PC78 (talk) 09:29, 14 September 2009 (UTC)
 Done, and changed the infobox wording in the sandbox, so will be implemented on next sync. — Martin (MSGJ · talk) 09:54, 14 September 2009 (UTC)

OK, you're quite right when you say that certain elements should only be used on article talk pages. It's a trivial thing, but I was thinking that for test banners in other talk namespaces, it would be nice if article/page/whatever was displayed consistantly. Let me try this pagetype thing from another angle:

WikiProject iconBiography
WikiProject iconThis article is within the scope of WikiProject Biography, a collaborative effort to create, develop and organize Wikipedia's articles about people. All interested editors are invited to join the project and contribute to the discussion. For instructions on how to use this banner, please refer to the documentation.BiographyWikipedia:WikiProject BiographyTemplate:WikiProject Biographybiography articles
Note icon
This article has passed an A-Class review.

In this case, even though I've overridden the default Template-Class assessment, pagetype still displays "template". Should pagetype not default to the assessment rather than the namespace? PC78 (talk) 10:17, 14 September 2009 (UTC)

Ah well. I thought quite hard about how to code this logic. See Template:Pagetype/doc for all the details. I can't quite remember now, but I think I decided that most demonstration cases (e.g. documentation, test cases) would be in subjectspace, and indeed the behaviour you want is exactly what does happen in any subject space. In normal usage, a file is still a file whatever you class it as, so it seemed to make more sense to say "this file has been rated as A-class" than "this article has been rated as A-class". What your asking for, I think, is for the category parameter be passed to {{pagetype}} so that it knows if it's "real" or a "demo", and this is probably far too much added complexity for little gain. — Martin (MSGJ · talk) 10:56, 14 September 2009 (UTC)
OK, no worries. :) On a related note then, what do you think of User:PC78/article only? The idea is to have some way of suppressing certain parameters for non-articles without interfering with demo banners. PC78 (talk) 11:19, 14 September 2009 (UTC)
Interesting. You've added it to the attention parameter - does that mean you don't foresee any need for a template or file to be tagged for attention? — Martin (MSGJ · talk) 12:04, 14 September 2009 (UTC)
Dunno. That was for testing purposes more than anything else. PC78 (talk) 12:23, 14 September 2009 (UTC)
With this latter idea I think I was just being dumb. The desired effect would be best achieved with something like {{#switch:{{WPBiography/class|class={{{class|}}}}}|Category|Disambig|Template|NA=|{{{needs-photo|}}}}}; there's no reason for a test banner to behave differently to a normal banner. PC78 (talk) 00:15, 23 September 2009 (UTC)

What's in the new "extended" quality scale?

Does it include Redirect, Needed, Future, and Current classes?

If so, I'd like to float the idea to have {{WikiProject College football}} use this new extended scale rather than a subpage. If not, perhaps using an inline class mask is more appropriate. In the past, the only reason WP:college football was using a subpage was to enable these classes - there was no other custom processing going on. It seems that there are now better ways of doing something straightforward like enabling less-common assessment classes. Thanks. DeFaultRyan 16:51, 22 September 2009 (UTC)

No. |QUALITY_SCALE=extended does just the same thing as |FULL_QUALITY_SCALE=yes used to do. However we now have the funky {{class mask}} which I have just put on your custom mask. (This can be put inline if you prefer, you just won't have that documentation page there.) — Martin (MSGJ · talk) 17:22, 22 September 2009 (UTC)
(ec) There's nothing new. |QUALITY_SCALE=extended is now equivalent to the old |QUALITY_SCALE=yes|FULL_QUALITY_SCALE=yes. So those classes are still unsupported. I'm not fully up to speed with what Martin's been doing with {{class mask}}; maybe that template has support for what you're looking for? Happy‑melon 17:23, 22 September 2009 (UTC)
OK, thanks for the clarification. Thanks also for the class mask edit. Keep up the good work! DeFaultRyan 20:10, 22 September 2009 (UTC)

Icons

Sorry if I'm bombarding you guys with requests/suggestions at the moment! :) I'd like to propose a few icon changes:

Current Proposed Reason
Auto assessment
More or less the same as the current icon, though I think this version looks a little more polished.
Needs infobox
SVG may be preferable?
Peer review
For visual consistancy with File:Bclass-checklist.svg. Changed per discussion below.
A-Class review
Correct icon for current reviews. Specifically for the initial part of the hook, which (so far as I can tell) determines what is shown on the actual banner page, not the main part of the hook which is fine.

Also, I would like to suggest that we adopt a standard size for such icons, because there is currently a certain amount of inconsistancy:

  • Task forces, notes, auto assessment and peer review all default to 30px.
  • Needs-attention and needs-infobox are both fixed at 20px.
  • A-Class review defaults to 18x18px.

Personally I would prefer to adopt a standard of 25px or 25x25px, that way icons won't look too big when placed next to a single line of text, and not too small against two or more lines of text. (Actually my preference would be x25px, but that doesn't appear to stretch smaller images - I don't know if that's a bug or not.)

Thoughts? PC78 (talk) 19:40, 13 September 2009 (UTC)

There's also the option of for peer-review. -- WOSlinker (talk) 20:45, 13 September 2009 (UTC)
True, I've seen that icon used for peer review elsewhere. PC78 (talk) 20:53, 13 September 2009 (UTC)
Yes, that A-Class hook is definately wrong when shown on the template page. -- WOSlinker (talk) 22:29, 13 September 2009 (UTC)
I don't like the "needs infobox" one, but the rest do look better. —Ms2ger (talk) 17:40, 17 September 2009 (UTC)
How does it look now? I checked the file on Commons and reverted to an earlier version which both looks better and is closer to the png. PC78 (talk) 22:35, 17 September 2009 (UTC)
These all look like improvements now. Happy‑melon 12:43, 22 September 2009 (UTC)
Cheers! I'm inclined to agree with WOSlinker about the peer review icon, since that's the icon used at {{peer review}} and {{icon}}. PC78 (talk) 14:51, 22 September 2009 (UTC)

Can we go ahead and implement these four icon changes? Any thoughts about what I said above regarding default icon sizes? PC78 (talk) 02:15, 24 September 2009 (UTC)

Tempting though it is to refuse until you do it yourself,  Done :D Happy‑melon 11:16, 24 September 2009 (UTC)

Portal box

This perhaps isn't the best place to raise this issue (but that won't stop me damn it!), but the portal box in {{WikiProject Alternative Medicine}} look rather odd being so elongated. Is it not possible to get the portal text to wrap onto another line? PC78 (talk) 18:29, 23 September 2009 (UTC)

{{portal|break=yes}} Happy‑melon 18:40, 23 September 2009 (UTC)
Although, of course, you really mean "is there a way to get the portal box produced by WPBM to wrap...?" Happy‑melon 18:42, 23 September 2009 (UTC)
Personally, I prefer our style... ;) 「ダイノガイ千？！」? · Talk⇒Dinoguy1000 19:17, 23 September 2009 (UTC)
Hmmm. It would be trivial to add a parameter here that would activate |break= in {{portal}}, but all that actually does is wrap the "portal" onto a new line. In this particular case it would be desirable to have the line break between "and" and "Alternative", but that would require a change at {{portal}}. PC78 (talk) 19:56, 23 September 2009 (UTC)
Think I solved the problem. It's looking a bit shorter now. — Martin (MSGJ · talk) 20:03, 23 September 2009 (UTC)
Well, that's one way of doing it! :D PC78 (talk) 20:22, 23 September 2009 (UTC)

Need assistance

I've coded {{WPBiography/sandbox}} so that the main categories for |auto=, |attention=, |needs-photo= and |needs-infobox= are not used if any of the work groups are specified. This works fine for the latter two but not for |auto= or |attention=, even though I've used the same code; see User talk:PC78/Sandbox1. Can anyone see what the problem is here? PC78 (talk) 17:44, 24 September 2009 (UTC)

The reason it doesn't work is because if the value is blank, for AUTO_ASSESS_CAT or ATTENTION_CAT, WPBannerMeta uses the default value. What you have to do instead is pass through "none". I've edited the sandbox to do that. -- WOSlinker (talk) 18:17, 24 September 2009 (UTC)
Ah, OK. Thanks for that. :) PC78 (talk) 19:36, 24 September 2009 (UTC)

Class → class

I have placed a notification on Wikipedia talk:WikiProject Council about this proposal. — Martin (MSGJ · talk) 11:45, 9 September 2009 (UTC) Renaming thousands of categories may never happen, but we can at least change XXX-Class to XXX-class in all the text in the banner, and continue to link to the same categories, can't we? This will make it consistent with importance/priority which use a lowercase initial letter. — Martin (MSGJ · talk) 15:08, 7 September 2009 (UTC)

Is this "think big" week? :D I can't see any real downsides with doing this. Happy‑melon 15:59, 7 September 2009 (UTC)
I'm not so keen. Simply changing it here would make things more inconsistant, with the categories (as noted above), with other non-WPBM banners, with the WP:1.0 logs, and wherever else XXX-Class is commonly used. I'm certainly not against a capitalisation change, but would prefer it to be done across the board. PC78 (talk) 16:14, 7 September 2009 (UTC)
Yes, but we have to start somewhere, and it makes sense to start on the most widely-used template. I don't mind tracking down other templates and changing them. — Martin (MSGJ · talk) 17:00, 7 September 2009 (UTC)
In fact, things are pretty consistent... they use capitalization to refer to the classifications as proper nouns. Not sure the change is even worth all the work that would accompany it, so I'm edging it on not doing it. Titoxd(?!? - cool stuff) 17:36, 9 September 2009 (UTC)
The change is very easy. I will just change some "C"s to "c". As I said, I am not proposing to rename any categories; that would indeed be a lot of work. The inconsistency is between the capital C for Class and the little i for importance. Thus we have things like
and there is no reason the two should not be capitalised the same. — Martin (MSGJ · talk) 17:47, 9 September 2009 (UTC)
Here's my problem: I'm all for switching to a lower-case "c", but not if it's just going to be a mere cosmetic change implemented here only. I would expect the categories to be dealt with as well, otherwise you're just trading one inconsistancy for another. PC78 (talk) 17:56, 9 September 2009 (UTC)
What about capitalizing "importance" instead? Headbomb {ταλκκοντριβς – WP Physics} 09:25, 10 September 2009 (UTC)
Only marginally less work. There are 21,300 subcats of Articles by quality, and 6,500 subcats of Articles by importance. In the general scheme of things, both numbers representa task of a similar magnitude. Happy‑melon 11:58, 10 September 2009 (UTC)
This is certainly an alternative idea, but having them both lowercase would seem more correct to me personally. — Martin (MSGJ · talk) 09:23, 11 September 2009 (UTC)
I understand your point, and we can certainly talk about migrating the categories (and you should talk to Dinoguy about that because he was interested). However, you have probably noticed that making sweeping changes is often pretty difficult here, and they are much more likely to succeed if they can be accomplished as a series of small steps. That is why I am suggesting this as an initial small step, as it would be trivial to implement. After using a lowercase c for several months, it would be much easier to make similar changes elsewhere or to make the case to move categories. — Martin (MSGJ · talk) 09:23, 11 September 2009 (UTC)
Did somebody call me? =D I'd agree with this change, but personally, I'd rather see it made incrementally, as MSGJ and Happy-melon are recommending. The problem with making a sweeping change of simultaneously converting all instances of "Class" to "class", is that this is only one facet of the inconsistencies in the current system. Such a change would require a decent amount of planning and preparation, to make sure the change gets done reasonably quickly, without a lot of breakage or inconvenience for end-users and bots and the like. All this planning would, frankly, be a pain to do separately for every single such inconsistency (not to mention the large degree of duplication of effort), so if a sweeping change is to be made, I'd rather see everything discussed first, with the whole community, and an agreement reached on exactly what to change and how to change it. This way, we have a central plan of action for all such changes, we can use the same resources for the entire thing, and we can get all of it done at once. On the other hand, if we're changing one system at a time (or even just changing *one* system, period, as has been tentatively suggested here), incremental steps mean we only have to deal with far more localized problems, and the different steps can be more easily parceled out to different users and done at different times, with little more planning than just making sure everyone is kept up-to-speed with what any one person is planning to do. 「ダイノガイ千？！」? · Talk⇒Dinoguy1000 19:09, 22 September 2009 (UTC)
So, you support doing things "incrementally", but you also want to "get all of it done at once". Can you clarify what you mean because these seem to be opposite ;) — Martin (MSGJ · talk) 12:58, 29 September 2009 (UTC)
Yes, I suppose my above comment was a bit confusing... Let me see if I can clarify (with extreme summarization; all my reasoning is already above): if we're only looking at changing "Class" to "class" for now, I'd prefer to see it done incrementally. If we want everything done at once, though, I would rather have everything done at once. Does that resolve the apparent contradiction? =) 「ダイノガイ千？！」? · Talk⇒Dinoguy1000 18:38, 29 September 2009 (UTC)
Okay, so I will take your response as support for this small proposal, and I look forward to taking part in your RfC whenever you get round to it. — Martin (MSGJ · talk) 19:46, 29 September 2009 (UTC)

Comments: revisting on old idea

Taken from Template talk:WPBannerMeta/Archive 3:

This discussion has been closed. Please do not modify it.
The following discussion has been closed. Please do not modify it.

I think the "edit · history · watch · purge" text looks a little bit clunky where it currently is. Might I suggest the following: 

<td style="text-align:left; padding:0px; background-color:white; border:1px solid #c0c090; padding:5px; margin-top:5px;"><sup class=plainlinks>{{center|[{{fullurl:{{FULLPAGENAME}}/Comments|action=edit}} edit]{{·}} [{{fullurl:{{FULLPAGENAME}}/Comments|action=history}} history]{{·}}  [{{fullurl:{{FULLPAGENAME}}/Comments|action=watch}} watch]{{·}} [{{fullurl:{{FULLPAGENAME}}|action=purge}} purge]}}</sup><br />{{{{FULLPAGENAME}}/Comments}}</td>

which would move this into a centralised position within the actual comments box? In either case, note the unnecessary extra space preceeding the {{·}} templates. PC78 (talk) 19:33, 3 January 2009 (UTC)

IMO, it was better before (apart from the spaces before {{·}}). —Ms2ger (talk) 20:18, 3 January 2009 (UTC)
Reverted. What does everyone else think? Happy‑melon 22:58, 3 January 2009 (UTC)
Could we see the two options side by side? Martin 09:18, 4 January 2009 (UTC)

This should give you a rough idea...

Current:

Comments: edit  · history  · watch  · purge
Module talk:WikiProject banner/Archive 7/Comments

Proposed:

Comments:
edit · history · watch · purge

Module talk:WikiProject banner/Archive 7/Comments

FWIW I think the bottom one looks neater. PC78 (talk) 12:58, 4 January 2009 (UTC)

I think I prefer the top one, if only because it takes up less room. You've got that orange bar doing not very much - might as well put the links in there. Martin 13:05, 4 January 2009 (UTC)
Changing my mind. Space is not an issue because it won't be displayed unless "show" is clicked. And it is clearer. Hmm, I'm torn. Martin 13:06, 4 January 2009 (UTC)
For one thing I think it's more appropraite to have these links with the actual message. At a glance, with the comments section collapsed, it's not obvious what they're for. PC78 (talk) 13:09, 4 January 2009 (UTC)
Okay, I support this change. Could I also suggest that the template checks not only that the /comments subpage exists but also that it contains something? It's annoying when, occasionally, you go to check a comment and the comments have been blanked. Martin 10:35, 5 January 2009 (UTC)
Would it be better if "purge" was "refresh" like it is on the Todo template? -- WOSlinker (talk) 20:57, 6 January 2009 (UTC)
Probably. Might be an idea to add a link for "view" as well. PC78 (talk) 21:10, 6 January 2009 (UTC)

This edit is to stop the archiving bot, as this thread is not concluded. Martin 15:11, 15 January 2009 (UTC)

I still think this is preferable to the current implementation, and the idea seemed to have some measure of support (from Martin at least) before it got buried in the archives. Any thoughts on revisiting this? PC78 (talk) 13:24, 13 September 2009 (UTC)

Incidentally, this would be consistant with {{WPBannerMeta/hooks/todolist}}. PC78 (talk) 18:36, 13 September 2009 (UTC)
Weak support from me, as before. — Martin (MSGJ · talk) 12:05, 14 September 2009 (UTC)
Feel free to add it to the todo list :) And sandboxes are available again. — Martin (MSGJ · talk) 09:02, 17 September 2009 (UTC)
Weak support from me as well, it's not exactly an earth-shattering change, but I do prefer the proposed layout. Happy‑melon 14:26, 17 September 2009 (UTC)

Proposed code on Template:WPBannerMeta/comments/sandbox. Can you confirm that this is what you want? — Martin (MSGJ · talk) 11:37, 22 September 2009 (UTC)

I've tweaked the padding a bit to sync it with {{WPBannerMeta/hooks/todolist}} (though you could also go the other way and adjust the padding for the hook instead); actually, there is still an extra pixel between edit/history/watch/purge and the transcluded text, but I'm inclined to think that no-one but me will notice (and I don't know where it's coming from). :) Also, you should be able to remove "background:#F8EABA" from todolist; it doesn't appear to be necessary and I've been told before that hardcoding colours like that is bad for different skins. PC78 (talk) 22:35, 22 September 2009 (UTC)
Okay. It is possible that those padding settings were chosen so that the /comments section was consistent with other collapsed boxes, such as /collapsed and /bchecklist. Would you mind checking this out? Ideally the [show] buttons would all be aligned. — Martin (MSGJ · talk) 11:47, 24 September 2009 (UTC)
I've cobbled together a test banner at User talk:PC78/testbanner. I can't get "comments" to show here, though "comments" are in line with "to do". /bchecklist doesn't appear to line up with any of the others anyway. PC78 (talk) 14:08, 24 September 2009 (UTC)
Right, I've reverted to your edit at {{WPBannerMeta/comments/sandbox}} and tweaked the padding at {{WPBannerMeta/hooks/todolist/sandbox}} instead; looks better now. PC78 (talk) 19:55, 24 September 2009 (UTC)

I've made the changes to /comments and /todolist. — Martin (MSGJ · talk) 13:38, 29 September 2009 (UTC)

Template:WikiProject Hazara

Bit of an odd one. I implemented a few fixes to this recently created banner in order for it to work properly. None of the relevant categories have been created, so I headed over to drop the project a line (and also about not handing out GA-Class assessments to any old article). Except the project appears to be just a single user, so I was going to contact the user directly except he's currently blocked. And so not having much of a clue what to do next, I'm leaving this note here in case anyone has any ideas. Is it worth helping this project/user set things up, or best holding off for now? PC78 (talk) 01:46, 30 September 2009 (UTC)

I've disabled the assessment categories for now. Maybe post at WT:COUNCIL and see what people think? Or WP:MfD if you think the project is a non-starter. — Martin (MSGJ · talk) 08:17, 30 September 2009 (UTC)

Template:ACIDcur/article

Another banner that requires attention. I've fixed the category parameter, but there are other issues here that I don't have time to go into ATM. So far as I can see this template will only ever be displayed on one talk page at a time (i.e. the current collaboration), so I'm not sure why the assessment parameters should be necessary. PC78 (talk) 13:16, 30 September 2009 (UTC)

Think I've fixed it up. Obviously the class and importance bits were not in use so I removed them. — Martin (MSGJ · talk) 15:04, 30 September 2009 (UTC)

And another...

(Sorry chaps!) Perhaps I'm being dim, but for the life of me I can't see where the C-Class assessment is coming from at Talk:Sophie Reade. PC78 (talk) 13:22, 30 September 2009 (UTC)

Ouch. This looks like an error in {{class mask}}. I'll look into it. — Martin (MSGJ · talk) 13:30, 30 September 2009 (UTC)
 Fixed It was actually an error in /class which only showed itself for a blank class parameter and an inline class mask. I've tweaked it and seemed to have solved the problem, but we should probably look at recoding that template. Basically the magic word padleft is being used in an unintended way in order to make the syntax cleaner. — Martin (MSGJ · talk) 14:46, 30 September 2009 (UTC)
Thanks for both of the above Martin. :) PC78 (talk) 22:30, 30 September 2009 (UTC)

Link to documentation

I don't know how you guys feel about tinkering with the main banner text, but it occurs to me that an explicit link to a banner's documentation would be useful in most cases, particuarly for more complex banners. Thoughts? PC78 (talk) 15:44, 13 September 2009 (UTC)

Blimey, you are keeping us busy here. Sure, this might be a good idea if it doesn't make the wording too long. What wording would you suggest? — Martin (MSGJ · talk) 07:21, 14 September 2009 (UTC)

How about adding: 

{{#if:{{{DOC_LINK|}}}|<small>[[[{{{DOC_LINK}}}|DOCUMENTATION]]]</small>}}

to the end of the existing text in /core, and: 

|DOC_LINK            = {{#if: {{{DOC_LINK|}}}
                         |{{{DOC_LINK}}}
                         |Template:WikiProject {{{PROJECT}}}/doc
                       }}

to the main template. For example:

WikiProject iconTulips
WikiProject iconThis article is within the scope of WikiProject Tulips, a collaborative effort to improve the coverage of tulips, liliaceae and related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TulipsWikipedia:Somewhere about tulipsTemplate:WikiProject TulipsTulips articles

-- PC78 (talk) 09:47, 24 September 2009 (UTC)

Hmm, well a few things:
  1. Using your conditional on the main template, {{{DOC_LINK}}} will always be defined, so the check on /core is a bit pointless.
  2. Might be worth adding an ifexist check somewhere.
  3. It's not quite clear that it's the documentation for the template that's being linked to. But TEMPLATE DOCUMENTATION is probably too long ...
  4. In general I would prefer to make changes to the default layout, if it agreed that it's definitely an improvement, rather than adding more options to the syntax for trivial things like this.

Sorry I know this isn't very constructive, and I'm not trying to tear your idea to pieces. — Martin (MSGJ · talk) 11:39, 24 September 2009 (UTC)

←That's OK; halfway through typing that comment above I realised that what I was going to suggest wouldn't work, so I changed things and that's why you've got the redundant #if check. Could change that #if to an #ifexist, though (I think). Actually I would probably prefer a rewording of the text rather than just tacking something onto the end. How about something like: 

This {{pagetype|{{{class|}}}}} is within the scope of '''[[{{{PROJECT_LINK|}}}|WikiProject {{{PROJECT}}}]]''', a collaborative effort to improve the coverage of {{#if:{{{MAIN_ARTICLE|}}}|{{#ifexist:{{{MAIN_ARTICLE}}}|[[{{{MAIN_ARTICLE}}}]]|{{{MAIN_ARTICLE}}}}}|{{#ifexist:{{{PROJECT}}}|[[{{{PROJECT}}}]]|{{{PROJECT}}} articles}}}} on Wikipedia.  {{#if:{{{small|}}}||All interested editors are welcome to participate and join the [[{{TALKPAGENAME:{{{PROJECT_LINK}}}}}|discussion]].  {{#ifexist:Template:WikiProject {{{PROJECT}}}/doc|For instructions on how to use this banner, please refer to the [[Template:WikiProject {{{PROJECT}}}/doc|documentation]].}}}}

-- PC78 (talk) 13:32, 24 September 2009 (UTC)

Current

WikiProject iconPlants
WikiProject iconThis article is within the scope of WikiProject Plants, a collaborative effort to improve the coverage of plants on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.PlantsWikipedia:WikiProject PlantsTemplate:WikiProject PlantsPlants articles

Proposed

WikiProject iconPlants
WikiProject iconThis article is within the scope of WikiProject Plants, a collaborative effort to improve the coverage of plants on Wikipedia. All interested editors are welcome to participate and join the discussion. For instructions on how to use this banner, please refer to the documentation.PlantsWikipedia:WikiProject PlantsTemplate:WikiProject PlantsPlants articles
  • Weak support for this tweaking of the default text. — Martin (MSGJ · talk) 11:21, 8 October 2009 (UTC)

Wikipedia:Template messages/WikiProject banners

For some reason I cant get {{WikiProject Years}} to transclude on this page, it's just giving a red link to WikiProject Years instead. Any ideas? PC78 (talk) 01:24, 2 October 2009 (UTC)

Think that page is overloaded with templates. It's in Category:Pages where template include size is exceeded. — Martin (MSGJ · talk) 04:36, 2 October 2009 (UTC)

Formatting errors

I've recently fixed three newly created banners with incorrect coding

  1. [1]
  2. [2]
  3. [3]

Is there any way for the meta to recognise any of these issues and add the banners to Category:WikiProject banners with formatting errors? PC78 (talk) 18:22, 5 October 2009 (UTC)

  1. Could not be detected I think, because category=no is for valid demo purposes on the template page.
  2. Is already tracked by Category:WikiProject banners with formatting errors (under heading P)
  3. Could not be detected currently, but I am proposing changes in a thread above so that |category={{{category|}}} is allowed.
There are probably lots of other checks we could add as well if we wanted. — Martin (MSGJ · talk) 22:17, 5 October 2009 (UTC)
Waiting for a code review for #3 (see a thread near the top...) — Martin (MSGJ · talk) 11:45, 8 October 2009 (UTC)

Another feature request for task forces

Can a |HOOK_CAT= parameter be added to {{WPBannerMeta/taskforce}}? This is merely to allow extra categories to be hooked onto each individual task force, which has the advantage of keeping things more streamlined and organised than just tacking them onto the end of the banner code. I've already tested this in the sandbox and it seems fairly trivial to implement. PC78 (talk) 14:50, 29 August 2009 (UTC)

Hmm, this request is a little odd. I could sort of see the purpose of supporting MAIN_CAT_2 (but even this seems rather unnecessary to me). But the place where you've put this new parameter in the code would not even benefit from the category supression ... — Martin (MSGJ · talk) 09:21, 2 September 2009 (UTC)
Just to clarify, it's for hooking {{WPBannerMeta/hooks/cats}} which already has category suppression. Have a look at the code for {{WPBiography/sandbox}} and see how I have employed this feature for the filmbio work group. This is, IMHO, a better way of doing things, and I'm rather keen to see this change go ahead. PC78 (talk) 10:25, 2 September 2009 (UTC)
Well HOOK_CAT is still strange. Theoretically you could hook anything, not just categories. TF_HOOK might make more sense. No strong opinion on whether it is a good way of doing things though. Except that, things of benefit to just one banner (however big!) are probably best implemented locally. Unless you think this has possible broader benefits. — Martin (MSGJ · talk) 10:33, 2 September 2009 (UTC)
Sure, in theory it could be used to hook anything (though I'm not sure if you'd want to). No objections to a rename, though. The advantages I see for {{WPBiography/sandbox}} are twofold: first, it keeps the categories for work groups grouped together, so they aren't all jumbled at the foot of the page; second, it should avoid unnecessarily repeating arguments such as {{#ifexpr: {{#if:{{lc:{{{a&e-work-group|}}}}}|1|0}} * {{#if:{{lc:{{{musician-work-group|}}}}}|0|1}} * {{#if:{{lc:{{{filmbio-work-group|}}}}}|0|1}} |yes}}. I'm not sure how I could do this locally, but isn't it the purpose of the meta to avoid such things? ;) No reason why it couldn't benefit other existing meta banners. Certainly I would be back here asking for it if we were to ever convert {{Film}}. PC78 (talk) 10:47, 2 September 2009 (UTC)
Okay, I agree that code for film-bio is neater and clearer like that. It is also fairly easy to implement and adds little complication to the template. So I am not strongly opposed but still need convincing that this is worthwhile, and waiting for thoughts from others. (Of course, adding a NOTE_HOOK parameter could achieve the same result, right? Why did you decide to do it that way round?) — Martin (MSGJ · talk) 12:54, 3 September 2009 (UTC)
Do you mean the |HOOK_NOTE= parameter in the main banner code? PC78 (talk) 13:12, 3 September 2009 (UTC)
No! I meant that adding a |NOTE_HOOK= parameter to Template:WPBannerMeta/note could achieve the same as adding a |TF_HOOK= to Template:WPBannerMeta/taskforce. — Martin (MSGJ · talk) 13:19, 3 September 2009 (UTC)

(outdent) Right, you mean if I had something like this: 

|note 4={{{needs-infobox|}}}
 |NOTE_4_TEXT           = An appropriate '''[[Wikipedia:Infobox templates|infobox]]''' may need to be added to this article, or the current infobox may need to be updated. Please refer to the [[Wikipedia:WikiProject Biography/Infoboxes|list of biography infoboxes]] for further information.
 |NOTE_4_CAT            = Biography articles without infoboxes
 |NOTE_4_HOOK           = {{WPBannerMeta/hooks/cats
 |category={{{category|¬}}}
 |BANNER_NAME           = Template:WPBiography
 |cat 1={{{military-work-group|}}}
 |CAT_1                 = Military biography work group articles needing infoboxes
}}

I guess that's equally valid, and I don't suppose it really matters. I guess I did it the other way because I felt it more appropriate to have everything relating to a single task force in one place. PC78 (talk) 00:03, 4 September 2009 (UTC)

Since {{WPBannerMeta/hooks/cats}} has no visible output, you can just put it at the end of the |TF_n_TEXT= text. Tidy would move any visible output that you put into the hook at that location, to the end of the text anyway. Happy‑melon 14:19, 3 September 2009 (UTC)

So that would be: 

|tf 2={{{filmbio-work-group|}}}
 |TF_2_LINK             = Wikipedia:WikiProject Actors and Filmmakers
 |TF_2_TEXT             = This {{pagetype|{{{class|}}}}} is supported by '''[[Wikipedia:WikiProject Actors and Filmmakers|WikiProject Actors and Filmmakers]]''', an attempt to build a comprehensive and detailed biographical guide to actors and filmmakers on Wikipedia.{{WPBannerMeta/hooks/cats
 |category={{{category|¬}}}
 |BANNER_NAME = Template:WPBiography
 |cat 1={{{WikiProject Automobiles|}}}
  |CAT_1      = Automatically assessed biography (actors and filmmakers) articles
}}
 |TF_2_NESTED           = Actors and Filmmakers
 |TF_2_IMAGE            = Fratelli Lumiere.jpg
  |TF_2_SIZE            = 30x30px
 |TF_2_QUALITY          = yes
  |tf 2 importance={{{priority|{{{importance|}}}}}}
  |TF_2_ASSESSMENT_CAT  = biography (actors and filmmakers) articles
 |TF_2_MAIN_CAT         = Actors and filmmakers work group articles

Right? I guess I could do things that way if you guys are reluctant to add the extra parameter, though it seems far less intuitive. PC78 (talk) 00:03, 4 September 2009 (UTC)

Yes, that might be a good way to do it for now. Or, we could maybe compromise and add it as a feature to the taskforce hook, as keeping the hooks efficient and streamlined is much less of an issue. — Martin (MSGJ · talk) 08:07, 4 September 2009 (UTC)
I've added this to the taskforce hook. WPBio wanted to use the default taskforce text, therefore the text parameter cannot be used and this seemed the easiest way. — Martin (MSGJ · talk) 10:36, 9 September 2009 (UTC)

Any thoughts on the changes I've made at {{WPBannerMeta/taskforce/sandbox}}? It doesn't seem logical to me for the task force importance ratings to be attached to the default text, since this will be overridden by the custom text. I think it would also be useful for "Foo-importance" to link to the appropriate category. In addition (this is something I didn't code in the sandbox), since we no longer display NA-importance in the main banner assessments, should we not also suppress NA-importance here as well? PC78 (talk) 16:40, 10 September 2009 (UTC)

  1. Would be difficult because quite a few projects (e.g. Template:WPMED) display the importance as part of their custom text, and so this change would make it display twice.
  2. Hmm, maybe.
  3. Support.
— Martin (MSGJ · talk) 17:04, 10 September 2009 (UTC)
Do you know why that banner uses custom text? At a glace it looks identical to the default text. PC78 (talk) 17:40, 10 September 2009 (UTC)
If taskforce-specific importance is not specified then some of the taskforces wanted to inherit the main importance. But they don't want it displayed on the taskforce in this case. See Template talk:WPMED#Taskforce importance. — Martin (MSGJ · talk) 17:49, 10 September 2009 (UTC)
  1. Hmmm... would that be the only banner affected? Perhaps a seperate parameter to define custom behaviour like this, though that may be a little overcomplicated.
  2. I was thinking this would be useful in the same way you have {{class}} and {{importance}} linking to specific categories.
  3. Shall we do it then? :) PC78 (talk) 17:34, 13 September 2009 (UTC)
  1. I doubt it's the only one. It would be quite a job to hunt down all the others ...
  2. Waiting to see what others think about this.
  3. I've added it to the to-do list. (Would like to get the QUALITY_SCALE stuff done before messing with the sandboxes!)
— Martin (MSGJ · talk) 07:16, 14 September 2009 (UTC)

I've made a few changes to /taskforce/sandbox.

  1. Re-order so that quality categories are added before importance categories, to match order in the overall quality/importance scales.
  2. Not displaying importance if it is Unknown or NA.
  3. Undo the change to custom text. I think this needs more care and further investigation before we can change it.
  4. Restored the words "marked as" - I think it makes it clearer than just having the name of the taskforce with the importance in brackets.

I would like to start using importance=¬ for when the importance scale is not used by a taskforce, instead of the IMPORTANCE parameter. This will require some different code to make the transition smooth. Basically we need the importance mask to pass through ¬, as the class mask does now. Any comments? — Martin (MSGJ · talk) 11:25, 22 September 2009 (UTC)

If there are no concerns or comments then I will start to make this change in the next day or two. — Martin (MSGJ · talk) 12:55, 29 September 2009 (UTC)
I've started on this. — Martin (MSGJ · talk) 09:27, 30 September 2009 (UTC)
  1. Add transition code to /taskforce so that the importance scale is not used if either IMPORTANCE is blank or importance=¬  Done
  2. Pass ¬ through the importance mask  Done
  3. Ensure that importance=¬ is used in all cases when importance scale is not desired  Done
  4. Remove transition code from /taskforce so that IMPORTANCE is not used  Done
  5. Remove IMPORTANCE from all calls to /taskforce  Done
Think I'm just about done with this. It's wrecked the nice efficient coding on /hooks/taskforces/core so I might look at that again now. Everything else seems to be working well. Farewell to |IMPORTANCE= — Martin (MSGJ · talk) 11:34, 6 October 2009 (UTC)

Another idea

What would people think about using |TF_n_TEXT=none to allow quality/importance classification on additional categories without any output? This would be analogous to the blank notes which are now allowed. It might simplify some banners which currently use the /qualitycats hook. — Martin (MSGJ · talk) 16:09, 6 October 2009 (UTC)

What does /qualitycats actually do? It isn't very well documented. PC78 (talk) 16:16, 6 October 2009 (UTC)
Well it implements additional quality categories without any output. For example Template:WikiProject Lutheranism uses it to add articles to subcats of Category:Christianity articles by quality. — Martin (MSGJ · talk) 16:20, 6 October 2009 (UTC)
I have implemented this now. I'm just thinking that it would probably be better to disable the nested text in this case, otherwise there could be could be visual output of the taskforce in the nested format but not in the expanded format which would be weird. — Martin (MSGJ · talk) 18:59, 11 October 2009 (UTC)

Boldly going where no auto-assessment bot has gone before...

A robot
A robot

Xenobot is happily chugging away, 1 2 3 4 5 6 auto-inheriting classes for projects that have requested it (currently 3, and about to ping 5 of the top 10 projects in terms of unassessed backlog as well). Could we could allow for native recognition of "auto=inherit"? Currently using this hook: 

|note 3={{{WikiProject Automobiles|}}}
 |NOTE_3_TEXT        = This article was [[WP:AUTOASSESS|automatically rated]] by a [[Wikipedia:Bots|bot]] because {{#ifeq:{{{WikiProject Automobiles}}}|yes
  |it uses a [[Wikipedia:Stub|stub template]]
  |at least one other project used this rating
 }}. Please ensure that the assessment is correct before removing the {{para|auto|{{#ifeq:{{{WikiProject Automobiles}}}|yes|yes|inherit}}}} parameter.
 |NOTE_3_IMAGE       = Robot icon.svg
 |NOTE_3_CAT         = Automatically assessed Toronto articles

Thanks, –xenotalk 20:25, 4 October 2009 (UTC)

 Thinking... not ignoring ;) — Martin (MSGJ · talk) 12:45, 7 October 2009 (UTC)
Me too; I think this is good, but it has caveats to work through. I think we'll want to implement something like |auto=stub, |auto=inherit, and |auto=yes as B/C for "stub". I shall await Martin's words of wisdom... :D Happy‑melon 13:04, 7 October 2009 (UTC)
Yes, I had thought about that as well. We could go one further and allow "auto=XX" for any class, and then if class= does not match auto=, the auto verbiage is suppressed and some kind of maintenance category could be added (Automatically assessed articles that have been re-rated... or something) for a bot or human to clear the auto flag. –xenotalk 13:07, 7 October 2009 (UTC)

No words of wisdom, but a few points:

  • I would definitely support using the class as the parameter value because it allows for a more descriptive message and would avoid confusion if the class is ever changed without removing the auto/inherited parameter.
  • Combining auto and inherited seems sensible because their purpose is so similar, but having |auto=yes working with |auto={{{class}}} seems sub-optimal and not intuitive. For instance there is no particular reason why |auto=stub could mean either of the following:
    • This article has been automatically rated as Stub-Class by a bot because it uses a stub template.
    • This article has been automatically rated as Stub-Class by a bot because at least one other project used this rating.
  • As there are only a handful of projects inheriting classes currently, I have to wonder if it is worth adding the support here when it is so easy to add the note text above to individual banners. (And it would be good to iron out the issues and sort out the best way to do this by working on a small scale first!) I still haven't got round to adding a |needs-image= parameter yet, and far more banners are likely to find that useful ...

— Martin (MSGJ · talk) 11:42, 8 October 2009 (UTC)

I'd suggest continuing to use "auto=yes" for the first issue. There are so many "Automatically assessed articles" that have auto=yes that it will likely never be fully converted to the new method. However, if this isn't preferable, auto=stub-inherit or something could be used. –xenotalk 11:47, 8 October 2009 (UTC)
Why not continue to use banner notes locally for the time being? I would recommend using the class and only displaying when that class equals the current class (as you suggested). And for future-protection you could continue to use |inherited= for this purpose. (It would be easy to use |auto={{{WikiProject Automobiles|{{{inherited|}}}}}} on relevant banner templates if it was decided later to combine the two parameters ... — Martin (MSGJ · talk) 12:07, 8 October 2009 (UTC)
I think you guys are overthinking things. There are any number of ways that a bot could auto assess an article, so rather than trying to cater for them all it would (IMO) be better to keep the wording for |auto= generic so that it fits any given situation. "This article was assessed automatically by a bot" is all you really need to say; if necessary, any specifics can be outlined more fully at WP:AUTOASSESS. That's what I was going for at {{Film}}, anyway. PC78 (talk) 16:44, 8 October 2009 (UTC)
I can keep using notes, it's no problem. But I'm getting mixed messages here, someone suggested last time to keep it all in the "auto" param =) –xenotalk 17:13, 8 October 2009 (UTC)
Yes, I don't see value in using separate parameters. And I agree with PC78. The schema I'd like would be something like this:
  • |auto=stub → "This article has been automatically assessed by a bot, as it uses a stub template".
  • |auto=inherit → "This article has been automatically assessed by a bot, because another banner on this page uses this class".
  • |auto=cheesecake → "This article has been automatically assessed by a bot, for some reason to do with cheesecakes".
  • |auto=yes → ???
What to do with |auto=yes is, IMO, the main question. Happy‑melon 19:54, 8 October 2009 (UTC)
As I intimated above, "auto=yes" will not be deprecated from its existing usage in the foreseeable future. –xenotalk 20:01, 8 October 2009 (UTC)
Actually, what I was suggesting is that we just use:
  • |auto=yes → "This article has been automatically assessed by a bot".
and not bother with any other parameters and/or variables, because it's suitably generic for whatever the bot is actually doing. The specifics aren't that important, IMO. PC78 (talk) 20:14, 8 October 2009 (UTC)
Simple is good... Consider this, though. When I do a job for a WikiProject I usually auto-stub first. So I find those articles that have a {{stub}} template and apply the stub class. Afterwards, I do the inheritance task. Now, if, during the inheritance task, I inherit the class of "stub"... What does that indicate? Probably that the inherited class is wrong! (Or that the article lacks a relevant stub template). Either way, it's a potential flag for action for projects that want to keep on top of these things... –xenotalk 20:38, 8 October 2009 (UTC)
What would your bot normally do in such a situation? PC78 (talk) 20:50, 8 October 2009 (UTC)
All projects thus far have wanted to still inherit anyway. My point was that if we use descriptors (auto=stub for 'class stub because we found a stub template' and auto=inherit for inheritance), then we can have a maintenance cat for the intersection of class=stub and auto=inherit. –xenotalk 13:22, 9 October 2009 (UTC)
How does the bot currently handle inherited assessments? Does it just give the assessment, or does it also add |auto=yes? PC78 (talk) 15:19, 9 October 2009 (UTC)
OK, based on the current run for WP:BIOGRAPHY the bot adds |auto=inherit whether or not the banner supports it? To reiterate what I said above, I don't think the banner should display a different message for each situation, because there are too many potential variations to cater for. What we could do is use different parameter values to populate different categories, which would still allow for the intersections you mention above. PC78 (talk) 19:34, 11 October 2009 (UTC)
Sure, this is something we should set in the bio template itself. Perhaps alongside this fix? –xenotalk 02:31, 13 October 2009 (UTC)

"FI" class, maybe?

It might be a bit of a burden, I know, but I was thinking that one of the purposes article assessments might be used most regularly for is selection of material for portals. I know I tend to use it when selecting items for the Christanity portal, for instance. In such cases, it might well be very useful to have a "Featured Image" class available, to make it easier to find and use the various relevant Featured Images. I acknowledge however that this might not be a function that would be used particularly often by other portals or projects I don't know as well. However, I am in the slow process of trying to help work on all the Christianity related portals, and I think having this option would probably help for all of them, and it might be useful for others as well. I'm not sure how many others might use the function, but it would be really useful for me. :) John Carter (talk) 23:21, 10 October 2009 (UTC)

It's not really something that needs to be implemented here. To create a new assessment class you would need to add support for it at {{class}}, {{classcol}} and {{classicon}}, then add a custom mask to {{ChristianityWikiProject}}. I support the idea in principle because it would certainly be useful for WikiProjects to be able to track featured content under their scope, but if it's done for Featured Pictures then it should also be done for Featured Sounds, Featured Topics, Featured Portals, and perhaps even Valued Pictures and Good Topics as well. PC78 (talk) 14:54, 11 October 2009 (UTC)
Personally I'm all for it. Headbomb {ταλκκοντριβς – WP Physics} 17:33, 11 October 2009 (UTC)
Some interesting discussion on that page, though as I've said in the past I'm opposed to the addition of "Type" alongside "Class" and "Importance/Priority". It's completely redundant. PC78 (talk) 17:47, 11 October 2009 (UTC)
Not completely redundant perhaps, and I admit to liking some aspects of the proposal. But I think the case for such a big change has yet to be made. — Martin (MSGJ · talk) 20:16, 11 October 2009 (UTC)
Well... that's a little o/t. :) WP Christianity could also keep track of Featured Pictures using notes rather than by adding a new assessment class. PC78 (talk) 20:53, 11 October 2009 (UTC)

It's redundant in the sense that it covers everything that was covered, and more. If that's your definition of redundant, my dual core is redundant of my long-forgotten pentium 4. It's not a trivial redesign of the banner, I'll concede that much, but in the long run, it's really the only thing that makes sense (IMO). Otherwise the banner becomes the limitation on what can be done, and will impede the growth of Wikipedia. What is not used can be left unused. For example, if a project isn't interested in assessing lists, they could still use "class=List" or "class=FL" rather than "class=B type=list" / "class=Featured |type=List". Headbomb {ταλκκοντριβς – WP Physics} 02:43, 13 October 2009 (UTC)

It's a needless over-complication; "Type" is already evident from a page's "Class". I'm assuming that you don't want to have the likes of "class=Start|type=template"? If this is solely for the assessment of list articles, then we have an existing assessment scale which is fit for that purpose. "Impeding the growth of Wikipedia"? That a little over dramatic, isn't it? :) PC78 (talk) 02:56, 13 October 2009 (UTC)
Well there are lists, but also sounds, images, books (soon to come), portals, videos, topics, lists, ... which could (and sometimes are) be assessed, and possibly more. If your concern is "|class=start |type=template" then you should equally be concerned with "|class=template |importance=high". And personally, if a project wants to assess it's templates, that's really up to them and not us. Headbomb {ταλκκοντριβς – WP Physics} 03:24, 13 October 2009 (UTC)
Templates don't need assessing, and we shouldn't encourage projects to do so. Nor do any of the other things you mention. Let's try and remember that we're supposed to be assessing articles. Besides a handfull of new classes to cover other featured/good content (and perhaps a Topic-Class), I really don't think we're missing anything. The cross referencing of "Type" and "Class" that you seem to be proposing throws up far too many unnecessary and undesirable variables, IMO. What are "Books"? PC78 (talk) 10:37, 13 October 2009 (UTC)
See Special:PrefixIndex/Wikipedia:Books for example (and Help:Books). [Also this wouldn't encourage the assessing of templates anymore that allowing the importance rating for template encourages the "importancing" of templates]. Headbomb {ταλκκοντριβς – WP Physics} 15:14, 13 October 2009 (UTC)
Also, while templates might not "need" assessing, the new Wikipedia:Article alerts function works on the basis of the pages in question either having the banner placed on them or being included in the categories generated by the banners, which, in effect, makes it more useful for the template to have some sort of parameter to use on them, even if only the extant NA. And again, whether for good or ill, I was thinking that many of the banners already have an "Image" class, and that the two other classes which have a "Featured" variant also have separate assessment grades for them, so adding this grade seemed at least to me to be sonsistent with the prior work done on the template. John Carter (talk) 17:26, 13 October 2009 (UTC)

The purposes of the assessment system are 1) to assist WP1.0 in selecting articles for static releases, and 2) to assist WikiProject members in prioritising their work. The purpose of WPBM's assessment code is to technically support the assessment system, and to minimise the administrative overhead associated with a project managing its slice of the assessment system. The purpose of the template is not to allow people to categorise things to an arbitrary precise degree, except where that furthers those two goals above.

Adding a |type= parameter multiplies the number of possible permutations of the assessment scheme by however many type values you allow; probably by around five or six times. Maintaining this very large number of possibilities significantly increases the administrative cost of the assessment system. What benefit does it provide? More importantly, how does it allow the limited resources of the WikiProject to be applied to a sufficiently better degree to outweigh the time cost of implementing the system? Saying that "a project isn't interested in assessing lists..." is disingenuous because you are not proposing a system that gives individual projects choice. This would be a change more akin to the C-Class introduction, something that would be possible, but difficult, for projects to opt out of. And recall the problems that those projects found with C-Class; except for a tiny handful of projects that run regular assessment drives, I'd say 95% of tag-and-assess is done by users who are not 'members' of the project they are tagging for. The C-Class optouts found that they were still accumulating large numbers of C-Class articles, because passing editors were 'helpfully' tagging them thus. With a change this extensive, it would be impossible for projects to opt-out entirely: either they implement the system and shoulder the increased administrative costs, or they shoulder the administrative costs anyway in keeping things the way they were. So the costs are unavoidable. Where are the benefits?

Happy‑melon 16:42, 13 October 2009 (UTC)

Concerning "objective 2)", if you want to prioritize work when you have >3 million pages to monitor (and I don't know how many category, books, topics, images...), you need a solid classification scheme. The encyclopedia consists of more than just the articles. There are categories, lists (also "articles" in a way), books, topics, and so on. If you introduce the type parameter, you can now assess lists, topics, books, and so on, thus allowing to identify which of them needs works. These are the benefits. And there is a demand for it.

Saying "if a project isn't interested in..." is not disingenuous in the least. Many project don't use the list-class. Some don't even use the "FA" and "FL" classes (Chemistry project comes to mind). Others don't tag their redirects. What I'm proposing gives no less a choice than Project already have. If you don't want to assess lists, don't assess them. If you don't want to keep track of topics, don't tag them with the banner. If you don't care about tagging templates, don't tag them.

For the C-Class opt out, if the passerby tagging of C-Class really is a problem, then hardcode a "C-Class = Yes" in the metabanner. If this isn't passed, then have the banner treat "|class=C" as "|class=Start". Problem solved, at no costs to WikiProjects. Headbomb {ταλκκοντριβς – WP Physics} 17:39, 13 October 2009 (UTC)
I'm not necessarily against a greater distinction of pages based on type, but after reading above comments, I am led to believe that it would be best to add support via an auxiliary template which then gets hooked into individual banners for projects which want the additional functionality. WPBM then still maintains its primary use - WP:1.0 quality/importance tracking - and projects that really want to go to the extra effort and trouble to assess their lists while still noting that they're lists (most common possible usage) have a simplish (simple-ish?) way to do it. And I still have no interest in actually pursuing any such system in the above linked RFC draft; as I've said more than once there, that is intended merely to help line up and polish all the little trinkets we're already juggling, not to add new ones on top of them. 「ダイノガイ千？！」? · Talk⇒Dinoguy1000 18:32, 13 October 2009 (UTC)
Your whole argument hinges on your first sentence: "if you want to prioritize work [in this environment], you need [this] classification scheme". I don't take that as axiomatic. What's your justification for that assertion? Why does a project being able to separate its featured images from its featured sounds (and from its other media) help it to more efficiently improve the encyclopedia? Happy‑melon 20:28, 13 October 2009 (UTC)
It was actually my proposal, and my reasons were, even if stated poorly, (1) better images on the portals will likely increase the number of featured portals, possibly increasing the amount of traffic to those portals, and, thus, by extension, to the articles relevant to the portal, which should benefit the project, and (2) it seemed to me with the existing FA grade along with other articles grades, and the L/FL grading, that, given there already is an "Image" class, an "FI" class might be seen as a logical extension of that. I never even thought of bringing all the others mentioned above in. John Carter (talk) 20:56, 13 October 2009 (UTC)
Actually, I think the thread has drifted far away from that original proposal, which is considerably more focused.
I agree that tracking featured content is an area where the benefits would outweigh the administrative cost. Fortunately, most types of featured content (articles vs media vs portals) can be distinguished by namespace, provided that all a project's featured content can itself be identified. Would a |featured=yes parameter, displaying a message that adapts by namespace, be an effective solution? Happy‑melon 21:22, 13 October 2009 (UTC)
That would work fine by me. John Carter (talk) 21:57, 13 October 2009 (UTC)
Since we already have FA and FL classes, it would seem simpler to add a new class for featured pictures rather than adding a new parameter (unless we are running with Headbomb's proposals). I think there is little need to track portals using WikiProject banners (typically there is no more than a one or two portals within a project's scope - it's hardly going to be hard to keep track of which of them are featured). I can see the use of keeping track of featured pictures though (I think I even suggested it somewhere) but would prefer FP to FI, or perhaps FM for Featured Media if sounds are to be included as well. — Martin (MSGJ · talk) 12:12, 14 October 2009 (UTC)
I've found where it came up before. There were some reservations about FP-class because of the ambiguity between Pictures/Portals. FF-class (Featured file) was also suggested by Dinoguy over there. — Martin (MSGJ · talk) 12:17, 14 October 2009 (UTC)
Heh, I remember that... *imagines a new user seeing "FF-class page" and thinking "wait, this page is Final Fantasy class?"* XD (oh, and I still want to do something with Featured Templates, but I'm hopelessly unmotivated) 「ダイノガイ千？！」? · Talk⇒Dinoguy1000 19:29, 14 October 2009 (UTC)
If we're going to go down that line, I'd support FM. I doubt we're ever going to set up Wikipedia:Featured MediaWiki system messages.... :D
Featured Templates? Nice idea, but utter hell to set criteria for. Which is most elegible for featured-ness, {{ambox}}, {{str sub}} or {{!}}? :P Happy‑melon 22:22, 14 October 2009 (UTC)
Actually, I like to think about a possible FT process, and I do have a usable set of criteria, I think, though they probably need further polishing. When I have more time, maybe I'll start a subpage draft in my userspace (teaser: any template, regardless of complexity, could be nominated as long as it's got clean, bug-free source or is well-maintained and is reasonably well-used... or something - like I said, needs polishing). =) 「ダイノガイ千？！」? · Talk⇒Dinoguy1000 22:26, 14 October 2009 (UTC)
Can't say I'm terribly enthusiastic about "Featured Media" because it's an invented term. I was actually thinking that HM was on the right track with his previous suggestion. PC78 (talk) 22:32, 14 October 2009 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:WikiProject_banner/Archive_7&oldid=1182522518"