User talk:Happy-melon/Archive 9

Lowercasing
If you're going to lowercase special: links can you also do MediaWiki:Sp-contributions-logs so they'd be consistent? (I'm supposing that's the page based on MediaWiki:Sp-contributions-blocklog that you created. Where's the convention from by the way? -- Menti  fisto  01:00, 5 March 2009 (UTC)
 * The discussion was at VPT; we were simply trying to lowercase the links that appear in the 'toolbar' brackets after users' names in watchlists, contribs, etc. Happy‑melon 08:56, 5 March 2009 (UTC)
 * Alright... well, is it visible for everyone? 'Logs' is capitalized on Special:Contributions/Example whereas 'talk' and 'block log' aren't. Surely that must be consistent like you thought Talk in the watchlist should? -- Menti  fisto  19:12, 5 March 2009 (UTC)
 * Indeed it should; unfortunately the same message is also used for the "logs" link in the sidebar toolbox; so it sticks out like a sore thumb when lowercased. I might have a look at that at some point. Happy‑melon 22:12, 5 March 2009 (UTC)
 * Have you tried MediaWiki:Sp-contributions-logs? Since it seems it's specifically for Special:Contributions could it possibly only change the one there? -- Menti  fisto  22:31, 6 March 2009 (UTC)
 * Tried it, doesn't seem to do anything. Happy‑melon 22:38, 6 March 2009 (UTC)
 * Hey, I noticed that the Logs was capitalized and looking out-of-place, so I came here. I asked User:Xavexgoem what the contents for MediaWiki:Sp-contributions-logs was as it was deleted, and when he told me, I asked him to restore it. That was when I noticed that you created the template just recently to test the same thing as I wanted to do, so I see that that page is useless. Anyway, MediaWiki:Log is definitely the only system message that has "Logs" anywhere in its contents. I went through the code for the page and can confirm that it pulls only from MediaWiki:Log and nowhere else, so I just submitted a report to MediaWiki about this. Gary King  ( talk ) 05:25, 7 March 2009 (UTC)
 * Okay MediaWiki now includes it, so when Wikipedia updates its MediaWiki, it will have it. Gary King  ( talk ) 06:41, 7 March 2009 (UTC)

Updated version of Infobox Protected area
I've written an update for Infobox Protected area. And I was hoping you might have time to review the new version and share any input. The updated version can be found at User:Droll/template and a test page is at User:Droll/tests. I know this is a lot to ask but I'm just getting started at this. I'm a retired programmer but I never saw anything like this before. I coded a few citation templates already but nothing like this.

I haven't mentioned this on the project page yet and I'm not sure how it will be received. Anyway I had some fun coding it. --DRoll (talk) 04:11, 6 March 2009 (UTC)


 * As long as you enjoyed the process of writing it, then it's a net benefit to the encyclopedia. I've had a look, and can't see anything glaringly wrong, but I'm not entirely sure what modifications you've made.  What were you trying to accomplish? Happy‑melon 08:39, 6 March 2009 (UTC)

Regarding infoboxes, I was going to suggest that you/I/we could have a long look at these with a view to improving their code and merging common functionality. (I'm talking generally and not about the above template, which I haven't looked at yet.) There's a user User:J JMesserly going round implementing "microformat data" on all of these and it struck me that it would be better if the code was centralised so that hundreds of infoboxes didn't need maintaining separately. Another area of improvement might be the templatepage of these infoboxes. Typically there is no display at all which doesn't help to see what they do at a glance. What do you think? (I've been waiting till today because it said you were busy at the top!) &mdash; Martin (MSGJ · talk) 08:48, 6 March 2009 (UTC)
 * There's a meta-template that should be used for such things; the usual principles apply.  It's not something I'm particularly interested in, but do go ahead if you think there improvements to be made! <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 11:22, 6 March 2009 (UTC)
 * Okay, I'll take a look at that template. By the way, I didn't notice any discussion about removing default support for redirect-class from WPBM. Perhaps it would be an idea to get people's thoughts about this, because it seems a major change. I don't have a strong view on it, but would like to see the reasons behind it. &mdash; Martin (MSGJ · talk) 12:09, 7 March 2009 (UTC)
 * I'm just doing groundwork at the moment, and trying to stop unnecessary further proliferation of the system. As you can see from the stats at User:MelonBot/Redirect-Class categories, over half the Category:Redirect-Class Foo articles categories are empty; I have a nasty feeling that many of these were created by editors simply because WPBM told them to.  Over half of all articles marked as Redirect-Class are from just four projects; 12 projects have over 80% of the total articles.  The system is ridiculously skewed towards those few projects.  But of course, as you say, there'll be a need for consultation; it's not something I plan on doing unilaterally :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 12:17, 7 March 2009 (UTC)

Thanks for the input. The changes are detailed at User:Droll/tests.

I didn't mean to start another standardization discussion although I should have guessed. The meta-template infobox is not apropriate for projects that use maps and coordinates. There is a meta-template geobox but wikipedians at WikiProject Mountains don't like it because they believe it is almost impossible to maintain. In my opinion it tries to do too much. People are reluctant to change you might have noticed. I would be more than happy to be involved in a standardization project as long as I don't need to be the ball carrier. --DRoll (talk) 23:22, 6 March 2009 (UTC)

