Module talk:WikiProject banner/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

→

Archive 14

Category:WikiProject banners with formatting errors

Does anyone know how to remove /monobook.js pages from this category?

Also, does anyone know what's going on with {{WPBiography}} at Wikipedia:WikiProject Musicians/Infobox? PC78 (talk) 01:50, 14 October 2009 (UTC)

Something odd with the bullet points. Works if I remove them. -- WOSlinker (talk) 07:03, 14 October 2009 (UTC)

 Fixed the monobooks. — Martin (MSGJ · talk) 12:05, 14 October 2009 (UTC)

Idle thoughts about category opt-out

It appears that the category opt-out can be enabled with so much as a blank |category= parameter. Is that wise? Would it not be preferable to do this with a more explicit |category=no or something?

Also, would it necessarily be a good idea to use something like |category={{{category|{{#ifeq:{{NAMESPACE}}|User talk|no|¬}}}}} in a banner's code? I recently removed a number of {{WPBiography}} banners from user space, and the main culprit appeared to be userfied articles. I was thinking it would be nice force the opt-out in that namespace. PC78 (talk) 11:30, 2 September 2009 (UTC)

Regarding your first point, this is intentional and a lot of work has been put into it (e.g. the whole changing µ to ¬ - see Template talk:WPBannerMeta/Archive 2#Category optout transition). I must admit that the reason for doing this has always escaped me. — Martin (MSGJ · talk) 11:49, 2 September 2009 (UTC)

Why did we transition, you mean? Because μ != µ, and that was totally impossible to test for. At least there is only one character that looks anything like ¬. Happy‑melon 22:28, 2 September 2009 (UTC)

Yes, I know why we did the transition. But I don't know why we use ¬ or μ at all. Why don't we just pass category={{{category|}}}? That's what I have never got my head around. — Martin (MSGJ · talk) 07:30, 3 September 2009 (UTC)

It's just a more rigorous way of doing it, it preserves the greatest amount of information about what's been set at the other end. We are able to do all that cool stuff with {{yesno}} and enabling things simply by passing parameters, because we preserve the distinction between undefined and defined-as-blank. We don't have to use the distinction if we don't want to, but it's very useful to have it there. Happy‑melon 14:27, 3 September 2009 (UTC)

Yes, but all that functionality can be achieved by putting the ¬ on Template:WPBannerMeta rather than each banner template. The only extra thing we gain is by being able to distinguish between an undefined and a defined blank value of category on template instances, correct? And as PC says, it may not be desirable that |category= should supress categories (as it may have just been copied from the documentation or something). — Martin (MSGJ · talk) 15:22, 3 September 2009 (UTC)

I was talking about the general case. |category= is the only use of the system where the 'end' of the chain is on the individual banner instances, not on the banner template pages themselves. The prerequisites for the system are that every step in the chain between the place where the switch occurs, and the final code that uses it, have to have the same default value, and that value is indistinguishable from the undefined parameter. For, say, |importance=, it is important that that value not be the empty string, because that's a legitimate value for the parameter that we need to account for. For |category=, I agree that it might be beneficial to treat blank as equivalent to undefined, but I think it would be a bad idea to lose the consistency of "all parameters where we care about the defined status use default ¬" that we currently have. It's fairly easy to change the behaviour of |category= by replacing all the {{#ifeq:{{{category|¬}}}|¬|...}} we currently have with {{#switch:{{{category|¬}}}||¬=...}}; it's only three extra bytes. Happy‑melon 16:42, 3 September 2009 (UTC)

I agree that using ¬ to determine the defined status of parameters is a good idea. I still don't understand why |category= is used differently to other parameters (i.e. the "end of the chain" is on banner instances). Would there be any disadvantage in making it more consistent and not requiring it on the banner templates? (I'm not proposing a mass removal of them, but we could simplify the syntax for new ones at least.) — Martin (MSGJ · talk) 11:12, 4 September 2009 (UTC)

Not sure what you're saying here. The reason "the end of the chain is on banner instances" is that we want to set the category optout for individual instances, not for every instance of the banner. |category= is more similar to |listas= than |importance=. You mean that, on banner templates, we ask users to set |note 1={{{note 1|}}}, but |category={{{category|¬}}}?? Happy‑melon 12:08, 4 September 2009 (UTC)

Correct, we don't care whether |category= is undefined or defined blank, just as we don't care whether |listas= is undefined or defined blank. — Martin (MSGJ · talk) 12:29, 4 September 2009 (UTC)

So back to this ... would there be any opposition to treating a blank category parameter the same as category=¬, and to stop requiring the use of |category={{{category|¬}}} in favour of |category={{{category|}}}? I don't propose we mass-change them, but we could make things a simpler for future banner templates and reduce the work for PC78 going through the tracking category removing instances of blank category parameters. — Martin (MSGJ · talk) 12:54, 29 September 2009 (UTC)

 Review There is a version on the /sandbox which does this. I also think we should probably treat |category=yes the same as the blank parameter (it ought to mean "yes, I want categories!"). What do others think? A couple of other proposed changes as well:

• Moved the code for the warnings back onto the main template, and put the actual message boxes on separate subpages. This is how it used to be, and on reflection I think this is better. We don't need to transclude /warnings on every instance of the template.
• Removal of the FULL_QUALITY_SCALE parameters as they are not used now.
• Tweak so that if neither priority nor importance parameters are passed then the scale name (for task force use) is "Importance".

Comments invited. — Martin (MSGJ · talk) 10:28, 7 October 2009 (UTC)

Anyone? — Martin (MSGJ · talk) 19:00, 11 October 2009 (UTC)

I've implemented this now. — Martin (MSGJ · talk) 14:33, 15 October 2009 (UTC)

Another thought

When I implemented a category opt-out for {{Film}} I added (and not without a sense of irony) a tracking category so it was possible to keep tabs on where and how |category= was being used, basically to guard against any potential misuse of the parameter. I was wondering if something similar might be of value here? Martin suggested elsewhere that demonstration banners shouldn't be used on article talk pages and I'd say that's about right, so perhaps a category to pick up any that are or might be? Just a thought. PC78 (talk) 17:58, 7 September 2009 (UTC)

Sounds reasonable. Are you volunteering to sort through this category? :P — Martin (MSGJ · talk) 08:07, 8 September 2009 (UTC)

If it's just looking for banners of article pages then [1] would be able to find them all without the need for a category. -- WOSlinker (talk) 10:48, 8 September 2009 (UTC)

No, what PC is suggesting is a tracking category for instances of |category=no in article talk space, i.e. where there should probably be no demonstrations of templates. We already have Category:WikiProject banners with formatting errors which tracks down banners in subjectspace without category=no. — Martin (MSGJ · talk) 12:18, 8 September 2009 (UTC)

Can we do this then? I'm not adverse to a bit of cleanup... :) PC78 (talk) 17:29, 13 September 2009 (UTC)

You mean "averse" :) I've added it to the to-do list. — Martin (MSGJ · talk) 07:19, 14 September 2009 (UTC)

I've put the code in /sandbox. At the moment it will include blank definitions category. Can you check this is what you want? — Martin (MSGJ · talk) 12:21, 22 September 2009 (UTC)

What does one do if a talk page banner, for whatever reason, is supposed to be displayed in those circumstances with |category=no?? :P Happy‑melon 12:40, 22 September 2009 (UTC)

Lol, you've got me stumped there. — Martin (MSGJ · talk) 12:42, 22 September 2009 (UTC)

You talkin' to me? Yeah, it seems to. If it's trivial to implement then it's also trivial to undo, so I say do it and see what it throws up (if anything). If it throws up any false positives then we can worry about it later. Should Category:WikiProject banners with formatting errors not be a hidden category, though? PC78 (talk) 21:50, 22 September 2009 (UTC)

 Done. I think originally that category was intended for errors just to banner templates. In those cases, it's probably better to draw attention to an error condition. Now it's being used for all sorts of purposes; probably should have a separate category for banner instances ... — Martin (MSGJ · talk) 22:03, 22 September 2009 (UTC)

I've already fixed banners seven or eight pages; main culprits so far have been {{GOCE}} (I've ammended the template documentation, but this doesn't strike me as being something that needs to use this meta) and {{WikiProject Marine life}}, where someone has been using the parameter for something completely different. PC78 (talk) 23:41, 22 September 2009 (UTC)

I notice that WOSlinker did quite a bit of work on Template:WikiProject Marine life in March, probably to do with this category parameter. (And then it seems that I "tidied" messed up his work in July.) — Martin (MSGJ · talk) 09:32, 23 September 2009 (UTC)

Yikes, there are now around 150 pages in the category! A lot of this appears to be the work of a single editor who has unwittingly copied some bad code from another talk page and pasted it en masse. I've already raised the issue with him. PC78 (talk) 20:00, 23 September 2009 (UTC)

Well done for clearing this out. Do you want to continue this tracking permanently, or shall we remove it? — Martin (MSGJ · talk) 18:52, 7 October 2009 (UTC)

Keep it. It may be a recurring problem. PC78 (talk) 18:59, 7 October 2009 (UTC)

Signpost article, redux

Lest anyone think I've forgotten...

I've put together a few questions at Wikipedia:Wikipedia Signpost/Newsroom/WikiProject report/Meta banner; any responses, both from the developers of the template and from anyone else with insight into the topic would be very appreciated. Thanks! Kirill ^[talk] [pf] 02:51, 13 October 2009 (UTC)

Just to follow up, if everyone could get their answers in by Sunday, that would be great! Kirill ^[talk] [pf] 12:33, 16 October 2009 (UTC)

Collapsed notes

Just a(nother) thought, but in the interests of keeping "small" banner small, could the default value for |COLLAPSED= be fixed as 0 if |small=yes? PC78 (talk) 10:42, 24 September 2009 (UTC)

Yes, this is a good idea. Is 0 preferable to 1 though? — Martin (MSGJ · talk) 13:40, 29 September 2009 (UTC)

I'd say so. I know at Template talk:WikiProject Korea you argued that "It is rarely useful to collapse one row, because the header of the section takes up the same amount of space and so information is hidden without any space saving", but a single row of text in a normal banner might equal three rows in a small banner, so collapsing one row would almost always save space. PC78 (talk) 16:09, 8 October 2009 (UTC)

Okay agreed. In that case, it's probably worth putting that code on /core to avoid having to put {{{small}}} through the yesno template twice. Is there anything else worth changing on small templates while we're here? — Martin (MSGJ · talk) 16:16, 8 October 2009 (UTC)

← B-Class checklists in small banners are pretty ghastly, though I don't have any quick fixes to offer. Something else I touched on elsewhere, it may not be worth bothering with but I'll mention it anyway. Using |small=¬ results in a curious mish mash of normal and small, for example:

That's all I can think of. :) PC78 (talk) 17:22, 8 October 2009 (UTC)

Clearly, the copy-paste thing for the syntax should not appear on small templates; that should go some way to fixing it. I had also noticed the small=¬ thing myself. I will look into it, but as no one will type small=¬ it's not a huge problem! — Martin (MSGJ · talk) 22:39, 8 October 2009 (UTC)

My understanding of HTML is a bit limited. How is the copy/paste thing placed in a seperate column? I can't tell from looking at the code. Also, where is {{WPBannerMeta/bchecklist/b}} used? PC78 (talk) 17:00, 17 October 2009 (UTC)

It's the <td> which starts a new cell, but from a quick glance, it seems we might be missing a closing </td> in there which might explain the problems we've been having with this code ... ? {{WPBannerMeta/bchecklist/b}} is currently used by {{WPBannerMeta/class}} but could perhaps be replaced by {{yesno}} at some stage. — Martin (MSGJ · talk) 21:51, 18 October 2009 (UTC)

Got some code in the sandbox for the |COLLAPSED= thing. Could you check it when you get a change? — Martin (MSGJ · talk) 11:02, 19 October 2009 (UTC)

This? Looks OK to me. :) I think you're right about the missing </td>, but I'll have to leave it to you to figure out where it goes. PC78 (talk) 20:30, 19 October 2009 (UTC)

 Implemented — Martin (MSGJ · talk) 10:28, 20 October 2009 (UTC)

I've made some changes in {{WPBannerMeta/bchecklist/sandbox2}} to improve the layout in small banners, though it still stretches the box. PC78 (talk) 12:58, 27 October 2009 (UTC)

It's definitely an improvement. But basically I think it is unreasonable to expect the B-class checklist to work properly in the small format because there just isn't room for it. Did you try removing the pre section? — Martin (MSGJ · talk) 17:05, 27 October 2009 (UTC)

I've tweaked the sandbox. What do you think? — Martin (MSGJ · talk) 21:27, 27 October 2009 (UTC)

I did consider it, but thought it might be appropriate to leave it in, perhaps in a reduced format. I don't have any strong opinions either way, though. PC78 (talk) 11:03, 28 October 2009 (UTC)

Template is transcluding core/sandbox

See Martin's last edit; I'm pretty sure that's not intentional. :) PC78 (talk) 23:05, 15 October 2009 (UTC)

Sorry. I've done that several times now. Happy-melon fixed it. — Martin (MSGJ · talk) 09:53, 16 October 2009 (UTC)

Mmmm, experimental functionality, anyone? :D Happy‑melon 13:32, 16 October 2009 (UTC)

Hopefully this will prevent it happening again! — Martin (MSGJ · talk) 10:59, 19 October 2009 (UTC)

TOC and comments transclusion issue

The code for {{WPBannerMeta/comments}} ends with

}}</td></tr>}}}}

