Module talk:WikiProject banner/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

→

Archive 15

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 {{WPBS}} 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 {{WPBS}} 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)