Template:WPAFC/class restored
I was working on creating redirects for Articles for Creation, when I noticed that suddenly they, disambiguation pages, files, and other pages were all being called NA class and sorted into the NA category instead of being treated as their respective types. It took me a while to figure out why, but apparently it's because Template:WPAFC/class was restored. I couldn't find any discussion about this, so I came here to ask why that change was made.&#32;-- kenb215 talk 16:29, 7 March 2009 (UTC)
 * The custom mask was wrong. I have deleted it for now, and can create a correct version if/when it's needed. &mdash; Martin (MSGJ · talk) 19:56, 7 March 2009 (UTC)
 * Wheel war! :D Entirely my fault, however, for implementing a broken mask (should have followed my own advice and not copied from WPBM's own). <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 10:51, 8 March 2009 (UTC)

A very personal question
Why doesn't the color of your signature change after I visit you user page. My new sig just turns blue. Is it magic that you can share or am I missing something. I know its my browser that does it.

Never mind. It was my own foolish mistake. --<font style="color:#355E3B">droll <font style="color:#704214">&#91;chat&#93; 06:16, 9 March 2009 (UTC)

Version 0.7 and assessment
Hi Happy-melon,

I'm trying to set up an IRC meeting with Linterweb, possibly Tuesday but perhaps Thursday (evening UTC). This will be to discuss the final publication. Would you be available? We now have a working index and a list of 75,000 possible "bad words" to check - we're trying to reduce the latter.

Also, we've been discussing assessment here, and you've been noticeable by your absence from the discussion. That page didn't start well, being accused of elitism (it was originally listed as being for "WikiProject coordinators"), but since we clarified that it's open to all we've actually had quite a decent discussion, summarised here. Do you have any comments to make? Walkerma (talk) 10:45, 9 March 2009 (UTC)

Film
Umm, what naming convention? PC78 (talk) 23:28, 6 March 2009 (UTC)


 * Why was no one from the project consulted about this? Girolamo Savonarola (talk) 01:26, 7 March 2009 (UTC)


 * The "Template:WikiProject PROJECT" format that, IIRC, about two thirds of WikiProject banners currently follow. Is there any reason why the change was undesirable? <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 10:45, 7 March 2009 (UTC)


 * So we no longer require getting consensus? We just unilaterally change things and worry about the project's thoughts after the fact? I'm disappointed. Girolamo Savonarola (talk) 15:35, 7 March 2009 (UTC)


 * It's not the change but the manner in which it was done. As you are neither citing an actual naming convention nor personally involved with the project then this wasn't your call to make. If you felt a rename was appropriate then you should have raised the issue with the project first; if nothing else it would have been a common courtesy. I am also rather surprised by your actions here. PC78 (talk) 18:42, 7 March 2009 (UTC)


 * Concur with the above. Additionally, the collateral damage already incurred was a day's loss of the article alerts, followed by today's resetting, which has falsely stated at least a half dozen discussions as being closed. While that certainly was not an intended consequence and likely is a design flaw of the bot, it's rather upsetting to see it triggered by a move that, best as I can tell, was only mentioned ahead of time in passing at BOTREQ, certainly not the right forum, and given virtually no pause to hear beyond the first support (from a non-project member, IIRC). If you cannot be bothered to ask the community for consent, then there is no right to assume we are actively silent on the matter. Given the response here, I'd respectfully ask that you respect the BRD cycle and (since neither PC78 nor I have the necessary tools to do so ourselves), revert your changes for the moment. I'm more than happy to open a proper and well-announced discussion on the question, but actions like these are wholly inappropriate and open admins up to accusations of "rogue". (Which I'm not arguing you are - I believe you acted in good faith, but I want you to be aware why this sort of action is not wise and reflects poorly on the admin system at large.) Girolamo Savonarola (talk) 00:27, 8 March 2009 (UTC)


 * I'm in agreement with Giro here. Had you made the suggestion of a change I would most likely have been supportive, but as things are I would rather you revert. This is an internal matter for the project's consideration. PC78 (talk) 00:38, 8 March 2009 (UTC)


 * Certainly I had no intention or suggestion that moving the page would cause collateral damage: I've reverted as you request, and apologies for that. However, I do believe you have reacted somewhat out of proportion here, Girolamo. How do your comments not conflict with relevant policy?? Would the situation somehow have been magically different if I had added my name to the WPFilms participants list before making the move?  Should it have been different?  The position that you appear to be taking, that WikiProject X owns its WikiProject banner and no one is 'allowed' to make significant changes to it without the project's 'permission', is unquestionably at odds with this and with WP:BOLD.  While in general the project's members are the ones who have the final say given that they are the ones who actually use the banner, to suggest that a project exerts a more ephemeral control than the ability to say "this makes our job harder" is dangerous to say the least.  I recognise the nature of the page, in particular its high visibility and consequent protection (which, as you note, requires me to revert when requested, no matter what the reason).  I find your implication that this page is somehow exempt from WP:BOLD and WP:OWN, and that 'non-members' require one to "ask the [WPFilms] community for consent" to modify, rather harder to see merit in.
 * To return to the issue at hand, however, are there reasons why a move would be undesirable? <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 10:48, 8 March 2009 (UTC)
 * Suppose someone came along and moved Template:WPBannerMeta to Template:WikiProject Banner meta without any prior discussion, because of a perceived naming convention? I think you might feel slightly annoyed, not because you "own" the template, but because you've put a lot of work into it and use it frequently. Such a move would also likely have several unintended consequences if the editor was not familiar with the template, as it did in this case. I don't think the analogy is completely inappropriate. It's not policy that forbids this, just courtesy. I do not think there is a contradiction with WP:OWN here, honestly. I think you can argue that WP:BOLD supports it, but with one of the most widely used templates on Wikipedia and one of the most active WikiProjects, it is possible that it was too bold :) Having said this, I agree that the comments above are stronger than necessary. A simple request to revert and discuss would have been sufficient. &mdash; Martin (MSGJ · talk) 11:25, 8 March 2009 (UTC)
 * If I were to react visibly, it would be to note that the capitalisation is at odds with Category:WikiProject banners :D. I agree that my immediate internal reaction would indeed be "WTF?"; however, I hope that I would then judge the action on its merits (and now you come to mention it, it does have some!). Try it and find out :D. Or actually, don't, as you're quite right in that moving it without doing some pretty speedy tidying up would make an awful mess.  If WP:BOLD is weakened with regards to high-profile templates, it is for that reason; and allow me to add an apology for the collateral damage I did cause to my comment above.  Certainly in these areas, WP:BRD is particularly important. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 11:40, 8 March 2009 (UTC)
 * I don't see any issues with WP:BOLD here; the guideline itself warns users to be careful and not be too bold. You're an admin which means you can freely edit protected templates and such, but that doesn't mean that you necessarily should, it doesn't preclude you from discussing things beforehand like the rest of us. I also don't see any issues with WP:OWN; as Martin says, it's just courtesy. Even if you were an active member of the project I would expect some prior notice to have been given. After all, we're talking about a highly used template by one of the largest and most active projects. Still, no harm done at the end of the day, and I have no doubt that you had the best of intentions. :) To answer your question (and reiterate what I've said elsewhere), I have no real objections to a rename and am indeed supportive to an extent, though to be honest I do like the brevity and ease of using Film. But likewise, are there any reasons why you feel the project need not have been approached beforehand about making this change? PC78 (talk) 12:14, 8 March 2009 (UTC)
 * I think you hit the nail on the head with the way you phrase that question: there is no particular reason why, in my mind, WPFilm should have 'preferential treatment' in terms of "being approached beforehand"; "need not" being of course very different to 'should not'. If I had voiced a proposal beforehand, it would have been on Template talk:Film rather than Wikipedia talk:WikiProject Films; the process I supported at, for instance. As for why I thought it acceptable to be bold, well, it's a name, a superficial change that has no visible effect except on one page. Of course while I was careful to ensure that the move didn't break the banner the change wasn't quite as silent as I expected, and apologies again for that, but if my assumption that it would have been a silent transition had been correct, what impact would the action have had?   will still work just as well as  no matter which contains the actual banner code; changing that, by contrast, would be a very major change, for which we have a proper process that it would be completely inappropriate for me to bypass. But I'd find it difficult to get worked up over such an (ideally) invisible change.  Of course since it is apparent that the change was not uncontroversial a revert-and-discuss process is appropriate.  But I don't think it's fair to conclude that the initial bold action was consequently inappropriate. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 12:33, 8 March 2009 (UTC)
 * A proposal at Template talk:Film would have been fine. I'm genuinely surprised that you think a project should not have "preferential treatment" (as you call it) with regard to it's tools and resources; ultimately it is the project which uses the banner, not you. Heck, even if you think you're right and the change really is inconsequential, sometimes it's just best to err on the side of caution. PC78 (talk) 13:06, 8 March 2009 (UTC)
 * It's more that I don't really regard "a WikiProject" as an independent entity, essentially they are to my mind just organised groups of individual editors. The editors are what's important (and they are very important, make no mistake), not the structures and titles they attach to themselves.  The editors that are both interested in and technically literate enough to understand the workings of a WikiProject banner, will or should have the page on their watchlists and so be able to respond to discussions started there.  Those members of a WikiProject who don't have the banner on their watchlist probably aren't interested in how the banner does whatever it does as long as it does do whatever it does.  For changes to a banner that will affect how editors can use the banner, which will therefore be 'of interest' to every member of a project, putting the notice in a location that they're more likely to be watching would be appropriate.  But I guess the distinction is that I don't think the project's opinion should be consulted because I don't believe that "a project" can have an opinion; if there is an opinion to be consulted, it is that of those editors who are likely to be interested in the banner template. Although the fact that most or all of those editors are also project members is not coincidental, it is not to my mind noteworthy.  In this context, the only difference between a WikiProject banner template and some other well-used template, say, is that the editors who are interested in the former are more likely to be members of the same WikiProject; so while the project talk page is an equally good place to propose changes, it is not necessary to put them there. I hope this clarifies how I see the situation. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 13:37, 8 March 2009 (UTC)
 * I don't actualy dispute any of that (except to say that the opinion of a WikiProject would be the concensus opinion of its members), but none of that is the issue. I never suggested that you should have raised the issue at WT:FILM, only that you should have raised it at Template talk:Film where interested editors would have had the opportunity to respond to it. PC78 (talk) 15:33, 8 March 2009 (UTC)
 * And perhaps you are right; certainly a more substantial and noticeable change would require such an approach. The issue, of course, is that it is rarely possible to tell except by the application of common sense which changes would benefit from such prior discussion, and which are sufficiently trivial as to not be worth spending time discussing, without being bold enough to try them and see what reaction occurs.  Hence the importance of WP:BRD.  It is never the 'wrong' approach to discuss changes before implementing them, and it is definitely not 'right' to implement major changes without discussion.  The large grey area in the middle is why we need all editors, admins and not, to exercise judgement, civility, and common sense.  On which note, PC78, thank you for bringing all three of those to this discussion.  <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 15:55, 8 March 2009 (UTC)


 * Hi. The bot task has been approved now, so all I'm waiting for is consensus on what the template name should be.  I'm not sure if you're aware -- the bot will not mass-migrate either  to  or  to  -- it will leave both those template calls exactly as they are.  Do you have a continuing objection to the bot's running?  Thanks!   [[Sam Korn ]] (smoddy) 14:38, 9 March 2009 (UTC)
 * in case you didn't see this...  [[Sam Korn ]] (smoddy) 17:09, 9 March 2009 (UTC)
 * Oh, sorry, did see this but then forgot. As you've said, not exactly an earth-shattering issue.  On the other, it's not fundamentally necessary to expand the redirects at all.  If the script won't convert between the two 'disputed' titles, then I don't have a justifiable objection to it running. So go ahead :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:18, 9 March 2009 (UTC)