which causes the TOC for the Talk page to be included in the collapsible window for the comments in the banner (See WPAVIATION banner on Talk:UH-1 Iroquois). The code is missing a closing html tag for the table and should look something like:

}}</td></tr></table>}}}}

--Born2flie (talk) 13:08, 1 October 2009 (UTC)

There is no error in the /comments code. TOCs on comments subpages are a common problem and there are two ways to solve the problem:

1. Don't use any headers on comments subpages.
2. Specify the position by placing __TOC__ below the project banners. (That's what I have ust done to that page.

— Martin (MSGJ · talk) 16:14, 1 October 2009 (UTC)

Okay, guess I misinterpreted the problem with one I had on another template. Wikimedia includes the TOC prior to the first section heading, unless __TOC___ is inserted elsewhere in the page, right? That can be problematic when you have more than one project utilizing WPBannerMeta for their banners, otherwise you could just include the TOC code as part of the template closing. I guess if there was a function to see if another banner was downstream in the text, it could add the TOC code as part of the closing if it was the last template... --Born2flie (talk) 03:35, 5 October 2009 (UTC)

You're right, adding to the bottom of the WPBM code would not work. But adding it to {{WikiProjectBannerShell}} might be an idea worth exploring ... — Martin (MSGJ · talk) 07:07, 5 October 2009 (UTC)

The rest of this discussion has been moved to Wikipedia talk:Discontinuation of comments subpages to centralise. — Martin (MSGJ · talk) 17:26, 7 November 2009 (UTC)

Template:Stubclass

Since the conversion of {{WPBiography}}, transclusions of {{Stubclass}} have dropped significantly to less than 4,500. A quick sampling of what's left suggests that the main culprits are WP:SONGS and WP:VIRGINIA. Could someone enable auto assessments in both {{Songs}} and {{WikiProject Virginia}}, then we could see about having a bot go through Category:Automatically assessed song articles and Category:Automatically assessed Virginia articles to replace {{Stubclass}} with |auto=yes? PC78 (talk) 13:40, 24 October 2009 (UTC)

I can do this with consensus from the projects. –xeno^talk 13:45, 24 October 2009 (UTC)

You're right, of course. I'll leave a message on each banner talk page. PC78 (talk) 14:19, 24 October 2009 (UTC)

You're unlikely to get any response on the template talk page. You might have more luck if you try the project talk page. — Martin (MSGJ · talk) 16:28, 28 October 2009 (UTC)

Do you think it's necessery, though? PC78 (talk) 11:28, 29 October 2009 (UTC)

I'm kinda busy over the next week and a half so I'm not sure how quickly I can get to this, or the bio workground thing. I've just moved the threads to the project talk page proper and if no one replies then I'd say we have tacit consensus to run the task. –xeno^talk 12:52, 29 October 2009 (UTC)

auto parameter added to both banners. No response on either of the talk pages. — Martin (MSGJ · talk) 17:17, 7 November 2009 (UTC)

Thanks, I'll see about having the {{Stubclass}} templates replaced in those categories. PC78 (talk) 18:46, 9 November 2009 (UTC)

B-class checklist again

File:B-checklist still screwy.jpg

Yes, the B-checklist is still as screwed up as ever on Internet Explorer. Thought Happy-melon had sorted this ... Why can't it line up with the others? — Martin (MSGJ · talk) 20:41, 24 September 2009 (UTC)

It's not quite right (though not as bad) on FF. PC78 (talk) 20:51, 24 September 2009 (UTC)

8-O What browser is that!?! Happy‑melon 21:17, 24 September 2009 (UTC)

That's IE8. — Martin (MSGJ · talk) 21:34, 24 September 2009 (UTC)

Looks like that on IE7 as well. PC78 (talk) 21:43, 24 September 2009 (UTC)

Eww... I can make it somewhat better by removing the 100% width from the <table> element in {{WPBannerMeta/bchecklist}} (the usual IE Box Model Bug), but I have a nasty suspicion that that's going to make it crush on Chrome. What's going on in {{WPBannerMeta/bchecklist/sandbox}}?? Happy‑melon 21:51, 24 September 2009 (UTC)

Poke... anything important going on in that sandbox? Happy‑melon 13:49, 2 October 2009 (UTC)

Sorry, no, go ahead. — Martin (MSGJ · talk) 13:52, 2 October 2009 (UTC)

Ok, does Template:WikiProject Firearms/testcases look better now? It looks ok to me on FF and IE7, anyone have Chrome and/or Safari to look at it? Happy‑melon 12:29, 3 October 2009 (UTC)

The B-class checklist show links butt right up against the text in Chrome 3, then jump out to the right when the list is shown. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:04, 3 October 2009 (UTC)

Any better? Happy‑melon 10:13, 6 October 2009 (UTC)

Looks fine on IE. I can check Chrome when I get home. — Martin (MSGJ · talk) 10:19, 6 October 2009 (UTC)

Nope, Chrome 3 still behaves the same. Checking more carefully, the show/hide link sticks to the right side of the collapsible cell, which means that the cell is collapsing horizontally as well as vertically when the content gets hidden. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:27, 6 October 2009 (UTC)

Why do all the other collapsed boxes seem to work consistently on all browsers, but we can't get this one to work?? Is there a way we could make the B-checklist more like the other boxes? (I wouldn't mind losing the icon if it would make it work!) I can envisage making /collapsed more generic and using it for all the collapsed boxes to keep the code centralised. — Martin (MSGJ · talk) 11:18, 8 October 2009 (UTC)

I honestly don't know why this implementation doesn't work on Chrome, but normal mboxes do; the underlying code is virtually identical. I suppose we could put the inner code in a separate table, that might help. Happy‑melon 12:30, 8 October 2009 (UTC)

Worth a try ... ? — Martin (MSGJ · talk) 22:35, 8 October 2009 (UTC)

Have you given up with this? ;) — Martin (MSGJ · talk) 10:36, 24 October 2009 (UTC)

I've just been very busy the past week. I'll get round to poking at it eventually... Happy‑melon 10:59, 24 October 2009 (UTC)

Poke ... :) And I have been thinking, perhaps it would be better if support for the B-class checklist was moved into a hook. It would take a lot of weight off the main code, and it isn't used by many banners. Of course, it would mean that those projects would need to use a custom mask, but I think that a lot of them probably do anyway ... what do you think? — Martin (MSGJ · talk) 17:10, 7 November 2009 (UTC)

I've started Template:WPBannerMeta/hooks/bchecklist as a trial and will try to assess if moving over to a hook is a good idea. — Martin (MSGJ · talk) 17:44, 13 November 2009 (UTC)

Support for an image-needed parameter

I've had some time to start thinking about adding native support for a parameter to indicate that an article needs an image, along the same lines as the current attention and infobox parameters. The idea is, although this can easily be encoded as a note in each banner template, there are so many projects which use a parameter like this that it is worthwhile to support it here. Here is what I've come up with so far:

The parameters I am thinking about are:

• image - a simple yes/no parameter to trigger the note.
• image-location - an optional parameter to specify location which modifies the wording and the category.
  • E.g. North Korea in the example above would categorise into Category:Wikipedia requested photographs in North Korea.
  • Banner templates could simply pass image for this parameter, so that |image=North Korea would both trigger the note and specify the location in one go.
• IMAGE_CAT - a default category for the articles.
  • E.g. if Category:Wikipedia requested photographs in Seoul does not exist, then the default Category:Wikipedia requested photographs in Korea is used.

What do people think? I'm not quite sure about the wording yet. — Martin (MSGJ · talk) 16:02, 28 October 2009 (UTC)

Just wondering about the choice of image. Should it be the same as the {{Reqphoto}} template? -- WOSlinker (talk) 19:10, 28 October 2009 (UTC)

Some banners have an extra {{{imagedetails}}} parameter to add extra image comments, see {{WikiProject Denmark}} for an example. -- WOSlinker (talk) 19:26, 28 October 2009 (UTC)

Yeah, I have seen that as well. I wonder if that is really a useful feature though ... — Martin (MSGJ · talk) 22:41, 28 October 2009 (UTC)

Here's a little table of what images are currently used: -- WOSlinker (talk) 19:36, 28 October 2009 (UTC)

Image	Templates using Image
	[2]
	[3]
	[4]
	[5]

Thanks WOS, that's helpful. I was thinking that an image is not always a photo (it could be a diagram, screenshot, etc.) and so perhaps a camera icon is not always appropriate? — Martin (MSGJ · talk) 22:42, 28 October 2009 (UTC)

Anti-archiving-bot message as I'm still hoping to find the time to look at this. — Martin (MSGJ · talk) 17:52, 11 November 2009 (UTC)

File-Class

I see the meta still defaults to Image-Class rather than File-Class. Can we change this behaviour? PC78 (talk) 09:09, 22 November 2009 (UTC)

All it would require is a simple change to Template:class mask, if there was consensus for it. There would be 683 categories that would need creating and another 683 to be deleted though. — Martin (MSGJ · talk) 09:19, 22 November 2009 (UTC)

Could it not be done without disturbing the current categories? We can use custom masks to accomodate banners using Image-Class much like we did when Redirect-Class was removed from the extended quality scale. PC78 (talk) 09:25, 22 November 2009 (UTC)

But then you have 600+ custom class masks to implement. And for what benefit? — Martin (MSGJ · talk) 16:46, 22 November 2009 (UTC)

I doubt it would be that many. The benefit would be in having the meta default to the correct name of the class, and it's an obvious first step towards the end goal of standardisation. PC78 (talk) 16:58, 22 November 2009 (UTC)

The best way forward with this, if you wanted to pursue it, would be to open a discussion somewhere appropriate (e.g. WP:VPPR or WT:COUNCIL) and propose that Image-class be renamed to File-class by default. Assuming it receives support, we'd need to employ an adminbot to create and delete the categories. Any projects that actually wanted to retain Image-class could do so with a custom class mask. I wouldn't oppose any of this, but I don't anticipate having enough time to help. — Martin (MSGJ · talk) 18:52, 22 November 2009 (UTC)

I'm not sure why changing the default should require such a discussion. The class has already been renamed, which is why {{class}} only outputs "File" and why {{Image-Class}} redirects to {{File-Class}} -- this was all done some time ago. The only thing that should require a centralised discussion is the mass migration of categories, and that's not what I'm proposing (yet, anyway). PC78 (talk) 19:03, 22 November 2009 (UTC)

You may be right, I just prefer to play safe and it never hurts to start a discussion. Redirecting Template:Image-Class was a bold edit which was never reverted. I think however, that some form of discussion would be needed to confirm this before any mass-renaming of categories or mass-implementation of custom masks can be done. Making a bold edit to a template which affects thousands of pages is fine because it can be easily reverted. 600 edits are not so easily revertable. By the way, you are wrong about Template:class only outputting "File". — Martin (MSGJ · talk) 19:18, 22 November 2009 (UTC)

Ah, yes, not sure where I got that from. Hmmm, I'll mull things over a bit then. PC78 (talk) 19:38, 22 November 2009 (UTC)

A few side queries:

1. Does Category:WPBannerMeta templates using custom classes only contain banners with a /class subtemplate? If so, can it be extended to include banners using an inline custom mask?
2. Can a tracking category be added for banners using the extended quality scale?

-- PC78 (talk) 00:05, 23 November 2009 (UTC)

Yes to both. And it is possible to do those changes yourself if you want to in /templatepage -- WOSlinker (talk) 07:58, 23 November 2009 (UTC)

Done, but someone might want to double check it. PC78 (talk) 10:15, 23 November 2009 (UTC)

This should work as well. — Martin (MSGJ · talk) 10:59, 23 November 2009 (UTC)

Task force assessments

Question: if a banner uses the extended quality scale, is it possible for task forces to use the standard scale or must they always use the same? PC78 (talk) 18:09, 24 November 2009 (UTC)

You would have to move the taskforce into a separate hook and then set |QUALITY_SCALE=standard for that hook. All taskforces in the same hook use the same scale. — Martin (MSGJ · talk) 18:16, 24 November 2009 (UTC)

Nested importance

When placed in {{WikiProjectBannerShell}} only the class is shown (importance is left out)

What gives? Headbomb {^ταλκ_{κοντριβς} – WP Physics} 21:37, 12 October 2009 (UTC)

Because you are using a custom importance scale. — Martin (MSGJ · talk) 21:40, 12 October 2009 (UTC)

The other issue is that you shouldn't be using importance with a capital I. -- WOSlinker (talk) 22:20, 12 October 2009 (UTC)

Well there should be a way recognized importance when the custom hooks (whatever hooks are) are used. It's only adding "no" and "bottom". I could write some proto-code, but I cease to be able to understand the metabanner whenever the word hook is involved. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 02:29, 13 October 2009 (UTC)

As always, the functionality that goes into the meta banner is a balance between providing functions that are useful to a lot of banners without adding too much complexity for the sake of a few banners. It was decided in this case that implementing "native" support for custom importance scales was not justified because

• there are relatively few projects which use a different importance scale, and
• it is fairly easy to add the functionality using a hook (alas without the nested importance feature).