Template:WikiProject Korea/sandbox
Cheers, schoolboy error on my part I guess! :) PC78 (talk) 18:29, 8 March 2009 (UTC)
 * Well, not really, I'm rahter scratching my head as to why it didn't work. With the check in, it should have worked... <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:31, 8 March 2009 (UTC)

On an unrelated note (but following on from our other discussions), what's the status of WikiProject Council/Banner standardisation? Seems like you drew up the proposal following discussions at the WPCouncil but then never did anything with it. Is it still something that you're interested in pursuing? PC78 (talk) 19:59, 8 March 2009 (UTC)


 * Maybe, although I'm not really sure how best to start. Moving 400 banners is a completely different kettle of fish to moving one. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 08:44, 9 March 2009 (UTC)


 * Interestingly enough, I see that this very issue has popped up at Wikipedia talk:WikiProject coordination group. PC78 (talk) 15:56, 9 March 2009 (UTC)

MellonBot breaking table rows
The MellonBot is not removing templates correctly from inside wiki-tables. See this example. The  |-  should remain on a line of its own. -- Patleahy (talk) 05:48, 9 March 2009 (UTC)
 * Thankyou for raising this point. I've added a check to the bot script that should stop this problem recurring. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 08:41, 9 March 2009 (UTC)
 * Thanks -- Patleahy (talk) 17:19, 9 March 2009 (UTC)

Template:WPBannerMeta
Hi, you're probably still working on this, but just in case you haven't realized, there seem to be some closing braces missing at the end (two after NAMESPACE and one after PAGENAME), and I guess this is causing the strange extra text to appear in transclusions.--Kotniski (talk) 14:52, 9 March 2009 (UTC)
 * That's a classic happy-melon-mistake! I've reverted. &mdash; Martin (MSGJ · talk) 15:06, 9 March 2009 (UTC)
 * Thanks MSGJ, I knew it was a good idea for you to have the bit :D. As you say, typical stupid this-is-a-simple-edit-oh-it-looks-ok-on-the-page-must-be-ok-now-i-have-to-go mistake.  <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 16:37, 9 March 2009 (UTC)
 * Would it be possible to put these tracking categories into templatepage so they will only categorise the banners? &mdash; Martin (MSGJ · talk) 16:55, 9 March 2009 (UTC)
 * Some of them certainly could go on /templatepage, although the one catching Redirect-Class articles obviously can't, nor can the small one, and the c note one would need to be redesigned. The reason I tend to put them there is A) they're all together that way, and B) it means that pages start to drop into the categories really quickly, so we can get straight to work updating them, following through the vde links on each banner.  We don't have to wait for the sometimes-rather-lethargic job queue to get round to updating the template pages themselves.  <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:04, 9 March 2009 (UTC)

Double redirects
Hi for the second time today... You were saying that it would be good to get consensus on the double redirects before Tuesday, and we seem to have it. I just wondered if you would be notifying the devs? (It sounds like you'd know how to go about doing that.) Thanks, --Kotniski (talk) 17:05, 9 March 2009 (UTC)
 * I literally just did; . <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:06, 9 March 2009 (UTC)
 * Great, thanks! Assuming it happens, do you think this could be put on a watchlist notice for a few days, to make sure everyone knows about it? Possibly with a link to a discussion about how bots are going to treat double redirects from now on?--Kotniski (talk) 17:44, 9 March 2009 (UTC)
 * As and when :D This should get higher priority than other config changes because it's tied to the software scap, but in general config changes can languish for months without being resolved: see, for instance. Let's see how things go (and whether Brion actually scaps tomorrow, of course :D) <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:48, 9 March 2009 (UTC)

Category:GFDL 1.2 images
Would you mind taking a look through Category:GFDL 1.2 images when you have a chance? Most have been through some deletion process and are just waiting for deletion. Thanks! ▫  Johnny Mr Nin ja  00:10, 10 March 2009 (UTC)
 * I've done a few, but images aren't really my strong point so I'm not really able to do the more borderline ones. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 08:41, 10 March 2009 (UTC)
 * No prob, thanks for the hand. When I left for work there were 28 and now there are 4 (3 other sysops helped; maybe they were watching your page or maybe they just saw the backlog), and those 4 probably shouldn't be deleted at this moment, so that's great! Even if those 4 are kept, they will be moved to Commons, so we pretty-much have an empty category. A month and a half ago there were 200, so this is very rewarding. Again, as usual, thanks for the hand. ▫  Johnny Mr Nin ja  12:30, 10 March 2009 (UTC)

TfD Holding cell
I've reverted your changes to the TfD Holding cell. I've edited that page for quite awhile and I prefer the old version.--Rockfang (talk) 16:52, 10 March 2009 (UTC)
 * Well naturally I'm open to discussion, but I'm not sure a blanket revert was the most productive way of proceeding. There is absolutely no point in keeping sections that are unused, or in being unnecessarily bureaucratic in organisation.  When did anyone last use the "closing" section, for instance? IMO, for such a low-traffic page, one consolidated list with a one-line summary (or even just a link to the discussion, which will include the closing instructions; incidentally why revert my implementation of ?), should be more than adequate.  So BRD certainly, but what other reasons do you have for opposing my changes? <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:00, 10 March 2009 (UTC)
 * A blanket revert was simple and quick. If I hadn't come here to discuss it, then I can understand how a blanket revert would be unproductive.  I'm not sure about how useful the "closing" section is as I'm not an admin.  I'm one of the few non-admins that edit the holding cell.  If you want to remove the "closing" section, I won't revert it.  The other sections are good enough to keep in my opinion.  For non admins, it is a quick and simple way of seeing what needs to happen to certain templates without having to wade through the TfDs right away.  With regards to tfdlinks, I like how the templates are sorted by, and can be viewed by date of the discussion just by glancing at the page.  If you could change the template to display the date of the discussion, I'd be all for using it on the holding cell page.
 * On a semi-related topic, you may want to add some kind of documentation to the page for tfdlinks.--Rockfang (talk) 17:30, 10 March 2009 (UTC)


 * That's true, and thanks for raising this here; I hadn't watched that page so I wouldn't otherwise have known until I next looked at the bottom of WP:TfD. I can make  display the date of the discussion easily. I like it because it makes it easier for bots (and humans) to separate the templates that are being deleted from other templates that might be being proposed as replacements... the ones for deletion are the ones with "delete" links :D. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:37, 10 March 2009 (UTC)

Flagged revisions proposal
Hi. I am working on a minimal flagged revisions proposal focused on BLPs. FR may seem dead, but I think we can gain consensus on something small and focused. If you have time, any comments are appreciated. Wikipedia_talk:Flagged_revisions --Apoc2400 (talk) 15:52, 11 March 2009 (UTC)

Template: David Archuleta
can i create a template for David Archuleta? <font color="E32636">diR <font color="FEFE33">k dA RyL  <font color="7FFF00">♫  16:21, 12 March 2009 (UTC)

TfD question
Hey Happy-melon, hope this day finds you well. I had a question about closing things. I looked back at the TfD for the rescue template, and as I scrolled down, I noticed that some of the following threads that belonged to the discussion weren't within the closed / do not modify part. I had also seen threads (AN or AN/I, etc.) where multiple threads were contained within the closed topic. Am I right in guessing that the reason is that a boilerplate tfd-closed was used, rather than a discussion top and discussion bottom pair of tags in conjunction with the resolved|solution tag? Would I also be right in guessing that the other threads will get archived with the tfd-closed part all in the same place (I see that bots do a lot of the archiving). And lastly, and in a sense perhaps answering my own question - does any of it really matter? thanks ;) — Ched ~ (yes?) 17:58, 14 March 2009 (UTC)
 * Yes, a lot of these discussions are closed by bots or scripts, that have varying levels of reliability when confronted with somewhat unorthodox thread layouts. I personally close TfDs with a 'fire and forget' bot script that just takes my result and closing statement, and does the rest for me (see).  In a sense, no it doesn't matter, since anyone reviewing the archives will be aware of what the intention of the closure was, but on the other hand it's still nice to do the job properly.  So thanks for bringing this to my attention; I'll try and make sure that my script is modified to avoid this issue in future. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:11, 14 March 2009 (UTC)
 * Oh I wasn't trying to point anything out at all, I'm still far too deeply entrenched in the learning phase. I was just trying to wrap my head around the way different tags close different things.  And while I've done some javascripting in the (all too distant) past, I'm probably a good 6-9 months away from any bot work.  I hope you weren't taking my post as a childish "lookie - lookie" thing - was not meant that way in the least. — Ched ~  (yes?) 18:59, 14 March 2009 (UTC)

Non-free logo in Template:WikiProject Animation
You placed a non-free logo in Template:WikiProject Animation. I don't believe this is legally permissible. Please see my post on the template's talk page. (Thanks for the rest of your work on the template, though...) --Wulf (talk) 21:45, 14 March 2009 (UTC)

Left-aligned small ambox
Hi Happy-melon. I have left a message for you over at Template talk:Mbox. I wanted your input on a small detail before we deploy the new ambox "small=left" feature. But I see now that you are away until 22 March, so I guess I will have to be bold and hope I use the right solution to the issue you brought up at that talk page.

--David Göthberg (talk) 19:06, 15 March 2009 (UTC)

Valid XHTML in MediaWiki messages
Hi Melon Since MediaWiki doesn't let HTMLTidy clean up MediaWiki messages (17486), can you please take extra care when editing them that they are valid XHTML? Not only because it's A Good Thing, but also because Twinkle breaks horribly otherwise (WT:TW, WT:TW). Cheers, Amalthea  02:46, 15 March 2009 (UTC)


 * Thanks for the heads-up; although I'm not entirely clear why it wasn't breaking before given that the same or similar markup was being used... anyway thanks for finding and fixing that; looks like a pig of a bug to find! <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:12, 22 March 2009 (UTC)


 * Thank god for FireBug, without it I don't think I could have found that problem at all. :) The wiki-list was contained in a div before, which works; the parser bug seems to only surface when the list is in a table cell. The second problem was a &lt;p&gt; tag that wasn't closed, which wasn't in the markup before. Cheers, Amalthea  17:26, 22 March 2009 (UTC)


 * How bizzare. Thanks again! <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:28, 22 March 2009 (UTC)

What Needs to Be Fixed?
I have found that you created another category of pages with banner problems. Would you be so kind as to put an explanation of the problem at the top of the page along with some indication for those of us who are not versed in the programming language of banners and are not interested in trying to read your mind what needs to be done to the pages to correct the problem?

No hurry. First thing Monday would be soon enough unless you can do it before that.
 * JimCubb (talk) 03:25, 17 March 2009 (UTC)


 * Looks like WOSlinker has already added an explanation. While the tracking categories are mainly for the benefit of those already involved with the associated issue and would be in userspace or offline if that were possible, I am grateful for your willingness to help when the categories do flag up actionable issues that can be 'fixed'; I will try to be more consistent in providing explanations in the future. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:10, 22 March 2009 (UTC)

Melonbot
Hi, just wondering if you will start melonbot again removing Template:American films. I was trying to AWB it, but it is a little bit too much for that. :) Garion96 (talk) 17:52, 22 March 2009 (UTC)
 * Yes, a few thousand too many for AWB!! I'm starting another run now. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:42, 22 March 2009 (UTC)
 * Thanks. Too bad though, could have impressed peope with editcountitis otherwise. Garion96 (talk) 20:59, 22 March 2009 (UTC)

Welcome back!
Been anywhere nice? &mdash; Martin (MSGJ · talk) 17:55, 22 March 2009 (UTC)
 * Why yes, thankyou :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:15, 22 March 2009 (UTC)
 * Looks nice! Hope you're better at skiing than I am ... or you're probably quite sore now :) A couple of things ... there is still the display problem with WPBM on Safari. No doubt you have been mulling over this for the past week and now have the perfect answer ready! And we were wondering about the future of the class template, specifically about the styles for the more obscure classes. I recently updated cat class by passing the colours of these classes manually. Perhaps you could comment on this as I'm not familiar with the intricacies of CSS. &mdash; Martin (MSGJ · talk) 20:59, 22 March 2009 (UTC)
 * As a matter of fact I have; my conclusion is that we need to change the CollapsibleTables code to put the show/hide button in a more sensible place and thus avoid the nasty nested tables that are making such a mess in the first place. I'll take another look at ; I really need a todo list - I keep losing whole projects through sheer forgetfulness! <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 21:24, 22 March 2009 (UTC)
 * I wa curious as to why the Future-Class colour seemed to be predefined even though it is not in MediaWiki:Common.css, but the other obscure ones were not. &mdash; Martin (MSGJ · talk) 07:09, 23 March 2009 (UTC)

You have missed the most interesting. Ruslik (talk) 18:49, 22 March 2009 (UTC)
 * I know! I have some serious catching-up to do! Although it's not an obvious focus of mine, I can see immediately how it impacts my life: all the warning messages use the wrong mbox template (ombox instead of fmbox) but to fix that we probably need more types of fmbox! <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:15, 22 March 2009 (UTC)
 * Do you know about this poll? Your input into this discussion about implementation is also appreciated. Ruslik (talk) 13:03, 24 March 2009 (UTC)
 * I am aware of it; congratulations for finally coming up with a FlaggedRevs configuration that a vast majority can accept! It is, if you don't mind me saying so, a bit of a technical dog's dinner, but we can work around that to produce largely the experience that's being proposed.  Unless you can give me the York Notes version, I seem to have a lot of background reading to do before I can be of much use in that discussion! <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 13:31, 24 March 2009 (UTC)

Removing other peoples input in discussions
Please do not do this again. I do not appreciate you deleting what I think is a good proposal which will benefit this project and you removing it as spam. I would never dream of removing anything in a public forum said by anybody else so I urge you to reconsider who on earth you think you are to be removing a converstation I moved to a better place for discussion. Dr. Blofeld      White cat 19:30, 23 March 2009 (UTC)


 * I presume you are referring to this edit? Which is an exact duplicate of the thread that has already been removed from the Bureaucrats' noticeboard here? And which you have also placed in numerous other irrelevant places? I'm afraid I will not withdraw my assertion that this is at best forum shopping, and in reality little more than disruption. The proposal may have merit; I haven't had the time or inclination to look at it properly given the unconstructive manner in which it has been presented, and thoroughly childish responses such as this and particularly this do nothing to encourage me to take you or it seriously.  And in reviewing your contributions to write this response, I see edit streams that have all the hallmarks of a malfunctioning automated script, running on an unflagged account.  I do hope you're not running an unapproved bot there.  Have a nice day. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 21:26, 23 March 2009 (UTC)

Automatic assessments
Forgive me if this is a daft question, but how do automatic article assessments work? Is the auto parameter in a project banner just there to provide a notice and/or categorisation? Must a bot be requested to do the assessments on a case-by-case basis, or is there a pre-approved bot for this sort of thing? PC78 (talk) 17:32, 24 March 2009 (UTC)


 * Yes, the parameter is set by a bot when doing automatic stub assessments; there are a number of bots already approved to to banner tagging, and most of them set the parameter when they automatically assess articles. The parameter itself just adds a notice and a category so the assessments can be human-reviewed. If you want a set of categories tagged-and-assessed, just ask at WP:BOTREQ. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:17, 24 March 2009 (UTC)

MediaWiki:Common.css
I'll ask here, because such things are a little over my head. :) Would it be possible to add the colours for the non-standard assessment grades, Future, Current, B+, Merge & Needed-Class? I'm thinking it would be of benefit to the class template where these colours need to be defined manually. On a related note, are there any plans for a similar template to handle the various importance types?

BTW, I chanced upon your .js subpage last night and pinched the bit that creates a "null" tab at the top of the screen, so cheers! 'twill come in handy! :) PC78 (talk) 19:42, 24 March 2009 (UTC)


 * I'm still pondering over how best to implement those nonstandard class colours, but I'm more inclined to think that they should be somehow applied as an 'exception' by the template. The sitewide stylesheets are for styles that are applied very widely across the site, usually to thousands or tens of thousands of pages.  All of the definitions in place do meet that criterion.  The B+ styles, by contrast, would be used on just 84 pages; the others are a similar story.  More generally, it sets the unhelpful precedent that any project that decides to use any bespoke class, no matter how little it is used, can get it added to Common.css automatically, which is not a Good Thing.  I think we should work on a way of applying these styles in the template. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:46, 25 March 2009 (UTC)