On reflection I still think this decision is right. The astronomy banner is not broken in any way, it just lacks a feature which is available to projects using the standard importance scale. — Martin (MSGJ · talk) 09:49, 13 October 2009 (UTC)

Nested banners get the class rating from custom masks, right? Presumably it's not as straightforward for custom importance... ? PC78 (talk) 10:41, 13 October 2009 (UTC)

It wouldn't take too much to add a HOOK_IMPORTANCE_NESTED hook though. (Similar to HOOK_NESTED for taskforces.) -- WOSlinker (talk) 12:50, 13 October 2009 (UTC)

I've retrieved this from the archive, because this is something that WikiProject Comics has asked for as well. What do people think about implementing HOOK_NESTED_IMPORTANCE? It's not going to be too difficult or complicated to do, and it would make a few projects happy. — Martin (MSGJ · talk) 13:47, 13 November 2009 (UTC)

After a bit of puzzling around, I've got a demo ready at Template:WPBannerMeta/testcases with Template:WPBannerMeta/test2 using a custom importance scale. -- WOSlinker (talk) 20:10, 13 November 2009 (UTC)

Also needed to create a new hook template called Template:WPBannerMeta/hooks/customimportancenested. -- WOSlinker (talk) 20:16, 13 November 2009 (UTC)

Also spotted that Template:WPBannerMeta/hooks/customimportance should allow the |small= parameter to be passed through. -- WOSlinker (talk) 20:22, 13 November 2009 (UTC)

Why? — Martin (MSGJ · talk) 17:05, 16 November 2009 (UTC)

Compare the importance on these two template (Cricket is using the customimportance hook)

-- WOSlinker (talk) 19:07, 16 November 2009 (UTC)

 Done. There's just a couple of things I'm wondering about:

• Your /customimportancenested hook duplicates a lot of the code from /customimportance. Is there a better way to do this?
• It would be nice, if possible, to allow for a hook to insert anything we want into the assessment part of the nested text. For example Template:FAOL adds some nested text, and it might be good if that was aligned as with other banners. Is there a way to do this which would also support the nested importance?

— Martin (MSGJ · talk) 10:27, 18 November 2009 (UTC)

I've changed Template:WPBannerMeta/hooks/customimportance/sandbox to use Template:WPBannerMeta/hooks/customimportancenested, so there is less duplication. -- WOSlinker (talk) 19:22, 18 November 2009 (UTC)

The custom importance mask has now been moved to Template:importance mask and I'm wondering if we can deploy it for the whole template instead of Template:WPBannerMeta/importance so that the code is centralised. This would then mirror the way that Template:Class mask is used. — Martin (MSGJ · talk) 20:21, 20 November 2009 (UTC)

You could make importance work the same way class does with the option of setting IMPORTANCE_SCALE to inline or subpage. Also, if you switch over to importance mask, since it uses pagetype rather than WPBannerMeta/class to detrmine NA, could probably call it once in WPBannerMeta rather than five times WPBannerMeta/core. -- WOSlinker (talk) 08:59, 21 November 2009 (UTC)

The importance calls can definitely be moved to the main template. About the custom importance ... we have discussed this before. Last time I wasn't really in favour of the idea because of all the complications about calling the class mask. Now that this doesn't happen, I suppose there is no reason not to ... — Martin (MSGJ · talk) 10:00, 21 November 2009 (UTC)

Implementation

1. I suppose the next step is to use {{Importance mask}} in WPBannerMeta/importance. I've done a version in the sandbox and some testcases. If no importance is passed, the result is slightly different in that it returns ¬ rather than Unknown but if importance is blank then the result is the same with Unknown.
2. Then the next step would be to use it on the base template page, [6]
3. And finally to remove the use of it within /core, [7]

Futher changes could be made later on for taskforce importances. I've also modified Template:WPBannerMeta/test2 to use the inline version for testing.

|IMPORTANCE_SCALE      = inline
 |importance={{importance mask | {{{importance|}}} | {{{class|}}} | bottom=yes}}

Any thoughts? -- WOSlinker (talk) 19:03, 21 November 2009 (UTC)

This looks good. I've made a couple of changes to /importance/sandbox. If that looks okay we could start with the first step. — Martin (MSGJ · talk) 17:52, 22 November 2009 (UTC)

I've mode one more change to /importance/sandbox for the class param. All looks ok to me. -- WOSlinker (talk) 18:15, 22 November 2009 (UTC)

Okay, thanks for spotting that one. It would be nice to standardise these parameters on the importance and class masks. My suggestion is that the most relevant parameter (i.e. the class on class masks and the importance on importance masks) is the only unnamed parameter and all others should be named. But this is a minor detail for the future. I've now implemented step 1 and we can move forward if everything is looking okay. — Martin (MSGJ · talk) 18:35, 22 November 2009 (UTC)

All done I think, hopefully without any issues! A couple of things still to do or think about:

• Turn off prompts for importance categories when IMPORTANCE_SCALE = inline or subpage
• What about setting the importance scale for taskforces? Presumably the same importance scale should be used. Should we also normalise these on {{WPBM}} then, rather than /core?
• What about setting the importance scale for hooks, e.g. /taskforces and /qualimpintersect?

— Martin (MSGJ · talk) 22:28, 22 November 2009 (UTC)

For the builtin taskforces, would just need to move the calling of /importance from /core to main and add in the IMPORTANCE_SCALE paramter for them. Yes, those other two things need looking at as well. Also, once all that is done, most of the banners using HOOK_ASSESS could be changed to just use the WPBannerMeta features directly. -- WOSlinker (talk) 22:37, 22 November 2009 (UTC)

Just wondering if it is worth passing importance as a param to the custom importance pages (similar to class) as otherwise may be confusing for some people. (Took me a little while to work it out as well). Otherwise we will need to use masks such as:

{{importance mask
 |1={{{1|}}}
 |class={{{class|}}}
 |bottom=yes
}}

rather than

{{importance mask|{{{importance|}}}
 |class={{{class|}}}
 |bottom=yes
}}

WOSlinker (talk) 23:06, 22 November 2009 (UTC)

I do see what you mean and I agree that it might cause confusion. I wonder what the best way is? Maybe we should just use named parameters throughout. I don't really mind how it is done, as long as it is consistent and also reasonably logical. — Martin (MSGJ · talk) 16:36, 23 November 2009 (UTC)

Not really sure which is the best option. -- WOSlinker (talk) 19:01, 23 November 2009 (UTC)

Well, if neither of us has come up with the perfect solution soon I'll just add your suggestion. — Martin (MSGJ · talk) 22:13, 23 November 2009 (UTC)

I've now got the changes for qualimpintersect ready at Template:WPBannerMeta/hooks/qualimpintersect/sandbox and Template:WPBannerMeta/hooks/qualimpintersect/core/sandbox. Hope it's ok. -- WOSlinker (talk) 19:01, 23 November 2009 (UTC)

Think we can do without the /formats page now. Can you check my changes? — Martin (MSGJ · talk) 22:13, 23 November 2009 (UTC)

Nearly there. I've made some more changes, so back over to you to check. -- WOSlinker (talk) 00:10, 24 November 2009 (UTC)

Looks good,  Done — Martin (MSGJ · talk) 07:27, 24 November 2009 (UTC)

WOS, you've put "Use WPBannerMeta/importance on main rather than core for taskforces" on the to-do list. Could you just explain why this is preferable? It might be more consistent with the main importance, but it seems slightly inefficient because we will be normalising every importance parameter even when they are not used ... — Martin (MSGJ · talk) 13:45, 27 November 2009 (UTC)

Ok, I've changed it to "Implement IMPORTANCE_SCALE for builtin taskforces". -- WOSlinker (talk) 16:13, 27 November 2009 (UTC)

 Review — Martin (MSGJ · talk) 16:28, 27 November 2009 (UTC)

Yes, that looks fine. -- WOSlinker (talk) 18:34, 27 November 2009 (UTC)

I've also done the changes for the hook in Template:WPBannerMeta/hooks/taskforces/sandbox & Template:WPBannerMeta/hooks/taskforces/core/sandbox. -- WOSlinker (talk) 15:13, 28 November 2009 (UTC)

Great. Both  Done — Martin (MSGJ · talk) 09:41, 29 November 2009 (UTC)

My first hook

Can I get someone to take a look at what I've got at User:PC78/featured? The idea is to provide a means for project banners to track a variety of featured content types without having to create a bunch of new assessment classes. It will allow projects to track things like featured pictures even if they don't use File/Image-Class, or even if they don't use assessments at all. For the sake of projects that don't assess articles, I'm wondering if it's worth adding featured articles, featured lists and good articles, that way they can still track such articles that fall under their scope. All parameters would be optional. Example:

Comments and crits welcome. PC78 (talk) 19:15, 21 November 2009 (UTC)

Nice idea. Not sure it's worth tracking commons data though. No reason not to support featured articles because the components can be chosen individually. Were you planning to give some more control over the categories used? — Martin (MSGJ · talk) 09:13, 22 November 2009 (UTC)

I hadn't planned on it, but I can do; since this is something new I just saw an opportunity to impose a standard naming scheme. Commons data can be useful with regard to portal content, "selected pictures" for example. PC78 (talk) 09:20, 22 November 2009 (UTC)

Any ideas why the test banner is showing "More information:" when none of the parameters are specified? PC78 (talk) 17:45, 22 November 2009 (UTC)

Yes. By setting HOOK_COLLAPSED=3, you are telling the template that there are permanently three lines of notes. Maybe you meant COLLAPSED=3? — Martin (MSGJ · talk) 17:56, 22 November 2009 (UTC)

If I remove |HOOK_COLLAPSED= the banner gives off a message saying that the parameter is necessary for |HOOK_NOTE=. PC78 (talk) 18:38, 22 November 2009 (UTC)

That is correct. For hooks with multi-line outputs attached to HOOK_NOTE, the only way to ensure correct behaviour is to use the /notecounter hook. — Martin (MSGJ · talk) 18:44, 22 November 2009 (UTC)

Right, I think I've got it. PC78 (talk) 18:56, 22 November 2009 (UTC)

Posting this here for future reference:

• Banners already tracking FA/FL/GA: {{Chemicals}}, {{WPMeasure}}
• Banners already tracking DYK: {{WPDOGS}}, {{WikiProject Netherlands}}, {{WikiProject Organizations}}, {{WikiProject National Register of Historic Places}}, {{WPHawaii}}, {{WikiProject Montana}}, {{WikiProject Lithuania}}, {{WikiProject Linguistics}}, {{WikiProject Circus}}

-- PC78 (talk) 19:13, 26 November 2009 (UTC)

I must be missing something. Why would we do this inside project banners, when separate templates exist and are regularly used for all of these things and/or most of them are tracked in {{ArticleHistory}}? It would just add redundancy. PS: It would be especially redundant in the case of the many thousands of articles with 2 or more project tags. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:25, 29 November 2009 (UTC)

It would allow projects to track these things internally. It's no more redundant than having seven banners on a page with seven FA-Class assessments. PC78 (talk) 23:32, 29 November 2009 (UTC)

Category:WPBannerMeta templates with missing assessment categories

Any ideas why {{WikiProject East Timor}} and {{WikiProject River City}} are in this category? Neither banner is showing the missing categories message box, and as far as I can tell all assessment categories are present and correct. :S PC78 (talk) 03:15, 24 November 2009 (UTC)

Template:WikiProject East Timor/hide. — Martin (MSGJ · talk) 05:42, 24 November 2009 (UTC)

??? If that's an explanation, I'm afraid it sailed right over my head. PC78 (talk) 14:29, 24 November 2009 (UTC)

Lol, sorry. There is a function to hide the warnings on /templatepage by creating a subpage /hide. So these banners do have categories missing but the warnings are supressed by this feature. Now that we have full control over the quality and importance classes, we could probably do without this function. — Martin (MSGJ · talk) 14:50, 24 November 2009 (UTC)

Suppression of some kind might be good for sandbox or userspace banners if that included the category as well, since these aren't things we need to be terribly concerned with.

I'm assuming that the two banners I mention above lack properly named top level assessment categories, as does (for example) {{WikiProjectWUSTLpeople}}. I'm wondering how best to deal with such issues. The categories do exist under a different name, so the banner is highlighting a problem that isn't really there. Category redirects offer a quick fix but are ultimately undesirable. In a few cases I've already replaced the existing category with the one called for by the banner, but that might not always be ideal. PC78 (talk) 16:04, 24 November 2009 (UTC)

Can someone double check the changes I've made at {{WPBannerMeta/templatepage/sandbox}} and {{WPBannerMeta/templatepage/catother/sandbox}}. What this does:

1. Removes support for the /hide subpage feature. I don't see the value in this, especially when it adds banners to the category regardless.
2. Suppresses the missing category warnings and categorisation for "in development" banners. Categories don't need to be created until a banner goes live.
3. Added a tracking category for banners with other (i.e. non-assessment) missing categories.
4. An override feature so that class and importance on the templatepage can be set manually (via a /templatepage subpage of the banner), useful if the default values are not used by the project; compare {{Department of Fun}} with {{Department of Fun/sandbox}}.

-- PC78 (talk) 08:53, 27 November 2009 (UTC)

I haven't checked your code yet, but some thoughts on your proposals:

1. Support. The /hide is unnecessary now.
2. I don't mind not categorising these, but I find it useful to get the prompts when building a template in the sandbox, so please could these be left?
3. Good idea.
4. I don't oppose it, but this sounds like far too much complication for very little benefit. The fact that those are redlinks should be enough to show that they are not in use. We could probably think of a better alternative to having more subpages if this is really perceived as a problem.

— Martin (MSGJ · talk) 13:34, 27 November 2009 (UTC)

1) There may turn out to be a use for this after all, I'll have to come back to it. I'm going to disable it anyway though, on a temporary basis if nothing else. 2) Personally I think the promps encourage the creation of categories that may not end up being used, but fair enough. I'll have to come back to this as well. 4) I don't think it's that complicated, and I don't think it's a good thing to have banners showing classes that a project doesn't actually use. Perhaps there's a better way of doing what I'm trying to do, or perhaps it would help if the templatepage defaults were changed to something else. I'll try and find out which banners are affected, and naturally I'll come back to this as well. :) PC78 (talk) 14:01, 27 November 2009 (UTC)

4) Perhaps if |QUALITY_SCALE=inline is used, you can use the value of {{{class}}}. This will give the default class (probably unassessed) but at least it will be a valid class. — Martin (MSGJ · talk) 16:32, 27 November 2009 (UTC)

I've implemented this, along with a few other things such as not prompting for importance categories when a custom scale is used. — Martin (MSGJ · talk) 11:55, 28 November 2009 (UTC)

I'm not sure that's ideal to be honest, partly because this isn't an issue for the vast majority of banners using an inline mask, and partly because those for which it is an issue are just as or more likely to be using a subpage. PC78 (talk) 14:49, 28 November 2009 (UTC)

The relevant banners affected by unused classes on the templatepage: {{Department of Fun}}, {{WPAFC-admin}}, {{WPCATSUP}}, {{WikiProject Editing trends}} and {{WikiProject Lists}}. PC78 (talk) 00:39, 29 November 2009 (UTC)

For subpage masks I suppose we could actually pass |class=B through the custum mask, so that if it wasn't a valid class then we would get the default value out. However for inline, there is no other way around it. — Martin (MSGJ · talk) 09:00, 29 November 2009 (UTC)

I went ahead and made a few of these changes. Any ideas why some banners are getting sorted under "{" in Category:WPBannerMeta templates with missing assessment categories? PC78 (talk) 01:53, 28 November 2009 (UTC)

Fixed. -- WOSlinker (talk) 09:16, 28 November 2009 (UTC)

Duplicate hooks?

What is the difference between {{WPBannerMeta/hooks/todolist}} and {{WPBannerMeta/hooks/article todolist}}? Could they be merged into a single hook? PC78 (talk) 21:37, 26 November 2009 (UTC)

WOS could probably answer this better but I believe it is the difference between a to-do list for the whole project versus a list just for the article in question. — Martin (MSGJ · talk) 13:36, 27 November 2009 (UTC)

They could probably be merged if someone wanted to work on it though. -- WOSlinker (talk) 22:50, 27 November 2009 (UTC)

FWIW, I like that they are different; just needs to be better documented. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:18, 29 November 2009 (UTC)

/qualitycats hook

Would there be any concern about deprecating this hook in favour of using taskforces with TF_TEXT=none. The advantages are:

• More centralised code; less to change when we want to make a change.
• Allowing quality categorisation without the use of hooks.
• The fact that there is no display is shown clearly in the syntax.

— Martin (MSGJ · talk) 23:19, 29 November 2009 (UTC)

B-Class checklist template call

Not terribly important, but can the template call in {{WPBannerMeta/bchecklist}} be changed from:

| b1 <!--Referencing & citations--> = <yes/no>
| b2 <!--Coverage and accuracy  --> = <yes/no>
| b3 <!--Structure              --> = <yes/no>
| b4 <!--Grammar and style      --> = <yes/no>
| b5 <!--Supporting materials   --> = <yes/no>
| b6 <!--Accessible             --> = <yes/no>

to:

| b1 <!--Referencing & citations--> = <yes/no>
| b2 <!--Coverage & accuracy    --> = <yes/no>
| b3 <!--Structure              --> = <yes/no>
| b4 <!--Grammar                --> = <yes/no>
| b5 <!--Supporting materials   --> = <yes/no>
| b6 <!--Accessibility          --> = <yes/no>

Purely a matter of conciseness and consistancy. PC78 (talk) 15:15, 29 November 2009 (UTC)

Why omit "style"? — Martin (MSGJ · talk) 20:21, 29 November 2009 (UTC)

Because it only says "Grammar" in the banner. PC78 (talk) 20:34, 29 November 2009 (UTC)

Ah, okay.  Done. — Martin (MSGJ · talk) 20:43, 29 November 2009 (UTC)

I think it'd be preferable to have "style" re-added, in both places. "Grammar" is too narrow. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:16, 29 November 2009 (UTC)

Okay, I would support that. — Martin (MSGJ · talk) 10:18, 30 November 2009 (UTC)

If there are no other comments I will readd "and style" to B4. And I propose to use the word "and" in the main checklist and an ampersand in the copy/paste code. — Martin (MSGJ · talk) 22:11, 30 November 2009 (UTC)

Comments link text not appearing

{{WikiProject Mountains}} has COMMENTS=yes, yet the comments text does not appear. See Talk:Helderberg Escarpment for an example. RedWolf (talk) 16:00, 29 November 2009 (UTC)

Comments only appear where they exist; the prompt asking for comments where a subpage doesn't already exist were removed following discussion here and at the VP. PC78 (talk) 16:30, 29 November 2009 (UTC)

I think the template documentation should be updated to reflect this change. RedWolf (talk) 17:00, 29 November 2009 (UTC)

I had a quick look and it seems that the documentation is up to date. Which part of it is not clear? Or perhaps you were referring to the documentation for Template:WikiProject Mountains? — Martin (MSGJ · talk) 20:12, 29 November 2009 (UTC)

The description says "this parameter will automatically display a note in the banner showing whether these comments exist or not." Also, the example shows the text that appeared if the Comments subpage does not exist. The current behaviour no longer shows this text if the subpage does not exist. RedWolf (talk) 02:24, 30 November 2009 (UTC)

Good point.  Fixed — Martin (MSGJ · talk) 10:18, 30 November 2009 (UTC)

Book class

In order to support Wikipedia:Books, can we add a class=books (or book (no "s")) to the template? While there aren't a lot of books at the moment, this will change drastically in the future, and having support in this template for these books would be very useful. ···日本穣^? · 投稿 · Talk to Nihonjoe 02:05, 2 December 2009 (UTC)

Hmm...looks like you all are way ahead of me. I figured out what I needed to do to support it in the {{WPJ}} banner. Thanks! ···日本穣^? · 投稿 · Talk to Nihonjoe 02:15, 2 December 2009 (UTC)

WP religion and book-class

I'm trying to modify {{WPReligion}} to accomodate the book-class, but it uses hooks (or whatever these are called) and I never could understand hooks or the logic behind them. So could you take a look at it? Headbomb {^ταλκ_{κοντριβς} – WP Physics} 05:58, 3 December 2009 (UTC)

What you did seems to be correct. You just need to set |QUALITY_SCALE=subpage on the hooks as well and then fix up Template:WPReligion/class. — Martin (MSGJ · talk) 07:24, 3 December 2009 (UTC)

Sorry, that's chinese to me. the topic1= and so on aren't documented. They seem to be related to taskforces, but there are hook-thingamajigs so I can't make sense of how the template works. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 07:58, 3 December 2009 (UTC)

Fixed, though I haven't set the task forces to subpage because personally I think they would be better off with the standard quality scale. PC78 (talk) 13:35, 3 December 2009 (UTC)

Well the guy mentionned he wanted to implement them for taskforces as well. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 15:25, 3 December 2009 (UTC)

Already replied on my talk page. That's not quite what John Carter said, though. PC78 (talk) 20:31, 3 December 2009 (UTC)

True, it seems I misread. Oh well, it can always be reverted if it's undesired. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 00:21, 4 December 2009 (UTC)

More thoughts on Book-Class

Since the pagenames of Wikipedia books all begin with the prefix "Book/", the thought occurs that it may be of benefit if Book-Class categories were sorted by {{SUBPAGENAME}} rather than the default {{PAGENAME}}. What would be the best way of going about this? PC78 (talk) 18:55, 4 December 2009 (UTC)

There's a "titlepart" magicword/parserfunction which comes in handy in cases like that. Probably the only best way to do it. (Note that there's a discussion on the WP:VP to create a book namespace). Headbomb {^ταλκ_{κοντριβς} – WP Physics} 21:38, 4 December 2009 (UTC)

A namespace would definitely be the easiest way to fix the sorting issue. Allowing customised sort keys throughout this template would be a real pain. — Martin (MSGJ · talk) 09:34, 5 December 2009 (UTC)

What about doing it locally within specific banners? PC78 (talk) 19:01, 5 December 2009 (UTC)

BTW, the namespace discussion is here: Wikipedia:Village pump (proposals)#Namespace for books. Leave comments if you have any. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 21:15, 5 December 2009 (UTC)

Template:WP UK Politics's bot note

For the life of me I can't figure out why the bot text isn't displaying but it's putting the category correct (note 5). –xeno^talk 15:59, 6 December 2009 (UTC)

Looks fine to me... ? PC78 (talk) 16:24, 6 December 2009 (UTC)

Talk:Adamsdown , the banner doesn't tell you it was rated by a bot. –xeno^talk 17:50, 6 December 2009 (UTC)

You need to click "show" next to "More information". ;) PC78 (talk) 18:29, 6 December 2009 (UTC)

...though the article in question is hardly a stub. PC78 (talk) 18:44, 6 December 2009 (UTC)

LOL! <facepalm> Thanks =) –xeno^talk 19:25, 7 December 2009 (UTC)

Portal icon

Any idea why the meta is showing the old portal icon? I've had a look at the code and it sems to be a straightforward transclusion of {{portal}}, so I don't get it. PC78 (talk) 19:52, 7 December 2009 (UTC)

The PORTAL_ICON parameter is currently normalised on Template:WPBannerMeta, and the default is still the old icon File:Portal.svg. Changing this to File:Portal-puzzle.svg would not help the assessibility issue because currently all images are linked by the code on /core. What we could do is just pass {{{PORTAL_ICON}}} through to the /core and then to {{portal}}, so that an undefined icon will result in the default. (I think this would require a small code change to Template:portal so that a defined blank icon parameter is treated the same as an undefined parameter.) — Martin (MSGJ · talk) 09:28, 8 December 2009 (UTC)

Category:Automatically assessed FOO articles

This may be a dumb question, but why doesn't Category:Automatically assessed Sports articles exist (or Category:Automatically assessed sports articles), and why are the subcategories of Category:Automatically assessed articles sometimes capitalized as to topic and sometimes not? There's no need for the "Cue" in Category:Automatically assessed Cue sports articles to be capitalized. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:09, 19 December 2009 (UTC)

Sorry for the late reply. The only thing I can say is that the category can be specified explicity using the |AUTO_ASSESS_CAT= parameter. If that is not specified then the PROJECT parameter gives a default category of Category:Automatically assessed PROJECT articles. — Martin (MSGJ · talk) 23:33, 31 December 2009 (UTC)

Book namespace created

See Wikipedia:Village pump (proposals)#Namespace for books. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 14:12, 28 December 2009 (UTC)

Oh God, I'm so out of date with this template. Martin, what on earth have you done to the class mask!?! :D It looks awesome, but I'd better start reading!! Happy‑melon 15:08, 28 December 2009 (UTC)

I've made the changes for class mask in Template:Class mask/sandbox and Template:Class mask/core/sandbox if you would like to review them. -- WOSlinker (talk) 15:37, 28 December 2009 (UTC)

Ah, I just posted on Template talk:Class mask about this before seeing this. Yes, the proposed changes seem good to me. I also suggested over there that Book-class might become part of the extended quality scale as it seems to have become widely adopted by WikiProjects, although this will need wider consultation. — Martin (MSGJ · talk) 23:43, 31 December 2009 (UTC)

Just a heads up, when I auto-created the Book-Class cat for WPFootball from Template:Football/class, the Subst. template didn't add any categories at the bottom like Category:Book-Class articles or Category:Football season articles by quality, see this link: [8]. Could you guys fix this, so it works like the other quality cats? --Funandtrvl (talk) 19:25, 11 January 2010 (UTC)

Possibly fixed by this edit. Perhaps you could test it out. — Martin (MSGJ · talk) 20:43, 11 January 2010 (UTC)

First, I would need to find a banner where the Book-Class hasn't been created yet, and secondly, wouldn't Template:WPBannerMeta/qualityscale have to be updated? --Funandtrvl (talk) 21:54, 11 January 2010 (UTC)

You're right, /qualityscale could use an update. We should use {{pagetype}} to determine the page type. Suggested code is in Template:WPBannerMeta/qualityscale/sandbox. — Martin (MSGJ · talk) 13:44, 13 January 2010 (UTC)

I've done this now. I notice that we have a slight anomaly though when a rating is given to a page which doesn't need a rating. For example if you give a template an A-class rating, it will display the A but then say it doesn't need a rating. — Martin (MSGJ · talk) 17:12, 14 January 2010 (UTC)

And since {{pagetype}} is called so many times, we should really think about calling it once and passing it through. — Martin (MSGJ · talk) 21:45, 13 January 2010 (UTC)