Well, those five are, I believe, the only nonstandard classes with any wide(ish) degree of usage. (Side note: what is meant by "nonstandard" anyway? What makes the likes of Redirect and Project-Class not "nonstandard"?) On the subject on nonstandard classes, I went through them all last night to see what was what, and the majority of them seem to have little or no use at all. Here's a copy of the notes I made:


 * Afd-Class, MergeDel-Class, Merged-Class -- unused, formerly used by WP The Beatles, WP Led Zeppelin, WP Indiginous peoples of North America & WP Western Sahara (1 use of Merged Class only)
 * Cat-Class td -- redirect to Category-Class td?
 * Dab-Class td -- redirect to Disambig-Class td?
 * Image-Class col & Image-Class td -- redirect to File-Class col & File-Class td?
 * Normal-Class -- should be "Normal-importance"; WP Volleyball, but unused
 * Reassess-Class -- unused
 * Structure-Class -- unused
 * Unused-Class -- used only in a bot-created list
 * Assessed-Class -- used in assessment tables; recategorise in ?
 * No-Class -- used in assessment tables; rename as "Unknown-importance"? No-Class td unused
 * Core-article -- rename as "Core-importance" and recategorise in ? used primarily by WP Biography
 * very-low-importance, Very Low-Importance -- unused
 * Bottom-importance -- used by WP Comics, WP Cricket, WP Dungeons & Dragons & WP Nw Brunswick
 * No-importance -- used by various WPs
 * Unassessed-importance n -- unused; rename as "-importance n"?
 * Unknown-importance -- minimal use; synonymous with -importance?
 * Article-type, Category-type, Image-type, List-type, Template-type -- minimal use; primarily used by WP New Orleans
 * WikiProject-Type -- used only in the deprecated (and itself unused) WP X
 * WPArtemisFowl/attention, WPArtemisFowl/needs-photo, WPArtemisFowl/needs-infobox -- unused due to WPBannerMeta conversion
 * WPZW/attention, WPZW/merge, WPZW/needs-infobox, WPZW/needs-map, WPZW/needs-photo, WPZW/old-peer-review, WPZW/peer-review -- unused due to WPBannerMeta conversion

It should be possible to kill some of these off. I've already listed a few at TfD if you're interested. Regards. PC78 (talk) 19:49, 25 March 2009 (UTC)

Village pump (technical)
^^^ I've deleted the new separator you created until consensus for the change is obtained. – xeno  ( talk ) 21:39, 25 March 2009 (UTC)
 * Thank you for filing the bug report, and sorry if I had misinterpreted your actions =) – xeno  ( talk ) 12:22, 26 March 2009 (UTC)

Regex gives me a headache
Special:AbuseFilter/61

Compare:

(<ref[^>\/]*(>.*? |\/>))

to

<ref(?!e)[^/>]*(/>|>(?s:((?! ).)*) )

Dragons flight (talk) 01:43, 27 March 2009 (UTC)


 * Regexes get particularly nasty when using them to parse html. Chillum  01:54, 27 March 2009 (UTC)

CSD move
This would have gotten lost in the big angry thread, so let me post it here. I happen not to like the "summary" change, but that's beside the point. You got bitten by one of Wikipedia's little failings - it's nearly impossible to really gauge consensus for something like that, because it's nearly impossible to advertise it widely enough to get an opinion from a big enough slice of people. That means that only way to see if such a change is objectionable is to do it and wait for objections (as you did) - but then you get opinions mainly from those who object, and of course you get accused of "being too bold". It's not your fault really, so please don't get too worked up about it. I would add one of those templates here, except that I never do that. Hope you get the idea regardless. — Gavia immer (talk) 17:27, 27 March 2009 (UTC)
 * Thanks for the kind words. I was aware that I was not so much opening the can of worms as shaking them up, poking them with a stick and then throwing them across the room, but as you say it's often the only way to get enough people actually interested and contributing to the discussion.  At least now we have people taking the idea seriously.  <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:31, 27 March 2009 (UTC)

WP 1.0 stats
I have no idea why the stats table was wrong; when the bot tried to read the files from disk it had some sort of hiccup. I ran the stats again and they seem to be right now. &mdash; Carl (CBM · talk) 02:59, 28 March 2009 (UTC)

String templates
Hi Happy-melon. I see you have worked in the string templates area. (We run in to each other all over the place! :)) I have just built a set of much more efficient string length templates, two of them are str ≥ len and str len full. And I am thinking of reworking several of the other string templates, and of doing more improvements to italictitle. Anyway, what I came here for: I am planning to merge some of the string length templates, see discussion at Template talk:Str len. Just wanted to give you a heads up, in case you want to comment.

--David Göthberg (talk) 07:22, 29 March 2009 (UTC)


 * I have now merged the string length templates. str len now uses my new optimised code, and str len full and strlen now redirects there.
 * I found your old sub-templates strlen/hundred and strlen/ten, do you want to keep them somewhere? They seem to never have been used. (Nice to see that we used a similar solution when we optimised string length measuring.)
 * --David Göthberg (talk) 15:00, 30 March 2009 (UTC)
 * No need, I've deleted them. Thanks for taking on that little cleanup task; since the string functions we have are essentially layers of abstraction on one fundamental process, any increase in efficiency we can get with them is a tangible benefit. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 14:37, 2 April 2009 (UTC)

GFDL1.2 only
Just checking:
 * 1) First, I'm annoyed that this discussion slipped by without even being noted on my radar. This should've been discussed even wider with a note on recent changes and such.
 * 2) If I understand correctly, the aim is to avoid this tag being used in new uploads. Are safeguards in place to avoid existing images from being deleted instead of being moved to Commons? = Mgm|(talk) 09:10, 2 April 2009 (UTC)


 * I haven't been very heavily involved with that discussion, but I generally agree that wider participation can rarely be a bad thing. There are no existing images under this license, so your second point is invalid. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 14:41, 2 April 2009 (UTC)

Talkback
-- IRP ☎ 21:08, 3 April 2009 (UTC)


 * I do have that page watched; there's no need to poke me quite so hard :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:17, 4 April 2009 (UTC)

Redirecting talk pages with content
Perhaps you agree with me that the use of Softredirect is a wise choice when dealing with such pages? __meco (talk) 17:29, 4 April 2009 (UTC)
 * I'm being careful when redirecting pages that contain more than just wikiproject banners, but in the instances where I have redirected it's because I feel the content is not relevant to the current situation: in general it refers to issues from before the page was merged or redirected. As such I think that hard-redirecting is appropriate.  Do you disagree? <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 17:36, 4 April 2009 (UTC)
 * If I may (because I'm bored and this popped up on my watch list), I've never seen soft redirects used in such a fashion before, nor do I think it is necessary. There's nothing wrong with a hard redirect for a page like Talk:Kelipot where the only content would otherwise just be project banners. For something like Talk:Matrixism where there is actual discussion, I would not redirect the page at all; redirects can have talk pages as well, y'know! :) Just my 2¢. PC78 (talk) 17:44, 4 April 2009 (UTC)
 * I agree that a page containing only WikiProject banners could be redirected, however, there is no need to blank the page as the hard redirect works the same way whether or not there is content on the page. Also, in the case of project banners, there is an assessment class called Redirect-class. Removing these banners is tantamount to enforcing the position that this class is superfluous. __meco (talk) 18:38, 4 April 2009 (UTC)
 * Well, I suppose I do disagree. I wouldn't like to see any content emptied out (without being properly archived) unless it was patent nonsense or vandalism. Note that a hard redirect can simply be added to an existing page without removing previous content. But again, to what purpose? Why not give the person who happens to stumble upon these pages the option of perusing its content as well as clicking conveniently on a soft redirect? __meco (talk) 18:38, 4 April 2009 (UTC)
 * It's not like the content is being removed or even concealed: unlike deletion, the past discussions are still available to all users, admin or not. Adding redirects on top of other content is a Bad Idea, as it screws up various link tables: for instance, if the text underneath the redirect includes an internal link (inevitable), then viewing WhatLinksHere for the link target will show the talk page listed as a redirect to that page, even though that is not actually the target of the redirect.  Ditto for included templates, categories and files.  All rather messy.  <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:54, 4 April 2009 (UTC)
 * I really wasn't aware of this buggy feature. I suppose a soft redirect wouldn't do that, or..? __meco (talk) 19:09, 4 April 2009 (UTC)
 * is just a template that outputs content that mimics a redirect's appearance, so no; it has nothing to do with a real redirect. The issue is whether it's useful to leave talk pages of redirects as freestanding pages: in almost all cases, if a user clicking on Foo is redirected to content at Bar, then a user clicking on Talk:Foo is looking for discussion related to the content at Bar, which means Talk:Bar.  If the user is looking for discussion about Foo itself, that's only one click away down the "redirected from" link. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 19:57, 4 April 2009 (UTC)
 * Still, it isn't appropriate to remove the WikiProject banners of those projects that have decided to categorize redirect pages. I am also concerned that relegating users to clicking on the history tab to see if there might be past discussions worth retrieving from the page history is cumbersome and this possibility is likely to avail experienced users only. __meco (talk) 20:13, 4 April 2009 (UTC)