Inconsistency?

Resolved

 – Fixed.

This code:

{{WikiProject New York|class=Disambig}}

correctly produces a banner with no "importance" line (and puts the page in the NA-importance category).

But if I use

{{WikiProject New York|class=Disambiguation}}

the banner correctly shows as Disambig-class but includes the "importance" line (and puts the page in the Unknown-importance category).

I should think that the two behaviors should be the same (specifically, the first). Am I correct?

-- Powers ^T 16:04, 26 January 2010 (UTC)

Correct. The "disambiguation" was missing from Template:pagetype (which is used to detect whether a page is an article or non-article). I have now fixed this. — Martin (MSGJ · talk) 16:14, 26 January 2010 (UTC)

Copyvio notice like BLP notice

I just thought of a re-use for the BLP warning that appears with |living=yes in {{WPBiography}} and appears again with |blp=yes above {{WikiProjectBannerShell}} if {{WPBiography}} is put inside it. This would be a copyright warning that could be used on all song article's talk pages tagged with {{WikiProject Songs|song=yes}} or {{WikiProjectBannerShell|song=yes|1={{WikiProject Songs}}}}. The message in the warning would say not to link to lyrics pages/sites, because they are copyvios; link to WP copyright policy on not linking to copyvios; explain that lyrics are the copyrighted property of their writer(s), their label and/or their music publishing group. PS: I'll make a copy of this post over at Template talk:WikiProjectBannerShell as an FYI, but direct discussion here. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 21:17, 26 January 2010

My initial thought is that this should be discussed with the songs WikiProject, and if there is agreement that such a warning is needed then it would be easy to add this to {{WikiProject Songs}}. (It wouldn't require any change to this template.) I'm not so sure about adding it to the banner shell. Usually people are looking to compress/collapse the information when they use that, and so only the most important info (e.g. the BLP blurb) should be shown uncollapsed. Anyway that would be an issue for Template talk:WikiProjectBannerShell I suppose. (Again, it wouldn't affect this template.) Regards, — Martin (MSGJ · talk) 21:41, 26 January 2010 (UTC)

Other classes not covered

A project I work on includes some audio files and redirects. Could we have 'Audio' and 'Redirect' classes? Stevie is the man! ^{Talk • Work} 17:11, 29 January 2010 (UTC)

Yes, Redirect-class is fairly commonly used by WikiProjects. Although most projects tend to use File-class for all media files, you could have Audio-class if you preferred. All this can be achieved by using Template:Class mask on the /class subpage of your WikiProject banner. If you tell me which project you are talking about I might be able to help. — Martin (MSGJ · talk) 17:45, 29 January 2010 (UTC)

Wikipedia:WikiProject Louisville is the project. Thank you for any assistance you can provide. Stevie is the man! ^{Talk • Work} 17:52, 29 January 2010 (UTC)

Take a look at Template:WikiProject Louisville/class and see if that makes sense. You'll need to set |QUALITY SCALE=subpage in the banner template to activate the custom mask. — Martin (MSGJ · talk) 18:47, 29 January 2010 (UTC)

Thank you for your assistance! Looks great! Stevie is the man! ^{Talk • Work} 19:28, 29 January 2010 (UTC)

You're welcome. If you would like to assign a color to this new class, you can request an edit to Template:Classcol. — Martin (MSGJ · talk) 20:05, 29 January 2010 (UTC)

Probably the same as file-class would be a start. -- WOSlinker (talk) 21:13, 29 January 2010 (UTC)

Possibly, although they are also using Image-class so perhaps a different colour would be preferable ... — Martin (MSGJ · talk) 08:13, 31 January 2010 (UTC)

Image-class vs. file-class

Hi there, I recently nominated Category:Image-Class articles to be merged into Category:File-Class articles. I've invited those at WT:COUNCIL into a discussion here and would like to direct others there for centralized discussion. My nomination of the category merging can be found here. Thank you. — ξ^xplicit 23:21, 23 February 2010 (UTC)

Categories

{{editprotect}} Needs a template documentation and categorized, otherwise added {{uncategorized}} to it. --Anime Addict AA (talk) 19:59, 10 February 2010 (UTC)

This template does have documentation (at Template:WPBannerMeta/doc) and categories (Category:WikiProject banners and Category:Wikipedia metatemplates). I have undone your edits to some of the subtemplates, because I cannot really see the purpose of having separate categories for these. — Martin (MSGJ · talk) 20:21, 10 February 2010 (UTC)

I'm sorry, but something without a category looks awkward to me. I reput the templates, maybe someone finds good categories for them. --Anime Addict AA (talk) 01:28, 23 February 2010 (UTC)

I've undone those edits again. It is considered edit-warring to reapply your edit when it has been reverted. You might like to read WP:BRD. Please do not make these edits again until you have a consensus. Thanks — Martin (MSGJ · talk) 22:54, 23 February 2010 (UTC)

I agree that there is no need for subtemplates to be categorised; that's totally pointless. Happy‑melon 16:13, 25 February 2010 (UTC)

Comments pages and transcluded CSD tags

I recently went through all of the WikiProject New Jersey articles that had /Comments subpages to clean them up per Wikipedia:Discontinuation of comments subpages. When I got to the point of tagging all of the subpages for CSD, the template transcluded onto the talk pages where the WPBanners had a COMMENTS parameter defined. Is there a way that this template be altered to not not include the CSD category for a transcluded template? Jim Miller ^{See me | Touch me} 15:50, 25 February 2010 (UTC)

No, except by removing the comments functionality from the WPNJ banner. How many pages are there? It's probably just easiest to give an admin a list and let them delete them all at once. Happy‑melon 16:08, 25 February 2010 (UTC)

Or wrap the CSD tag with noinclude... –xeno^talk 16:08, 25 February 2010 (UTC)

Would wrapping the CSD tag still add the intended page to the category? I figured out the parameter removal a bit late in the process, but did do it eventually. That doesn't help with other banners that still have the parameter. WPBiography has it, and kept a number of talk pages showing in CSD. The Comments pages have already been deleted, and it seems like there is just a bit of lag in clearing the talk pages out of the CSD category. Thankfully a clueful admin did the deletions! I am merely looking forward to a larger project undertaking this process, and what can be done to prevent the mass unintentional addition of valid talk pages into the CSD Category. Maybe I will just make a note at Wikipedia:Discontinuation of comments subpages that the COMMENTS and COMMENTS_FORCE paramaters should be deleted from any project banner prior to tagging the subpages. Jim Miller ^{See me | Touch me} 16:26, 25 February 2010 (UTC)

Yes, wrapping it will do all the needful business on the page, but won't pollute pages where it is transcluded. So, yes, make a note to either wrap it in noinclude or take out the comments param. –xeno^talk 16:28, 25 February 2010 (UTC)

<facepalm> yes, that would indeed work :D Happy‑melon 17:48, 25 February 2010 (UTC)

listas parameter defines default sort key.

This results in conflict in the case where different WikiProjects prefer different sorting schemes. A biographical article, for example, would have the sort key "surname, first_name" for WikiProject Biography, but other, e.g. regional projects may sort differently, resulting in conflicting defaultsort declarations. Is there a fix or workaround? --Paul_012 ^(talk) 17:47, 23 January 2010 (UTC)

Not really. Why would projects need to sort categories differently? Can you point to some actual examples? Happy‑melon 18:31, 23 January 2010 (UTC)

Biographical articles are the only thing that comes to mind now. I was thinking of how Thai people are known by first name and their articles should be sorted by first name under WikiProject Thailand (telephone directories are sorted this way in Thailand), but are sorted by surname, as the international rule, under WikiProject Biography. --Paul_012 ^(talk) 05:51, 24 January 2010 (UTC)

The default sort key can be overridden, although I don't know how possible that is within the confines of WPBannerMeta. Powers ^T 17:56, 26 January 2010 (UTC)

<sigh> I said here and elsewhere (I think at Template talk:WPBiography before that template used the code here, if this template even existed yet) something like three years ago that having project banners sort by way of DEFAULTSORT was a very Bad Thing. It still is, since nothing has magically changed since then. The proper solution to this is to have a DEFAULTSORT on any talk page for bios, sorting by family name as expected internationally, then recode this meta-template to have |listas=project-preferred value do a |project preferred value on any categories added by that project tag. After that, {{WPBiography}} will never again need a listas at all, and nor will any other project unless it wants to do something quite unusual by anglophone standards. The further Good Thing about this overdue solution is that it will eliminate all conflicts between different projects wanting different sorts. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 21:08, 26 January 2010 (UTC)

I can see some advantages to the approach you are suggesting. However it is not yet clear to me whether there is a real need for different sort keys. To avoid confusion, surely the WP:NAMESORT guideline ought to apply Wikipedia-wide? I'm not really familiar with why the current approach was used, but I think it would be a huge task to change this: you would either lose all of the correct sort keys in all projects which didn't use the listas parameter, or you would have hundreds of default conflicts. — Martin (MSGJ · talk) 10:57, 29 January 2010 (UTC)

Bump. So would it be feasible to implement at least part of the changes suggested above by SMcCandlish? Specifically, I would like to have a parameter that allows a project to define a custom sort key for its assessment categories, for the reasons mentioned above. (I've moved the section to the bottom of the page for it to be more visible.) --Paul_012 ^(talk) 05:40, 16 March 2010 (UTC)

I'm sure it would be feasible, it's just a question of whether it's worth doing considering the work involved and the expected benefits. Happy-melon's opinion on this would be helpful I think. — Martin (MSGJ · talk) 07:25, 16 March 2010 (UTC)

This would be an outright reversal of the changes we made here, requiring us to restore the hugely-fiddly and extremely fragile method of passing through a |listas= parameter to every subtemplate that includes a category. This would also have to be passed to hooks, which would be extremely inconvenient and increases the complexity for end-users. I'm thoroughly unconvinced that this change would be beneficial, I really don't see how the small benefit to WPThailand outweighs the cost to all other projects. Happy‑melon 10:43, 16 March 2010 (UTC)

If Thailand is likely to be the only project which has a use for this, then I could probably code up a custom banner for their needs. I agree that passing listas to every subtemplate would be a pain (although, perhaps the behaviour of that parameter would be more intuitive if we did?). — Martin (MSGJ · talk) 10:58, 16 March 2010 (UTC)

Assuming that a customizable parameter could be added to the Meta template, wouldn't there be a situation where the article's talk page would be categorized by first name in the project categories, but that the article's page in the mainspace would be categorized by surname? If both the WPTHAILAND and WPBIO templates are on the same talk page, would that page be categorized by first name in project Thailand, and last name in project Biography, or would one sort method take precedence over the other? In the English Wikipedia, shouldn't the WP:NAMESORT guideline be followed consistently? Is there a Thai language Wikipedia, and how are names sorted there in both the project categories and mainspace categories? How would a difference in a sortkey method, project-wide, be communicated to non-project members, that are just looking through the project categories to find something, when they would be expecting the NAMESORT guideline to be followed? --Funandtrvl (talk) 13:44, 16 March 2010 (UTC)

Template:Comedy

Hi-

1. Could you move Template:Comedy to Template:WikiProject Comedy, in order to standardize the template name for the WikiProject?
2. Could you delete Category:No-importance Comedy articles since it's empty?
3. Then could you delete the subpage: Template:Comedy/importance since the non-standard "No-importance" category wasn't/isn't being used?

Thx much! --Funandtrvl (talk) 00:36, 17 March 2010 (UTC)

 all done — Martin (MSGJ · talk) 21:06, 17 March 2010 (UTC)

Help! A vandal recreated Template:Comedy/importance, if you have time, could you re-delete it? I've also marked it as db-g3, hopefully, that's the correct one. Thank you! --Funandtrvl (talk) 21:17, 18 March 2010 (UTC)

California banner setup

Was there ever an autoimportance setting added to the meta banner? If so can someone please add it to {{WikiProject California}}. Just making sure it's up to date. While we're on it, how far is that custom class mask off from the default extended setup aside from some Foo class pages vs Foo class articles? Thanks, -Optigan13 (talk) 04:37, 17 March 2010 (UTC)

Added autoi to Cali template as note7. (not natively supported yet as only a few projects use it) –xeno^talk 20:37, 18 March 2010 (UTC)

Template:WikiProject California/class adds support for the non-standard Book- and Redirect-classes. It also forces pages marked as NA-class into a more specific class based on their namespace, which is also non-standard behaviour. If that's now what you're asking, please clarify. — Martin (MSGJ · talk) 23:11, 22 March 2010 (UTC)

Thanks, that was more or less what I was looking for. I just wanted to make sure it wasn't just an issue of using Project-Class California articles instead of Project class pages. Thanks -Optigan13 (talk) 00:39, 23 March 2010 (UTC)

The assessment naming scheme is defined by the ASSESSMENT_CAT parameter. As this is undefined in {{WikiProject California}} it defaults to California articles. — Martin (MSGJ · talk) 12:28, 23 March 2010 (UTC)

Vital articles

Template:VA needs to merge into this template. From what I can tell, it is a 100% WikiProject-related concern, and a very simple matter, which is unnecessarily generating new top-of-talk-page clutter. Should be quite trivial to implement here instead, and appear in the summary that appears for a project in Template:WikiProjectBannerShell's default, collapsed view. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 19:23, 14 April 2010 (UTC)

It probably could be converted. I'm not sure it is "a 100% WikiProject-related concern" as you say though. It might be worth bringing this up at Wikipedia talk:Vital articles. — Martin (MSGJ · talk) 20:55, 17 April 2010 (UTC)

MTV, please pimp my auto!

Previous discussion: Template talk:WPBannerMeta/Archive 7#Boldly going where no auto-assessment bot has gone before...

Meta Template Veterans, please pimp my |auto= ! There are now 15 or more projects that are using an enhanced auto parameter,

|auto=yes for bot found a {{stub}} template on the article (legacy)

|auto=inherit for bot inherited class from other projects

Can we get this slight change added to the template proper so I can avoid having to add custom notes to the project banners?

The "generic message" implementation on Template:WPBiography (note 1) seems fine. –xeno^talk 17:07, 26 January 2010 (UTC)

Thanks! –xeno^talk 16:48, 26 January 2010 (UTC)

Ooh, I'll have to look over that discussion again and see what was suggested. And look over the WPBio code - although if I remember correctly, PC put some crazily complicated code over there so it might be nice to simplify/streamline it a little ... — Martin (MSGJ · talk) 21:42, 26 January 2010 (UTC)

Indeed - I don't think the separate auto-assess cats should be used - I was more talking about just using the generic message rather than describing how the bot came to its conclusion. I'm fine with that, or I'm fine with describing it. Whatever's clever. –xeno^talk 21:46, 26 January 2010 (UTC)

Okay, I've reviewed that conversation again. The main points of discussion were:

• Use the same or different parameter names? It seems there is agreement that the one parameter auto was sufficient.
• Use different text depending on parameter input? PC78 was arguing for a generic message "This article has been automatically assessed by a bot" for all cases. It seems that others preferred to adapt the message depending on the input, e.g.
  • "This article has been automatically assessed as Stub-class by a bot because it uses a stub template".
  • "This article has been automatically assessed by a bot, because another banner on this page uses this class".
• Support for different categories depending on input? There was some discussion about the value of being able to look at category intersections, but this is probably overly complicated for the meta. Projects can always install their custom notes if they want to do this.
• Using the class as the value of the parameter? This would allow the message to be hidden when the current class is not the same as the bot-rated class. However it seems that I was the only one advocating this approach.

Have I missed anything? — Martin (MSGJ · talk) 11:27, 29 January 2010 (UTC)

That looks like a pretty good summation. While I like the extra functionality that would be provided by the "auto=xxx" where xxx is the class, I think it would just confuse people not familiar with the template. –xeno^talk 19:41, 29 January 2010 (UTC)

How about this? — Martin (MSGJ · talk) 09:22, 30 January 2010 (UTC)

|auto=stub

{{WPBannerMeta/test|auto=stub|class=stub|category=no}}

|auto=inherit

{{WPBannerMeta/test|auto=inherit|class=C|category=no}}

Y looks good! –xeno^talk 17:42, 31 January 2010 (UTC)

You mean, apart from the "by a by a"!? All done, let me know of any problems please. — Martin (MSGJ · talk) 22:30, 31 January 2010 (UTC)

Lol, my subconcious did not clue into the repetition. Hey this is probably pretty easy: how do I get a maintenance category of "stubs rated via inheritance"? (alternatively, sort it by a major key or something) –xeno^talk 19:40, 9 March 2010 (UTC)

Hmm? You want categories such as Category:Automatically assessed (via inheritance) PROJECT articles? What is a "major key"? — Martin (MSGJ · talk) 11:48, 11 March 2010 (UTC)

category sort discussion: convenience break

No just 1 class needs to be examined like this - Category:Automatically assessed (via inheritance) PROJECT stubs. But it doesn't even need to be in a different category, it could use a major/minor sortkey (you know those silly-looking Greek "u" or whatever that put the members at the top or bottom of a category list) in the main Automatically assessed Foo articles category. –xeno^talk 15:53, 17 March 2010 (UTC)

Yes, that could work. How about sort key "I" for inheritance and "S" for stub. It means that we would lose the alphabetical index for each group, but we could adapt a two-letter index (like Template:Large category TOC) to do this. Are you proposing to make this the default or an opt-in behaviour? — Martin (MSGJ · talk) 12:41, 26 March 2010 (UTC)

Hmm... Not quite sure if it should be opt-in or default. Actually if we could doubly-sort them so we could see "Inherited stubs" "Inherited B class" that would be keen! Don't forget that SONGS is going to be doing auto=size soon... Probably default - I think that projects will really want to examine "inherited FA/GA/FL/B" but won't necessarily care as much about the lesser ratings. –xeno^talk 17:52, 30 March 2010 (UTC)

When I mentioned a 2-letter sort key, what I had in mind was:

• First letter would be S (for stub), I (for inheritance), L (for length)
• Second letter would be the initial letter of the article

Therefore the articles would be sorted alphabetically inside their respective types. I'm not sure how effective it would be to sort them by their class as well. — Martin (MSGJ · talk) 20:35, 30 March 2010 (UTC)

Since these automatically-assessed categories are primarily for maintenance, it's not really necessary to navigate them alphabetically (though it looks nice). The ability to see which articles were rated via inheritance - sorted by class - would be extremely useful. As I intimated above, project members may want to quickly ensure that inherited ratings that are B-class are higher are correct while leaving aside start, stub and list class for the time being since there are so many. Allowing them to quickly see these articles would be great. –xeno^talk 20:37, 30 March 2010 (UTC)

I understand what you're saying. But how can this work? A category only displays headings for the first letter of the sort key. So you wouldn't know where one class ended and the next began. For this to work you would need to make the class the primary key and have a separate letter for each class. — Martin (MSGJ · talk) 21:40, 30 March 2010 (UTC)

That's fine... As long as class=stub,auto=yes can be put separate from class=stub,auto=inherit. –xeno^talk 21:41, 30 March 2010 (UTC)

Well we could keep "S" for auto=stub and maybe use numbers for auto=inherit, e.g. FA=1, A=2, GA=3, B=4, C=5, Start=6, Stub=7. Not sure where the lists and non-article classes would fit in. Maybe just use I for all the others. — Martin (MSGJ · talk) 21:49, 30 March 2010 (UTC)

"A" is never inherited because requirements for A class are project-specific. The only non-article types that are inherited is List and FL (and really only "List", FL comes from "currentstatus=".). So FA/FL=1, GA=2, B=3, C=4, Start=5, Stub=7 would be cool. –xeno^talk 21:52, 30 March 2010 (UTC)

Possible code on /core/sandbox. See the test on Template talk:WPBannerMeta/testcases. You can play with the class and auto parameters and check the sort keys on Category:Automatically assessed Video game articles. — Martin (MSGJ · talk) 11:15, 31 March 2010 (UTC)

Looks great! –xeno^talk 15:52, 31 March 2010 (UTC)

Okay, shall we leave this for a couple of days in case others have any comment? I think it may be sensible to put A=2 back in, if only to help find erroneous cases. — Martin (MSGJ · talk) 20:31, 31 March 2010 (UTC)

Call me OC but always seeing 1,3,4,5...will bug me... Maybe "A" could be "0" because an A-class should typically not be inherited (most projects have an internal approval process). Float to the top, like. –xeno^talk 03:48, 3 April 2010 (UTC)

Okay, so your bot will never inherit A class, but there is no real distinction between this class and a lot of the others. Stub/Start/C/B/A are all WikiProject assessments and as such, different projects could use different class descriptors if they wished. In fact, there is broad agreement of Stub/Start/C but I think you'd find there are some significant differences with B-class. A lot of projects haven't adopted the 6 B-class criteria. I guess the whole point of auto-assessing is that they should be checked by human editors, but I find it inconsistent to include all the WikiProject assessments except A. — Martin (MSGJ · talk) 07:37, 3 April 2010 (UTC)

So how about 0=A 1=FA/FL 2=GA 3=B 4=C 5=Start 6=Stub 7=List ? –xeno^talk 12:15, 3 April 2010 (UTC)

auto=length

WikiProject Songs is about to auto-assess based on the size of the article. Are these changes acceptable? –xeno^talk 04:02, 3 April 2010 (UTC)

As we are talking about articles in an encyclopedia, I feel that "length" is a more appropriate term than "size". I have no problem in principle to adding this option to the template though. — Martin (MSGJ · talk) 07:30, 3 April 2010 (UTC)

Length is fine and will be consistent with sortkey "L" (leaving "S" for stub). (Though I do note "size" is consistent with magicword "PAGESIZE") –xeno^talk 12:16, 3 April 2010 (UTC)

Okay. I notice you added a default message, but currently the note will not display anything for |auto=sausages ... — Martin (MSGJ · talk) 13:55, 3 April 2010 (UTC)

Thinking about it more, I'm not so sure that "length" is the best fit: it could be confused with vertical length. What about just "auto=pagesize" ? –xeno^talk 16:43, 3 April 2010 (UTC)

I'm not too fussed, but "length" just seems more natural to me. Whatever is chosen ought to match with the text shown in the banner. — Martin (MSGJ · talk) 16:50, 4 April 2010 (UTC)

I'd say the benefit of having a free and unambiguous sortkey available for "Length" is a winning argument. "Length" would more accurately refer to word count rather than bytecount, but then again, that would be a better way of evaluating article quality anyway. Happy‑melon 18:06, 4 April 2010 (UTC)

Good point - let's go with length. Some projects may request me to do it by wordcount so length would fit both situations. –xeno^talk 16:37, 5 April 2010 (UTC)

I've started a template that could be used as a TOC for these categories. What do you think? — Martin (MSGJ · talk) 10:14, 5 April 2010 (UTC)

---

This category contains articles that have been automatically assessed. Editors should confirm or amend the assessment made by the bot and then remove the |auto=??? parameter.

Automatic assessment	by inheritance									by stub template	by length
	FA	FL	GA	B	C	Start	Stub	List	NA
Sort key	1	2	3	4	5	6	7	8	9	S	L

---

I love it. What about FL and List, though? –xeno^talk 16:37, 5 April 2010 (UTC)

As you are the main editor involved in auto-assessment, I think you can decide on the details :) I think I've said all I have to say on this issue. — Martin (MSGJ · talk) 16:59, 9 April 2010 (UTC)

About lists:The data fields are not designed to handle different article types, not an issue related to the bot as such. A list could be quite poor stub-class list or a high quality B-class list, but the current mechanism does not allow for them to be distinguished. Regards, SunCreator ^(talk) 17:06, 9 April 2010 (UTC)

Yes, we only have list or FL... I believe discussions on developing a listclass= or "articletype" or something have occured, but you're right: this isn't really related to the bot's autoassessor. I do notice that Discographies (which is almost exclusively lists) just uses the classes for lists (which confuses the auto-tagger to no end! =) –xeno^talk 21:06, 10 April 2010 (UTC)

• I went ahead and made the changes live. Thanks for your help MSGJ and input Happymelon. –xeno^talk 21:06, 10 April 2010 (UTC)

  No problem. Was that your first edit to this template :O — Martin (MSGJ · talk) 21:48, 10 April 2010 (UTC)

  I think so. When it lagged out I was worried I killed the wiki :). –xeno^talk 16:19, 11 April 2010 (UTC)

• Curious...How long do you figure for the categories to be re-sorted? Will it happen automagically or do the pages need to be touched? –xeno^talk 15:41, 19 April 2010 (UTC)

  I don't think there is a clear answer to this question. I believe that eventually they will all move without being touched, but I don't know how long that will take! — Martin (MSGJ · talk) 10:30, 20 April 2010 (UTC)

Make removal advisement more explicit

Should probably include the whole statement i.e. "...before removing the |auto=(yes|inherit|length) parameter." Seems that our current message confused at least one party [9]. –xeno^talk 18:12, 7 April 2010 (UTC)

Hmm, maybe. But I'd want to see more than one instance of this happening to be convinced that this is a problem. — Martin (MSGJ · talk) 16:57, 9 April 2010 (UTC)

Visually impaired

As per Wikipedia:Manual of Style (icons)#Remember accessibility for the visually impaired. Add |link=|alt= . Thanks Gnevin (talk) 22:19, 22 March 2010 (UTC)

Which icons are you referring to? I assume the NOTE_n_IMAGE, TF_n_IMAGE and PORTAL_IMG parameters. But what about IMAGE_LEFT and IMAGE_RIGHT? — Martin (MSGJ · talk) 23:06, 22 March 2010 (UTC)

I think it would have to be done by adding additional parameters as not all those images can be set to no link as they need attribution. -- WOSlinker (talk) 23:18, 22 March 2010 (UTC)

All icons in the template MSGJ. Can we defaulted it to blanks with parameters WOSlinker Gnevin (talk) 00:31, 23 March 2010 (UTC)

You cannot de-link a non-public domain image without attributing it in some other obvious manner, so it's probably best to find some generic alt text for the image fields and allow for provided alt text (or delinking if the image is public domain). –xeno^talk 00:55, 23 March 2010 (UTC)

@Xeno: Non public domain (AKA Fair Use) images shouldn't be used outside the main namespace (articles) as per our policies so that doesn't really appear to matter. Peachey88 ^{(Talk Page · Contribs)} 12:41, 23 March 2010 (UTC)

No, "free" does not mean "public domain". — Martin (MSGJ · talk) 12:50, 23 March 2010 (UTC)

cc-by-sa, GFDL, and other attribution-required licenses are permitted outside mainspace. –xeno^talk 13:03, 23 March 2010 (UTC)

Can't the caption have the attribution?Gnevin (talk) 09:59, 23 March 2010 (UTC)

What do mean by caption? Icons don't have captions. — Martin (MSGJ · talk) 12:32, 23 March 2010 (UTC)

I meant but doesn't work with alt=|link=| Gnevin (talk) 16:09, 23 March 2010 (UTC)

Guys, there is no way we can support different alternative text for every image in the banner. Can you imagine |NOTE_9_IMAGE_ALT= and |TF_4_IMAGE_ALT=. It would be ridiculously excessive. — Martin (MSGJ · talk) 12:32, 23 March 2010 (UTC)

Fair enough - then just use a generic alt text like we do on asbox, e.g. "Stub icon". –xeno^talk 13:04, 23 March 2010 (UTC)

Okay then, how about "Taskforce icon" for TF_n_IMAGE, "Note icon" for NOTE_n_IMAGE, and "WikiProject icon" for IMAGE_LEFT and IMAGE_RIGHT? —Preceding unsigned comment added by MSGJ (talk • contribs) 13:48, 23 March 2010 (UTC)

Seems reasonable. –xeno^talk 13:49, 23 March 2010 (UTC)

These are purely decorative and should have no alt text Gnevin (talk) 16:09, 23 March 2010 (UTC)

I think we're going round in circles here! — Martin (MSGJ · talk) 17:04, 23 March 2010 (UTC)

Would this change be better made at the individual template level by adding {{!}}alt={{!}}link= where needed? Gnevin (talk) 17:29, 23 March 2010 (UTC)

The |alt= part could probably be added into WPBannerMeta but the link part would need to be done at the individual template level providing the images are PD. -- WOSlinker (talk) 19:47, 23 March 2010 (UTC)

But there is no way to do that with the way this template is currently set up ... It was designed to be as easy to use as possible so only the name of the images are passed, and all the formatting and technical stuff is handled by the template. So there is no way to set this locally. — Martin (MSGJ · talk) 20:55, 23 March 2010 (UTC)

Never say never :) Template:GaelicGamesProject Gnevin (talk) 21:20, 23 March 2010 (UTC)