Perhaps a clarification of what I was doing would help. From the discussion at Template talk:WPBannerMeta, I'm working to remove Redirect-Class from the 'standard' scale used by projects, so that we don't have to force all wikiprojects to create and maintain Redirect-Class articles. The option is still there for projects that can and do use the class, but the majority of projects don't. To do that I'm going through a tracking category that lists all pages marked as Redirect-Class. I'm checking whether the corresponding project actually uses Redirect-Class and has a populated category, or whether the categorisations are 'accidental'. Previously if the category didn't exist, a message on the template page prompts for its creation; once the category is created, then people redirecting the page may innocently change all the banners on a talk page to Redirect-Class, populating the category even if the project doesn't actually use it. It's these cases that I'm clearing out, where the category has between one and about ten pages in it, with no evidence that the category is actually being used. I've managed to reduce the size of that category from 3,600 this morning down to about 300 now through redirecting such talk pages when it seems appropriate to do so, correcting the class rating to NA-Class when the content should be left, or by modifying the banner to continue to support Redirect-Class if it's obvious that the project in question is making proper use of it. I hope this clarifies. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:23, 4 April 2009 (UTC)

UCFD -> CFD
We're discussing modifying a template or creating a new one. Your thoughts/help would be welcome. - jc37 20:51, 2 April 2009 (UTC)
 * WT:CFD
 * Where? :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:52, 2 April 2009 (UTC)
 * Added the link above, sorry about that : ) - jc37 21:26, 2 April 2009 (UTC)
 * Ping. Here, there, and everywhere : ) - jc37 23:43, 4 April 2009 (UTC)
 * Pong :D What is there actually for me to do here? If you need help with a specific bit of template code, then do say, but CfD is not an area of expertise for me, I'm not best placed to comment on the merge itself. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 08:37, 5 April 2009 (UTC)
 * The merge is pretty much done (though I still am finding straggling text here and there...(
 * What I was hoping for would be some thoughts/comments concerning the archiving, and how it might be implmented, and maybe even help with the implementation : ) - (See the discussion for more info.) - jc37 08:44, 5 April 2009 (UTC)
 * Your idea with the tag is good and should be easy for a bot to work with.  You need to talk to the operator of the archive bot to get any extra functionality you need from it.  I don't really understand the need for a separate archive copy for UCfD noms in the first place, but that's not really my field. If you do want to create a copy to collect UCfD noms, you're going about it in exactly the right way. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 08:57, 5 April 2009 (UTC)
 * *Gasp* - I'm doing something right? (grin)
 * As for the reasons, it's a long story, to pretty much make everyone (including the bot runners), for various reasons, happier : )
 * I dropped a note on Rick Block's talk page awhile back, how would you suggest I update my comments there? - jc37 09:00, 5 April 2009 (UTC)
 * Explain what you want to do (add something to the closing tags that the bot can pick up on) and ask if it's possible, to which he should say either "yes I'll do it now" or "yes give me a minute/month". Once he's written the code you're good to go.  It's not a difficult thing to do, just might take him a while to get round to it. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 21:42, 5 April 2009 (UTC)

DRV notice
I'd like to see if we could cobble together a new template. One which could be optionally placed atop a closed XfD discussion noting that the discussion has been nominated for DRV.

It would need to be something small, possibly transparent. Similar to the TfD template maybe?

With a notice like: The following discussion has been nominated at WP:DRV (with a direct link to the discussion).

So something small, and unobtrusive, but which could help aid navigation.

Doable? - jc37 21:30, 2 April 2009 (UTC)


 * That's certainly doable, and shouldn't be very difficult. But would that be helpful? Very few editors are going to be randomly looking through the XfD archives looking for such tags; almost everyone who finds the old XfD will do so through the DRV. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:13, 3 April 2009 (UTC)
 * The idea is that this would be an optional tag to place over a closed discussion, to inform those who may still have the discussion on their watchlist. And further, for those who might be researching past discussions, it would make finding DRVs related to a discussion, easier. - jc37 15:06, 3 April 2009 (UTC)
 * And yes, this is a request for your help at creating such a template : ) - jc37 08:44, 5 April 2009 (UTC)
 * Why don't you have a go at creating such a template yourself? If you get stuck or need any help, don't hesitate to ask, but it doesn't strike me as a particularly difficult exercise. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 08:53, 5 April 2009 (UTC)
 * Well, because I'm usually better at editing once the "core" is done : )
 * Also, besides just modifying a copy of template:TFD, I was hoping for some other thoughts about how it could/should look. Since XfD closures are blue, perhaps a red background might stand out? or would transparent be better? etc.
 * Also, might this be done with one of the mboxes? or better if it wasn't? - jc37 08:57, 5 April 2009 (UTC)
 * You could do it with ombox; that might look nice. Or maybe the small version. There's really no substitute for playing around. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 15:16, 5 April 2009 (UTC)

Template:Class
I suspect this wasn't what you were trying to type in Class: |redriect = background:#C0C0C0; —Ms2ger (talk) 16:34, 5 April 2009 (UTC)


 * Not quite! Thanks for spotting that! <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 16:37, 5 April 2009 (UTC)

* cough* Template talk:Class Why do you need that line anyway when the colour is defined at MediaWiki:Common.css? PC78 (talk) 16:36, 5 April 2009 (UTC)

Assessment issues
Hello, I am wondering if you can help me. The wine and spirit banners all have the redirect class but when I add that class to redirect pages, it assigns them to the project class articles. could you please look at this for me?

Here are the two redirects I assessed as redirects:
 * Wikipedia talk:Wine
 * Wikipedia talk:Spirits

PS

I like the tweaks you did to the assessment graphics, they look real nice.

--Jeremy (blah blah) 19:13, 5 April 2009 (UTC)


 * Do you want the Redirect-Class assessment? It was recently (ie this morning) removed from the default configuration in WPBannerMeta because so few projects were using it; I concluded from the fact that these projects had few or no articles in their category that they weren't among them. If you still want to use this assessment grade, you can add it using a custom mask, but you should think about whether the project would actually find the grouping useful, or if it's merely a keeping-up-with-the-Joneses ("project X has it, so should we") feature. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 19:18, 5 April 2009 (UTC)


 * I was actually using them, not because other projects were, but because they were there and they were good tags to organize page related to the project that are just place holders. I put soft redirects on those pages in conjunction. I actually like the tag. --Jeremy (blah blah) 03:24, 6 April 2009 (UTC)

Class and the -Class td templates
So far as I can tell, the code for Class seems to be compatible with the various -Class td templates. Would it be possible (for example) to replace the code of FA-Class td with ? PC78 (talk) 21:08, 5 April 2009 (UTC)
 * Given the way we're storming towards a 100% implementation of WPBannerMeta, I think all of those templates will soon become redundant. On a technical front, yes, they are fully compatible in the way you describe; I'm not sure how useful it would be to make that change, however; perhaps we should be looking to TfD them once they're unused... <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 21:11, 5 April 2009 (UTC)
 * Meh, just looking at ways to consolidate the remaining class templates, but I'm all for orphaning & deleting. :) I've already found plenty to delete in my recent clearout of the more obscure and unused templates... PC78 (talk) 21:38, 5 April 2009 (UTC)
 * You marked the lot?!?! Good job!  Poke me in a week and I'll go and T3 the lot of them :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 21:48, 5 April 2009 (UTC)

Diff on
Hello Happy-melon,