File:GAA_logo-test4.png cannot be unlinked, it requires attribution. –xeno^talk 21:25, 23 March 2010 (UTC)

Well it shows this issue could be dealt with locally Gnevin (talk) 22:58, 23 March 2010 (UTC)

I'm surprised that worked actually. But even so, I'm not sure that it is a good idea to do it this way as it may have unintended consequences. Presumably it wouldn't work if we add alt text globally. — Martin (MSGJ · talk) 10:10, 24 March 2010 (UTC)

How do you suggest we proceed so ? Gnevin (talk) 13:10, 24 March 2010 (UTC)

Well, until the attribution issues can be resolved, there is the option of adding alt text, as proposed above. — Martin (MSGJ · talk) 10:16, 25 March 2010 (UTC)

A generic alt text or a blank alt text? I'm not sure how generic would be helpful. Gnevin (talk) 12:58, 25 March 2010 (UTC)

Blank alt text won't work, it will just read the file name. Do you have a better solution other than generic alt text? –xeno^talk 13:04, 25 March 2010 (UTC)

(either as visible text or as a comment or other image metadata).I assume this mean HTML comment? Would this be possible? Gnevin (talk) 17:02, 25 March 2010 (UTC)

 Added alt text in the absence of any better solution. — Martin (MSGJ · talk) 09:51, 27 March 2010 (UTC)

Thanks ,is there a reason we can't use HTML comments? Gnevin (talk) 15:20, 28 March 2010 (UTC)

They don't appear in the final HTML; they're stripped from wikitext as pretty much the first thing the parser does. Happy‑melon 16:32, 18 April 2010 (UTC)

• One possible workaround would be redirects containg attribution in the filename to the original file. –xeno^talk 18:21, 28 March 2010 (UTC)

Portals

Is there an easy way to add a portal to each (or atleast most) TFs on the banner, or a COTW for each? 76.66.192.73 (talk) 10:46, 1 April 2010 (UTC)

Template:WikiProject Food and drink does something like this, you might like to look at the code. It's not ideal though because only one portal link can be shown, so what happens if an article is tagged with two taskforces? — Martin (MSGJ · talk) 10:50, 1 April 2010 (UTC)

What we're looking for is a for is TF_#_PORTAL parameters that put portal links inline with the task forces instead of replacing the main portal link. Can that be done? --Arctic Gnome (talk • contribs) 14:36, 1 April 2010 (UTC)

Interesting idea. I'm not sure if there would be much need for this feature from other projects. But we could probably

• add support for this in the taskforce hook and/or
• add it by abusing the TF_#_TEXT parameter.

What kind of format are you imagining for these extra portal links? And let's see what others think about the idea. — Martin (MSGJ · talk) 17:11, 1 April 2010 (UTC)

I think this feature would be fairly widely used. I've seen several projects where the TF's portal replaces the main portal, so any of them would likely show both portals if they could. Ideally each portal link would be one of those little boxes you see on the right-hand side of WikiProject Banners, but they would be inline with the part of the banner that mentioned the TF. If this would be really hard to set up, the portal link could also be done through text inline with the link to the TF. --Arctic Gnome (talk • contribs) 17:28, 1 April 2010 (UTC)

I agree. If there could be at least one portal for the main project, then at least one portal for each task force, that would be awesome. ···日本穣^? · 投稿 · Talk to Nihonjoe 20:10, 1 April 2010 (UTC)

Well, something like this is possible at the moment just by customising the TF_#_TEXT parameter. Is this what you have in mind? — Martin (MSGJ · talk) 07:09, 2 April 2010 (UTC)

Yes, something exactly like this would be useful to add so the TF_#_TEXT parameter could be used for something else if necessary. ···日本穣^? · 投稿 · Talk to Nihonjoe 08:30, 3 April 2010 (UTC)

This feature would come in handy, one of the issues we in WP:Food and Drink have is subjects that fall under several projects that all have their own portal. --Jeremy (blah blah • I did it!) 14:43, 2 April 2010 (UTC)

This happens with WP:JAPAN, too, fairly often. ···日本穣^? · 投稿 · Talk to Nihonjoe 08:30, 3 April 2010 (UTC)

Okay, well this seems easily possible and I was quite surprised how good it looks, even with long text on the same line. A few questions/comments:

• Is an image really required? (There is already a taskforce icon on the same row of the table.)
• If an image is desired, would it make sense to use the same image as the taskforce icon (albeit smaller)?
• I think it would be nice to standardise the height of these portal boxes. (Perhaps by specifying a maximum height of the image?)
• I would be reluctant to add a TF_#_PORTAL parameter to the main template, because I think it should be kept as simple and easy to use as possible, but this might be a good addition to the /taskforces hook.

— Martin (MSGJ · talk) 16:43, 4 April 2010 (UTC)

I notice that my code in the Canada sandbox has been removed, so I've changed to a Japan example above. — Martin (MSGJ · talk) 17:10, 9 April 2010 (UTC)

Answering in order: I don't know that an image is necessary, especially since it will be so tiny. I would remove it. Setting a standard height for the portal box is fine, though maybe unnecessary without an image. I agree that adding it to the taskforces hook would be the best place for it, though it may be nice to add an additional hook to the main template in case there's more than one related portal without a related task force. ···日本穣^? · 投稿 · Talk to Nihonjoe 18:25, 9 April 2010 (UTC)

Turns out that having no icon is not an option that is currently available with Template:Portal, so I have started a thread over there which will need to be resolved first ... — Martin (MSGJ · talk) 22:33, 9 April 2010 (UTC)

Maybe we could just have it display one of the many arrow icons we have. I think one of these would work well: , , , , or . The arrows would work for any of them quite well. If we just picked one that was the same no matter which portal it was (this is for the taskforces hook only), it should work well. ···日本穣^? · 投稿 · Talk to Nihonjoe 23:21, 9 April 2010 (UTC)

I think that having a consistent portal icon would bring some much-needed attention to the portal namespace. --—Arctic Gnome (talk • contribs) 16:47, 11 April 2010 (UTC)

Yes, an arrow might work well, or alternatively just use the standard portal icon . I think on reflection it might be simpler just to use the default icon for each portal (Template:Portal now selects this icon automatically). — Martin (MSGJ · talk) 13:07, 10 April 2010 (UTC)

This feature is now live on the taskforce hook, so TF_n_PORTAL parameters may now be specified. (For the main 5 taskforces, a call to {{portal}} can be added to the TF_n_TEXT parameter instead.) Feel free to tweak it. — Martin (MSGJ · talk) 21:58, 10 April 2010 (UTC)

Just wondering if it would be better to move the portal code to the start in the taskforce template as it looks better when the task for text needs to word wrap. Size your browser window so that the text below for the task forces is on more than one line and see which is better. -- WOSlinker (talk) 14:02, 18 April 2010 (UTC)

{{WPBannerMeta |PROJECT = N/A |category = no |MAIN_TEXT =   |HOOK_TF = <tr><td>'''Current'''</td><td><hr></td></tr> {{WPBannerMeta/taskforce |category=no |LINK = Wikipedia:WikiProject Soft Drinks/Coffee and Tea task force |NAME = Coffee & Tea task force |IMAGE = Emblem-relax.svg |SIZE = 60 |TEXT = {{{TF_1_TEXT|}}} |importance = Top |IMPN = importance |PORTAL = Drink }} <tr><td>'''Sandbox'''</td><td><hr></td></tr> {{WPBannerMeta/taskforce/sandbox |category=no |LINK = Wikipedia:WikiProject Soft Drinks/Coffee and Tea task force |NAME = Coffee & Tea task force |IMAGE = Emblem-relax.svg |SIZE = 60 |TEXT = {{{TF_1_TEXT|}}} |importance = Top |IMPN = importance |PORTAL = Drink }} }}

That is indeed an improvement.  Done — Martin (MSGJ · talk) 14:15, 18 April 2010 (UTC)

Further proposals for portals and taskforces

While we are talking about these things, I have a few more ideas:

1. Remove support for the PORTAL_IMG parameter. Now {{portal}} selects the portal icon automatically, it would be simpler and more consistent to just use that feature. Changes can be made to Template:Portal/images which will then be mirrored on all usages of that portal link.
2. Change the TF_n_SIZE parameters so that instead of specifying the width of the images, it will specify the height. A default height of say 25px can be used. This will produce a neater banner because the rows would be more likely to be the same height. (This could also be done for the NOTE_n_SIZE parameters.)
3. Remove the TF_n_SIZE parameters from the main 5 taskforces. This would simplify the main template and would still allow projects to use the taskforce hook if they wanted to use this feature. (We could also remove the NOTE_n_SIZE and NOTE_n_FORMAT parameters for the same reason.)

— Martin (MSGJ · talk) 22:10, 10 April 2010 (UTC)

Number 1 now implemented. — Martin (MSGJ · talk) 21:08, 17 April 2010 (UTC)

Which default height do people think is most appropriate for the taskforces? (Please check the examples below.) — Martin (MSGJ · talk) 15:06, 18 April 2010 (UTC)

{{WikiProjectBannerShell|category=no|
{{WPBannerMeta/test|short-story-task-force=yes|crime-task-force=yes|fantasy-task-force=yes|sf-task-force=yes|19thC-task-force=yes|australian-task-force=yes|narnia-task-force=yes|lemony-snicket-task-force=yes|shannara-task-force=yes|sword-of-truth-task-force=yes|category=no|height=20}}
{{WPBannerMeta/test|short-story-task-force=yes|crime-task-force=yes|fantasy-task-force=yes|sf-task-force=yes|19thC-task-force=yes|australian-task-force=yes|narnia-task-force=yes|lemony-snicket-task-force=yes|shannara-task-force=yes|sword-of-truth-task-force=yes|category=no|height=25}}
{{WPBannerMeta/test|short-story-task-force=yes|crime-task-force=yes|fantasy-task-force=yes|sf-task-force=yes|19thC-task-force=yes|australian-task-force=yes|narnia-task-force=yes|lemony-snicket-task-force=yes|shannara-task-force=yes|sword-of-truth-task-force=yes|category=no|height=30}}
{{WPBannerMeta/test|short-story-task-force=yes|crime-task-force=yes|fantasy-task-force=yes|sf-task-force=yes|19thC-task-force=yes|australian-task-force=yes|narnia-task-force=yes|lemony-snicket-task-force=yes|shannara-task-force=yes|sword-of-truth-task-force=yes|category=no|height=35}}
}}

25px works best for me. I wouldn't remove the TF/NOTE_SIZE parameters from the main template. It doesn't save any code except for pass-throughs, and it introduces an unnecessary deviation between the core features and the hooks. Happy‑melon 16:29, 18 April 2010 (UTC)

Yes, I was thinking that either the 25 or 30 looked about right. About the SIZE and FORMAT parameters, I don't see anything wrong with having additional features in hooks which are not supported by the main template. I think this is something we should do more of, actually. So the deviation is not a problem from my viewpoint. Secondly, it doesn't even seem to be a useful feature: although I've seen them used in some banners, it's always the same size that it used for all taskforces. I don't think I've ever seen different sizes used for different taskforces and I can't really imagine why this would be a good idea. — Martin (MSGJ · talk) 17:49, 18 April 2010 (UTC)