Since you seem to be the go-to guy on this template, I thought I'd alert you to a change I made: see here. I introduced this change for the sake of references formatted like ref 1 here; see how we have  AND. I've seen many articles with refs formatted like this, so I figured the change was necessary and couldn't do any harm. However, I've come to you to make sure that there really is no harm in the change. Thanks for your review. &mdash; Anonymous Dissident  Talk 08:00, 7 April 2009 (UTC)
 * My change didn't work, and I've reverted myself. It caused to appear appended at the end of all references with . Still, I think you can see what I was trying to introduce support for, so I'd still appreciate it if you'd look at the situation. Best, &mdash;  Anonymous Dissident  Talk 08:28, 7 April 2009 (UTC)
 * A later version appears to work, but I could be wrong. &mdash; Anonymous Dissident  Talk 08:30, 7 April 2009 (UTC)
 * It works as long as accessdate is given in day-month format. If it's given as month-day it will end up as "April 7 2009". That's why cite web has the accessdaymonth and accessmonthday fields, accessdate may only contain a full date. Now, with the string manipulation functions we could hack something together to try and turn everything into a proper date, but that won't be pretty (and possibly too heavy to parse for some pages with lots of references). I could also see the template (and its friends) automatically categorizing pages in a new "Category:Invalid citation parameters" and write a bot to go through and fix them all, it seems that they are used incorrectly quite often. For what it's worth, AD, you can't use the  parser function with an "and" keyword.   only evaluates if the the first parameter is non-empty, and the "and" is taken as a literal, so it was never empty. What would have worked is   Amalthea  09:07, 7 April 2009 (UTC)
 * Hmm, the parameters could probably be analyzed with  which is less heavy. -- Amalthea  09:14, 7 April 2009 (UTC)
 * Perhaps a comma between  and  would solve the problem from a logistic standpoint? ie. April 7, 2009 is acceptable, as is 7 April, 2009. &mdash;  Anonymous Dissident  Talk 09:19, 7 April 2009 (UTC)
 * But ... but ... think of the MOS! It's probably OK as it is, seeing that those parameters are deprecated, and that  produces the same incorrect format. -- Amalthea  10:36, 7 April 2009 (UTC)
 * If you want my £0.02, that ref is simply incorrectly formatted and should be corrected to use only accessdate. The parameter sets that should be used are only accessdate or accessday, accessmonth and accessyear. Any other combination of those is just Wrong, and should be fixed, manually or by bot.  <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 10:48, 7 April 2009 (UTC)
 * Well, is there any actual problem with leaving it that way? Why is it just "wrong" if it formats the date properly from an aesthetic viewpoint? &mdash; Anonymous Dissident  Talk 11:03, 7 April 2009 (UTC)
 * Because as Amalthea notes it's more difficult to format them consistently; it's more complicated and messy code, and it creates the incorrect impression that it might be acceptable to do a similar thing with date and, archivedate and archiveyear, etc etc. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 11:08, 7 April 2009 (UTC)
 * Well, all I can say is that I've seen this ref format quite a bit. It's not an isolated incident. The options are 1. to create a bot to fix he instances or 2. introduce support for it in . If you'd like to do the former, so be it; but if not, and the only problem with my solution is more code and an impression, it should stay, because otherwise we have an unknown number of days and months without years appended. &mdash; Anonymous Dissident  Talk 11:19, 7 April 2009 (UTC)
 * Oh certainly the code should stay, I didn't mean to suggest otherwise. I may well extend my cite web maintenance script to cover this as well so we can properly resolve this issue. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 11:23, 7 April 2009 (UTC)

classicon
Could you add "unassessed" as an option to classicon so that doesn't trigger the Category:Deprecated use of classicon ? -- WOSlinker (talk) 19:12, 7 April 2009 (UTC)


 * You may also need to handle Current, Feture, Needed, Merge & SL. -- WOSlinker (talk) 06:31, 8 April 2009 (UTC)

Bot fault
Please see this. I figured you should be aware of the issue. -- Cyde Weys 09:42, 8 April 2009 (UTC)

-Class
* poke* Can you please have another look at this? As far as I can tell the code looks good, so I'm inclined to think it was the meta's handling of the template that was causing problems rather than the change itself. Since the meta no longer uses this template, it should be easy to tell if the change is causing problems elsewhere. Cheers! PC78 (talk) 18:43, 7 April 2009 (UTC)
 * Well poked, I've restored the changes. I wouldn't be surprised if problems do arise elsewhere, but as you say, they won't be in WPBM, so not my problem :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:23, 8 April 2009 (UTC)
 * Cheers. A random sampling of pages suggests that all is well; the only problem I see is that some banners are using -Class where they should be using -importance, but that strikes me as poor banner design and so isn't really my problem either. ;) A minor (very minor) issue I spotted in meta banners is a marginal (very marginal) misalignment in the text of the class and importance templates. You can see it best with the ??? on Talk:Active citizenship. I would guess the cause lies with the class template, but it's a trivial concern. PC78 (talk) 15:32, 8 April 2009 (UTC)
 * It's because the nbsp between the image and the text isn't being hidden along with the image. I couldn't think of a nice way to hide it too without bloating one or other template too much. It'll go away if we do importance the same way :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 15:35, 8 April 2009 (UTC)
 * What about placing another nbsp after the text? PC78 (talk) 15:38, 8 April 2009 (UTC)

Template talk:WikiProject Video games
an edit-protected request I just fulfilled may have stomped on your recent edit, want to visit and comment? – xeno  ( talk ) 14:02, 9 April 2009 (UTC)

Misunderstanding of WP:PROD
Replied on my talk page, of course. Flyer22 (talk) 17:17, 9 April 2009 (UTC)

subst
Is there a way to have text on a page, but to not have that text be included when subst-ing that page? - jc37 18:15, 10 April 2009 (UTC)
 * Wrap it in

tags
 * – xeno  ( talk ) 18:21, 10 April 2009 (UTC)


 * That'll work if you don't want it transcluded either; there is no clean way to have a different content when transcluded to when substituted; one or other display has to contain code fragments. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:23, 10 April 2009 (UTC)
 * I knew "noinclude" works for transclusion. but it also works for subst?
 * I've cleaned up enough userbox pages to wonder : )
 * But ok, I'll have to test that. Thank you : ) - jc37 18:26, 10 April 2009 (UTC)

Cool it seems to work : )

Now what I need is to be able to have the numbers be able to change based upon a "switch".

See User:Jc37/RfA/General questions.

I'd like to be able to indicate the starting number, and have the rest be automatically "set".

I'm guessing that this would be done with some variables?

Would the following work?:

(Where "start" is the variable for whatever the number should start with.)

Or is there a better way to do it? Also if done as the above, I'm not sure how to make a number to be start+1 : ) - jc37 00:28, 12 April 2009 (UTC)


 * → . See mw:Help:Extension:ParserFunctions for more. -- Amalthea 00:41, 12 April 2009 (UTC)
 * Thank you, that's exactly what I needed.
 * See User:Jc37/RfA/General questions. It works great : ) - jc37 01:19, 12 April 2009 (UTC)

Fmbox
Hi Happy-melon. I'd like to explain my thinking around the fmbox divs and template. But since this is kind of "wiki strategy" I don't want to explain it on the fmbox talk page. So here goes:

Technically I liked to use "div.fmbox-warning" for those system message boxes that are simple boxes and don't contain any images. And I wanted to document that approach in the fmbox /doc. Since I find using the div is just as easy as using the template, and I find it more robust and efficient.

For system message boxes that contain an image I of course want to use the fmbox template. Since such boxes are too complex for people to hardcode, they just screw it up too often then.

As you pointed out having two different approaches might confuse people. But I think if we explained the div method in the fmbox documentation, then it would probably solve that.

The real reason why I accepted removing the div approach is this: I think many people would see the div approach as a kind of hardcoding of the messages, and thus they would think it legitimises the hardcoding of more complex message boxes. While you and I know it is better if they use the fmbox for the more complex messages. So giving up the div can perhaps help us in getting people used to the fmbox as the standard solution for system message boxes.

So for "wiki strategical" reasons I accepted removing the div. Even if I think it is not the best technical path. Unfortunately (as you have pointed out to me repeatedly), we are handling humans here just as much as we are handling computers...

So our reasons to not have the div are similar, but perhaps not the same.

--David Göthberg (talk) 20:11, 10 April 2009 (UTC)


 * I think you're right about our reasons being similar; I wanted to deprecate the div.fmbox-warning method partly to encourage the wide use of for system messages.  When I came back from holiday and found that the AbuseFilter had been enabled, one of the first things I did was to go through and change all the warning messages to use fmbox; previously they had used ombox.  Establishing fmbox as the 'instinctive' choice for system messages is a slow process - as you say, we're dealing with humans, they can't just be programmed to use a particular box in a particular place - and the only way to do it is, IMO, to make it totally ubiquitous: "oh look, another system message, another fmbox", etc.  So we're both mainly concerned with people seeing alternative methods as a disincentive to use fmbox, which is a Bad Thing.
 * The other part of my 'wikistrategy' on system messages is now in play on MediaWiki talk:Common.css: as well as resolving an inconsistency that has been bugging me for some time, a part of the reason for me wanting to change the preview notice is to get the div version of fmbox-editnotice into Common.css. Once that's done, it will be easy to standardise other awkward messages like the "this edit can be undone" message that appears when you click "undo".  You might disagree with that for the same reason as the preview bar, but that's the sort of thing I'm aiming at.  Improved consistency == improved professionalism, IMO. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:23, 10 April 2009 (UTC)


 * Oh, I didn't notice that the code you suggested for the preview header is a div version of fmbox-editnotice. I see what you mean that we then can simply add the ID or class of other system messages to that declaration to make them look like fmbox-editnotice messages.
 * But when it comes to the preview header, then we do disagree. Since I really think that one needs to stand out. It can't just look like any other box.
 * I agree that MediaWiki:Undo-success should be changed to have the 100% wide fmbox-system style. I see that MediaWiki at rendering time surrounds that message with a div with class="mw-undo-success", so it could be done by adding a "div.mw-undo-success" class with fmbox-editnotice styling to Common.css. (And I don't mean the inner div it had with id="mw-undo-success".) But I prefer using the fmbox template instead in this case. Partially since that id has to be placed somewhere, and fmbox has an id parameter. So I have now fixed the MediaWiki:Undo-success message.
 * --David Göthberg (talk) 02:53, 11 April 2009 (UTC)

LEPS
Please see User:IRP/LEPS. I have finished creating it and I am requesting that it be implemented by an administrator. It is a system that I decided to create (after seeing your comment at Template talk:Asbox and JMesserly's comment at Wikipedia:Village pump (miscellaneous) ) to help prevent the insertion of confusing or deceptive links. -- IRP ☎ 23:18, 11 April 2009 (UTC)
 * That's an interesting idea, but I'm not sure if it's possible or practical using the AbuseFilter system. Although I have AFE, I'm not particularly strong on the semantics of filter syntax; I can't tell you whether what you propose is possible or not with the AbuseFilter mechanism.  You'd have to ask at WP:AF/R. I'm also not entirely convinced that such an aggressive approach to resolving these inconsistencies is the best approach. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:58, 12 April 2009 (UTC)


 * I assumed that this would be a perfectly OK idea because there is also a filter that disallows test edits, which aren't particularly abuse unless a user continually does it after a series of warnings. This makes me assume that it isn't only used to prevent abuse, but common mistakes, such as link errors (as mentioned in my first post) and test edits (as mentioned in this post). I have made a request. You can see it at Abuse_filter/Requested. -- IRP ☎ 10:53, 12 April 2009 (UTC)

It looks like no administrator or abuse filter editor saw the request. Is there a place where I can put a request where someone will see it? -- IRP ☎ 20:14, 13 April 2009 (UTC)


 * That is the place :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:15, 13 April 2009 (UTC)

Are you...
...open to trouting? – xeno  ( talk ) 20:06, 13 April 2009 (UTC)
 * Why, what have I done now? <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:10, 13 April 2009 (UTC)


 * Too late! Anyways, that's for slowing down my browser, making me wrack my brains, pull my hair, uninstall all kinds of (admittedly unnecessary) background processes, re-install Firefox, delete Firefox, re-install Firefox again, delete all my saved passwords and forms, consider going back to IE (ugh), install Chrome, and then finally realize the problem wasn't local. don't worry, I know you were acting in good faith (and probably couldn't have had any idea whatever you did would slow down mah wiki), but this makes me feel a bit better ;p – xeno  ( talk ) 20:15, 13 April 2009 (UTC)
 * On the ambox thing? That was User:Davidgothberg, not me... wasnt' me, guv'nor :P <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:35, 13 April 2009 (UTC)
 * o dam ! blue on blue ! – xeno  ( talk ) 12:23, 14 April 2009 (UTC)

Broken template
Can you look at AfricaProject? There is some error in its code. No matter how I assess pages like File talk:Scout gambia badge.png and Template talk:National Parks of Burundi, it still triggers inclusion in Category:Unassessed Africa articles and Category:Unknown-importance Africa articles. Thanks.  MBisanz  talk 21:28, 14 April 2009 (UTC)
 * That's one of the few remaining silly banners that doesn't properly control its class input. Any value of class will be accepted for display: the template will proudly state that "this article has been rated as Cheesecake-Class on the quality scale" if you set cheesecake!!!  However, neither Cheesecake nor File or Template are quality ratings used by WPAfrica, so it's reported as unassessed.  You should assess them as NA-Class, and try to persuade the project to convert to WPBannerMeta, which would treat Cheesecake == File == Unassessed for both display and categorisation. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:17, 15 April 2009 (UTC)

Request
I have made a request at MediaWiki talk:Common.js. -- IRP ☎ 00:45, 15 April 2009 (UTC)

CSS definitions of styles for quality classes
Hi. Would I be right in thinking that the definitions in MediaWiki:Common.css of the background colours for quality assessments are not being used now? &mdash; Martin (MSGJ · talk) 19:15, 14 April 2009 (UTC)
 * You would. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:07, 15 April 2009 (UTC)
 * Shall I remove them then? &mdash; Martin (MSGJ · talk) 11:28, 15 April 2009 (UTC)
 * Go for it. Don't remove the importance ones though, as they're actually being used by, etc.  As-and-when we implement some meta-template for them, we should remove them too.  Adding them in the first place was a mistake. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 11:48, 15 April 2009 (UTC)
 * Okay, I will hang back until I or someone else has implemented importancecol across the board and then get rid of them all. Should the references to these classes be removed from each template (e.g. A-Class currently contains class="assess-a")? What will happen if it refers to a definition which doesn't exist? &mdash; Martin (MSGJ · talk) 12:00, 15 April 2009 (UTC)
 * Nothing, and the classes should be left in the templates so that users can style them themselves if they want different colours, different font, crazy flashing upside-down text, etc etc... <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 19:56, 15 April 2009 (UTC)
 * Okay thanks, I have now removed all the quality and importance definitions from MediaWiki:Common.css. Hopefully none have been forgotten! By the way, is there any way I can find the surplus entries in Category:Redirect-Class AFC articles? &mdash; Martin (MSGJ · talk) 21:32, 15 April 2009 (UTC)
 * Nice work. I don't think there's any way to find them short of searching through the deletion log looking at old revisions, restoring and deleting any that would have categorised into the category.  Only pages that were deleted during the window when we were running a MW version between r40912 and r47326 would be affected; you could look through the history of the server admin log to find when that was.  It's not a task I would relish!  I'm writing a maintenance script that will refresh the counters for all categories, it needs to be finished, then committed by someone with SVN commit access, then run by someone with server shell access.  I'll race you :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:32, 16 April 2009 (UTC)
 * I depopulated Category:Redirect-Class AFC articles and now it is showing as empty so I'm thinking that it must have sorted itself out. &mdash; Martin (MSGJ · talk) 07:29, 18 April 2009 (UTC)

Not urgent, but...
Could you have a look at Template:WikiProject Melanesia? I think it's in the same state Australia's was before you did your wizardry and made it standards-compliant. Thanks :) Orderinchaos 20:37, 16 April 2009 (UTC)
 * Sure, but one question: do you use the portal-# code? Or is that just a throwover from whichever banner the code was pinched from? <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:49, 16 April 2009 (UTC)

Notice

 * What do you want me to do about it? There clearly isn't consensus for implementation in the site javascript, and I don't have SVN commit access so can't fix the bug. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 21:42, 16 April 2009 (UTC)
 * This doesn't require a change in the software or JavaScript. It requires a change to MediaWiki:Monobook.js. The code that has to be inserted in order for this to be fixed was posted at 11477. -- IRP ☎ 22:03, 16 April 2009 (UTC)
 * Actually that needs to be added at Common.css, but the point is, there's no consensus for its addition. Going around making visible changes to the interface just because I agree with you that it's a good idea would be an abuse use of admin tools.  <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:03, 17 April 2009 (UTC)
 * Because of that, I have posted a request at Administrators' noticeboard to see if there will be consensus for the change. -- IRP ☎ 22:21, 17 April 2009 (UTC)