Any more responses to this? I still suggest removing the size parameters from the main template, or at least reducing to one parameter for all notes (NOTE_SIZE) and one for all taskforces (TF_SIZE). — Martin (MSGJ · talk) 19:21, 20 April 2010 (UTC)

I've now added the TF_SIZE and NOTE_SIZE parameters and removed all the separate ones. (For compatibility with the old syntax, these parameters will default to TF_1_SIZE and NOTE_1_SIZE.) If a case ever arises when different sizes are needed, then the hook can be used. I've also added a tracking category to find uses of the NOTE_n_FORMAT parameters. — Martin (MSGJ · talk) 15:16, 23 April 2010 (UTC)

I think the TF_SIZE and NOTE_SIZE parameters should also be added to the hooks as default options (also keeping the individual sizes). I've done the changes for the taskforce hook and the note hook in the sandboxes. -- WOSlinker (talk) 18:14, 23 April 2010 (UTC)

I agree and had the same idea myself. Thanks for doing that. — Martin (MSGJ · talk) 20:08, 23 April 2010 (UTC)

Category:Automatically assessed articles

I think that Category:Automatically assessed articles should be renamed to Category:Automatically-assessed articles since "automatically-assessed" is a compound modifier and should be hyphenated (see Hyphenation#Compound modifiers). The subcategories will also need to be renamed but, if I'm not mistaken, updating this template should result in a trickle-down update to all WikiProject banners which make use of the AUTO_ASSESS_CAT parameter.

The transfer of categories (including the creation of new Automatically-assessed {Topic} articles) can be processed through the category speedy renaming process so that the actual edits will be made by a bot. The transfer of articles will, if I understand this template correctly, take place automatically. The only manual work that will be required is: (1) listing all categories at WP:CFD/S, which will take me a few minutes to do; (2) updating this template, which will take a few seconds to do; and (3) updating any incoming links to the subcategories, which I also can/will do.

The change can be speedied, technically, but I thought that prior notice could perhaps bring to light any issues I've overlooked. Thoughts? -- Black Falcon ^(talk) 00:18, 22 April 2010 (UTC)

With respect, I have to say this sounds like a complete waste of time. — Martin (MSGJ · talk) 07:18, 22 April 2010 (UTC)

In a project of this nature, where all members are volunteers and there is no deadline, no positive change is a "waste of time" as long as someone is willing to undertake it and not force it on others. The manual work will take me maybe fifteen minutes and the rest will essentially take place automatically, so there will be no "waste" of anyone's time. -- Black Falcon ^(talk) 17:23, 22 April 2010 (UTC)

The non-hyphenated version is actually becoming much more common, and is even mentioned in style manuals as acceptable in some cases. I see no reason to do this. ···日本穣^? · 投稿 · Talk to Nihonjoe 07:52, 22 April 2010 (UTC)

It is becoming more common, but the hyphenated form is undoubtedly clearer; see a related discussion here, where consensus was for hyphenation. Without a hyphen, "automatically" and "assessed" appear as if they independently modify "articles"; with a hyphen, it is clear that "automatically-assessed" is a compound modifier. -- Black Falcon ^(talk) 17:26, 22 April 2010 (UTC)

In this case, not really as "automatically" can not grammatically modify "articles" as "automatically articles" has no meaning. It is therefore obvious that "automatically" modifies "assessed". ···日本穣^? · 投稿 · Talk to Nihonjoe 20:42, 22 April 2010 (UTC)

Contextually, yes, but not grammatically; with the current wording, "automatically" modifies "articles" and results in the nonsensical "automatically articles". To put it another way: I don't doubt that you're right that some sources will indicate that "automatically assessed" is acceptable, but all sources will confirm that "automatically-assessed" is correct. -- Black Falcon ^(talk) 21:37, 22 April 2010 (UTC)

I imagine this will be wreak havok on the job queue. I actually prefer the current way, fwiw - pedantry be damned. Not to mention the incoming links to these places will break. –xeno^talk 17:37, 22 April 2010 (UTC)

We generally don't worry about short-term performance issues, do we? As for the incoming links, there aren't many, and I would update any that are broken. -- Black Falcon ^(talk) 17:47, 22 April 2010 (UTC)

To every single subcategory as well? –xeno^talk 18:38, 22 April 2010 (UTC)

Yes. Each subcategory has only a few incoming links, and many of those appear to be automatically-generated (i.e., renaming the categories should cause the links to update automatically).

Also, since category renaming is processed at a central location (WP:CFD/W), it is generally easiest to update any incoming links to renamed categories immediately after the categories are renamed. I watchlist WP:CFD/W and routinely check for and update incoming links to deleted and renamed categories (see e.g. here). -- Black Falcon ^(talk) 19:23, 22 April 2010 (UTC)

Meh. I still don't think this needs to be done, but I'll admit it's more of an "idontlikeit" objection. These categories are not part of the mainspace and should typically be {{hidden category}} so I don't see the need for adherence to a manual of style. Personally, I think it looks more natural without the dash. But no I'm not going to belabour the point because in the end it's no big deal. –xeno^talk 19:30, 22 April 2010 (UTC)

I do appreciate that you expressed your opinion. I know now, for example, that the change should not be listed at WP:CFDS; I may initiate a full CfD for the main category, but I think I'll hold off for now... Thanks, -- Black Falcon ^(talk) 20:01, 22 April 2010 (UTC)

"If it's not broken, don't fix it" - no? It is grammatically correct the way it is, according to some style manuals. 70.29.208.247 (talk) 12:46, 23 April 2010 (UTC)

Rename an attribute?

Hi, I'm with WikiProject Essays and we'd like to rename the "importance" attribute to "impact" as that will clear up some recurring debates we're having, as newcomers don't understand that we're using "importance," to signify how much impact an essay has on Wikipedia, through analysis of watchers, pageviews, and incoming links. Is it possible to use "impact" instead of "importance"? ɳorɑfʈ ^Talk! 05:54, 24 April 2010 (UTC)

I'm sure that can be achieved fairly easily. What scale do you intend to use - {Top, High, Mid, Low}? — Martin (MSGJ · talk) 06:28, 24 April 2010 (UTC)

Here you go - code is in the /sandbox:

I doubt if the bot will recognise these categories though. — Martin (MSGJ · talk) 06:40, 24 April 2010 (UTC)

We want to do it exactly the same way we're doing it now, and just change the name of the attribute from "importance" to "impact," so we'll still be using Top, High, Mid, and Low. If the bot won't recognize it, I'm wondering if we can just change the name where people can see it...meaning the bot still recognizes "importance" and tags as such, but the template itself says "Impact" where humans are reading it. Is this possible? ɳorɑfʈ ^Talk! 03:59, 25 April 2010 (UTC)

AFAIK as long as the "Top-foo" category is in Category:Top-importance articles, the bot is happy. Happy‑melon 20:27, 25 April 2010 (UTC)

Portal images

I'm trying to get File:Empire State Plaza symbol 2.svg to show up in the Portal box at {{WPCapitalDistrict}}. In checking another template that uses WPBannerMeta, {{WikiProject Geography}}, I see it successfully uses the PORTAL_IMG field. Why can't I get it to work? Additionally, it would be helpful if I could add a second portal (that for Portal:New York); is this possible, or are you limited to one portal per template? Sorry if this is a simple issue; I'm not exactly a coder. upstateNYer 05:10, 1 May 2010 (UTC)

Never mind about the image; I updated Template:Portal/images. But I would still like to know about multiple portals, if possible. Gracias. upstateNYer 05:16, 1 May 2010 (UTC)

I've added two portals to the banner by changing the MAIN_ARTICLE parameter to MAIN_TEXT and then using the {{portalbox}} template. See [10]. -- WOSlinker (talk) 07:54, 1 May 2010 (UTC)

Excellent. Thanks a bunch! upstateNYer 14:02, 1 May 2010 (UTC)

B-class checklist

I mentioned last year that I was thinking about moving the B-class checklist functionality to a hook. The rationale is that it adds quite a lot of complexity to the main template but relatively few projects use it. I would also like to add additional options and features to the checklist, as well as experimenting more with fixing the internet explorer display issue. For this reason I still think this is a good idea. — Martin (MSGJ · talk) 17:24, 25 April 2010 (UTC)

First step: move B-checklist normalisation code from /class to {{class mask}}. Proposed code is on Template:WPBannerMeta/class/sandbox and Template:Class mask/sandbox. — Martin (MSGJ · talk) 11:23, 27 April 2010 (UTC)

Talk:Fishkill Creek, which I assessed as B-Class, is showing up as C-Class for two projects. –Juliancolton | ^Talk 23:32, 27 April 2010 (UTC)

Three of the four projects on Talk:Lower East Side are showing up as C-Class when all four are assessed as B-Class. – TMF 05:15, 28 April 2010 (UTC)

After looking at several articles, it seems as if B-Class is showing up as C-Class for all projects that use this template. Since that's, what, 97% of WP, this is kind of a big issue... – TMF 05:18, 28 April 2010 (UTC)

In Template:WPBannerMeta could someone change ... Code redacted for readabiliy. — Martin (MSGJ · talk)

which I think should fix the issue. Thanks. -- WOSlinker (talk) 06:47, 28 April 2010 (UTC)

 Done. Sorry guys, that code was in the sandbox. I just forgot to deploy it! — Martin (MSGJ · talk) 06:56, 28 April 2010 (UTC)

• Update: We now have a /bchecklist hook, and I am gradually changing the banners which use the checklist so that they use the hook instead. — Martin (MSGJ · talk) 12:17, 30 April 2010 (UTC)

The {{WP UK Politics}} banner has recently had the new hook added but I am seeing some strange behaviour. On Talk:Referendums in the United Kingdom the class is set to "B" but the banner is defaulting to "C" because the checklist hasn't been completed. Previously the class field overruled the checklist.

Is this now the normal behaviour for the banners or has a bug crept in somewhere? Road Wizard (talk) 21:02, 9 May 2010 (UTC)

This was always the intended default behaviour and looking at Template:WP UK Politics/class I can't immediately see why this didn't happen previously. If it's not desired it can very easily be fixed by removing the b1-b6 parameters from that page. — Martin (MSGJ · talk) 07:29, 10 May 2010 (UTC)

I have no problem with it if that is how it is supposed to behave. When the b-class checklist was first added the class field overruled the list, then for a week or so the current behaviour appeared before reverting back to the class field ignoring the list. I can't remember now whether it was adjustments to the banner or the meta that was causing the switchover. However in any case it is no longer relevant. Thanks for the reply. :) Road Wizard (talk) 08:30, 10 May 2010 (UTC)

What would people think about automatically promoting a C-class article to B-class if all of the criteria are satisifed? — Martin (MSGJ · talk) 08:40, 10 May 2010 (UTC)

Bibliography box

Hi, inspired by Wikipedia:Village_pump_(development)#Question_regarding_bibliography_articles, could we add an additional parameter along the lines of the PORTAL parameter. This would give a box much like the portal one (below the portal, if it exists), to a Bibliography subpage of the relevant wikiproject. Make sense? Need wider discussion (somewhere else?)? Rd232 ^talk 01:07, 7 May 2010 (UTC)

I've commented on Wikipedia:Village pump (development) to keep the discussion in one place. — Martin (MSGJ · talk) 10:56, 7 May 2010 (UTC)

Collapsed section

After working on Template:ArticleHistory I found a possible nice way to simplify the code for the collapsed section. Instead of putting the notes in a table when the collapsed threshold is reached, we can put all the notes into a table and just make it collapsible when the thresold is reached. This means we don't have to use the /collapsed subpage anymore. Any thoughts? The code is on /core/sandbox. — Martin (MSGJ · talk) 11:33, 7 May 2010 (UTC)

 Review Any chance of a code check on this? — Martin (MSGJ · talk) 20:38, 9 May 2010 (UTC)

Works when I tried it out on a test banner. -- WOSlinker (talk) 20:48, 9 May 2010 (UTC)

Thanks, this is now deployed. — Martin (MSGJ · talk) 08:25, 10 May 2010 (UTC)

note_1_cat

I was wondering if there a way to get more than one category in the parameter NOTE_1_CAT? Right now I have:

|NOTE_1_CAT={{#if:{{{toronto|}}}{{{Toronto|}}}|Wikipedia requested photographs in Toronto|}} {{#if:{{{montreal|}}}{{{Montreal|}}}|Wikipedia requested photographs in Montreal|}}

This works fine if an article is only tagged for one city, but if it is tagged for both, then it gets a long category name that uses both cities. I could fix the problem by making note_1 "toronto-needs-photo" and note_2 "montreal-needs-photo", but that puts two image-needed icons in the template and makes the parameter names longer, so I'm curious about whether there is another solution that I missed. —Arctic Gnome (talk • contribs) 20:08, 9 May 2010 (UTC)

Nevermind, User:MSGJ solved my problem. —Arctic Gnome (talk • contribs) 20:19, 9 May 2010 (UTC)

I partially solved the problem using a reverse switch. Adding a separate note for each taskforce would be a more robust solution (Template:WikiProject Japan takes this approach to extreme lengths). Otherwise we could look at hooking extra categories to the taskforces like Template:WPBiography does. — Martin (MSGJ · talk) 20:37, 9 May 2010 (UTC)